Servo motor

Servo motor – definition

A servo motor is an actuator that combines an electric motor, a feedback sensor, and a control loop to achieve a commanded position, velocity, or torque. In mobile robotics, the term is used in two slightly different ways. In hobby and embedded systems, a servo often means a self-contained actuator that accepts a pulse-width command and internally closes the position loop. In control engineering, a servo motor is any motor operated in a closed-loop servo system with encoder feedback and a dedicated controller.

For UGV platforms, this distinction matters. A differential-drive base such as Leo Rover primarily uses drive motors for wheel propulsion, not RC-style servos for locomotion. However, servo motors are common in subsystems mounted on a UGV. Typical examples include pan-tilt units for cameras, steering modules in custom drivetrains, sensor deployment mechanisms, small grippers used as payloads, or latching and calibration fixtures. On larger research platforms such as Raptor Rover, servo-based mechanisms may also appear in payload stabilization, antenna pointing, instrument positioning, or auxiliary steering assemblies.

From a robotics integration perspective, a servo motor is defined by three properties: a command interface, a feedback path, and a closed-loop response. The controller compares a target value with measured state and applies motor current or voltage accordingly. This is the practical meaning of servo operation in ROS 2 based systems.

How servo motors are used on mobile UGV platforms

On a mobile robot, servo motors are usually not the main traction actuator unless the platform uses steering axles or articulated suspension. In the context of Leo Rover and Raptor Rover, they are more often used as accessory or payload actuators. This is important because servo integration affects power distribution, timing, controller architecture, and ROS 2 topic design.

The most common UGV use cases are the following.

camera pan-tilt mechanisms for inspection or teleoperation
LiDAR tilt units for 3D scanning or terrain profiling
sensor mast deployment and calibration fixtures
small end-effectors mounted as research payloads
steering actuators in custom non-differential experimental chassis

Leo Rover has a differential drive and 4 wheels, so wheel motion is not normally implemented with hobby servos. The platform typically uses Raspberry Pi based onboard compute and can be integrated with ROS 2. Any added servo motor must therefore be integrated as an auxiliary actuator through a microcontroller, PWM driver, or dedicated bus servo interface. Raptor Rover, with higher payload capacity, can host heavier sensor heads and stronger servo assemblies, but the same architectural rule applies: the servo must be represented explicitly in the robot control stack.

Control modes and feedback

The defining feature of a servo motor is feedback. Without feedback, the actuator is only an open-loop motor. In robotics documentation and manufacturer datasheets, servo systems are usually classified by controlled variable.

The main control modes are listed below.

position control – target angle or linear position
velocity control – target angular speed
torque or current control – target output torque, common in advanced servodrives

In small integrated servos, the feedback sensor is often a potentiometer or magnetic encoder. In industrial or research-grade servo drives, incremental or absolute encoders are typical. The control law may be PID or cascade control. A simple position loop can be written as:

e(t) = r(t) - y(t)
u(t) = Kp*e(t) + Ki*∫e(t)dt + Kd*de(t)/dt

Here, r(t) is the commanded position, y(t) is measured position, and u(t) is the control effort. In practice, many servo drives use current, velocity, and position loops arranged hierarchically.

Key parameters and metrics

Servo motor selection for a UGV payload should be based on measurable parameters, not only nominal voltage or form factor. The same actuator may work for a light RGB camera but fail for a LiDAR tilt mechanism exposed to shock and vibration.

The most relevant parameters are summarized below.

Parameter	What it means	Why it matters on a UGV
Rated voltage	Supply range, for example 5 V, 6 V, 7.4 V, 12 V	Must match onboard power rail and regulator capacity
Stall torque	Maximum torque at zero speed	Useful for sizing, but not a continuous operating point
No-load speed	Angular speed without external load	Determines motion time for scanning or pointing tasks
Angular range	Supported rotation span, for example 180 degrees or continuous rotation	Affects field of regard and mechanical stop design
Position resolution	Minimum controllable increment	Important for repeatable sensing and calibration
Deadband	Command change needed before output reacts	Impacts fine positioning and image stability
Update rate	Maximum command and feedback frequency	Limits tracking performance in ROS control loops
Ingress protection	Environmental sealing level	Critical in dust, moisture, and outdoor inspection work

Torque should be estimated from load geometry. For a payload of mass m mounted at distance r from the axis, static gravitational torque is approximately:

τ = m * g * r

where g ≈ 9.81 m/s². For field robots, a safety factor is needed because vibration, acceleration, and shock loads exceed static bench conditions.

