$100 robot kit running ROS2 and Navigation2

You can think ROS as a framework aimed at developing robotic applications (similar to what a REST framework would be for developing a web API). With it you get access to a lot of open source packages and tools out of the box (simulation via Gazebo, native process communication using pub/subs, autonomous navigation, joint transformation, etc.). There is a lot of dependence handling to make a robot work (component drivers, real time comm, planners, SLAM, the list goes on), if you are able to abstract something of the pipeline, it's worth it.

The whole thing might not seem very concise, but looking back, it was released aiming to facilitate research development, all these packages are maintained indepently. ROS2 is an attempt to tackle some architecture and scope issues brought up by the industry.

People in the perception space may care more about all the standard camera drivers, the publicly available SLAM datasets, and the zero copy nodelet system for passing image date through a pipeline.

People in controls care about the simulator integration, and the flexibility of move_base and its successors through a rich plugin system.

Then there are people doing stuff with manipulators, people doing realtime industrial stuff, people doing quadcopters, people doing academic research, people trying to build a product, people doing web frontends.

It's a lot of use-cases, so it's hard to recommend any one "getting started" path because it depends a lot what your interests are and your expected end goal. But generally speaking a safe option is to get a robot like Turtlebot up in the simulator, get it map-making and navigating autonomously, and then start mutating that— add more sensors to it, or write your own planner, or make an rviz plugin that does something interesting, etc. Maybe swap out gmapping for cartographer, or set it up to explore on its own.

These kinds of tasks will familiarize you with a lot of the tools that almost every ROS person uses, so that you'll have more of a sense of what the potential next steps are.

Like others have said, ROS includes a serialization protocol with codegen, a pub/sub and RPC messaging system with discovery, a build system, a configuration file system, logging system, and a repository of packages using them.

You might ask: why is it popular? One reason: it was started before the current ubiquitous solutions for those things were ubiquitous.

But I think the main reason is: in robotics, we use a lot of semantically complex data like high-dimensional sensor readings, probabilistic models of the world, representations of rotation and angular velocities, etc., and we need to do a lot of things with that data. For example, suppose we use a vision system to identify objects from a camera. We don't just display that information to a user -- it becomes the input to the high level planner, which is its own complex system.

If your object recognition library and your planning library are both pure C++ libraries, then they probably each define their own classes for the datatype "list of (bounding box, object name) pairs". You need to write glue code to use the libraries together.

However, if those libraries are both ROS packages, the idiomatic thing is to publish a package containing only message definitions (like vision_msgs [1]) and have both libraries produce / consume that. This makes it easier to put together complex systems that pass around highly structured data, because you don't have to constantly write glue code to get your libraries to work together.

TL;DR: ROS is popular because it's like a big collection of .proto or .thrift files for complex robotics datatypes that everyone agrees to use in their libraries.

[1] https://index.ros.org/p/vision_msgs

This is always majority of the work.

Often you get research lab products that are pretty cool (this is not robotic specific) and people think "Hey, we should spin this off/sell this/licence this, it would be a great product and 90% of the work is done".

Usually, at most 5-10% of the work has actually been done. 20% if it is an uncharacteristically completest lab. There are a significant number of "startups" dying on the vine because of this fundamental error.

Another problem with above of course, there is no such thing as "presto AI".