But basically, if you’re using QL4- packages, you’re just on your own (with a high probability)
I think that this is a great vision, but unfortunately some very foundational packages, such as launchdo not seem to have a quality declaration?
As a pretty heavy python user, I have noticed that the quality of the Python packages is lagging, and could be improved. Unfortunately my attempts to contribute to improve the quality of the launch package have gone unanswered so far. Even though I pinged most people who seem to regularly contribute to launch, no one has replied on my draft PR to give me any advice.
So I will echo the sentiment of some of the above posters: it seems like maintainers of core packages do not actually have enough time to guide community contributions and this means that unfortunately the core of ROS2 is not at the quality level that it could be.
I am experienced in developing industrial ROS-powered robots following a modern software engineering process (and I think ROS is great).
Returning back to academia, I observe many students struggling getting started with ROS (reminding me of myself when I got started). These struggles include:
trying to install their first ROS packages,
connecting computers in a network,
starting nodes/launch files,
compiling their first community contributed package.
Frequently, a ROS solution is ditched in favor of a do-it-yourself implementation. If they can create their own package, the code quality is low (sorry) and even if the package works as intended, it is by no means portable/maintainable once students move on.
To lower the entry burden, I am currently experimenting with ROSbloX. ROSbloX are ROS building blocks, i.e. physical devices which run one single containerized ROS package, e.g. a LiDAR driver or a SLAM algorithm. The idea is that ROSbloX can be used to compose robots with complex functionalities even by less experienced developers.
I do love the push to develop a maintainable, industrial strength ros, so I’m very appreciative. This is just a little grain of salt.
I’ve the past six months needed to work with a ROS2 codebase developed by a vendor, so I’ve personally been making the shift from ROS1 to ROS2. These are the biggest things that stand out to me:
TL;DR: mostly docs, and a lot of dropped little things in the most commonly touched parts of ros
Documentation is non-existant. Like, scarily so. Like, I’m referencing design docs from 5-7 years ago, or ros1 docs hoping for things not to change ago, or finally the woefully incomplete main ROS2 docs site.
Off the cuff, of the desired needs and capabilities from ros that handle 90% of my problems, it’s usually only the same 30% or so of everything that ros can do (now that other 10%…). The main docs site is full of everything, the full 100% of what ros can do, yet is insufficient to meet this common 90%, and very distracting.
Alternatively, the source code for ros2 is very readable; I usually just have a few github links to the source code open (rclcpp, rclpy, or tooling, depending). So this has been a pleasant experience for fixing my problems.
On that note, I wouldn’t teach a robotics class with ros2. The ros1 docs were so mature (*cough* in comparison) that it would be much easier for students who struggle with googling or reading source code to work with them, and the well practiced good styles we’ve developed over the years. (when even chatgpt and google-copilot can’t help you write good code)
Style: code styles that promote node / launch file interface composition readability. Kinda rare in ros1, but we did have the wiki pages with the packages’ nodes’ sub/pub/topics/params listed; intra/inter-file docs were less-so. Both non-existent ros2.
Tooling that feels like a regression.
Lack of support for xml launch files. The python ones are incredibly verbose for the 90% of real need, and are not as easy to quickly read+parse. Launch file errors are terrifying and useless. Eval/Var don’t work easily, needing lots of string escapes. Using Arg/Let for simplifying repeated strings, with variable substitution for commands/nodes doesn’t work easily / correctly, I don’t bother trying anymore.
We finally have types for python, decent workflow integration (mypy/pylance-vscode), and beartype is the most glorious python pkg ever created that disregards everything else that follows in this subpoint, but typing support for messages (aka all our datastructures) and rclpy (aka which the rest of our code is entangled with) have second class implementation. (Thanks to the few volunteers who keep pushing! :confetti: )
With respect to python, finally on python3 for a long time, yet all ros pkgs / installations exclusively (or else painfully?) only go in the system pkgs. It’s very difficult to leverage pyenv well with ros2, and pick your favorite incarnation of virtualenvs are still excluded to non-ros projects.
Gazebo / Ignition isn’t a regression per-se, but year over year I don’t think it’s gotten better, enough that we end up writing some simulator-esque thing for some subset of our product that doesn’t necessarily need a full physics simulator…
I felt comfortable using Indigo for years (back when we were too scared to jump versions), and kinetic was the best distro to work out of (in terms of ported packages and ros1 maturity). Now with Noetic we have the updated ubuntu and python 3, great. I’d still use any of them for production or teaching. But I find that every release of ros2 seems to have a personally-critically-missing feature or such, that I keep backporting (company almost will transition to ubuntu 22…). I find that the only and best way to have everything that I would want is to build / develop out of rolling. But even if I did, I find more important features lingering in long issue or PR tickets, so I’m always waiting for more.
Cheers to the clearpath etc guys who started the Nix package installation / building thing mentioned last roscon! I look forward to having the bleeding edge at my fingertips, as soon as I figure out nix.