The capture results don't look satisfactory indeed.
Apart from the limbs moving in wrong directions it seems like the packages are arriving to blender with some lag, resulting in shiggly movements. Are you using wifi? Perhaps try the capture once with a long ethernet cable to check if this problem persist. (if you do it ensure the packages are not being transmitted through wifi, for example you can turn down the raspberry's wifi with: sudo ifconfig wlan0 down)
Are you doing the calibration alone? the T pose looking south should be maintained from the moment in which the calibrate button is clicked until is clicked again. If the calibration problem persists please send me a video in where I can see the person wearing the suit together with the blender result
The idea of using CAN or another differential bus is great. The open hardware we provide was conceived to be as simple as possible, and for most domestic use the i2c works well enough, but having the possibility of building a more robust version of the hardware would be a great contribution for the community!
Another good option would be RS485 with an addressable protocol such as Modbus (even if, to be honest Modbus is kind of bloated for this use. One could hand-roll a custom simpler protocol).
In either way, it would require an MCU with new firmware to bridge the differential protocol to the sensor (being at it, the MCU could read the sensor through SPI at higher rates). If you want to go even further the MCU could also perform the sensor fusion and deliver quaternion data to the notochord. In that case a robust enough MCU should be chosen.
So yeah, even for the simplest setup it requires a non negligible amount of work. If you want to give a try implementing a more robust bus you will have all our support!!
