0
$\begingroup$

Rosanswers logo

Hello ROS community!

I just got into ROS through a project I'm participating in at my University. My job is to navigate the husky given a set of breadcrumbs (waypoints) and a zone (like a "virtual corridor") where it's OK to maneuver in.

Whilst playing around with the husky gazebo simulation and investigating how the move_base local and global planner work, I thought of an idea. Would it be possible to add a "virtual corridor" to the global occupancy grid cost map, which would make the husky think it was trapped and not navigate outside of the corridor, but still navigating through the breadcrumbs and avoiding obstacles inside? My hopes is that the laser distance sensor could still see through this virtual wall in order to navigate itself in the world.

Or do you know of any more convenient way to do this?

Thanks in advance, wbr

EDIT: Basically what I'm asking is: Is it possible to add area restrictions on the path planner in order to keep the robot inside a certain region while going to goal?


Originally posted by mattiasbäx on ROS Answers with karma: 1 on 2015-09-23

Post score: 0

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

(This is too long for a comment, so I had to put it into a new answer)

To elaborate on solution 1:

This really depends on how you want to define/detect the "impassable" areas. So the idea is to create a node which subscribes to the current laser scan readings, and then modifies it to suit your needs, e.g. "shorten" the beams on the sides of the robot to create a virtual wall and republish it under a new topic.

You would feed only the original laser scan to AMCL, so your localization is would not be affected at all. In the costmap configuration file you would then subscribe only to the modified laser scan data. The problem you might run into is that the robot then of course constantly thinks that there is an obstacle so it cannot drive through there, even though it might be the only path.

Thus, the tricky part would be to decide, when to modify the laser readings and when to leave them untouched, i.e. you would need an algorithm or lookup table that can decide if the region is unsafe or free to pass.

So to sum up, solution 2 is the quick and dirty, but also easy solution. If you have the map anyway and do not want the robot to drive through certain parts, close them with dotted lines in the static map. Otherwise, you need some kind of decision algorithm that you use to create the virtual walls for the laser scanner modification.


Originally posted by daenny with karma: 376 on 2015-09-24

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by mattiasbäx on 2015-09-24:
I don't think that the only path being through the virtual walls and the robot not taking it is a problem, it's actually the behavior I'm looking for. The robot is supposed to be a system in a system, where the decision of "move through these waypoints in this area" is made on a higher lvl, and ...

Comment by mattiasbäx on 2015-09-24:
if it is not possible to do so, the robot should request another path and/or area. Is it possible though, to clear the previous virtual walls once a new set of waypoints and a new "corridor" is recieved?

Comment by daenny on 2015-09-28:
Yes, that would be possible. In your "Virtual wall node" you would just need a service call to "clear current corridor" or something similar. This you could call in your program or via the commandline.

Comment by mattiasbäx on 2015-09-29:
I have managed to create a node that publishes fake sensor data to an obstacle layer i created myself in the global of move_base. But I have no idea how to clear this layer to completely remove all the virtual walls.

$\endgroup$
0
$\begingroup$

Rosanswers logo

Yes, if you add obstacles to the costmap, the robot will avoid those (virtual or not, the robot doesn't know this distinction). There are multiple ways to achieve this goal:

  1. Generate fake sensor data like fake LIDAR scans and feed those to the obstacle layer
  2. Use a static map (that you could draw with an image editor of your choice) with the static map layer
  3. Implement your own costmap layer plugin which would allow you to perform arbitrary modifications to the costmap.

Originally posted by Stefan Kohlbrecher with karma: 24361 on 2015-09-23

This answer was NOT ACCEPTED on the original site

Post score: 2


Original comments

Comment by mattiasbäx on 2015-09-23:
Thank you Stefan, this is very useful! How will these different solutions affect the localization with for example amcl? Is it possible to add obstacles to the costmap that the robot avoid, but don't localize against (since they don't exist)?

Comment by Stefan Kohlbrecher on 2015-09-23:
Yes, you should be able to load a completely independent map from the one used in AMCL either into your one static map layer, or you should be able to add a second static map layer that contains your edited map. I haven't tried this, but it should work.

Comment by daenny on 2015-09-23:
If you add the virtual wall with 1 pixel every couple of centimeters, such that the base does not fit through anymore, AMCL is robust enough to deal with that. We use that approach in robocup quite a lot. Stefan's solution is of course neater and should work better, maybe use two map servers?

Comment by mattiasbäx on 2015-09-23:
Thank you both. Another question: I want to do this every time a new set of waypoints are given to the robot. Once a set of waypoint is published, the map is updated with the virtual corridor accordingly. Is this still possible? Because editing the static map is just before runtime, no?

Comment by daenny on 2015-09-23:
As you say yourself, the static map is only "gimped" once before start, not during runtime. If you want a dynamic solution you need to implement Stefan's solutions 1 or 3, while 1 would probably be easier to start.

Comment by daenny on 2015-09-23:
I just remembered, I answered a similar questions here: http://answers.ros.org/question/211153/mapping-with-turtlebot-and-the-stairways/#211158 But this is just a bit more elaboration on the already described solution

Comment by mattiasbäx on 2015-09-24:
Thank you Daenny for a more elaborate description on solution 2. Would it be possible for you to give a step by step breakdown of problem one, as you did in your last comment of the post you linked?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.