A robot is several programs running at once: one reads a camera, one plans a path, one drives the motors. ROS, the Robot Operating System, is not an operating system. It is middleware: a standard way for those programs to find each other and exchange data.
The four ideas that matter
Nodes are small programs, each doing one job. Topics are named channels: a camera node publishes images to /camera/image, and any node that wants them subscribes. Services are request-and-reply calls, such as asking a gripper to close. Actions are long jobs with feedback, such as driving to a point.
Why bother?
Without a standard, every sensor needs custom glue to reach every consumer. With ROS, you can swap a camera or test a planner without rewriting everything else. You also get tools: logging data with rosbag, visualising with RViz, and a transform system that keeps track of where every part of the robot is relative to every other.
When you do not need it
A line-following rover on a microcontroller does not need ROS. ROS earns its place when you have several sensors, several processes and a need to debug a system as a whole, typically on a single-board computer or a PC.
A good first project
Make two nodes: one publishes a number every second, the other prints it. Then add a third that doubles it. When you can draw the graph of nodes and topics on paper before you write the code, you understand ROS.