0
\$\begingroup\$

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.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ In this system, is it just control of the wheels from a master to many slaves, or are there other devices on the CAN bus? Will the wheel controllers need to report back to the Master? Be sure to edit your question to include this. \$\endgroup\$
    – LordTeddy
    Dec 6, 2023 at 19:36
  • 2
    \$\begingroup\$ Can you write more on what you mean by reliability? Properly implemented CAN is a very reliable communication scheme that is used in many safety critical systems in many industries. CAN is also intended to connect devices that are distributed throughout a vehicle/machine. SPI is meant for devices that are on the same PCB. Is your worry that the main controller will spend too much time managing the six wheel controllers to perform its other tasks? If so that will be a risk regardless of the communication scheme. \$\endgroup\$ Dec 6, 2023 at 19:44
  • \$\begingroup\$ What size is this robot? how far are the wheels from the controller? \$\endgroup\$
    – LordTeddy
    Dec 6, 2023 at 20:00
  • \$\begingroup\$ What you do depends on your robot's requirements. How nimble does your robot's locomotion need to be? Regardless, I would not use SPI for such a dedicated connection. SPI is not well suited for off-board communications or noise immunity. I would use a dedicated RS-422 if I wanted a dedicated connection to the motor drivers. You could still use a CAN bus for the motor drivers for something that requires responsieness if you give motor controller messages sufficiently high priority. 6-wheel rover? Probably not the most nimble thing in the world like a quadcopter's control, or even a Segway. \$\endgroup\$
    – DKNguyen
    Dec 6, 2023 at 20:15
  • \$\begingroup\$ Make a real-time specification of how fast everything needs to react then take it from there. CAN is almost certainly to prefer over SPI in terms of EMC, if you have a lot of DC motors etc in the system. \$\endgroup\$
    – Lundin
    Dec 7, 2023 at 14:49

2 Answers 2

1
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ Thank you for the helpful response! Do you think that adding different "layers" in the CAN-Bus topology would help the data transmission reliablility of the system? \$\endgroup\$ Dec 6, 2023 at 22:02
  • \$\begingroup\$ Could you be a bit more specific what you mean by layers? \$\endgroup\$
    – LordTeddy
    Dec 6, 2023 at 22:20
  • \$\begingroup\$ For example using a micro-controller to connect to multiple CAN-Buses. In one network, the controller would act as a slave, and in the second one as master. \$\endgroup\$ Dec 7, 2023 at 10:18
  • \$\begingroup\$ Yes, having multiple CAN buses is a way to solve some problems, as it effectively doubles your bandwidth. It's one way of making sure one set of messages doesn't interfere with another. \$\endgroup\$
    – LordTeddy
    Dec 7, 2023 at 11:07
  • \$\begingroup\$ It doesn't make sense to label something as "too slow" out of any context. Without a real-time specification of how fast the motors need to react, there's no telling what will work or not. \$\endgroup\$
    – Lundin
    Dec 7, 2023 at 14:54
0
\$\begingroup\$

I would like to propose the following architecture:

schematic

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.)

\$\endgroup\$
4
  • \$\begingroup\$ How exactly is RS485 low cost compared to CAN? There's almost no difference, except that RS485 has a much crappier data link layer protocol and forces you to implement CRC manually. \$\endgroup\$
    – Lundin
    Dec 7, 2023 at 14:51
  • \$\begingroup\$ @Lundin Transreceivers are availabe for a smaller dollar (the low feature set ones) and you are not required to use a MCU with CAN controller or an external CAN controller. Implementing CRC manually is 30seconds ChatGPT these days.... \$\endgroup\$ Dec 7, 2023 at 18:42
  • \$\begingroup\$ Standard CAN transceivers (the SO8 flavour) cost the same. MCUs with CAN controllers do not anything cost extra. ChatGPT is a lie generator. \$\endgroup\$
    – Lundin
    Dec 8, 2023 at 7:42
  • \$\begingroup\$ @Lundin If have no data on that, but considering a CAN controller to be a more special peripheral than an UART, i would say that in an low real estate scenario, going for a CAN enabld MCU will cost you extra when compared to an MCU with a single UART. \$\endgroup\$ Dec 8, 2023 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.