my question revolves around having to create a SuperCollider class to read data from the accelerometer Adafruit LIS3DH (GitHub - adafruit/Adafruit_LIS3DH: Arduino Library for Adafruit LIS3DH breakout board). This sensor is an I2C device and so far I’ve been using my laptop connected to an Arduino, to read the sensor values and stream it into SC via serial port.
This has been fairly simple as LIS3DH requires minimal to none intervention in the Arduino code, being extremely documented there. The problem begins trying to move to a desktop-less system: my choice is Bela (https://bela.io/), which would allow me to run SuperCollider straight on board and work with the sensor data in the same environment, without having to rely on a laptop/desktop to run SC.
In the Bela forum I’ve found some similar attempts (for example GitHub - jreus/Trill_SC: Trill UGens for SuperCollider on the Bela, I2C basis for SuperCollider UGens - Bela), but I lack the formal technical knowledge to understand how to even contemplate setting up such system.
If you’re wondering “why don’t you just use OSC to communicate between the Bela and SC” well, I don’t really know. Probably it would be a triple-backflip pickle to make that happen all on Bela, at least that’s my understanding of it.
To whoever has had experience setting up a SuperCollider UGen to read I2C sensor data, how would you advice me to proceed? What would be a good workflow to get this started?
Appreciate any help on the matter
I have a plugin for the BNO055 IMU made for the Bela, over here: GitHub - jpburstrom/scbno055: SuperCollider plugin for reading BNO055 IMU on Bela. It’s using a couple of auxiliary tasks (a Bela-specific pthread wrapper) to read from the IMU and handle a calibration routine. Hopefully it can be of some use as an example. It works for me, but not being a c++ programmer, I more or less tried things out until it stopped crashing.
I based the IMU reading code on a previous Bela-based project, so I didn’t need to convert any Arduino code. That might be the tricky part. But you could perhaps use the basic structure of the sensor-reading class (in the files Bela_BNO055.cpp/h), and bring in the LIS3DH-specific stuff from the Arduino library.
Hello @jpburstrom - thank you very much for sharing your knowledge about using the BNO055 on a Bela running SuperCollider. Unfortunately I can not fully follow the instructions of yours to get it running just from the Readme. @Robin_Morabito summed up quite well, how I feel about it.
tbh I’m a bit more confused about what to do then before
Would you be willing to provide some further information? Also about the wiring, if all the steps have to be done via SSH on the Bela or on your computer, an example program to see the raw data… I would really like to follow, if you gave me some guidance, and would also be willing to contribute to its documentation afterwards.
So, everything works great here, thanks for your further work on this! During setup I ran into a couple of issues, which I documented and provided as a pull request, so feel free to merge them. Its mostly about some additions for the setup procedure and a wrong class used in the help file. If everything is fine for you, I could also drop a copy&pastable code example in the Readme.
One more question though: I quite don’t get how to get the acceleration running. I expected here values that are changing over time, depending on the acceleration of the sensor, but they remain static. Can you shed some light on this maybe?
Thanks! I’ll need to get back to my Bela to test and see if there’s anything wrong with the accelerometer data. Recently I’ve only used the orientation (euler) data (BNO.orientationKr). Do you get input from any of the UGen methods?
Also make sure you don’t have trigged the calibration. Then it will output zeroes until you have finished the second calibration step. It’s outlined in the documentation but I should probably better document how that’s done – it’s a bit idiosyncratic, like the load/save methods.
Yes, I get input from all the UGens, and can read the orientation data reliably. Also triggering the re-calibration works well.
Its really just that I expected the acceleration data to return values above 0.0 only when the sensor is moving and when it is at rest, to return 0.0 for all directions. Right now the accelKr method seems to return absolute values, similar to the orientation.