DEV Community: AnthonyCvn

Air-Gapped Drone Data Operations with Delayed Sync and Auditability

AnthonyCvn — Tue, 24 Feb 2026 00:00:00 +0000

Drones in air-gapped environments produce a lot of data (camera images, telemetry, logs, model outputs). Storing this data reliably on each drone and syncing it to a ground station later can be hard. ReductStore makes this easier: it's a lightweight, time-series object store that works offline and replicate data when a connection is available.

This guide explains a simple setup where each drone stores data locally with labels, replicates records to a ground station based on what it detects, and keeps a clear audit trail of what was captured and replicated.

What we'll cover:

Drone-to-Ground Architecture

The architecture has three main components:

Each drone runs a small ReductStore server to save images and telemetry locally on disk (this lets the drone operate fully offline).
A ground station runs a ReductStore instance that receives replicated data for analysis and archiving.
ReductStore replication tasks copy data from drone to ground based on labels and conditions (e.g., only records flagged as anomalies, plus context around them).

Each drone pushes its data to the ground whenever it is connected. If the network disconnects, replication continues when the drone reconnects. This approach provides offline capability, lets you decide which data to replicate, and keeps a clear record of what happened.

Setting Up the Drone Node

Start by running ReductStore on the drone's companion computer. Here is a minimal docker-compose.yml:

services:
  reductstore:
    image: reduct/store:latest
    ports:
      - "8383:8383"
    environment:
      RS_API_TOKEN: <DRONE_TOKEN>
      RS_BUCKET_1_NAME: mission-data
      RS_BUCKET_1_QUOTA_TYPE: FIFO
      RS_BUCKET_1_QUOTA_SIZE: 10000000000 # 10 GB
    volumes:
      - ./data:/data

Run it with:

docker compose up -d

This starts a ReductStore server with a mission-data bucket that uses FIFO retention. Old data is deleted only when the 10 GB limit is reached, so the drone always keeps as much history as possible.

FIFO quota is volume-based, not time-based. This means data is only deleted when disk space runs out, not after a fixed time period. This is important for drones that may sit idle between missions.

If you prefer Snap instead of Docker:

sudo snap install reductstore

That starts a ReductStore server on port 8383 by default. You can then create the bucket using the Reduct CLI:

reduct-cli alias add drone -L http://localhost:8383 -t "<DRONE_TOKEN>"
reduct-cli bucket create drone/mission-data --quota-type FIFO --quota-size 10GB

Storing Drone Data with Labels

Use labels to tag every record with mission context. This is what makes selective replication and auditing possible later. Here is an example using the Python SDK:

import asyncio
import time
import hashlib
from reduct import Client


async def main():
    async with Client("http://localhost:8383", api_token="<DRONE_TOKEN>") as client:
        bucket = await client.get_bucket("mission-data")

        # Read a camera frame
        payload = open("frame.jpg", "rb").read()
        checksum = hashlib.sha256(payload).hexdigest()
        timestamp = int(time.time() * 1_000_000)  # microseconds

        # Write with mission labels
        await bucket.write(
            "camera",
            payload,
            timestamp=timestamp,
            labels={
                "mission_id": "m-2026-02-24-01",
                "platform_id": "uav-07",
                "anomaly": "false",
                "confidence": "0.95",
                "checksum": checksum,
            },
            content_type="image/jpeg",
        )

        # Write telemetry as a CSV batch
        csv_data = "ts,lat,lon,alt,speed\n"
        csv_data += "1708771200000000,47.3769,8.5417,450.2,12.5\n"
        csv_data += "1708771201000000,47.3770,8.5418,451.0,12.8\n"

        await bucket.write(
            "telemetry",
            csv_data.encode(),
            timestamp=timestamp,
            labels={
                "mission_id": "m-2026-02-24-01",
                "platform_id": "uav-07",
                "anomaly": "false",
                "checksum": hashlib.sha256(csv_data.encode()).hexdigest(),
            },
            content_type="text/csv",
        )


asyncio.run(main())

The anomaly label is important: it lets the replication task decide what to sync based on what the drone actually sees. For example, if the drone detects something unusual (an object, a warning, a low confidence score), it sets anomaly=true. The replication task can then automatically sync that record — plus the context around it.

The checksum label gives you a simple way to verify data integrity during audits.

Setting Up Selective Replication

Once the drone connects to a trusted network, replication sends only the relevant records to the ground station. The simplest approach is to replicate based on a label, for example only records where the drone detected an anomaly:

reduct-cli alias add drone -L http://localhost:8383 -t "<DRONE_TOKEN>"

reduct-cli replica create drone/mission-to-ground \
    mission-data \
    https://<GROUND_TOKEN>@<ground-address>/drone-data \
    --when '{"&anomaly": {"$eq": "true"}}'

This creates a replication task that copies only records where anomaly=true from the drone's mission-data bucket to the ground station.

Replicating with context (before and after)

In many cases, you don't just want the anomaly record itself — you also want to see what happened before it. ReductStore supports this with the #ctx_before and #ctx_after directives. For example, to replicate each anomaly record plus 30 seconds of data before it and 10 seconds after:

{
  "&anomaly": { "$eq": "true" },
  "#ctx_before": "30s",
  "#ctx_after": "10s"
}

This is powerful for drone operations: imagine the drone's onboard model detects an unexpected object. ReductStore will replicate that record and the 30 seconds of camera frames leading up to the detection, so the ground team can review what happened.

You can provision this directly in Docker using environment variables:

services:
  reductstore:
    image: reduct/store:latest
    ports:
      - "8383:8383"
    environment:
      RS_API_TOKEN: <DRONE_TOKEN>
      RS_BUCKET_1_NAME: mission-data
      RS_BUCKET_1_QUOTA_TYPE: FIFO
      RS_BUCKET_1_QUOTA_SIZE: 10000000000
      RS_REPLICATION_1_NAME: mission-to-ground
      RS_REPLICATION_1_SRC_BUCKET: mission-data
      RS_REPLICATION_1_DST_BUCKET: drone-data
      RS_REPLICATION_1_DST_HOST: https://<ground-address>
      RS_REPLICATION_1_DST_TOKEN: <GROUND_TOKEN>
      RS_REPLICATION_1_WHEN: |
        {
          "&anomaly": { "$$eq": "true" },
          "#ctx_before": "30s",
          "#ctx_after": "10s"
        }
    volumes:
      - ./data:/data

With this setup, the drone can operate fully offline. Replication runs automatically when a connection is available and waits when it's not. It's also possible to pause replication tasks if needed. And because context is included, the ground team always has enough data to understand what triggered the event.

Querying for Audit Reports

After a mission, you can query the ground station to check what was captured and replicated. Here is a simple example that lists all records from a specific mission:

import asyncio
from reduct import Client


async def main():
    async with Client("https://<ground-address>", api_token="<GROUND_TOKEN>") as client:
        bucket = await client.get_bucket("drone-data")

        # Query all camera records from a specific mission
        async for record in bucket.query(
            "camera",
            when={"&mission_id": {"$eq": "m-2026-02-24-01"}},
        ):
            print(
                f"ts={record.timestamp}, "
                f"anomaly={record.labels.get('anomaly')}, "
                f"checksum={record.labels.get('checksum')}, "
                f"size={record.size}"
            )


asyncio.run(main())

This gives you a clear log of every record in that mission: timestamp, anomaly flag, checksum, and size. You can use this to verify that all expected data arrived on the ground side.

To go further, compare the checksums on the drone with the ground side to confirm nothing was altered during transfer. You can also check the error logs of the replication task to see if any records failed to replicate.

Why This Setup Works Well for Drones

Drones have specific constraints that general purpose databases don't handle well. Here is what makes this setup practical:

Full offline operation. Drones store everything locally and don't need a network connection during the mission. Data is safe on disk until sync happens.
Automatic sync when connected. When the drone lands or connects to a trusted network, replication picks up where it left off. No manual file transfers, no rsync scripts, no USB sticks.
Smart replication with context. You don't have to sync everything. The replication task filters by labels and can include past records around each event using #ctx_before. The ground team gets exactly what they need to understand what happened.
Disk never fills up unexpectedly. FIFO retention removes the oldest data only when the disk is full. The drone always keeps as much history as possible without running out of space mid mission.
Easy auditing. Every record has a timestamp, labels, and a checksum. After a mission, you can query the ground station and verify exactly what was captured and what was synced.
Store any file type. Camera frames, telemetry CSV, logs, MCAP files, model outputs. Everything goes into the same system with the same interface.

Next Steps

If you want to go deeper, check out these articles:

Distributed Storage in Mobile Robotics for a similar setup with mobile robots and S3 cloud backend
How to Store and Manage Robotics Data for a broader look at ReductStore features for robotics
Data Replication Guide for the full documentation on replication tasks, filters, and modes
Conditional Query Reference for all available conditional query operators you can use in replication filters and queries

I hope you found this article helpful! If you have any questions or feedback, don't hesitate to reach out on our ReductStore Community forum.

Comparing Data Management Tools for Robotics

AnthonyCvn — Thu, 04 Dec 2025 09:26:57 +0000

Modern robots collect a lot of data from sensors, cameras, logs, and system outputs. Managing this data well is important for debugging, performance tracking, and training machine learning models.

Over the past few years, we've been building a storage system from scratch. As part of that work, we spoke with many robotics teams across different industries to understand their challenges with data management.

Here's what we heard often:

Only a subset of what robots generate is actually useful
Network connections are not always stable or fast
On-device storage is limited (hard drive swaps is not practical)
Teams rely on manual workflows with scripts and raw files
It's hard to find and extract the right data later
ROS bag files get large quickly and are difficult to manage

In this article, we compare four tools built to handle robotics data: ReductStore, Foxglove, Rerun, and Heex. We look at how they work, what they're good at, and which use cases they support.

If you're working with robots and need to organize, stream, or store data more effectively, this overview should help.

Key Criteria for Comparison

When picking a data tool for robotics, focus on these areas:

Data Types Robotics is a large field with many sensor types. The tool should support the data you work with, such as:
- Telemetry: Lightweight (GPS, IMU, joints), ideal for monitoring.
- Downsampled Data: Lower-rate images or lidar for incident review without high storage cost.
- Full-Resolution: Raw sensor outputs for deep debugging or training. This is storage-intensive but essential for some applications.
Integration The tool should work with what you already use, like ROS, Grafana, MQTT, cloud platforms (S3, Azure, Google Cloud), and your development environment to avoid extra glue code and simplify workflows.
Performance and Scalability Data must move quickly (both locally and to the cloud). Large files or slow queries can block robots or delay analysis.
Ease of Use and APIs A simple UI and solid API support make it easier to automate, scale, and adapt the tool to different use cases.

Tool Overviews

ReductStore

ReductStore is a storage and streaming system designed for robotics data. It works both on the robot and in central storage (on-premise/self-hosted or in the cloud) with the same interface and SDKs (in Python, C++, Go, Javascript/TypeScript or Rust). That means your code stays the same whether you're reading local, remote data (or creating a browser-based dashboard).

To move data to the cloud, ReductStore uses conditional replication. You can define rules to upload only certain records: by label, rules, or event. For example, replicate all incident data, or just 1 out of 10 entries for routine monitoring.

ReductStore handles storage limits on edge devices with FIFO retention. Old data is deleted only when the device is full. Each bucket can have different rules, so you can keep more images and less telemetry, for example.

With an S3 backend, ReductStore batches small records together before uploading. This cuts down the number of requests and lowers cloud storage costs. For observability, you can connect Grafana to ReductStore to create dashboards with system metrics and sensor data. For MCAP files, ReductStore supports shareable query links that open directly in Foxglove v1/v2.

It also lets you filter or merge records server-side. For example, you can pull all temperature readings above a threshold over a time range without downloading full datasets.

Want more technical detail? Check out The Missing Database for Robotics Is Out.

Foxglove and MCAP

Foxglove is a browser-based visualization and observability tool for robotics. It supports ROS 1, ROS 2, and MCAP logs, and handles data types like telemetry, camera feeds, lidar, and depth maps.

It uses MCAP, an open-source log format built for robotics, to store high-resolution data efficiently. You can explore MCAP files interactively in Foxglove Studio or stream them programmatically.

Foxglove provides an agent that detects new MCAP files on the robot and uploads them to the cloud automatically. This requires robots to record short rosbag segments (typically a few minutes each) which are closed and rotated continuously.

It integrates natively with ROS topics, services, and actions, and offers WebSocket and REST APIs. It also connects to major cloud providers like AWS, Azure, and Google Cloud for scalable storage.

The interface is built for time-series and sensor data, with interactive 2D/3D views, plots, and drag-and-drop panels for quick setup and review.

Rerun

Rerun is an open-source visualization solution for time-series and multimodal data. It supports data types like images, point clouds, lidar, depth maps, tensors, and other sensor streams.

Its main strength is combining flexible logging with a fast, built-in 3D viewer designed for robotics and extended reality (XR) applications. For large datasets, Rerun provides a column-oriented API to speed up ingestion and reduce memory usage. It also uses efficient internal structures to minimize allocations and optimize performance on edge devices.

Rerun doesn't offer native ROS integration yet, but it can be used in ROS projects by adding custom logging to nodes.

You can embed Rerun in Jupyter notebooks or web pages, and use loggers for Python, Rust, and C++ to stream data into the viewer.

The UI is built for real-time 3D exploration, with overlays and live tracking that make it easy to inspect different data types in the same visual space.

Heex

Heex is a data capture and review platform for autonomous systems that focuses on collecting only key moments—like errors or specific events instead of logging everything. This reduces bandwidth and storage needs while keeping important context.

Robots using Heex record data continuously in short ROSbag segments. A small agent on the robot watches for triggers and uploads only selected segments to the cloud based on rules.

A core feature is RDA (Resource and Data Automation) for ROS 2, which automates what to record and when. Rules can be changed remotely without restarting the robot.

Data is stored in ROSbag and can be reviewed directly in the Heex dashboard, which includes built-in open-source version of Foxglove. This setup makes it easy to manage data across fleets and locations.

Heex supports both ROS 1 and ROS 2, and integrates with other systems through SDKs, APIs, and a CLI.

The interface includes customizable dashboards to monitor sensor data, errors, and system status. Timelines and streams are easy to navigate for quick analysis.

Comparative Analysis Table

To help visualize the differences between the tools, here is a comparison table summarizing their main characteristics:

Tool	Core Focus	Data Types	Storage Strategy	Visualization	ROS Integration	Unique Features
ReductStore	Time-series storage and streaming for robotics	Telemetry, camera images, lidar, logs	Local + cloud with same API (supports S3, FIFO retention, conditional replication)	Grafana, Foxglove (via MCAP links)	Integrated with ROS via extensions	Filter/merge on server, batch uploads, topic-level control, efficient on edge
Foxglove	Visualization and observability for robotics logs	MCAP logs (telemetry, lidar, camera, depth)	ROSbag short segments, auto-upload with agent	Foxglove Studio (2D/3D, timeline, plots)	Native ROS 1 & 2	Drag-and-drop views, real-time stream inspection, cloud integration
Rerun	Real-time 3D visualization of multimodal time-series data	Images, lidar, point clouds, tensors, metrics	User-defined logging; logs streamed into viewer or embedded in notebooks	Built-in viewer (3D overlays, tracking)	Not native (custom logging)	Column-oriented API, fast ingestion, selective logging, notebook/web integration
Heex	Event-driven data capture for fleets of robots	ROSbag (telemetry, images, lidar, metrics)	Continuous recording, uploads filtered by event-based rules via onboard agent	Built-in Foxglove in dashboard	Native ROS 1 & 2	RDA (automated capture rules), remote config, scalable fleet-wide dashboards

Conclusion

Each tool addresses a different part of the robotics data workflow. ReductStore is ideal for distributed storage across many robots, with selective replication to the cloud and flexible integration with tools like Grafana and Foxglove. Foxglove excels at visualizing MCAP logs and ROS topics. Rerun offers flexible, real-time 3D inspection for custom applications. Heex focuses on capturing just the important moments for efficient fleet analysis.

Choosing the right tool depends on what kind of data you collect, how you process it, and where you need it to go. In many cases, combining tools can give you the best of all worlds.

Thanks for reading. I hope this article helps you decide on the right storage strategy for your vibration data.
If you have questions or comments, feel free to visit the ReductStore Community Forum.

Distributed Storage in Mobile Robotics

AnthonyCvn — Mon, 17 Nov 2025 00:00:00 +0000

Mobile robots produce a lot of data (camera images, IMU readings, logs, etc). Storing this data reliably on each robot and syncing it to the cloud can be hard. ReductStore makes this easier: it's a lightweight, time-series object store built for robotics and industrial IoT. It stores binary blobs (images, logs, CSV sensor data, MCAP, JSON) with timestamps and labels so you can quickly find and query them later.

This introduction guide explains a simple setup where each robot stores data locally and automatically syncs it to a cloud ReductStore instance backed by Amazon S3.

Edge-to-Cloud Architecture

The architecture has three main components:

Each robot runs a small ReductStore server in order to save images and IMU data locally on disk (this let the robot operate offline).
A cloud ReductStore instance runs on a server (e.g., EC2) and uses S3 for long-term storage.
ReductStore replication tasks copies data from robot to cloud based on labels, events, or rules (e.g., 1 record every minute).

Each robot pushes its data to the cloud whenever it is connected to the network. This approach provides the robots with offline capability, allows you to decide which data to replicate, and easily scales to support many robots.

How Replication Works

ReductStore uses an append-only replication model:

The robot stores new data locally.
ReductStore automatically detects new records.
It sends them to the cloud in batches (or streams large files).
If the network disconnects, replication continues when the robot reconnects.

You can replicate:

everything
or only specific sensors
or only records with certain labels
or based on rules (e.g., 1 record every S seconds or every N records)

This can be configured per robot using environment variables (provisioning), with the web console or via the CLI (as shown in this guide).

Cloud ReductStore With S3 Backend

ReductStore supports storing all records directly in S3. It keeps a local cache for fast access and batches many small blobs into larger blocks to save on S3 costs.

By batching data into S3 objects, you can save significantly on storage costs compared to storing many small files individually.

Here is an example docker-compose.yml to run a ReductStore server that uses S3 as the remote backend and provisions buckets for robots:

services:
  reductstore:
    image: reduct/store:latest
    container_name: reductstore
    ports:
      - "8383:8383"
    environment:
      # AWS credentials and S3 bucket configuration
      RS_REMOTE_BACKEND_TYPE: s3
      RS_REMOTE_BUCKET: <YOUR_S3_BUCKET_NAME>
      RS_REMOTE_REGION: <YOUR_S3_REGION>
      RS_REMOTE_ACCESS_KEY: <YOUR_AWS_ACCESS_KEY_ID>
      RS_REMOTE_SECRET_KEY: <YOUR_AWS_SECRET_ACCESS_KEY>
      RS_REMOTE_CACHE_PATH: /data/cache
      # Bucket provisioning
      RS_BUCKET_ROBOT_1_NAME: robot1-data
      RS_BUCKET_ROBOT_2_NAME: robot2-data
      # .. additional buckets as needed
    volumes:
      - ./cache:/data/cache

Run it with:

docker compose up -d

This starts a ReductStore server that writes to S3 automatically. There are many more configuration options available in the configuration documentation.

Setting Up Replication

First spin up a local ReductStore on each robot. Here with Snap:

sudo snap install reductstore

That starts a ReductStore server on port 8383 by default. Then you can use the Reduct CLI to set up replication from the robot to the cloud instance:

# Point the CLI to the robot's local ReductStore
reduct-cli alias add local -L http://localhost:8383 -t "<ROBOT_API_TOKEN>"

# Create a bucket for that robot
reduct-cli bucket create local/robot1-data

# Create a replication task to the cloud
reduct-cli replica create local/robot1-to-cloud \
    robot1-data \
    https://<CLOUD_API_TOKEN>@<cloud-address>/robot1-data

This creates a replication task called robot1-to-cloud that copies all data from the robot's local robot1-data bucket to the cloud instance. You can customize replication further by adding filters or rules. See the replication guide for more details.

Storing Sensor Data

There are many ways to store data. When it comes to high-frequency sensor data like IMU readings, a common approach is to store them in 1-second files. Images can be stored as binary blobs (e.g., JPEG or PNG files). Here is an example of storing IMU data as CSV files and images as binary blobs using the Python SDK (this stores 10,000 samples and one camera image for a given timestamp as an example):

import asyncio
import time
import random
from reduct import Client


