PID controller

PID controller – definition

A PID controller is a feedback control algorithm that computes a control signal from the error between a target value and a measured value. PID stands for proportional, integral, and derivative. In mobile robotics, it is used to regulate variables such as wheel speed, angular velocity, heading, motor current, or platform velocity. The controller output is a weighted sum of three terms: the present error, the accumulated error over time, and the rate of change of error.

In a UGV, a PID controller is usually not a complete autonomy solution. It is a low-level component inside the motion stack. It stabilizes the platform and helps the robot follow commands generated by higher layers such as trajectory tracking, waypoint following, or ROS 2 Nav2. On differential-drive platforms such as Leo Rover, PID control is commonly applied to left and right wheel velocity loops. On larger platforms such as Raph Rover, the same principle is used, but gains, actuator limits, inertia, and payload effects differ due to higher mass and torque requirements.

The standard continuous-time form is:

u(t) = Kp * e(t) + Ki * integral(e(t) dt) + Kd * de(t)/dt

Where:

u(t) – control output
e(t) – error = setpoint – measurement
Kp – proportional gain
Ki – integral gain
Kd – derivative gain

In embedded robot controllers, the discrete-time implementation is more common because motor loops run at fixed sampling intervals. Typical loop rates are tens to hundreds of hertz, depending on encoder resolution, motor driver capability, and compute budget.

Why PID matters in mobile robotics

Mobile robots operate in the presence of disturbances. These include wheel slip, changing battery voltage, uneven ground, payload variation, and friction differences between left and right sides. Open-loop motor commands are usually not sufficient for repeatable motion. A PID controller reduces the effect of such disturbances by using sensor feedback.

For a UGV, this has direct impact on navigation quality. If wheel speed control is poor, odometry degrades. If odometry degrades, localization and path tracking degrade as well. This is especially relevant for ROS 2 stacks where the robot publishes velocity commands on /cmd_vel and estimates motion through odometry topics and TF frames defined by REP 105 and standard ROS message interfaces.

Typical controlled variables on UGVs include:

wheel angular velocity from encoder feedback
platform linear velocity in m/s
platform angular velocity in rad/s
heading from IMU or fused state estimate
steering angle, if the platform is not differential drive

How PID control is used on Leo Rover and Raph Rover

Leo Rover is a four-wheel skid-steer mobile platform with ROS 2 support, typically based on Raspberry Pi as the onboard compute unit. In this architecture, PID control is most relevant at the drivetrain level. A higher ROS 2 node sends target velocities, and a lower controller translates them into motor effort while closing the loop using encoder feedback.

In practice, the control chain often looks like this:

a planner or teleoperation node publishes geometry_msgs/msg/Twist on /cmd_vel
a differential-drive or skid-steer controller converts body velocity into left and right wheel targets
a motor controller or embedded node runs PID loops for wheel speed
encoder data is used for correction and odometry estimation

On Leo Rover, PID tuning must respect the limits of a compact platform. High gains can cause oscillation, current spikes, and unstable motion on uneven terrain. Since Leo Rover is not autonomous out of the box, any navigation stack integrated by the user depends on correct low-level control behavior.

On Raph Rover, the same loop structure applies, but the control problem is usually harder. A larger payload and vehicle mass increase inertia. Terrain shocks and actuator saturation become more important. This often requires more conservative gains, anti-windup protection, and attention to motor current limits and command ramping.

PID in ROS 2 control and robotics software

In ROS 2, PID control may exist in several layers. It can be implemented inside firmware, in a hardware interface, or in a controller plugin. A common software framework is ros2_control, which separates hardware interfaces from controllers and allows standardized integration of joints, actuators, and command interfaces.

For mobile bases, differential-drive control is often handled through a controller that consumes velocity commands and publishes odometry. The exact package version and parameters depend on the ROS 2 distribution. Humble and newer distributions commonly use the ros2_control ecosystem together with controller manager and robot description files.

Representative interfaces in ROS 2 include:

geometry_msgs/msg/Twist for body velocity commands
nav_msgs/msg/Odometry for estimated motion
sensor_msgs/msg/JointState for wheel state feedback
TF frames such as odom, base_link, and wheel links according to REP 105

A simplified YAML-style configuration can look like this:

controller_manager:
  ros__parameters:
    update_rate: 100

diff_drive_controller:
  ros__parameters:
    type: diff_drive_controller/DiffDriveController
    left_wheel_names: ["left_front_wheel_joint", "left_rear_wheel_joint"]
    right_wheel_names: ["right_front_wheel_joint", "right_rear_wheel_joint"]
    wheel_separation: 0.38
    wheel_radius: 0.0625
    publish_rate: 50.0
    cmd_vel_timeout: 0.5
    use_stamped_vel: false

When PID is handled below ROS 2, for example in a motor microcontroller, the ROS 2 side may only expose target velocity and measured state. That division is common in robust field robots because it reduces timing jitter compared with running hard real-time loops on the main Linux computer.

Key parameters and tuning considerations

PID behavior depends on both gain values and implementation details. Two controllers with the same nominal gains can behave differently if they use different sampling times, derivative filtering, or output clamping. For mobile robots, tuning should be done on the real drivetrain and expected terrain whenever possible.

The most important parameters are:

Kp – increases response to current error, but too high a value can cause oscillation
Ki – removes steady-state error, but can cause overshoot and windup if saturation is present
Kd – damps fast changes, but is sensitive to encoder noise and quantization
sampling period – affects discrete-time stability and derivative calculation
output limits – constrain PWM, current, or velocity command
anti-windup – prevents integral term growth when the actuator is saturated

Useful performance metrics in UGV tuning include rise time, overshoot, settling time, steady-state error, and tracking error under load. If wheel speed setpoint is 5 rad/s, a tuned controller should reach it quickly without sustained oscillation and maintain it when the robot climbs a small slope or encounters rolling resistance changes.

Limitations and trade-offs

PID is simple and effective, but it has limits. It does not model terrain interaction explicitly. It cannot compensate for severe wheel slip, backlash, encoder dropout, or poor state estimation on its own. In outdoor robotics, these issues are common.

For that reason, PID is usually combined with other methods:

feedforward terms based on motor models or identified drivetrain parameters
state estimation using encoder, IMU, and optionally GPS/RTK fusion
higher-level trajectory controllers that account for kinematics
safety layers such as watchdog timeouts and command rate limiting

For Leo Rover and Raph Rover, PID should be treated as one layer in a larger stack. Good low-level control improves odometry and motion repeatability, but autonomous navigation still requires correctly integrated localization, transforms, and obstacle sensing.

Normative references and standards

In ROS-based mobile robotics, the controller itself is not defined by a single REP, but its integration relies on standard ROS interfaces and frame conventions. REP 105 defines coordinate frames for mobile platforms. ROS 2 message definitions such as geometry_msgs/msg/Twist, nav_msgs/msg/Odometry, and sensor_msgs/msg/JointState define how velocity commands and feedback are represented. The ros2_control framework provides a standardized method to expose command and state interfaces for robot hardware in ROS 2. For control theory terminology and performance measures, standards and textbooks from organizations such as IEEE and ISA remain common reference sources.