alexpiet
commented
1 month ago Great question!
(1) I can track errors from the GUI regardless of what branch/version of the code you are running (just install openssh server, and tell me the computer hostname). So if you have custom hardware, you can test/run it on your own branch with whatever modifications you like, and I can track errors. However, this means that bug fixes/feature releases, any other updates wont get added to your rig each week. For short term tests, this is probably the best solution. For week+ tests it gets significantly less desirable.
(2) You mentioned in the other issue that your hardware interacts with a separate bonsai workflow from the GUI. Its fine to have many bonsai workflows running in parallel, in fact thats how we run the FIP data collection. So if your custom hardware workflow is separate from the GUI, then simply run your workflow (you can use either the version of bonsai we vend with the gui, or a separate one), and run the main/up to date version of the GUI. This is great because you get weekly updates, and error tracking, and can run whatever workflows you like.
(3) If your custom hardware, or software interacts with the GUI code, or task bonsai workflow, then it gets harder to get updates. I would probably develop your code on a branch, and every week pull the most up to date version of main into your development branch. Most likely this will be easy, unless some update is actively working on the same part of the code. Any conflicts would need to be resolved eventually anyways, so it shouldn't be that hard, but it does require manual steps.
(4) For long term support of a custom hardware device, add a setting to the Settings_box#.csv file, like "MyCustomDevice,1", and then update the bonsai workflow to only subscribe to the updated bonsai code if that setting entry is provided. We do this for the AIND Lickity Split detectors, and high speed cameras. Its relatively easy to implement. @bruno-f-cruz provides an example here: https://github.com/AllenNeuralDynamics/dynamic-foraging-task/issues/190#issuecomment-2012912970
Do any of those solutions work for you? Happy to brainstorm other options, or help implement these options
We (myself and @galenlynch ) have been testing out Sonya's (@Poofjunior) Sniff Detector harp board paired with a thermistor (thanks @tiffanyona & @bruno-f-cruz!) for external breathing monitoring during the dynamic foraging task on ephys rig 2. It is working great, but is a fairly boutique solution that will likely only get scaled to other ephys rigs, if at all.
What are the best practices for disseminating Bonsai/gui code to account for this optional device? Also, how is there a way to preserve the tracking features of the behavior service with rig-specific Bonsai changes?