Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PeppyOS: A simpler alternative to ROS 2 (now with containers support)

peppy.bot

Post reply on HN
Print view View original

21–30 of 43 posts

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#21

Post by mikepurvis »

cjwoodall wrote: post #13

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 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.

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#22

Post by dheera »

kevin42 wrote: post #6

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 mak…

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.

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#23

Post by dimatura »

cjwoodall wrote: post #13

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 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).

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#24

Post by a_t48 »

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.

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#25

Post by sgillen »

dheera wrote: post #22
kevin42 wrote: post #6

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 mak…

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 pro…

Can you say more about the nav stack? I thought nav2 was considered one of the better more mature packages in ROS2, but it's not my area of expertise.

| 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.

NVIDIA actually is addressing this with NITROS: https://nvidia-isaac-ros.github.io/concepts/nitros/index.htm...

And ROS native buffers: https://discourse.openrobotics.org/t/update-on-ros-native-bu...

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#26

Post by droelf »

kevin42 wrote: post #6

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 mak…

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.

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#27

Post by dheera »

sgillen wrote: post #25
dheera wrote: post #22

Earlier quoted context omitted.

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 pro…

Can you say more about the nav stack? I thought nav2 was considered one of the better more mature packages in ROS2, but it's not my area of expertise. | 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. NVIDIA actually is addressing this with NITROS: https://nvidia-isaac-ros.github.io/concepts/nitros/index.htm...…

> Can you say more about the nav stack?

It's fine for robots like these

https://docs.nav2.org/about/robots.html

It's not useful for robots like these

https://www.youtube.com/watch?v=XoQI-kLRrXA

https://www.youtube.com/shorts/hKVwM5pa3NQ

https://www.youtube.com/shorts/XA_jjE2OES4

https://www.youtube.com/shorts/JOqc7dmmD5o

https://www.youtube.com/shorts/v9Pilgh1vcA

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#28

Post by LatticeAnimal »

digikata wrote: post #5
LatticeAnimal wrote: post #4

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.

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.

Physically crash. When we would block the control loop at all (even down to 100hz), we would get errors and then occasionally the arm would erratically experience massive acceleration spikes and crash into its nearby surroundings before e-stopping.

Re: Other comment. Yes, this was with ur3e s which by default have update rates at around 500hz.

Re: PeppyOS: A simpler alternative to ROS 2 (now with containers support)

#30

Post by sebastos »

a_t48 wrote: post #24

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…

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.

Post reply on HN