Can someone provide an ELI5 or like a few sentences of a "pitch" style overview?
Very popular in research, so in practice little of it really works together, much is abandoned and most stuff barely compiles. Lately there have been "smart" people thinking they can just install ROS and presto robot AI startup. These people are in for a harsh lesson.
Oh, but they can. The "presto AI" part is easy. Making a working product after ROS collapses under its own weight is the tough bit.
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".
ROS2 is version 2 of the original ROS framework.
As a results of the ROS framework, a number of modules (packages in ROS-talk) for complex robotics algorithms, functionality has been implemented by companies / the community and shared among each other.
For instance, Hadabot reuses the Navigation package (along with many others) that has been pre-impremented which allows me to employ many robotics functionalities without having to re-invent the wheel.
Libraries exist at different levels of abstraction, but it is for the most part not exactly plug-and-play.
It's super useful if you are for example building robots in an academic lab, say, or re purposing existing hardware & software. The further you get from that environment, the less obvious the fit will be. But if you are playing around with robotics, ROS can help you avoid reinventing a whole bunch of wheels just to get started.
It's like Rails, if instead of targeting the web your deployment platform were an unmanned autonomous submarine vehicle.
And you needed to support a donated Russian sonar, some second-hand one-off logic boards, some sensors you soldered together in your lab, and implement a navigation algorithm you only have in research paper form.
Plumbing:
ROS is centered around a publish/subscribe messaging framework, with a central broker that ROS processes (called nodes) register with to advertise their publications and request subscriptions. Message definitions that are passed on the pub/sub "topics" are specified in language agnostic Interface Definition Language (IDL) files. There's an RPC service layer built on top of the messaging infrastructure, and the central broker also hosts a 'parameter server' database that nodes can use to query or update named values. ROS client libraries that provide APIs for topics/services/parameters are provided for several languages, primarily C++ and Python. A set of commonly used message definitions and conventions, which form de-facto standard interfaces, are used to establish interoperability and substitutability between ROS nodes.
Tools:
ROS provides build tools for individual software packages based on CMake and custom metadata embedded in an xml file. Packages can be grouped into workspaces, built with ROS tools, and workspaces can be layered on top of one another. Other ROS tools exist for process management (the launch system), introspection of running ROS processes, interaction with topics/services, and visualization of message data published with well-known message types. This list is by no means comprehensive
Capabilities:
Building on the concepts of publication/subscription with shared interface descriptions, and the package abstraction, various packages are publicly available that use ROS interfaces to accomplish various functions. These could include reading data from a sensor and converting the data to a ROS message, implementing robotic navigation algorithms, providing a visualization or UI, or controlling the behavior of a simulation. It's possible to build on and modify a lot of existing capabilities to build a system, which arguably speeds up the
Ecosystem:
ROS is widely used across industry and academia, and there's lots of people familiar with its workings. These people work together to advance the state of the art of the ROS framework and the capabilities implemented with it, the standards/conventions for interoperating with various components, and
ROS 2 is an evolution of ROS. It keeps a lot of the same concepts, but replaces the bespoke pub/sub messaging protocol with an abstraction to plug in lower-level messaging libraries (DDS is used by default). The reasons and motivations for starting over with ROS 2 are outlined here[2], but may require some familiarity with ROS 1 to get all of the nuance.
[1] https://www.ros.org/about-ros/ [2] https://design.ros2.org/articles/why_ros2.html