I'm really struggling in learning ROS in a systematic way. The tutorials are all over the place and somehow unorganized IMO. When trying to replicate stuff on my machine, all kinds of weird errors pop up.
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.
I've been doing ROS professionally for ten years and have presented twice at ROSCon. I would argue that part of the difficulty with this is that ROS is many different things to different people. I'm a low level platform/OS/firmware guy, so I tend to care most about the build system, dependency management, the relationship with the host OS, the standardized sensor messages, and the approach to logging (rosbag).
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.
This is exactly what I'm trying to address with Hadabot. A systematic / opinionated way to learn ROS (specifically ROS 2), understand its significance, in a hands-on manner, with a real robot. The next milestone for Hadabot is a very simple introductory ROS robotics curriculum / syllabus that is not as intimidating as a MOOC, requires low mental load to get started and reach various milestones. Lots of hard work ahead to get this right! Don't hesitate to reach out w thoughts and opinions - jack AT hadabot DOT com - Jack
I can't offer any modern links, but some background and framing that might help a bit.
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.
(Disclaimer: I contribute to ROS in my day job) As someone who has been working on ROS for a living and spent the past 3 years in research labs ROS does seem very scary. The ROS website itself is in need of an overhaul with better tutorials. Part of the reason why a beginner coming in may also get lost is that there are many very advanced tools and libraries for concepts which are foreign to software engineers. Take the TF library for instance which you mention - its goal is to calculate transforms, but unless you are deep into robotics you may find it difficult to understand why it is used in so many places. The fact is ROS provides an extremely comprehensive set of APIs, but why those APIs are useful is not immdiately clear unless you actually build robots.
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.
I have this exact same problem. I'm not exactly sure why, but finding useful examples has been a serious pain point for me. It seems like there's a serious dearth of material between the "here's the absolute smallest thing you can do" and "now we're going to built the F-35, but with ROS!". Like, I want to subscribe to and manipulate the value in a topic. Fine. But how about two topics in the same program? All of a sudden my code won't compile and the tutorials aren't helpful.
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.
This is one of the best primers / courses in ROS around. Start at the top and just go straight down the list in the first section. Most of section 3 is unrelated to the ROS content and is general dev reference.
Robotics founder here. Never used ROS. I would avoid it unless there is a clear need. Once you are on expensive third party hardware plus ROS, you are guaranteed to have no USP.
The thing with ROS is… it's pretty good at what it sets out to do. It's a common framework that everything in the robotics universe can speak to, has some amazing tooling, and handles many tedious things that robotics experts shouldn't have to care about. It does broadly achieve this.
But from my perspective as a generalist software engineer who isn't a low-level robotics expert – as an ecosystem, it seems to have adopted every bad practice available and invented some more of its own. My experience working with it has been an exercise in trying to isolate it as much as possible so that the blast radius can be restricted. Many of the architectural design decisions are frankly baffling, although I appreciate that this is in part down to age, legacy, and the open nature of the platform.
ROS2 definitely feels like it rounds off some of the sharper edges and I'm very happy to see this project push forward in some useful areas!
Eeyup. I've seen a few companies with a prototype built on ROS and they universally struggle to get it from a basic demonstrator to a production system until they ditch ROS because it's just so poorly engineered. Everything you gain in the short term from having a nicely integrated system with a bunch of existing libraries gets more than offset by how buggy, difficult to debug, slow, and incomplete each part of it is, relative to basically any other alternative. Especially because it defaults to a distributed system which basically takes your existing problem and makes many new and exciting ones to go along with it (and neither ROS nor most of its users/developers are well equipped to solve distributed problems reliably).
This is my life right now: reckoning with optimizing a ROS1-based system that was itself hacked together in record time.
ROS seems almost like it wants to distribute state by default. And it has no primitives for sanely managing distributed state, health checks, etc. The lego brick approach to camera drivers is great, but trying to orchestrate all those bricks is a nightmare. Rosparam/master is woefully inadequte as a control plane.
I recommend anyone in this space look at tools like Consul.
I agree from my own painful experience, which makes the OP more impressive. I once tried to get the navigation stack running on a raspberry pi based robot to test out a gps driver, and was shocked that I had to include massive libraries for lidar and point clouds that I had no intention of using to get anything to build. In the end everything ran but the nav stack ate up so many resources that my robot wasn’t able to move reliably.
Re: the "what is ROS?" question asked by many on this thread:
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.
Another perspective on the question "what is ROS?", having worked with countless ROS nodes:
In a nutshell, ROS is a library that allows you to send and receive messages.
The two most used methods in the API are Subscriber.subscribe(message_topic, callback)
and Publisher.publish(message)
For example, a sensor driver will publish a message containing a camera image, then a node will receive a message, detect the people in it, and send another message with their positions. Another node will receive the positions message and calculate a desired action, and send that as a message. You can write your own node which captures any kind of message and publishes any other kind, making things very modular.
So ROS also contains a million tools to help you process the messages, for example the Time tools allow you to set timers and convert time stamps, the rosbag tools allow you to store the messages and replay them later, the tf tools allow you to transform geometrical objects between message reference frames, and so on...
Many of the tools do their job well, the main issue is documentation. In some cases, the best way to figure out what can/should be done is to look at existing code.
I'm trying to figure out what ROS2 is -- judging by the docs and tutorials it seems like a very low level and abstract piece of complex software but I'm struggling to understand its practicality.
Can someone provide an ELI5 or like a few sentences of a "pitch" style overview?
ROS itself is basically a glorified message bus, and the ecosystem around it allows you to quickly cobble together a robot from disparate parts (use one thing to publish frames from your specific camera model, feed it into some other module that does SLAM).
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.
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".
The short elevator pitch in my "unofficial" over-simplified own words - "ROS is framework to program complex robotics applications that encourages modularity and shareability of modules. ROS is to robotics development what Django/Rails is to web development."
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.
Basically ROS is a collection of libraries, mostly for and by researchers for interfacing with and controlling robots.
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.
ROS is a helper framework, for people who would otherwise be implementing low-level embedded interfaces to arbitrary hardware, so that they can share more of their work.
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.
ROS isn't really one thing. Per the "about"[1] it's really made up of several pieces:
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.
A naive question -- does that mean if I picked up one of those cheap 2-wheel robot kits from ebay (that includes wheels, board, risers, but no MCU) for ~ A$20 -- I could, in theory, turn it into a ROS-capable system by somehow adding in an ESP32-on-a-board?
(I've got about as much experience / understanding of ROS as most of the other people asking questions on this thread : )
Being in Australia, that 'under $100' is far from it - and the pathway to cheap discovery with some basic robotics is moderately opaque.
I think there’s a github repo that may or may not compile to make ESP32 talk ROS2 message protocols, and that would be the entirety of ROS2 that fits in an ESP32 anyway, so the answer is a yeah
For ESP32 there are better options, for example you can get RoverC base from M5Stack for 45 dollars. And, if you want to be closer to more realistic robots that run full stack software, there is JetBot from NVIDIA.
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.