Hey HN! Myself and my cofounder are excited to actually launch the product we've been working for the past six months. It's a robotics framework with a focus on testing and production. The current industry standard (ROS) is great for prototyping, but suffers from performance and testing problems as the robot gets more complex. I would have loved to work on this another six months or a year to polish it up and really, but I know it's better to launch a bit before you think you're ready.
It's a C++ pub-sub framework (a lot like ROS, in that way), but rather than declaring C++ publishers/subscribers directly, you declare the topics and types your code cares about in a configuration file, along with conditions on those inputs. Doing this allows for deep knowledge about the code running, which unlocks the possibility of deterministic simulation and testing (along with making it easy to generate bindings for other languages, create alternate schedulers, more easily swap out internal concepts, etc). It also enables easy static analysis of the codebase - given a launch file and arguments to the launch file, one can analyze the topic network and find missing publishers or publishers that publish to nothing.
Props to this team for picking Protobuf given its wider adoption unlike ROS and its custom format.
Is there a reason an existing pub-sub system like NATS isn’t suitable for a framework like this?
Also unfortunate that this project is written in C++ and offers Rust bindings rather than the other way around.
ROS bags are a useful facility for data capture and testing, and there are some ROS packages that are useful (against the backdrop of an awful packaging/build system). But even all that is just because the community decided this particular pub-sub system was the robotics one and started building packages on it.
So why ROS, robotics community, why?
This is a pretty common story. Python became very successful in a similar way. I have seen things like flight critical software written in Python not because Python is a good language for it (if I heard this 15 years ago I would laugh), but because Python became a de-facto standard for prototyping in the domain due to its libraries, tools and bindings and solving a realtime challenge for an existing prototype is often an easier lift than rebuilding it from scratch. My 2c.
ROS was developed as the framework for the PR1 robot, as a "Linux for robotics" idea. But it really took off when Willow Garage GAVE out a bunch of PR2 robots to academic institutes around the world.
It then stuck because those labs, even independently, developed really useful tools in a very backwards compatible language (C++) or with support to old languages (Lisp). You can find many repos such as this one which basically have EVERYTHING, handed down from PhD to PhD student over decades
https://github.com/jsk-ros-pkg
Basically a lot of the headache inducing grudge work exist there as a library, you only need to glue it together.
You want to calibrate your camera, get the relative position to the root of a robot arm? You can knack it together with openCV and then end up debugging for hours because coordinate transform convention was wrong. Or just install this library, publish your sensor data in specified topic, and it does it for you.
Imo it's easy to miss the usefulness of ROS if you don't consider the tf package, rosbag and rviz together with ROS as a bundle.
Everytime I see a pub/sub "new ROS" framework, sooner or later I realize I need to reinvent tf/rosbag/rviz, because those standard packages are almost never available (or available only for the developers specific need)
I’ve worked with ROS in commercial fleets of tens to hundreds of robots for, gosh I guess over a decade now. The main issue from my POV as a web person is how poor a fit ROS comms are across unreliable networks (basically anything outside localhost). ROS2 tries to do better with choose your own DDS but there’s still pains with wanting some of the basics found in other realms: compression, encryption, authentication/authorization, proper schemas and API definition/versioning.
Does Basis intend to target any of this?
Proper schemas/API versioning: I'm not sure what you mean by "proper schemas", but schema/API versioning is also an area I'd like to get right. I've been bit before by tests using old ros bags, before some message type was changed or topic name was moved.
After years of working with tens of thousands of deployed robots, one of the most painful things with ROS, from my perspective, is that the message definitions are very limiting. Cannot have `null` types. In research and shorter term contexts, it doesn't really jump out as an issue, but the story for how to upgrade and deploy to large fleets without downtime or hidden compatibility pains (MD5sum anyone?) is paramount when I think about "production" ready robotics.
https://en.wikipedia.org/wiki/Clock_domain_crossing
The trick is usually to stratify the navigation, path-planner, guidance, manual-overrides, and safe-machine-state system definitions into different problem domains.
YMMV =3
Perf: Again, mostly my experience, with ROS1, in self driving. Two issues:
1. High rate topics were previously a bit dicey - I remember someone hooking up an IMU driver directly to the topic graph with no batching (600 Hz) and causing some perf degradation. 2. There's no builtin controls for core pinning, etc, which hurts on high core systems. In fairness, we haven't implemented these either, but it's coming.
There's some ROS2 examples here: https://discourse.ros.org/t/ros2-speed/20162/2 but the topic is a little old, and it honestly looks a little dependent on the DDS backend. They are swapping to Zenoh anyhow (mostly for config complexity reasons, I believe), I'm not sure what the perf will be, there.
Getting real perf benchmarks is top of mind for me, understand if my explanation is not so convincing.
Deleted Comment
The limitations section at the bottom of the readme is excellent. Good level of detail and self-awareness. More projects need that.
Sadly, while theres a lot of stuff I like, ultimately I don't think this is the ROS replacement the world needs. Specifically because of step 1: clone the repo (or add as submodule).
Its a terrible move, IMO, to not have the pub/sub system be a binary executable or shared object file. ROS's fatal flaw (among many flaws IMO) is requiring every library-user to be able to build from source. I'm glad it doesnt dictate a folder structure, but I'm really sad to see this project continue the trend of needing to build from source.
I don't get your comment about ROS - in my experience with ROS, most users don't build the distribution from source, they use apt or similar, up until they need to fork it to fix some bug or another (and then cry because you have to muck with apt's repository version syntax to use _your_ version of the package and not upstream). Regardless, I think it is important that users are able to build from source if needed - see above. Why would you like to restrict that?
I'm actually not a fan of the "bring your own serializer" design. I think just use one serializer thats fast (like protobuf) and then let other serializers be built on top of that (e.g. JSON). I could be wrong, but thats my hunch of a good system.
Would it be crazy to try and connect it to Gazebo?
As for why not capnproto - I'm more experienced with protobuf. No good reason, in this case, other than popularity.
Also, if you do embedded, there's a lack of something akin to nanopb for capnproto.