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

31–40 of 43 posts

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

#31

Post by Ekami »

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…

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.

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

#32

Post by Ekami »

droelf wrote: post #26
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.

Fun fact, we've been using pixi to compile everything Python related internally. In fact PeppyOS was even started with pixi as a base layer (but we pivoted away from it since the project is in Rust and Cargo is the de-facto toolchain). We support uv by default for Python (since it's what's the most used these days) but pixi is already supported, see the note on this page: https://docs.peppy.bot/guides/first_node/

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

#33

Post by Ekami »

dheera wrote: post #27
sgillen wrote: post #25

Earlier quoted context omitted.

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

Very interesting. There is nothing that would prevent PeppyOS nodes from running on the GPU. The messaging tech behind PeppyOS is Zenoh (it's swappable), it can run on embedded systems (PeppyOS nodes will also be compatible with embedded in the future). That being said, at the moment the messaging system runs exclusively on the CPU.

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

#34

Post by Ekami »

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

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.

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

#35

Post by Ekami »

steve_adams_86 wrote: post #18

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…

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

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

#36

Post by Ekami »

pavon wrote: post #17
antoineleclair wrote: post #10

Earlier quoted context omitted.

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.

BSL is not an open source license. It is a proprietary source-available license that prohibits any "production" use.

BSL will just prevent people from creating a competing SaaS product on top of PeppyOS, nothing will prevent anyone from using it for free commercially

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

#37

Post by Ekami »

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.

> 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

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

#38

Post by Ekami »

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…

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.

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

#39

Post by a_t48 »

sebastos wrote: post #30
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…

I was sad, too. If there was a way I thought to continue doing it, I would. But as it is I'm actually considering getting out of robotics at this point, I've had enough of everyone "Living That Way".

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

#40

Post by rcxdude »

jeff-hykin wrote: post #14
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

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.

This is my experience as well. The average quality in ROS is rock-bottom and so while it contains all of the things you might want from a robotics framework, you pay dearly for it. I would also say that whole the concept of distributed network modes is a convenient one for robotics development, stringing your control loops through such a structure is a recipe for disaster and should be avoided in your system design as much as possible (and one of the problems with ROS as a framework is that it heavily encourages this)
Post reply on HN