How-To: Tune ROCKO Velocity & Position PIDs

How-To: Tune ROCKO Velocity & Position PIDs

Part 1 - Introduction To PIDs

PID is a type of ‘feedback’ control, that takes in a target value (in our case an angle or velocity) and outputs a signal that drives a machine (in our case the motor driving the wheel). PID stands for proportional, integral, and derivative, which are the three components in each PID.

image-20250513-172050.png
Image from Wikimedia Commons

For each of the three components of a PID (proportional, integral, and derivative), there are three gain values that can be tweaked:

Proportional Gain:

This gain value is multiplied by the difference between the current value and the target value. A proportional gain is usually the first component to be implemented.

PID_PGraphIllustration.png
In this case, the proportional gain would be multiplied by the difference between the current angle (~-10 degrees) and the target angle (0 degrees).

A higher gain results in a stronger response to the current error. Too high a gain​ can lead to oscillations or instability, while too low a value can result in a slow response.

Integral Gain:

The integral term is multiplied by the accumulation of errors.

PID_IGraphIllustration.png
In this case the integral gain would be multiplied by the area under the curve (approximately -1.75)

A higher gain value usually helps reduce steady-state error, but can lead to instability if set too high.

As opposed to the P and D components of a PID, the I component is cumulative, which means that even readings taken 50 seconds ago impact the controller.
Additionally, it is possible for I components to grow to very large values before they can balance out. For this reason, it is usually recommended to ‘Cap’ the I component in some way, so it doesn’t get too large.

Normally the integral term is used to eliminate steady-state error, but as will be shown later, this is not the case for all the I-terms we use.

Look further down in the FAQ for an explanation of this.

Derivative Gain:

The derivative is multiplied by the current rate of change (or derivative) in the target value.

The derivative gain is multiplied by the measured value’s rate of change (or derivative). It helps dampen oscillations by counteracting rapid changes.

PID_DGraphIllustration.png
In this case the derivative gain would be multiplied by the rate of change of the angle over time (~83 degrees/second)

Increasing the gain enhances damping and reduces overshoot, but too high a value can lead to instability or sensitivity to noise.

Usually the derivative gain is a stabilizing value (e.g. a higher derivative gain reduces the violence and number of oscillations), but if there is substantial noise in the measured value or substantial delay in the system (possibly from high computation time), higher derivative gains can lead to instability.

For more general information on PID’s, you can read more at:

https://dewesoft.com/blog/what-is-pid-controller

Part 2 - Pitch PID

The pitch PID is primarily concerned with keeping the center of mass at the target angle. Ideally an angle of zero degrees means the center of mass sits directly above the center of the wheel, meaning the robot is balanced (represented by the black line below). When the robot begins falling to either side, it will have a non-zero angle(represented by the purple line below).

The input to the pitch PID is an angle read from the IMU/gyro, and the output is a motor speed in rad/s.

The pitch PID the following components:

Proportional Gain:

This gain is multiplied by the angle of the robot with respect to the horizontal. A higher value will allow the robot to recover from being tipped over

Derivative Gain:

This gain is multiplied by the change in angle (rotational speed) of the robot. A higher derivative gain should reduce the number and magnitude of oscillations

Integral Gain:

This gain is multiplied by error over time of the angle. This gain is recommended to be zero, since the integral gain is usually used to reduce steady state error, but in this case it can actually harm the controller. More information about this effect is listed in the FAQ.

PitchController_Diagram.png
The Pitch PID takes the distance between the current angle (purple) with respect to the vertical 0 angle (black) as an input

Part 3 - Velocity PID

The velocity PID is primarily concerned with keeping the robot at the target velocity, and keeping the robot in position near it’s starting location.

The input to the velocity PID is the speed of the wheels in m/s and the output of the velocity controller is an angle that is fed into the pitch controller. This means the two controllers are coupled, with the velocity controller feeding into the pitch controller.

An example of this coupling process (and example calculations) are listed in section 5.

Technically the speed of the wheels is calculated and measured by the motor’s built in encoder values, since the wheel speed cannot be measured directly by the robot.

