Ncomm – A node-based robotics framework written in Rust

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 :)

Here's another one: "roboflex", 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!

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.

There is also Dora-RS which looks quite interesting - but I agree, improving ROS would be even better!

https://dora-rs.ai/

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.

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.

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.

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.

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.

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.

[dead]

This.

I have also worked with ROS professionally, and it does the opposite of “get out of the way” almost as a design choice. It’s bad.

It would also cut down on the amount of code in those packages significantly. The overhead of gluing things into ROS is enourmous (and mostly makes everything worse: a robotic control system running through 3-4 unsynchronised nodes communicating over a network-based pub-sub system on commodity hardware has very little hope of working if everything is well written, let alone with the average quality of a ROS package).

There's probably not that much overlap between people who are good at writing communications middleware and people good at each of those research problems; there's not even that much overlap between people good at each of those research problems.

This was exactly my experience. We used DDS for our non-ROS parts but ROS2 was experimental at the time so we ended up needing to build bridges for everything that was ROS. Brining in even a single ROS package to not have to reinvent things was a huge pain point and ROS had issues where it couldn't be used across everything.

It was a real shotgun shot to the face. What ROS 1 needed was to modernize ros_comm a bit so it doesn't crash when the network changes and it would be a far better solution, plus integrating multimaster_fkie.

Now we've got this bullshit with multiple slower RMWs with vastly larger overhead and none of them work reliably, clogging the network with multicasts. Not only that but some packages only work with some RMWs or just one, fracturing the ecosystem even further, because breaking everything every 2 years wasn't enough to reduce compatibility.

Like the whole point of ROS in principle is the standardization, grab any two packages and they will work with each other if you remap the topics because the message types are the same. The effort should be in the direction to further this standardization, not actively prevent it.

Awesome as Term is, NComm still wins in many ways on unexpanded 68k machines like plain A500.

It can keep up with decent speeds while not using much RAM.

Interesting tidbit for you my Amiga friend, guess from where the name Copper comes from in "Copper Robotics" (see the other thread for context) :)

I'm not very familiar with gstreamer-rs so this comment might not be super useful, but NComm doesn't currently have any streaming capabilities. If everything is Rust though, the local publishers and subscribers use `Arc` shared pointers to send data between Nodes so sending large amounts of data between Nodes has very little overhead.