[jdiez17]

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]

> 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]

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.