A Complete Guide for Navigating a ROS Robot Base from Zero to Industrial-Ready Phase with the Best Practices

ROS-Industrial
1

Hallo,

This Topic is Very Wide, but;

Although there are lots of tutorials, open source packages about how to make a navigating robot for beginners, according to my research for days, there are no guidelines or a complete tutorial or tutorial list about creating a well-developed ROS based navigating robot for the people who know about ROS. All the existing good packages and tutorials are either very old, or just very specific approach for what that robot is created for (like old open source commercial robots) or solving a specific problem with best practices (ros industrial tutorials)

Navigation is the heart of the ROS, more specifically the main part of the most ROS based robots. So it could be very nice to have a general complete guide on Creating a Navigating Robot Base from Zero to Industrial-ready Phase with Best Practices.

There is the Turtlebot3, supporting all the new features, ros1, ros2, including general example applications and tutorials, but frankly, it has the Raspberry Pie as a main computer: I doubt how it could possibly have the best approaches about solving real world problems. I understand that this problem doesn’t have a predefined solution list, and there isn’t a single, general way, so I’ll keep the parts as simple and as general as possible. My aim is to create a road-map-like list of things for writing a full guideline on this topic.

I have some bad answers to some of these, but I’m not an expert, so I expect experienced and helpful fellows to help with their answers to the numbered parts. Also I’d like to update this topic according to new area ideas to include since I can’t know all the real world problems.

  1. Building the Hardware and Mechanics
    a. Choosing the mechanics: wheel types, motor types, motor drive, driving style(omni-directional, differential drive, ackerman steering etc.),
    b. Designing the mechanics: footprint optimization, structural optimization, design ideas to include safety considerations, material decisions etc.
    c. Choosing the sensors: Laser scanner, IMU, camera-type sensors, must-have sensors for a good navigation capability etc.
    d. Choosing the Computers and Communication Methods: microcontroller, high-level computer requirements, new communication methods and industry standards between hardware components and outside world devices

  2. Building the Software
    a. The low level: low level controller code specifications, must-be-solved-in-low-level problems, existing solutions that are coming from the hardware manufacturers,
    b. The high level computer with ROS: This part is the area of ROS and already well documented. In this guideline, the aim of this part could explain different solutions to different software/pc related real world problems and solutions; hardware specs/industrial standarts/ROS versions and distributions/OS decisions according to the continuous development of ROS.
    c. Management approaches for multiple robot environments
    d. Must-be-implemented-high-level-controllers: writing high level ROS drivers, sample well written node tutorials for mostly used hardware types, helpful links etc.
    e. The Simulation: choosing the simulator software, creating realistic simulation environment, abstraction of the simulation software to run on sophisticated super computers / cloud servers
    f. Containers: Although this is an unrelated topic, with the help of the containers like docker, spreading and managing the software can be automatized as you most probably know.

  3. Safety and Tests
    a. Safety standards for low and high level: could just explain (for example)EU standarts, Industry 4.0 standarts, ROS Navigation related safety guides, must-be-in-the-low, must-be-in-the-high level safety standarts
    b. Tests: Software testing for robotics, ready to use mocking softwares and development of mocking softwares

Why in the world, the community could possibly need this?

  • Including the hardware and mechanics?: Even though, right now, ROS is an awesome middleware stack, I’ve seen lots of badly designed robots, both unsuccessful industrial ones and research oriented ones, which couldn’t benefit using these awesome libraries, tools, just because of the bad mechanical and hardware design.
  • There are already lots of tutorials / guides / information about this: Yes. There are, but not organized and combined, and not for navigating base only, and not with the Best Practices. Some of the parts of this guide could directly show a helpful list of links. But The target of the existing tutorials are mostly for beginners or intermediate ROS users who doesn’t have the experience. This guide could be a way to advance in ROS based robots. Because writing guides like this for all ROS related things isn’t looking possible to me right now. But I think with a one with fully best practices on the navigation, It can also lead improving the other topics. Learning and using ROS for years makes the enthusiasts know lots of things about these topics. Still, no one can easily know all of these well.
  • The truth about future of ROS2 based IoT Robots: Okay, even without this guide, IMHO, ROS will be the widest standard for the industry. Autonomous cars, drones, all types of vehicles will be using it in the future. My idea is, just like the time ROS created, a perfect, best practices oriented, industrial targeted, navigation related guide could really fasten this process. Let’s say, with the help of the experts, this guide is completed. And reached to lots of people, do you see any reason for ROS to not be the industry standard for all IoT devices?
