octomap, slam, path planning: how does it all fit together?

asked 2015-11-17 15:12:56 -0500

triantatwo
237 ●8 ●11 ●12

My goal is to simulate the flight of a UAV in an outdoor environment. My preliminary steps are to see what ROS packages exist which I can reuse, and determine what I need to write myself.

I've looked for projects which have overlap with mine:

However I'm still trying to figure out how the following topics fit together:

SLAM
OctoMap
Path Planning

I'm not sure how they're intertwined, so I have several questions for experts out there:

OctoMap

Is it only good for generating 3D probabilistic maps? Does it offer solutions for localization? Or is that out of scope?
Is it capable of efficiently representing large geometric areas as obstacles? For example if I have a house I want to avoid, can I place a large rectangular prism in the map?
Does it have support for dynamic obstacles? For example other drones or moving vehicles?
Are octomaps even necessary for mobile drone applications (or outdoor applications in general)? Do people roll their own mapping solutions or does everyone use octomap?
Is there a certain data type (or sensor type) that the octomap supports or requires? What if I have sonar, RGBD, LIDAR, monocular camera, etc.?
What if an octomap gets too big? Is it possible to have a moving window filter around an area of interest (i.e. the drone) and "forget" the rest of the map (or dump to disk)?

Path Planning

Can I view path planning as a function which takes in an octomap and returns a 3D path according to the planner algorithm?

SLAM

Does a SLAM algorithm populate the octomap? Or does the SLAM algorithm work off the existing octomap and sensor data? What does this workflow look like?

Comments

Could you find answer to this question? A good answer to this question will greatly help me. Thank you.

Anurag ( 2016-09-27 15:32:08 -0500 )edit

add a comment

answered 2018-05-27 15:25:03 -0500

dljubic

516 ●2 ●7 ●9

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 ...