Is it wise / possible to use multithreading to handle control system on robot? For example, a line follower robot with PID control flowchart would be:

The control system will be much like this :

void calculate_control(){
last_error = error
error = reference - sensorval

//calculation
out_control = k1*error + k2*last_error + k3*last_out_control
last_out_control = out_control
//.. ...
//.. ..
}


What if the sensor I'd be using has high reading delay (example : image processing based). Should it follow the same flowchart or should I use multithreading so that while the sensor value is not updated, control system keeps running with updated value (because last_out_control will keeps changing).

ps: changing the procedure for calculating control value is not possible. I'm just looking for input and suggestion to optimally integrates the system.

• it seems that you are describing non-blocking code Dec 4 '19 at 6:01
• Yes it is. 3 procedures mentioned aboves can be made into non-blocking. But I'm not sure if it will optimize the whole system or make it worse.
– dpw
Dec 4 '19 at 6:07
• sorry, i should have been clearer ... you are describing a single non-blocking thread, not multiple threads Dec 7 '19 at 1:28

Multithreading doesn't help a simple robot much. For example, if you have just a couple of sensors for line following, multithreading isn't necessary.

However, as the robot becomes more complex both electronically and in programming, multithreading makes sencpse.

Add more sensors to your line-follower, perhaps a lidar for distance measurements, audio for speech recognition for accepting new commands, and vision for object recognition. In this case multithreading really helps. Unlike a few quick sensor readings, the speech recognition takes more time and attention. A command, perhaps "Robot, stop," takes maybe a second to say. In a single-threaded robot everything else would have to stop while this command was parsed.

With multithreading, on thread could be used to listening, and the main thread might only be notified when the command was heard.

Yes, there is more overhead in a multithreaded program, but it can handle more complex cases more easily.

I would suggest that you use a framework to handle multithreading. That way most of the difficult part of multithreading will have already been done.

For a simple PID control you don't need parallel threads, as a control rate of 50 to 100 Hz should be enough.

• If the PID controller works in a physics simulation, there are two threads who are running in parallel: the simulation and the robot controller. A faster game loop won't overcome the problem, that realtime systems are working on different layers at the same time. Dec 5 '19 at 9:20
• The control system I've described above is not a PID controller, rather than putting dozens code lines of actual control system, I simplified it.
– dpw
Dec 5 '19 at 10:39
• @ManuelRodriguez so you're saying that its okay to use multithread on my system? what should the control system do while sensor is not yet updated? Is it keep feeds data to actuator or what?
– dpw
Dec 5 '19 at 10:41
• @dpw you mean your sensor is running at lower rate than the control loop? Please confirm whether it is a real system or you are running some simulations e.g ROS/Gazeba? Dec 6 '19 at 11:06
• @dpw "Should I run the control system only after sensor is triggered?" Yes. The whole point of any feedback control law is that you have the feedback from sensor. If your Controller is running faster than the Sensor that means it simply does not have the feedback available to it during some of the discrete time samples. So either make your controller run lower than sensor rate or increase your sensor rate. Dec 9 '19 at 6:46