Description of basic functionality

[jonnew]

We want to add two operators that make using the Open Ephys commutator easy:

1. A sink node that takes sequence of doubles and turns the commutator accordly via a specified serial port. It can also expose commutator options such as enable/disable, LED status etc.
2. A transform node that converts Quaternions to rotation values about an axis.

[jonnew]

After playing around a bit, I actually don't like this split. I now like the idea of an integrated node that takes a Quaternion and uses it to update the state of the hardware with all logic required to do this internal. Why?

1. "A transform node that converts Quaternions to rotation values about an axis"
   • This was never a pure transform because you need two Quaternion measurements to create a rotation. Although it will behave as one if you bake in some state for the first value, the first command will always do nothing and its de-facto already a combinator
2. The rate at which commands are sent to the hardware should be kept at 10 Hz or so to prevent communication issues. This means that either the Transform node would need to be combinator that downsampled its outputs, the sink node would need act as a combinator for the same reason, or the user would be expected to put sample between the two and give it a reasonable rate.
3. The idea of hooking up the Quaternion output from a BNO source to a single node with PortName and RotationAxis specified without any intermediate stuff is very appealing to me.

[glopesdev]

@jonnew the issue with making this a mega-node is that it cuts off composition to the point of making the node unusable for all but the most basic cases.

In practice we have never used the commutator operating by itself with just the BNO. We need options for manual intervention, panic button, GUI, etc, many of which are really experiment-specific.

By closing off all composability from this library I don't see how this could be useful for the cases discussed above.

I feel it will also complicate logging and future upgrades as well, since it will make people continue to make their own ad-hoc solutions by encoding turns into JSON manually and doing their own rate control, and this means that any upgrades to the commutator firmware will brick an unknown number of workflows to the point that you will never really want to update.

[jonnew]

100% agree with all of this, but the ease of use trumps most of these advantages in my opinion.

I guess i could write a bunch of small nodes and then create the mega node from the smaller elements as an included .bonsai file.

I could call the meganode something specialized like AutoCommutator or whatever

[glopesdev]

I could call the meganode something specialized like AutoCommutator

I think this is a great idea. By having both the embedded workflow and the more granular operators it should be possible to assemble all the usage patterns and more efficiently update the package in the future.

I can see now better the complications behind the initial naive proposal and indeed the problem gets complicated by an interaction between the need for rate control and numerical accuracy when computing the relative twist feedback signal.

I will submit a PR that tries to address both of these ideas. I have also created a default main branch so we can retarget different PRs for comparison if useful.