What is the recommended way to implement CANbus communication for a robotics application with 8-10 VESC motor controllers on the bus?
Our CAN bus controller is a Linux based single board computer with a PiCAN 2 - CAN Interface board running Ubuntu and ROS.
I see that there is support for Libcanard / UAVCAN starting with firmware 3.45 but I am not sure how much of the protocol is implemented.
I also saw this implementation
https://github.com/vedderb/rise_sdvp/tree/master/Embedded/RC_Controller
but this is using a microcontroller for can bus communication
I am also aware of the VESC CAN_STATUS_1_2_3_4 status messages
Any suggestions and comments would be appreciated.
I strongly recommend using a microcontroller with a canbus peripheral and a UART peripheral to automatically forward can data over UART and UART data over canbus. Other methods like the mcp2515 will greatly load down the host controller with interrupts and uarts are very easy to interface to on the host Linux computer
Thanks for your feedback! This is an interesting point of view.
Isn't UART going to create the same kind of interrupts for the Linux controller, or maybe the data in and out is better buffered on the UART interface? Initially I thought that adding a middle man for communication would only complicate the system. I would appreciate your comments here.
If we are going to use a microcontroller, do you have a recommendation? I am thinking that using a STM32F4 microcontroller running ChibiOS may make the VESC integration easier.
I think that would be very beneficial for the project to create a standardized CAN interface with Linux based controllers used in robotics. CANOpen has been a standard for a long time but I see that VESC is going for Libcanard / UAVCAN. I think that this is an interesting discussion for the future of this project.
No, a UART won't have a lot of the same overheads as a can interface on an applications processor because they will generally have optimized, dedicated hardware for uarts, like character buffers, fifos, DMA set up by the well optimized drivers etc, whereas with an external can interface will have smaller buffers and be almost entirely interrupt driven.
You dont specifically have to use a UART though, it was just a recommendation, USB CDC/VCP, Ethernet etc, any other easy to impliment, highly optimized interface would be a fine choice
Any micro would do, but yes, the F4 line is fine. I am not sure how nessecary ChibiOS is for something like this, it depends.
Also, this wasn't intended to be a suggestion to go out and make such a device, I believe with some googling you will fine other people have already done this.
Thanks for your recommendations. I am looking for a solution that would be easy to interface with the VESC and easy to maintain as the VESC firmware evolves. That is why I was suggesting ChibiOS. I did some googling, there are a lot of CAN-UART interfacing solution out there. Some examples:
https://copperhilltech.com/can-bus-to-uart-converter/
https://linklayer.github.io/cantact/
https://canable.io/
I am not really sure what existing solution you were referring to.
The question is, which solution is easier to integrate with the VESC without digging into the VESC code and re-writing the protocol, reading and writing messages byte by byte. We can do that, but maybe there is an easier to maintain method.
I think a https://canable.io/ board running candlelight would make a decent starting point
Thanks for your suggestion! It looks like with the alternative candleLight firmware, the CANable enumerates as a native CAN interface on Linux. Does that mean that this is going be a CAN device in Linux? In this case are we going to have deal with the same number of interrupts over CAN? If that is that case then, what is the advantage of using CANable over PiCAN 2 - CAN Interface board?
Yes it enumerates as a native can device but that isn't where the interrupt problem happens, the interrupt problem is with devices like the mcp2515 and their driver, when they receive a packet they toggle an interrupt and the pi reads the data out from spi and then goes back to doing its thing.
With the candlelight firmware, the device and USB buffers are much bigger and data is polled off the USB interface, into the can interface, potentially multiple packets at a time, in a nonblocking manner.
It makes sense. Thanks for your input!