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.
Disclaimer: Everything to follow circa-2010. Modern ROS* may be substantially different.
First, and most importantly, "Why ROS?" To which one might reply "To run robots," but that's not really why.
Historically, ROS' purpose is so that researchers can avoid rewriting boilerplate linking / low-level code, and reuse high-level components developed elsewhere.
To that end, ROS provides two main functional components: a standardized message bus, and a somewhat-structured framework into which one can plug arbitrary modules. So yes, closer to an API/spec than an OS.
So the easiest way to think about ROS (the base framework) is as a no-batteries-, no-motor-, no-X-included kit. Bring your own everything. And for values of everything, where there is likely some component out there that does X... but that component isn't ROS.
So you (as it sounds like) essentially end up with the JavaScript ecosystem problem, except moreso. Do I use X or Y for this purpose? Does X integrate cleanly with A? Does Y?
When you look at ROS as something useful to a PhD student pursuing their robotics dissertation on SLAM, but who doesn't want to write all the other bits, it makes a bit more sense.
If you are an absolute beginner here are some tips:
The core of ros is a message bus. Its aim is to provide a messaging layer, not unlike what one would get with mqtt. However, ros's message bus has been designed to be distributed and quite frankly has better performance than mqtt on an edge device. It also has a good set of tools that allows you to visualize errors.
Each ros program is called a node. Think of it like microservices. Why do we do this? Well first of all it provides modularity so we can swap out components. It also provides a certain amount of resiliency to your robot. So suppose one node on your robot dies, the whole thing will not come crashing down.
In addition to the ros messaging bus, there are tools like rosbag, which provides users with a super simple way to log sensor data and share it across runs. There are also tools like rviz which help you visuallize the robot's data. These tools are very useful when you are dealing with 3D data coming from LiDARs or depth cameras, however it probably is not needed when your robot is a simple line follower.
Once your familiar with these you should look at the TF library which deals with transforms. Transforms are central to robotics however it does take time to get a good grasp on them. At this point I recommend you take some MOOC to help fill the gap in knowledge.
MoveIT! is designed for robots with multiple joints like robot arms.
For wheeled robots and obstacle avoidance you probably want to look at move_base and nav2 packages. Movebase is the old package for obstacle avoidance on ground robots. It is a bit of a pain to work with. I strongly recommend you use Nav2 instead which is far superior and better documented and the successor to move_base.
tl; dr: Robotics is hard. There is no royal road to it.
Especially with the release of ROS2 (which, frustratingly, seems to be rarely stand-alone, in that the learning process often references or links to ROS(1) code through things like rosbridge), it's just been a frustrating experience. If someone were to release a paid textbook walk-through that actually explains it in a systematic, stand-alone, way with linked repositories, I'd buy it tomorrow.
Which, I suppose, is sort of exactly where this kit is aimed!
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.
That said, as said elsewhere, you should ask why you are trying to learn ROS. For research and academia, it’s great as you get a solid collection of tools/tooling that mostly works out of the box.
However, when looking at creating a product from it... think through the benefits. Much like any framework, even if there is no “cost”, there will always be a real cost in dealing with its complexity. So think through your use case, and design to that.
Honestly, I don't even get what ROS is about? Like it seems it is an "amalgamation" of tools and scripts to create a general API with some ideas of robotics application in mind. Also the naming of its stack seems weird to me: tf2, MoveIt!, the over-loading of terms like joint controller, robot controller, etc...
If anyone can point me to a free, coherent and hands-on study plan or guide with exercises that actually build and run fine that would be awesome.