6 ms·

Ncomm – A node-based robotics framework written in Rust

60 points by Tycho87 2y ago

TheChaplain 2y ago
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.
- gbin 2y ago
  Interesting tidbit for you my Amiga friend, guess from where the name Copper comes from in "Copper Robotics" (see the other thread for context) :)
- snvzz 2y ago
  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.
picklebarrel 2y ago
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.
- dgfitz 2y ago
  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.
- Datenstrom 2y ago
  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.
- moffkalast 2y ago
  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.
- rcxdude 2y ago
  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).
  - carlmr 2y ago
    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.
- dimatura 2y ago
  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.
chfritz 2y ago
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
rgovostes 2y ago
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.
sgu999 2y ago
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?
- n8w3rt 2y ago
  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.

60 points by Tycho87 2y ago

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.

gbin 2y ago
Interesting tidbit for you my Amiga friend, guess from where the name Copper comes from in "Copper Robotics" (see the other thread for context) :)
snvzz 2y ago
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.

picklebarrel 2y ago

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.

dgfitz 2y ago
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.
Datenstrom 2y ago
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.
moffkalast 2y ago
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.
rcxdude 2y ago
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).
- carlmr 2y ago
  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.
dimatura 2y ago
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.

chfritz 2y ago

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

rgovostes 2y ago

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.

sgu999 2y ago

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?

n8w3rt 2y ago
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.