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

Revision history [back]

click to hide/show revision 1
initial version

Someone please correct me if I am wrong but this is my understanding:

So the Global Planner generates a path, which connects the start and goal point, and does not pass through any occupied cells in the costmap. The Local Planner is responsible for balancing costs associated with staying close to the given global plan, reaching its goal, and avoiding obstacles. It is the local planner which actually generates command velocities and is therefore responsible for the robot, moving, avoiding collision, or having a collision.

That being said, the only information the Global Planner has when you give it a goal, is the global_costmap, and that's it. What it essentially does with that, is a graph search across all possible unoccupied cells, to find a (hopefully short) path that connects the start point to the goal point. During this time it treats the robot as a point object with no shape/structure. This point object "assumption" simplifies the process of calculating the path across a map because it allows us to ignore the shape of the vehicle, the shape of obstacles, and the collision potential of different parts of the vehicle. Because it treats your object as a point, all it has do is check whether or not there is a collision at each cell individually. For large maps this is a huge optimization.

In order to prevent this point approximation being a problem you have to use a InflationLayer on your global_costmap. This makes the obstacles appear larger, and means that our point object approximation will, even when planning right on the edge of what "looks like an obstacle", actually still be in a safe space in the real world. As a rule of thumb I personally set my global_costmap InflationLayer to be about 3/4 the width of my robot.

This is different from the local_planner, which is responsible for generating the command velocities the robot will execute. The local planner generally uses a much shorter planning horizon (2 to 10 meters?) and a much smaller costmap. When it is evaluating potential trajectories that is may command, it will predict forward the position of the robot (accounting for its footprint) and check for collisions with the obstacles found in the local_costmap. It is in the local planning stage where your platform's footprint is actively taken into account. The local planner will balance the cost associated with proximity to obstacle cells, the local end goal point, and the global plan and generate a command velocity that will execute a path that minimizes these costs.

All the global planner did was find a string of connected cells that takes you from the start to the goal, and your local planner actually generates the command velocities that minimize the cost associated with the objective function.

Note: Sorry I did not link directly to more source material :/

Someone please correct me if I am wrong but this is my understanding:

So the Global Planner generates a path, which connects the start and goal point, and does not pass through any occupied cells in the costmap. The Local Planner is responsible for balancing costs associated with staying close to the given global plan, reaching its goal, and avoiding obstacles. It is the local planner which actually generates command velocities and is therefore responsible for the robot, moving, avoiding collision, or having a collision.

That being said, the only information the Global Planner has when you give it a goal, is the global_costmap, and that's it. What it essentially does with that, is a graph search across all possible unoccupied cells, to find a (hopefully short) path that connects the start point to the goal point. During this time it treats the robot as a point object with no shape/structure. This point object "assumption" simplifies the process of calculating the path across a map because it allows us to ignore the shape of the vehicle, the shape of obstacles, and the collision potential of different parts of the vehicle. Because it treats your object as a point, all it has do is check whether or not there is a collision at each cell individually. For large maps this is a huge optimization.

In order to prevent this point approximation being a problem you have to use a InflationLayer on your global_costmap. This makes the obstacles appear larger, and means that our point object approximation will, even when planning right on the edge of what "looks like an obstacle", actually still be in a safe space in the real world. As a rule of thumb I personally set my global_costmap InflationLayer to be about 3/4 the width of my robot.

This is different from the local_planner, which is responsible for generating the command velocities the robot will execute. The local planner generally uses a much shorter planning horizon (2 to 10 meters?) and a much smaller costmap. When it is evaluating potential trajectories that is it may command, it will predict forward the position of the robot (accounting for its footprint) and check for collisions with the obstacles found in the local_costmap. It is in the local planning stage where your platform's footprint is actively taken into account. The local planner will balance the cost associated with proximity to obstacle cells, the local end goal point, and the global plan and generate a command velocity that will execute a path that minimizes these costs.

All the global planner did was find a string of connected cells that takes you from the start to the goal, and your local planner actually generates the command velocities that minimize the cost associated with the objective function.

Note: Sorry I did not link directly to more source material :/