PeppyOS: A simpler alternative to ROS 2 (now with containers support) (opens in new tab)

ROS is, in my opinion, dying on the industry front.

* It is a dependency hell

* It is resource-heavy on embedded systems

* It is too slow for real-time, high speed control loops

* Huge chunks of it are maintained by hobbyists and far behind the state of the art (e.g. the entire navigation stack)

* As robotics moves toward end-to-end AI systems, stuff needs to stay on GPU memory, not shuttled back and forth across processes through a networking stack.

* Decentralized messaging was the wrong call. A bunch of nodes running on a robot doesn't need a decentralized infrastructure. This isn't Bitcoin. Robots talking to each other, maybe, but not pieces of code on the same robot.

We're working hard to get ROS out of dependency hell - https://prefix.dev/blog/reproducible-package-management-for-...

Would love to hear your thoughts.

Hey, good points, we have plans to create a ROS2 bridge in the near future. We definitely won't be able to catch up with huge ecosystem that ROS2 has created over the years but we will rewrite the annoying parts, that's for sure.

I've been a ROS 1 (and now 2) user since 2010. I like the game engine analogy given elsewhere in the thread, in that ROS gives you some important things "for free" if you cooperate with its ecosystem conventions. Data bagging, visualization, teleop, and sim are the some obvious ones that I think a lot of teams don't think about if they're just focused on getting cartographer or whatever going, and not considering the larger development and debugging questions.

For some, packaging/deployment would also fall under the umbrella of a solved-by-ROS problem, however I don't think the Open Robotics supplied debs are suitable for most product deployments, for a variety of reasons that I've discussed in two separate ROSCon talks.

I usually feel the same when starting something new. The "STUFF" is annoying and often feels like overkill when a project is new and minimal. Installing/building ROS, the package boilerplate, etc. And often I can get away with more minimal alternatives like just a single (possibly multithreaded) process, or multiple processes with a simple IPC. But then again I often end up wanting a lot of the extra stuff you get with ROS like the bags, the viewers, the cli tools, etc. LLMs help on both fronts though - they're decent at making DIY versions of ROS-like functionality, but they're also pretty good at handling the ROS boilerplate. (Which is one area where I'd see peppyOS being a severe disadvantage).

As someone who has used ros2, I feel fine passing judgment; it is terrible. If its easier to write your own stack, do it. Your own stack will be easier to add to and maintain long term. The conceptual design (nodes) is great, its just the execution that is awful.

Our goal is to make all of this super easy with the installation of a single script. We're also working on a SaaS in parallel which will allow you to fire up the whole stack in your browser, 0 setup required (you pick the robot you want and it runs in a sim in your browser). Then, when you're satisfied with the result you just run a bash script on your Jetson board and everything will work the same on your real robot.

Take a look at github.com/dimensionalos/dimos. We are a team making - not only a replacement for ROS - but one that can be easily vibe coded, and one with compatibility with ros and containers.

Always looking for testers and feedback if you want to influence the design/API.

Feedback noted, thanks! > Does this have any compelling selling points to convince someone to switch other than 'less overhead than ROS 2'?

At the moment it's pretty raw, but we'll eventually turn it into a "no fuss entry into robotics".

I see in their FAQ:

> Will PeppyOS be open source?

> Yes! PeppyOS will be fully open source under a BSL license before the end of this year. Once the software is mature, everyone will be able to contribute and participate in its development.

Crash? The software, or physically? A 200Hz as a min control loop rate seems on the fast side as a general default, but it all depends on the control environment - and I may be biased as I've done a lot more bare silicon controls than ROS.

> The website claims “30hz polling rate”, “2ms latency”. Not sure if that is a best case or just for that demo.

This is just example cases but in fact it can go as high as you want as long as your hardware allows it

There's no actual source for this, just some examples

I was sad to see you guys shut down - I think you were on to something with deterministic faster-than-realtime replay. Not surprised it was hard to find paying customers, but for what it's worth, my engineering self thought that you guys were solving the right problem. As far as I can tell, it's still not solved, and the shocking truth is that everyone is just Living That Way.

The other thing that is important is how to provide a more query-like interface to tease out the data you actually want your node to react to, yet in a way that will be deterministic. You need to guide users away from introducing non-determinism, which can be tricky because innocent things like a message buffer with a max size can lead to such situations.

I have talked with one of the key people at Xronos (https://www.xronos.com/), who are trying to attack related problems. Still, even they aren't quite as pre-occupied with _replay_, which is crucial.

I think the sad truth is that the second evolution of all this frameworking simply hasn't come together convincingly enough, and in one place, for it to gather momentum. It turned out to be hard. And now that it has taken too long, it's my bet that ROS2 and all of its imitators will get lapped by holistic deep approaches. Not the stupid stuff happening with these fake humanoid robot companies mind you, but still - something holistic and deep. Something coming out of the predictive coding research e.g., or world models, etc. Training in simulated environments with generative systems is going to lead to behavior so much more sophisticated than gluing together all of our little services. Roboticists have their own version of the bitter lesson coming soon.

Hey, too bad you've shut down, looked like a great project.

> I notice you don't have shared memory transport, nor do you support runtime composability (I think?)

We're using Zenoh in the backend, we didn't try to reinvent the wheel on that front.

> I'm also a little confused on what serialization format you support - is it an entirely custom one?

It's cap'n proto, but abstracted away for the user so he doesn't have to think about it.

> BSL feels great, but I found it scared off some people

Agreed, but we're building a SaaS in parallel, PeppyOS will be 100% free and open source but we don't want another company to build a SaaS on top of it, that will be the only restriction of the BSL license, otherwise it's the same as Apache 2.0.