Forem: ReductStore

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.

ReductStore v1.17.0 Released with Query Links and S3 Storage Backend Support

Alexey Timin — Tue, 21 Oct 2025 00:00:00 +0000

We are pleased to announce the release of the latest minor version of ReductStore, 1.17.0. ReductStore is a high-performance storage and streaming solution designed for storing and managing large volumes of historical data.

To download the latest released version, please visit our Download Page.

What's new in 1.17.0?

This release includes several new features and enhancements. First, there are query links for simplified data access. Second, there is support for S3-compatible storage backends.

These new features enhance the usability and flexibility of ReductStore for various use cases in the cloud and on-premises environments and make it easier to share and access data stored in the database.

🔗 Query Links for Data Access

ReductStore now supports query links, enabling users to generate temporary, public URLs for specific data records — without requiring authentication. This makes it easier to share datasets with external collaborators , embed links into dashboards, or integrate with third-party systems that need read-only access to specific data.

You can create query links directly from the Web Console (or any SDKs):

Open the Data Browser page and select a record you want to share.
Click the “Share record” icon in the action panel.
Configure an expiration time to automatically revoke access after a defined period.

Once generated, anyone with the link can access the selected record via a simple HTTP(S) request — no access token required. The link only has access to the specific query for which it was created, along with the creator's permissions. This provides a secure and convenient way to expose selected data for collaboration and analysis.

☁️ S3-Compatible Storage Backend

ReductStore now supports S3-compatible storage backends , allowing you to use object storage instead of a local file system for your underlying data. This update brings greater flexibility and scalability for managing large datasets in the cloud.

Previously, ReductStore supported only local disk storage, and users had to mount S3 buckets as local disks via FUSE drivers. With this release, ReductStore can now natively integrate with S3-compatible backends — no additional software or mounting is required.

This feature is designed with performance and cost optimization in mind. ReductStore uses a local disk cache layer to speed up read and write operations, while batching multiple records into a single data block to reduce storage and retrieval costs. This approach works especially well with cost-efficient AWS S3 storage classes such as S3 Standard-IA or S3 Glacier.

To run ReductStore with an S3-compatible backend, use the following environment variables:

docker run -p 8383:8383 \
 -e RS_REMOTE_BACKEND_TYPE=s3 \
 -e RS_REMOTE_BUCKET=<YOUR_S3_BUCKET_NAME> \
 -e RS_REMOTE_REGION=<YOUR_S3_REGION> \
 -e RS_REMOTE_ACCESS_KEY=<YOUR_S3_ACCESS_KEY_ID> \
 -e RS_REMOTE_SECRET_KEY=<YOUR_S3_SECRET_ACCESS_KEY> \ 
 -e RS_REMOTE_CACHE_PATH=/data/cache \
 -e RS_LICENSE_PATH=<PATH_TO_YOUR_LICENSE_FILE> \ 
 -v ${PWD}/data:/data/cache \
 reduct/store:latest

Read more about configuring S3-compatible storage backend in the documentation

info

This feature requires a commercial license. Please see the Pricing page for more details.

What’s Next

We’re continuing to develop new features to make ReductStore even more powerful and user-friendly. Here’s a preview of what’s coming in the next releases:

📦 Multiple Entries in a Single Request

Currently, each write or query request must target a single entry. This can be limiting when dealing with multiple entries or dynamic lists of entries in your applications.

In upcoming versions, ReductStore will support batch operations across multiple entries within a single API request. This improvement will simplify integrations and reduce overhead for large-scale data ingestion and querying workflows.

🔒 Read-Only Mode for ReductStore

Like most databases, ReductStore currently requires exclusive access to its data directory while running. As a result, running multiple instances on the same dataset—for load balancing or high availability—is not yet possible.

To address this, we’re introducing a read-only mode that will allow one writer instance* and multiple reader instances to access the same dataset concurrently. This approach will enable scalable read operations and improved availability without adding the complexity of clustering or replication mechanisms.

I hope you find those new features useful. If you have any questions or feedback, don’t hesitate to use the ReductStore Community forum.

Thanks for using ReductStore!

Building a Resilient ReductStore Deployment with NGINX

Alexey Timin — Sat, 13 Sep 2025 00:00:00 +0000

If you’re collecting high-rate sensor or video data at the edge and need zero-downtime ingestion and fault-tolerant querying, an active–active ReductStore setup fronted by NGINX is a clean, practical pattern.

