Robot Motors Jitter or Lag: Real-Time Motor Control and CAN Bus That Keep Up
Robots that stutter, overshoot or react late usually have a timing problem, not a mechanical one. How I fix real-time control.
The problem clients bring: "Our robot moves jerkily, sometimes overshoots, and gets worse when the camera or navigation runs."
What is really going wrong
- Control loops run at irregular intervals because they share a processor with heavy tasks.
- Motor commands travel through a slow or overloaded bus.
- Encoder readings are delayed or missed.
- Vision and control are tightly coupled, so one stalls the other.
How I solve it
- Split the design: hard real-time control on a microcontroller, vision and planning on a Linux processor.
- Run control loops from hardware timers at a fixed rate.
- Use CAN or CAN FD with a defined message schedule between nodes.
- Bridge the real-time side into ROS 2 for navigation and tools.
- Measure loop timing and bus load under worst-case conditions.
What the client gets
Smooth, predictable motion that stays stable when the rest of the robot is busy, on an architecture that scales to more motors and sensors.