More information about how this conversion is available in the ‘How-To: Simulate ROCKO’

Proportional Gain:

This gain is multiplied by the speed of the robot’s wheels in m/s, subtracted by the robot’s target velocity. A higher value will cause the robot to oscillate more, but it will also push the motor to get the wheel back under the robot at higher speeds.

For balancing, the target speed is set to 0 m/s

Derivative Gain:

This gain is multiplied by the derivative of the wheel’s velocity, which is the wheels acceleration. This hypothetically reduces the jerkiness of the robot, but due to the way this value is ultimately calculated (by taking the derivative of the derivative of the encoder values) we recommend this value be very small.

Integral Gain:

This gain is multiplied by the integral of the wheel’s velocity, which is effectively the wheels position. This will help keep the robot tended towards a set point, and stop the robot from drifting too far forward or backward.

 

 

VelocityController_Diagram.png
The Velocity PID takes the difference between the desired speed and the current speed, and outputs an angle that is fed into the pitch controller.

Part 4 - Recommended Process of Tuning

Step 1, Setting Up Your ROCKO:

It is recommended when setting up your ROCKO that you place him on the edge of a table, like the following image:

 

This allows for your ROCKO to be set up in a consistent position, and can be helpful for debugging any potential bugs or problems.

Step 2, Tune Pitch P Component:

The first gain to increase is the Pitch P component. As the components depend heavily on your system, there is no great rule of thumb for what to change this variable to right off the bat. However, we recommend to start small and increase the value as needed, rather then have a large value right at the beginning.

 

Qualitatively, with just this component as you tilt your ROCKO clockwise or counterclockwise, the wheels should also begin spinning in that direction.

As you tilt ROCKO further in one direction, the speed of the wheels should increase roughly proportionally to the amount tilted.

As ROCKO is returned to his ‘zero’ setpoint, the wheels should slow down until they reach zero at the set point.

PitchController_PDiagram.png

The goal is to slowly increase this gain value until ROCKO can recover (return to the zero setpoint) when starting at an angle of 15 degrees, and not immediately fall over after recovering:

Pitch P = 5

P should be further increased, as the force is not sufficient to get the wheel back under the center of mass
image-20250514-041252.png
Graph of the robot’s angle over time

 

Pitch P = 15

P is able to recover robot from falling over. Further increasing P will not ‘hurt’ at this stage, but this P value is sufficient to move forward.
image-20250514-041021.png
Graph of the robot’s angle over time

 

With just a P component, the robot should be able to stop itself from falling over for some amount of time, but without some way to control the speed, the robot will never be able to stop after it starts moving in a direction.

Step 3, Tune Pitch D Component:

The second gain to increase is the Pitch in the D component. A good rule of thumb is that this value should not be more then a fifth of the P component.

Pitch P = 15, D = 0.5

image-20250514-041947.png
Graph of the robot’s angle over time.

The bump and then slow descent downward indicates an underdamped system, increase D.

Pitch P = 15, D = 1

image-20250514-042223.png
Graph of the robot’s angle over time.

Given the quick approach to zero (<0.3 seconds) this D value accepted.

Pitch P = 15, D = 2

image-20250514-042304.png
Graph of the robot’s angle over time.

The slow approach to zero (>0.5 seconds) was deemed to be too much damping.

Tuning the D component at this point is more akin to seasoning to taste then finding an exactly right value. this term should help reduce oscillations, and although it is easy to tell if the system is underdamped (too small of a D component), as the robot will shoot past the setpoint and then move back (as was present in the far left simulation), there may be reasons to have a seemingly ‘overdamped’ system right now.

As was mentioned in part one, the derivative component can lead to more oscillations if there is delay or noise in the system. If increasing the D component begins to lead to more oscillations, it likely means a smaller D component is needed.

Step 4, Tune Velocity P Component:

The third gain to increase is the velocity controller’s P component. This component will help keep the robot from flying off into infinity, and help it keep it’s target velocity (which for balancing, is assumed to be zero).

