I built Altara, a React component library for real-time robotics and telemetry UIs. It connects natively to rosbridge and ships with components that most GCS builders end up rebuilding from scratch.
What’s included:
-
Attitude indicator, HSI, altimeter, airspeed — aerospace instruments
-
Occupancy grid, LiDAR point cloud viewer, object detection overlay — AV/robotics
-
Time-series charts, signal panels, waterfall spectrogram — general telemetry
-
Native rosbridge + MQTT adapters
Live demo: https://jayasaikishanchapparam.github.io/altara/demo/ GitHub: https://github.com/JayaSaiKishanChapparam/altara
Would love feedback from people actually building ROS2 monitoring interfaces — what’s missing, what’s broken, what you’d actually use.
4 Likes
Very cool library of components, @Jaya_Sai_Kishan !
As a potential adopter my main question would be: how do I know these will be maintained in the long-run? This question matters in robotics more than in other fields, simply because everything takes longer in robotics (hardware can’t suddenly “grow” 100x over night as software does) so you need to plan ahead for longer? (guess how many fielded robots still run on ROS 1!)
I believe it is this question that drive a lot of people in robotics to fork-and-self-maintain rather than depend on third-party maintainers, even for some well established (but poorly maintained) ROS packages. So I think overcoming that question is the main hurdle for open-source contributors like you and it is one of the reasons I so firmly believe that open-source needs a business model, especially in robotics. I started Transitive Robotics to offer just that (analogous to Android), and you are welcome to make your components available on the platform, especially if there are some “pro” extensions you could offer for a premium that would allow you to maintain all these components long-term, professionally.
I would also argue that it is because Foxglove has a solid business model that people are more likely to adopt it instead of some of the open-source alternatives such as rosboard. Free and open are great, but longevity is actually much more important when building a complex stack. Otherwise, well, we all know this picture:
1 Like
Oh hey some of those widgets look really neat! I’ve never seen such a focus on aerospace indicators in ROS related visualizers since there’s not a whole lot in terms of flying platforms that have good integration (Crazyflie, Matrice, custom builds with MAVROS+Pixhawk, and that’s about it), and the bureaucracy involved with actually flying anything anywhere outdoors has become astronomical. I’m really curious about what’s your specific use case that drove you to develop this toolset?
1 Like
This is exactly the right question to ask, and honestly the one I’ve been thinking about most.
You’re correct that longevity is the real adoption barrier and the ROS 1 example is perfect. The “fork-and-self-maintain” behavior you describe is a rational response to a real risk, not stubbornness.
My honest answer: right now Altara is maintained by one person, and I’m not going to pretend that’s a long-term guarantee. What I can say is that the architecture is intentionally simple Canvas + React, no exotic dependencies, each component is self-contained, so the maintenance burden per component is low and the fork-and-self-maintain path is viable if needed.
On the business model point, you’re right, and I’ve been thinking about a Pro tier and eventually a cloud connector for managed telemetry. The Transitive Robotics model is interesting and worth a closer look. I’d genuinely like to understand more about how the platform works and whether there’s a fit.
What does component availability on Transitive Robotics look like in practice?
Glad the aerospace indicators stood out, that was intentional. The gap you’re describing is exactly what motivated it: MAVROS+Pixhawk setups have solid flight stacks but the ground station visualization side is either proprietary, desktop-only, or you’re stitching together generic charting libraries that weren’t built for flight data.
My use case was building a custom ground control interface for a project and realizing there was no embeddable React component library that understood what a PFD actually is, or why a heading tape behaves differently from a generic gauge. Everything either looked like a Grafana panel or required running a full desktop application.
The regulatory frustration is real, the bureaucracy has definitely pushed a lot of development toward simulation and indoor platforms, which is part of why I made sure the components work just as well on Crazyflie-scale projects as on larger MAVROS builds. mockMode on every component means you can develop and demo without hardware at all.
Curious what platform you’re working with, always useful to know which setups people are actually running.
It’s described in this section: Publishing Capabilities | Transitive Robotics. The ones preceding it describe how to create a new capability (from a starter template we provide).
Well for our lab specifically, we do have some Crazyflies but admittedly nobody’s quite gotten around to doing anything proper with them. There are some firmware problems around image streaming, or at least were the last time anyone tested. We’ve used MAVROS on a few AUVs in a project (on some level submarines are just water airplanes, so the visualization demands are somewhat similar haha), BlueRobotics has an emulated PX4 setup on their controllers so it’s the only way to really interface with those.
Our missing use case was more around having a way to register sonar and lidar data with satellite tile maps, plus sending waypoint missions. We’ve implemented something akin to QGroundControl for ROS for that and I’ve even added something similar to a PFD to it a while back though it’s more of a general rotational visualizer.
There is another project we’ve got now though that involves doing a localization subsystem for aerospace, in which case the final result would be presented in a way that’s at least somewhat up to standard for actual pilots, so Altara’s PFD and HSI would be a pretty great fit.
Honestly imo the switch between ROS1/2 is not really about sunk cost of self supported legacy code. Alright fine, in lots of corporate cases it is. As an example though, we teach ROS 2 with Turtlebots and use it a fair bit on various AGVs where Nav2 is the way to go… but still find ourselves using ROS One on practically all other platforms. Our research code is mostly python and with rclpy being in the absolute state it currently is in the efficiency difference is a complete no brainer, you get several times more performance out of the same machine and more repeatable node behavior. Just the time saved not having to constantly debug DDS issues pays for itself in gained productivity. Thanks @v4hn and the rest for maintaining that btw 