Teleoperation

Teleoperation – definition

Teleoperation is the remote control of a robot by a human operator over a communication link. In mobile robotics, the term usually means sending motion commands, mode changes, or actuator requests from a remote station to a UGV while receiving feedback such as video, odometry, battery state, and alarms. The robot executes commands locally, but the high-level driving decision remains with the operator.

In ROS and ROS 2 systems, teleoperation is commonly implemented as a chain of publishers, subscribers, and safety nodes. The operator input may come from a keyboard, joystick, web UI, or custom control station. The command is typically published as geometry_msgs/msg/Twist on /cmd_vel for differential-drive motion, or as a stamped variant if the stack requires timestamps and frame context. On UGV platforms such as Leo Rover and Raptor Rover, teleoperation is the standard entry point for testing drivetrain integration, validating sensor placement, and operating the robot before autonomous navigation is deployed.

Teleoperation is not autonomy. It does not perform local planning, global planning, or obstacle-aware path execution unless those functions are added as separate layers. A teleoperated UGV may still use local protections such as emergency stop, velocity limiting, collision monitoring, or watchdog timeouts.

How teleoperation works in ROS 2

In ROS 2, teleoperation is usually built around standardized message types and middleware QoS policies. For a differential-drive rover, the operator sends linear and angular velocity setpoints. The drivetrain controller or base node converts these into wheel commands. Feedback flows in the opposite direction through state topics.

A minimal ROS 2 teleoperation path for a UGV typically contains the following elements:

Input device node – for example teleop_twist_keyboard or joy plus teleop_twist_joy
Command topic – usually /cmd_vel with type geometry_msgs/msg/Twist
Velocity mux or arbiter – merges manual, autonomous, and safety command sources
Base controller – often based on diff_drive_controller in ros2_control
Feedback topics – such as /odom, /joint_states, /battery_state, camera streams, and diagnostics

ROS 2 teleoperation is affected by DDS transport behavior. Reliable QoS can help on stable local networks, but best effort may reduce latency for joystick-like control on lossy links. For camera streams, image transport and compression parameters often dominate usability more than the control topic itself.

For differential drive, the command variables are:

v - linear velocity in m/s
w - angular velocity in rad/s

The wheel angular velocities are then derived from standard kinematics:

omega_left  = (v - (w * L / 2)) / r
omega_right = (v + (w * L / 2)) / r

where L is the track width and r is the wheel radius. This matters because any teleoperation limit on v and w maps directly to motor demand, wheel slip, and current draw.

Key parameters and metrics

Teleoperation quality is determined by control responsiveness, operator feedback, and safety behavior under packet loss or delay. For UGVs working indoors, outdoors, or in research environments, the important metrics are measurable.

Parameter	Typical value	Why it matters
Command topic rate	10 – 50 Hz	Too low gives jerky motion, too high can waste bandwidth
End-to-end control latency	< 100 ms preferred for manual driving	Higher latency reduces operator precision
Video frame rate	15 – 30 fps	Low frame rate makes terrain assessment difficult
Watchdog timeout	0.2 – 1.0 s	Stops the robot if commands stop arriving
Max linear velocity	Platform-specific	Should match traction, mass, and environment
Max angular velocity	Platform-specific	Affects turning radius and rollover risk on rough terrain

The command topic for teleoperation usually uses ROS units defined by message semantics: meters per second for linear velocity and radians per second for angular velocity. Frame conventions should follow REP 103 for units and coordinate conventions, and mobile base frame naming commonly follows REP 105, including frames such as base_link, odom, and map.

Typical ROS 2 implementation

A practical setup uses a joystick node and a teleop mapping node. The output is then constrained by a safety layer or velocity smoother before reaching the base controller.

ros2 run joy joy_node
ros2 run teleop_twist_joy teleop_node --ros-args \
  -p require_enable_button:=true \
  -p enable_button:=4 \
  -p axis_linear.x:=1 \
  -p scale_linear.x:=0.4 \
  -p axis_angular.yaw:=3 \
  -p scale_angular.yaw:=1.2

A corresponding YAML configuration may look like this:

teleop_node:
  ros__parameters:
    require_enable_button: true
    enable_button: 4
    axis_linear.x: 1
    scale_linear.x: 0.4
    axis_angular.yaw: 3
    scale_angular.yaw: 1.2

For inspection and debugging, these CLI commands are commonly used:

ros2 topic list
ros2 topic echo /cmd_vel
ros2 topic hz /cmd_vel
ros2 topic echo /odom
ros2 node info /teleop_node

Teleoperation on Leo Rover and Raptor Rover

On Leo Rover, teleoperation is often the first control mode used after assembly, sensor integration, or software deployment. Leo Rover is a four-wheel skid-steer mobile platform with ROS 2 support and an onboard Raspberry Pi-based compute unit. In this context, teleoperation is used to verify wheel orientation, drivetrain calibration, encoder feedback, and command pipeline integrity before enabling SLAM or Nav2.

Because Leo Rover is not an autonomous vehicle out of the box, remote driving is a practical default mode during lab work, education, and field prototyping. A common setup includes /cmd_vel control, camera streaming, and local safety timeout in the motor control path. On Wi-Fi, a researcher can drive the platform indoors for mapping data collection or outdoor inspection at low speed. Documentation and integration details for the platform are available at docs.fictionlab.pl/leo-rover.

On Raptor Rover, teleoperation serves a similar role but under higher payload and higher inertia conditions. The larger mass changes braking distance, wheel slip behavior, and acceptable acceleration limits. That means joystick scaling, velocity saturation, and watchdog tuning should be more conservative than on a lighter educational rover. Raptor Rover is better suited to heavier sensor payloads or field equipment, but that does not remove the need for robust remote control, especially during commissioning and testing.

Safety, limitations, and trade-offs

Teleoperation is simple to deploy, but its limits are clear. It depends on communication quality, operator skill, and sufficient situational awareness. A UGV with narrow camera field of view, delayed video, or no depth sensing is harder to drive safely, especially on ramps, loose soil, or cluttered indoor corridors.

For that reason, a teleoperation stack should usually include these protections:

Deadman switch or enable button
Command timeout watchdog
Velocity and acceleration limits
Emergency stop, wired or wireless
Priority arbitration between manual and autonomous sources
Battery and thermal alarms on the operator interface

Teleoperation also does not solve localization drift, obstacle avoidance, or route planning. It is often combined with perception modules, but those are separate functions. In practice, teleoperation is the baseline operational mode from which assisted teleoperation or full autonomy can be developed.

Normative references and standards

The technical interpretation of teleoperation in ROS-based UGV systems should align with official ROS conventions and hardware documentation rather than ad hoc assumptions. The most relevant references are:

ROS 2 interface documentation for geometry_msgs/msg/Twist, sensor_msgs/msg/Joy, and nav_msgs/msg/Odometry – source: docs.ros.org
REP 103 – Standard Units of Measure and Coordinate Conventions
REP 105 – Coordinate Frames for Mobile Platforms
ros2_control and diff_drive_controller documentation for differential-drive command interfaces
Platform-specific documentation for Leo Rover – source: docs.fictionlab.pl/leo-rover

In ROS 1 and ROS 2, the teleoperation concept is the same, but package names, launch style, parameter syntax, and middleware behavior differ. ROS 2 adds DDS-based QoS configuration, which directly affects remote control reliability and latency.