Revision history [back]

Hello, triantatwo!

Excellent question(s)! I realize that the question is fairly old, but I will try to give my best to answer it since it may help others.

OctoMap

• OctoMap is good for several reasons. It is, as you said, probabilistic mapping procedure which allows us to integrate our measurements with a certain probability and to account for sensor noise and outliers. Furthermore, it is very memory efficient and relatively fast (depending on your requirements and number of points you want to integrate in one step). It is a multi-resolution mapping procedure, which means that you can see multiple resolutions in a map. By changing the resolution and range of your measurements you can also get a significant speedup etc. A very important thing to realize about OctoMap is the ray casting it does. It allows for the distinction between unknown, free and occupied voxels which some other mapping procedures do not have (point clouds, elevation maps, and multi-level surface maps). The important thing to notice is that OctoMap is a mapping procedure! Therefore, an odometry or SLAM algorithm needs to be present in order to populate the OctoMap correctly. As far as I know, no solution for localization is present although you could probably write your own localization algorithm. The OctoMap author mentioned it here.

• Well, I would say that efficiency is mostly related to the resolution of the OctoMap. Of course, number of points to be integrated into a single measurement also plays a big role.

• Dynamic obstacles are where the probability kicks in. Based on the values of probability for a "hit" and "miss" in the sensor model you could control the speed at which you are adding obstacles to your OctoMap. Everything with a probability over 0.5 is seen as an obstacle so if your probability of a hit is high dynamic obstacles will be added to the map relatively quickly - depends of course on the consistency of your sensor measurements. In theory, it works, but in practice, I could never get the desired behavior because of the sensor measurements inconsistency.

• Of course, OctoMaps are not necessary! There are many other mapping procedures that could be used. It mostly depends on your requirements - speed, memory, sparse, semi-dense or dense mapping etc.

• In order to map an environment and represent it with an OctoMap, you need some kind of a 3D information. If you have sonar you would get a point cloud and could easily insert it into an OctoMap. Same goes for RGBD sensors (Kinect, RealSense, ASUS Xtion) and LIDARs. If you have a monocular camera, there is no way of getting a 3D points of the image directly. You would have to use additional algorithms in order to create a point cloud from several RGB images.

• If an OctoMap gets too big, you could just delete it and start over. Although I suppose it is not the solution you were aiming for. There is also a possibility to create a local map of the environment i.e. a bounding box around a drone and forget everything outside that box.

There are some extensions for OctoMaps that should enhance its performance like this.

Moreover, a new article on algorithm SkiMap that compares itself to the OctoMap and even states better performance is available online together with ROS implementation.

Path Planning

• Generally speaking, yes. Path planning would be a module that would take in some kind of a map and plan the path according to the set of requirements - shortest path, most secure path etc. Usually, one would take an OctoMap, create an occupancy grid based on it and run a path planning/navigation packages on top of it. Since I have no experience in 3D path planning/navigation I have googled some posts that could be useful:
  • first
  • second

SLAM

• As I've said before, you will need a SLAM or odometry algorithm in order to correctly build your OctoMap. The workflow could be something as follows: We have a drone equipped with IMU, GPS, and a monocular camera. Based on sensor information it calculates odometry (GPS, IMU and visual odometry using RGB camera) and tracks its position in the environment. At the same time, since it knows its position, it can map the environment relative to that position. If you know the position and have a point cloud at that position, the OctoMap mapping will easily insert it into the map.

However, one thing to note here! The OctoMap has no support for global optimization which occurs when loop closure is done. The map stays as it is! Furthermore, because of the drift in the odometry, the map can overlap between multiple frames. Therefore, you have to have good odometry algorithm to avoid it or, forget previously visited parts of the map by having a bounding box around a robot.

Since this is already a relatively long answer, I will stop here and if someone has any further questions feel free to ask.

If someone notices mistakes or some pieces of outdated information, please notify/correct me.