Telemetry

Telemetry – definition

Telemetry is the automated measurement, transmission, and monitoring of data from a remote system to another system for observation, logging, diagnosis, or control. In mobile robotics, telemetry usually means the live operational data stream sent by a UGV to a ground station, developer workstation, cloud endpoint, or another robot. The term covers both onboard state data and external link diagnostics.

In the context of ROS and ROS 2, telemetry is not a single protocol or package. It is a functional layer built from topics, services, actions, diagnostics, logs, time synchronization, network transport, and data recording. Typical telemetry on a UGV includes pose estimates, wheel odometry, IMU measurements, battery state, motor controller status, CPU temperature, wireless signal quality, GNSS fixes, and mission events. On Leo Rover and Raph Rover, telemetry is relevant for teleoperation, autonomous navigation experiments, field testing, remote debugging, and post-run analysis.

Telemetry should be distinguished from command traffic. A /cmd_vel message is a control input. A stream such as /odom, /imu/data, /battery_state, or /diagnostics is telemetry. In practice, both often share the same network, but they differ in timing requirements, reliability expectations, and storage value.

How telemetry works in ROS 2

ROS 2 typically uses DDS or a DDS-compatible middleware layer for communication. This matters for telemetry because data delivery behavior is configured through Quality of Service, not just through topic names. A telemetry stream can be configured for best effort, reliable delivery, transient local persistence, or limited history depending on the message type and operational goal.

For mobile robots, telemetry usually combines high-rate sensor data, medium-rate state estimates, and low-rate health information. The table below shows common ROS 2 telemetry topics on a UGV.

Topic	Typical message type	Typical rate	Purpose
`/odom`	`nav_msgs/msg/Odometry`	20 – 100 Hz	Wheel odometry or fused motion estimate
`/imu/data`	`sensor_msgs/msg/Imu`	50 – 400 Hz	Angular velocity and linear acceleration
`/joint_states`	`sensor_msgs/msg/JointState`	10 – 100 Hz	Wheel speed and steering-related state if present
`/battery_state`	`sensor_msgs/msg/BatteryState`	0.5 – 5 Hz	Voltage, current, charge, percentage
`/diagnostics`	`diagnostic_msgs/msg/DiagnosticArray`	0.5 – 5 Hz	Health, temperature, device status
`/tf` and `/tf_static`	`tf2_msgs/msg/TFMessage`	`/tf`: 10 – 100 Hz, `/tf_static`: on change or startup	Frame transforms for state interpretation
`/fix`	`sensor_msgs/msg/NavSatFix`	1 – 20 Hz	GNSS position telemetry

In ROS 2, telemetry design depends strongly on QoS settings. Sensor streams often use the predefined sensor data profile with best effort delivery and small queue depth to reduce latency. Health and event messages are more often reliable, because missing a fault report is worse than receiving it late.

# Inspect live telemetry topics
ros2 topic list

# Check message rate
ros2 topic hz /odom
ros2 topic hz /imu/data

# Inspect bandwidth
ros2 topic bw /camera/depth/image_rect_raw

# Echo battery telemetry
ros2 topic echo /battery_state

# Record telemetry for offline analysis
ros2 bag record /odom /imu/data /battery_state /diagnostics /tf /tf_static

Key parameters and metrics

A telemetry link is useful only if the data is time-consistent, interpretable, and available at a sufficient rate. For UGV work, engineers usually evaluate telemetry with quantitative metrics rather than qualitative descriptions.

The most important telemetry parameters are listed below.

Update rate – how often a topic publishes, in Hz.
End-to-end latency – time from measurement to reception by the operator or processing node.
Packet loss – fraction of samples never received.
Timestamp accuracy – consistency between sensor timestamps and system clock.
Bandwidth – data rate in bit/s or byte/s. This is critical for image and point cloud telemetry.
Jitter – variation in arrival times. High jitter complicates state estimation.
Frame consistency – correctness of frame identifiers relative to REP 103 and REP 105.

For practical engineering, the effective throughput can be estimated as:

