Jump to main content
Automation Technology
OctoMap
Automation Technology 

Timebased local OctoMaps

Autonomous navigation of our rough-terrain rovers implies the need of a good representation of their near surrounding. In order to archive this we fuse several of their sensors into one representation called OctoMap. But moving obstacles can produce artefacts, leading to untraversable regions. Furthermore, the map itself is increasing in size while discovering new places. Even though we are only interested in the near surrounding of the rovers.

Our approach to these problems is the usage of timestamps within the map. If a certain region was not updated within a given interval, it will be set to free space or deleted from the map. This first option is an existing solution and the second option reflects our new alternative. The proposed approach is provided as open source.

Artefacts

Within this experiment one rover is standing still, while a second rover is slowly crossing its close surrounding. Since our visual depth sensors are tilted downward only the lower part of the driving rover is updated almost on time. In contrast the upper part is only sensed by the slowly turning laser, creating several artifacts. Since both timebased implementations show similar results only our implementation is compared to the regular octomap implementation. As shown in the image and in the video the timebased implementations remove artefacts as expected. Only those too new to be degraded are within the map for a certain amount of time.

The degrading is needed to remove artefacts from moving objects.

Freemap

Within this experiment, one rover is driving along a rectangular path of approximately 90m×40m while mapping its surrounding. The final result of both implementations regarding visible, occupied voxels are alike and therefore not explicitly shown. However a distinctive difference is seen when comparing free voxels. Here our implementation is clearly more memory saving.

The preview-image shows the final results regarding free voxels. Our implementation (right) does not take as much memory as the existing implementation (left).
Within the video, the free voxels of both implementations are shown by blue dots. Additionaly the current nearfield map is visible to help tracking the robot and to point out that there is no difference regarding visible, occupied voxels.

Publications

  • ?. ()

Source Code

Source Code of our extension for degrading voxels:

https://github.com/TUC-ProAut/ros_octomap

The basic framework and its description can be found here:

http://octomap.github.io/