You’re reading an older version of the Slamcore SDK documenation. The latest one is 23.04.

Frames of Reference Convention


Currently the Slamcore frames of reference do not abide to the ROS frames of reference convention, as defined in REP-105. If this is important to your application, consider using a static transform publisher node to republish the measurements of the ROS Wrapper using a frame that does abide to REP-105.

When using the RealSense D435i camera by default, our system is configured to track the reference frame that’s rigidly attached to the RealSense IMU chip. With the camera parallel to the ground and facing forwards, that coordinate system has the Z axis pointing forwards and the X axis pointing to the right side.

We track this coordinate frame with regards to the world coordinate frame which is initialised based on the gravity direction. Given that again, the camera is pointing forwards and parallel to the ground, the Z axis will be initialised opposite of the gravity direction. Then the X axis will point towards the right side and Y will be pointing forwards.

So, if you start up the RealSense, parallel to the ground as in most cases and start moving it forwards, you will notice our Y estimate increasing. Similarly, if you move it upwards, then you’ll notice a positive increase in the Z coordinate.

Following is an image from RVIZ after having moved the camera slightly forwards. In this image the world frame is called slamcore/map frame, and the pose estimation / IMU frame is called slamcore/imu_0 frame. The slamcore/odom frame is discussed in the following section.


map and odom frames

Many popular ROS frameworks, like the navigation stack abide to the ROS Coordinate Frames convention - REP-105, and thus requires two transformations to operate:

  • map \(\rightarrow\) base_link

  • odom \(\rightarrow\) base_link

where base_link is the main frame of reference of the robot platform in use.

This way a ROS node that’s interested in the pose of the robot can query either map \(\rightarrow\) base_link or odom \(\rightarrow\) base_link. If it queries the former, it will get the most accurate estimation of the robot pose, however, that may include discontinuities or jumps. On the other hand, the odom \(\rightarrow\) base_link transform is drift-y and overall less-accurate but is guaranteed to change smoothly over time.

Traditionally the localisation module would compute the map \(\rightarrow\) base_link transform, and would use the latest odom \(\rightarrow\) base_link, as published by the odometry node (e.g. dead reckoning via wheel odometry) to eventually publish map \(\rightarrow\) odom and abide to REP-105.

To abide to this standard and also increase the overall accuracy of these transforms, the Slamcore ROS Wrappers incorporate the latest odometry information and publish both the map \(\rightarrow\) odom and odom \(\rightarrow\) base_link transforms. This way we can provide a smooth odom \(\rightarrow\) base_link transform that potentially uses the wheel-odometry, as well as information from the visual and inertial sensors.