# How to handle motor stall zones in differential drive point-forward go to goal algorithm?

I am implementing the Go To Goal algorithm for a differential drive robot as described here and in this video. The issue I have is that there is a large dead zone in pwm values where the motors are stalled. I have calibration data for each motor that measures the stall pwm and the minimum speed that the motor can turn just above stall. I also have calibration data for the maximum speed. I'm using optical encoders to measure the rotational speed of the wheels. So my issue is that the point-forward algorithm controls both linear velocity and angular velocity and it is calculating wheel speeds that cannot be achieved by the robot; they are in the stall zone. How does one handle that issue? It seems like just upping velocities by the minimum velocity does not work because then the turning angle is too shallow to reach the goal.

For a similar problem (TT motors can't start the bot rolling on a carpet) I have been toying with the idea of setting up PID control for the angular velocity. If it stays stuck, the integral term will start upping the power. Once it suddenly breaks loose, the differential term will throttle it back. That's the idea, anyway -- someday I'll actually try it. Tuning might be a challenge, especially since the minuscule bit of control theory I have is quite rusty by now.

• I do have a closed loop speed control with feed-forward; the issue is that that point-forward algorithm is requesting speeds in the stall zone, so the robot gets stuck. However, if I enforce a minimum speed, then the turn-radius is altered and the goal is not achieved. Commented Jan 24, 2021 at 21:24

I know it is an old post, but you never know. Anyway, did you find any solution to overcome this issue?

My idea is that maybe a mapping can be done between the values i get and values that overcome the threshold value of PWM that moves the robot. Something like a linear interpolation, maybe. Otherwise, my guess is that pid gains of the control maybe could be adjusted in such way that they produce pwm correction which again is translated to PWM values that make the robot move.

Hope it helps.

In any case, please share if (and how) you managed to overcome this problem in a better way.