async def main():
    async with Client("http://localhost:8383", api_token="<ROBOT_API_TOKEN>") as client:
        bucket = await client.get_bucket("robot1-data")

        # Current timestamp to index the data by time in ReductStore
        timestamp = int(time.time() * 1_000_000)  # microseconds

        # Generate 10'000 IMU samples
        rows = []
        for i in range(10_000):
            rows.append(
                {
                    "ts": timestamp + i * 100,  # microseconds
                    "linear_acceleration_x": round(random.uniform(-2, 2), 3),
                    "linear_acceleration_y": round(random.uniform(-2, 2), 3),
                    "linear_acceleration_z": round(random.uniform(8.0, 10.0), 3),
                }
            )

        # Convert to CSV (store 1 seconds of data per file)
        csv = (
            "ts,linear_acceleration_x,linear_acceleration_y,linear_acceleration_z\n"
            + "\n".join(
                f"{r['ts']},{r['linear_acceleration_x']},"
                f"{r['linear_acceleration_y']},{r['linear_acceleration_z']}"
                for r in rows
            )
        )

        # Write the IMU batch
        await bucket.write(
            entry_name="imu_logs",
            data=csv.encode(),
            timestamp=timestamp,
            labels={"sensor": "imu", "rows": "1000"},
            content_type="text/csv",  # MIME type
        )

        # Write one camera image
        with open("camera_image.png", "rb") as img:
            await bucket.write(
                entry_name="images",
                data=img.read(),
                timestamp=timestamp,
                labels={"sensor": "camera"},
                content_type="image/png",
            )


asyncio.run(main())

If you are considering storing all IMU data as individual records in a time series database (TSDB) like Timescale or InfluxDB, keep in mind that high-frequency sensors (e.g., 1000 Hz) can lead to performance and cost issues. Batching samples into files (e.g., one second of data per CSV file) is a more efficient storage and querying method.

Querying Sensor Data Using ReductSelect

If your IMU data is stored as CSV, the ReductSelect extension lets you:

extract only certain columns
filter rows based on conditions

Example: filter CSV rows where acc_x > 10:

{
    "#ext": {
        "select": {
            "csv": {"has_headers": True},
            "columns": [
                {"name": "ts", "as_label": "ts_ns"},
                {"name": "linear_acceleration_x", "as_label": "acc_x"},
                {"name": "linear_acceleration_y"},
                {"name": "linear_acceleration_z"},
            ],
        },
        "when": {"@acc_x": {"$gt": 1.9}},
    }
}

Python example:

import asyncio
from reduct import Client

when = { ... } # the JSON condition from above

async def main():
    async with Client("https://<cloud-address>", api_token="<TOKEN>") as client:
        bucket = await client.get_bucket("robot1-data")

        async for rec in bucket.query("imu_logs", when=when):
            data = await rec.read_all()
            print(data.decode())

asyncio.run(main())

This returns only the rows where linear_acceleration_x > 1.9, along with the timestamp.

Why This Setup Works Well for Robotics

There are several advantages to using a specialized storage solution like ReductStore for mobile robotics:

Robots can store data locally and operate offline without network connectivity.
Automatic replication when connected to avoid manual uploads and simplify data management.
Selective replication lets you control what data is sent to the cloud (i.e. decide on your reduction strategy) to save bandwidth and storage.
Labels and timestamps make it easy to organize and query sensor data later.
Store files of any type (images, CSV, logs, MCAP) in a single system without needing separate storage solutions for each data type.

Next Steps

ReductStore also integrates into robotics observability stacks such as the Canonical Observability Stack (COS) for robotics. You can visualize sensor data, logs, and metrics in Grafana dashboards alongside your other robot telemetry. More details in our blog post The Missing Database for Robotics Is Out.

I hope you found this article helpful! If you have any questions or feedback, don't hesitate to reach out on our ReductStore Community forum.

The Missing Database for Robotics Is Out

AnthonyCvn — Wed, 22 Oct 2025 00:00:00 +0000

Robotics teams today wrestle with data that grows faster than their infrastructure. Every robot generates streams of images, sensor readings, logs, and events in different formats. These data piles are fragmented, expensive to move, and slow to analyze. Teams often rely on generic cloud tools that are not built for robotics. They charge way too much per gigabyte (when it should cost little per terabyte), hide the raw data behind proprietary APIs, and make it hard for robots (and developers) to access or use their own data.

ReductStore introduces a new category: a database purpose built for robotics data pipelines. It is open, efficient, and developer friendly. It lets teams store, query, and manage any time series of unstructured data directly from robots to the cloud.

What Makes It a New Category

ReductStore treats robotics with the respect it deserves. It captures everything in its raw form and stores it with a time index and labels for flexible querying and management. It ingests and streams any type of data (images, sensor frames, logs, MCAP files, CSVs, JSON, etc) without forcing developers to convert or reformat it.

It works on robots and in the cloud using the same interface and SDKs (Python, C++, Rust, Javascript, Go). This means developers can build data pipelines that run the same way on robots or in the cloud without needing to change code or learn new tools.

Developers can run ReductStore on an edge device for local data capture and replicate to a cloud instance (with S3 backend) for cloud analytics or archiving.

It is the first and only database designed specifically for unstructured, time series robotics data.

Data Handling and Querying

Developers can work directly with data using simple queries and SDKs. The focus is speed and flexibility.

1. MCAP topic filtering

You can filter topics directly from multiple MCAP files stored in ReductStore without needing to download and reprocess everything locally.

import json
import pandas as pd
from reduct import Client

# Extract only the IMU topic from MCAP files
ext = {
    "ros": {"extract": {"topic": "/imu/data"}},
}

async with Client("https://test.reduct.store") as client:
    bucket = await client.get_bucket("my-robotics-data")
    parts = []
    async for rec in bucket.query("mcap-entry", ext=ext):
        blob = await rec.read_all()
        data = json.loads(blob.decode("utf-8"))
        rows = [
            {
                "ts": data["header"]["stamp"]["sec"] * 1_000_000_000
                + data["header"]["stamp"]["nanosec"],
                "linear_acceleration_x": data["linear_acceleration"]["x"],
                "linear_acceleration_y": data["linear_acceleration"]["y"],
                "linear_acceleration_z": data["linear_acceleration"]["z"],
            }
        ]

This allows you to extract only the relevant topics from multiple bags. In this example, we extract only the IMU topic as a stream of JSON records, which would look like this:

ts	linear_acceleration_x	linear_acceleration_y	linear_acceleration_z
1633024800000	0.1	0.3	-9.8
1633024801000	0.0	0.1	-9.7
...	...	...	...

2. CSV/JSON field extraction and filtering

You can extract specific JSON fields or CSV columns when querying data. This lets you select only the information you need, for example, filtering and visualizing certain fields from streams of JSON or CSV sensor readings.

import io
import pandas as pd
from reduct import Client

# Select specific CSV columns and filter rows
ext = {
    "select": {
        "csv": {"has_headers": True},
        # Use "json": {}, for JSON data
        "columns": [
            {"name": "ts"},
            {"name": "linear_acceleration_x", "as_label": "acc_x"},
            {"name": "linear_acceleration_y"},
            {"name": "linear_acceleration_z"},
        ],
    },
    "when": {"$gt": [{"$abs": ["@acc_x"]}, 10]},
}

async with Client("https://test.reduct.store") as client:
    bucket = await client.get_bucket("my-robotics-data")

    # Loop over filtered CSV entries
    async for rec in bucket.query("csv_sensor_readings", ext=ext):
        blob = await rec.read_all()
        csv_data = pd.read_csv(io.BytesIO(blob))

The tabular result will only include the selected columns and rows that match the filter abs(linear_acceleration_x) > 10:

ts	linear_acceleration_x	linear_acceleration_y	linear_acceleration_z
1633024800000	12.5	0.3	-9.8
1633024801000	-15.2	0.1	-9.7
...	...	...	...

3. Query any type of data

ReductStore automatically batches small records and streams large ones for efficient storage and access. You can query any type of data, from lightweight telemetry to high-resolution images or point clouds, efficiently.

import io
from PIL import Image
from reduct import Client

# Every 5 seconds, limit to 5 records
when = {"$each_t": "5s", "$limit": 5}

async with Client("https://test.reduct.store") as client:
    bucket = await client.get_bucket("my-robotics-data")
    async for rec in bucket.query("camera_frames", when=when):
        blob = await rec.read_all()
        img = Image.open(io.BytesIO(blob))

The example above retrieves camera frames at 5-second intervals. You can then process or visualize these images as needed.

4. Browse petabytes of data

ReductStore is designed to handle massive volumes of data. Its indexing and storage architecture allows you to efficiently browse data at scale without downloading everything locally.

For example, you can quickly navigate records and preview your data directly in the ReductStore web console, even when working with petabytes of robotics data.

info

You can build custom applications on top of ReductStore using its SDKs for Python, C++, Rust, Javascript, and Go. This makes it easy to build data pipelines, dashboards that works in the browser, or integrate with existing tools.

Cloud Integration and Cost Savings

ReductStore connects robots and the cloud in a simple and flexible way. It works with S3-compatible storage and includes a robust replication system to transfer data from robots to the cloud (even when the network is unstable or intermittent), making it perfect for field robots that often go offline.

Replication tasks can be configured to replicate only specific data based on labels or any criteria (for example, only replicate data when the confidence score is below a threshold, or replicate everything from a 10-minute window around a specific event ).

In the cloud, by batching multiple records into single data blocks, ReductStore minimizes both the number of blobs and the number of API calls to S3. This design reduces storage and retrieval costs by leveraging S3's pricing model.

This approach can deliver major savings when working with large volumes of robotics data.

Observability Stack Integration

ReductStore works with the tools robotics engineers already trust.

Foxglove Studio

Foxglove is an amazing tool for visualizing robotics data and debugging robots for the MCAP format.

To share data from ReductStore to Foxglove, you can use the ReductStore web console (or the SDKs) to generate a query link that Foxglove can open directly.

You can then paste the query link into Foxglove Studio to visualize the data.

Grafana

Grafana is a popular open-source tool for creating dashboards and visualising time-series data. You can connect Grafana to ReductStore using the ReductStore data source plugin, which allows you to query and visualise data stored in ReductStore.

You can query data using labels, for example, localization coordinates, object detected, confidence score, etc:

Or you can query based on content, such as JSON files with sensor readings or other structured data:

Canonical Observability Stack (COS)

Canonical's COS (Canonical Observability Stack) for robotics is an end to end observability framework built on open source tools such as Prometheus, Loki, Grafana, and Foxglove.

The missing piece in this stack has always been a purpose built system for storing and managing robotics data efficiently from robot to cloud.

ReductStore closes that gap. It provides a data storage and streaming solution optimized for both edge and cloud environments, along with an agent that captures data directly from ROS and streams it into the observability pipeline.

Closing Thoughts

Robotics teams no longer need to choose between control and convenience. ReductStore gives full ownership of data from robot to cloud. It removes vendor lock, cuts cost, and keeps everything observable and connected. It is the new foundation for robotics data infrastructure (the missing database for robotics).

If you are interested to compare ReductStore with other databases (like MongoDB or InfluxDB), you can read our white paper that goes deeper into the architecture and design choices.

I hope you found this article helpful! If you have any questions or feedback, don't hesitate to reach out on our ReductStore Community forum.

Comparing Robotics Visualization Tools: RViz, Foxglove, Rerun

AnthonyCvn — Tue, 15 Jul 2025 00:00:00 +0000

In robotics development, effective visualization and analysis tools are essential for monitoring, debugging, and interpreting complex sensor data. Platforms like RViz, Foxglove, and Rerun play a key role at the visualization layer of the observability stack. They help developers interact with both live and recorded data. These tools rely on timely, well-structured access to the underlying data streams. That's where ReductStore comes in. It handles the data logging, storage, and processing, with a focus on capturing high-volume time-series data efficiently. ReductStore aims to integrate with tools like RViz, Foxglove, and Rerun, supporting a complete observability pipeline: from raw data ingestion to actionable insights.

Each visualization platform has its unique role in the development workflow. RViz (ROS Visualization) is the classic 3D visualization tool built for the ROS ecosystem, widely used for real-time robot monitoring and debugging. Foxglove is a modern data visualization and inspection platform for robotics and physical AI systems, aiming to simplify how teams collect, visualize, analyze, and manage large volumes of diverse sensor data. Rerun is a lightweight, native desktop application focused on fast and efficient visualization of robotics data, enabling developers to quickly explore and debug both live and recorded sensor streams with minimal setup.

This article compares RViz, Foxglove, and Rerun across key criteria: pricing, cross-platform support, remote collaboration, user interface, extensibility, ROS integration, performance with large datasets, and visualization and analysis features. The goal is to help robotics developers choose the right tool for their specific needs.

Pricing

RViz and RViz 2 are part of the ROS ecosystem and released under the BSD 3-Clause License. This permissive open-source license allows free use, modification, and redistribution (including for commercial purposes), as long as the original copyright and license notices are preserved.

Foxglove offers a free tier that includes core features for up to 3 users, 10 devices, and 10 GB of cloud storage. For larger teams or needs (e.g., extra users, storage, private extensions, enterprise integrations), paid subscriptions are available. Pricing is based on the number of users and storage volume, as well as usage and support level. There is also a free academic plan for qualified institutions, which includes more users and storage. Foxglove itself is proprietary software, though it is built on open protocols like MCAP and integrates with open-source ROS tools.

Rerun is fully open-source under both the MIT and Apache 2.0 licenses. There are no current paid plans for the open-source core. The project follows an open-core model: the core visualizer and SDK are free, while a commercial platform is in early access for teams needing cloud-based storage, collaboration tools, advanced analytics, and scalable CI/CD workflows. This commercial layer is designed to build on top of the open-source foundation.

Platform & Collaboration

RViz and RViz 2 are primarily developed for Linux, where they offer the most stable and reliable performance. RViz 2 also supports Windows and macOS as part of ROS 2, but these versions are less mature and less commonly used. They often require manual setup or compilation, though support continues to improve with newer ROS 2 releases.

Both RViz versions are local desktop applications and are not designed for remote or multi-user use out of the box. Workarounds like SSH with X11 forwarding, VNC, or running RViz locally while connecting remotely to a ROS system are possible, but they are often fragile, require manual configuration, and may suffer from performance or latency issues depending on the network and hardware.

To address these limitations, early tools like ROS3D.js offered browser-based ROS 1 visualization, but they are now mostly unmaintained and incompatible with ROS 2. Modern web visualization is typically done with tools like Foxglove, Webviz, or custom WebSocket-based interfaces. Some cloud robotics platforms also offer remote ROS visualization, though they typically require extra integration work.

Foxglove runs on Windows, macOS, and Linux, available both as a native desktop app and in a web browser. This gives users the flexibility to work locally or remotely without installing software. The browser version supports multi-user collaboration, allowing teams to share layouts and stream live data securely in real time from any internet-connected device.

Rerun is a lightweight native desktop application for Windows, macOS, and Linux. It requires minimal setup and enables developers to quickly visualize and debug live or recorded sensor data without needing a browser or complex configuration. Although Rerun does not support multi-user or collaborative features, teams often share log files for offline review. This approach is usually more practical than using remote desktop tools. Rerun also integrates well into development workflows, such as Python environments, which typically require installing Rerun's SDKs and dependencies.

Note : All three tools support sharing of recorded data, such as rosbag files for RViz & Rviz 2 (.bag for ROS 1 and .db3, .mcap for ROS 2), .mcap files for Foxglove, and .rrd for Rerun. To support these workflows at scale, you can use ReductStore solutions to manage continuous recording, indexing, and long-term storage of these file types across teams and infrastructure.

User Interface

RViz and RViz 2 have a powerful but somewhat dated interface that focuses more on functionality than modern design. The learning curve can be steep, especially for beginners, due to the complex layout and the need to manually configure displays, topics, coordinate frames, and tools. The interface is built around multiple panels and dialogs that require careful configuration. It lacks the visual polish and streamlined workflows of newer visualization tools.

Foxglove features a modern, user-friendly interface with flexible dashboards and responsive controls. It is designed to be accessible to users at all experience levels, making it easier to explore, analyze, and share robotics data. The interface relies heavily on graphical elements instead of commands or configuration files, which lowers the entry barrier for users unfamiliar with ROS or robotics tools.

Rerun offers a clean and straightforward interface focused on efficient data visualization. It balances ease of use with core functionality, providing easy-to-navigate views without overwhelming users. The interface requires minimal setup and supports intuitive exploration of data streams and logs. However, it currently has fewer customization options than RViz or Foxglove.

Extensibility

RViz (both ROS 1 and ROS 2) supports extensibility through C++ plugins, allowing users to develop and integrate custom visualizations, tools, and panels. This plugin architecture makes RViz highly adaptable across robotics domains such as perception, navigation, and manipulation. Many ROS packages include their own RViz plugins by default. However, developing and using plugins requires tight integration with the specific ROS environment. Plugins made for RViz in ROS 1 are not directly compatible with RViz 2; they often require modification or a complete rewrite.

Foxglove offers extensibility through an Extensions SDK, which allows developers to build React-based visualizations using TypeScript. Extensions can be shared via an online registry and do not require recompilation. Foxglove also provides APIs and libraries in C++, Python, and Rust, primarily for working with the MCAP file format, enabling integration with ROS (both versions), WebSocket streams, and recorded sensor data. Foxglove's ecosystem also supports integration with popular robotics and simulation tools such as NVIDIA Isaac Sim, Velodyne LiDAR, and Jupyter Notebooks, either directly or via external bridges.

Rerun focuses on extensibility through SDKs and APIs, especially for Python and other programming environments. It does not support plugin-based customization or drag-and-drop extensions like RViz or Foxglove. Instead, it prioritizes programmatic data embedding and visualization, making it well-suited for users who prefer scripting and code-driven workflows.

Rerun offers strong Python support, but its core is built with Rust and the egui GUI framework — technologies less familiar to many robotics developers. This can introduce a learning curve and limit low-level customization unless users are comfortable with Rust.

Rerun does not offer a simple or dynamic plugin system or scripting layer similar to RViz's C++ plugins or Foxglove's TypeScript extensions. This limits rapid prototyping or quick third-party integration.

Still, its APIs offer robust integration with diverse data sources, including ROS topics, sensor streams, and machine learning frameworks like TensorFlow and PyTorch. This makes Rerun a flexible tool for logging, visualizing, and debugging complex data pipelines.

Rerun is best suited for developers who prefer programming-driven customization over GUI-based tools. It provides direct control over data ingestion and visualization, enabling highly tailored, dynamic workflows that can grow with project needs.

ROS Integration

RViz is tightly integrated with ROS and supports direct interaction with live ROS topics. Originally developed for ROS 1, it was succeeded by RViz 2 for ROS 2, and it remains a core visualization tool in many robotics workflows. However, this deep integration limits RViz's usability outside the ROS ecosystem. Both versions depend on a fully functioning ROS environment and are not designed to run independently or handle non-ROS data without conversion.

Foxglove connects to live ROS systems using foxglove_bridge, a WebSocket-based bridge designed for this purpose. It runs on the same network as the ROS system and streams real-time ROS messages to Foxglove over WebSocket. This architecture allows remote monitoring and interaction with installing ROS locally. Unlike RViz, Foxglove can be used without a full ROS setup.

In addition to live data, Foxglove also supports opening and analyzing ROS bag files locally. This makes it easy to review recorded data, visualize topics, and troubleshoot issues offline, without needing an active ROS system.

Rerun supports integration with both ROS 1 and ROS 2, enabling live topic visualization and recorded data inspection. For ROS 2, Rerun officially maintaines basic example scripts, hosted on GitHub, that use Python (rclpy) or C++ to subscribe to ROS 2 topics and forward selected data to the Rerun viewer. This is a user-defined bridge rather than a native-plugin integration. ROS 1 integration is possible using custom nodes written in either C++ or Python (rospy), but usually requires more manual setup. Unlike Foxglove, which uses standardized communication protocols like foxglove_websocket via foxglove_bridge (and optionally rosbridge), Rerun ingests data directly through user-defined code and does not rely on ROS-specific bridge protocols. While Rerun avoids protocol-based bridging, it still requires users to write custom nodes that translate ROS messages into its API.

Rerun is especially useful for visualizing time-synchronized multimodal data, such as sensor readings, 3D geometry, camera images, transforms, and trajectories. However, it currently lacks built-in support for certain ROS-specific features like interactive TF tree exploration, occupancy/grid map overlays, and full URDF-based robot model visualization. Community-maintained examples (e.g., the urdf_loader) offer partial support for URDF rendering, but do not yet match RViz’s depth or interactivity.

Rerun also cannot currently open ROS bag files directly (.bag for ROS 1 or .db3 for ROS 2). Instead, users replay them with rosbag play or ros2 bag play and forward selected topics to Rerun using custom Python or C++ bridge nodes. This workflow offers flexibility and performance but requires additional configuration. Rerun uses its own .rrd log format, which is optimized for high-throughput, time-seekable storage and streaming.

Performance with Large Data

RViz is not fully optimized for very large datasets, such as dense point clouds, high-frequency topics, or long message histories. When visualizing large volumes of data, users may encounter performance issues like low frame rates, rendering lag, and high CPU or GPU usage. This happens because RViz continuously renders incoming ROS messages and stores message history in memory, which can quickly overwhelm system resources.

