Is it a bad idea to use CAN-Bus to control robot wheels?

Question

I am working as a student on a 6 wheel robot project and have problems deciding what communication protocol to use for controlling the locomotion system.

The idea is to use a Master Controller in a local CAN-Bus to control the multiple motor controllers as slaves. The master controller would then be connected to a central CAN-Bus where multiple subsystems are also connected.

This would save a wiring mess, but I am worried about the reliability, since the system needs to do a lot of multitasking. I want to be sure that the robot can move, while doing other tasks.

Should I better use a SPI connection (or similar) from the OBC to the local CAN-Bus controller, or should I stick to plan?

The robot would be pretty big in size (over 1m) and it is not planned for the motor controllers to report back to the master, but this might be implemented later.

Answer 1

I think perhaps the better way to look at this would be "What are the potential pros/cons of using the CAN bus for this?"

A CAN bus is great for relatively long transmissions (meters) and can minimize wiring because the CAN wires are shared for all devices. It's possible to daisy chain these wires nicely.

It's a reliable bus, widely used in the automotive industry, and being a differential signal it's not terribly noise-vulnerable.

On the flip side, careful thought has to be given to the management of the CAN bus. It's possible for too many messages to clog the bus, and messages may not arrive in the right order. Feedback as to whether a message is received successfully may not be immediate and so on. The bus has a priority system, which determines when two nodes try to transmit which takes priority. So there is extra work to be done.

If your robot is going to speed at 60mph, then CAN might not be the right way to control the motors or if your protocol will use lots of messages this might be a bottle-neck. For low latency and faster updates you might be better using a dedicated link to each motor, or it might just be a bit easier. For something a bit slower, and perhaps it's ok if it takes a few ms to stop then CAN could be a great choice. I've used the CAN bus in applications with steppers, where the master says "step this way X times" and it's great for that sort of periodic update. It would work also with a "run at X speed until I say otherwise", but the limitation becomes how quickly you can get a new message to the motor if you need to.

SPI would not be on my list for this application, it's a bit too long of a distance, and it's a bit of a pain to have to run that many wires about the place. I would strongly consider some kind of Serial interface like an RS-422 suggested by DKNguyen. I assume part of the appeal of the CAN bus is also that the master needs only two pins, so you might be limited in this respect.

Answer 2

I would like to propose the following architecture:

^{simulate this circuit – Schematic created using CircuitLab}

Main Application Processor:

This is a grunty beast running all the Top-Level tasks like motion planning, cameras, WIFI, what-not.... It does not directly control the motors and does not get down in the "for move x i have to run motor[n] at y speed". This can run a OS without any hard real-time constraints.

Motion Co-Processor:

This processor handles the real-time movement planning and motor tasking. From information received by the application processor (e.g. turn vehicle left 15° within 2 seconds while going with a absolute velocity of 5m/s and do not violate 5m/s^2 in x/y) it derives the actual motor commands (e.g Motor1: Turn 5rpm, Motor3: turn 9 rpm... you get the idea). It can signal problems to the application controller, but handles all the real-time and safety stuff on its own.

Motor controllers:

Each motor has its own controller which handles the low-level motor controll (PWM generation, current monitoring, velocity control, torque control, whatever... ). It is connected to the Motion Co-Processor via a serial PtP link (i would suggest RS485, as low cost). I would use PtP over multidrop, as it avoids congestion in fault scenarios and is easier to manage from a real-time perspective. As you have to feed DC-supply for the motors to every motor anyways, you might as well add two small wires (RS_A, RS_B) as well.

NOTE: Your protocoll between the motion processor and the motor controller must implement some sort of interrupt signaling! (Hey motion processor, i just ran into a torque limit... therefore the requested move is not possible - please replan the motion for all the other motors.)