6 ms·

OK, so now we have: Basis Robotics (C++), Copper Robotics (Rust), and NComm (Rust) all trying to replace ROS. Shouldn't you guys be working together instead? Al

OK, so now we have: Basis Robotics (C++), Copper Robotics (Rust), and NComm (Rust) all trying to replace ROS. Shouldn't you guys be working together instead? Also, can't we just all instead improve ROS instead? I think Zenoh is leading the way there, introducing a new ROS 2 middleware, rather than trying to replace it wholesale. Also, in case you didn't know, some much larger companies tried to replace ROS and eventually saw the light and gave up: NVidia (Isaac, yes, Isaac was at first a new framework for robotics that was meant to replace ROS, they've since reused that name to mean something else), and Viam (Go; now a ROS sponsor).

awesomebytes 2y ago
This.
italicmew 2y ago
Agreed. But just to be clear, ROS ecosystem sucks. I'm personally tired of the lack of consistent versioning, bad package system, every new version a breaking change is introduced somewhere...etc. I known, that does not exclude the fact that people should try to work together, but maybe not using the same ROS philosophy.
droelf 2y ago
There is also Dora-RS which looks quite interesting - but I agree, improving ROS would be even better! https://dora-rs.ai/ https://dora-rs.ai/
- ramon156 2y ago
  I'd put my money's worth on dora-rs instead, seems like a much more promising tool
Q6T46nT668w6i3m 2y ago
Cargo is great so I’m surprised we’re not seeing tinier interoperable packages (e.g., tasks like serialization and transport) instead of C++-like frameworks.
colinator 2y ago
Here's another one: "roboflex", https://github.com/flexrobotics https://github.com/flexrobotics ROS is irredeemable. I've seen it used in large projects, and the amount of time wasted "wrestling with ros" was ridiculous. I believe this will never change. Just because tensorflow existed meant folks shouldn't have looked for an easier way, and created PyTorch? No! Forge on, intrepid ros-replacers!
- jdiez17 2y ago
  I think ROS' biggest benefit is that the "golden path" is well documented and it has a huge community. I found that if you "stick to the golden path" (monorepo with all your nodes/pkgs + colcon as the build system, deploy to a single supported OS), ROS mostly Just Works. That's a lot of pre-conditions though. But if you deviate a little bit, you're in for a world of pain. If you try to develop a ROS system as any other C/C++/Python project, there will be some confusing things like always having to source the environment setup file. Installing it is ... difficult (to say the least) if you're not using the exact version of Ubuntu that is officially supported. One pretty good workaround I found for this is using a VSCode Dev Container for ROS development. I'm then cross compiling to arm64 using Yocto Linux and meta-ros, so I get reliable and reproducible deployments. Once you get over the initial setup pain (which is significant), it's not too bad. I think things could be significantly improved, but I will also say - I see many students at my uni which build advanced robots with ROS and they probably wouldn't consider themselves expert programmers. A similar effect happens with Arduino. And replicating this "novice-compatibility" is in my opinion the hardest part of replacing ROS.
  - leetrout 2y ago
    > always having to source the environment setup file We are wrapping everything in bash entry points to accomplish this. > ... build advanced robots with ROS ... Yes, experiencing this first hand... there are just so many examples out there for integrating with all the various sensors and such. > I'm then cross compiling to arm64 using Yocto Linux and meta-ros, so I get reliable and reproducible deployments. Once you get over the initial setup pain (which is significant), it's not too bad. Can we get a call and talk about this? Because I'm comfortable with the concepts you're talking about but we've not sorted out how to make an actually deployable artifact from (for one example) our workspace making use of pymoveit. EDIT: Saw your email in your profile and sent a message
gbin 2y ago
Copper Robotics creator here: the issue with ROS IMHO is that the architecture is not ideal and if you want your framework to be just ROS compliant you get all the issues the other comments are talking about (wrestling, tuning and so on). Copper is deterministic by design, data oriented from head to toes (we get 100x less latency than ROS2 out of that), performance tuning can be done algorithmically instead of having to have a developer in the loop and we leverage the awesomeness of cargo to have a sane package management that is familiar to rust developers etc... all those are basically impossible to achieve if we don't call it ROS3 or something :)
- deleted 2y ago
  [deleted]
