I will admit I have almost always made the choice to not use ros2. I am trying to use it now for some work, and I can see where/when it would be useful...
But I almost always feel like there is just so much STUFF involved in ros, that really is just better resolved by having really robust controllers, well defined protocols, and everything else.
I wait to pass judgement until I have more information though
I've got one of these! Mine is called 'roboflex' (github.com/flexrobotics). It's c++/python, not rust. But similarly born out of frustration with ros. Writing your own robotics middleware seems to be a rite of passage. Just like 'writing your own game engine'. Nothing wrong with that - ros is powerful but has legit problems, and we need alternatives.
Although tbh, these days I'm questioning the utility. If I'm the one writing the robot code, then I care a lot about the ergonomics of the libraries or frameworks. But if LLMs are writing it, do I really care? That's a genuine, not rhetorical question. I suppose ergonomics still matter (and maybe matter even more) if I'm the one that has to check all the LLM code....
It looks like this is cleaner and simpler than ROS 2, and the API seems nice, but it would be really difficult to diverge from the standard and use an ecosystem with a very small community and no momentum behind it. Does this have any compelling selling points to convince someone to switch other than 'less overhead than ROS 2'?
I'm not trying to downplay that selling point at all. My experience with ROS 2 is limited but that aspect of it was miserable.
This is such a small nit, but landing at the docs page (https://docs.peppy.bot/) and seeing this splash is annoying to me. Just show the docs.
Also it would be nice if I could switch between Rust and Python examples and have all code panes respect that choice, rather than have to switch every pane to Rust.
This doesnt look open source, so maybe not a good comparison with ROS
Hey uh - good luck. I spent a while smashing my head against this.
You should read https://basisrobotics.tech/2025/01/08/postmortem/ and consider: - How you will get users - How you will fund development - What the "good parts" from ROS and other frameworks you want to take
I notice you don't have shared memory transport, nor do you support runtime composability (I think?). This might make perception heavy stacks run poorly. I'm also a little confused on what serialization format you support - is it an entirely custom one? It looks like two publishers with the same topic type will duplicate the schema, which is a bit odd. Worth also considering how you will do recording/replay.
Additionally - BSL feels great, but I found it scared off some people. IMO just do Apache 2.0 if you're going to have some other revenue stream anyhow.
I spent like...a year thinking about this stuff, happy to chat at kyle@basisrobotics.tech if you need a friendly ear.
IIRC, the ROS UR controller runs at 200Hz and we’ve had arms crash when they run much slower than that.
The website claims “30hz polling rate”, “2ms latency”. Not sure if that is a best case or just for that demo.
One of the only ways I can imagine that would _somehow add even more complexity_ to the disaster that is ROS/ROS2, is to try and make rust a first-class citizen.
You're using ROS2, so you have a problem. You want to add rust to fix it? Now you have 47 problems.
What makes this better than HORUS? Also Rust based, and opensource already.
yet another roll your own ROS...
I'd love to use something other than ROS2, if for no other reason than to get rid of the dependency hell and the convoluted build system.
But there are a lot of nodes and drivers out there for ROS already. It's a chicken and egg thing because people aren't going to write drivers unless there are enough users, and it's hard to get users without drivers.
It looks like their business model is to give away the OS and make money with FoxGlove-like tools. It's not a bad idea, but adoption will be an uphill battle. And since they aren't open source yet, I certainly wouldn't start using it on a project until it us.