RViz 2 improves on this with better multithreading and more efficient message transport via DDS. These changes help boost performance and scalability in ROS 2 environments. However, RViz 2 still struggles with very dense or high-rate data streams, especially when rendering complex 3D data in real time, and these improvements do not fully solve the challenges of high-density visualization. To improve performance, users often reduce message history length, filter or downsample data, and disable non-essential displays.

Foxglove , particularly its web version, can underperform RViz in high-data scenarios. Because it runs in a web browser, it's constrained by browser memory limits, single-threaded JavaScript execution, and limited access to hardware acceleration. As a result, visualizing large point clouds or streaming high-frequency topics may lead to lag, dropped frames, or browser instability. These limitations are especially evident when handling continuous 3D data or large bag files.

Performance can vary depending on the use case and browser environment. The desktop application bypasses some browser limitations and can perform better. However, since it is built on Electron, it still has overhead related to memory usage and resource management common to Electron-based apps. Though these issues are generally less severe than in the web version. For lighter workloads, such as 2D plots or moderate-frequency telemetry, Foxglove often performs well and benefits from its accessible UI and cross-platform support.

Rerun is designed with high performance in mind for large-scale, multimodal data workflows. It is a native desktop application written in Rust and uses the modern WGPU rendering backend. This gives it direct access to system resources, helping it efficiently handle dense point clouds, long message histories, and high-frequency data streams. Behind the scenes, Rerun uses techniques such as memory-mapped I/O, zero-copy data handling, and intelligent batching to reduce latency and resource use.

Although there are only few formal benchmarks comparing Rerun with RViz or Foxglove, early community feedback and its architecture suggest that Rerun scales effectively with complex datasets. Performance can be further improved by filtering or downsampling data streams according to specific needs. Rerun is currently under active development to expand its capabilities for robotics visualization and analysis.

Note : Best practices for handling large datasets include splitting data files by time or size (e.g., every 1–5 minutes), using separate files for different topic groups, and automatically deleting old files when disk space is low. Chunk compression can also save disk space more efficiently than whole-file compression, but this approach consumes more CPU and memory resources, representing a trade-off between storage and performance.

Analysis & Visualization

RViz & RViz 2

Key Capabilities:

Real-Time Visualization & Bag File Support : RViz and RViz 2 support real-time visualization by subscribing to live ROS topics. They also display data from recorded bag files (.bag for ROS 1, .db3 and .mcap for ROS 2), when those files are replayed using tools like rosbag play or ros2 bag play.
Data Format Support : RViz visualizes a wide range of robot state information, including URDF robot models, coordinate transforms (TF), and various sensor data such as LIDAR, IMU, depth, and RGB cameras. It also supports odometry, localization, occupancy grid maps (used in SLAM), navigation data (paths, goals, trajectories), and interactive markers for user interaction. RViz 2 supports the same data types with ROS 2 message compatibility.
Interactive Markers : These 3D UI elements enable users to manipulate objects within the visualization: setting navigation goals, adjusting robot end-effector positions, or dragging points for motion planning. Using them requires writing supporting ROS nodes and configuring interaction logic.
Configurable Interface : Users can add, remove, and arrange panels, and customize display properties such as colors, shapes, and update rates for each data type. These configurations can be saved and reloaded using .rviz files, streamlining repetitive workflows like navigation, debugging, or SLAM visualization. Multiple camera control modes (Orbit, FPS, Top-down) allow flexible 3D scene navigation.
Plugin-Based Architecture : Developers can extend RViz by creating custom visualizations and tools through C++ plugins. RViz 2 supports plugins too, built on a more modern and modular architecture.

Data from Mobile Robot Example

Limitations :

Limited Analysis : RViz and RViz 2 primarily serve visualization purposes and lack built-in tools for detailed message inspection, conditional logging, or advanced playback controls like pause, step, or speed adjustment. These features typically require external tools such as rqt_bag, ROS CLI utilities, or third-party RViz plugins (e.g., rosbag_panel). RViz also does not consistently warn about invalid data (e.g., NaNs or infinities), which can result in missing or misleading visuals. These tools are not designed for deep offline data analysis and are best used alongside more specialized logging or analysis solutions.
No Time-Series Analysis : RViz and RViz 2 do not support time-series plotting or statistical analysis. For these tasks, dedicated tools like rqt_plot, PlotJuggler (with ROS 2 support), or external environments like Jupyter with Python are more appropriate.
No Conditional Filtering : RViz and RViz 2 display all incoming data without the ability to filter messages based on content or fields. Filtering must be performed upstream, often by custom ROS nodes. Some plugins or panels offer limited filtering but are not general solutions.
No Topic Synchronization : RViz and RViz 2 subscribe to each topic independently and display messages as they arrive. They do not synchronize data streams from different topics based on timestamps, which can cause misalignment or inconsistencies in time-sensitive visualizations (e.g., camera images, LIDAR scans, TF frames). Synchronization requires external tools like message_filters or custom nodes.
No Built-In Logging or Export : RViz and RViz 2 cannot automatically export visualized data or record screencasts. Users are limited to manual screenshots unless using custom plugins or external tools to record sessions or extract data.
Limited Multi-Robot Support : While RViz can display data from multiple robots using namespaces, the interface is not designed for straightforward multi-robot workflows. RViz 2 includes minor improvements, but still lacks dedicated features for managing multiple robots simultaneously.

Foxglove

Key Capabilities:

Multi-Modal 3D Visualization : Foxglove provides comprehensive 3D visualization for a variety of robotics data, including URDF robot models, TF trees, sensor streams (LIDAR, point clouds, camera feeds), occupancy grids, and navigation elements such as paths, goals, and costmaps. Users can interact with the scene in real time: rotating the view, toggling layers, and focusing on specific frames or topics. Multi-camera views, tooltips, and overlays enhance spatial understanding. Synchronized multi-viewports and flexible camera modes (free, fixed, follow-frame, sensor-aligned) make it possible to examine several spatial data streams side by side. All streams are synchronized through a shared timeline for consistent context across modalities.
Topic Synchronization & Playback Timeline : Foxglove offers a unified, timestamp-based timeline that synchronizes data from multiple topics. This ensures time-aligned playback of sensor streams like RGB images, depth, point clouds, IMU, and TFs, useful both in real time and with recorded data. The timeline includes playback controls such as pause, frame-by-frame stepping, variable speed, and bookmarks for quickly navigating to key events. This tight time synchronization is a major advantage over RViz, enabling clearer insights into system behavior.
Advanced Analysis & Time-Series Tools : Foxglove offers a capable set of tools for offline analysis of recorded data. Users can inspect messages in detail, filter them by topic or namespace, and control playback through an integrated timeline with pause, step-by-step navigation, and adjustable speed. To view custom ROS 2 message types with full support, messages are best recorded in or converted to the MCAP format, although Foxglove can open other formats with some limitations.
Modular & Configurable Interface : The Foxglove UI is fully modular, allowing users to add, remove, duplicate, and rearrange panels such as 3D views, image feeds, message viewers, plots, diagnostics, and consoles. Each panel is highly configurable, with settings for color, scale, transparency, update rate, and filtering. Users can save layouts as JSON files, enabling reproducible setups, role-based dashboards, and fast task switching (e.g., from SLAM debugging to perception analysis). Layouts can be shared across teams or versioned over time.
Custom Panels & Extensions : Foxglove allows users to build custom panels using plugins, enabling specialized interfaces tailored to specific workflows. These panels are embedded directly into the Foxglove interface, keeping everything streamlined and centralized. This is particularly valuable for teams developing internal tools or dashboards for robotics development and testing.
Cloud & Collaboration : Foxglove can be run locally or in the cloud. Its cloud features include shared dashboards, timeline comments, and real-time collaboration, enabling teams to jointly review logs or live data remotely. This makes it particularly useful for distributed development, remote testing, or asynchronous data reviews.

Autonomous Robotic Manipulation Example

Limitations :

Limited Real-Time 3D Interactivity : Foxglove does not natively support interactive 3D markers like RViz. Users cannot directly manipulate objects in the 3D scene (e.g., setting goals, editing poses, or dragging elements) without building custom extensions. This limits Foxglove's out-of-the-box usability for real-time tasks such as motion planning, teleoperation, or interactive environment setup.
Limited Advanced Features : Foxglove currently lacks certain advanced features found in tools like PlotJuggler. For example, Foxglove does not yet support strict axis ratio locking — a critical feature for accurately visualizing spatial data where maintaining proportional relationships between axes is important. Additionally, Foxglove's built-in data transformation capabilities are limited compared to PlotJuggler's comprehensive suite of statistical and signal-processing tools, such as moving averages, derivatives, filtering, and custom mathematical expressions. These advanced features make PlotJuggler especially useful for detailed signal analysis and fine-grained data manipulation, often essential when debugging sensor data or control signals.
No Automated Anomaly Detection : Foxglove does not include built-in automated validation or anomaly detection. It does not use ML models or rule-based systems to automatically flag issues. Instead, it offers detailed message introspection and customizable visualizations that enable users to manually identify irregularities such as NaNs, infinities, or out-of-range values. This hands-on approach requires user expertise but provides flexible, in-depth analysis without automated alerts.

Rerun

Key Capabilities :

Real-time & Recorded Data Visualization : Rerun supports both live-streamed and recorded sensor data visualization with minimal latency. It ingests data via Rust- or Python-based logging SDKs, handling a wide range of robotics sensor modalities including 3D spatial data, camera imagery, numeric time-series, semantic segmentation maps, depth maps, annotations (bounding boxes, keypoints), and textual or categorical event data. Recorded datasets can be replayed with full timeline control for stepwise inspection or smooth playback, aiding in bug reproduction and model validation.
Collaboration & Sharing Features : Rerun streamlines collaborative workflows through data export and session sharing via .rrd files. Teams can share recorded .rrd files for offline inspection, annotate data using Annotation Context (which supports labeling via class IDs and color mapping), and use shared Recording IDs to log streams from multiple processes or machines into a unified session, as long as the Recording ID is set consistently at the time of logging. Note: merging previously recorded .rrd files with different Recording IDs offline is currently not supported. Users can also export screenshots (for reports or dashboards) via the CLI or viewer options, depending on the version and available commands.
Customizable & Extensible UI : The Rerun Viewer offers a modular, layout-aware interface tailored for tasks such as SLAM debugging, multi-sensor calibration, and performance profiling. Users can save and reload Blueprints — serialized UI configurations that preserve panel layouts, timelines, selected entities, and styling (e.g., color, transparency, size). A full styling hierarchy (override → store → default → fallback) makes it easy to customize visuals without modifying source data. Multiple synchronized views (3D scenes, timelines, 2D plots, raw data inspectors) support comprehensive analysis.
Rich 3D Visualization with Spatial Context : Built on egui and WGPU, Rerun's 3D viewer efficiently renders large-scale scenes on consumer hardware. It uses an entity-path-based scene graph that reflects the hierarchical kinematic tree, allowing intuitive navigation and inspection of components, sensor frames, trajectories, bounding boxes, segmentation masks, dense point clouds, annotated images, 3D meshes, and time-series plots. Users can customize visual parameters (e.g., color maps, visibility, annotations, rendering modes) and navigate using orbit, zoom, and pan controls.
Flexible Time-Series & Event Logging : Rerun supports synchronized timeline playback of multiple data streams, using both explicit (user-defined) and implicit (auto-derived) timestamps. It manages multiple time domains (logical/log time and timeline time) to accurately align heterogeneous data sources. Timeline controls include zooming, scrubbing, filtering by entity path or timeline, and detailed event inspection with metadata. Conditional filtering and selective visibility help isolate anomalies or relevant events in complex multi-agent or multi-sensor deployments.
Programmable Data Access & Web Integration : The Rerun SDK provides semantic logging primitives (e.g., log_scalar, log_image, log_point_cloud, log_text_entry, log_tensor) that render automatically in the Viewer. Rerun uses Apache Arrow for efficient data handling, supporting advanced analysis with tools like Pandas and Jupyter. Direct export to formats like Parquet is supported via the API, making it suitable for both streaming visualization and offline batch analysis. The Viewer is also available as a React component, enabling seamless embedding within React applications and custom web dashboards, though integration with other JavaScript frameworks may require additional adaptation.
Emerging Features : Experimental capabilities include graph-based views for visualizing system architectures, connectivity, and agent interactions, extending Rerun's utility beyond traditional sensor data visualization into system design and research workflows.

nuScenes Example

Limitations :

No Built-In Advanced Analytics : Rerun focuses primarily on visualization and lacks integrated statistical analysis, anomaly detection, or expression-based plotting features. In contrast, Foxglove provides richer analytics, including expression plots and integration with monitoring systems like Prometheus.
Not Optimized for Live Robot Control : Although it supports real-time data streaming, Rerun is not designed for robot teleoperation or control input interaction. RViz and Foxglove offer more mature tools for monitoring and interacting with live robots.
No Native Support for Navigation and SLAM Maps : Unlike RViz, Rerun does not natively visualize occupancy grids, costmaps, or SLAM results, limiting its utility for path planning or localization workflows.
Limited Real-Time Collaboration : While Rerun supports offline session sharing, it lacks live multi-user collaboration features such as synchronized remote views or cloud-hosted live sessions, which are available in Foxglove.
Limited Visualization of Large-Scale System Architectures : Rerun's entity-based model focuses on spatial and temporal data but does not yet offer comprehensive tools for exploring complex system communication graphs or architecture diagrams interactively.

Conclusion

This article provided a detailed comparison of RViz, Foxglove, and Rerun, evaluating them across practical dimensions: pricing, platform, and collaboration support, user interface, extensibility, ROS integration, performance with large datasets, and analysis and visualization capabilities. By outlining their strengths and limitations, we offer a clear perspective to help robotics engineers and developers choose the right tool for their specific needs.

Choosing the right tool depends on your context: use RViz for real-time ROS development and interactive debugging, Foxglove for collaborative data analysis, time-synchronized playback, and remote team workflows, and Rerun for fast, developer-centric visualization of structured data in programmatic pipelines. In practice, many robotics teams find that combining these tools enables more effective development and validation across different stages of their workflows.

We hope this comparison helps you make informed decisions and inspires you to keep exploring better tools and workflows. If you have questions, feedback, or insights to share, join the conversation on the ReductStore Community Forum.

Getting Started with LeRobot

AnthonyCvn — Tue, 27 May 2025 00:00:00 +0000

LeRobot is an open-source project by Hugging Face that makes it easy to explore the world of robotics with machine learning, even if you’ve never done anything like this before. It gives you pre-trained models, real-world data, and simple tools built with PyTorch, a popular machine learning framework. Whether you're just curious or ready to try your first robotics project, LeRobot is a great place to start.

What You Need to Get Started

You can run everything in a simulation right from your browser — no robot, no installations, and no powerful computer needed. We’ll be using Google Colab, a free cloud-based coding environment.

Here’s what you’ll need:

Google Account: To use Colab, you need a Google account. If you use Gmail, you already have one. If not, you can create a Google account.
Hugging Face Account: LeRobot uses models and datasets hosted on Hugging Face. To access all features, you'll need to create a Hugging Face account.

Preparation

To get started with LeRobot in Google Colab, first open Google Colab and sign in with your Google account. Once you're signed in, click the New Notebook button to create a blank notebook — this is where you’ll run all your code.

Note: All the commands below are already written out in a ready-made Google Colab notebook you can use to follow along.

Step 1: Switch to GPU

LeRobot can use a GPU (Graphics Processing Unit), which makes things run faster, especially for simulation and machine learning tasks:

In the Colab menu, click Runtime > Change runtime type.
Under the Hardware accelerator, select GPU.
Click Save.

Now your notebook is using a free GPU provided by Google. Note that GPU access in Colab is limited in time and resources, depending on whether you’re using the free or PRO version.

Step 2: Clone the LeRobot Repository

Run this command in a Colab code cell to download LeRobot from GitHub. This repository is public, so you don’t need a GitHub account to clone it.

!git clone https://github.com/huggingface/lerobot.git

A new folder named lerobot will appear in the file browser on the left (click the folder icon to open it).

For now, you can simply start with the lerobot/examples folder. It contains ready-to-use scripts that let you try out real robot tasks using pre-trained models — no setup or deep knowledge needed.

Note: Colab’s environment is temporary. If you restart the runtime, the files will be deleted and you’ll need to run the setup steps again. It’s best to keep these commands handy at the top of your notebook.

Step 3: Move into the LeRobot folder

Now that the LeRobot files are downloaded, we need to tell Python to work inside that folder. Run this command in a new cell:

%cd lerobot

This changes the current working directory to the lerobot folder, where all the code and scripts are located.

Step 4: Install LeRobot and Its Dependencies

After cloning the repository and switching to the lerobot folder, the next step is to install everything LeRobot needs to work. Run this command in a new cell:

!pip install ".[pusht]"

After running it, LeRobot will be ready to use in your notebook. All necessary tools and libraries will be installed automatically.

Note: If you see any errors during installation, you may just need to install a missing libraries.

We recommend installing the hf_xet library for faster and more reliable downloads from Hugging Face:

!pip install hf_xet

This tool helps speed up access to models and datasets, especially when loading large files in Colab.

Running a Pre-Trained Model

LeRobot includes several pre-trained models, so you can try robot tasks without needing to train anything yourself. These models are already trained on specific tasks and ready to go.

π0: A powerful model that combines vision, language, and action. It’s designed for general robot tasks, for example, following instructions or reacting to what it sees.
π0 FAST: A faster, optimized version of the π0 model.
Diffusion Policy: A model trained on the Push-T dataset, where a robot learns to push a T-shaped object toward a target.
VQ-BeT: Another model trained on the same Push-T task, but it uses a different architecture. You can run both and compare how they perform.
ACT: A model trained for fine manipulation tasks that require high precision, like inserting objects or handling small parts.

By default, the example script runs the Diffusion Policy model on the Push-T task. To try it out, run this command in a code cell:

!python examples/2_evaluate_pretrained_policy.py

When you run the command, LeRobot will automatically download the pre-trained model, set up a simulation environment, and run the robot as it tries to complete the task. Throughout the process, you’ll see messages showing what’s happening step-by-step. A short video will also be saved so you can see how the robot performed.

Note: When running dataset downloads or model loading multiple times in a row, you might occasionally encounter temporary access restrictions from Hugging Face. This is normal and part of their rate limiting to prevent abuse.

What You’ll See in the Output

As the model runs, Colab will print some logs in the output below the code:

{'observation.image': PolicyFeature(type=<FeatureType.VISUAL: 'VISUAL'>, shape=(3, 96, 96)), 'observation.state': PolicyFeature(type=<FeatureType.STATE: 'STATE'>, shape=(2,))}
Dict('agent_pos': Box(0.0, 512.0, (2,), float64), 'pixels': Box(0, 255, (96, 96, 3), uint8))
{'action': PolicyFeature(type=<FeatureType.ACTION: 'ACTION'>, shape=(2,))}
Box(0.0, 512.0, (2,), float32)
step=0 reward=np.float64(0.0) terminated=False
step=1 reward=np.float64(0.0) terminated=False
...
step=108 reward=np.float64(0.9727550736734778) terminated=False
step=109 reward=np.float64(0.9969248691240408) terminated=False
step=110 reward=np.float64(1.0) terminated=True
Success!
IMAGEIO FFMPEG_WRITER WARNING: input image is not divisible by macro_block_size=16, resizing from (680, 680) to (688, 688) to ensure video compatibility with most codecs and players. To prevent resizing, make your input image divisible by the macro_block_size or set the macro_block_size to 1 (risking incompatibility).
Video of the evaluation is available in 'outputs/eval/example_pusht_diffusion/rollout.mp4'.

Here’s what they mean:

Observations: What kind of data the robot receives, like the shape and type of images or sensor readings it expects.
Actions: The format of the commands the robot will output to control its movements.
Reward: A number that shows how well the robot is doing (higher = better).
Step-by-step info: Shows progress, like step 108, reward 0.97, etc.
Success or Failure: Whether the robot completed the task. In our experiments, the same pre-trained model produced different results. It didn’t always complete the task successfully.

You may also see a warning about video resizing. It’s normal and doesn’t affect how the robot runs.

Where’s the Video?

The video is saved in lerobot/outputs/eval/example_pusht_diffusion/rollout.mp4.

It shows the robot pushing the T-shaped object in simulation using the actions generated by the model. To download it, find the file in the file browser, click the three dots to the right of the filename, and select Download. Then you can watch it with any video player.

Want to Try a Different Model?

You can switch from Diffusion Policy to VQ-BeT, which is trained on the same task. It’s a good way to explore how different models perform.

Here’s how you can do it:

In the file browser, open the file lerobot/examples/2_evaluate_pretrained_policy.py.
Double-click the file to open it in the editor pane on the right.
Update the following lines in the script:

33 from lerobot.common.policies.vqbet.modeling_vqbet import VQBeTPolicy
# Optional: change output path to avoid overwriting results
36 output_directory = Path("outputs/eval/example_vqbet_pusht")
43 pretrained_policy_path = "lerobot/vqbet_pusht"
47 policy = VQBeTPolicy.from_pretrained(pretrained_policy_path)

