Schemes for controlling multiple motors

Hello everyone.

This is my first post and I just have to say that I’m excited to be able to play around with this project, SimpleFOC is amazing!

I’m pretty new to the system but I’ve managed to set up a basic test on my bench. I bought some GB36-1 gimble motors and got some PCBs made of the SimpleFOC shield v3. I’ve been out of coding for a while but I’m getting the hang of it.

My goal is to have multiple motors running at the same time, say for a robot arm or something. I see that a microcontroller can run two motors at the same, and that more than that might be problematic due to the hardware not having enough timers to run the PWM for the drivers, if I understand correctly.

I’d be pretty happy with having one microcontroller per driver and another microcontroller acting as a coordinator/controller for the lot. What I am unsure of is what would be the best way to communicate between the coordinator and the driver controllers?

Would I be able to use SPI if there are spare SPI ports? What would I be able to get away with without upsetting the FOC instances?

I guess I am unsure of how much extra code I can put in, seems like the FOC code takes up a lot of the microcontrollers resources.

Hi @Charles , welcome to SimpleFOC!

That depends a lot on the microcontroller you use. For most 32bit MCUs the limit is not the number of timers but rather the number of pins (to connect all those drivers and sensors), the CPU power (to run the FOC algorithm fast enough) and the sensor interfacing (ability to read all the sensors without causing delays).

Yes, this is a good architecture, that keeps each driver simple and means the code of each one can be the same. But, as you’re aware it introduces the need for a communication protocol.

You have many options:

  • I2C
  • CAN
  • Serial Point to Point
  • Serial Bus (eg RS485)
  • Ethernet
  • WiFi
  • Bluetooth
  • ESP-Now and other proprietary protocols

In theory, yes, you could use SPI. But SPI was never designed for use over wires, and wires >20cm can start to cause problems and limit performance. So I doubt it’s a good choice as a driver interconnect protocol.

I2C is fairly simple to use, doesn’t need extra hardware (just a few pull-up resistors), and can (with some care) bridge distances of 1m or more over cables.

CAN is designed for industrial control applications, and very suitable to your purpose. But it’s complex on the software side and needs extra transceiver hardware.
Same applies to Ethernet.

WiFi or ESP-Now could be great solutions if you’re using Espressif MCUs, but of course latency of these connections can vary and reliability is perhaps lower than a cable connection. Also setup will be “fiddly”.

Serial connections are a great choice - they can be very fast, and very reliable, even over 1m or more. MIDI is a good example if you’re familiar with that.

RS485 - I’m not a fan - I think CAN is better. But IIRC Dynamixel Servos work with a RS485 bus, as an example.

Depending on the MCU it takes most of the resources. Even on fast MCUs with CPU power to spare it is a hard real time task with timing constraints under 1ms.
So this means you have to structure your code to do the communications asynchronously, without causing any blocking delays which disturb the motor commutation.

I’m in the process of designing an 8-motor board, controlled by a single MCU. It’s possible but the logistics and skillset might be a little out of most hobbyists. And the board won’t be too cheap either. So the good news yes it’s possible. As @runger said, it’s all about the number of pins and processing power.

I’m sure some of the higher-end MCUs can control more than 8 motors (I estimate realistically 12) but that design would be really expensive.

Cheers,
Valentine

Hi… I am planning to control two axes with two Arduino UNO R3, everyone with a simpleFOC board. So, one MCU per motor. I need to synchronize the two axes, and I am thinking of controlling them by a PC by serial connection. I plan to make a control code in Python in which there are the data (two precalculated vectors, one for every motor) to be sent to the two motors in a rapid sequence by serial protocol. To do that, in every Arduino, the void loop has to be able to receive the actual data (by serial) and to command the move at every cycle (continuously). I think, as for the speed, the PC will be able to do that. But will the Arduino UNOs R3 be the same?

TBH that will be difficult on any MCU. But on the R3 it seems unrealistic. On the R3 you should aim for loopFOC rate of around 1-2kHz, that would be good. And motion downsample the move() loop a bit to 500Hz or so.

But you won’t be able to process serial messages at 2kHz, and probably not even at 500Hz (although it depends a bit on how complex your protocol is - if it’s just individual bytes then maybe. But for ascii encoded floats like SimpleFOC uses, forget it).

A typical 115200 Serial speed on the Arduino translates into around 10-15 bytes per millisecond. But as I said, it’s doubtful you can process them so fast on a R3.

Why not look at the Nucleo 64 boards from ST Micro? They don’t really cost a lot and have about the same shape as an R3. A STM32G4 series MCU would manage more like 20kHz loopFOC speed, and has some nice hardware features for motor control.

Or a RPi Pico 2 - they’re very fast and have 2 cores so you could use one core for motor control and one core for communications?

I’ll reply in more detail when I get some time but thank you for the messages.

I have managed to get the FOC core running on an Arduino mega. I 3D printed a little test stand for the BLDC motor and used a magnetic sensor on the back. Works really well!

Another thing I’d like to do is get simpleFOC working with some stepper motors. Tonight I just brought up a board based on the TI DRV8711. It needs an SPI interface for configuration and I’ve currenty got that working quite nicely with a raspberry pi pico.

Yes, a Nucleo board can run two motors and two SPI sensors, but the connections to the driver will have to be made by wires - two shields will not work directly stacked onto the Nucleo board, i don’t think. – runger

Sorry if I repeat but I want to be sure… I mean two motors everyone coupled with a magnetic encoder as sensor for the control, sensors using SPI protocol as per the attached scheme. And do you know where can I find the wiring connection scheme between Nuckleo and simplefoc shield?

I tried the I2C between two Arduinos, and it works very well. I have configured one Arduino UNO as a master who generates a position to follow over time and another Arduino UNO as a slave with a SimpleFOC 2.04 board stacked on it; it drives an IPOWER GM110-8 with a CUI encoder very well. I am sure it will also work with an AS5048A magnetic encoder.
It works as I wanted… My first thought was serial communication because I had never thought of using I2C as a protocol between two MCUs. Now, for me, that is the solution. I guess this can work for two motors or more as well. Now I have also a Nucleo 64. In the future, I will try it. But for now, I found the way I was looking for.
So, thank you, runger, for listing the possibilities for controlling multiple motors with multiple MCUs.