7 Likes
2

Well because most of us that can do that use that knowledge to keep employed :wink:

But more seriously, it just takes alot of time. Its not that this information isn’t valuable, its that the type of people that know this stuff like to build stuff, not write things down by in large. The tutorials that exist are from a substantial investment in man-hours from OSRF (or Willow) that made the investment in creating the community and providing good starting points for the things they wrote as the centralized authority. The incentives to most ROS users and companies using ROS in the decentralized way it is today isn’t aligned with creating amazing beginner tutorial guides (to then compete with their core businesses) but contributing back with with new stuff that was needed for their applications and some general community interest.

Moreover this is by in large a research-oriented field. Things change rapidly and any “choosing best sensor” document would soon fall out of date in 3-5 years when new companies with new hardware come out. For example the R200 (a comparatively old and deprecated sensor now) was announced 5 years ago. Its now been built in products and since replaced with the D400s. Again, not to say that information isn’t valuable but now you’re adding bookkeeping over time to anyone’s daily agenda of things they’ve written to have to keep up to date. The same holds true of algorithms, choices of drive systems, safety standards, etc.

You learn these types of skills through doing them and the “lets do it” type people don’t generally like to sit around and write long extensive entry-level documentation about it. Not to say we potentially shouldn’t be doing that, but those are my thoughts about how things are right now from my view.

A solution would be to donate money to OSRF and tell them to use it for building documentation :wink: or write some documentation yourself! No one’s better at it than someone with passion.

1 Like
3

This project provides a guide for setting up a ROS Robot Base. We could extend this project?

Linorobot is a suite of Open Source ROS compatible robots that aims to provide students, developers, and researchers a low-cost platform in creating new exciting applications on top of ROS (Robot Operating System). Linorobot supports different robot bases you can build from the ground up.

Supports: 2WD, 4WD, Mecanum Drive, and Ackermann Steering.

Github: https://github.com/linorobot/linorobot

1 Like
4

Explains a lot actually. This approach looks very familiar to me… The one that is opposite of open source :upside_down_face:

Yes, you are right. For example, there are event cameras coming out. This is a very new sensor type and can be very good in multiple types of applications. But a guide to choose, and ways to search for a sensor type could also be useful.

That actually looks very logical. I think, companies that have closed source mentality -which also the money- wouldn’t do that kind of donation :upside_down_face: So yes, I (We) should do by myself(ourselves).

About the software part, that is actually the PR2 for references. Looks like I can start writing this guide after reading all those lines in PR2 (He died before seeing the end of the guide… :upside_down_face:)

That looks like another turtlebot to me :upside_down_face:

5

For me personally it’s not so much that it (ie: that knowledge) keeps me employed, but the fact that writing proper guides (or documentation in general) is non-trivial and takes quite a bit of time and skill.

I can only spend my time once, and unfortunately there is never enough.

Money can buy someone else’s time, true :slight_smile:

2 Likes
6

Yes, and I think even if you write a guide, you’ll still see questions on exact same stuff at answers website :slightly_smiling_face:

I understand that this guide thing needs a lot of time and also teaching/tutorial/documentation experience. My idea now is, maybe starting the initiative can take attention from people who are experienced in small parts of it. And they also can use the experience of the people who started doing other parts of it. Just with a little(maybe from multiple little donations) donation about hiring a documentation expert could make it possible.

7

Please don’t take any of my comments as discouragement. That was not my intention.

I just wanted to provide an additional datapoint and perhaps balance out the “we want to get paid for this knowledge”-comment by @smac.

8

