Here are more info to let you understand how things work on Niryo One:
– The problem with the CAN bus is that it’s a multi-master bus. So, the RPi will send commands to each motor, but also each motor will send some data (at a pre-defined frequency, and each node of the CAN bus has a unique ID). Thus, we can’t really control when exactly data is sent/received, and it’s possible that suddenly the CAN bus is saturated and thus will preempt the frames from lower priority nodes (the ones with bigger IDs).
– Second problem is that the MCP2515 we’re using has only 2 buffers for incoming messages. So the RPi will receive data from 3 motors (4 for V1), and the MCP2515 will have to handle all that with 2 buffers, which is quite limited compared to other components that can allow more than 6 buffers.
Conclusion: CAN is a great communication bus, but maybe not the best type of bus when working on a master/slave system (RPi master + motor slaves). Why we chose to use it ? Well because it was a much better solution than what we tried before (I2C or SPI daisy-chain), and still affordable to setup + not too complicated with the components that are available for us. (same reasoning for MCP2515)
Hope this gives you a better understanding. And as you can see, using or not using torque is not a variable is this problem, it’s mostly about the bus itself. That’s why I emphasized the physical connector quality, which is the only thing that you can play with to get better results. (and from the tests that we do here, we almost never have a problem with the CAN bus for new robots).