ROS 2 integration patterns

ROS 2 does not define a single universal servo API for all hardware. Integration depends on whether the actuator is exposed as a low-level PWM device, a smart serial servo, or a full servodrive with encoder telemetry. The representation should be consistent with the rest of the robot architecture.

For simple accessory servos, a common approach is to run a microcontroller that receives ROS 2 commands and outputs PWM. For smarter actuators, the node may expose state and command topics or connect through ros2_control. The most useful message types are often standard interfaces such as sensor_msgs/msg/JointState, trajectory_msgs/msg/JointTrajectory, and geometry_msgs/msg/Twist only when the servo is part of a kinematic subsystem rather than the base drive itself.

A minimal ROS 2 topic example for a pan servo controller might look like this.

ros2 topic pub /pan_servo/command std_msgs/msg/Float64 "{data: 0.52}"

If the servo is modeled as a joint, state feedback may be published as:

ros2 topic echo /joint_states

An example controller configuration in YAML can be structured as follows.

controller_manager:
  ros__parameters:
    update_rate: 50

pan_tilt_controller:
  ros__parameters:
    type: joint_trajectory_controller/JointTrajectoryController
    joints:
      - pan_joint
      - tilt_joint
    command_interfaces:
      - position
    state_interfaces:
      - position

For ROS 2 systems, command frequency should match actuator capabilities and communication latency. A hobby PWM servo may only accept effective updates around the standard RC refresh domain, while serial servos and industrial drives can run much faster. The control loop should not publish faster than the hardware can process reliably.

Hardware interfaces and implementation details

The electrical interface is often the practical constraint on a rover. Small servos usually require a dedicated power rail because current spikes can reset onboard compute or inject noise into sensors. This is especially relevant on Raspberry Pi based systems such as Leo Rover.

The most common interface types are:

PWM servo interface – typically command pulse width, often around a 50 Hz frame in RC-style devices
UART or half-duplex serial smart servo – supports telemetry, IDs, and parameter configuration
CAN bus servo drive – common in higher power mechatronic systems
EtherCAT or industrial fieldbus servodrive – less common on compact UGV payloads, more common in advanced research rigs

For Leo Rover, a practical pattern is to offload timing-critical PWM generation to a microcontroller or dedicated driver board. The onboard ROS 2 computer then sends high-level commands. This reduces jitter and avoids CPU scheduling issues on Linux. For Raptor Rover, higher power rails and larger payload budgets make bus servos or integrated drives more realistic when heavier sensors or mechanisms are involved.

Use cases with Leo Rover and Raptor Rover

On Leo Rover, servo motors are useful when a research task needs active sensor orientation without redesigning the drivetrain. A pan-tilt depth camera can improve teleoperation, visual inspection, or data collection in narrow environments. A tilting 2D LiDAR can be used to create sparse 3D scans, although this is slower and mechanically more complex than a native 3D sensor.

On Raptor Rover, the larger chassis allows more demanding auxiliary mechanisms. Examples include heavier thermal cameras, GNSS antenna alignment rigs, environmental sensing heads, or stabilized sensor booms. In these cases, servo selection must account for payload inertia, cable routing, and outdoor durability.

Limitations and trade-offs

Servo motors are useful, but they introduce system-level trade-offs. A low-cost integrated servo is easy to command, yet often has limited feedback quality, unknown internal tuning, and poor environmental sealing. This can be acceptable for an indoor camera mount, but not for a precision outdoor sensing payload.

The main limitations are:

backlash in gears reduces pointing precision
limited duty cycle can lead to overheating under static load
current spikes can disturb onboard compute and sensors
consumer PWM servos often provide little or no state telemetry
mechanical stops limit range and can be damaged by poor control logic

For outdoor UGV work, servo reliability depends as much on power design and enclosure engineering as on the motor itself.

Normative references and standards

In ROS-based robotics, the relevant references are usually interface specifications rather than a single servo-specific standard. For robot description and control integration, URDF and ros2_control conventions are central. Joint state reporting commonly uses sensor_msgs/msg/JointState. Trajectory-driven motion typically uses trajectory_msgs/msg/JointTrajectory. Frame naming and coordinate conventions should follow REP 103 for standard units and coordinate conventions, and REP 105 for mobile platform frame semantics when the servo-mounted sensor contributes to localization or perception.

When comparing hardware, numerical parameters should be taken from manufacturer datasheets. Torque, speed, encoder resolution, communication protocol, and ingress protection vary significantly across vendors and cannot be inferred from the word servo alone.