In a traditional costmap, all of the data is stored in a single grid of values, in what we term a monolithic costmap. The monolithic costmap has been the prevailing technique because of its simplicity, in that there is only one place to read values from and write values to. However, proper maintenance of the costmap from cycle to cycle becomes more difficult as the number of types of values in the costmap increases.
For example, consider the relatively simple example of a conflict between the sensor data and the values already in the global costmap. The sensor data indicates that a certain area is
clear, while the costmap indicates there is an obstacle. The correct method for updating the costmap depends on the origin of the data and additional semantic information. One scenario might be that the previous values indicated a prior position for a person who has now moved. Then, the correct behavior may be to overwrite the lethal values in the costmap with the new free values, allowing the robot to pass through the newly vacated space. However, an equally valid scenario is that the values in the costmap originate from the static map, which was created to include obstacles that cannot be seen by the sensors, such as glass walls. In that case, the lethal values should stay in the costmap.
The key problem with monolithic costmaps is that it is impossible to differentiate these two cases, as both present as lethal values in the costmap. Any semantic data for what the values in the costmap represent is stripped from the data as soon as it is reduced to a single value in the costmap.
The previous example revealed the inadequacies of the monolithic costmap in differentiating between just two data sources. The problem is exacerbated when additional types of data are integrated. If we would like to declare precedence between two different sensors, the mono- lithic costmap also lacks the semantic information to update accordingly. If, for example, one wanted to integrate a sonar sensor with laser range finder data, to avoid driving through glass walls, the sonar data may be given precedence. However, in the update process, the context of the values previously in the costmap are obscured meaning that the sonar values can easily be overwritten by the free values from the laser range finder.
Storing all of the obstacle information in a two-dimensional grid also can be problematic for properly handling three-dimensional obstacle data. The original developers of the ROS implementation encountered this problem when they used three-dimensional sensors like a tilting laser range finder. If the obstacle data is stored only in the monolithic costmap, obstacles at different heights could be inappropriately removed by clearing observations. Thus, they introduced voxel grids to keep track of the additional information[62].
The problem also presents when multiple non-lethal data sources are integrated, each of which will have individual semantic meaning. Consider the complexities of differentiating between a nonlethal value generated from the inflation step and the nonlethal value based on someone’s personal space, like in Figure 7.1. The value in a given cell in this example is the sum of the two costs. However, in order to change or remove the costs for one of the data sources, the update algorithm would need to know the value of the two individual
Figure 7.1: Overlapping Costmap Costs - This graph shows how to calculate the values in a row of grid cells using two overlapping costs. The first is the standard obstacle and inflation layer with its exponential drop off as distance increases from the obstacle, shown in green. The second is a linear hallway layer like the one used in Chapter 5, aimed at making the lowest cost be as far left as possible, shown in blue. The value in the monolithic costmap for each cell is the sum of the two costs.
costs, not just their sum. However, in a monolithic costmap, the only information that is maintained is the sum. Hence, a change in one of the values requires that both of the costs be recalculated. Such a recalculation would require additional semantic information, which would have to be maintained somewhere outside the monolithic costmap.
The monolithic costmap also only affords a single interpretation of the values in the costmap. Thus far the costs have represented the cost of being in that cell, but other use cases may require different interpretations. For example, it is common when using sonar data to create a probabilistic occupancy grid, where each cell’s value is the probability that there is an obstacle in that cell. The real trouble lies in trying to combine a probabilistic map with a cost-based map. Since the values do not mean the same thing, they cannot both be stored in the monolithic costmap.
In addition to the limited storage capacity of the monolithic costmap, there is the problem of the exact update process to use to combine the disparate data sources. For a probabilistic occupancy grid with a single data source, the update process consists of the simple appli- cation of Bayes Theorem. It is similarly easy to define policies to update a costmap with
relatively few data sources. However, as the number of sources increases, the policies needed to combine them become increasingly complex.
The lack of semantic information in the monolithic costmap also makes it difficult to tell how long any particular cost value has been in the costmap. Hence, if the updated area needs post-processing or to be published to some external source, there is no established way to determine the scope of the most recent updates.
The lack of an established paradigm for maintaining and updating a costmap results in implementations that take an ad-hoc approach. This method has worked thus far due to the relatively small number of data sources used in practice, but it becomes infeasible as the number of sources increases. In order to ensure that the data is combined in the correct way, every data source needs to be aware of every other data source.
Even in the prior work that define useful algorithms for calculating costs, the process that they use to actually integrate them with their full costmap is usually opaque. Without the information about how precisely costmaps are updated, accurately replicating results becomes impossible.
Storing all of the compiled cost data into this single simple data structure loses all the semantic information about where each value came from and what it represents. Once in a monolithic costmap, the value lacks context.