REP 105 (coordinate frames: map, odom, base_link)

REP 105 – definition

REP 105 is the ROS Enhancement Proposal that defines standard coordinate frames for mobile robot platforms. Its full title is Coordinate Frames for Mobile Platforms. The specification establishes common frame names and their intended semantic meaning, allowing localization, odometry, navigation, perception, and visualization components to exchange spatial data without project-specific frame conventions.

For a UGV, REP 105 primarily defines the relationship between map, odom, and base_link. These frames separate globally referenced position, locally continuous odometry, and the physical robot body. This separation is useful because wheel odometry is usually smooth but accumulates drift, while global localization can correct drift but may introduce discontinuous pose updates.

Source: ROS REP 105: Coordinate Frames for Mobile Platforms.

Core coordinate frames in a mobile robot

REP 105 defines conventions for a frame hierarchy rather than a single absolute pose. A typical ROS 2 UGV publishes transforms through tf2. Each transform describes the pose of a child frame relative to its parent frame.

Frame	Purpose	Expected behavior	Typical publisher
`map`	Global, world-fixed reference frame used by maps and global localization.	Should not drift over time, but its relation to `odom` may change when localization is corrected.	AMCL, SLAM system, visual localization, GNSS/RTK localization node.
`odom`	Locally continuous reference frame derived from odometry.	Must be continuous over short time intervals. It can drift relative to the physical environment.	Wheel encoder odometry, IMU fusion, robot_localization EKF.
`base_link`	Reference frame rigidly attached to the mobile base.	Moves with the robot. Its origin and orientation are defined by the robot integration.	Odometry publisher for `odom -> base_link`; `robot_state_publisher` publishes transforms to URDF-defined child links.

The standard transform chain for a mobile robot is:

map -> odom -> base_link

In this chain, the transform odom -> base_link is produced by odometry. The transform map -> odom is produced by a global localization or mapping process. A navigation stack can therefore plan in map while local controllers use the smooth pose available through odom.

Why REP 105 separates map and odom

A differential-drive UGV cannot obtain an error-free global pose from wheel encoders alone. Wheel slip, uneven terrain, wheel diameter tolerances, and encoder quantization introduce accumulated position and heading error. For this reason, REP 105 does not treat odom as a globally accurate frame.

The odometry estimate can be represented as a planar transform:

T_odom_base_link = [ R(theta)  t(x, y) ]
                   [    0          1   ]

Here, x and y describe the robot position in the odometry frame, while theta describes yaw. For ground robots, roll and pitch may also be present when an IMU is used, but navigation systems commonly operate on a planar projection of the robot pose.

Global localization corrects accumulated error by updating map -> odom. This design prevents a localization correction from causing a discontinuity in the odometry transform itself. The robot remains locally controllable even when the estimated global pose changes.

REP 105 on Leo Rover and Raph Rover

Leo Rover uses a four-wheel differential-drive chassis and supports ROS 2 on its built-in Raspberry Pi compute unit. A basic ROS 2 integration should publish a valid odom -> base_link transform from the rover drive system. This transform is sufficient for teleoperation, local odometry display, and initial control development, but it does not provide autonomous navigation by itself.

For autonomous operation, Leo Rover requires an additional localization and navigation stack. The exact sensor configuration depends on the environment and task.

A 2D LiDAR can provide data for scan matching, occupancy-grid mapping, and AMCL-based localization against a pre-existing map.
An IMU can improve orientation estimation and short-term motion estimation when fused with wheel odometry.
A depth camera can publish a sensor frame such as camera_link and support obstacle perception.
A GNSS receiver with RTK corrections can provide a global position source for outdoor mapping and field navigation.

Raph Rover follows the same REP 105 semantics. Its larger payload capacity can support more extensive sensor configurations, such as a LiDAR, GNSS/RTK receiver, IMU, and additional compute hardware. The frame tree remains conceptually identical. Additional payloads should be connected to the robot frame tree, typically through static transforms below base_link when they are rigidly mounted.

Sensor frames and URDF integration

Every physical sensor needs a frame with a known pose relative to the mobile base. These transforms are usually defined in a URDF or Xacro model and published by robot_state_publisher. Sensor frame names should be descriptive and consistent across launch files, calibration data, and recorded ROS bags.

A simplified URDF convention can use the following frame structure:

base_link
├── laser_link
├── imu_link
├── camera_link
└── gps_link

The static transform between base_link and a sensor frame must use measured translation and rotation values. An incorrect extrinsic calibration affects mapping, obstacle detection, visual odometry, and sensor fusion. In particular, a LiDAR mounted with an incorrect yaw offset can produce distorted maps and inconsistent scan matching results.

Checking the TF tree in ROS 2

ROS 2 provides command-line tools for validating whether the required REP 105 transforms are available. The following command queries the current transform between the global map frame and the robot body frame.

ros2 run tf2_ros tf2_echo map base_link

The transform tree can also be exported for inspection. This is useful when a navigation node reports missing transforms, extrapolation errors, or disconnected frame trees.

ros2 run tf2_tools view_frames

A valid navigation configuration normally requires a connected path from the navigation global frame to base_link. If a system uses map as its global frame, the chain must include both map -> odom and odom -> base_link.

ROS 1 and ROS 2 considerations

REP 105 applies to both ROS 1 and ROS 2 because it defines frame semantics rather than middleware-specific APIs. ROS 2 uses the tf2 transform library, while transform broadcasters publish transforms through the /tf and /tf_static topics. Static sensor transforms should be published on /tf_static, while changing odometry and localization transforms are published on /tf.

Frame identifiers should be consistent across the robot description, sensor drivers, localization nodes, and Nav2 configuration. Mixing names such as base_link, base_footprint, and custom base frame names without explicit transforms is a common cause of integration failures.

Normative references and standards

REP 105 is the primary normative reference for this frame convention in ROS mobile robotics. It should be read together with ROS 2 tf2 documentation and the Navigation2 documentation when integrating localization and navigation on a UGV.