This tutorial walks you through the reference implementation, explains the architecture, and shows production-grade NGINX snippets you can adapt.

What We’ll Build

We’ll set up a ReductStore cluster with NGINX as a reverse proxy, separating the ingress and egress layers. This architecture allows for independent scaling of write and read workloads, ensuring high availability and performance.

Ingress layer

The ingress layer handles all writes and replicates data to the egress layer. Its nodes may have limited storage capacity, while they need only to handle writes and replicate data to the egress nodes. It can use high-rate storage like NVMe SSDs or even RAM disks, depending on your data volume.

Egress layer

The egress layer handles all reads and serves data to clients. Its nodes are optimized for read performance and can use larger, slower storage like HDDs or cloud object storage. Each egress node holds a complete copy of the dataset, allowing for high availability and load balancing.

NGINX Load Balancer

The NGINX load balancer sits in front of both layers, exposing two stable endpoints:

http://<host>/ingress → load balances writes across ingress nodes
http://<host>/egress → load balances reads across egress nodes

This separation allows you to scale each layer independently and ensures that writes and reads are handled optimally.

It is also important to note that NGINX must maintain session affinity (stickiness) for both ingress and egress requests to ensure that queries remain consistent and throughput is maximized.

Quick Start

Clone the example and bring it up:

git clone https://github.com/reductstore/nginx-resilient-setup
cd nginx-resilient-setupdocker 
compose up -d

This will start two ingress nodes and two egress nodes with NGINX in front, all configured to replicate data between them. Check the docker compose file for details on how the nodes are set up.

Now we need to write some data and verify that we can read it back.Install the reduct-cli tool if you haven't already, then run the following commands to set up aliases for the ingress and egress endpoints:

reduct-cli alias add ingress -L http://localhost:80/ingress --token secret
reduct-cli alias add egress -L http://localhost:80/egress --token secret

Then copy some data from our Demo Server to the ingress layer and read it back from the egress layer:

# Add demo server alias to the CLI
reduct-cli alias add play -L https://play.reduct.store --token reductstore
# Copy data from the demo server to ingress
reduct-cli cp play/datasets ingress/bucket-1 --limit 1000
# Read/export via egress
reduct-cli cp egress/bucket-1 ./export_folder --limit 1000

NGINX Configuration

Below is a distilled config you can adapt for open-source NGINX:

# Upstreams
# Separate pools for ingress (writes) and egress (reads)
upstream reduct_ingress {
    ip_hash;   # stickiness for writes
    server ingress-1:8383 max_fails=3 fail_timeout=10s;
    server ingress-2:8383 max_fails=3 fail_timeout=10s;
    keepalive 64;
}

upstream reduct_egress {
    ip_hash;   # stickiness for queries
    server egress-1:8383 max_fails=3 fail_timeout=10s;
    server egress-2:8383 max_fails=3 fail_timeout=10s;
    keepalive 64;
}

server {
    listen 80;
    server_name _;

    client_max_body_size 512m;
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;

    location /ingress/ {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://reduct_ingress/;
    }

    location /egress/ {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://reduct_egress/;
    }
}

In the config above, we define two upstream blocks: reduct_ingress for handling write requests and reduct_egress for handling read requests. Each block uses ip_hash to ensure session affinity, which is crucial for maintaining consistent writes and reads.

ReductStore Configuration Notes

The configuration between nodes of each layer is identical. To reach the desired architecture, you need to provision buckets and replication tasks for ingress nodes and buckets only for egress nodes. See the configuration files in the example repo for details.

Failure Drills

When the setup is running, you can simulate failures to see how it behaves:

Kill an ingress node → writes continue via other ingress nodes.
Kill an egress node → reads continue via other egress nodes; replication resyncs when it’s back.
Simulate total ingress outage → analysis continues on egress; for true ingestion continuity, pair with a pilot-light instance in another location.

Runbook

Here’s a high-level runbook for deploying this architecture in production:

Provision ingress + egress ReductStore nodes
Create buckets and replication tasks
Expose /ingress and /egress via NGINX with ip_hash
Test with demo dataset
Validate reads from egress
Run failure drills

References

I hope you find this article interesting and useful. If you have any questions or feedback, don’t hesitate to use the ReductStore Community forum.

