# How to control the velocity of a mobile robot?

I have a differential drive robot whose linear velocity and angular velocity is to be controlled. The current strategy for doing that is:

1. A high level path tracking module spits out the reference velocities (linear and angular)

2. Using the kinematic equations of the differential drive robot, the rpm of each wheel is calculated.

3. A PID controller is run for each motor which achieves the desired RPM for that motor.

Is this a good strategy for controlling the linear and angular velocity?

It seems like an open loop controller because two separate PIDs are just maintaining the RPMs of individual motors. But the linear and angular velocities seem uncontrolled.

If I want to model a plant whose states are linear velocity and angular velocity, I don't know how to find the dynamics equation for the states (linear acceleration and angular acceleration)

Even if I refer to the data sheet of the motors and get the dynamics right would it make sense to implement such a controller?

What would be the best way to go about this problem of controlling linear and angular velocity of a mobile robot?

The main problem controlling the wheels speed after the kinematics conversion is that you are only controlling the response of the wheels to the setpoint, not the linear velocity response and the angular velocity response. See diagram below. This way, you will normally have 2 similar PIDs calibrated with the same parameters for controlling the wheels.

Another approach is to have 2 different PIDs for controlling the Linear Velocity (V_comm) and the Angular Velocity (W_comm) commanded from the High-level Path Tracking. Using this, you can calibrate differently the response for the linear and the angular velocities.

To make this work properly, you will need also a Forward Kinematics module to estimate the actual linear velocity and angular velocity from your encoders measurements, and then use this estimation to calculate the error in your 2 PIDs. See diagram below. With this approach, after calculating the Setpoint for the linear velocity (V_set) and angular velocity (W_set), you can then calculate the speed for every wheel (RPM_set_wheel_1 & RPM_set_wheel_2) with already-known inverse kinematics equations.

Here (Slide 5) you can find the equations for the direct kinematics differential drive.

• Sorry for the first post. I hope it is better explained now. Oct 8, 2019 at 11:37
• Not at all, we always appreciate a new expert joining us, and your revised answer provides some fascinating insights. We look forward to your future contributions to our community. Oct 9, 2019 at 9:57

The strategy you outlined is up to the task only if the high-level path planning will be undertaking every once in a while the required corrections to compensate for the unavoidable mismatches between the commanded velocities delivered to the system and the actual feedback that might be represented as current locations along a designed path within the map.

On the other hand, your goal of coming up with a complete state-space model of the differential drive system would be fruitful only if you can get measurements of the linear and angular velocities independently from the wheels kinematics, as for example by relying on an inertial unit and/or visual odometry. If you can only elaborate wheels feedback, then you are good to go with your policy.

• Thank you for your answer. I understood the first part. But I didn't understand why I cannot use the wheels feedback? And why I should use the feedback from other sensors? Sep 29, 2019 at 18:04
• You can certainly use the wheels signals to implement the PID control at stage 3 of your recipe and also to make the online corrections I mentioned, but measurements collected without resorting to the differential kinematics (e.g. with an IMU) convey the right amount of information to do full state feedback much more effectively. Sep 29, 2019 at 19:11

In general, there are two options available. The first one is called model predictive control which means to simulate future states of the system and search in the game tree for a pleasant node. The second strategy is “direct control”, which can be realized as a pid controller. The idea is to implement if-then-statements without predicting the future.

To figure out which strategy is preferred the overall human-machine-interaction has to be investigated. The first step is, not to program a control loop but to create an event recorder who saves the human actions into a queue. New sensor/action measurements are replacing older ones, similar to a black box in a truck. In the second step, the recorded game log gets analyzed and then a decision is made which kind of control strategy will work.

The idea in the original post with a high level path tracking module make sense. The concept can be explored further into a qualitative simulation. That is a symbolic description of the system which leaves out the details. Sometimes it can help to handle complex differential equations more easily. Creating a qualitative simulation is similar to program a computer game for a low end computer like the Commodore 64. That means, the simulation is not working accurate, but it's a simplified description of the problem.