What’s the maximum control loop frequency for the Motoron python library (GitHub - pololu/motoron-rpi: Motoron Motor Controller Python library for Raspberry Pi) running on an RPI 3/4?
Hello.
I am not sure I understand what you are asking. Neither the Motoron, nor any of the examples from our Python library, implement a control loop (which implies you are implementing some kind of closed-loop position or velocity feedback that the Motorons do not have any built-in support for processing).
There are several example programs from our library with loops, but the frequency that your Raspberry Pi gets through those will probably depend on several factors of your setup like which specific example you are running, what Raspberry Pi you are using, and what else your Raspberry Pi is doing in the background.
- Patrick
Hi Patrick,
Thanks for the response. Let me rephrase my question - what’s the latency for the call to set the motor speed? I’m trying to target > 1 kHz control loop frequency for my application.
Thanks,
Will
Are you using a Motoron designed for I2C or serial communication?
- Patrick
I will use it with I2C, but would be interested in both.
Hello, Will.
The Motoron internal loop could take up to about 650 µs to process a command (the typical time is more like 200 µs). If the processing finishes right after a PWM period has started, that could add another period before the command takes effect, so that would be 700 µs worst case at 20 kHz PWM. The time it takes to send a “Set speed” command on an A-Star 32U4 using the Arduino Wire library at 400 kHz is about 180 µs, so we are looking at about 880 µs (but typically more like 450 µs). Of course this doesn’t count any extra latency introduced by your Raspberry Pi.
For the serial versions, the internal 700 µs part is the same. The Motoron supports baud rates up to 250000 bps. (Baud rates up to 1 Mbps are possible, but could lead to problems. See the “Serial interface” section of the Motoron user’s guide for more information.) For 250000 baud, sending the “Set speed” command should take 160 µs if you use the compact protocol, or 240 µs if you use the Pololu protocol. So we are looking at 860 µs to 940 µs for the serial Motorons (but typically more like 410 µs to 490 µs).
The numbers above assume you have disabled CRC for commands, so you do not have to send a CRC byte. Also, you should not enable acceleration or deceleration limits, since that would add about 10 ms to the latency.
Here are some oscilloscope traces showing what happens in a test where we sent rapid “Set speed” commands to a Motoron M2T256 using I2C. We used an I2C frequency of 400 kHz and varied the delay between commands. The commands alternate between setting the speed of motor 1 to 100% (800) and setting it to 0%. Starting at the top, the signals shown in this trace are:
- Yellow: This is a debugging signal from the A-Star 32U4 controller that drives high after it has finished sending a 100% command and drives low after it has finished sending a 0% command.
- Green: This is the Motoron’s M1A line. Each rising or falling edge on this signal corresponds to an edge of the same type on the yellow signal. The time difference between these corresponding edges represents how long the Motoron needed to fully process the command and make it take effect.
- Orange: This is the SCL signal generated by the controller, which shows when data is being sent over I2C.
When we sent commands at 2 kHz (every 500 µs), the Motoron had enough time to fully process every command:
When we sent commands at 5 kHz (every 200 µs), a command would often arrive fast enough to override the previous one before it could take effect:
I’ve drawn red lines on this last image so you can see the correspondence between the last data byte of a command (orange) and the edge on the Motoron’s output where that command later took effect (green).
Please let me know if you have additional questions.
–David