Glossary

Fictionlab > Glossary > rosbag

rosbag

rosbag – definition

rosbag is the ROS mechanism for recording, storing, inspecting, and replaying data exchanged between ROS nodes. In mobile robotics, a bag file captures a time-ordered record of topic messages such as LiDAR scans, wheel odometry, IMU measurements, camera images, GNSS fixes, TF transforms, and navigation commands.

The term has two related meanings. In ROS 1, rosbag refers to the command-line tool and the ROS bag file format. In ROS 2, the equivalent capability is implemented by the rosbag2 package and accessed through the ros2 bag command. ROS 2 recordings can use different storage back ends, including SQLite3 and MCAP, through storage plugins.

For an unmanned ground vehicle (UGV), rosbag provides reproducible sensor datasets. A developer can record a field run with Leo Rover or Raph Rover, replay the same messages later, and evaluate localisation, SLAM, perception, or navigation behaviour without repeating the physical test.

How rosbag works in ROS 2

In ROS 2, ros2 bag record creates subscriptions to selected topics. Received messages are serialised and written by a storage plugin. Metadata is stored with the recording and can be inspected with ros2 bag info. During playback, ros2 bag play republishes the recorded messages to the ROS graph.

Rosbag records ROS messages at the middleware boundary. It does not directly record raw network packets, operating-system logs, GPIO states, or sensor data that was never published to a ROS topic. The usefulness of a recording therefore depends on the topic architecture of the robot application.

# Record a minimal UGV localisation dataset
ros2 bag record \
  /scan \
  /imu/data \
  /wheel/odometry \
  /tf \
  /tf_static \
  /gps/fix \
  -o leo_field_run

# Inspect the resulting recording
ros2 bag info leo_field_run

# Replay messages and publish /clock
ros2 bag play leo_field_run --clock

When playback publishes /clock, nodes intended for deterministic replay should use ROS time. In ROS 2, this normally requires the use_sim_time parameter to be set to true. Nodes that continue to use system time can produce inconsistent time comparisons during offline analysis.

Relevant UGV topics and message types

A useful rosbag for a mobile robot should include both sensor observations and the state estimates or transforms required to interpret them. Recording only a LiDAR topic, for example, may be insufficient if the transform between the LiDAR frame and base_link is unavailable.

UGV data Typical ROS message type Purpose during replay
2D LiDAR scan sensor_msgs/msg/LaserScan Obstacle detection, 2D SLAM, localisation
IMU sensor_msgs/msg/Imu Orientation and acceleration fusion
Wheel odometry nav_msgs/msg/Odometry Dead reckoning for differential-drive motion
GNSS position sensor_msgs/msg/NavSatFix Global position; validation of RTK-capable GNSS data
Camera image sensor_msgs/msg/Image Computer vision and depth processing
Coordinate transforms tf2_msgs/msg/TFMessage Frame relationships for sensor fusion and navigation

The coordinate-frame tree should follow ROS conventions where applicable. REP 105 defines commonly used mobile-robot frames, including map, odom, and base_link. Static transforms should normally be recorded from /tf_static; dynamic transforms are usually published on /tf.

QoS, timestamps, and data completeness

ROS 2 Quality of Service (QoS) policies affect whether rosbag2 receives a topic. A recorder subscribes as a ROS 2 node and must be compatible with publisher QoS settings. Sensor drivers commonly use a best-effort reliability policy, while state or configuration topics may use reliable delivery. An incompatible subscription can result in missing data even when a topic is visible in the ROS graph.

Before field recording, the integration team should verify the following items:

  • Every required topic has an active publisher and a compatible QoS profile.
  • Message headers contain valid acquisition timestamps where the message definition provides a std_msgs/msg/Header.
  • The recording includes /tf and /tf_static when algorithms require frame transforms.
  • Storage capacity and write throughput are sufficient for the selected image, point-cloud, and sensor topics.
  • Topic names, namespaces, and frame IDs are documented with the dataset.

For image and point-cloud workloads, storage throughput is a practical constraint. A rosbag can contain compressed image topics, raw image messages, point clouds, or both. The selected representation changes CPU load, disk usage, and replay fidelity. The recording configuration should therefore be version-controlled together with the robot software.

Using rosbag on Leo Rover and Raph Rover

Leo Rover is a differential-drive, four-wheel UGV with a Raspberry Pi-based compute unit and ROS 2 support. Rosbag is useful on Leo Rover for collecting repeatable datasets from external LiDAR, IMU, depth camera, or GNSS payloads. The rover does not provide autonomous navigation out of the box, so recordings are commonly used to develop and validate the required localisation and navigation stack.

A typical Leo Rover experiment can record wheel odometry, IMU data, LiDAR scans, TF, and velocity commands. The resulting bag can then be replayed on a development workstation to tune an Extended Kalman Filter, test SLAM parameters, or inspect navigation failures without operating the vehicle again.

Raph Rover is intended for larger payloads and more demanding field integrations. Its rosbag workflow is similar, but a project may additionally record multiple cameras, 3D LiDAR, RTK GNSS, or payload-specific topics. For both platforms, sensor mounting geometry must be represented by correct static transforms. A valid recording cannot compensate for incorrect extrinsic calibration.

ROS 1 and ROS 2 differences

ROS 1 and ROS 2 bag files are not interchangeable by default. ROS 1 commonly uses the ROS bag file format associated with the rosbag tool. ROS 2 uses rosbag2 with pluggable storage and serialisation components. Migration, conversion, or cross-version analysis should be planned explicitly rather than assumed.

ROS 2 also uses DDS-based communication and explicit QoS policies. This makes QoS verification more important than in many ROS 1 recording workflows. The ROS 2 documentation recommends inspecting topics and QoS settings before diagnosing recording or playback gaps.

Normative references and technical documentation

The following primary sources define the ROS interfaces and conventions relevant to rosbag-based UGV datasets:

See also