PID controller for motor speed control and distance control

I am building a robot rover comprised of dual DC motors each with hall sensors to obtain rotaional speed. I currently have a PID controller for each DC motor that is able to control the speed of the rover.. ie. I can provide a setpoint and the rover will move forward at a steady speed.

The next step is that I want to tel the Robot to move forward a certain distance. I'm thinking the approach here is to use a outer PID loop running at a much lower rate, taking a cumulative measuerment from the hall sensor to determin the distance traveled from the start point. The output would feed the inner PID loop for the motors.

Is this the right approach ?

My concern is that i've used the input from the hall sensors in two place, is one of these redundant for example ?

2 Answers

The approach is the right beginning. The term for it is dead reckoning. It has some problems regarding its precision. Next steps in increasing precision would be sensor adding optical flow or other sources for distance travelled some using sensor fusion technique.

You do not have a redundancy problem. If you use the same sensor signal and transform it into something else it will not be redundant. You would need to have redundancy later, to increase precision. E.g. you get another signal measuring position, now you have redundancy, and it is good to have redundancy in this case, because you can (probably) increase precision.

Given that you are using 2 dc motors, I'm guessing you are using a differential drive configuration. Your intuition about the algorithm is good. The encoders on the motors along with some physical/mechanical measurements (wheel radius/circumference and wheel base) are used as input to a kinematic model, in this case the unicycle model. Using this, you can maintain a running estimate of the robot's position and orientation. Using that, you can find the delta from a desired goal point (as a delta angle). You can then use this delta as input to a P-regulator whose set point is the angle to the goal and whose output is wheel velocities. I've implemented that algorithm this project; see the gotoPoint() method in the go-to-goal behavior. The documentation on the firmware internals contains a link to a presentation that describes the unicycle model and dead reckoning algorithm with illustrations.

Note that dead reckoning with only wheel encoders is useful for short distances, but other sensors will be necessary for accurate pose estimates for anything more.

• Thanks, this is great. Yet the intention is to use differential drive. Also have accelerometer, gyro and magnetometer and Lidar on the platform that hopefully can be use to give me something much more precise. Mar 6, 2021 at 9:37