Hello,
I’m a mechanical engineer/controls guy/self taught C++ programmer (please forgive (and correct) me if I use the wrong terminology). I’ve been using ROS professionally for a few years. I started with humble. It’s got it’s warts but for the most part I love it!
The most frequent complaint I hear from my “real” software developer co-workers is that “ROS is bloated”. I never really knew what they were talking about until it came time to actually package and “ship” our code. Here are my thoughts. They may come across as negging but really my goal here is to just point out a few things that don’t make sense to me and offer some ideas on how that might be fixed.
It seems that bloom and therefore ROS is intentionally designed to only ship “-dev” packages (but not label them as such).
rosdep can of course point to both runtime and dev packages but there is no relationship between them. There’s no way to say here’s the dev package I’d like to use…unless I’m deploying in which case use the non-dev variant.
ament is another offender that (as far as I can tell) makes calls to cmake install but does not make an effort to specify that something maybe specifically for a -dev build while something else maybe needed in runtime build.
package.xml seems to be the only piece that may have actually gotten it right in that it allows you to specify in detail exactly what should get installed and when…but there’s no real motivation to use the features because none of the tooling does either.
Suggested improvements:
- package.xml is fine as far as I can tell
- whenever ament makes an ‘install’ call it should be doing something like this where each item is given an ‘component’ tag indicating the purpose of the item (runtime or development)
- rosdep needs to be extended to be able to track both -dev and non-dev packages associated with a single key
- bloom I really don’t know much about. Personally I am using cpack and some custom cmake macros to generate my runtime and development debs which has been working great for me. But I would love to not have had to write that in the first place…
If these changes were implemented I think the “real” developers would need to dig a little deeper to find something about ROS to hate on…
I get the feeling several of these tools are holdovers from ROS1? Maybe it’s time to upgrade or provide an alternative packaging mechanism for ROS2?
I’m sure I’m not the first one to point this out…but thanks for reading anyway. I’m clueless on how to actually make any of this happen (otherwise I’d be doing that instead of complaining about it here!)
-Stewart