Analog space mission
Analog Space Mission – definition
An analog space mission is a terrestrial field campaign designed to reproduce selected operational, environmental, technical, or human factors of a space exploration mission. It does not replicate space in full. Instead, it creates test conditions that are relevant to a defined research question, such as delayed communications, restricted mobility, remote science operations, low-bandwidth telemetry, harsh terrain, or limited maintenance access.
In mobile robotics, an analog space mission is commonly used to validate unmanned ground vehicle (UGV) hardware, autonomy software, perception pipelines, and operator workflows before deployment in remote environments. A rover may be evaluated in quarry terrain, volcanic landscapes, caves, deserts, snow, or construction-like sites. The goal is not to simulate a road vehicle or a stationary industrial robot. The goal is to measure how a mobile robotic system behaves when navigation, sensing, power management, and communication are constrained.
NASA describes analog missions as field tests that help researchers study technologies, operations, and human-system interactions relevant to exploration missions. The exact mission design depends on the target scenario, such as planetary surface exploration, subsurface inspection, or remote scientific sampling. Source: NASA Analog Missions.
Purpose of analog missions in UGV development
For a UGV, an analog mission turns a laboratory integration task into an operational test. It combines the robot, payload, terrain, communications, mission procedures, and data collection into one repeatable experiment. This makes it possible to identify failures that are not visible during short indoor tests.
A mission plan for a mobile rover should define measurable success criteria before deployment. Typical criteria include the following:
- Completion of a route or waypoint sequence without direct joystick control.
- Localization continuity during GNSS-denied or visually degraded segments.
- Obstacle detection performance for rocks, slopes, vegetation, trenches, or site infrastructure.
- Packet loss, command latency, and telemetry availability over the selected communication link.
- Battery consumption per mission segment, terrain type, and payload configuration.
- Repeatability of maps, trajectories, sensor recordings, and ROS 2 bag files.
- Recovery behavior after localization loss, sensor failure, wheel slip, or communication interruption.
An analog mission should distinguish between autonomy performance and operator performance. A rover may have reliable local obstacle avoidance but still fail an operational task if map updates are unavailable, data cannot be retrieved, or remote operators cannot understand its state.
ROS 2 architecture for an analog mission
ROS 2 provides a practical software framework for building mission-oriented UGV systems. A rover can expose sensor data, robot state, navigation status, diagnostics, and recorded mission data through ROS 2 topics, services, actions, and parameters. ROS 2 commonly uses DDS middleware, which supports configurable Quality of Service (QoS) policies for communication reliability, history, durability, and deadline handling. Source: ROS 2 QoS documentation.
A field system should use a stable frame tree. REP 105 defines commonly used mobile robot coordinate frames, including map, odom, and base_link. REP 103 defines standard coordinate conventions, including right-handed axes and SI units. These conventions are important when combining LiDAR odometry, IMU orientation, GNSS data, wheel odometry, and camera observations. Source: REP 105; Source: REP 103.
A typical ROS 2 mission data flow can include the following interfaces:
| Function | Typical ROS 2 interface | Relevant message type |
|---|---|---|
| Wheel odometry | /odom |
nav_msgs/msg/Odometry |
| Laser scanning | /scan |
sensor_msgs/msg/LaserScan |
| 3D LiDAR or depth point cloud | /points |
sensor_msgs/msg/PointCloud2 |
| Inertial measurements | /imu/data |
sensor_msgs/msg/Imu |
| GNSS position | /fix |
sensor_msgs/msg/NavSatFix |
| Navigation goal | NavigateToPose action |
nav2_msgs/action/NavigateToPose |
Localization, mapping, and terrain assessment
Analog missions often include navigation outside a controlled laboratory. This requires explicit handling of drift, wheel slip, sensor occlusion, terrain geometry, and changing illumination. A differential-drive rover can estimate motion from wheel encoders, but encoder-only odometry accumulates error when wheels lose traction or traverse uneven ground.
Sensor fusion can combine wheel odometry, IMU data, and GNSS or RTK-GNSS observations. In ROS 2, the robot_localization package is commonly used for Extended Kalman Filter or Unscented Kalman Filter state estimation. For GNSS-denied scenarios, a LiDAR-based or visual SLAM pipeline may provide a map-relative pose estimate. Navigation systems can then use the relationship between map, odom, and base_link defined by REP 105.
Mission datasets should include raw sensor streams as well as derived outputs. Recording only a final map or trajectory prevents later analysis of calibration errors, time synchronization problems, and perception failures.
ros2 bag record \
/tf /tf_static \
/odom \
/imu/data \
/scan \
/points \
/fix \
/diagnostics \
/cmd_vel \
/plan \
/local_costmap/costmap \
/global_costmap/costmapThe recorded topics should be adapted to the installed payload and mission objectives. For example, a GNSS-denied analog mission may prioritize LiDAR, IMU, wheel odometry, camera frames, and SLAM outputs. A precision outdoor survey may additionally record correction status and covariance data from the GNSS receiver.
Analog missions with Leo Rover and Raph Rover
Leo Rover is suitable for compact research, education, and prototype analog missions where the robot must carry a defined sensor payload and execute ROS 2 software on its onboard Raspberry Pi-based compute unit. Its four-wheel differential-drive configuration requires a navigation stack, sensor integration, and mission-specific tuning before autonomous operation. Autonomous navigation is not provided by the base platform alone.
A Leo Rover analog mission can test indoor-to-outdoor transitions, autonomous inspection routes, local mapping, teleoperation under constrained communications, or sensor fusion experiments. Its IP55 enclosure rating can be relevant when planning tests involving dust exposure or splashing water, but it does not remove the need to define environmental limits for each installed sensor and compute accessory. Source: Leo Rover technical documentation.
Raph Rover is more appropriate when the analog mission requires a larger payload, additional power capacity, or integration of heavier sensing equipment. Examples include multi-LiDAR configurations, a survey-grade GNSS receiver, a larger onboard computer, or field instrumentation. Platform selection should follow payload mass, center-of-gravity constraints, terrain requirements, and required mission duration rather than treating Raph Rover as a replacement for Leo Rover in laboratory or classroom work.
Mission metrics and verification
An analog mission is useful only when its results can be compared across runs. Test procedures should specify the route, terrain condition, payload configuration, software version, ROS 2 distribution, parameter files, and acceptance criteria. Containers, version-controlled launch files, and recorded ROS 2 bags help reproduce the software environment.
Useful quantitative metrics include position error, mission completion rate, localization availability, obstacle detection rate, energy consumption, network uptime, and mean recovery time after a fault. Position error can be expressed as:
position_error = || p_estimated - p_reference ||Where p_estimated is the position reported by the localization system and p_reference is a surveyed, motion-capture, or other validated reference position. The reference method must be documented because different reference systems have different uncertainty characteristics.