Save the file by pressing Ctrl+S (or Cmd+S on Mac).
After saving, re-run the code cell that runs the script:

!python examples/2_evaluate_pretrained_policy.py

This will now evaluate the VQ-BeT model instead of the Diffusion Policy.

Training a Model

LeRobot isn’t just for running pre-trained models, it also lets you try training one yourself. You can train the same type of model used by the official LeRobot team: the Diffusion Policy on the Push-T task.

Since we’re using Google Colab, you have access to a free GPU, which is important because training on other systems without a CUDA-enabled GPU can be very slow. For example, in our tests on a Mac with Apple Silicon (using the MPS backend), training took significantly longer — in one case, up to two hours just to complete just 20 steps.

By default, the training script runs for 5000 steps, which takes some time. In our case, the run took about an hour on Colab’s GPU. If you want to try it faster, you can reduce the steps to, say, 100. This will still give you a good idea of how training works.

In the file lerobot/examples/3_train_policy.py, find and change these line:

42 training_steps = 5000

Now run the training script:

!python examples/3_train_policy.py

This will start training the Diffusion Policy model on the Push-T task using the lerobot/pusht dataset.

As the script runs, you’ll see lines like this in the terminal:

step: 0 loss: 1.161
step: 1 loss: 5.978
...
step: 4998 loss: 0.048
step: 4999 loss: 0.037

Each line shows the current training step and the corresponding loss value. A decreasing loss generally means the model is learning.

Where the Trained Model is Saved

LeRobot will save your trained model in lerobot/outputs/train/example_pusht_diffusion. Inside the folder, you’ll find two files represent your trained Diffusion Policy: one with the model’s weights and one with its settings. They will be used automatically when you run the model.

Evaluating Your Trained Model

Now let’s see your model in action.

Open the file lerobot/examples/2_evaluate_pretrained_policy.py and change the code so it loads your trained model instead of the pre-trained one:

33 from lerobot.common.policies.diffusion.modeling_diffusion import DiffusionPolicy
36 output_directory = Path("outputs/eval/example_pusht_diffusion")
# Comment out the old pretrained model path
43 # pretrained_policy_path = "lerobot/diffusion_pusht"
# Use your newly trained model path instead
45 pretrained_policy_path = Path("outputs/train/example_pusht_diffusion")
47 policy = DiffusionPolicy.from_pretrained(pretrained_policy_path)

To avoid overwriting the previous video, give your video a new name:

136 video_path = output_directory / "rollout_our_model.mp4"

Now run the evaluation script:

!python examples/2_evaluate_pretrained_policy.py

What You’ll See

The script will run your model in simulation and save a video you can later open to see how your model behaved lerobot/outputs/eval/example_pusht_diffusion/rollout_our_model.mp4.

You’ll also see logs like:

...
step=297 reward=np.float64(0.0) terminated=False
step=298 reward=np.float64(0.0) terminated=False
step=299 reward=np.float64(0.0) terminated=False
Failure!

This means the robot didn’t complete the task successfully. Even if you trained for 5000 steps, your model may still perform noticeably worse than the official pre-trained model. That’s normal, the LeRobot team trained their models with much more compute and fine-tuning. In comparison, your version might show less precise or more random movements. It’s a good first step, though, and shows the entire training and evaluation pipeline working end-to-end.

Downloading a Dataset

To train a model we need one key ingredient: data. These include video from the robot’s cameras, joint positions, and the actions it took over time.

LeRobot makes this part easy. It comes with a growing collection of high-quality robot learning datasets you can download and explore with just a few lines of code.

Browse all available datasets here.

To download and inspect a dataset, run this example script:

!python examples/1_load_lerobot_dataset.py

By default, this will download a dataset lerobot/aloha_mobile_cabinet.

But you’re not limited to just one. If you’d like to try the dataset used by the models in the previous section (DiffusionPolicy and VQ-BeT), open the script and change the repo_id variable like this:

50 repo_id = "lerobot/pusht"

Then re-run the script. This will download the Push-T dataset, the same one used to train both models you just ran earlier. You’ll now have access to the raw data they were trained on.

Tip: Clean Up the Output

The dataset script prints a lot of information, overwhelming for beginners. To make things easier, you can comment out some of the verbose print lines.

To comment out multiple lines quickly:

Windows/Linux: Press Ctrl + /.

macOS: Press Cmd + /.

Suggested lines to comment out include:

38  # print("List of available datasets:")
39  # pprint(lerobot.available_datasets)
42  # hub_api = HfApi()
43  # repo_ids = [info.id for info in hub_api.list_datasets(task_categories="robotics", tags=["LeRobot"])]
44  # pprint(repo_ids)
65  # print("Features:")
66  # pprint(ds_meta.features)
69  # print(ds_meta)
73  # dataset = LeRobotDataset(repo_id, episodes=[0, 10, 11, 23])
76  # print(f"Selected episodes: {dataset.episodes}")
77  # print(f"Number of episodes selected: {dataset.num_episodes}")
78  # print(f"Number of frames selected: {dataset.num_frames}")
82  # print(f"Number of episodes selected: {dataset.num_episodes}")
83  # print(f"Number of frames selected: {dataset.num_frames}")
86  # print(dataset.meta)
90  # print(dataset.hf_dataset)
111 # pprint(dataset.features[camera_key])
113 # pprint(dataset.features[camera_key])
119 # delta_timestamps = {
#... all lines
148 # break

You can always uncomment them later if you want a deeper look into the dataset structure.

What’s Inside the Push-T Dataset?

Once downloaded, you’ll see a summary like this:

Number of episodes: 206. An episode is like one full attempt by the robot to complete a task, one round of practice.
Frames per episode (avg.): ~124. Each episode is made up of about 124 images (or frames), showing what the robot saw over time as it moved and acted.
Recording speed: 10 FPS. These images were recorded at 10 frames per second, like a slow-motion video. It lets you see how the robot moved step by step.
Camera views: observation.image. Each frame is taken from the robot’s camera, and labeled as observation.image in the data. It’s what the robot sees.
Task description: Push the T-shaped block onto the T-shaped target.
Image format: Each image is stored as a PyTorch tensor (a data structure used in machine learning):

LeRobot downloads the dataset into a special hidden cache folder inside the Colab environment /root/.cache/huggingface/lerobot/lerobot/pusht/.

This folder contains all the data files: observations, actions, metadata, and even video recordings. Since it’s hidden by default, follow these steps to access it:

Click the eye icon at the top of the file browser to show hidden folders like .cache.
Click the folder icon with two dots just above the lerobot folder.

Now navigate through the folders like this: root > .cache > huggingface > lerobot > lerobot > pusht.
To go back to the lerobot folder, look for the content folder, it's at the same level as the root, and go inside.

Dataset Folder Structure

Here's what the folder structure typically looks like:

lerobot/pusht
├── README.md
├── .cache/
├── data/
│   └── chunk-000/
│       ├── episode_000000.parquet
│       └── ...  # More episodes
├── meta/
├── videos/
│   └── chunk-000/
│       └── observation.image/
│           ├── episode_000000.mp4
│           └── ...  # More videos

README.md: A short file that explains what’s inside the dataset and what it’s for.
data/: This folder contains one file per episode .parquet, where the robot logs everything it experienced.
meta/: This folder contains helpful background info, like the episode’s descriptions, task goals, and performance stats, that LeRobot uses to organize and analyze the data.
videos/: Short .mp4 videos showing the robot’s camera view during each episode. These are great if you want to see what the robot was doing.
.cache/: A hidden folder used by LeRobot internally.

Visualize a Dataset

Once your dataset is loaded, it’s super helpful to see what the robot actually experienced. LeRobot comes with an easy-to-use, interactive visualization tool that runs right in your browser.

Try the Built-in Viewer

You can open it here: Visualize Dataset (v2.0+ latest dataset format) or use the older version: Visualize Dataset (v1.6 old dataset format).

In the viewer, just enter the name of a dataset, like lerobot/pusht.

What Can You See?

Watch each episode like a video from the robot’s point of view.
Explore graphs showing how the robot moved and what actions it took. For example, in the lerobot/pusht dataset, the viewer displays Motor 0 and Motor 1 — both state and action — as four curves plotted over time. This allows you to see how the robot's decisions changed from frame to frame during each episode.

Next Steps

You’ve just taken your first steps into robotics and machine learning with LeRobot, so what can you do next?

Try different models and tasks: LeRobot supports several models and scenarios. For more challenging examples, check out the lerobot/examples/advanced folder.
Run your own experiment: Once you’re familiar with the basic workflow, you can try a simple experiment: change the dataset slightly or load a new one. Even a small change, such as selecting a different set of episodes, will help you see how data affects the model’s behavior.
Grow your projects further: As you work more with LeRobot and collect larger amounts of data, organizing and managing that data becomes important. This can feel overwhelming at first, but understanding the basics of data management will save you time and frustration later. We recommend checking out this beginner-friendly guide, How to Store and Manage Robotics Data. It explains simple strategies for handling robot data efficiently. You don’t need to master this now, but keeping these ideas in mind will help you scale your experiments smoothly when you’re ready.

Conclusion

In this tutorial, we saw how LeRobot lets you explore robotics and machine learning without needing a physical robot. You ran pre-trained models in simulation, worked with real robot data, and even trained a simple model — all within Colab.

What many find surprising is how accessible this has become. Tasks that once required expensive hardware and deep skills can now be done with just a browser and a few lines of code. Seeing a robot act based on what it sees is exciting, and you can go further by modifying, training, and evaluating models yourself. LeRobot is a great way to start new projects and dive into robotics.

We hope this tutorial inspires you to keep exploring. If you have any questions or ideas to share, feel free to use the ReductStore Community Forum.

Getting Started with MetriCal

AnthonyCvn — Tue, 13 May 2025 00:00:00 +0000

Sensor calibration is the process of determining the precise mathematical parameters that describe how a sensor perceives or measures the physical world. By comparing sensor outputs to known reference values, we can correct measurement errors and ensure data from different sensors align accurately.

There are two main categories of calibration parameters:

Intrinsic parameters (Intrinsics): These capture the internal characteristics of a sensor, such as lens distortion in cameras or bias and scaling errors in IMUs. Calibrating intrinsics helps eliminate built-in measurement errors.
Extrinsic parameters (Extrinsics): These define a sensor's position and orientation relative to another sensor or the environment. Accurate extrinsics are essential for transforming and combining data from multiple sensors into a shared coordinate system.

High-quality calibration is key to getting reliable, consistent data, which is critical for mapping, perception, and decision-making in robotics and autonomous systems. Recognizing this need, ReductStore can be used to manage the entire calibration data pipeline — from raw inputs such as LiDAR scans and calibration images to the output files produced during processing (e.g., intrinsic/extrinsic parameters, transformation matrices). When used together with tools like MetriCal, which streamline the calibration of multimodal sensor data, ReductStore can help enable scalable, automated workflows across distributed systems by making it easy to collect, store, and manage sensor data directly at the edge. Calibration results can then be saved back to ReductStore for persistent access and reuse.

What is MetriCal?

MetriCal is a calibration tool developed by Tangram Vision for systems that include diverse types of sensors. It’s designed to handle real-world calibration scenarios and supports the simultaneous processing of data from cameras, LiDARs, and IMUs. MetriCal is suitable for both small-scale setups and larger, production-level environments, providing tools for precise and consistent multi-sensor calibration.

Key Features

ROS Data Input: Supports .bag and .mcap files (recommended)
Automatic Extrinsics Estimation: Computes sensor and target poses without requiring CAD models or manual setup
Unlimited Sensor Streams: Supports an arbitrary number of input streams
Broad Target Support: Compatible with both 2D and 3D targets; includes a library of premade targets and supports multiple targets at once
Modular Calibration Workflow: Allows splitting the calibration process into multiple datasets and stages
Detailed Diagnostics: Provides visual and numerical feedback on data quality and calibration performance
ROS Integration: Outputs calibration results as an URDF file
Pixel-Level Corrections: Generates lookup tables for single-camera undistortion and stereo rectification
Lightweight Deployment: CPU-only operation; runs efficiently on compact devices like Intel NUCs or in the cloud

How MetriCal Works

MetriCal is structured as a CLI-based, fully scriptable pipeline designed to support reproducible workflows and automation. The core calibration process can be divided into the following stages:

1. Preparation

The quality of calibration strongly depends on the choice of targets and the quality of the input data. It's important to select or build targets suited to your use case and follow MetriCal’s data capture guidelines to ensure the collected data meets the required quality standards.

At this stage, you'll also prepare an object space file , which describes all calibration targets and their properties.

2. Initialization

Once the dataset and configuration files are ready, MetriCal’s init mode analyzes sensor observations to infer a raw input plex — a description of the spatial, temporal, and semantic relationships within your perception system. It represents the physical system being calibrated and serves as the starting point for all further calibration steps.

If you already have a plex with existing calibration results that you want to preserve, it can be used as a seed for an init plex.

3. Calibration

In calibrate mode, MetriCal performs a full bundle adjustment to refine both the initial plex and the object space. It applies motion filtering to remove features affected by motion blur, rolling shutter, false detections, and other artifacts in images or point clouds.

A .json cache file is created at this step. This file stores detected objects, allowing future runs to skip the detection process and complete faster.

The calibration data capture and detection process can also be visualized during this step.

4. Diagnostics

MetriCal generates a detailed diagnostic report with color-coded charts summarizing calibration quality:

Cyan – spectacular
Green – good
Orange – okay, but generally poor
Red – bad

5. Visualization

In display mode, calibration results are visualized using Rerun, an open-source tool for multimodal data visualization. It allows you to quickly verify the calibration quality before exporting.

Typically, the same dataset is used for visualization, but you can also use a different one if it has the same topic names.

6. Export

In shape mode, the optimized plex can be transformed into various configurations for use in deployed systems, for example, ROS URDFs or pixel-wise lookup tables.

MetriCal also includes several additional modes to support advanced workflows: completion mode, consolidate object spaces mode, pipeline mode, and pretty print mode.

MetriCal Example

To test MetriCal’s multi-sensor capabilities, we use the official example featuring two cameras and a LiDAR. The dataset contains synchronized observations from all three sensors, capturing a LiDAR circle target from different angles. This allows MetriCal to calculate:

Intrinsics and poses for both cameras
Extrinsics between each camera and the LiDAR
Target geometry and consistency across different views

Installation

We installed MetriCal via Docker. Make sure to set up an alias for convenient access during installation:

~/.zshrcmetrical() { docker run --rm --tty --init --user="$(id -u):$(id -g)" \ --volume="$PATH/metrical/":"/datasets" \ --volume=metrical-license-cache:/.cache/tangram-vision \ --workdir="/datasets" \ --add-host=host.docker.internal:host-gateway \ tangramvision/cli:latest \ --license="LICENSE KEY" \ "$@";}

MetriCal requires a license key.

You can also install MetriCal natively on Ubuntu or Pop!_OS.

Calibration

After cloning the repository, download and unzip the .zip file. Place the observations folder into:

$PATH/metrical/examples/camera_lidar

Next, set the LICENSE variable inside metrical_alias.sh, located in the same directory.

Once everything is configured, you can run the full calibration pipeline using the provided shell script:

$PATH/metrical/examples/camera_lidar/camera_lidar_runner.sh

Visualization

To visualize the results, install Rerun via pip and launch the Rerun server in a separate terminal tab.

Then, run the following command to display calibration results in display mode and view the data in real time:

metrical display /datasets/examples/camera_lidar/observations /datasets/examples/camera_lidar/results.json

Understanding Results

During calibration, MetriCal produces charts and diagnostics that show the quality of the process and highlight areas that may need improvement.

Data Inputs (DI Section)

The Data Inputs section provides an overview of the input data and ensures that the dataset is appropriate for a successful calibration.

Key Metrics:

Calibration Inputs (DI-1): Displays basic configuration parameters.

█ DI-1 █ Calibration Inputs
+--------------------------------------+----------+
| Calibration Parameter                | Value    |
+--------------------------------------+----------+
| MetriCal Version                     | 13.2.1   |
+--------------------------------------+----------+
| Optimization Profile                 | Standard |
+--------------------------------------+----------+
| Camera Motion Threshold              | Disabled |
+--------------------------------------+----------+
| Lidar Motion Threshold               | Disabled |
+--------------------------------------+----------+
| Preserve Input Constraints           | Disabled |
+--------------------------------------+----------+
| Object Relative Extrinsics Inference | Enabled  |
+--------------------------------------+----------+

Object Space Descriptions(DI-2): Describes the calibration targets (object spaces).

█ DI-2 █ Object Space Descriptions
+-------------+-------------------------+---------------------------------------+------------------------+
| Type        | UUID                    | Detector                              | Variance               |
+-------------+-------------------------+---------------------------------------+------------------------+
| Circle      | 34e6df7b...45d796bf     | - 0.6m radius                         | 1e-8, 1e-8, 1e-8       |
|             |                         | - 0.375m x offset                     |                        |
|             | Mutual Group A          | - 0.375m y offset                     |                        |
|             | |-- 24e6df7b...45d796bf | - 0m z offset                         |                        |
|             |                         | - 0.05m reflective tape width         |                        |
|             |                         | - Detect interior points: true        |                        |
+-------------+-------------------------+---------------------------------------+------------------------+
| Markerboard | 24e6df7b...45d796bf     | - 7x7 grid                            | 0.0002, 0.0002, 0.0002 |
|             |                         | - 0.097m markers                      |                        |
|             | Mutual Group A          | - 0.125m checkers (aka solid squares) |                        |
|             | |-- 34e6df7b...45d796bf | - Dictionary: Aruco4x4_1000           |                        |
|             |                         | - Marker IDs start at 0               |                        |
|             |                         | - Top-left corner is a Marker         |                        |
+-------------+-------------------------+---------------------------------------+------------------------+

Processed Observation Count (DI-3): Shows how many observations were processed from the dataset.

█ DI-3 █ Processed Observation Count
+----------------------------------+--------+-------------------+------------------------+-----------------------+
| Component                        | # read | # with detections | # after quality filter | # after motion filter |
+----------------------------------+--------+-------------------+------------------------+-----------------------+
| infra1_image_rect_raw (f7df04cc) |    283 |               276 |                    273 |                   273 |
+----------------------------------+--------+-------------------+------------------------+-----------------------+
| infra2_image_rect_raw (34ed8934) |    284 |               282 |                    278 |                   278 |
+----------------------------------+--------+-------------------+------------------------+-----------------------+
|      velodyne_points1 (38140838) |   2750 |              2026 |                   2026 |                  2026 |
+----------------------------------+--------+-------------------+------------------------+-----------------------+

Camera FOV Coverage (DI-4): Displays how well the calibration data covers the field of view (FOV) of each camera. Ideal coverage is characterized by minimal red cells, which represent areas without detected features.

Detection Timeline(DI-5): Displays when detections occurred across the dataset timeline. Each row corresponds to a different sensor, making it easier to check synchronization.

█ DI-5 █ Detection Timeline
+----------------------------------+-------------------------------------------------------------------------------------------------+
|            Components            |          Detection Timeline (x axis is seconds elapsed since first observation)                 |
|                                  |          Every point on the timeline represents an observation with detected features.          |
+----------------------------------+-------------------------------------------------------------------------------------------------+
|                                  | ⡁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 4.0 |
| infra1_image_rect_raw (f7df04cc) | ⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀     |
| infra2_image_rect_raw (34ed8934) | ⠂⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠉⠁⠉⠉⠉⠁⠉⠀⠉⠉⠉⠉⠁⠁⠉⠀⠈⠉⠉⠉⠉⠉⠈⠉⠁⠀⠀⠈⠁⠈⠈⠉⠉⠉⠁⠁⠀⠉⠀⠈⠁⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠈⠈⠀⠉⠉⠉⠁⠉⠉⠈⠉⠉⠈⠉⠉⠈⠉⠁⠉⠉⠈⠉⠉⠀⠉⠁     |
| velodyne_points1 (38140838)      | ⡁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀     |
|                                  | ⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠉⠁⠉⠉⠉⠁⠉⠀⠉⠉⠉⠉⠉⠀⠉⠁⠈⠉⠉⠉⠉⠉⠈⠉⠀⠀⠀⠀⠀⠉⠉⠉⠉⠉⠁⠉⠉⠉⠁⠀⠉⠉⠉⠁⠉⠈⠁⠉⠉⠉⠉⠉⠈⠁⠉⠉⠉⠉⠉⠉⠉⠉⠈⠁⠉⠉⠈⠉⠁⠉⠉⠈⠉⠉⠀⠉⠁     |
|                                  | ⠂⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀     |
|                                  | ⡉⠀⠀⠈⠀⠉⠈⠈⠀⠀⠈⠁⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠈⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠁⠉⠁     |
|                                  | ⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀     |
|                                  | ⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁⠈⠀⠁ 0.0 |
|                                  | 0.0                                                                                  269.1      |
+----------------------------------+-------------------------------------------------------------------------------------------------+

