Glossary

Fictionlab > Glossary > Visual SLAM (vSLAM)

Visual SLAM (vSLAM)

Visual SLAM (vSLAM) – definition

Visual simultaneous localization and mapping, usually abbreviated as Visual SLAM or vSLAM, is a method that estimates a mobile robot’s pose while building or updating a map from camera data. In an unmanned ground vehicle (UGV), the system processes consecutive images, detects visual features or image regions, estimates camera motion, and associates observations with landmarks or map elements.

vSLAM is distinct from visual odometry. Visual odometry estimates relative motion over a short sequence of images. A SLAM system additionally maintains a map and can reduce accumulated drift through map matching, relocalization, or loop closure. A loop closure occurs when the robot recognizes a previously observed place and adds a constraint between non-consecutive poses.

For UGVs such as Leo Rover (differential drive) or Raph Rover (Ackermann steering), vSLAM is usually one component of a larger ROS 2 navigation system. Camera-derived motion can be fused with wheel odometry and IMU measurements. The resulting pose estimate can supply the odom to base_link or map to odom transform required by navigation, depending on the selected architecture.

Coordinate frames and state estimation in ROS 2

ROS coordinate conventions are defined by REP 103, while the standard mobile-robot frame relationship is described in REP 105. A UGV navigation stack normally distinguishes the locally continuous odom frame from the globally referenced map frame. vSLAM commonly contributes corrections in the map frame after relocalization or loop closure.

The core pose estimate can be represented as a rigid-body transform:

T_world_camera = [ R  t ]
                 [ 0  1 ]

Here, R is the camera orientation and t is the camera position. The robot base pose is then obtained through the calibrated static transform between the camera frame and base_link. Incorrect camera extrinsics produce systematic navigation errors even when feature tracking is stable.

For ROS 2 integration, the following interfaces are commonly relevant. Their exact topic names are package-specific, but their message definitions are standardized by ROS 2 packages.

Data type Typical ROS 2 message Role in vSLAM
Monocular or RGB image sensor_msgs/msg/Image Feature extraction, tracking, direct alignment, or learned inference.
Camera calibration sensor_msgs/msg/CameraInfo Provides intrinsic parameters and distortion model.
Inertial measurement sensor_msgs/msg/Imu Supports visual-inertial motion estimation and improves robustness during rapid motion.
Wheel odometry nav_msgs/msg/Odometry Provides a motion prior for a wheeled UGV.
Frame transforms tf2_msgs/msg/TFMessage Connects map, odom, base_link, and camera frames through /tf and /tf_static.

Camera configurations and scale observability

The selected camera configuration determines whether translation scale is directly observable. A monocular camera can estimate motion from image geometry, but its scale is not observable from vision alone. Metric scale must therefore come from another source, such as an IMU, wheel odometry, a known target, or external positioning.

Practical vSLAM configurations for mobile robotics include the following options.

  • Monocular vSLAM: uses one camera. It has the lowest sensor count but requires initialization and external scale information for metric navigation.
  • Stereo vSLAM: uses a calibrated camera pair. Depth is inferred from disparity and the known baseline.
  • RGB-D SLAM: uses colour images with per-pixel depth from a depth camera. It is effective indoors where the depth sensor operates within its specified range.
  • Visual-inertial SLAM: jointly estimates motion from images and IMU samples. It requires accurate time synchronization and IMU-to-camera calibration.

Depth cameras and stereo systems simplify metric mapping, but they do not eliminate calibration requirements. The camera optical frame, mounting orientation, timestamp source, and transform to base_link must be consistent with REP 103 conventions and the frame relationships described in REP 105.

vSLAM algorithms used with ROS 2

ROS 2 does not define one mandatory vSLAM algorithm. The choice depends on the camera type, compute budget, scene characteristics, and whether the output must be a sparse landmark map, dense reconstruction, or a navigation-ready pose estimate.

Common algorithm families include the following.

  • Feature-based SLAM: detects and matches keypoints, then optimizes camera poses and landmarks. ORB-SLAM3 supports monocular, stereo, RGB-D, and visual-inertial modes.
  • Direct or semi-direct SLAM: estimates motion from image intensities rather than only discrete features. It can perform well in textured scenes but remains sensitive to exposure changes and motion blur.
  • Visual-inertial optimization: combines image constraints with IMU preintegration. It requires synchronized image and IMU streams.
  • GPU-accelerated visual perception pipelines: can provide visual odometry or mapping on NVIDIA Jetson-class compute units, subject to the supported ROS 2 distribution and package version.

A navigation system should not treat a vSLAM pose as automatically suitable for control. Covariance, transform continuity, delay, map-frame corrections, and loss-of-tracking behaviour must be evaluated before connecting the estimate to Nav2 or another autonomous navigation stack.

Integration on Leo Rover and Raph Rover

Leo Rover uses an onboard Raspberry Pi compute unit and can be used with ROS 2; the supported distribution depends on the installed Leo Rover software image and package versions. Its four-wheel differential drive provides wheel odometry that can be fused with visual and inertial data. vSLAM is not included as autonomous navigation by default. It requires a camera payload, calibration, ROS 2 drivers, and a configured localization and navigation stack.

A minimal ROS 2 system should publish image data, calibration data, static transforms, and robot odometry before the vSLAM node is started. The following command verifies that a camera stream is available.

ros2 topic list
ros2 topic echo --once /camera/camera_info
ros2 run tf2_ros tf2_echo base_link camera_link

Raph Rover is appropriate when the application requires a larger payload capacity for protected sensor enclosures, multiple cameras, an IMU, an edge computer, or a LiDAR used as a complementary localization sensor. It remains necessary to validate camera mounting rigidity, vibration isolation, power delivery, and field-of-view clearance for the intended terrain.

Limitations and validation criteria

vSLAM performance depends on observable image structure. Uniform walls, repetitive corridors, dust, rain, glare, low illumination, rolling-shutter distortion, and wheel-induced vibration can cause tracking degradation or failure. Outdoor UGV deployments also require exposure control because sudden transitions between shade and direct sunlight alter image quality.

Before field deployment, evaluate the system against a reference trajectory or surveyed landmarks. The validation should include the following checks.

  • Camera intrinsic calibration and distortion model validity.
  • Static transform accuracy between camera, IMU, and base_link.
  • Timestamp consistency between image, IMU, and wheel-odometry streams.
  • Pose continuity during loop closure and relocalization.
  • Recovery behaviour after temporary occlusion or tracking loss.

Normative references and primary sources

The following documents define the ROS conventions and technical concepts most relevant to a ROS 2 vSLAM integration.

See also