We intend to buy SOLO-12 and implement recent high performance control strategies based on MPC - whole body control.
Therefore, I want to clarify some points regarding the capabilities of the hardware/software that I cannot fully understand from the documentation.
As far as we can understand, there are two communication alternatives for the motor control; the first is over the masterboard with ethernet and the
second is directly with the micro driver board over CAN bus. Is there any noticeable difference between the overall communication speed and any other capability. (For example if I choose CAN bus, will I still be able to integrate IMU over masterboard)
In your ICRA paper (Implementation of a Reactive Walking Controller for the New Open-Hardware Quadruped Solo-12) frequency of the whole body controller is stated as 500Hz. Is this value restricted by the high level planner or is there a limitation on the hardware or software side.
In other words, will I be able to go up to 1kHz while generating the desired torque input from the controller (Please note that I will not focus on the high level planner, our subject will be on the non-linear dynamics and walking/running algorithms)
I can understand so little about the details of the masterboard. Is it used solely as a communication interface between the control PC and the motors/sensors or are we able to do any computation on it regarding the control of the robot ?
With solo12, you have to use udriver V2 with SPI (so with the MasterBoard) the CAN implementation is yet to be done on udriver V2. Also with CAN, you can do 1khz control but the architecture implemented on the original TI dev board is point to point, so you would need 12 can interfaces on the PC side. In short, I advise you to go with the MasterBoard. Or to connect directly to the SPI with a solution of your choice. Without the MasterBoard, you will have to integrate the IMU yourself.
About the difference with the MasterBoard, you can do 1khz control loop, just be aware that the udriver are sampled by the masterbord at 1khz, and the PC samples asynchronously the master board at 1khz (or a bit more if you want). So you can have a latency varying from 0 to 1ms. In practice this is not important. Especially since all the differentiated quantity are computed in hardware and transmitted (joint velocity for example).
If you target extra low latency and higher control frequency, you might have a look at our ongoing project omodri Open Dynamic Robot Initiative · GitHub. If you are in a rush, keep in mind that this is still work in progress, and that some of the components are out of stock.
This can also be seen as a way to later make your solo evolve in the future.
The MasterBoard does allow performing some small computation, but keep in mind that this is a small embedded MCU, 200 MHz or so, dual-core, no Linux, but freeRTOS etc… And is already busy with the communication.
I want to add another thing that I wonder. As far as I can understand, you have implemented a direct current (torque) controller on micro driver board. You calculate the feedforward torque and the torque required for the impedance controller and send motor driver the sum of these two terms. In opposition to that, some of the recent motor drivers that are widely used in legged robots (like MIT mini cheetah) embedded impedance controller into the driver. Motor driver receives kp,kd gains and reference trajectory as an input in addition to the feedforward term in that case.
I wonder if it is possible the implement the latter approach in your driver as I expect a more robust behavior. And, is there a reason for you to chose the first approach in the first place ?
You are totally right, closing the impedance loop on the driver is a good idea as it can run at high frequency with minimum latency.
This is implemented and widely use in the ODRI project. We can send feedforward current as well as reference position, velocity and Kp, Kd gains at 1 kHz. You can have a look at the SPI protocol describing all the field here