Review package requirements and set preliminary design goals

[glopesdev]

We should review the original high-level goals for Bonsai.ONIX and how these have evolved into the current architecture. We would go over the current stack diagram for ONIX hardware and conceive of the best way to map these into Bonsai operators (similar to how we did for Harp, BonVision, DLC, etc).

This is a critical step of the project and often takes up a significant proportion of development time, but is hard to quantify so we would set ourselves a deadline for presenting a solution to you.

[glopesdev]

From #4 (comment)

liboni is a low-level, hardware agonistic library for general purpose data streaming. Its design follows the principles of other libraries built for similar purposes (e.g. sockets, serial IO, etc). An opaque, unique context holds is created one to one with a piece of host hardware. It links the hardware to the API via a dynamically loaded driver. It is meant to be opened and closed infrequently. Currently a context is created and destroyed for every single access to a hardware property outside of runtime which is the complete opposite of its intended usage.

From past experience with both Harp, camera drivers and other hardware integration into Bonsai, the path of least resistance is always to try and express the low-level library concepts closely in the design of the package, so it is great to keep the design of liboni in mind as we think about the refactor.

Related work and preliminary thoughts on architecture (Proposal 1)

For something like liboni, the most recent design we have worked on is actually the new package for Tinkerforge (TF) we developed in the context of the eMOTIONAL Cities project.

Like the ONIX, in TF there is a modular architecture of peripherals that branch out from a single piece of host hardware (the master Brick). We also have a single connection to the host device, which has to be shared to read and communicate with all peripherals (Bricklets) connected to the Brick device. We have modeled this explicitly in Bonsai using a source node that directly creates the connection (CreateBrickConnection).

From this object, we can spawn nodes representing all Bricklets connected to the device:

Workflow

<?xml version="1.0" encoding="utf-8"?>
<WorkflowBuilder Version="2.7.2-build030102"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xmlns:tkf="clr-namespace:Bonsai.Tinkerforge;assembly=Bonsai.Tinkerforge"
                 xmlns:rx="clr-namespace:Bonsai.Reactive;assembly=Bonsai.Core"
                 xmlns="https://bonsai-rx.org/2018/workflow">
  <Workflow>
    <Nodes>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="tkf:CreateBrickConnection">
          <tkf:HostName>localhost</tkf:HostName>
          <tkf:Port>4223</tkf:Port>
        </Combinator>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="tkf:GPSV2">
          <tkf:Uid>PvW</tkf:Uid>
          <tkf:SBAS>Disabled</tkf:SBAS>
          <tkf:StatusLed>ShowStatus</tkf:StatusLed>
          <tkf:DateTimePeriod>10</tkf:DateTimePeriod>
          <tkf:AltitudePeriod>100</tkf:AltitudePeriod>
          <tkf:CoordinatePeriod>100</tkf:CoordinatePeriod>
          <tkf:StatusPeriod>1000</tkf:StatusPeriod>
        </Combinator>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="tkf:GPSV2DateTime" />
      </Expression>
      <Expression xsi:type="MemberSelector">
        <Selector>Time</Selector>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="tkf:GPSV2Coordinate" />
      </Expression>
      <Expression xsi:type="MemberSelector">
        <Selector>Latitude</Selector>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="tkf:HumidityV2">
          <tkf:Uid>WhE</tkf:Uid>
          <tkf:Period>100</tkf:Period>
          <tkf:Heater>Disabled</tkf:Heater>
          <tkf:MovingAverageLengthTemperature>5</tkf:MovingAverageLengthTemperature>
          <tkf:MovingAverageLengthHumidity>5</tkf:MovingAverageLengthHumidity>
          <tkf:StatusLed>ShowStatus</tkf:StatusLed>
        </Combinator>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="rx:Timer">
          <rx:DueTime>PT0S</rx:DueTime>
          <rx:Period>PT0S</rx:Period>
        </Combinator>
      </Expression>
      <Expression xsi:type="Combinator">
        <Combinator xsi:type="tkf:AnalogOutV3">
          <tkf:InitialVoltage xsi:nil="true" />
          <tkf:StatusLed>ShowStatus</tkf:StatusLed>
        </Combinator>
      </Expression>
    </Nodes>
    <Edges>
      <Edge From="0" To="1" Label="Source1" />
      <Edge From="0" To="6" Label="Source1" />
      <Edge From="0" To="8" Label="Source1" />
      <Edge From="1" To="2" Label="Source1" />
      <Edge From="1" To="4" Label="Source1" />
      <Edge From="2" To="3" Label="Source1" />
      <Edge From="4" To="5" Label="Source1" />
      <Edge From="7" To="8" Label="Source2" />
    </Edges>
  </Workflow>
</WorkflowBuilder>

Each bricklet can provide either input or output streams (e.g. see AnalogOutV3). The only constraint is that each bricklet node needs to receive the shared connection from the master Brick as input.

Pros

• Shared connection can be manipulated safely using subjects and / or any other reactive operator
• No hardware access is required at build-time (only need connection for finding bricklet UIDs / serial numbers, but these are editors not compiler operators).

Cons

• All configuration follows the direction Workflow > Hardware (no state is transmitted from hardware to bonsai)
• Cannot easily drop ONIX operators inside task logic like Arduino (although we would argue this is probably a good thing as it motivates use of subjects to develop hardware-independent logic)