Theorycrafting: "Virtual" walls for husky navigation

asked 2015-09-23 01:37:19 -0600

mattiasbäx
1 ●2 ●3 ●3

updated 2015-09-23 04:23:35 -0600

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?

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2015-09-24 08:37:49 -0600

daenny
376 ●4 ●4 ●6

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

edit flag offensive delete link

Comments

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

mattiasbäx ( 2015-09-24 09:37:10 -0600 )edit

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?

mattiasbäx ( 2015-09-24 09:38:49 -0600 )edit

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.

daenny ( 2015-09-28 04:09:26 -0600 )edit

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.

mattiasbäx ( 2015-09-29 03:55:08 -0600 )edit

add a comment

answered 2015-09-23 06:28:26 -0600

Stefan Kohlbrecher

24361 ●173 ●299 ●444 https://www.energy-rob...

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:

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

edit flag offensive delete link

Comments

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

mattiasbäx ( 2015-09-23 07:13:47 -0600 )edit

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.

Stefan Kohlbrecher ( 2015-09-23 08:00:07 -0600 )edit

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?

daenny ( 2015-09-23 08:22:39 -0600 )edit

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?

mattiasbäx ( 2015-09-23 09:27:50 -0600 )edit

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.

daenny ( 2015-09-23 10:01:24 -0600 )edit

I just remembered, I answered a similar questions here: http://answers.ros.org/question/21115... But this is just a bit more elaboration on the already described solution

daenny ( 2015-09-23 10:10:12 -0600 )edit

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?

mattiasbäx ( 2015-09-24 01:56:20 -0600 )edit

add a comment

Theorycrafting: "Virtual" walls for husky navigation

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Theorycrafting: "Virtual" walls for husky navigation edit

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Theorycrafting: "Virtual" walls for husky navigation