[kevin42]

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.

[dheera]

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.

[sgillen]

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

[dheera]

> 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

[Ekami]

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.

[menaerus]

What alternatives there are that exist and can replace ROS? I imagine that not all companies are using ROS, however, I'm not in that field exactly so I don't know. I always thought that the quality of that code is mediocre at best.

[dheera]

Most companies in production are inventing their own purpose-built systems and not open-sourcing them. High speed control loops usually use some form of real-time OS, AI-forward robots are starting to use fused CUDA kernels.

[droelf]

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.

[Ekami]

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/

[Ekami]

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.