Sensor Monitoring

MRS UAV Status is the primary tool for monitoring the UAV's state during operation. Configure it to display rates for all sensors so you can quickly spot issues.

Launch All Sensors in Every Provided Session

When a UAV has multiple sessions for different applications (e.g. session_indoor and session_outdoor), the set of sensors each application uses will often differ — indoor flights might rely on a LiDAR for SLAM while outdoor flights use GNSS. Even so, launch every physical sensor the robot is equipped with in every session, not just the ones the current application consumes. E.g a camera driver should be launched in both indoor and outdoor sessions, even if only the indoor session uses the camera data.

Why this is worth the extra panes:

• Sensor health check at startup. If a sensor is broken, miswired, or misconfigured, you want to discover that on the ground with every session — not the first time you swap applications in the field.
• Monitoring stays uniform. MRS UAV Status will show rates for all sensors in both sessions.
• Reference for customers. Each session doubles as a worked example of how to bring up every sensor on the platform. When a client customize a new session, they can copy a driver pane from an existing session.

In practice, this means the sensor driver panes in tmux.sh are largely the same across sessions on the same robot — what differs is the application stack (SLAM, estimators, mission nodes) layered on top.

tip

If a sensor's data is genuinely not wanted in a given application (for bandwidth or interference reasons), prefer excluding it from recording or from the application's inputs rather than skipping its driver launch.

Configuring MRS UAV Status

Edit config/custom_config.yaml in your session folder. Under the mrs_uav_status section, add entries for each sensor topic you want to monitor. Under the want_hz key, list the topics along with their display names and expected rates.

Format

Each entry in want_hz follows this format:

"<topic_path> <display_name> <expected_rate>"

• topic_path: The ROS topic to monitor
  • Absolute paths (starting with /) are used as-is
  • Relative paths (without /) are prefixed with /$UAV_NAME/
• display_name: Short name shown in the status display
• expected_rate: Expected publish rate in Hz

Example Configuration

mrs_uav_status:
    want_hz:
      - "hw_api/gnss hz_gnss 5.0"
      - "hw_api/imu hz_imu 100.0"
      - "estimation_manager/odom_main hz_odom 100.0"
      - "/ouster/imu hz_ouster_imu 100.0"
      - "camera/camera_info hz_cam 30.0"

In this example:

• hw_api/gnss becomes /$UAV_NAME/hw_api/gnss (relative path)
• /ouster/imu stays as /ouster/imu (absolute path)

Bandwidth Considerations

warning

Do not monitor high-bandwidth topics directly. Monitoring camera image topics or full point cloud topics can overload the network, especially over WiFi.

Use lower-bandwidth alternatives instead:

Sensor Type	Avoid Monitoring	Monitor Instead
Cameras	/camera/image_raw	/camera/camera_info
LiDARs	/lidar/points	/lidar/imu or a diagnostic topic

Verification

After configuring, run the tmux session and check MRS UAV Status:

1. All configured sensors should appear in the status display
2. Rates should be green (matching expected values)
3. No sensor should show red/missing unless it's physically disconnected