Ncomm – A node-based robotics framework written in Rust | Hacker News Reader

Ncomm – A node-based robotics framework written in Rust

github.com

60 pointsTycho8732 comments

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

This.

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/

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

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.

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!

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.

> 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

Sure! I love to talk about this stuff ;) My email is in my profile. Let me know what you're trying to accomplish and we can discuss it.

For context: I'm building a "satellite bus/payload computer" OS based on Yocto Linux for space applications addressing the typical problems people encounter when trying to use Linux for space:

- I've set up my robot/OBC/gadget by copying files into a /home/user and it's running. How do I deploy this and keep track of how the image was built? Some people make an image of the SD card. Other people make a script that customizes the rootfs and creates an image (better!). But we want to have control of the whole stack, since we want to implement secure boot and a few other things.

- I want to update my robot/satellite. Ideally using as little bandwidth as possible. How? Some options: have an A/B system and download a new (delta-)image to the other partition. Or I just upload the changed files. To solve this we use OSTree which lets us have a versioned filesystem with extremely small bsdiff delta updates. It's very satisfying.

> we've not sorted out how to make an actually deployable artifact from (for one example) our workspace making use of pymoveit

Heh, this is the big question for ROS and meta-ros. How do you deploy a workspace? So far we've settled on building the workspace in Yocto and installing it straight into the ROS prefix (typically /opt/ros/ROS_DISTRO).

You can see an example of a recipe that compiles a ROS2 workspace here: https://gitlab.com/raccoon-os/raccoon-os/-/blob/master/meta-...

It's a bit complicated due to the fact that we're also using ROS2 Rust and this recipe should be converted into a .bbclass, but we haven't gotten that far yet.

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

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.

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.

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.

Here's another one: https://github.com/matt-attack/pubsub

And it even has recording/playback and visualization features in the author's other repos.

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.

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.

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.

I worked with ROS1 professionally for a few years. My big takeaway was that the middleware got a lot more attention than it deserved. There are tons of hard research problems to work on in robotics: reliable navigation, object recognition, planning, manipulation, etc. I felt like a better contribution to open source robotics would be some great class libraries for those things. But let your users wire them up however they want, rather than requiring them to fit into a predefined architecture.

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.

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.

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

Exactly, the first question when somebody suggests using ROS should be: Do you even need it in the first place? Your code may be much simpler if you forgo the networking communicating nodes model completely.

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.

First excited when I saw the name, NComm was a major player among terminal programs for the Amiga, before Term came and destroyed any competition.

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

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.

Having built a few systems with ROS, I've been contemplating the use of distributed publisher-subscriber architectures in robotics. Why is this pattern so prevalent in this domain, but not so widely in others? To be sure, there are plainly many advantages, but there are also several disadvantages, and it doesn't seem to have the conceptual purity of other patterns.

I had a quick glance at it but for someone unfamiliar with Ros it's really not obvious how much this does. I'm building CV pipelines and I'm always looking for friendlier alternatives to gstreamer-rs for the bulk of the plumbing... Is it coming with synchronisation primitives in-between inputs for each node?

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.

Reply on news.ycombinator.com