ReductStore v1.16.0 Released With New Extensions and Context Replication

Alexey Timin — Sat, 30 Aug 2025 00:00:00 +0000

We are pleased to announce the release of the latest minor version of ReductStore, 1.16.0. ReductStore is a high-performance storage and streaming solution designed for storing and managing large volumes of historical data.

To download the latest released version, please visit our Download Page.

What's new in 1.16.0?

The v1.16.0 release introduces two new extensions designed to enhance data workflows for robotics and columnar data, along with support for replicating context records during queries.

Querying and Replicating Data with Context

We’ve extended the conditional query syntax with directives that allow users to modify global query behavior. The first directives introduced are #ctx_before and #ctx_after, which enable the inclusion of context records that occur before or after each matching record in a query.

This feature is particularly useful when analyzing specific events or conditions in your data, as it helps provide a clearer picture of the surrounding context. For instance, you can use these directives to include records from a few seconds before or after an anomaly or incident, aiding in root cause analysis or pattern recognition.

Here’s an example of how to use the #ctx_before directive in a query:

{ "#ctx_before": "5s", "&anomaly_score": { "$gt": 0.8 }}

This query returns all records with an anomaly score greater than 0.8, along with the context records that occurred within 5 seconds before each matching entry.

New ReductSelect Extension

ReductStore is fundamentally a blob storage system and does not allow direct manipulation of stored data. However, with its extension mechanism, we can introduce new capabilities while keeping the core system simple.

The new ReductSelect extension enables users to query and transform data stored in CSV or JSON formats, making it easier to build flexible and efficient data processing workflows.

For example, the following query uses ReductSelect to extract specific columns from CSV data and filter rows using the same conditional syntax available in ReductStore's native query language:

{
  "ext": {
    "select": {
      "csv": {
        "has_headers": true
      },
      "columns": [
        { "name": "temperature", "as_labels": "temp" },
        { "name": "humidity" }
      ]
    }
  },
  "when": {
    "&temperature": { "$gt": 30 }
  }
}

This query selects the temperature and humidity columns from a CSV file, renames temperature to temp, and filters rows where the temperature is greater than 30°C.

These simple transformations enable you to ingest structured data very quickly and retrieve only subsets of it for further processing and analysis.

New ReductROS Extension

Another exciting addition is the ReductROS extension, which provides tools for extracting and transforming data stored in ReductStore into formats compatible with the Robot Operating System (ROS).

With this extension, you can extract data from MCAP files containing ROS 2 messages and convert it into JSON format, making it easier to analyze and visualize. It also supports transforming raw binary data—such as images—into more accessible formats like JPEG or base64 strings.

For example, the following query extracts data from a ROS 2 topic and encodes the image payload as a JPEG:

{
  "ext": {
    "ros": {
      "extract": {
        "topic": "/camera/image",
        "encode": { "data": "jpeg" }
      }
    }
  }
}

ReductROS is still in active development, and we plan to expand its capabilities with support for additional ROS message types and more flexible extraction options in future releases. Stay tuned for updates!

What next?

We are constantly working on improving ReductStore and adding new features to provide the best experience for our users. In the next release we plan to add new features and improvements, including:

Shareable Query Links

We are developing a feature that allows users to generate and share links to specific queries in ReductStore.

This will simplify collaboration by enabling team members to access query results without needing direct access to the ReductStore instance. It will also allow users to download results directly via a link and support integration with external tools and platforms such as Foxglove.

Integration with Grafana

We are also working on a Grafana plugin that enables users to visualize and analyze data stored in ReductStore directly within Grafana dashboards.

This integration will provide a seamless experience with Grafana’s powerful visualization tools, allowing you to:

Build custom dashboards using data from ReductStore.
Monitor your data streams and historical records in real time.
Visualize labels and data output in JSON or CSV formats.

Stay tuned for the first release—coming soon!

I hope you find those new features useful. If you have any questions or feedback, don’t hesitate to use the ReductStore Community forum.

Thanks for using ReductStore!

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.

ReductStore v1.15.0 Released With Extension API and Improved Web Console

Alexey Timin — Wed, 07 May 2025 00:00:00 +0000

We are pleased to announce the release of the latest minor version of ReductStore, 1.15.0. ReductStore is a high-performance storage and streaming solution designed for storing and managing large volumes of historical data.

To download the latest released version, please visit our Download Page.

What's new in 1.15.0?