With just a Pitch P (and/or D) component, as the robot was held in place at a specific angle, the wheel speed would stay at a consistent speed, since the setpoint wasn’t changing.

With the velocity P however, the setpoint will change as the wheel rotates. If ROCKO is titled the wheels will begin to spin, but now ROCKO’s wheels will continue to speed up even if he is held at a constant angle.

Even if ROCKO is returned to his ‘zero’ setpoint, the wheels will continue to spin, and won’t stop unless the pitch of the robot is over enough in the opposite direction to overcome the velocity controller’s change in setpoint.

VelocityController_PDiagram.png

 

Once again, no real way to know what this value should be, so we recommend starting small and slowly increasing:

Pitch P = 15, D = 0.5
Velocity P = 1

image-20250514-050204.png
Graph of the robot’s wheel velocity over time

The P component is able to reduce the speed initially, but ultimately more is needed.

Pitch P = 15, D = 0.5
Velocity P = 5

image-20250514-050245.png
Graph of the robot’s wheel velocity over time

The P component is able to reduce the speed initially, and then trend it towards 0.

Pitch P = 15, D = 0.5
Velocity P = 11

image-20250514-050544.png
Graph of the robot’s wheel velocity over time

The P component is far too high, with the robot nearly falling over and oscillating violently.

Tuning the velocity P component can actually get the robot to stay still in near-perfect conditions (show in the center example above). Too large or too small of a value can pose stability problems, so it is important to find a value that can keep the robot fairly steady.

This assumes pretty perfect information from the sensors, which likely just is not true. Part 5 explains some more of this in detail, but even a ‘good enough’ P value is likely enough to move onto the next step.

Step 5, Tune Velocity I Component:

The fourth gain to increase is the velocity controller’s I component. This component will help keep the robot centered around the starting location, and ultimately is what keeps the robot in place. Normally the I component of a PID is exceedingly low compared to the P or D terms, but we found for ROCKO that the I component could be as much as 80% of the P component.

Pitch P = 15, D = 0.5
Velocity P = 5, I = 0.1

image-20250515-000529.png
Graph of the robots wheel position over time

The I component is slowly bringing the robot back to its starting position (x=0).

Pitch P = 15, D = 0.5
Velocity P = 5, I = 2

image-20250515-000845.png
Graph of the robot’s wheel position over time

The I component brings the robot back to its starting position (x=0) and slightly overshoots.

Pitch P = 15, D = 0.5
Velocity P = 5, I = 5

image-20250515-001450.png
Graph of the robot’s wheel position over time

The I component brings the robot back to its starting position (x=0), but does slightly oscillate around the setpoint.

Much like the pitch D component, the exact I value will depend on how tightly you want your robot to stick to it’s starting position, with lower values more gradually bringing the robot to position, but higher values will lead to more oscillation around the setpoint and reaction to noise in the position variable.

At this point your ROCKO is tuned!

If you’re still having trouble getting your ROCKO to stay upright, look at the next section to see potential improvements or changes based on the limitations of your system.

Part 5 - Potential Sources of Error & Trouble Shooting

As in all multi-discipline projects, there can be multiple sources of error for one problem. Issues can crop up from the electrical, mechanical, programming, or computational systems. This makes debugging difficult, although this section attempts to identify a few sources of error of the ROCKO system.

Potential Source 1: Robot Turning

The above tuning procedure assumes that both fo ROCKO’s wheels are perfectly aligned at all times, have exactly the same input from their motors, and that both wheels move in exactly the same way/at exactly the same speed.
Given that ROCKO is assembled with tensioners on the belts (which by design do not slip), the wheels likely have an unequal amount of friction and damping. This means even if both motors output the same amount of torque, the wheels on either side will spin at different speeds, and ROCKO will spin (pictured right)

 

A software solution to this is the implementation of a third PID controller:
A ‘Yaw’ controller, which controls how the robot turns about the vertical axis.

Potential Source 2: Vertical Offset

 

Potential Source 3: Poor Encoder Resolution

 

Potential Source 4: Control Input Delay

 

Part 6 - FAQ

 

Part 7 - Worked Out Controller Example