Odometry Polluted with Noise

Comparing the mapping abilities of the SLAM algorithms with odometry polluted with noise, it is evident Figure 5.5 that many of the sensor and SLAM algorithm combinations failed to generate maps. These failures are represented by missing box plots on the graphs, as described in Section 5.2.1.1. Again, the progress bar represents the map generation success out of five runs. Another common feature that is seen on the box plots is the are blue dots that represent the simulation results. They are placed on the same graph so that it can be used as a comparison for the reader to note the difference between the experimental runs with real and simulated sensor data. A feature, which has not been seen previously, is a horizontal line. This line is only present when one out of five runs was able to generate a map. Since it is only one successful one, there is no average and variation, which is why a line is shown instead of a box plot.

When noise was introduced into the odometry data, KartoSLAM began to fail consistently when used with low FoV sensors, this can be seen in Figure 5.5. This behaviour is similar to how Hector Mapping did even with nominally perfect odometry data. The only success that KartoSLAM had with the low FoV sensors was with the Microsoft Kinect, and the map quality itself was quite poor. Gmapping also produced some failures with the low-FoV sensors, although its success rate was slightly higher than that of KartoSLAM. The failures with the low FoV shows the importance of a high FoV. A low FoV reduces the amount of features that is present in each scan, this makes it more difficult for scan matching algorithms to match incoming scans and thus generate a map that is representative of the ground truth.

Figure 5.6: The multitude of ghost maps seen in the LightWare simulation with Hector Mapping.

A surprising observation was that the LightWare and Hector Mapping combination was unable to gen- erate a single map. This was due to the low rota- tion rate of the LightWare sensor; this conclusion was reached based on simulation results. In the simula- tion, the LightWare sensor limitations (rotation rate, FoR, etc.) were matched and paired with Hector Map- ping. It was found that in the simulation the maps failed to generate as well and it was only when the rotation rate was increased that a map was able to be generated. In Chapter 5 this was stated as a possi- ble theory and this simulation provides evidence that the low rotation rate was the culprit. The maps pro- duced would be populated with an excess number of ghost maps (as seen in Figure 5.6) as the scans were incoming at a rate too slow for the scan matching al- gorithm to function properly. This behaviour was not seen on Gmapping and KartoSLAM suggesting that pure scan matching is insufficient in dealing with low rotation rate sensors.

rates), it was able to generate maps that contained lower error values than the maps generated by Gmapping (as shown in Figure 5.5). However, Hector Mapping still failed on occasion with this type of sensor, meaning that Gmapping appears to be a better choice in terms of robustness (robustness referring to a greater map generation consistency). This is further reflected in the missed points when comparing Gmapping and KartoSLAM, as Gmapping produced maps which contained a lower amount of missed points.

Observing Figure 5.5, it can be seen that Gmapping had the most robust map generation capabilities when compared to Hector Mapping and KartoSLAM. Unlike Hector Mapping and KartoSLAM, Gmapping was able to generate a map with the SwissRanger sensor while also generating 5/5 maps with all the wide FoR sensors. While Gmapping did produce maps which had a similar amount of error (often slightly higher rather than lower) to the KartoSLAM maps, it was more likely to succeed in map generation, making it a better choice. It appears that when compared to Hector Mapping and KartoSLAM, Gmapping sacrifices some accuracy in return for greater robustness.

As was found in the nominally perfect odometry cases, KartoSLAM again generated maps that more closely approached the simulated sensor data maps than both Hector Mapping and KartoSLAM. This can be seen in Figure 5.5. While not necessarily the most accurate algorithm, this again shows that KartoSLAM deals well with errors in the ranging data.

As seen in Figure 5.5 the Santos Metric was again affected by ghost map errors that were present in the maps. The only case where the Santos Metric was not affected by ghost map error, with the KartoSLAM results, is with the LightWare sensor. This was due to the LightWare and KartoSLAM combination being the only combination in which ghost map error was not present. This is especially seen with KartoSLAM and the Velodyne maps. The Reversed Santos Metric again was affected by the excess data noise that was seen in the maps.