Show HN: The easiest way to create web UIs for ROS robots
transitiverobotics.comOur new, free ros-tool capability makes it trivial to interact with ROS from the web. It provides a React API for subscribing and publish to topics and for placing service calls. It works with both ROS 1 and 2, and unlike rosbridge, it caches all data in the cloud, which means your UIs will work even when your robot is offline (just showing the latest data). Since all data is synced via the cloud, it is also much easier and more efficient to aggregate data from multiple robots, e.g., for showing your fleet on a map.
For those like me who don't know this space, ROS seems to be https://www.ros.org/
Thanks for adding this. Yes, ROS is the de-facto standard for robotics software middle-ware nowadays and the vast majority of new robotics startups build their robots with ROS. Some people say it's like democracy (the worst form of government except for all the others we've tried), but that still makes it the best option out there.
ROS is shit. In every possible way. It's a set of semi-related components, most of which can be done far better by doing it the normal way or writing it yourself. Nobody wants a "DDS" to simply send bits across and nobody wants their build system and nobody wants their half-assed protobuf reimplementation. And so on.
I also have strong feelings of frustration towards ROS but I have yet to see a viable alternating. Half the value of ROS is the community building robot specific packages on the ROS foundation. Any frustration with the system is certainly smaller than rolling a new one.
I'm working on one right now, no public code yet - http://basisrobotics.tech (well, we - myself and cofounder)
It's serialization independent (integrating a new serializer is super easy, you can even use ROS messages if you have a lot of legacy code to migrate), works with regular old CMake, and provides a framework to run deterministic replay/simulation against.
Hoping to put up a Show HN myself in a few weeks - need a few more pieces in place first - I have the foundation of the replay system written, but it's not all there, yet.
(Hi Christian!, Kyle here)
Well said!
I hear you man. The fact that a `byte` in ROS's bootleg protobuf is actually signed, and `string` is ASCII-only means that if you want to send a file or binary blob you have to use a `uint8[]`, which of course C++ will turn into a `std::vector<uint8_t>`. Good luck turning that into a proper `std::string` without an extra copy. And don't get me started on the comically scattered documentation for any basic use case that only ChatGPT can seem to make sense of. Better yet, the complete insanity that is node parameters - ever heard of reading from a file? Can't believe anyone takes this seriously.
ZeroMQ, protobuf, and a little thought would go a long way at our org.
/rant
ROS is really great for prototyping. Agree that it has some major issues for production.
“Free vs. Premium: The free version of this capability includes 100 MB of data transfer per month, throttles updates from the robot to the cloud/web to 1 Hz and limits the maximum message size to 10 KB. These limitations are lifted when you have a valid payment method on your account, allowing you to increase the rate to up to 10 Hz and increasing the maximum message size to 10 MB.”
Is there an open source self hosted option? Is this open source?
Yes, you can self-host Transitive (which is open-source): https://transitiverobotics.com/docs/develop/introduction. And on your self-hosted deployment you can install and use ros-tool with no limits -- except of course that you'll be paying your cloud provider a fee for data egress that is very similar to what we charge once you exceed the 100 MB limit.
Gotcha, thanks for the clarification! It certainly makes sense to charge for anything hosted, I just wasn’t familiar with the product or company.
In all contexts I've worked in so far, allowing the frontend to do ROS topic publications is a major security issue.
So what's the advantage of your cloud service vs something similar like https://github.com/groove-x/mqtt_bridge where you can easily create a MQTT API for your robots by hand-selecting topics to be exposed?
> easily create a MQTT API
That's a bit like asking: why do we need React when we have HTML and JS? ros-tool is built on Transitive, which uses MQTTSync -- an open-source protocol we've developed for doing data sync on top of MQTT (instead of just message passing). So we are several levels up from MQTT. But yes, if people want to, they can easily write their own Transitive capabilities (see https://transitiverobotics.com/docs/develop/creating_capabil...) and, in fact, the starter-code provided by our capability init script includes example code for subscribing to ROS. So if anyone wants to write their own, I recommend starting with that. But because ros-tool is built on Transitive, a developer can specify permissions at very fine granularity in the JWT they provide to their users, including not permitting any publishing from the front-end, and/or limiting access to specific topics or services.
Great idea, but curious what the market is for a service like this. Seems a little niche?
Well, every robotics company needs to manager their fleet somehow, and web tools are the way to go. My estimate is that there is currently a $4B market for fleet management software in service robotics. Not ginormous, but big enough, especially for bootstrapped businesses. And its growing rapidly.