@gavanderhoorn no misunderstanding at all, I’m just using yours and @smac’s ideas to improve my ideas since I’m not an expert. To me, this initiative is important because I saw people know parts of this stuff very well, but just some parts of it, but also cannot share the information because of: 1. Their responsibilities to their companies, 2. The thing that @smac was joking about :slight_smile:

My idea as a workaround to the problems 1 and 2 above, there’s no harm for experienced people to share some tactics, best practices and tutorials about just specific parts. I also know that this is a childish idea in the industry; but with the open source mind, this should be done for the humanity :upside_down_face: When this kind of problems will be less challenging, I think lots of more people will have the time to contribute to ROS, instead of dealing with the stuff that they shouldn’t.

9

I agree that the overall goal is unrealistic, but perhaps there could be some best practices / guidelines / suggestions / tips and tricks etc. for the things that are closer to the navigation stack itself or other ROS packages that are meant to work with and/or around it.

Here I am thinking about things the list below, where I think the answer for most of it is either: I’ll have to make it myself (which is not always a bad thing if it is something that is core to your robot / business / use-case etc.) or I’ll just have to experiment a lot and when I have the answer it might be worth money later on, so I don’t need to share it.

  • Are there any tools for the points below or should I create my own tailor made ones?
    • Waypoint / route creation, storage and retrieval
    • Tools to create zones on the map for different robot behavior (e.g. slow / fast zones) and how to detect when the robot is in each zone
  • Is the move_base statemachine useful at all or should I go directly for a replacement?
    • robot_navigation, move_base_flex, custom solution wrapped around move_base?
  • Given a generalized type of environment (people sparse industrial area, crowded public area etc.) what would be the pros and cons of:
    • Simple global planner like A*, Djikstra vs something like SBPL
      • If you use SBPL, you already have a kinematically feasible plan - should you still let your local planner stray far from this plan to do obstacle avoidance, or let SBPL do that and have the local planner be a simple path follower?
    • Local / Global costmap update rate in combination with global planner choice
    • Predictability / politeness in global planner (e.g. doing one-shot and only replanning after catching exceptions or local planner failure) vs replanning all the time (but getting unpredictable result from an observers point of view).
  • Experiences with which sensor sources to include in which costmap
    • When should you include your lidar and 3D cam in the global costmap?
    • obstacle layer vs voxel layer vs nonpersistent voxel layer vs STVL

Edit: I think some of these points will be addressed in ROS2, at least from what I have seen people discuss in various issues / wishlists / requests for features.

3 Likes
10

Yeah, sorry maybe I shouldn’t have said that, it was a joke. Future readers, please read with a healthy dose of satire. I think overall most people in our community are very open to sharing general knowledge, but getting a coffee and chatting is a different level of commitment and scrutiny of ideas than writing some “official” documentation/how-tos.

To @gavanderhoorn’s comment on spending time, I’d echo that. I would say that I think of that as another side of the same coin as the people “doing the thing” like to do-the-thing and when the thing is done, they want to do another-thing. I think its a pretty fundamental trait of successful people that “do the thing”, especially in robotics where there’s so much to do. As a result, there’s never enough time because there’s always another interesting thing-to-do. I don’t know that he, I, or anyone else couldn’t find the time to do it. We have a lack of time, but that’s because we fill our time with things to do (and also need to do things to keep a job, but if we work for places that let us open source, there’s clearly some commitment in place as a starting point to build off of ).

I’d argue minute-for-minute, a successful “doer” can make more impact in doing. These types of people have to document it to some level so other people can use it or understand it, but that’s not the same level of documentation that has to exist for A) entry level, B) a tutorial, C) the desire to keep it up to date.

I’m totally guilty of this. All my documentation talks about what “the thing” does and describing the dials you can play with, but I make no attempt to explain why you should need this, how you can set it up in excruciating detail, etc. I’m writing to people with similar sets of knowledges as myself who are looking for a solution to a specific problem, much lesser so to people learning about it. But I think that’s one of the truly valuable things about ROSCon - the “doers” talk about the-thing and in discussion (as I mentioned above) we’re all very willing to help and share our knowledge.

