6 ms·
PeppyOS: A simpler alternative to ROS 2 (now with containers support)
- Jenzaah 6mo agoWhat makes this better than HORUS? Also Rust based, and opensource already.
- ijustlovemath 6mo agoThere's no actual source for this, just some examples
- blensor 6mo agoLooking through the website and github, it looks a bit premature to post at all. I don't have too much love for ROS personally but that claim the title is making is quite bold
- LatticeAnimal 6mo agoIIRC, 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.
- digikata 6mo agoCrash? 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.
- Symmetry 6mo agoI'm guessing running a 200 Hz command rate on an e-series UR which uses 1 kHz internally will give you a protective stop?
- LatticeAnimal 6mo agoPhysically 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.
- Ekami 6mo ago> 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
- kevin42 6mo agoI'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.
- dheera 6mo agoROS 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.
- sgillen 6mo agoCan 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.html https://nvidia-isaac-ros.github.io/concepts/nitros/index.htm... And ROS native buffers: https://discourse.openrobotics.org/t/update-on-ros-native-buffers/51771 https://discourse.openrobotics.org/t/update-on-ros-native-bu...
- dheera 6mo ago> Can you say more about the nav stack? It's fine for robots like these https://docs.nav2.org/about/robots.html 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/watch?v=XoQI-kLRrXA https://www.youtube.com/shorts/hKVwM5pa3NQ https://www.youtube.com/shorts/hKVwM5pa3NQ https://www.youtube.com/shorts/XA_jjE2OES4 https://www.youtube.com/shorts/XA_jjE2OES4 https://www.youtube.com/shorts/JOqc7dmmD5o https://www.youtube.com/shorts/JOqc7dmmD5o https://www.youtube.com/shorts/v9Pilgh1vcA https://www.youtube.com/shorts/v9Pilgh1vcA
- colinator 6mo agoI'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....
- jeff-hykin 6mo agoTake 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.
- 094459 6mo agoThis doesnt look open source, so maybe not a good comparison with ROS
- antoineleclair 6mo agoI 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.
- AlfredBarnes 6mo agohttps://xkcd.com/927/ https://xkcd.com/927/
- cjwoodall 6mo agoI 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
- jeff-hykin 6mo agoAs 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.
- rcxdude 6mo agoThis 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)
- deleted 6mo ago[deleted]
- mikepurvis 6mo agoI'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.
- steve_adams_86 6mo agoIt 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/ 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.
- Ekami 6mo agoFeedback 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".
- irishcoffee 6mo agoOne 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.
- luc_ 6mo agoyet another roll your own ROS...
- a_t48 6mo agoHey uh - good luck. I spent a while smashing my head against this. You should read https://basisrobotics.tech/2025/01/08/postmortem/ 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.
- sebastos 6mo agoI 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/ 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.
- deleted 6mo ago[deleted]
- synergy20 6mo agowhen will this be ready and is this as open as ros2?