[HN Gopher] Ncomm - A node-based robotics framework written in Rust
___________________________________________________________________
Ncomm - A node-based robotics framework written in Rust
Author : Tycho87
Score : 53 points
Date : 2024-09-13 13:14 UTC (4 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| chfritz wrote:
| 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 wrote:
| This.
| italicmew wrote:
| 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 wrote:
| There is also Dora-RS which looks quite interesting - but I
| agree, improving ROS would be even better!
|
| https://dora-rs.ai/
| ramon156 wrote:
| I'd put my money's worth on dora-rs instead, seems like a
| much more promising tool
| Q6T46nT668w6i3m wrote:
| 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 wrote:
| 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!
| jdiez17 wrote:
| 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 wrote:
| > 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
| jdiez17 wrote:
| 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.
| gbin wrote:
| 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 :)
| moffkalast wrote:
| 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 wrote:
| 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 wrote:
| 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.
| n8w3rt wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| TheChaplain wrote:
| 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 wrote:
| Interesting tidbit for you my Amiga friend, guess from where
| the name Copper comes from in "Copper Robotics" (see the other
| thread for context) :)
| picklebarrel wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| rgovostes wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-17 23:01 UTC)