Camera Modeling (CM Section)

This section shows how well the camera models fit the actual calibration data — that is, how accurately the system understood the camera’s behavior based on the collected data.

Key Metrics:

Binned Reprojection Errors (CM-1): A heatmap showing reprojection errors across the camera’s FOV. If certain areas show high error (orange or red), it could indicate problems with the camera model or lens distortion that isn't being captured correctly.

Stereo Pair Rectification Error (CM-2): For multi-camera setups, this shows the stereo rectification error between camera pairs, indicating how well the cameras are aligned for stereo vision.

█ CM-2 █ Stereo Pair Rectification Error
+---------------------------------------+--------------+-------+-------------------------------------------------------------------------------------+
| Stereo Pair                           | # Mutual Obs | RMSE  | Binned rectified error (px)                                                         |
+---------------------------------------+--------------+-------+-------------------------------------------------------------------------------------+
| Dominant eye:  infra1_image_rect_raw  | 155          | 0.742 | ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 3202.0 |
| Secondary eye: infra2_image_rect_raw  |              |       | ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀        |
|                                       |              |       | ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀        |
|                                       |              |       | ⣇⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀        |
|                                       |              |       | ⡇⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀        |
|                                       |              |       | ⡇⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀        |
|                                       |              |       | ⡇⢸⣀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀        |
|                                       |              |       | ⠇⠸⠀⠏⠹⠒⠖⠲⠒⠖⠲⠒⠦⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠀⠀ 0.0    |
|                                       |              |       | 0.0                                                                     7.0         |
+---------------------------------------+--------------+-------+-------------------------------------------------------------------------------------+

Extrinsics Info (EI Section)

This section focuses on the spatial relationships between components in the calibration setup. Accurate extrinsic calibration ensures that the relative positions and orientations of the sensors are well understood.

Key Metrics:

Component Extrinsics Errors (EI-1): Displays the extrinsic errors between each pair of components. If the errors are large, check whether all components are positioned and oriented correctly.

█ EI-1 █ Component Extrinsics Errors
+--------------------------------------------+----------+----------+----------+----------+-----------+---------+
| Weighted Component Relative Extrinsic RMSE | X (m)    | Y (m)    | Z (m)    | Roll (°) | Pitch (°) | Yaw (°) |
| Rotation is Euler XYZ ext                  |          |          |          |          |           |         |
+--------------------------------------------+----------+----------+----------+----------+-----------+---------+
| To: infra1_image_rect_raw (f7df04cc),      | 2.254e-3 | 1.802e-3 | 3.780e-3 |    0.077 |     0.100 |   0.148 |
|    From: infra2_image_rect_raw (34ed8934)  |          |          |          |          |           |         |
+--------------------------------------------+----------+----------+----------+----------+-----------+---------+

IMU Preintegration Errors (EI-2): Displays a summary of all IMU preintegration errors from the system. In this example, IMUs were not calibrated.
Observed Camera Range of Motion (EI-3): Shows how much motion was observed for each camera during the data collection. Sufficient motion is necessary to avoid projective compensation errors.

█ EI-3 █ Observed Camera Range of Motion
+----------------------------------+--------+----------------------+--------------------+
| Camera                           | Z (m)  | Horizontal angle (°) | Vertical angle (°) |
+----------------------------------+--------+----------------------+--------------------+
| infra1_image_rect_raw (f7df04cc) | 6.308  | 127.081              | 63.801             |
+----------------------------------+--------+----------------------+--------------------+
| infra2_image_rect_raw (34ed8934) | 6.434  | 144.606              | 126.280            |
+----------------------------------+--------+----------------------+--------------------+

Calibrated Plex (CP Section)

This section displays the final results of the calibration, including the intrinsic and extrinsic parameters that can be used for updating the system configuration.

Key Metrics:

Camera Metrics (CP-1): Contains the intrinsic parameters of each camera, such as focal length, principal point, and distortion parameters. Standard deviations indicate the uncertainty of each parameter.

█ CP-1 █ Camera Metrics
+----------------------------------+-------------------------+-----------------------------------------+--------------------------------------+
| Camera                           | Specs                   | Projection Model                        | Distortion Model                     |
+----------------------------------+-------------------------+-----------------------------------------+--------------------------------------+
| infra1_image_rect_raw (f7df04cc) |  width (px)        848  |  Pinhole                                |      OpenCV Distortion               |
|                                  |  height (px)       480  |  f (px)      431.914 ±      0.224 (1σ)  |  k1   -1.574e-3 ±   8.715e-4 (1σ)    |
|                                  |  pixel pitch (um)  1    |  cx (px)     421.938 ±      0.395 (1σ)  |  k2       0.011 ±   1.876e-3 (1σ)    |
|                                  |                         |  cy (px)     230.592 ±      0.465 (1σ)  |  k3   -6.171e-3 ±   1.241e-3 (1σ)    |
|                                  |                         |                                         |  p1   -2.037e-3 ±   2.680e-4 (1σ)    |
|                                  |                         |                                         |  p2   -1.479e-3 ±   2.443e-4 (1σ)    |
|                                  |                         |                                         |                                      |
+----------------------------------+-------------------------+-----------------------------------------+--------------------------------------+
| infra2_image_rect_raw (34ed8934) |  width (px)        848  |  Pinhole                                |      OpenCV Distortion               |
|                                  |  height (px)       480  |  f (px)      429.085 ±      0.215 (1σ)  |  k1   -3.050e-4 ±   8.638e-4 (1σ)    |
|                                  |  pixel pitch (um)  1    |  cx (px)     421.203 ±      0.387 (1σ)  |  k2    1.517e-3 ±   1.809e-3 (1σ)    |
|                                  |                         |  cy (px)     230.821 ±      0.436 (1σ)  |  k3   -6.881e-4 ±   1.170e-3 (1σ)    |
|                                  |                         |                                         |  p1   -1.887e-3 ±   2.510e-4 (1σ)    |
|                                  |                         |                                         |  p2   -1.630e-3 ±   2.358e-4 (1σ)    |
|                                  |                         |                                         |                                      |
+----------------------------------+-------------------------+-----------------------------------------+--------------------------------------+

Optimized IMU Metrics (CP-2): In this example, IMUs were not calibrated.
Calibrated Extrinsics (CP-3): Shows the minimum spanning tree of spatial constraints in the plex, highlighting only the most critical constraints needed to keep the structure intact.

█ CP-3 █  Calibrated Extrinsics
+---------------------------+------------+-----------------+----------------------+---------------+---------------------+
| Final Extrinsics          | Subplex ID | Translation (m) | Diff from input (mm) | Rotation (°)  | Diff from input (°) |
| 'To' component is Origin  |            |                 |                      |               |                     |
| Rotation is Euler XYZ ext |            |                 |                      |               |                     |
+---------------------------+------------+-----------------+----------------------+---------------+---------------------+
| To: infra1_image_rect_raw | A          | X: 0.360        | ΔX: 359.862          | Roll: -85.208 | ΔRoll: -85.208      |
|     f7df04cc, RDF         |            | Y: 0.083        | ΔY: 82.722           | Pitch: -2.812 | ΔPitch: -2.812      |
| From: velodyne_points1    |            | Z: 0.048        | ΔZ: 48.451           | Yaw: 171.579  | ΔYaw: 171.579       |
|     38140838, Unknown     |            |                 |                      |               |                     |
+---------------------------+------------+-----------------+----------------------+---------------+---------------------+
| To: infra2_image_rect_raw | A          | X: 0.319        | ΔX: 318.513          | Roll: -85.317 | ΔRoll: -85.317      |
|     34ed8934, RDF         |            | Y: 0.086        | ΔY: 85.533           | Pitch: -2.717 | ΔPitch: -2.717      |
| From: velodyne_points1    |            | Z: 0.033        | ΔZ: 33.454           | Yaw: 171.470  | ΔYaw: 171.470       |
|     38140838, Unknown     |            |                 |                      |               |                     |
+---------------------------+------------+-----------------+----------------------+---------------+---------------------+

Summary Statistics (SS Section)

This section provides a high-level overview of the optimization process and the overall calibration quality.

Optimization Summary Statistics (SS-1): Includes overall reprojection error and posterior variance, which indicates the calibration’s uncertainty.

█ SS-1 █ Optimization Summary Statistics
+------------------------+----------+
| Optimized Object RMSE, | 0.206 px |
| based on all cameras   |          |
+------------------------+----------+
| Posterior Variance     | 0.731    |
+------------------------+----------+

Camera Summary Statistics (SS-2): Summarizes the reprojection errors for each camera. An RMSE under 0.5 pixels is typically acceptable, and under 0.2 pixels is excellent.

█ SS-2 █ Camera Summary Statistics
+----------------------------------+------------------------------------------+
| Camera                           | Reproj. RMSE, outliers downweighted (px) |
+----------------------------------+------------------------------------------+
| infra1_image_rect_raw (f7df04cc) | 0.209 px                                 |
+----------------------------------+------------------------------------------+
| infra2_image_rect_raw (34ed8934) | 0.204 px                                 |
+----------------------------------+------------------------------------------+

LiDAR Summary Statistics (SS-3): Shows the RMSE of various residual metrics: circle misalignment, interior points to plane error, paired 3D point error, and paired plane normal error.

█ SS-3 █ LiDAR Summary Statistics
+-----------------------------+-------------------------------+------------------------------------+--------------------------+--------------------------+
| LiDAR                       | Circle misalignment RMSE with | Circle edge misalignment RMSE with | Interior point RMSE with | Plane normal difference, |
|                             | all cameras, outliers         | all cameras, outliers              | all cameras, outliers    | lidar-lidar, outliers    |
|                             | downweighted (m)              | downweighted (m)                   | downweighted (m)         | downweighted (deg)       |
+-----------------------------+-------------------------------+------------------------------------+--------------------------+--------------------------+
| velodyne_points1 (38140838) | 0.020 m                       | 0.028 m                            | 0.018 m                  | (n/a)                    |
+-----------------------------+-------------------------------+------------------------------------+--------------------------+--------------------------+

Data Diagnostics

This section highlights potential issues with the calibration setup, data, or process.

High-Risk Diagnostics: Critical issues such as insufficient camera motion or missing required components must be addressed for successful calibration.

Medium and Low-Risk Diagnostics: Less critical issues, such as poor feature coverage, should still be monitored and corrected when possible to improve calibration quality.

Output Summary

+------------------------+------------------------------------------------------------+
| Results JSON           | /datasets/camera_lidar/results.json                        |
+------------------------+------------------------------------------------------------+
| Calibrated Plex        | Run `jq .plex [results.json] > optimized_plex.json`        |
+------------------------+------------------------------------------------------------+
| Optimized Object Space | Run `jq .object_space [results.json] > optimized_obj.json` |
+------------------------+------------------------------------------------------------+
| Cached Detections JSON | /datasets/camera_lidar/observations.detections.json        |
+------------------------+------------------------------------------------------------+
| Report Path            | /datasets/camera_lidar/report.html                         |
+------------------------+------------------------------------------------------------+

The calibration process generates several output files, located in the $PATH/metrical/examples/camera_lidar directory.

init_plex.json: A raw input plex from the init mode.
observations.detections.json: Cached detections for faster reruns in calibrate mode.
results.json: The main output file, containing calibrated plex and object space.
report.html: An HTML report summarizing calibration performance visually.
results_urdf.xml: A ROS-compatible URDF file that describes the spatial relationships between the two calibrated cameras and the LiDAR, enabling tools like robot_state_publisher to publish real-time TF transforms based on these relationships.

Conclusion

MetriCal simplifies multimodal sensor calibration by offering a fully scriptable, CLI-based workflow with detailed diagnostics and seamless ROS integration. One of the key takeaways from working with this tool is that successful calibration depends heavily on the quality of the captured data. Carefully choosing calibration targets, ensuring sufficient sensor motion, and achieving full field-of-view coverage all have a major impact on the results. For those just starting out, prioritizing high-quality data capture and closely following the recommended guidelines is essential for obtaining reliable outcomes.

We hope this tutorial provided a clear and practical introduction to using MetriCal for multi-sensor calibration. If you have any questions or comments, feel free to use the ReductStore Community Forum.

How to Analyze ROS Bag Files and Build a Dataset for Machine Learning

AnthonyCvn — Wed, 30 Apr 2025 00:00:00 +0000

Working with real-world robot data depends on how ROS (Robot Operating System) messages are stored. In the article 3 Ways to Store ROS Topics, we explored several approaches — including storing compressed Rosbag files in time-series storage and storing topics as separate records.

In this tutorial, we'll focus on the most common format: .bag files recorded with Rosbag. These files contain valuable data on how a robot interacts with the world — such as odometry, camera frames, LiDAR, or IMU readings — and provide the foundation for analyzing the robot's behavior.

You’ll learn how to:

Extract motion data from .bag files
Create basic velocity features
Train a classification model to recognize different types of robot movements

We'll use the bagpy library to process .bag files and apply basic machine learning techniques for classification.

Although the examples in this tutorial use data from a Boston Dynamics Spot robot (performing movements like moving forward, sideways, and rotating), you can adapt the code for your recordings.

Install Required Libraries

!pip install numpy pandas matplotlib seaborn scikit-learn bagpy

Loading and Preprocessing Bag Files

Let's create a function to load a .bag file and extract velocity features.

In our example, the odometry data is published under the /spot/odometry topic. Make sure to specify the correct topic where your robot's motion data is recorded. Depending on your use case, you might find other features, such as accelerations or additional sensor data, more relevant for recognizing your robot's movements. For this task, we'll primarily focus on linear and angular velocities.

import numpy as np
import pandas as pd
from bagpy import bagreader

def process_bag_to_dataframe(bag_path, topic='/spot/odometry', target_label=0):

    # Load a .bag file and generate a DataFrame with velocity features and a target label

    bag = bagreader(bag_path)
    df = pd.read_csv(bag.message_by_topic(topic))

    # Calculate linear and angular velocities
    df['linear_velocity'] = np.sqrt(df['twist.twist.linear.x']**2 +
                                    df['twist.twist.linear.y']**2 +
                                    df['twist.twist.linear.z']**2)

    df['angular_velocity'] = np.sqrt(df['twist.twist.angular.x']**2 +
                                     df['twist.twist.angular.y']**2 +
                                     df['twist.twist.angular.z']**2)

    # Assign target label
    df['target'] = target_label

    # Keep only relevant columns
    return df[['twist.twist.linear.x', 'twist.twist.linear.y', 'twist.twist.linear.z',
               'twist.twist.angular.x', 'twist.twist.angular.y', 'twist.twist.angular.z',
               'linear_velocity', 'angular_velocity', 'target']]

Processing three different movement types

Let's use the process_bag_to_dataframe function to load and process the data for each of the three movement types. Each movement type was recorded in a separate .bag file, so we'll apply the function to each file individually, and then merge the results into a single DataFrame.

df_forward = process_bag_to_dataframe('linear_x.bag', target_label=1)   # moving forward
df_sideways = process_bag_to_dataframe('linear_y.bag', target_label=2)  # moving sideways
df_rotation = process_bag_to_dataframe('rotation.bag', target_label=3)  # rotating

# Combine all samples
df_all = pd.concat([df_forward, df_sideways, df_rotation], ignore_index=True)

Visualizing velocities

We can visualize the linear and angular velocities over time for each type of motion, as shown in the example for the forward movement. This will help us better understand how the velocities change during each specific motion.

import matplotlib.pyplot as plt

def plot_velocities(df, title=''):

    plt.figure(figsize=(7, 3))

    plt.subplot(1, 2, 1)
    plt.plot(df['linear_velocity'], color='#4B0082')
    plt.title('Linear Velocity')
    plt.xlabel('Time Step')

    plt.subplot(1, 2, 2)
    plt.plot(df['angular_velocity'], color='#9A9E5E')
    plt.title('Angular Velocity')
    plt.xlabel('Time Step')

    plt.suptitle(title)
    plt.tight_layout()
    plt.show()

plot_velocities(df_forward, 'Forward Movement')

Training and Evaluating Classification Models

We'll test several popular models, including Logistic Regression, Decision Tree, Random Forest, and Support Vector Machine, and tune their hyperparameters using GridSearchCV. You can also experiment with other hyperparameters to optimize the models based on your specific data and requirements.

To evaluate the classifier, we'll use the F1 Score metric, which balances precision and recall and is especially useful for imbalanced datasets. However, you can also choose to evaluate using Accuracy, Precision, or Recall, depending on your needs.

Now, let's prepare the data for training.

X = df_all.drop('target', axis=1)
y = df_all['target']

The features X consist of the velocity data, and the labels y represent the different movement types.

Next, let’s define the scalers, models, and their respective hyperparameters.

from sklearn.preprocessing import StandardScaler, MinMaxScaler, RobustScaler
from sklearn.linear_model import LogisticRegression
from sklearn.tree import DecisionTreeClassifier
from sklearn.ensemble import RandomForestClassifier
from sklearn.svm import SVC

# Scalers
scalers = {
    'Standard Scaler': StandardScaler(),
    'MinMax Scaler': MinMaxScaler(),
    'Robust Scaler': RobustScaler()
}

# Models
models = {
    'Logistic Regression': LogisticRegression(max_iter=10000),
    'Decision Tree': DecisionTreeClassifier(),
    'Random Forest': RandomForestClassifier(),
    'SVM': SVC(probability=True)
}

# Hyperparameters for tuning
parameters = {
    'Logistic Regression': {'C': [0.01, 0.1, 1, 10, 100]},
    'Decision Tree': {'max_depth': [3, 5, 10, None]},
    'Random Forest': {'n_estimators': [50, 100]},
    'SVM': {'C': [0.1, 1, 10], 'kernel': ['linear', 'rbf']}
}

Let's train and test the models using the defined scalers, models, and hyperparameters.

from sklearn.model_selection import train_test_split, GridSearchCV, StratifiedKFold
from sklearn.metrics import f1_score, confusion_matrix

def run_classification(model_name, scaler_name, X, y):

    # Split data into train and test sets
    X_train, X_test, y_train, y_test = train_test_split(X, y, stratify=y, test_size=0.2)

    # Apply the chosen scaler to the data
    scaler = scalers[scaler_name]
    X_train = scaler.fit_transform(X_train)
    X_test = scaler.transform(X_test)

    # Set up hyperparameter grid and cross-validation
    param_grid = parameters[model_name]
    cv = StratifiedKFold(n_splits=5, shuffle=True)
    grid = GridSearchCV(models[model_name], param_grid, cv=cv, scoring='f1_weighted')
    grid.fit(X_train, y_train)

    # Get the best model from the grid search
    best_model = grid.best_estimator_

    # Make predictions on the test set
    y_pred = best_model.predict(X_test)

    print(f'Best parameters: {grid.best_params_}')
    print(f'F1 Score: {f1_score(y_test, y_pred, average="weighted"):.3f}')

    return y_test, y_pred, best_model, X.columns

After training and testing the models, we'll plot the confusion matrix to visualize how well our model is performing by comparing the predicted labels with the actual labels.

import seaborn as sns

# Plot confusion matrix
def plot_confusion_matrix(y_test, y_pred):

    cm = confusion_matrix(y_test, y_pred)

    sns.heatmap(cm, annot=True, fmt='d', cmap='Purples')
    plt.title('Confusion Matrix')
    plt.xlabel('Predicted')
    plt.ylabel('Actual')
    plt.show()

After evaluating the model's performance, we’ll visualize the feature importance for the Decision Tree and Random Forest models to understand which features contribute the most to the model’s predictions.

# Feature importance for Decision Tree and Random Forest
def plot_feature_importance(best_model, X_columns):

    importances = best_model.feature_importances_
    sorted_idx = importances.argsort()[::-1]

    sns.barplot(x=importances[sorted_idx], y=X_columns[sorted_idx], color='#50208B')
    plt.title('Feature Importances')
    plt.xticks(rotation=90)
    plt.tight_layout()
    plt.show()

Training a Random Forest classifier

Finally, let's apply the Random Forest classifier to our data and evaluate its performance.

y_test, y_pred, best_model, X_columns = run_classification('Random Forest', 'MinMax Scaler', X, y)

The optimal parameter for n_estimators is 100 , and the model achieved an F1 score of 0.976.

We’ll plot the confusion matrix to assess the classifier's performance across different movement types. The diagonal elements represent the correctly classified instances, while the off-diagonal elements indicate the misclassifications.

plot_confusion_matrix(y_test, y_pred)

After evaluating the Random Forest model, we can check the Feature Importance to see which velocity components were most important in distinguishing the movement types. This is especially useful for Decision Tree and Random Forest models, as they automatically rank features by their importance.

plot_feature_importance(best_model, X_columns)

Best practices

When working with .bag files and training machine learning models, these best practices can help you manage data more effectively and build better-performing models:

Split large files: If your .bag files are too large, divide them into smaller episodes. This helps avoid memory issues and makes the files easier to process.
Separate topics by type: If your .bag file includes both lightweight messages (like battery level) and large data streams (like images or LiDAR), store them in separate .bag files. This separation can optimize performance and make your workflow simpler.
Use Randomized Search for tuning: If your model’s accuracy isn’t good enough, try using RandomizedSearchCV instead of GridSearchCV. It can find the best hyperparameters faster and more efficiently.
Try different algorithms: Experiment with different algorithms to find what works best for your specific data.
Consider ensemble methods: Techniques like bagging or boosting can improve accuracy by combining multiple models and leveraging their strengths.
Explore deep learning: If you have a large dataset and enough computing power, deep learning models can capture complex patterns that simpler models may miss.
Prevent overfitting: Make sure that your model generalizes well by splitting your dataset into training, validation, and test sets. Use cross-validation to evaluate your model’s performance more reliably.

Conclusion

In this tutorial, we walked through the process of handling robot movement data stored in .bag files. We extracted key velocity features and used them to train machine learning models for classifying different types of robot movements.

As a next step, you can experiment with various models, hyperparameters, or additional features to improve classification performance. You can also explore advanced techniques such as deep learning for more complex tasks.

We hope this tutorial provided a clear starting point for processing robot data and building basic movement classification models. If you have any questions or comments, feel free to use the ReductStore Community Forum.

How to Store and Manage ROS Data

AnthonyCvn — Wed, 02 Apr 2025 00:00:00 +0000

In this tutorial, we will create a custom ROS 2 Humble package called rosbag2reduct that records incoming ROS 2 topics into MCAP bag files on a Raspberry Pi and automatically uploads those files to a ReductStore instance with metadata labels. We'll walk through setting up ROS 2 Humble on the Pi, interfacing a USB camera using the v4l2_camera driver, deploying a lightweight YOLOv5 (nano) object detection node (using ONNX Runtime) to produce detection metadata, and implementing the rosbag2reduct node to capture data and offload it. We will also cover installing ReductStore on the Pi, configuring replication of labeled data to a central storage on your laptop (using label-based filters via the web console). This end-to-end guide is structured with clear steps, code examples, and configuration snippets to help you build and deploy the system.

Prerequisites and Architecture

Before beginning, ensure you have the following:

Hardware: Raspberry Pi, a USB camera, and an internet connection.
OS: Ubuntu or Desktop Server (22.04 LTS or later) on the Raspberry Pi.
Laptop/PC: A separate machine on the same network, to serve as a central data store.

In this tutorial, we will set up the following architecture:

Architecture: Raspberry Pi with ROS 2, USB camera, YOLOv5n, and ReductStore; Laptop with ReductStore Web Console.

Raspberry Pi: Running ROS 2 Humble, interfacing with a USB camera, and running a YOLOv5n object detection node with ONNX Runtime.
Laptop/PC: Running a ReductStore instance (acting as a central data store) and ReductStore's Web Console for managing data.
Network: The Pi and the laptop are on the same network. The Pi will upload data to the ReductStore instance on the laptop automatically.

1. Install Ubuntu on Raspberry Pi

If not already done, flash Ubuntu for Raspberry Pi on a microSD card and boot your Pi. You can download Ubuntu images for Raspberry Pi from the official site. Ensure you have internet access and update the system:

# On Raspberry Pi
sudo apt update && sudo apt upgrade -y

2. Install ROS 2 Humble on Raspberry Pi

Follow the steps below to set up ROS 2 on your Raspberry Pi. This guide assumes you are using a supported 64-bit Ubuntu OS (e.g., 22.04, 24.04). ROS 2 is available in multiple distributions such as Jazzy , Humble , and Noetic. If you're unsure, we recommend using the latest LTS version , which we can install via the commands below.

Setup Locale:
Add ROS 2 apt Repository:
Install ROS 2 Packages: For a baseline, install ROS 2 base packages (or ros-<distro>-desktop if you need GUI tools):
Install Build Tools: We will create custom packages, so install development tools:

3. Create a ROS 2 Workspace

