$100 robot kit running ROS2 and Navigation2

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.

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!

> Honestly, I don't even get what ROS is about?

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.

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.

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.

So, if you really want to learn ROS, I recommend the classes at the Construct (no affiliation): https://www.theconstructsim.com/robotigniteacademy_learnros/... While not “free”, they have been the best I found to date.

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.

(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.

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.

http://nu-msr.github.io/embedded-course-site/index.html

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).

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.

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.

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.

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.

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.

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.

[1] https://www.ros.org/about-ros/ [2] https://design.ros2.org/articles/why_ros2.html

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