It’s not necessarily untrue. For instance:
-
iRobot is developing an event-based executor, afaik not yet merged, but which is core ROS2 functionality. I would have expected the ROS2 executors to be fully mature and documented.
-
Consider ros2_control. I didn’t study it in detail, so I am certainly not saying it does not have its merits, but on first sight it seems that it implements parallel functionality to ROS2 core. Which feels sub-optimal. I would have expected ROS2 core to provide the necessary tools for real time, deterministic communication between nodes, so that a control loop would consist of standard nodes (trajectory generator node, kinematics node, controller node, hardware node, etc.) that communicate through standard topics, and not ros2_control-specific read() and write() calls.
So a priori it seems ros2_control might be a solution to what is actually a lack of ROS2 core functionality. -
There’s a ton of rclcpp code that is not documented anywhere. For instance the pendulum demo instantiates a “MessagePoolMemoryStrategy”. Ok, i can deduct from the example what is is, but what I’d rather want is higher level info on its use, info on other strategies that might exist, etc.
Obviously for a lot of people these things are irrelevant, and they are perfectly happy with ROS2 as it is, but overall I think indeed any move towards a more mature and stable ROS2 core is highly desirable.