# Loop time for self balancing robot

I have been working on a self balancing robot and there are quite a few parameters and one of them is loop execution time (t_loop henceforth). To my understanding, the smaller t_loop, the better it is for the control algorithm. But, since the motors also need to be given sufficient time to react, we cannot make it very small. Also, making t_loop large so that motors have sufficient time to react will make the system unstable. So there has to be some optimum value. I started with 5 milliseconds and started increasing it. At 5 ms the robot is quiet jerky (but it manages to balance). Between 10 and 20 ms, the vibrations become less. The question is how to find the optimum value of t_loop or control loop execution time.

• couple of typos: the word is quite Feb 17, 2019 at 18:24
• at what loop time does it fail if you keep increasing the loop time? Feb 17, 2019 at 18:26
• Between 40 - 50 ms Feb 17, 2019 at 19:36
• A quite nice resource on this can be found here: controlguru.com/… Feb 17, 2019 at 19:51

The answer is not a trivial one. Because,

1. the system dynamics depends on multiple sub-system dynamics (including software, sensors, and actuators (motors in this case))
2. finding the optimum value for t_loop, requires finding the best possible controller for all (i.e. several) t_loop values.

It's worth considering the following approach:

1. assume that the motors have the slowest dynamics (hence they are the bottle-neck for the problem)
2. the bandwidth of the motors will define the frequency at which they can be successfully commanded (you can utilize an open-loop test code, e.g. a code that runs sine waves for the motors in different frequencies, and the decide when the motors are not able to keep up with the commands)
3. the frequency that the motors can receive commands is the control frequency (fm). It is best practice to use a 10*fm frequency to control the motor in this case. ref: https://controlguru.com/sample-time-is-a-fundamental-design-and-tuning-specification/

Further than this, you will need to refer to modern-control literature for the following terms:

• system bandwidth,
• crossover frequency,
• nyquist theorem
• aliasing

But, I think a deeper dive into control theory is not necessary at this moment.

• This answer is not really spot on. Being $B$ the bandwidth of the motor at hand, the control loop needs to run at least at $f_s = 2 \cdot B$. In practice, we go much faster, having something like $f_s = 10 \cdot B$. See controlguru.com/…. In fact, DC motor do have a few Hertz bandwidth, whereas control loops run at > 100 Hz. Mar 9, 2021 at 17:51
• Thanks @UgoPattacini, I had meant to say "at least 2*B" from Nyquist theorem. I'll implement the link and the 10B suggestion. Thanks again for the contribution. Mar 11, 2021 at 18:49

A normal game engine at the desktop PC runs with around 40 frames per second. This is equal to 1000/40=25msec of waiting time after a tick. Fasten up the system brings no advantage but it will only increase the CPU consumption. Different from the framerate the motor control has to be executed. A motor needs some time to speed up and stop, especially in embedded systems. What is used in robotics operating systems like VXworks is a concept called realtime control. This means, that the operating systems provides threads. A thread is dropped from the main program and runs in the background until the task is done.

For example, the motor needs 1 second to stop. This means, the task in which the stop signal is send to the motor has a length of 1 second. The motor stop task is activated at timeframe 1000 and runs until the timeframe 1040 (1 second * 40 fps = 40 ticks). .During that time the main program doesn't stop but it runs also. The concept of threading is used at desktop PCs heavenly for creating GUI applications but it is useful for controlling robots as well.