The problem
Robots produce constant data from sensors, software, AI models and hardware, but it sits in separate systems. Teams end up building custom tools just to work out why a robot failed.
OpenTelemetry for robots
Brewric is open-source software that records what a robot fleet is doing, with paid real-time monitoring on top. Capture data once and use it in any tool.
Work with us
In development
Works with03
- ROS 2Robot software
- MCAPLog format
- OpenTelemetryTelemetry
What we're building
An open-source collector reads what robots already publish, so teams get value with no code changes.
Optional SDKs add richer data using shared telemetry conventions, with links to synced sensor recordings.
A paid service watches a whole fleet in near real time and links each incident to the exact sensor recording.
The framework
[Capture once. Use anywhere.]
A vendor-neutral telemetry layer, not another dashboard.
[01]A collector that reads what robots already publish.
Teams get value with no code changes. It works with ROS 2 and MCAP, the standard robot software and log format, and with OpenTelemetry, and the data can go to any tool.
- Reads
- ROS 2 topics and MCAP sensor recordings
- Built on
- The OpenTelemetry Collector
- Price
- Free and open source
[02]Optional SDKs for richer data, on shared telemetry conventions.
Common definitions mean every robot records the same things the same way, so one event can be followed across sensors, software and AI models.
- Languages
- C++ and Python, for ROS 2
- Conventions
- Robot identity, tasks, failures, interventions and model versions
- Links
- Synced sensor recordings
[03]Paid monitoring that watches a whole fleet in near real time.
The managed service detects failures and AI model regressions, and links each incident to the exact sensor recording. Engineers can open that recording in tools like Foxglove.
- Detects
- Failures and AI model regressions
- Connects
- Fleet-wide live queries, alerts and incident correlation
- Runs
- Hosted ingestion, retention and enterprise controls
Figures show the planned design.
Why a telemetry layer
Foundation first
Vendor-neutral
Common definitions for robot identity, tasks, failures and interventions, owned by no single tool.
Portable
Data gets captured once, then goes to whichever tool a team wants to use. It stays portable.
Less integration work
Start with what robots already publish. Add the SDKs later, when a team wants more.
Where we are[03]
We're at the start. Fleet monitoring depends on reliable, correlated telemetry, so we're building that first.
-
Next
Release the open-source SDK and collector for ROS 2.
-
Then
Get them running on a live fleet.
-
After that
Sell managed monitoring on top.
The team
We each saw half of this problem.
The robot side
Shubh Maheshwari
Co-founder
Worked on robot fleet deployments with Ottonomy's founders across sites in 7+ countries, where finding out why a robot failed meant stitching together data from separate tools. Builds the SDKs and ROS 2 integrations, and tests on real robots.
The data side
Arnav Borkar
Co-founder
Spent three years building a lakehouse query engine at e6data, and saw this as missing infrastructure, not a missing dashboard. Builds ingestion, storage and queries.
We met in person five years ago at BITS Goa, in the Data Systems and High Performance Computing Lab. Arnav was running the clusters, and Shubh came in to get an Nvidia Jetson Orin.
Know why your robots fail
We're looking for robotics teams with tens to hundreds of deployed robots.
Work with us