The transform_tolerance parameter sets the maximum amount of latency allowed between these transforms. Specifically, it assumes that all transforms between the coordinate frames specified by the global_frame parameter, the robot_base_frame parameter, and sensor sources are connected and up-to-date. In order to insert data from sensor sources into the costmap, the costmap_2d::Costmap2DROS object makes extensive use of tf.
The details of this inflation process are outlined below. This consists of propagating cost values outwards from each occupied cell out to a user-specified inflation radius. After this, each obstacle inflation is performed on each cell with a costmap_2d::LETHAL_OBSTACLE cost. Each cycle, sensor data comes in, marking and clearing operations are perfomed in the underlying occupancy structure of the costmap, and this structure is projected into the costmap where the appropriate cost values are assigned as described above.
#2d occupancy grid mapping c++ update
The costmap performs map update cycles at the rate specified by the update_frequency parameter. Columns that have a certain number of occupied cells (see mark_threshold parameter) are assigned a costmap_2d::LETHAL_OBSTACLE cost, columns that have a certain number of unknown cells (see unknown_threshold parameter) are assigned a costmap_2d::NO_INFORMATION cost, and other columns are assigned a costmap_2d::FREE_SPACE cost. Each status has a special cost value assigned to it upon projection into the costmap. Specifically, each cell in this structure can be either free, occupied, or unknown. While each cell in the costmap can have one of 255 different cost values (see the inflation section), the underlying structure that it uses is capable of representing only three. If a three dimensional structure is used to store obstacle information, obstacle information from each column is projected down into two dimensions when put into the costmap. A clearing operation, however, consists of raytracing through a grid from the origin of the sensor outwards for each observation reported. A marking operation is just an index into an array to change the cost of a cell. Each sensor is used to either mark (insert obstacle information into the costmap), clear (remove obstacle information from the costmap), or both. The costmap automatically subscribes to sensors topics over ROS and updates itself accordingly. The details about how the Costmap updates the occupancy grid are described below, along with links to separate pages describing how the individual layers work. The costmap_2d::Costmap2D class implements the basic data structure for storing and accessing the two dimensional costmap. The layers themselves may be compiled individually, allowing arbitrary changes to the costmap to be made through the C++ interface. Each layer is instantiated in the Costmap2DROS using pluginlib and is added to the LayeredCostmap. It contains a costmap_2d::LayeredCostmap which is used to keep track of each of the layers. The main interface is costmap_2d::Costmap2DROS which maintains much of the ROS related functionality. Maintaining 3D obstacle data allows the layer to deal with marking and clearing more intelligently. By default, the obstacle layer maintains information three dimensionally (see voxel_grid). For instance, the static map is one layer, and the obstacles are another layer. Each bit of functionality exists in a layer. This is designed to help planning in planar spaces.Īs of the Hydro release, the underlying methods used to write data to the costmap is fully configurable. For example, a table and a shoe in the same position in the XY plane, but with different Z positions would result in the corresponding cell in the costmap_2d::Costmap2DROS object's costmap having an identical cost value. The costmap_2d::Costmap2DROS object provides a purely two dimensional interface to its users, meaning that queries about obstacles can only be made in columns. The costmap uses sensor data and information from the static map to store and update information about obstacles in the world through the costmap_2d::Costmap2DROS object.
The costmap_2d package provides a configurable structure that maintains information about where the robot should navigate in the form of an occupancy grid. For the robot to avoid collision, the footprint of the robot should never intersect a red cell and the center point of the robot should never cross a blue cell. Note: In the picture above, the red cells represent obstacles in the costmap, the blue cells represent obstacles inflated by the inscribed radius of the robot, and the red polygon represents the footprint of the robot.
0 kommentar(er)
