11 posts tagged with "ros"

ROS 1 Noetic reached end of life in May 2025, but a lot of robots still run on it. Recording data from them usually means rosbag files, or a custom recording node that you have to maintain yourself.

Reduct Bridge is another way to do it. It subscribes to topics on a ROS 1 master and stores each message it receives in ReductStore as a record, so you can query by time and by label later. It can also use the timestamp from the message header instead of the time the message arrived.

In this tutorial we'll record a camera topic and an IMU topic, set a retention limit, and read the data back with the ReductStore CLI and the Python SDK.

ROS2 is widely used for building robotic systems with sensors like cameras, LiDAR, and IMUs. While it's great for communication (e.g., publishing and subscribing to topics), it lacks a built-in solution for storing large amounts of unstructured data, such as images.

Bag files are commonly used to store data in ROS2, but they aren't a good fit for long-term storage or real-time streaming. They're mainly meant for recording and replaying mission data or episodes, not for managing large volumes of unstructured data.

Addressing this challenge, this blog post will guide you through setting up ROS2 with ReductStore a high-performance storage and streaming solution optimized for unstructured, time-series data.

We will focus specifically on image data, but if you are interested in a more general overview you can read How to Store and Manage Robotic Data which covers the challenges and strategies for storing and managing robotic data in general.

For the full code example, we will be using the reduct-ros-example repository, which provides a complete implementation of the concepts discussed in this article.

A rosbag recording is ultimately written to files, and a single file cannot grow forever. Something has to close it at some point, so rosbag2 makes you pick: ros2 bag record -a -b 100000 closes one every 100 kilobytes, or -d 9000 closes one every 9000 seconds. Either way, a recording that runs for hours comes out as a directory of many small files instead of one huge file that becomes awkward to work with.

Splitting a recording into five minute bags seems like a simple solution. The problem starts when you need to turn them back into one file.

A rosbag2 user reported that merging 300 GB of split recordings required roughly 600 GB of disk capacity. The original 300 GB stays on disk while another 300 GB is written out as the merged bag.

Splitting solves one problem. Merging creates another, and it is easy to underestimate.