ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Known map with undectable obstacles (navigation stack)

asked 2017-04-05 17:06:32 -0500

Oddity gravatar image

Hi there,

I'm struggling to find how to use existing ROS navigation packages with my robot.

Here's the setup: I have a known map and an RPLidar on my robot, but this lidar is only able to detect some beacons on the edge of the map and the adverse robot.

My problem is that on this known map, there are a lot of obstacles that are close to the ground, which the lidar won't detect, and I'm not sure of how to combine the known map and the map of what that the lidar can actually detect.

So I'm looking for people with knowledge of the navigation stack.

Navigation stack: If I understood well, it doesn't do "internal" localisation, and only uses the LaserScan to detect some obstacles (correct me if I'm wrong). So if I use a map_server with my known map (with all the obstacles), the navigation should be planned according to the obstacles in this map, while avoiding any "additionnal" obstacles (the adverse robot) detected by the Lidar. So what I think I should do is to use the lidar's readings both in the navigation stack (to avoid the "additional" obstacles, so the adverse robot) and in the odometry source (to localise the robot precisely, with the occupancy grid I created), which is not in the navigation stack (I was thinking about using amcl for that).

Is this a correct understanding of how the navigation package works ?

And if this is right, would it be possible to somehow tell the package that the adverse robot that it will detect has a certain size ? Because from what I saw, I can use a parameter "inflation_radius" but I wouldn't like it to affect how the robot will act wrt the "known" obstacles.

One last question, I couldn't quite figure out how to generate my known map (the one with all the obstacles). Should I use the gmapping tool as for the occupancy grid I created for the beacons, but with my lidar placed just above the ground ?

edit retag flag offensive close merge delete


You have a few questions here :D I suggest you create different questions on different topics. Regarding the "known obstacle", may I ask what global planner you are using? Because some global planner alrd considered the "known map" during planning, so the robot will be cleared from these obstacles

DavidN gravatar image DavidN  ( 2017-04-05 21:23:40 -0500 )edit

Well that's proof that I didn't quite understand the navigation stack: I tought it embeds a global planner ! On this page it seemed like it:

Oddity gravatar image Oddity  ( 2017-04-06 15:14:07 -0500 )edit

Ok, that means you use the default global planner. If so, it should be able to plan the robot to avoid "marked objects" on the static map. On RVIZ, can you enable visualization for "/move_base/global_costmap/costmap"? can you also post your launch file for navigation?

DavidN gravatar image DavidN  ( 2017-04-06 20:48:05 -0500 )edit

I'm not quite there yet, I'm just trying to understand how the navigation stack works to see if I can use it or if I should re-write everything by myself (I'd rather not). So by the "static map", you talk about the map_server ?

Oddity gravatar image Oddity  ( 2017-04-07 16:35:12 -0500 )edit

Yes, "static_map" means the map sent from map_server.

DavidN gravatar image DavidN  ( 2017-04-09 21:57:50 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2017-04-10 02:26:35 -0500

Procópio gravatar image

updated 2017-05-16 02:02:19 -0500

As pointed by @DavidN, you have lots of questions here that should be better addressed individually. The first thing that pops out when you say: " I have a known map and an RPLidar on my robot, but this lidar is only able to detect some beacons on the edge of the map and the adverse robot." is that you are using a map that was not gererated by your robot.

Is this right?

If that is the case, you will have a very hard time localizing in such map, because AMCL will try to match your laser readings with the map, and in your case, there will be no match. To start things from the beginning, follow the gmapping instructions, and make sure you are able to create a nice map. Eventually you will have to move the Lidar up or down so it can detect the relevant features in your environment.

Basically you will do a:

rosrun gmapping slam_gmapping scan:=base_scan

and then

rosrun map_server map_saver [-f mapname]

to save the generated map.

More info: gmapping, map_server

EDIT: yes, you can use two map servers, but make sure the one used for localization is generated by the robot, and not by a simulation.

edit flag offensive delete link more


Thanks for your answer! :) So actually what is going on is that on the playground on which the robot will evolve, there are some obstacles, but their height is around 3 cm. These obstacles are undetectable with the lidar, but must be accounted for in the planning.

Oddity gravatar image Oddity  ( 2017-04-10 09:23:59 -0500 )edit

Do you think I could use 2 map_servers ? One for the localisation with amcl (on which I only put the detectable beacons) and one for the planning (with all the obstacles).

Oddity gravatar image Oddity  ( 2017-04-10 09:24:47 -0500 )edit

And no, the map is not generated by the robot, it is a map that I created with gazebo in which I added the playground and a robot with a laser scanner.

Oddity gravatar image Oddity  ( 2017-04-10 09:26:05 -0500 )edit

yes, you can use two map servers, but make sure the one used for localization is generated by the robot, and not by a simulation.

Procópio gravatar image Procópio  ( 2017-05-16 02:02:33 -0500 )edit

Question Tools

1 follower


Asked: 2017-04-05 17:06:32 -0500

Seen: 896 times

Last updated: May 16 '17