In this post I will introduce to you the basics of PID control, and why it comes in handy for robotic applications. You don’t need much of background to read this, but knowing the basics of motors is always a good idea: my previous posts on this subject are listed here: Welcome to the jungle. Now it’s time for serious business.

You already theoretically know how to change the spinning speed and direction of a DC brushed motor — if not, you just have to read a few posts (see above) to get quickly updated.

Yet, you may find out that some improvement is needed if you want to give your motors — your robots — some robotic behaviors.

Robotic behaviors… what are they? Basically, it can be the fact of being autonomous: no remote control. Also, it’s how a robot react with its direct environment.

Let’s take an example: you managed to design and produce this nice rover of yours, you casually build a rocket to put it inside, then successfully leave Earth atmosphere and get your rover safely to the ground of Venus in no time. That’s quite a good job, really. But at this point your rover is only good to be radio-controlled from your comfy sofa on Earth, so allow me to wish you great skills of patience — and a whole set of cutting-edge technology. Yes, now that you think about it, you’d rather have made an autonomous rover. In this example, being autonomous for the rover is living its own life while exploring the wonders of Venus. What I call environment is, for example, the load at the end of the rover’s robotic arm that will apply a force to its joint — hence a torque; it’s also the rock under its 7th wheel, or the slope of the steep mountain it’s trying to climb to see the view that will reduce its programmed speed, etc. Your rover must get along with these factors and continue being a rover in spite of the fact that they all kindly but firmly work together in order to try to prevent it from doing whatever you programmed it to do on its brand-new planet. Life is hard on Venus.

How to be autonomous and get along with environment?

Getting autonomous (for a robot, that is) basically involves you writing a kick-ass programming code that will cover all the single actions you want your robot to do, but also all the possibilities of bad turn of events that could happen in its life. This code could as well include some deep-learning functions so that your robot has its own evolving intelligence. The goal being that it can act accordingly with what it is supposed to do, along with its external environment.

If I summarized, you need to give a purpose to your robot, and put a brain inside it so that it can manage to fulfill it.

But let’s not forget I’m discussing the subject of DC brushed motors in robotics, not every parts and every aspects of a robot. So I must narrow the subject to this question:

How to get a motor being autonomous?

We can now talk about control loop feedback system.

Note: Here I use the same word — control — that in the post How to stop being controlled by your DC motor: reverse the roles! (part 1: direction and part 2: speed). This is a generic word, and the control I’m talking about today is actually closer than engineering control, which is more complex than giving a simple speed order to a motor.

Let’s first define the system as:

An actuator (for example a motor) and its control board (e.g. this board)

A sensor (speed, torque, position, etc.)

A micro-controller board

All of them must be supplied with proper electric energy. As a user, you want the actuator to reach a value, that is called a set-point.

A control loop feedback system is a system that runs in a close loop, with a set-point to reach. The command given to the actuator to reach the set-point depends on the feedback. This feedback consists in the actuator’s value measured by the sensor and compared to the set-point value. The resulting error is computed and re-injected into the initial order as a command that automatically corrects and adjusts the value of the actuator, in order to reach the set-point.

Applied to the motor-sensor-system I defined above, it follows a simple recipe (please note it’s highly simplified for now):

An initial order is given to the motor (for example: please spin at 10 rad/s).

The sensor retrieves the status of the motor (the motor is spinning at 8 rad/s).

The error is calculated (10 minus 8 equals 2).

The error is re-injected and computed into the initial order (Please go 2 rad/s faster, if it’s not too much to ask you).

And so on.

This illustration will help you understand: