I’ve added a “I2CCommander” class in the SimpleFOC drivers repository, you can find it here:
The goal is to allow programmatic control of a SimpleFOC motor driver in an easy way. I know there are better (esp. faster) protocols than I2C out there, but I2C is widely supported, simple to use, sufficient for many use cases and only uses 2 wires. It will be familiar to many users, for example I2C is already used in many of the Arduino DC-motor or servo driver boards out there.
The code has interfaces for both target device (the motor driver running SimpleFOC) and the controller device (some kind of coordinating MCU that is trying to send control messages to one or more motor drivers). The code defines a set of registers which expose the SimpleFOC variables and allow reading/writing them.
It can in theory control up to 256 motors, and deals with multiple target devices, multiple I2C buses and multiple motors (up to 8) per target device. So now nothing stands between you and that kinetic sculpture of 200 motors you were planning
The code is still very new, and barely tested, but the simple use cases I’ve tried so far are working. If anyone is interested, feedback (and bug reports) are welcome!
I’m certainly no expert, but you should get 1m out of I2C without problems, and maybe even 5m or more. It can certainly go further than SPI. Slower speeds help with larger distances, as can shielding the wires, and twisting them around ground lines, but if you have really large distances to cross then either CAN-bus or a point 2 point differential link are better.
You can connect quite a few devices to an I2C Bus, and you can easily “partition” the bus electrically using simple buffer chips, either to help extend its length, or to use different voltages. There are also “signal conditioning” ICs which are like “super pull-ups/downs” and ensure nice “square” signals (steep transitions).
From what I gather people usually have more trouble with the bus capacitance (length, but usually too many devices), address collisions (there are chips to solve it) and “stuck bus” type problems (devices not using the protocol correctly and leaving the bus in an unusable state) rather than distance, but I’m sure if one tries to push it too far, it will fail…
[edit]
I think for SimpleFOC applications the limiting factor will be the speed of I2C. If your application works well just sending a few commands a second to the motor drivers, you will be able to control many many motors with I2C. If the application needs tight timings and lots of feedback from the driver then it will probably not work well for more than 1 motor, if that. I assume a “command rate” (where a command either sets or reads a value from a driver) of a few kHz is realistic, shared over all the driver boards on an I2C bus.
Thank you, this would be perfect for commanding motors from ROS - I wrote my own I2C code for testing last year around the same time you published this, but I think I’ll test and use yours - mine is just spagetti code, but still works well (never hit auto shutdown if no command received from I2C for 10ms).
SimpleFOC is the perfect candidate for robotics and though I2C is somewhat slow, 99% of hobby robots do not require anything faster than I2C - bellow 10ms should be fine for any moving platform with speed of 2m/s or less.
I’ll have to write my own I2C publisher for ROS based on your code and I’ll share it with the community in case there is interest to publish it and promote simpleFOC with the ROS community - I’m very slow in my hobby because of lack of spare time, so it might take months.
No problem if it takes months, same here on my side: never enough time for SimpleFOC!
I think that there would be considerable interest in a bridge to ROS, so it would be very cool if you do share your results, whenever you feel ready…
In terms of I2CCommander, there will be an update to it with improvements regarding its asynchronous nature when receiving commands. Its in the works, but it could take months
That sounds interesting! A few of us are working on this little bot: https://rosmo.io/ that one day aspires to be ROS2/MicroROS compatible.
We have a volunteer who’s planning to do the MicroROS part on ESP32 and connect the driver board over I2C commander. His components should be arriving soon, so hopefully, he’ll make a start.