Closed loop PID control of a DC motor

What a PID controller should look like after proper tuning

What a PID controller should look like after proper tuning

After getting the DC motor to work nicely with my PS3 joystick, I continued by building in a control system using the PID algorithm. A feedback based control system is very important for advanced robotics, as it makes sure that what your software thinks is happening, actually does happen. A closed-loop feedback process works by taking in a sensor input and using it to adjust the output. In the case of my rather simple DC motor, an encoder generates ticks that are used to find the RPM of the motor, which is the original command.


Briefly, here’s what the PID controller does, mathematically. The Wikipedia article above does a great job explaining the core components, so here is a translation of that main equation into practical pseudo code.

u(t) = K_{p}e_{n} + K_{i}\int e_n + K_{d}\frac{de_{n}}{dt}

K_{p} = Proportional scale factor
e_{n} = input error (setpoint – input)
K_{i} = Integral scale factor
\int e_n = cumulative error (sum += error)
K_{d} = Derivative scale factor
de_{n} = change in error since last calculation
dt = change in time since last calculation

I turned this math into a C++ node for ROS that takes an RPM input and spins the motor to that correct speed. In the previous open loop behaviour, one node takes joystick input and outputs directly to the Arduino for control. After working on the next phase, I realized that would work better in more generic nodes, which is the more “ROS way” of doing it. So instead I have one node that takes the joystick input and outputs a left/right number scaled to some limit (in this case the maximum 58 RPM of the motors). A second node reads that RPM node output and uses a PID controller to generate motor output commands. This configuration makes it much easier to test because I can use standard ROS message publishing to set a target speed.

Here I’ll show and explain the different C++ code used to build the required nodes.

Generating RPM values

First is a node called motor_RPM_node that takes encoder ticks from the Arduino and publishes the current RPM speed.

This is a relatively simple node that subscribes to /arduino/encoder and publishes on /motors/rpm. You can see that it allows you to set the number of encoder ticks per revolutions with a launch parameter. The core method is the encoder callback, which builds the time since the last tick then uses the ticks per revolution value to generate the RPM and publish in left/right configuration using a custom YardBot message.

Since the joystick teleoperation node is pretty common, I’ll leave that out. Basically depending on joystick position, there is a stream of left/right messages published to /cmd_num with the desired RPM of each motor.

A PID class

Before explaining the main component, we need a PID class to handle generating valid output. This is an excellent time to use object oriented programming practices and build a PID class that can be reused.

Much of the overall process and procedure was pulled from the excellent PID library for Arduino by Brett Beauregard. There are many convenience methods for retrieving data about the controller and it shows the input data contributing to the error. Once created as an object, the main controller simply needs to mark a setpoint, set the actual input and receive the processed output.

The main controller

Finally comes the main controller node. It subscribes to the encoder RPM topic and RPM setpoint topic and publishes to the Arduino motor. This is a pretty standard ROS paradigm: take input, process and generate output.

Once again there is a definition of the class, along with the different ROS callbacks. There is a subscriber for the RPM input and encoder RPM data, plus a service for setting the tuning parameters. I use a launch file to set the different nodes and parameters, but while testing it becomes cumbersome to constantly restart the launch file to use the updated values. By having a service server, I can set the motor to 0 and update the tunings on the fly, then mark them in the launch file.

As before the initialization methods create the callback objects and receive the launch parameters. The tuning callback sets the PID controller values. The encoder callback sets the PID input values and the RPM callback sets the PID target.

The main processing happens inside a timer callback function that is run every 0.2 seconds. This timing requires taking different factors into consideration: processing speed of your computer, output response requirement and the capabilities of your output (DC motor in this case). My particular number may change as I learn more about the overall system.

Inside the timer callback, the PID controllers generate the next output. For the special zero case, the motors are also turned off. The node tracks the output values and only publishes if the desired speed changes. This is to reduce the number of messages being sent to the Arduino. The PID controller outputs in RPM values but the motor controller itself requires an integer between -127 and 127 so there’s an extra step where the RPM value is mapped to the motor controller parameter.

Tuning the controller

So now that the controller is set up, the most time consuming aspect of building the control system is tuning it to safe and efficient levels. To do this, you need to be able to interpret response characteristics as tuning parameter changes. Admittedly I’m still working on that part, but there’s enough info on the internet that I was able to see progress. In order to see how the controller was behaviour, I opened ROS on my desktop and used rqt_plot to display the desired RPM value against the actual RPM output. That’s what I used for the nice graph at the top.

PID with large overshoot

First is output with a large overshoot. I increased Ki a little more.

PID with i decreasing

Here Kp is too low, as the output doesn’t overshoot the target of 40 RPM. This also gives a good example of what control systems are supposed to do: eliminate error. Given enough time, this system would still reach the target.

PID continuous

With this graph, I changed the target multiple times. You can see the response becomes much smoother as time goes on. Ideally all responses would be smooth like that, so I’ll continue to look into those improvements.

PID follow joystick

Finally I hooked my joystick node back in and used it to move the motor around. Here you can clearly see how the output follows the target. There are a few uneven spots where I can continue to optimize but it’s very clear that the basic behaviour is there. The next phase of improving the controller is to add some safety features that will monitor the output so that it behaves correctly in all scenarios.

Posted in Software Tagged with: , ,
2 comments on “Closed loop PID control of a DC motor
  1. sunnywinter says:

    When I use rosserial subscribe or publish a topic,belong the node serial_node.How can I publish to arduino motors? or I use CMAKE to make a file using cpp code? And can i see you full arduino code?

    • Wes says:

      You’ll need to write code for the Arduino to subscribe to the published motor commands. Is that something you’ve done yet? Basically you publish messages like left = 128, right = 100 and interpret that with the Arduino.

Leave a Reply

Your email address will not be published. Required fields are marked *