- moffkalast 2y ago
  Yeah but can the average postgrad use it to deploy their whatever pytorch thing with ten lines of python? If the answer to that is no, then not much bleeding edge research will ever use it. I'm not a fan of what OSRF has done with ROS 2 personally, but supporting both python and C++ is one of the good bits, even though that support has degraded since ROS 1.
  - rcxdude 2y ago
    Certainly newbie-friendliness is a good attribute (and I'd argue ROS isn't that particularly, even apart from all the bad habits it teaches, there's just a lot of tutorials for it), but it would be nice to have an alternative that's good for professional use, regardless of whether academia uses it.
jdiez17 2y ago
Totally agree, Zenoh is a breath of fresh air. Being able to interoperate with a ROS system without having to hook into the whole build system is huge. I can imagine a future where we have "established" ros2 packages like nav2, moveit, ros2_control etc using ROS's DDS abstractions, launch system and whatnot - while other parts of the system are written in simple Python/C++/Rust and just interact via DDS. That way we can slowly figure out more ergonomic ways of build/install/package/run nodes without sacrificing the really useful software that exists in the ROS2 ecosystem.
spicy_indian 2y ago
Here's another one: https://github.com/matt-attack/pubsub https://github.com/matt-attack/pubsub And it even has recording/playback and visualization features in the author's other repos.
n8w3rt 2y ago
NComm creator here: I've been following the Copper Robotics project for a bit and I love the design. I would say that copper has a lot larger of a scope than NComm (i.e. executor, drivers, logging, etc.). With NComm, I was focusing much more on something as close to ROS 2's execution model as possible, but without the headaches of it being ROS and C++. In general, I think of NComm as more of a communication library (hence Comm) with the added benefit of standardized tasks and executors to make breaking up the various robotics tasks into small more manageable chunks. Personally, I like that there's a ton of projects trying to replace the ROS middleware because we've all chosen a different way of fixing the problem so no one's stuck using ROS because its the only option.
mandibles 2y ago
This is a broader sentiment that can be applied to just about any open source ecosystem. Sometimes the technical debt and legacy install base of an existing project is too great to overcome. Sometimes people want to build a library that duplicates existing work just to see if they can. Sometimes personalities involved just don't mesh.
rcxdude 2y ago
improving ROS means breaking it, it's not just the details which are bad but a lot of the baked-in architecture (distribute everything! Now you have N+1 problems where N is the number of nodes). ROS 2 was an opportunity there but not much improved.
trashburger 2y ago
Had Nvidia put their hubris aside for a second (tough ask, I know) and worked to make Isaac into an open source project, it would have eaten ROS' lunch. The subgraph-based approach was much better, the node/component/channel approach is intuitive, and had it been improved upon with better DX, it would be wonderful to use. Plus it used Bazel instead of the godawful colcon. The only good part of ROS is IPC which Isaac sucks at. Sadly they decided to abandon it and repurpose their GEMs as ROS packages instead.

awesomebytes 2y ago

This.

italicmew 2y ago

Agreed. But just to be clear, ROS ecosystem sucks. I'm personally tired of the lack of consistent versioning, bad package system, every new version a breaking change is introduced somewhere...etc. I known, that does not exclude the fact that people should try to work together, but maybe not using the same ROS philosophy.

droelf 2y ago

There is also Dora-RS which looks quite interesting - but I agree, improving ROS would be even better! https://dora-rs.ai/ https://dora-rs.ai/

ramon156 2y ago
I'd put my money's worth on dora-rs instead, seems like a much more promising tool

Q6T46nT668w6i3m 2y ago

Cargo is great so I’m surprised we’re not seeing tinier interoperable packages (e.g., tasks like serialization and transport) instead of C++-like frameworks.

colinator 2y ago

Here's another one: "roboflex", https://github.com/flexrobotics https://github.com/flexrobotics ROS is irredeemable. I've seen it used in large projects, and the amount of time wasted "wrestling with ros" was ridiculous. I believe this will never change. Just because tensorflow existed meant folks shouldn't have looked for an easier way, and created PyTorch? No! Forge on, intrepid ros-replacers!

jdiez17 2y ago
I think ROS' biggest benefit is that the "golden path" is well documented and it has a huge community. I found that if you "stick to the golden path" (monorepo with all your nodes/pkgs + colcon as the build system, deploy to a single supported OS), ROS mostly Just Works. That's a lot of pre-conditions though. But if you deviate a little bit, you're in for a world of pain. If you try to develop a ROS system as any other C/C++/Python project, there will be some confusing things like always having to source the environment setup file. Installing it is ... difficult (to say the least) if you're not using the exact version of Ubuntu that is officially supported. One pretty good workaround I found for this is using a VSCode Dev Container for ROS development. I'm then cross compiling to arm64 using Yocto Linux and meta-ros, so I get reliable and reproducible deployments. Once you get over the initial setup pain (which is significant), it's not too bad. I think things could be significantly improved, but I will also say - I see many students at my uni which build advanced robots with ROS and they probably wouldn't consider themselves expert programmers. A similar effect happens with Arduino. And replicating this "novice-compatibility" is in my opinion the hardest part of replacing ROS.
- leetrout 2y ago
  > always having to source the environment setup file We are wrapping everything in bash entry points to accomplish this. > ... build advanced robots with ROS ... Yes, experiencing this first hand... there are just so many examples out there for integrating with all the various sensors and such. > I'm then cross compiling to arm64 using Yocto Linux and meta-ros, so I get reliable and reproducible deployments. Once you get over the initial setup pain (which is significant), it's not too bad. Can we get a call and talk about this? Because I'm comfortable with the concepts you're talking about but we've not sorted out how to make an actually deployable artifact from (for one example) our workspace making use of pymoveit. EDIT: Saw your email in your profile and sent a message

gbin 2y ago

Copper Robotics creator here: the issue with ROS IMHO is that the architecture is not ideal and if you want your framework to be just ROS compliant you get all the issues the other comments are talking about (wrestling, tuning and so on). Copper is deterministic by design, data oriented from head to toes (we get 100x less latency than ROS2 out of that), performance tuning can be done algorithmically instead of having to have a developer in the loop and we leverage the awesomeness of cargo to have a sane package management that is familiar to rust developers etc... all those are basically impossible to achieve if we don't call it ROS3 or something :)

deleted 2y ago
[deleted]
moffkalast 2y ago
Yeah but can the average postgrad use it to deploy their whatever pytorch thing with ten lines of python? If the answer to that is no, then not much bleeding edge research will ever use it. I'm not a fan of what OSRF has done with ROS 2 personally, but supporting both python and C++ is one of the good bits, even though that support has degraded since ROS 1.
- rcxdude 2y ago
  Certainly newbie-friendliness is a good attribute (and I'd argue ROS isn't that particularly, even apart from all the bad habits it teaches, there's just a lot of tutorials for it), but it would be nice to have an alternative that's good for professional use, regardless of whether academia uses it.

jdiez17 2y ago

Totally agree, Zenoh is a breath of fresh air. Being able to interoperate with a ROS system without having to hook into the whole build system is huge. I can imagine a future where we have "established" ros2 packages like nav2, moveit, ros2_control etc using ROS's DDS abstractions, launch system and whatnot - while other parts of the system are written in simple Python/C++/Rust and just interact via DDS. That way we can slowly figure out more ergonomic ways of build/install/package/run nodes without sacrificing the really useful software that exists in the ROS2 ecosystem.

spicy_indian 2y ago

Here's another one: https://github.com/matt-attack/pubsub https://github.com/matt-attack/pubsub And it even has recording/playback and visualization features in the author's other repos.

n8w3rt 2y ago

NComm creator here: I've been following the Copper Robotics project for a bit and I love the design. I would say that copper has a lot larger of a scope than NComm (i.e. executor, drivers, logging, etc.). With NComm, I was focusing much more on something as close to ROS 2's execution model as possible, but without the headaches of it being ROS and C++. In general, I think of NComm as more of a communication library (hence Comm) with the added benefit of standardized tasks and executors to make breaking up the various robotics tasks into small more manageable chunks. Personally, I like that there's a ton of projects trying to replace the ROS middleware because we've all chosen a different way of fixing the problem so no one's stuck using ROS because its the only option.

mandibles 2y ago

This is a broader sentiment that can be applied to just about any open source ecosystem. Sometimes the technical debt and legacy install base of an existing project is too great to overcome. Sometimes people want to build a library that duplicates existing work just to see if they can. Sometimes personalities involved just don't mesh.

rcxdude 2y ago

improving ROS means breaking it, it's not just the details which are bad but a lot of the baked-in architecture (distribute everything! Now you have N+1 problems where N is the number of nodes). ROS 2 was an opportunity there but not much improved.

trashburger 2y ago

Had Nvidia put their hubris aside for a second (tough ask, I know) and worked to make Isaac into an open source project, it would have eaten ROS' lunch. The subgraph-based approach was much better, the node/component/channel approach is intuitive, and had it been improved upon with better DX, it would be wonderful to use. Plus it used Bazel instead of the godawful colcon. The only good part of ROS is IPC which Isaac sucks at. Sadly they decided to abandon it and repurpose their GEMs as ROS packages instead.