I maintain Altara, a set of MIT-licensed React components for real-time robotics telemetry (PFD, moving map, gauges, event log), and I wrote up building a small drone ground station with them that talks to MAVROS over rosbridge.
The thing I was trying to solve: I wanted a status dashboard our team could open in a browser tab and drop into our own app, rather than running a separate native GCS. So the components are embeddable and themeable rather than a standalone tool.
If you’ve built browser dashboards for a ROS2 stack, I’d like to know what you ended up reading off your topics, and where existing tools forced you into a standalone app when you wanted something embedded.
the same idea of embeddable front-end components written in React with
a data-synchronization layer built on MQTT, with some definite advantages over rosbridge, and
the concept of full-stack packages, bundling those front-end components with corresponding cloud and robot components to create an end-to-end functionality called a capability.
Transitive is an open eco-system for developers. Just like Android, it allows third parties like yourself to create new capabilities and submit them to the cap store from where any Transitive user can install them on their robots with one click or a config change.
I think your react components look really slick and could be extended to become full-fledged capabilities. Feel free to DM me if you are interested in exploring this.
Thanks Christian, that means a lot coming from you, and yes, I’ve been following Transitive.
The overlap is real, embeddable front-end components over a sync layer is the same shape. Where I think Altara sits a little differently is the high-frequency end. The components are built around a fixed-size RingBuffer feeding a single requestAnimationFrame loop that draws to Canvas, deliberately keeping per-sample data out of React state, because at 50Hz+ IMU or a streaming point cloud, reactive re-rendering is the thing that falls over. I benchmarked exactly that tradeoff recently and it’s the whole reason the rendering path looks the way it does.
So my real question about MQTTSync: is it tuned for reactive state at moderate rates, or does it hold up feeding high-rate streams into the UI, tens to hundreds of Hz, or binary payloads like sensor_msgs/PointCloud2? That boundary is where I’d want to understand the fit, because it’s the exact load these components are built for.
(Also curious in practice how a React component lands as a capability alongside the Web Components abstraction, but that’s a detail.)
Happy to take it to DM and dig in properly. Appreciate you reaching out.
Re. render: nothing in Transitive forces you to use React for rendering. React is just particularly convenient in the context of push-based data-sync (via MQTTSync). You can absolutely use other rendering approaches, including the canvas + requestAnimationFrame one you describe.
Re. MQTTSync: yes, I think that’s a really great point. MQTTSync is for syncing a shared data state (what used to be called a “world model” in robotics until the AI folks repurposed this term). Ephemeral data that is only meant for live viewing is better sent over MQTT without retaining (which is what MQTTSync relies on for establishing that shared data state), which should perform very similar to rosbridge in this scenario. One trick we do use in MQTTSync compared to rosbridge, though, is to only send diffs, not the same message over an over again, when most fields don’t change. Better yet you could use a true peer-to-peer connection like WebRTC that works remotely without a VPN or proxy, unlike rosbridge. This is what we demonstrated in Foxglove WebRTC | Transitive Robotics.
Of course, point clouds are a beast to stream no matter what, so down-sampling and/or compressing, e.g., using cloudini, will be the main challenge, independent of the communication channel.
Re. 50Hz+: I’d argue that this is overkill to stream to the web. It’s faster than most people can perceive and definitely faster than they can react, so you might as well send the same data chunked at 10Hz, if you really need all of it, e.g., for plotting.
Re. React vs. Web Components: Our own capabilities are all written in React but then also wrapped into a Web Component and made available as either.