Set up a workspace for our project (if you don't have one):

# On Raspberry Pi
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws
colcon build # just to initialize, will be empty initially

Add source ~/ros2_ws/install/setup.bash to your ~/.bashrc so that the workspace is sourced on each new shell, or remember to source it in each terminal when using the workspace. We will add packages to this workspace in subsequent steps.

Setting up the USB Camera with `v4l2_camera`

We'll use the v4l2_camera ROS 2 package to interface with the USB camera via Video4Linux2. This package publishes images from any V4L2-compatible camera (most USB webcams) as ROS 2 image topics.

1. Install the `v4l2_camera` Package

On the Raspberry Pi, install the driver node via apt:

sudo apt install ros-${ROS_DISTRO}-v4l2-camera -y

This installs the v4l2_camera node and its dependencies. Alternatively, you could build it from source, but the binary is available for Humble.

2. Connect and Verify the Camera

Plug in the USB camera to the Pi. Verify that it's recognized by listing video devices:

ls /dev/video* # You should see /dev/video0 (and possibly /dev/video1, etc. if multiple video capture interfaces are connected)

If /dev/video0 is present, the system sees the camera (at list one). You might also install v4l2-utils and run v4l2-ctl --list-devices to see the camera name and capabilities. You can also run v4l2-ctl --list-formats-ext to see supported resolutions and formats.

3. Run the Camera Node

Launch the camera driver to start publishing images:

# In a sourced ROS 2 environment on the Pi
ros2 run v4l2_camera v4l2_camera_node

By default, this node will open /dev/video0 and start publishing images to the ~/image_raw topic (type sensor_msgs/Image) at a default resolution of 640x480 and pixel format YUYV converted to rgb8 (see ROS 2 camera driver for Video4Linux2 Documentation). You should see console output from the node indicating it opened the device and is streaming.

Open a new terminal (with ROS sourced) on the Pi (or from a laptop connected to the ROS 2 network) and verify images are coming through, e.g., by running rqt_image_view:

sudo apt install ros-${ROS_DISTRO}-rqt-image-view -y # if not installed
ros2 run rqt_image_view rqt_image_view

In rqt_image_view, select /image_raw to view the camera feed. This confirms the camera setup is working.

Note: You can adjust parameters by remapping or via ROS 2 parameters, e.g., to change resolution or device:

ros2 run v4l2_camera v4l2_camera_node --ros-args -p image_size:="[1280,720]" -p video_device:="/dev/video0"

This would set the camera to 1280x720 resolution (if supported).

Deploying a Lightweight YOLOv5 Object Detection Node

Next, we set up an object detection node to analyze the camera images and output metadata (object_detected and confidence_score). We'll use YOLOv5n (Nano) - the smallest YOLOv5 model ("only" 1.9 million parameters) which is ideal for resource-constrained devices (see releases at ultralytics/yolov5). We will run inference using the ONNX Runtime, which allows running the model without needing the full PyTorch framework on the Pi.

1. Install ONNX Runtime and Dependencies

On the Raspberry Pi, install the ONNX Runtime Python package and OpenCV (for image processing):

pip install onnxruntime opencv-python

(If pip isn't available, use sudo apt install python3-pip to install it. You may also install numpy if not already present, as ONNX Runtime will likely need it.)

2. YOLOv5n ONNX Model

We need the YOLOv5n model in ONNX format. To do that, we can clone the YOLOv5 repository on a more powerful machine than the Pi and export the model:

# On a PC or via Colab:
git clone https://github.com/ultralytics/yolov5.gitcd yolov5
pip install -r requirements.txt # includes PyTorch
python export.py --weights yolov5n.pt --include onnx

This will create yolov5n.onnx. Transfer that file to your Raspberry Pi (e.g., via SCP).

For this tutorial, assume yolov5n.onnx is now on the Raspberry Pi (e.g., placed in ~/ros2_ws/src).

3. Create a ROS 2 Package for the YOLO Node (optional)

You can integrate the YOLO inference in the same package as rosbag2reduct, but for modularity, let's create a separate ROS 2 Python package called yolo_detector.

In the workspace src directory, run:

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_python yolo_detector --dependencies rclpy sensor_msgs std_msgs

This will create a yolo_detector folder with a Python package structure. Edit yolo_detector/package.xml to add dependencies for opencv-python and onnxruntime (since these are non-ROS dependencies, we list them for documentation; you might use pip in the installation step rather than rosdep). For example, inside <exec_depend> tags, add:

<exec_depend>onnxruntime</exec_depend>
<exec_depend>opencv-python</exec_depend>

4. Implement the YOLO Detection Node

Create a file yolo_detector/yolo_detector/yolo_node.py with the following content:

YoloDetectorNode (Python code)

import rclpy
from rclpy.node import Node
from sensor_msgs.msg import Image
from std_msgs.msg import String, Float32
import cv2
import numpy as np
import onnxruntime as ort

class YoloDetectorNode(Node):
    def __init__(self):
        super().__init__('yolo_detector')
        # Load the YOLOv5n ONNX model
        model_path = '/path/to/yolov5n.onnx'  # TODO: update to actual path
        self.session = ort.InferenceSession(model_path, providers=['CPUExecutionProvider'])
        self.get_logger().info(f"Loaded model {model_path}")

        # Get model input details for preprocessing
        model_inputs = self.session.get_inputs()
        self.input_name = model_inputs[0].name
        self.input_shape = model_inputs[0].shape  # e.g., [1, 3, 640, 640]
        self.img_height = self.input_shape[2]
        self.img_width = self.input_shape[3]

        # Subscribers and publishers
        self.subscription = self.create_subscription(Image, '/image_raw', self.image_callback, 10)
        self.pub_object = self.create_publisher(String, 'object_detected', 10)
        self.pub_conf = self.create_publisher(Float32, 'confidence_score', 10)

        # If the model requires normalization factors or specific transformations, define them:
        self.mean = np.array([0.0, 0.0, 0.0])  # YOLOv5 models assume 0-255 input, no mean subtraction
        self.std = np.array([255.0, 255.0, 255.0])  # we'll scale 0-1 later by dividing by 255

    def image_callback(self, msg: Image):
        # Convert ROS Image message to OpenCV format (BGR array)
        # Assuming msg.encoding is 'rgb8' as provided by v4l2_camera default output
        img = np.frombuffer(msg.data, dtype=np.uint8).reshape(msg.height, msg.width, -1)
        # Convert RGB to BGR as YOLO model might expect BGR input (depending on training)
        img_bgr = cv2.cvtColor(img, cv2.COLOR_RGB2BGR)

        # Resize and pad image to model input shape (letterboxing if needed)
        input_img = cv2.resize(img_bgr, (self.img_width, self.img_height))
        # Convert to float32 and normalize 0-1
        input_img = input_img.astype('float32') / 255.0
        # transpose to [channels, height, width]
        input_blob = np.transpose(input_img, (2, 0, 1))
        input_blob = np.expand_dims(input_blob, axis=0)  # shape [1,3,H,W]

        # Run inference
        outputs = self.session.run(None, {self.input_name: input_blob})

        # Parse outputs to find the highest confidence detection (for simplicity)
        # YOLOv5 ONNX output typically includes [1, num_boxes, 85] array (for COCO: 4 box coords, 1 objness, 80 class scores)
        detections = outputs[0]
        # Filter by confidence threshold (e.g., 0.5)
        conf_threshold = 0.5
        best_label = "none"
        best_conf = 0.0
        if detections is not None:
            for det in detections[0]:
                obj_conf = det[4]
                class_conf = det[5:]  # class confidences
                score = obj_conf * np.max(class_conf)
                class_id = np.argmax(class_conf)
                if score > conf_threshold and score > best_conf:
                    best_conf = float(score)
                    best_label = str(class_id)  # or use a class id->name mapping

        # Publish results
        self.pub_object.publish(String(data=best_label))
        self.pub_conf.publish(Float32(data=best_conf))
        self.get_logger().info(f"Detected: {best_label} ({best_conf:.2f})")

def main(args=None):
    rclpy.init(args=args)
    node = YoloDetectorNode()
    rclpy.spin(node)
    node.destroy_node()
    rclpy.shutdown()

Explanation: This node subscribes to the camera images (/image_raw), processes each frame through the YOLOv5n model, and publishes two topics:

object_detected (std_msgs/String): the class label (or ID) of the primary detected object (or "none" if none above threshold).
confidence_score (std_msgs/Float32): the confidence score of that detection.

For simplicity, we took the detection with highest confidence above a threshold. In a real scenario, you probably output multiple detections or more info (bounding boxes, etc.), but we only need metadata for this tutorial.

Make sure to adjust the model_path to the actual location of your yolov5n.onnx. Also note that without class name mapping, best_label is currently the class index (as string). You can map this index to an actual label (e.g., using the COCO class list below).

COCO Class List

names:
  0: person
  1: bicycle
  2: car
  3: motorcycle
  4: airplane
  5: bus
  6: train
  7: truck
  8: boat
  9: traffic light
  10: fire hydrant
  11: stop sign
  12: parking meter
  13: bench
  14: bird
  15: cat
  16: dog
  17: horse
  18: sheep
  19: cow
  20: elephant
  21: bear
  22: zebra
  23: giraffe
  24: backpack
  25: umbrella
  26: handbag
  27: tie
  28: suitcase
  29: frisbee
  30: skis
  31: snowboard
  32: sports ball
  33: kite
  34: baseball bat
  35: baseball glove
  36: skateboard
  37: surfboard
  38: tennis racket
  39: bottle
  40: wine glass
  41: cup
  42: fork
  43: knife
  44: spoon
  45: bowl
  46: banana
  47: apple
  48: sandwich
  49: orange
  50: broccoli
  51: carrot
  52: hot dog
  53: pizza
  54: donut
  55: cake
  56: chair
  57: couch
  58: potted plant
  59: bed
  60: dining table
  61: toilet
  62: tv
  63: laptop
  64: mouse
  65: remote
  66: keyboard
  67: cell phone
  68: microwave
  69: oven
  70: toaster
  71: sink
  72: refrigerator
  73: book
  74: clock
  75: vase
  76: scissors
  77: teddy bear
  78: hair drier
  79: toothbrush

Also, update setup.py entry points to include our node script:

setup(
    ...
    entry_points={
        'console_scripts': [
            'yolo_node = yolo_detector.yolo_node:main',
        ],
    },
)

5. Build and Run the YOLO Node

Add onnxruntime and opencv-python to your workspace's requirements (you might include them in a requirements.txt for the package and use pip to install, since they are pip packages). For now, ensure they are installed via pip as done earlier.

Build the workspace:

cd ~/ros2_ws
colcon build --packages-select yolo_detector
source install/local_setup.bash

Run the YOLO detection node in a new terminal on the Pi:

ros2 run yolo_detector yolo_node.py

You should see log output from the node whenever it processes an image (every frame or at least when something is detected, depending on your logging). The node will publish messages on object_detected and confidence_score topics.

You can echo these topics in another terminal to verify:

ros2 topic echo /object_detected
ros2 topic echo /confidence_score

For example, if a person is detected with 85% confidence. You should see messages like:

object: "0"
confidence: 0.85

Now we have a camera streaming images and a detector outputting metadata. Next, we'll create the rosbag2reduct package to record these data and handle file rotation and uploading to ReductStore.

Creating the `rosbag2reduct` Package

Our rosbag2reduct package will be a ROS 2 node that does the following:

Subscribe to the relevant topics (e.g. /image_raw, object_detected, confidence_score).
Record those topics into a bag file using the rosbag2 Python API (in MCAP format).
Label each bag file with the latest detection metadata.
After a fixed time interval (bag rotation period), close the current bag, then upload it to ReductStore with Python client SDK, including the metadata as labels, and delete the local bag file.
Start a new bag file and repeat.

warning

This is not optimal (writing to disk then uploading) and is done for simplicity. In a real scenario, you should stream directly to ReductStore or separate storage topics by type. More on this in the Best Practices and Further Improvements section.

1. Create the Package Structure

Run the ROS 2 package creation command:

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_python rosbag2reduct --dependencies rclpy rosbag2_py sensor_msgs std_msgs

This creates a new folder rosbag2reduct with a basic Python package setup. Update rosbag2reduct/package.xml to include <exec_depend>reduct-py</exec_depend> (ReductStore's Python SDK) since we'll use that. Also make sure rosbag2_py is listed as a dependency (the above command included it). In setup.py, add an entry point for our main node if desired (though we can also run the Python file directly with ros2 run as long as it's installed).

After creation, the structure should look like:

ros2_ws/src/rosbag2reduct/
├── package.xml
├── setup.cfg
├── setup.py
├── resource/
│   └── rosbag2reduct
└── rosbag2reduct
    ├── __init__.py
    └── recorder_node.py   # (we will create this)

2. Install ReductStore Python SDK and MCAP Support

Before coding, install the ReductStore client library (reduct-py) in your Python environment:

pip install reduct-py

This gives us the reduct module for interacting with a ReductStore server. (We will set up the actual ReductStore server on the Pi soon, but we can write the code first.)

Also, install the MCAP storage format support for rosbag2:

sudo apt install ros-${ROS_DISTRO}-rosbag2-storage-mcap

3. Implementing the `rosbag2reduct` Node

Open a new file rosbag2reduct/recorder_node.py and add the following code from the snippet below. This code defines the Rosbag2ReductNode class, which is a ROS 2 node that subscribes to the camera images and metadata topics, records them into bag files, and uploads the bag files to ReductStore with metadata labels.

Rosbag2ReductNode (Python code)

import rclpy
from rclpy.node import Node
from std_msgs.msg import String, Float32
from sensor_msgs.msg import Image

from rclpy.serialization import serialize_message
from rosbag2_py import SequentialWriter, StorageOptions, ConverterOptions, TopicMetadata

import os
import shutil
import datetime
import asyncio
from reduct import Client, Bucket


class Rosbag2ReductNode(Node):
    def __init__(self):
        super().__init__('rosbag2reduct')
        self.bag_duration = 60.0
        self.storage_id = 'mcap'  # Or 'sqlite3'

        self.current_bag_index = 0
        self.writer = None
        self.current_bag_name = self._open_new_bag()

        self.create_subscription(Image, '/image_raw', self._image_callback, 10)
        self.create_subscription(String, 'object_detected', lambda msg: self._metadata_callback(msg, 'object_detected'), 10)
        self.create_subscription(Float32, 'confidence_score', lambda msg: self._metadata_callback(msg, 'confidence_score'), 10)

        self.last_object_detected = "none"
        self.last_confidence = 0.0

        self.create_timer(self.bag_duration, self._rotate_bag_timer)

        self.reduct_url = "http://127.0.0.1:8383"
        self.bucket_name = "pi_robot"
        self.entry_name = "rosbags"
        self.reduct_client = Client(self.reduct_url)
        asyncio.get_event_loop().run_until_complete(self._ensure_bucket())
        self.get_logger().info(
            f"rosbag2reduct node initialized, writing to {self.storage_id} bags and uploading to ReductStore bucket '{self.bucket_name}'.")

    def _open_new_bag(self):
        self.writer = SequentialWriter()
        bag_name = f"rosbag_{datetime.datetime.now().strftime('%Y%m%d_%H%M%S')}_{self.current_bag_index}"
        storage_options = StorageOptions(uri=bag_name, storage_id=self.storage_id)
        converter_options = ConverterOptions('', '')
        self.writer.open(storage_options, converter_options)

        self.writer.create_topic(TopicMetadata(
            name='/image_raw',
            type='sensor_msgs/msg/Image',
            serialization_format='cdr'))
        self.writer.create_topic(TopicMetadata(
            name='object_detected',
            type='std_msgs/msg/String',
            serialization_format='cdr'))
        self.writer.create_topic(TopicMetadata(
            name='confidence_score',
            type='std_msgs/msg/Float32',
            serialization_format='cdr'))

        self.writer.create_topic(TopicMetadata(
            0,
            '/image_raw',
            'sensor_msgs/msg/Image',
            'cdr'
        ))
        self.writer.create_topic(TopicMetadata(
            0,
            'object_detected',
            'std_msgs/msg/String',
            'cdr'
        ))
        self.writer.create_topic(TopicMetadata(
            0,
            'confidence_score',
            'std_msgs/msg/Float32',
            'cdr'
        ))

        self.get_logger().info(f"Opened new bag: {bag_name}")
        return bag_name

    def _image_callback(self, msg: Image):
        self.writer.write('/image_raw', serialize_message(msg), self.get_clock().now().nanoseconds)

    def _metadata_callback(self, msg, topic_name):
        if topic_name == 'object_detected':
            self.last_object_detected = msg.data
            self.writer.write('object_detected', serialize_message(msg), self.get_clock().now().nanoseconds)
        elif topic_name == 'confidence_score':
            self.last_confidence = msg.data
            self.writer.write('confidence_score', serialize_message(msg), self.get_clock().now().nanoseconds)

    def _rotate_bag_timer(self):
        object_label = self.last_object_detected
        confidence_val = float(self.last_confidence)
        old_bag_name = self.current_bag_name

        self.current_bag_index += 1
        self.current_bag_name = self._open_new_bag()

        self.get_logger().info(f"Uploading bag {old_bag_name} with metadata: object={object_label}, confidence={confidence_val:.2f}")
        asyncio.get_event_loop().run_until_complete(
            self._upload_bag_file(old_bag_name, object_label, confidence_val))

        # Clean up the bag directory if a file was uploaded
        bag_dir = old_bag_name
        if os.path.isdir(bag_dir):
            try:
                shutil.rmtree(bag_dir)
                self.get_logger().info(f"Deleted bag directory {bag_dir} after upload.")
            except Exception as e:
                self.get_logger().warn(f"Could not delete directory {bag_dir}: {e}")
        else:
            self.get_logger().warn(f"Bag directory {bag_dir} not found.")

    async def _ensure_bucket(self):
        await self.reduct_client.create_bucket(self.bucket_name, exist_ok=True)

    async def _upload_bag_file(self, bag_name, object_label, confidence_val):
        bag_dir = bag_name
        mcap_file = None

        # Find the first .mcap file in the bag directory
        try:
            for filename in os.listdir(bag_dir):
                if filename.endswith(".mcap"):
                    mcap_file = os.path.join(bag_dir, filename)
                    break
        except FileNotFoundError:
            self.get_logger().error(f"Bag directory {bag_dir} does not exist.")
            return

        if not mcap_file:
            self.get_logger().warn(f"No .mcap file found in {bag_dir} — skipping upload.")
            return

        try:
            with open(mcap_file, 'rb') as f:
                data = f.read()
        except Exception as e:
            self.get_logger().error(f"Error reading {mcap_file}: {e}")
            return

        bucket: Bucket = await self.reduct_client.get_bucket(self.bucket_name)
        timestamp = datetime.datetime.utcnow().isoformat() + "Z"
        labels = {"object": object_label, "confidence": str(confidence_val)}
        await bucket.write(self.entry_name, data, timestamp=timestamp, labels=labels)
        self.get_logger().info(f"Uploaded {mcap_file} to ReductStore with labels {labels}.")


def main(args=None):
    rclpy.init(args=args)
    node = Rosbag2ReductNode()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    node.destroy_node()
    try:
        rclpy.shutdown()
    except Exception:
        pass

Let's break down key parts of this implementation:

We use rosbag2's Python API : SequentialWriter to record messages. We specify MCAP as the storage format when opening the bag. We explicitly register three topics (/image_raw, object_detected, confidence_score) with their message types, so we can write to them. In each subscription callback, we call self.writer.write(topic_name, serialize_message(msg), timestamp) to append to the bag.
We maintain last_object_detected and last_confidence variables to store the most recent detection metadata. The _metadata_callback updates these whenever a message on those topics arrives, and writes the message to the bag as well.
A ROS timer triggers _rotate_bag_timer() every self.bag_duration seconds (e.g., every 60 seconds). This function closes the current bag and opens a new one (by calling _open_new_bag() which increments a bag index and starts a new file). We then proceed to upload the bag file (that we just closed) to ReductStore.
ReductStore upload: Using reduct-py, we ensure a bucket named pi_robot exists in ReductStore (which we assume is running locally on the Pi at 127.0.0.1:8383). We then read the bag file into memory and use bucket.write() to store it in the bucket under the rosbags entry. We label each record with the detection metadata (e.g., labels={"object": "1", "confidence": "0.85"}).
After a successful upload, we delete the local .mcap file to save space on the Pi (since it's now stored in ReductStore).

info

This is a basic implementation. In a real-world scenario, you will likely want to handle prediction and timestamping differently, add more metadata, and of course use a more efficient way to upload data directly to ReductStore.

4. Build the `rosbag2reduct` Package

Ensure that in setup.py of rosbag2reduct you have an entry point if needed, e.g.:

entry_points={
    'console_scripts': [
        'rosbag2reduct = rosbag2reduct.recorder_node:main'
    ],
},

This will allow us to run ros2 run rosbag2reduct rosbag2reduct to launch the node. Now build the package:

cd ~/ros2_wscolcon build --packages-select rosbag2reduct
source install/local_setup.bash

If everything compiles (installs) without errors, we're ready to run the system.

Installing and Configuring ReductStore on the Raspberry Pi

Before running the rosbag2reduct node, we need a ReductStore server running on the Pi to accept uploads. ReductStore is a lightweight time-series object storage, perfect for edge devices. We will install it on the Pi and create a bucket for our bag files.

1. Install ReductStore on Raspberry Pi

The easiest way on Ubuntu is to use snap or Docker. We'll use snap for simplicity:

# On Raspberry Pi
sudo apt update
sudo apt install snapd -y # if snapd is not already installed
sudo snap install reductstore

This will install ReductStore from the Snap Store. The snap should set up ReductStore as a service listening on port 8383 by default. (If using a different OS or if snap isn't desired, you can use Docker: e.g., docker run -d -p 8383:8383 -v ~/reduct_data:/data reduct/store:latest to run ReductStore in a container.)

Note: The database will listen on http://0.0.0.0:8383 (accessible to the LAN). Ensure this port is allowed through any firewall if you want external access.

Check that ReductStore is running:

sudo snap services reductstore # should show active
curl http://127.0.0.1:8383/api/v1/info

The curl command should return JSON info about the instance (like version, uptime, etc.).

2. (Optional) Configure ReductStore

By default, ReductStore doesn't require authentication for local use (anonymous access is allowed). This is fine for our edge scenario on a local network. If you want to set up access tokens or adjust storage quotas, you can do so by following the Access Control documentation. For now, we'll use defaults.

We will use the Web Console to verify data and to set up replication later. The web console is accessible from a browser at the server's address (it's the same as the API endpoint). For example, on the Pi, open http://<raspberrypi_ip>:8383 in a browser - you should see the ReductStore Web Console interface (a simple GUI).

3. Create a Bucket for ROS bag data

Our rosbag2reduct code will attempt to create a bucket named "pi_robot". We called create_bucket("pi_robot", exist_ok=True) in the code, so the bucket will be created on first run if it doesn't exist. You can also create it manually via the web console:

Navigate to Buckets and create a new bucket named “pi_robot”. (You can set a quota, e.g., a FIFO quota to avoid filling up the disk on the Pi.)

ReductStore Web Console: Creating a bucket named "pi_robot" for storing ROS bags.

Now, ReductStore is set up on the Pi and ready to accept data. We can run the complete system to record ROS data, detect objects, and upload to ReductStore.

Running the Complete System

We have three ROS 2 nodes to run on the Raspberry Pi:

The camera driver (v4l2_camera_node)
The YOLO detection node (YoloDetectorNode)
The rosbag2reduct recorder/uploader node (Rosbag2ReductNode)

It's best to run each in its own terminal (or use a launch file to launch them together). For clarity, we'll do it step-by-step:

Terminal 1: Camera node

# Terminal 1 on Pi (source ROS 2 and workspace)
ros2 run v4l2_camera v4l2_camera_node

Terminal 2: YOLO detection node

# Terminal 2 on Pi (source ROS 2 and workspace)
ros2 run yolo_detector yolo_node.py

(If you set up the entry point, you could do ros2 run yolo_detector yolo_detector or similar, but here we assume running the script directly.)

Terminal 3: rosbag2reduct recorder node

# Terminal 3 on Pi (source ROS 2 and workspace)
ros2 run rosbag2reduct rosbag2reduct

(This uses the console script entry point we defined. Alternatively ros2 run rosbag2reduct recorder_node.py if not configured as an entry point.)

Now monitor the outputs:

The camera node should just stream (no text output unless error or warning).
The YOLO node will log detections (as we coded with get_logger().info on each detection).
The rosbag2reduct node will log bag rotations and uploads. For example, you should see logs like “Opened new bag: rosbag_20230325_101500_0” and later “Uploading bag 0 with metadata: object=person, confidence=0.85” then “Uploaded rosbag_... to ReductStore with labels ...” etc.

Let this run for a while. By default, every 60 seconds it will finalize a bag and upload it. If you want to trigger a rotation sooner (for testing), you could reduce bag_duration or even manually call the rotation function (not easily via ROS, unless you expose a service but it's not implemented here).

1. Verify Data in ReductStore

On the Pi (or from any machine that can access the Pi's port 8383), open the ReductStore Web Console in a browser: http://<raspberrypi_ip>:8383. You should see the bucket “pi_robot”. Click it to see the list of entries.

Each uploaded bag file appears as a record in the rosbags entry of the pi_robot bucket. The record name is the bag file name, and you should be able to see its labels, e.g., object: 1 and confidence: 0.85 attached to that record.. You can also see the timestamp of each record (when it was uploaded).

You have successfully set up the edge device to capture ROS data and push it to ReductStore with metadata labels!

Setting up Replication to a Central ReductStore (Laptop)

With data being collected on the Pi, we likely want to aggregate it on a central server (e.g., your laptop or a cloud instance) for analysis or long-term storage.

ReductStore's replication feature allows the Pi (source) to push new records to another ReductStore instance (destination) in real-time, filtering by labels so that, for example, only important events (e.g., specific objects or high-confidence detections) are sent for long-term storage.

info

Replication lets you stream only the data you need from the edge to the cloud or between edge devices. You can filter by label and push data without constant polling. If the device is offline or the destination is down, the data waits and replicates later.

In this section, we'll:

Run ReductStore on the laptop.
Use the ReductStore Web Console to create a replication task on the Pi's instance that filters and forwards data to the laptop's instance based on labels.
Verify that replication works.

1. Install/Run ReductStore on Laptop

On your laptop (assuming Ubuntu 22.04 or any system with Docker or Snap):

Option A: Docker - run ReductStore in a container:
Option B: Native - you could similarly install via Snap (sudo snap install reductstore) or use a binary. Docker is quick and easy.

After starting it, ensure you can access it:

curl http://127.0.0.1:8383/api/v1/info

should return info as before (but for the laptop's instance).

Open the web console on the laptop: http://localhost:8383 and keep it open for monitoring.

Create a bucket named “pi_robot” on the laptop as well, otherwise the replication task will fail (it needs the destination bucket to exist).

tip

Use provisioning to automate bucket creation and other setup steps in a real deployment. See Configuration/Provisioning Documentation for more.

Networking: Make sure your laptop is accessible from the Pi. If both are on the same LAN, you might use the laptop's IP (e.g., 192.168.x.x). If the laptop's ReductStore is in Docker, ensure the port 8383 is open (it is published in the run command above). For testing, you might temporarily disable firewall or ensure port 8383 is allowed.

Find your laptop's IP address (e.g., hostname -I on Linux) - let's say it's 192.168.1.100 for example.

2. Configure Replication on the Pi via Web Console

On the Pi's web console ( http://<raspberrypi_ip>:8383 ), look for “Replications” and the “+” to add replication). We want to create a replication task that sends data to the laptop.

Fill in the replication settings as:

Source Bucket: pi_robot (on Pi)
Destination URL: http://<laptop_ip>:8383 (e.g., http://192.168.1.100:8383)
Destination Bucket: pi_robot (on laptop)
Replication Name: (give it a name like “to_laptop”)
Entries: rosbags (or whatever entry name you used in bucket.write()), or leave blank to replicate all entries.
Filter Records : add the "Exclude" filter rule for object equals "none".

Start the replication task. The Pi's ReductStore will now start forwarding new records that meet the criteria to the laptop, in real-time. It's a push model from Pi to laptop, so the laptop doesn't need to know about the Pi or poll it - the Pi will push new records as they arrive.

ReductStore Web Console: Setting up a replication task to forward data to a central storage.

3. Test Replication

Back on the Pi, ensure the rosbag2reduct node is still running and creating new records. When the next bag file is uploaded on the Pi, if it meets the replication filter conditions, the Pi's ReductStore replication task will immediately send it to the laptop.

On the laptop's web console , open the “pi_robot” bucket. You should start seeing records appear that correspond to those on the Pi (with a slight delay for transfer). The labels should also be present. If you configured a filter (e.g., confidence > 0.8), try to produce a detection above that confidence on the Pi (point the camera at an easily recognized object or adjust threshold on the Pi code for testing).

Records not meeting the condition will stay only on the Pi and eventually be overwritten if Pi's FIFO quota is set.

You can also check the replication status on the Pi's web console; it may show last replicated record timestamp etc., indicating it's working.

At this point, we have a robust pipeline:

Raspberry Pi captures camera data and detection metadata.
rosbag2reduct segments the data into time-based bags, labels them, and pushes to local storage.
ReductStore on Pi retains recent data and automatically forwards critical data to the laptop's ReductStore based on labels.
The laptop accumulates the forwarded data in its own ReductStore bucket, which you can browse or integrate with other systems.

Best Practices and Further Improvements

This tutorial only scratches the surface of building a robust data acquisition and storage pipeline for robotics. Here are some best practices and further improvements to consider:

📊 Separate Storage Topics by Types

Separate storage streams for different topic categories (e.g., telemetry vs. raw sensor data) to optimise storage and retrieval. This allows you to apply different retention policies, access controls, or replication rules to each category.

📖 See 3 Ways to Store ROS Topics
📘 Example: How to Store Images in ROS 2

Here are some common data categories and their characteristics to consider:

Category	Examples	Characteristics
Lightweight telemetry	GPS, IMU, joint states, system status	Low bandwidth, near real-time, useful for business analytics
Downsampled sensor data	Lower framerate/resolution camera or lidar data	Mid-size, great for monitoring and incident triage
Full-resolution data	Raw camera frames, high-fps lidar, depth maps	High volume (up to 1TB/hour), needed for debugging or model retraining

🗜️ Compress High-Bandwidth Topics

We can se ROS 2's built-in compression mechanisms for image topics and large messages to reduce bandwidth and storage costs.

🖼️ Example: Use /image_raw/compressed instead of raw image streams

🔐 Use Token-Based Authentication

This is especially relevant for cloud storage or remote ReductStore instances. Use access tokens to secure data transfers and prevent unauthorized access.

⚙️ Use Non-Blocking Operations

When uploading large files or performing storage operations, use non-blocking (asynchronous) methods to avoid freezing your ROS 2 nodes. This keeps your system responsive and prevents dropped messages or missed frames.

📉 Combine Downsampling with Replication

This is typical in ELT (Extract-Load-Transform) pipelines. The idea is to save everything locally (on the robot) at high resolution and framerate, then stream part of the data to the cloud or a central server at a lower resolution or lower frequency.

➡️ Example: Store 1 FPS video in cloud, keep 30 FPS original on robot SSD
🔄 See example in: Building a Data Acquisition System for Manufacturing

❄️ Offload Data to Cold Storage

For long-term archiving, consider offloading data to cold storage to reduce costs while keeping data accessible.

⚖️ Example: Keep 30 days of data locally, archive older data to Google Cloud Storage.
📖 Guide: Deploy on ReductStore Cloud

Conclusion

In this tutorial, we set up a complete pipeline on a Raspberry Pi running ROS 2 Humble that captures camera data and AI output, records it to MCAP bag files with a custom Python node, and automatically offloads those files to a time-series object store. We added labels to each record (object ID detected and YOLO's confidence level). We configured replication to forward labeled data to a central instance on a laptop, filtering by labels to reduce bandwidth - for example, forwarding only "interesting" events (excluding "none" detections).

The end-to-end system demonstrates how to build a robust data logging and centralized storage solution for robotics. Of course, this tutorial must be adapted to your specific use case and environment. Keep in mind that the pipeline is highly customizable and can be adapted to different scenarios (separating topics by type, using specific filters, adding more metadata, etc.).

We hope this end-to-end tutorial helps you build your own ROS 2 data acquisition system. Happy hacking!

Thanks for reading, I hope this article will help you choose the right storage strategy for your vibration data. If you have any questions or comments, feel free to use the ReductStore Community Forum.

ReductStore vs. MinIO: Beyond Benchmarks

AnthonyCvn — Tue, 25 Mar 2025 00:00:00 +0000

As data-driven applications evolve, the need for efficient storage solutions continues to grow. ReductStore and MinIO are two powerful solutions designed to handle massive amounts of unstructured data, but they serve different purposes.

While ReductStore is optimized for time-series object storage with a focus on unstructured data such as sensor logs, images, and machine-generated data for robotics and IIoT, MinIO is a high-performance object storage system built for scalable, cloud-native applications with a focus on S3 compatibility and enterprise-wide storage needs.

In this article, we'll explore the differences between ReductStore and MinIO, examine where each excels, and discuss how they can be used together to build a more comprehensive data storage solution.

Understanding MinIO: The Scalable Cloud-Native Object Storage

MinIO is an open-source object storage system that provides a high-performance, S3-compatible API for storing and managing unstructured data. Designed to be lightweight yet highly scalable, it is often deployed in cloud-native environments, acting as a drop-in replacement for Amazon S3 or integrated into private and hybrid cloud infrastructures.

Key Features of MinIO

Amazon S3 API Compatibility : Provides a smooth integration with existing cloud storage applications.
High-Performance Object Storage : Designed for fast throughput and large-scale workloads.
Enterprise Security & Compliance : Provides encryption, access controls, and security measures.
Scalability & Redundancy : Supports multi-node clusters with erasure coding and replication.
Multi-Cloud Deployment : Works across private, hybrid, and public cloud infrastructures.

MinIO is particularly suited for cloud-native storage, providing an efficient way to manage large datasets across distributed environments. It is commonly used in AI/ML pipelines, backup and disaster recovery, and data lakes where scalability and reliability are critical.

Amazon S3 compatibility allows MinIO to integrate with existing cloud applications, reducing migration and operational challenges. Security and compliance measures, such as encryption and access controls, ensure that corporate data is protected.

The platform's ability to operate across multiple cloud environments makes it a preferred choice for organizations adopting hybrid and multi-cloud strategies.

ReductStore: Purpose-Built for Storage and Streaming in Data Acquisition Systems

In a recent article we showed the performance benefits of ReductStore for time-series data, out-performing MinIO for multiple file sizes. ReductStore excels with unstructured time series data, where MinIO serves as a more general purpose object storage solution.

MinIO is highly optimized for AI/ML, but not specifically towards data acquisition systems (DAQ) where time series data is key, particularly time-series data with large records such as vibrational and acoustic data for industrial applications, camera and sensor logs (telemetry) for robotics. AI/ML often relies on unstructured time-series data as well, and when this data is the primary focus, ReductStore outperforms MinIO by a significant margin.

Key Features of ReductStore

Optimized for Time-Series Data: Stores unstructured, sequential data efficiently.
FIFO (First-In, First-Out) Quota System: Automatically manages storage volume by replacing older data.
Low-Latency Retrieval: Ensures fast access to historical data.
Batch Processing for High-Speed Ingestion : Reduces network overhead and speeds up data acquisition.
Lightweight and HTTP(s) API Integration: Designed for portability and easy connectivity in robotics and IIoT infrastructures.

ReductStore is particularly useful for automated industrial systems, robotics, or any autonomous system (such as self-driving cars) that require fast storage and retrieval of large volumes of sensor data, video streams, and device logs.

In distributed setups - such as those with high latency or remote nodes - the tool supports data streaming (replication) from one node to another. This is ideal when edge devices need immediate access to information locally, while simultaneously replicating that data to centralized servers or cloud storage for broader analysis or backup.

Key Differences: ReductStore vs. MinIO

Feature	ReductStore	MinIO
Primary Use Case	Time-series object storage for high-frequency, unstructured data (robotics/IIoT).	Cloud-native object storage for scalable, S3-compatible workloads.
Data Type	Sequential, time-indexed blobs (sensor streams, logs, images, event data).	General-purpose unstructured data (files, backups, training datasets).
Performance	Optimized for low-latency writes/reads of time-series data; batch ingestion.	High-throughput for large-scale parallel workloads.
Deployment Focus	Edge devices, lightweight data acquisition, and central time-series storage.	Enterprise data centers, multi-cloud clusters, and hybrid environments.
Key Use Cases	Data acquisition systems, robotics telemetry, industrial monitoring, ELT.	Data lakes, AI/ML pipelines, backup/archival, multi-cloud file storage.

When to Use ReductStore

ReductStore is ideal for applications that require real-time, high-speed data capture and retrieval. It works particularly well in applications such as manufacturing and autonomous systems (autonomous cars/robotics). Especially when raw, time-stamped sensor data (such as logs, LiDAR scans, or event streams) is collected for later processing or AI training via an extract-load-transform (ELT) approach.

It's ideal for deploying robust data collection systems on edge devices with limited memory. For example, a computer vision module with AI predictions can locally store images along with AI-generated labels. When memory runs low, the system automatically removes older data to make room for new information (FIFO quota). At the same time, it can stream selected records - filtered by AI labels - to centralized storage, providing efficient and reliable data flow from the edge to the cloud.

When to Use MinIO

MinIO is the better choice for organizations requiring high-performance, scalable storage for enterprise applications. It is widely used in AI and machine learning workflows, where large datasets must be stored and processed across distributed cloud environments. Enterprises looking to build private or hybrid cloud storage solutions will benefit from MinIO's S3-compatible API and multi-cloud deployment capabilities.

MinIO also excels in long-term storage and disaster recovery , making it a preferred option for organizations that need to store a lot of data while ensuring redundancy and resilience. Businesses in industries such as media, healthcare and financial services can rely on MinIO's ability to securely store large files, backups and archives while maintaining fast retrieval speeds.

Combining ReductStore and MinIO for a Complete Solution

ReductStore and MinIO can be combined to create an efficient hybrid storage architecture.

ReductStore is designed to store and manage high-frequency blob data - such as images, video frames, or sensor logs - using the local file system. This makes it easy to integrate with any backend that supports FUSE (Filesystem in Userspace).

MinIO provides scalable, S3-compliant object storage that can be mounted using MinFS, a FUSE driver for MinIO. By mounting a MinIO bucket via MinFS, ReductStore can write and read data directly from MinIO, just like a regular filesystem.

This setup allows:

ReductStore to run at the edge or in the cloud
MinIO to handle long-term blob storage

Together, they provide a flexible solution: ReductStore manages real-time ingestion and fast access, while MinIO provides persistent, scalable storage in the background.

Conclusion

ReductStore is a strong choice for workloads that require real-time access to time-series blob data, whether at the edge or in the cloud. It provides low-latency ingestion and efficient storage for use cases in robotics and IIoT.

MinIO is best suited for general purpose, cloud-native object storage. It works well for long-term archiving, backups, and applications that require S3-compliant access across distributed environments.

In many cases, using both systems together is a practical solution: ReductStore handles the active, high-frequency data stream, while MinIO provides scalable and resilient storage for long-term retention.

ReductStore vs. TimescaleDB: How to Choose the Right Time-Series Database

AnthonyCvn — Thu, 06 Mar 2025 00:00:00 +0000

With the rapid growth of time-series data in AI, IoT, and industrial automation, choosing the right database solution can significantly impact performance, scalability, and efficiency. As we covered briefly in our whitepaper, ReductStore and TimescaleDB are two powerful but distinct solutions, each designed to handle time-series data in different ways. ReductStore specializes in unstructured time-series data, making it ideal for edge computing and large binary objects. TimescaleDB, on the other hand, is an extension of PostgreSQL, optimized for structured time-series data with robust querying capabilities. In this article, we'll explore these differences between ReductStore and TimescaleDB, as well as their other strengths, and when to use each.

Understanding TimescaleDB: The PostgreSQL-Based Time-Series Database

TimescaleDB is a time-series database built as an extension of PostgreSQL, leveraging SQL's familiarity while adding optimizations for time-series workloads. Unlike traditional relational databases, TimescaleDB structures data into hypertables, which automatically partitions data across multiple chunks, improving read and write performance.

Key Features of TimescaleDB

SQL Compatibility : Allows users to run traditional SQL queries on structured time-series data.
Hypertables & Automatic Partitioning : Improves storage efficiency and query performance.
Compression & Data Retention Policies : Reduces storage costs by compressing or discarding older data.
Full PostgreSQL Ecosystem : Supports joins, indexing, and relational data integration.
Efficient Querying : Optimized for aggregations, rollups, and downsampling.
Extensive Analytical Capabilities : Ideal for real-time monitoring, forecasting, and trend analysis.
Scalability & Replication : Supports distributed architectures for improved availability.

Because TimescaleDB is based on PostgreSQL, it's particularly useful for applications that blend time-series data with relational datasets. It excels in scenarios requiring frequent queries, detailed analytics, and structured data storage. With features such as full-text or vector search, it is hard to beat the performance that TimescaleDB offers for structured PostgreSQL time series data, especially when dealing with deep metadata queries. Like ReductStore, TimescaleDB is able to leverage on-premise and cloud storage to create a powerful, efficient and affordable solution, provided the dataset is structured. Because of this flexibility, performance, built-in SQL integration, and deep query capabilities, TimescaleDB is widely used in financial transactions, predictive maintenance, and smart city infrastructure.

ReductStore: Optimized for Unstructured Time-Series Data

While TimescaleDB shines in structured environments, ReductStore is purpose-built for high-speed, unstructured time-series data. It is designed for scenarios where time-series data consists of binary large objects (BLOBs), such as images, videos, and sensor logs. Unlike relational databases, ReductStore organizes data into buckets and entries, with specialised features for edge computing and industrial IoT applications.

Key Features of ReductStore

Designed for Unstructured Data : Efficiently stores and retrieves binary time-series objects.
Volume Based FIFO (First-In, First-Out) Quota System: Ensures the most relevant and recent data is retained with minimal configuration, and ensures that edge storage is not overrun.
Batching & Low-Latency Retrieval : Reduces network overhead, making it highly efficient for edge devices.
Lightweight HTTP API (and ReductStore SDKs): Provides a simple interface for integrating with AI, robotics, and other IoT systems.
Optimized for Large Data Objects : Unlike TimescaleDB, ReductStore handles large records natively.
Cost-Effective Storage Management : Aside from efficient data retention policies with minimal configuration, leverage lower cost blob storage to keep costs down. (For more information, see our article on data lakehouses for manufacturing)

ReductStore excels in AI, robotics, and industrial automation, where managing high-frequency unstructured time-series data is critical. It is particularly well-suited for environments requiring efficient storage and processing of large sensor data, video streams, or machine logs. Organizations developing autonomous systems, security monitoring applications, and predictive maintenance solutions could benefit significantly from ReductStore's ability to efficiently handle and prioritize large volumes of binary time-series data. Its flexibility in leveraging both on-premise and cloud storage solutions allows for seamless integration into a variety of industrial and AI-driven pipelines.

One of ReductStore's standout features is its real-time FIFO (First-In, First-Out) quota system based on storage volume, which ensures optimal storage management by automatically replacing older data while retaining high-priority information. This capability is particularly valuable in edge computing, where storage constraints require careful storage management. Additionally, ReductStore's batching and iterator-based query approach significantly reduces latency overhead, making it an efficient choice for high-frequency data retrieval. While TimescaleDB offers advanced SQL-based time-series indexing and partitioning, it is inherently optimized for structured datasets and relational metadata, making ReductStore the preferred choice for workloads involving continuous ingestion and rapid access to unstructured binary time-series data.

Key Differences: ReductStore vs. TimescaleDB

Feature	TimescaleDB	ReductStore
Data Model	Relational time-series database (PostgreSQL extension)	Time-series object storage
Best For	SQL-based analytics and structured time-series data	Fast data acquisition systems (primarily unstructured/binary data)
Schema	Standard relational schema design	Flat storage structure
Transport Protocol	PostgreSQL wire protocol (TCP)	HTTP/1 and HTTP/2
Query Language	SQL-based queries	Conditional Query Language (HTTP-based)
Scalability	Vertical/horizontal scaling via hypertables and distributed hypertables	Optimized for edge computing and centralized cloud storage
Performance	High ingest rates for structured data; optimized compression for analytics	High-speed ingestion and retrieval for large binary data
Ideal Use Cases	Real-time analytics, monitoring, IoT with structured data, financial workloads	Industrial IoT, vibration/acoustic sensors, predictive maintenance, robotics, computer vision

When Both Solutions Might Work Together

While ReductStore and TimescaleDB specialize in different areas, there are scenarios where using both solutions together can provide the best of both worlds. For example, in an industrial IoT setting, TimescaleDB can be used to store structured metadata, such as device identifiers and timestamps, while ReductStore can manage the corresponding unstructured data, such as sensor images, audio logs, or vibration waveforms.

Similarly, AI-driven applications might rely on ReductStore for raw data storage while using TimescaleDB for structured annotations and analytics. For instance, in predictive maintenance, TimescaleDB could store structured sensor readings like temperature and pressure logs, while ReductStore could handle infrared images, vibrational sensor data or audio recordings used for diagnosing issues.

Which One Should You Choose?

If your application requires structured, SQL-compatible time-series data with strong analytics and query performance, TimescaleDB is a great choice. It excels in scenarios like financial monitoring, IoT device management, and predictive analytics where structured data is key. Organizations that need deep historical analysis, trend forecasting, and regulatory compliance for long-term data storage often find TimescaleDB to be a perfect fit.

On the other hand, if your workload involves unstructured time-series data with large binary objects, ReductStore is the better fit. It is optimized for high-speed ingestion, edge computing, and AI-driven applications, making it ideal for robotics, manufacturing, and high-frequency sensor data. Its ability to handle binary time-series data makes it a natural choice for applications in satellite imaging or industrial automation.

Final Thoughts

Both ReductStore and TimescaleDB offer powerful solutions for managing time-series data, but their strengths lie in different areas. Understanding these differences allows you to choose the best fit for your specific use case—or even leverage both for a comprehensive data storage strategy.

If your project deals with structured time-series data analytics, particularly if it involves SQL in any way, TimescaleDB is a great choice. If you work with large unstructured time-series datasets, ReductStore is the optimal solution. For businesses handling both types of data, integrating the two databases can offer a balanced, efficient, and scalable approach to time-series data management.

If you have any questions or comments, feel free to use the ReductStore Community Forum.

ReductStore vs. MongoDB: Which One is Right for Your Data?

AnthonyCvn — Fri, 21 Feb 2025 00:00:00 +0000

With the rapid expansion of data-driven applications, choosing the right database for your workload has never been more crucial. As data complexity increases, so do the number of specialized solutions. ReductStore, as we've covered before, is a powerful alternative for handling time series unstructured data, but it's not the only player in the space. MongoDB, one of the most widely used NoSQL databases, also offers an effective solution for managing large-scale data. However, each has their own key areas of strength. In this article, we'll break down the differences between ReductStore and MongoDB, and help you determine which is best suited for your needs.

Understanding MongoDB: The NoSQL Powerhouse

MongoDB is a document-based NoSQL database designed for flexibility and scalability. Unlike relational databases, it doesn't enforce a strict schema, making it ideal for applications where data structures may evolve over time.

One of MongoDB's biggest advantages is its JSON-like document model (BSON), which allows developers to store and retrieve complex, hierarchical data efficiently. Combined with horizontal scaling via sharding, MongoDB can handle massive datasets across multiple distributed nodes. This makes it a preferred choice for applications that demand real-time performance, fast read/write capabilities, and scalability.

Key Features of MongoDB

Schema Flexibility : MongoDB allows users to store data without a fixed schema, making it highly flexible for modern applications.
Indexing & Query Performance : Allows the creation of powerful indexing options including single field, compound, multikey, geospatial, text and more.
Replication & High Availability : Replicates data across multiple servers to ensure data redundancy and reliability.
Horizontal Scaling : Data can be sharded across multiple servers for performance optimization.
Aggregation Framework : Enables complex data transformations using MongoDB Query Language and SQL-style queries.
Built-in Load Balancing : Ensures smooth performance even with high-volume transactions.

For applications that involve real-time analytics, dynamic content management, or large-scale web and mobile applications, MongoDB's high write throughput and indexing capabilities make it a strong choice. However, while MongoDB can manage time-series data, it's not inherently optimized for binary large objects (BLOBs). While this can be mitigated by GridFS, which can handle data files above 16MB, it is slower, and cannot optimize storage costs by storing blobs in a commodity cloud storage solution.

ReductStore: The Specialist for Time Series Unstructured Data

Now that we've covered the basics of MongoDB, let's turn to ReductStore. While MongoDB is highly versatile, ReductStore is built specifically for time series unstructured data, making it a stronger choice for industrial IoT, computer vision, and edge computing applications. Unlike MongoDB, which is better suited to storing documents, ReductStore stores time-ordered binary data in a lightweight, object-store-based structure. This makes it a natural fit for machine-generated data, including sensor readings, video feeds, or other large-scale unstructured datasets.

Key Features of ReductStore

Optimized for Time-Series Data : Purpose-built for handling time series unstructured data in a compact format.
High-Speed Data Ingestion : Supports extremely fast write speeds for records larger than a few KB, making it ideal for data acquisition (DAQ) systems (e.g., vibration sensors, cameras, log files, etc.).
Real-Time FIFO Quota System : Ensures storage is efficiently managed, preventing storage overflow on edge devices, while retaining the most recent and necessary data.
Batching & Low Latency : Reduces network overhead for high-latency environments.
Efficient Storage Management : When it comes to its cloud solution, ReductStore can leverages low cost blob storage to reduce costs and stores these large binary objects (BLOBs) in a scalable and efficient way.

One of ReductStore's key advantages is its real-time FIFO (First-In, First-Out) quota system based on storage volume, which ensures that older data is automatically replaced as needed. This makes it highly efficient for edge computing, where storage resources are often limited.

Another key feature is data replication between edge devices and the cloud (or across edge devices) using label-based filtering. Each data record can be labeled with key-value pairs (such as AI labels), allowing replication tasks to automatically select and transfer only the relevant data. This approach provides flexibility to optimize bandwidth and storage costs, or to ensure that critical data is always accessible.

In addition, ReductStore optimizes data retrieval and storage efficiency by adapting to different data sizes and network conditions. For large records, it supports chunked downloads to avoid overwhelming system memory. In high-latency environments or when handling many small records, its batching capabilities minimize overhead and ensure faster writes and retrievals. In addition, rather than relying on traditional query mechanisms, ReductStore uses an iterative approach to efficiently navigate and retrieve unstructured-time series data with minimal resource consumption.

Key Differences: ReductStore vs. MongoDB

Feature	MongoDB	ReductStore
Data Model	NoSQL Document Store (BSON)	Time-Series Object Storage
Best For	Scalable web applications	Fast data acquisition systems
Schema	Flexible, dynamic schema	Flat storage structure
Transport Protocol	TCP	HTTP/1, HTTP/2
Query Language	MongoDB Query Language	Conditional Query Language
Scalability	Horizontal scaling with sharding	Optimized for edge computing and centralized cloud storage
Performance	High read/write throughput for document storage	High-speed ingestion and retrieval for large binary data
Ideal Use Cases	Real-time analytics, content management, mobile/web apps, and Generative AI	Industrial IoT, vibration / acoustic sensors, predictive maintenance, robotics, computer vision

Real-World Applications and Use Cases

When to Use MongoDB

MongoDB is ideally suited for web and mobile applications requiring a dynamic schema, high speed queries, and distributed data storage. Other use cases include e-commerce platforms, which benefit from MongoDB's flexible schema and fast search capabilities, big data and analytics, where its aggregation framework allows it to optimally store and analyze structured or semi-structured data. It is also ideal for content management systems and generative AI where its JSON-like BSON language allows it to more efficiently retrieve user-generated content, blogs or media files, and to efficiently create new content of this type..

When to Use ReductStore

ReductStore is an ideal solution for time series unstructured data from any source. Sources of such time series unstructured data include Industrial IoT, edge computing devices, manufacturing machine sensors or vibration sensors, computer vision, robotics, GPS, log files, and more.

If your use case involves large amounts of sensor data, especially those with large file sizes, ReductStore offers the best performance and storage efficiency. Since disk space is often at a premium in edge and cloud locations, FIFO quotas and cost-effective blob storage are additional benefits. And because ReductStore's performance metrics are so high, you need fewer disks or edge devices in parallel to ingest data at speed.

The ability to leverage cheaper blob storage in the cloud without taking a significant performance hit means that ReductStore offers the biggest bang for your buck. AI/ML applications is another area in which ReductStore excels. Learning models that rely on time-series data can greatly benefit from ReductStore's optimized ingestion and retrieval speeds.

Robotics is another potential use case, where video files, positional data, logs and sensor readings of various sizes need to be processed quickly. For larger file sizes, such as video and images, vibrational sensor data, or audio, ReductStore's read and write efficiency cannot be beat.

Which One Should You Choose?

If you're looking for a general-purpose NoSQL database with flexibility, scalability, and strong query support, MongoDB is an excellent choice. It works well for applications that require structured yet schema-flexible data storage, such as e-commerce platforms, social media applications, and analytics dashboards.

However, if your application deals primarily with time series unstructured data, especially in an AI-driven environment, ReductStore offers a more specialized, high-performance solution. Its FIFO quota system, efficient batching, and low-latency retrieval make it ideal for managing large-scale sensor data, image processing, and robotics applications.

Ultimately, your choice will depend on the type of data you are working with and the performance requirements of your system. For flexible document storage, go with MongoDB. For efficient time series unstructured data storage, ReductStore is the better fit.

By understanding the strengths and limitations of both, you can make an informed decision and ensure your data management strategy aligns with your application's needs.

If you have any questions or comments, feel free to use the ReductStore Community Forum.

DEV Community: AnthonyCvn

Air-Gapped Drone Data Operations with Delayed Sync and Auditability

Drone-to-Ground Architecture​

Setting Up the Drone Node​

Storing Drone Data with Labels​

Setting Up Selective Replication​

Replicating with context (before and after)​

Querying for Audit Reports​

Why This Setup Works Well for Drones​

Next Steps​

Comparing Data Management Tools for Robotics

Key Criteria for Comparison

Tool Overviews

ReductStore

Foxglove and MCAP

Rerun

Heex

Comparative Analysis Table

Conclusion

Distributed Storage in Mobile Robotics

Edge-to-Cloud Architecture​

How Replication Works​

Cloud ReductStore With S3 Backend​

Setting Up Replication​

Storing Sensor Data​

Querying Sensor Data Using ReductSelect​

Why This Setup Works Well for Robotics​

Next Steps​

The Missing Database for Robotics Is Out

What Makes It a New Category​

Data Handling and Querying​

1. MCAP topic filtering​

2. CSV/JSON field extraction and filtering​

3. Query any type of data​

4. Browse petabytes of data​

Cloud Integration and Cost Savings​

Observability Stack Integration​

Foxglove Studio​

Grafana​

Canonical Observability Stack (COS)​

Closing Thoughts​

Comparing Robotics Visualization Tools: RViz, Foxglove, Rerun

Pricing ​

Platform & Collaboration ​

User Interface ​

Extensibility ​

ROS Integration ​

Performance with Large Data ​

Analysis & Visualization ​

RViz & RViz 2 ​

Foxglove ​

Rerun ​

Conclusion ​

Getting Started with LeRobot

What You Need to Get Started​

Preparation​

Step 1: Switch to GPU​

Step 2: Clone the LeRobot Repository​

Step 3: Move into the LeRobot folder​

Step 4: Install LeRobot and Its Dependencies​

Running a Pre-Trained Model​

Want to Try a Different Model?​

Training a Model​

Evaluating Your Trained Model​

Downloading a Dataset​

Visualize a Dataset​

Next Steps​

Conclusion​

Getting Started with MetriCal

What is MetriCal?​

Key Features​

How MetriCal Works​

MetriCal Example​

Understanding Results​

Data Inputs (DI Section)​

Camera Modeling (CM Section)​

Extrinsics Info (EI Section)​

Calibrated Plex (CP Section)​

Summary Statistics (SS Section)​

Data Diagnostics​

Drone-to-Ground Architecture

Setting Up the Drone Node

Storing Drone Data with Labels

Setting Up Selective Replication

Replicating with context (before and after)

Querying for Audit Reports

Why This Setup Works Well for Drones

Next Steps

Edge-to-Cloud Architecture

How Replication Works

Cloud ReductStore With S3 Backend

Setting Up Replication

Storing Sensor Data

Querying Sensor Data Using ReductSelect

Why This Setup Works Well for Robotics

Next Steps

What Makes It a New Category

Data Handling and Querying

1. MCAP topic filtering

2. CSV/JSON field extraction and filtering

3. Query any type of data

4. Browse petabytes of data

Cloud Integration and Cost Savings

Observability Stack Integration

Foxglove Studio

Grafana

Canonical Observability Stack (COS)

Closing Thoughts

Pricing

Platform & Collaboration

User Interface

Extensibility

ROS Integration

Performance with Large Data

Analysis & Visualization

RViz & RViz 2

Foxglove

Rerun

Conclusion

What You Need to Get Started

Preparation

Step 1: Switch to GPU

Step 2: Clone the LeRobot Repository

Step 3: Move into the LeRobot folder

Step 4: Install LeRobot and Its Dependencies

Running a Pre-Trained Model

Want to Try a Different Model?

Training a Model

Evaluating Your Trained Model

Downloading a Dataset

Visualize a Dataset

Next Steps

Conclusion

What is MetriCal?

Key Features

How MetriCal Works

MetriCal Example

Understanding Results

Data Inputs (DI Section)

Camera Modeling (CM Section)

Extrinsics Info (EI Section)

Calibrated Plex (CP Section)

Summary Statistics (SS Section)

Data Diagnostics

Output Summary

Conclusion

Install Required Libraries

Loading and Preprocessing Bag Files

Processing three different movement types

Visualizing velocities

Training and Evaluating Classification Models

Training a Random Forest classifier

Best practices

Conclusion

Prerequisites and Architecture

1. Install Ubuntu on Raspberry Pi

2. Install ROS 2 Humble on Raspberry Pi

3. Create a ROS 2 Workspace

Setting up the USB Camera with `v4l2_camera`

1. Install the `v4l2_camera` Package