This release includes several new features and enhancements. These are the extension API, the improved Web Console and the new conditional query operators.

Extension API

ReductStore is blob storage. It doesn't know anything about the data it stores. We are determined to maintain this because it enables us to ingest and query data in any format with optimal performance. We know that you sometimes need to perform processing and special queries based on the original data format.

For example, if you ingest data in the JSON format, you should be able to query only some fields of the JSON object or use it in the query condition for filtering. The new extension API makes it possible.

The extension API is experimental and not yet documented. We are developing extensions for columnar data, CSV and MCAP formats. Once we have enough experience, we will document the API and publish the extensions so that you can build your own extensions for your data formats.

For most curious users, a demo extension that scales JPEG images on the fly can be found on GitHub: https://github.com/reductstore/img-ext

Improved Web Console

In the v1.14.0 release, we introduced the ability to browse data in the Web Console. This release includes two new features: the ability to upload files to the database and update labels in the Web Console.

The upload feature can be useful when you store some artifacts e.g. AI models or configuration files in the storage and want to update it occasionally.

New Conditional Query Operators

We have expanded the set of conditional query operators with new ones that allow you to filter and aggregate data more effectively:

$each_n - keeps only every N-th record in the result set.
$each_t - keeps only one record within given time period in seconds.
$limit - limits the number of records in the result set.
$timestamp - allows you to filter records by timestamp.

The $timestamp operator can be particularly useful if you store timestamps and metadata in another database and want to retrieve blobs from ReductStore:

client = Client("http://localhost:8080")
bucket = await client.get("my_bucket")
async for record in bucket.query(
  start=1231231081,
  end=1231231085, 
  when ={ "$in": ["$timestamp", 1231231081, 1231231082, 1231231083, 1231231084,] },): 
  content = await record.read_all()

You can read more about the new operators in the Conditional Query documentation.

What next?

We are constantly working on improving ReductStore and adding new features to provide the best experience for our users. In the next few releases we plan to add new features and improvements, including:

Integration with ROS

ReductStore is a great solution for storing and managing large amounts of data in robotic applications. Currently, we are working on integrating ReductStore with ROS to provide a seamless experience for storing and retrieving data in ROS applications. We have started a new ROS2 Agent that allows you to store and retrieve data in ReductStore from ROS2 applications. The agent is designed to be easy to use and integrate with existing ROS2 applications. We are also going to add support for the mcap format with the new Extension API, which will allow you to retrieve data in the original format from mcap files, filter topics and many other features.

Golang SDK

Our big goal is to integrate Grafana by the end of 2025. This month we started work on the Golang SDK, which is the first step towards achieving this goal. The project is still in the early stages of development, but you can already check it out on GitHub: ReductStore Golang SDK.

I hope you find those new features useful. If you have any questions or feedback, don’t hesitate to use the ReductStore Community forum.

Thanks for using ReductStore!

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.

Forem: ReductStore

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​

ReductStore v1.17.0 Released with Query Links and S3 Storage Backend Support

What's new in 1.17.0?​

🔗 Query Links for Data Access​

☁️ S3-Compatible Storage Backend​

What’s Next​

📦 Multiple Entries in a Single Request​

🔒 Read-Only Mode for ReductStore​

Building a Resilient ReductStore Deployment with NGINX

What We’ll Build​

Ingress layer​

Egress layer​

NGINX Load Balancer​

Quick Start​

NGINX Configuration​

ReductStore Configuration Notes​

Failure Drills​

Runbook​

References​

ReductStore v1.16.0 Released With New Extensions and Context Replication

What's new in 1.16.0?​

Querying and Replicating Data with Context​

New ReductSelect Extension​

New ReductROS Extension​

What next?​

Shareable Query Links​

Integration with Grafana​

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

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

What's new in 1.17.0?

🔗 Query Links for Data Access

☁️ S3-Compatible Storage Backend

What’s Next

📦 Multiple Entries in a Single Request

🔒 Read-Only Mode for ReductStore

What We’ll Build

Ingress layer

Egress layer

NGINX Load Balancer

Quick Start

NGINX Configuration

ReductStore Configuration Notes

Failure Drills

Runbook

References

What's new in 1.16.0?

Querying and Replicating Data with Context

New ReductSelect Extension

New ReductROS Extension

What next?

Shareable Query Links

Integration with Grafana

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