[metadojo]

Bruh, take a step back for a second. ROS is a messaging system. Its like Microservices for Robotic components. If students are having trouble with ROS you might take a different angle on the purpose. When you teach ROS you are learning middleware patterns of integration first. Secondly you have to teach fundamental geometric concepts like TF. So thats why your students are having problems you are giving them too broad or too narrow or some convoluted context to reason about what they are doing. Try flipping the script.

[j-pb]

If only ROS were that. ROS wasn't a particularly good Middleware, and ROS2 isn't a middleware at all (DDS is a middleware, ROS is a framework using DDS).

The issue with ROS isn't the general idea of communicating nodes over a blackboard and the accompanying standard libraries, but the huge pile of low quality tools, sparse documentation, ad-hoc architecture, bad code, and mediocre introspection tooling. A lot of that can be traced back to C++ and CMake, but ROS manages to take already complex tools and make them even more complex in an attempt to make them easy with automagic.

If ROS2 had just opted for ProtoBuffers/FlatBuffers/CaptnProto over MQTT/NATS and build TF et.al as a library over that, we could just point students to the excellent documentation of the Serialisation Format, of the Middleware and to the (with all that freed developer time) much better documentation of the Robotics libraries, and call it a day.

Instead they spend months with the idiosyncrasies of the build system, only to continue struggling with the documentation, and the sub-par tooling when something goes wrong. Cough only two seconds of time travel in ROSBags cough