Glossary

Fictionlab > Glossary > Planetary rover

Planetary rover

Planetary rover – definition

A planetary rover is a mobile robotic vehicle designed to traverse, observe, and perform scientific or operational tasks on the surface of an extraterrestrial body. Typical target environments include the Moon, Mars, and, in research settings, simulated planetary terrain. Unlike an orbital spacecraft, a rover operates in contact with the surface and must manage locomotion, perception, energy, communication, and navigation under terrain-dependent constraints.

In mobile robotics, a planetary rover is treated as a ground vehicle with a constrained mobility model, a sensor suite, an onboard compute system, and a mission-level autonomy stack. Its software architecture commonly includes state estimation, mapping, obstacle detection, path planning, motion control, and telemetry. These functions can be implemented with ROS 2, although ROS 2 itself is not a planetary-flight qualification standard.

The term also applies to terrestrial rover prototypes used for planetary robotics research. Leo Rover and Raph Rover can be used as development platforms for testing perception, navigation, teleoperation, ROS 2 integration, and payload interfaces before deploying software to a mission-specific rover. They are not planetary-qualified vehicles and should not be represented as hardware certified for extraterrestrial operation.

Core subsystems of a planetary rover

A rover must convert high-level mission goals into safe motion over uncertain terrain. The required subsystems are coupled. For example, poor wheel odometry affects localization, which in turn reduces path-planning accuracy and may cause unsafe commands.

  • Locomotion system: wheels, tracks, suspension, motor drivers, encoders, and a kinematic model.
  • State estimation: fusion of wheel odometry, IMU data, visual odometry, LiDAR odometry, and GNSS where GNSS is available.
  • Perception: cameras, stereo cameras, depth cameras, LiDAR, radar, or terrain-relative sensing.
  • Navigation: mapping, localization, global planning, local obstacle avoidance, and velocity control.
  • Mission software: waypoint execution, sampling procedures, inspection logic, logging, and remote supervision.
  • Communications: command uplink, telemetry downlink, video streams, and delayed-operation handling.

On Earth, GNSS or RTK GNSS can provide global position estimates. On the Moon and Mars, no operational GNSS infrastructure is available. A planetary rover therefore relies more heavily on inertial sensing, visual odometry, stereo vision, LiDAR, wheel odometry, landmark observations, and terrain-relative localization.

Coordinate frames and rover state in ROS 2

ROS 2 rover applications normally use the coordinate-frame conventions defined by REP 103 and the mobile-robot frame conventions defined by REP 105. REP 103 specifies a right-handed body-frame convention: x forward, y left, and z upward.

A basic rover transform tree usually contains map, odom, base_link, and sensor frames. The map frame represents a globally consistent reference. The odom frame provides locally continuous odometry. The base_link frame is fixed to the rover chassis.

map
 └── odom
      └── base_link
           ├── imu_link
           ├── lidar_link
           └── camera_link

Common ROS 2 interfaces include nav_msgs/msg/Odometry for estimated motion state, sensor_msgs/msg/Imu for inertial data, sensor_msgs/msg/LaserScan or sensor_msgs/msg/PointCloud2 for ranging data, and geometry_msgs/msg/Twist for commanded velocity. Their definitions are maintained in the official ROS 2 interface documentation.

Locomotion models and terrain constraints

Many research rovers use skid-steer or differential-drive control because the hardware is mechanically simple and compatible with independent left and right wheel groups. Leo Rover uses a four-wheel skid-steer configuration. Its planar kinematic approximation can be expressed as:

v = (vR + vL) / 2
ω = (vR - vL) / b

In this model, v is linear velocity, ω is angular velocity, vR and vL are right and left wheel-side velocities, and b is the effective track width. On loose soil, gravel, slopes, or uneven terrain, wheel slip makes encoder-derived odometry inaccurate. A practical rover stack should therefore fuse encoder data with IMU and exteroceptive measurements rather than treating wheel odometry as ground truth.

Planetary-rover workflows with Leo Rover and Raph Rover

Leo Rover provides a compact ROS 2 test platform for experiments involving skid-steer kinematics, teleoperation, SLAM, visual perception, and autonomous waypoint navigation. The platform uses an integrated Raspberry Pi compute unit and can be used with ROS 2; supported distributions depend on the installed software image and configuration. Its IP55 enclosure rating is relevant for terrestrial laboratory and controlled outdoor testing, but it does not imply suitability for vacuum, radiation, extreme temperature, or abrasive planetary regolith.

Raph Rover is more appropriate when a rover experiment requires greater payload capacity, larger sensors, additional onboard compute, or a heavier research instrument package. It can support terrestrial analog workflows such as carrying a 3D LiDAR, stereo camera rig, RTK receiver, environmental sensor package, or NVIDIA Jetson-based perception computer. Platform selection should follow the payload mass, power, mounting, and terrain requirements documented for the specific configuration.

A ROS 2 navigation configuration for a terrestrial planetary-analog test may define conservative velocity limits and use a local obstacle layer built from LiDAR or depth data:

controller_server:
  ros__parameters:
    controller_plugins: ["FollowPath"]
    FollowPath:
      plugin: "dwb_core::DWBLocalPlanner"
      max_vel_x: 0.25
      max_vel_theta: 0.6

local_costmap:
  local_costmap:
    ros__parameters:
      global_frame: odom
      robot_base_frame: base_link
      rolling_window: true
      plugins: ["obstacle_layer", "inflation_layer"]
      obstacle_layer:
        plugin: "nav2_costmap_2d::ObstacleLayer"
      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"

The values above are example software limits, not Leo Rover or Raph Rover hardware specifications. They must be validated against wheel traction, payload, braking distance, sensor field of view, and the operating surface.

Autonomy limitations in planetary environments

Planetary navigation is constrained by limited communications, uncertain terrain properties, restricted energy budgets, and sparse global reference data. A terrestrial navigation stack such as Nav2 can provide useful components, but it must be adapted to the mission environment. Standard local planners may require additional terrain traversability costs, slip detection, slope estimation, wheel-sinkage monitoring, and fault-management logic.

For Leo Rover and Raph Rover, autonomous navigation is not a default capability of the base platform. A complete system requires sensor integration, calibrated transforms, a valid robot model, localization or SLAM, a costmap configuration, motion-controller tuning, and safety validation. The relevant platform integration details should be checked in the Leo Rover technical documentation.

Technical references and sources

The following sources provide conventions, interfaces, implementation guidance, and background relevant to rover software in ROS-based mobile robotics.

See also