throughput [B/s] = message_size [B] x publish_rate [Hz]

For example, an IMU message of a few hundred bytes at 200 Hz is light compared with a depth image stream. A 640 x 480 depth image at 16 bits per pixel is about 614 kB per frame before transport overhead. At 30 Hz, raw throughput exceeds 18 MB/s, so compression, decimation, or edge processing may be necessary on Wi-Fi links.

Telemetry sources on Leo Rover and Raph Rover

On Leo Rover, telemetry typically originates from the Raspberry Pi-based onboard computer, motor control interface, inertial sensors, cameras, and optional external devices such as LiDAR or GNSS receivers. Because the platform supports ROS 2, telemetry can be published into the ROS 2 graph and inspected using standard tools. This is convenient in research and education, but it also means that bandwidth and CPU budget must be managed carefully on the embedded compute unit.

For Leo Rover, common telemetry streams include:

wheel odometry from the differential drive base,
IMU data for orientation and motion estimation,
battery and power state for mission supervision,
camera and optional LiDAR data for perception experiments,
diagnostic messages for thermal and process monitoring.

Raph Rover serves a different class of workload. Its larger payload capacity allows integration of heavier sensors and more capable compute modules. In telemetry terms, this often means denser point clouds, multi-camera setups, RTK GNSS, and longer field missions. The principle is the same, but logging volume, synchronization requirements, and power-domain monitoring become more important.

Integration patterns and example configuration

Telemetry is often aggregated through standard ROS 2 topics plus diagnostic_updater and rosbag2 recording. A common pattern is to publish low-level state locally, fuse selected signals into higher-level estimates, and forward a reduced telemetry set over the wireless link.

The following example shows a simple ROS 2 parameter file for diagnostic publication and telemetry-oriented logging choices.

telemetry_node:
  ros__parameters:
    publish_rate_hz: 10.0
    battery_topic: /battery_state
    odom_topic: /odom
    imu_topic: /imu/data
    diagnostics_topic: /diagnostics
    log_to_rosout: true
    warn_cpu_temp_c: 75.0
    warn_link_rssi_dbm: -70

For field work, it is common to split telemetry into three classes:

real-time operator telemetry – low latency, possibly reduced fidelity,
navigation telemetry – used by onboard estimators and planners,
forensic telemetry – full-resolution rosbag2 recording for later analysis.

Limitations and trade-offs

Telemetry is constrained by wireless quality, compute resources, and time synchronization. A mobile robot operating outdoors may face unstable Wi-Fi, changing line of sight, and strong variation in bandwidth. Sending full sensor streams can saturate the link and degrade command responsiveness. The usual mitigation is to keep control onboard and export only selected telemetry.

Another trade-off is reliability versus latency. Reliable QoS improves delivery, but retransmissions can increase delay on poor links. Best effort delivery reduces delay but tolerates loss. For state monitoring on a moving UGV, best effort is often acceptable for high-rate sensor data, while fault and battery messages should remain reliable.

Timestamp quality is also critical. If telemetry from IMU, LiDAR, and GNSS is not aligned, sensor fusion quality degrades. This affects localization, SLAM, and post-mission analysis. In ROS systems, frame naming and coordinate conventions should follow REP 103 for units and coordinate orientation, and REP 105 for mobile platform frame semantics such as base_link, odom, and map.

Normative references and standards

The technical meaning of telemetry in ROS-based UGV systems is grounded in message specifications, transport behavior, and coordinate conventions rather than in a single standard document. The most relevant references are the ROS 2 documentation on topics and QoS, ROS message definitions, and ROS Enhancement Proposals for frames and units.

ROS 2 documentation – topics, rosbag2, and QoS policies, source: docs.ros.org
REP 103 – Standard Units of Measure and Coordinate Conventions, source: ros.org/reps/rep-0103.html
REP 105 – Coordinate Frames for Mobile Platforms, source: ros.org/reps/rep-0105.html
sensor_msgs, nav_msgs, diagnostic_msgs, source: ROS interface definitions
Telemetry as remote measurement and reporting in engineering systems, source: standard engineering usage