# Differential Drive Robot Control

Edited: I have a differential drive robot that needs to drive down a hall and stay in the center. I have 4 ultra sonic sensors, 2 on each side. Currently, I thought of implementing pure pursuit and having a lookahead distance etc. but I am not sure if this is the correct approach. I have all the lower level PIDs for motor control working, I just need some help in choosing a path planning algorithm? Will pure pursuit work to my needs? OR do people have any suggestions.

• can you elaborate more? What type of sensors you are using for controlling? Probably you need to have a look at how PID works: P depends on the present error, I on the accumulation of past errors, and D is a prediction of future errors, based on current rate of change Commented May 2, 2014 at 19:23
• I understand the fundamentals of PID... I just am unsure about how to go about the system... For sensors I have two ultrasonic sensors in each side of the robot facing the walls... Commented May 2, 2014 at 20:01
• You should start with only the proportional term and see how it goes. If it oscillates, add the derivative term to the controller. Integral term will be most useful for the error caused by asymmetry of motors/sensors. So you will almost certainly need it as well. Commented May 4, 2014 at 9:57
• I edited my question... and once again I understand the requirements for PID and how to tune it. That is not my question... Mine is on the higher level... more of a what is my error? Heading error? lateral error? etc. Commented May 12, 2014 at 0:22
• Is the goal of this robot to go down the hall as fast as possible or to minimize the time spent off of the center line? Do you assume that the hallway is perfectly straight and smooth, or do you expect to adjust your path based on the presence of doorways?
– Ian
Commented May 18, 2014 at 22:42

At the foundation of PID control, there is the assumption that the quantity you are measuring (and using to compute your error) has a direct linear relationship with the quantity you are controlling.

In practice, people frequently bend this rule without things going horribly wrong. In fact this resiliency to modeling error--when our assumptions (our "model") do not match exactly to the real system--is one of the reasons PID control is such a popular and commonly used technique.

In your case, what you are measuring is distances between your robot and the walls, and what you are controlling is the speed of your motors. So your question really boils down to "How can we describe a (hopefully) linear relationship between these quantities?"

First off, we have to deal with the fact that we have at least six different numbers floating around (four sensor measurements and at least two motor speeds), when we'd really like to have just one, to make a simple SISO (Single Input Single Output) PID controller.

For the motors, one way we can accomplish that is by choosing to use the difference between the motor speeds as our control quantity. We will have to control overall speed separately, but it makes steering a lot easier this way.

$\omega = R_\text{wheel speed}-L_\text{wheel speed}$

Next, for combining the range sensor inputs we have a number of different options to choose from. Which one is best for a given situation will depend a lot on the geometry of the robot and where the sensors are pointing. For now, let's just assume we can boil it down to a DISTANCE_LEFT and DISTANCE_RIGHT that tells us how far away the walls are on either side. We can then take the difference and use that as our "error" measurement. Minimizing this error makes the distance to either wall equal and keeps us centered in the hall. So far, so good.

error = RIGHT_DISTANCE - LEFT_DISTANCE

Now for the part where we bend the rules. When we chose to use the difference between left and right motor speeds as our control variable, what we were in effect doing is controlling the angular rate of our robot. The relationship between angular rate and us being centered in the hallway goes something like this:

angular rate --> {integration over time} --> robot heading angle --> {cosine of heading angle * forward movement speed} --> movement speed toward or away from the hallway center --> {integration over time} --> robot position in the hallway

Yikes! That does not look linear. What do we do? Well, we can do what all good engineers do when faced with a complex math problem. We approximate. ;)

For example, if the robot is facing in roughly the direction down the hall that we would like it to go, we can make the claim that our robot's heading (for small heading angles) is (approximately) linearly proportional to it's movement speed toward or away from the hallway center. Now we have:

angular rate --> {integration over time} --> robot heading angle --> {approx. linear} --> movement speed toward or away from the hallway center --> {integration over time} --> robot position in the hallway

Better, but we're not there yet. We still have those integration operations to deal with. This is where it gets complicated. I'll see about filling out this answer more later, but for now I'll say that the reason this PID controller (might) still work has to do with (a.) the integral and derivative terms in the controller and (b.) interaction between the controller and the dynamic equations governing the motion of the robot itself.

• I really liked your post. It was clear and gave good insight into the relationship between PID input and output. Thank you a lot for your post. :) Commented Jul 29, 2014 at 19:29
• Yeah, except its hugely overkill. Bringing motor speed into it serves no purpose other than confuse the reader. No where in the question do I even see the mention of motor encoders for rotational velocity, other than to say it is already working, someway. Just goes to show, pretty pictures is what sells on robotics stack exchange, not answers. This posted 2 months after the correct explanation was given. Commented Aug 21, 2014 at 18:11

error = distance to left - distance to right, goal (set point) is 0.

• I would suggest elaborating a bit more. One-liners are not very beneficial since they are often very unclear. Commented May 22, 2014 at 15:09
• It was specifically responding to the comment "I understand the requirements for PID and how to tune it. That is not my question... Mine is on the higher level... more of a what is my error? Heading error? lateral error? etc" Hope that helps. Commented May 23, 2014 at 12:13
• Questions and answers will be read by many people, not just the original asker. By providing fully fledged answers with context, stackexchange sites become a resource for others with similar questions in the future.
– Sean
Commented Jul 14, 2014 at 20:47
• I could draw pretty flowers too, if that will help. Commented Jul 15, 2014 at 8:50