A reason to give money to the experts so that there’s a specific request to do so :wink: or people that are motivated :slight_smile: I’m not sure at the moment the proper incentives are in place for a systematic change in the way we build documentation, but I’d be excited to hear your thoughts on it. Just because that’s how things are, doesn’t mean we should accept that. I’m sure we can do better. However its hard when ROS has become so decentralized in the ecosystem development and very few in particular at that level has incentives to do what you’re suggesting.

To my recollection, I think OR has recently hired someone like that, but I can’t recall specifically where I thought I was told that and can’t find references to it at this moment. But clearly they’re focused on ROS and the related ecosystem, and your suggestions are more focused on how to build a mobile robot hardware and applications.

I fundamentally disagree that its unrealistic. I think its just not in line with how things are done in this community at this very junction in time. Clearly at other times this was a priority, and other communities have this. I wouldn’t try to make an argument that ROS is somehow tangibly different.

Thanks for the shout outs :wink:

1 Like
11

They do now have a document writer, reporting to Tully. I was told that they have started at the bottom, by re-working the introductory tutorials.

However I think that the point about the purpose of this document writer’s work is valid. The OSRF wants documentation on how to use ROS to be good. “How to build a mobile robot that works well” is probably secondary to that, if it’s within their scope at all.

(And to those who talk about not having the expertise to write good documentation, there is a reason “technical writer” is a job title.)

1 Like
12

(Although it could be nice to see OR’s effort) I completely agree that it isn’t OSRF’s, -or with the new name- OR’s problem. Area of this guide thing, is the industry and professionals. Could be possible by efforts of experienced people who do professional work. And if only few good people will try to do, it will require a huge time to get any result. My idea is starting it and expanding it by time. Even writing titles and putting TODOs under them is a good starting point to see what’s next / who can contribute / how much effort it can take to get a result. I’ll start it as a personal project when I have the time and the experience anyway. I don’t know what could change till that time. Maybe ROS1 will be completely deprecated.

Even though we are joking about it, many people don’t want to share their knowledge about some of these topics.

  • Some companies who open source their robots, don’t make the new ones open too. Because of security concerns, or because this is what their company gets the profit from.
  • Some people with the wide knowledge don’t have enough time.
  • Some people with a little experience like me don’t know the best practices, industrial needs, mechanics, real world problems etc. For example I still search for other robots from different brands and their common points when I design my new robot setup, to avoid reinventing the wheel (as most people do).
  • Topics are wide and there are many solutions to multiple problems.

I don’t know how to narrow the topic list down but I hope that I’m successful about sharing my idea. Experts could also narrow things down.

If there will be an algorithmic way for starting to develop a navigating base, it could be extremely helpful. Entry level;

  • Is it an outdoor robot to explore a planet? Design your mechanics by thinking about these problems + steering drive technique + hardware/control components
  • Are you going to make a robot for lifting heavy weights? Choose these Mechanical options + steering types + this kind of hardware.
  • Is it an indoor robot which will help people? Your problems are safety, navigating in a dynamic environment, carrying a robot arm etc.
  • How much do you want to develop on your own? Here are things you can out-source. Here’s ros_control, here’s default controllers for these problems etc.

First and the beginner part of this guide can be the things above, then comes the details, wrongly organized in my first post in this topic, the intermediate ones. One doesn’t need to follow all intermediate ones since the person is going to do their specific solution according to redirecting options listed in the beginner part.

The Advanced part could be about navigation and diagnosing. Maybe, to narrow things down, can only include gmapping, default planners, ros_control usage details etc. And can show the algorithmic way of starting, from creating urdf to adding launch/config files of the navigation stack. Because the need of using an open source robot code fork as a robot base when developing a new robot is painful (packages are either old or good ones are including lots of unnecessary parts).

And diagnosing your setup, here is a well known good example of diagnosing navigation/Troubleshooting - ROS Wiki which has this information in the bottom of the page;

Wiki: navigation/Troubleshooting (last edited 2011-04-13 00:28:06 by DanielStonier)

Why Navigation? (again, sorry)

Beyond having a guide for professional use to show people directions, also navigation is one of the things that are firstly being operational in new LTS ROS releases. And Navigation Stack includes most of the common packages, libs in ROS.

2 Likes