In August, DC ran only on one ROS 2 distro, with a legacy Humble line beside it. I received many emails to thank me along with requests over the years to update the branches.
Today the repository maintains three: Jazzy, Lyrical and Rolling, each with its own container images, each green in CI.
What DC is, in one paragraph
DC is my open-source data collection stack for ROS 2, MPL-2.0. It runs on the robot. Measurements (odometry, battery, scans, camera reads, anything you write a plugin for) are collected into Records, validated against JSON schemas, and handed to a delivery pipeline with backpressure handling and disk buffering, so records survive a destination outage or a reboot. Data lands in infrastructure you own: PostgreSQL for queries and dashboards, S3-compatible storage for files. The architecture borrows Nav2’s plugin approach, so a new measurement is a small C++ or Python plugin, and a new destination is usually configuration alone.
If you are reading the robot fleet series on this blog, DC is the piece that turns a running robot into queryable history.
Three distro lines
The Lyrical branch went green on 14 September, on Ubuntu 26.04. I expected the port to be a flag in the build matrix. It was three days of C++ rewrites: Lyrical moved tf2 interfaces onto the NodeInterfaces bundles, so every timer and TF listener in dc_measurements had to learn the new API while still building against Jazzy’s. The navigation simulation needed its own patience; the sim graph now runs on CycloneDDS end to end to match Lyrical’s Nav2.
Rolling followed two days later, and with it the workflow change I should have made earlier: development happens on Rolling first, and fixes reach the distro lines as automated backport PRs, labelled backport:jazzy and backport:lyrical. Jazzy is maintained to 05/2029, Lyrical to 05/2031. Humble stays as the legacy DC 1.x line with high and critical security fixes only.
Every commit builds and verifies per-distro images on ghcr.io: dc-ros for the ROS workspace and dc-uploader for the file sidecar, one tag pair per distro.
What the new branches ships
All packages are at 0.2.0 with real changelogs. The change I would have wanted years ago is the file sidecar: dc-uploader takes what measurements produce, such as map_server maps, camera frames and videos, and uploads them to object storage with verified, resumable transfers. A transfer interrupted by a dock drop or a reboot resumes where it stopped, and each file’s metadata is recorded as a Record, so “which image belongs to which inspection at which timestamp” is a SQL join.
Destinations got simpler by losing a path. The bridge used to carry hand-written PostgreSQL, S3 and console code alongside the shipper; 0.2 removes it, a breaking change, and every destination now goes through the same shipper configuration: three destination types set from ROS parameters (file or vector for records, s3 for files), and every other sink in Vector’s catalog through raw passthrough configuration. Recipes for the common setups are in the docs. Incidents are typed on the Record envelope, so fault events pass the same schema validation as every other record.
The robot tier now renders as Compose, Quadlet or Kubernetes, the last as a Helm chart plus Kustomize overlays, and the three-tier topology is validated in kind with NetworkPolicies on every pull request. No :latest tag in any deploy manifest. The docs site got the same release discipline: one versioned site with a distro selector, published per branch, so a Jazzy user no longer reads Rolling instructions.
Why DC when there is Formant and Foxglove?
People asked me this in almost every email, it solves a different problem: it turns ROS 2 runtime data into validated, application-ready records that can be delivered reliably to your own backend.
Foxglove is a full robotics data platform, and the label is earned: live visualization, teleoperation, recording in MCAP, searchable replay across a fleet, event annotation, team collaboration, with a cloud service, your own storage bucket or an on-prem deployment behind it. Formant sells a hosted fleet platform: dashboards, teleoperation, alerts, with a commercial model per robot. Both do their jobs well.
DC is deliberately narrower. It collects structured records on the robot, validates them at the source, and delivers them into your own database with delivery guarantees. Foxglove holds your history as recordings indexed in its platform; DC holds it as rows in your own PostgreSQL. When your customer asks how many picks per hour a cell ran in August, or when a fault first appeared, or which inspection images belong to a failed incident, you write SQL against your own tables and join them with the rest of your business data. No vendor sits in the data path, no per-robot fee scales with your fleet, and the license lets you ship it inside your product.
In practice they complement each other, and I run both, on different robots. Foxglove is how people watch a robot; DC is how your database learns from one. The data DC collects feeds the dashboards you already have, whether that is Grafana, Metabase or a script your ops person wrote on a Friday.
My humble (wink wink) request
Over the last year, a steady trickle of emails told me someone, somewhere, runs DC. I am grateful for every one of them. I can count the setups I know about without running out of fingers, and 119 GitHub stars is the only overview I have. That is a strange position for a maintainer: the project grows, the inbox ticks over, and I still do not know who is out there.
So, if DC runs on one of your robots, or you evaluated it and moved on: I want to hear from you. A line by email, a GitHub issue with what you collect, or a star if that is all the time you have. Tell me which distro you run and where your records land. Feature requests carry the same weight as kind words; 143 commits landed between 23 August and today because people asked for things.
The repository is minipada/ros2_data_collection, the docs are at minipada.github.io/ros2_data_collection, and the 0.2 images are on ghcr.io.