Robotics StackExchange | Archived questions

How to detect new obstacles

Hello,

I have a robot that can create a map. I save this map and the robot can navigate with it. Now I want to receive a message from the robot if it detects a new obstacle in its path (which was not there at the mapping stage) due to which the robot creates a different path.

I have an idea to somehow compare local and global costmaps to understand that there are new obstacles, but I do not know how to compare them exactly. Or maybe I can get this information from the path planner? I am using teb_local_planner and global planner.

Asked by Ivan4815162342 on 2020-10-30 06:49:46 UTC

Comments

I am using teb_local_planner and global_planner as well and one scenario I have been working on is replanning of the global plan when obstacles in the local costmap block the global path, see here https://youtu.be/o6uR-MZ-jMY.

What is your goal with finding the new obstacles?

You could take the portion of the global costmap at the topic /move_base/global_costmap/costmap of type nav_msgs/OccupancyGrid surrounding the robot and compare it to the same size of the local costmap at /move_base/local_costmap/costmap also of type nav_msgs/OccupancyGrid.

You could also look for updates in the global of local path and find obstacles near those paths.

Asked by tropic on 2020-11-14 07:01:50 UTC

Answers

This is generally in my experience the place to use the local costmap.

The global costmap is used by the global planner to generate a path from point a to point b that avoids the known obstacles in the static map that you have probably previously generated. Generally the global map is not updated during run time (unless you are using SLAM) and therefore cannot help you account for new obstacles.

The local planner, the thing that usually generates the actually velocity commands sent to the base controller, uses the local costmap. The local costmap characterizes the environment immediately around the robot (10m*10m) and is updated continuously during run time by a laserscan or other depth sensor (realsense-kinect-radar etc). Because it is continuously updated during run time, it will incorporate new obstacles, and the local planner will generate commands that stay away from obstacles in the local costmap (read: not the global costmap).

So the local planner has the job of staying close to the global plan it was given, avoiding obstacles that it sees in the local costmap, and navigating to its own "carrot style" goal. The proper balance of these things will provide a functional behavior.

You should look look at the config file here and in particular the costmap_local.yaml which uses the costmap_2d::ObstacleLayer with the laserscan as its input.

I am not exactly sure if these things generalize to the TEB planner exactly, but this is my experience with the other ROS nav stack planners.

Asked by JackB on 2020-10-30 11:34:21 UTC

Comments

Thank you for your response, I know that robot can detect new obstacles on local map, but I am interesting how can I know about it

Asked by Ivan4815162342 on 2020-10-30 13:07:10 UTC

Ah I should I have read your questions more closely. I do not think there is an out of the box solution to your problem. But certainly comparing your local costmap to the global costmap seems like an interesting place to start.

Asked by JackB on 2020-10-30 13:20:29 UTC

Ok I will try this

Asked by Ivan4815162342 on 2020-10-30 13:38:44 UTC

Going with your strategy, you could perhaps get that information from the obstacle layer of say, the local costmap. This link might help you to access a particular plugin like obstacle_layer. I haven't done so yet, but i believe obstacles would be reflected in this layer's data and would possibly give a more specific dataset to compare in the pre and post obstacle scenarios.

Alternatively, since you are already using TEB, you might be familiar with the costmap converter. You could use that (costmap converter package) to base your node and issue messages when any obstacle populate it.

Asked by harshal on 2020-11-02 05:45:58 UTC

Comments