4 ms·

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 m

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.

jackp510 6y ago
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
ethbr0 6y ago
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.
qchris 6y ago
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!
DoctorDabadedoo 6y ago
> 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.
mikepurvis 6y ago
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.
deleted 6y ago
[deleted]
contingencies 6y ago
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.
aerophilic 6y ago
So, if you really want to learn ROS, I recommend the classes at the Construct (no affiliation): https://www.theconstructsim.com/robotigniteacademy_learnros/ros-courses-library/ 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.
accurrent 6y ago
(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.
spieswl 6y ago
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 http://nu-msr.github.io/embedded-course-site/index.html

jackp510 6y ago

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

ethbr0 6y ago

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.

qchris 6y ago

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!

DoctorDabadedoo 6y ago

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

mikepurvis 6y ago

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.

deleted 6y ago

[deleted]

contingencies 6y ago

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.

aerophilic 6y ago

So, if you really want to learn ROS, I recommend the classes at the Construct (no affiliation): https://www.theconstructsim.com/robotigniteacademy_learnros/ros-courses-library/ 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.

accurrent 6y ago

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

spieswl 6y ago

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 http://nu-msr.github.io/embedded-course-site/index.html