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.
cjwoodall 1 hours ago [-]
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
jeff-hykin 53 minutes ago [-]
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.
42 minutes ago [-]
colinator 2 hours ago [-]
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....
jeff-hykin 48 minutes ago [-]
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.
094459 1 hours ago [-]
This doesnt look open source, so maybe not a good comparison with ROS
antoineleclair 1 hours ago [-]
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.
pavon 40 minutes ago [-]
BSL is not an open source license. It is a proprietary source-available license that prohibits any "production" use.
LatticeAnimal 3 hours ago [-]
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.
digikata 3 hours ago [-]
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.
Symmetry 1 hours ago [-]
I'm guessing running a 200 Hz command rate on an e-series UR which uses 1 kHz internally will give you a protective stop?
Jenzaah 3 hours ago [-]
What makes this better than HORUS? Also Rust based, and opensource already.
ijustlovemath 3 hours ago [-]
There's no actual source for this, just some examples
blensor 3 hours ago [-]
Looking 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
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.
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
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....
Always looking for testers and feedback if you want to influence the design/API.
> 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.
The website claims “30hz polling rate”, “2ms latency”. Not sure if that is a best case or just for that demo.