Is it only 2D or extension to 3D is available ?

[saimanoj18]

Hi, Congratulations on this great work! I am wondering if your work is only for 2D or it has an implementation for 3D as well? If it's not available for 3D, what are the changes, that needs to be done ?

I have a working odometry algorithm based on 3D NDT, however, it accumulates a little drift and even more importantly, the rotation estimates are not accurate. Hence its corrupting the map.

I was wondering if I can add a graph slam based back end for accurate mapping!

Can you put down your thoughts on extending your work and suggestion ?

Thanks, Sai

[Lukx19]

Hi, Current implementation is in 2D but can be extended to 3D. I know how is that possible to be done but it will require a some work. I am planning to build some 3D algorithms a top of this package but it won't be any time soon.

Current state:

I am currently finalizing my work on rewriting some parts of this package. You can see progress in branch bugfixing. New package will be divided into two parts

1. 2D front-end scan-matching which will be used as a precise odometry for second part which is 2D graph slam algorithm. This back end receives laser scans (point cloud can be an option as well) and integrates them to bigger mini-maps based on odometry received. It is important that odometry is really precise in order to have good minimaps. In case of bad odometry it is still possible to generate smaller minimaps but that will require more computation in the loop closure search. These minimaps are put into nodes in the graph. The graph is searched for loop closures. All possible loop closures need to be registered. I am currently using correlative method (Olson) with 2d d2d-ndt algorithm. I use g2o for graph optimization. I am still missing loop closure rejection which I will work on during this summer and in the next semester.

You have already created odometry frontend so you need implementation of backend. How to make backend in 3D:

1. implement efficient 3D datastructure representing minimaps. This structure needs to know operation Merge(grid a , grid b), MergeTraced(grid a , grid b) , some lookups based on 3d regisration algorithms, serialization to something usable for navigation. It can be implemented as my ndtgrid2d (simple table which holds pointers to cells. Cells are allocated only in case of present distribution) only in 3D or use something maybe more efficient like octomap.

2. implement 3D version of algorithm suitable for loop closure detection. Take a look at http://aass.oru.se/~mmn/icra2009_placerec.pdf

3. some bugfixing in current code. I have not tested it with 3D, but all parts like graph and loop closure detection should be 3D ready with minimal changes. I use a lot of unchecked templates. This gives you chance to get in almost anything you need on the other hand it can be little confusing from time to time and I would done it differently now.

4. make it work in real time - my implementation already uses one thread for merging scans to minimaps and second for loop closure and optimization but this may not be enough because 3D algorithms can be more demanding.

So as you can see this is a lot of work. I will be focusing on finalizing 2D (maybe one layer of 3D can be done really easily) so it can be fully used in community, but it would be great if you could create 3D version. I would definitely like to help with it.

I don't know what problem are you solving but if it is good enough to do multiple layers of 2D than my algorithm could be used with minimum changes.

It is possible to partially use existing implementation form original authors as a kind of help. http://wiki.ros.org/ndt_map

Could you send me a link for your 3D NDT implementation? I can check for some bugs. What kind of algorithm for 3D NDT do you use? How often do you execute registration?

Thank you for your interest :) Lukas

[saimanoj18]

Thank you Lukas for this awesome reply!

I am trying to develop a 3D mapping algorithm that is consistent over large scale, and online operation is not at all a requirement.

Precisely, I am using the ndt_mapping algorithm that is presented here. https://github.com/CPFL/Autoware/blob/master/ros/src/computing/perception/localization/packages/ndt_localizer/nodes/ndt_mapping/ndt_mapping.cpp

It works great for distances of around 300 meters but has problems such as inaccurate estimation of rotation at times, which is leading to slight misalignment in the map created using point cloud accumulation.

I am trying to creating highly dense point clouds with Velodyne 64.

Though loop closure is an option, I am a bit afraid that there will be slight errors that will be visible in the densely accumulated point cloud map. However, I want to give it a try on creating a back end scheme for accurate point cloud registration.

I will keep you posted on my approach. Your idea of multilayer 2D-NDT is also a great one.

The exact problem of misalignment shows up when I view the densely accumulated PCD with intensity. When the vehicle turns and comes back the same place, it can be seen that there are two layers to road curbs, resulting from slight inaccurate estimation of rotation. This is what I am trying to solve.

Another thought is to integrate the intensity values in NDT registration framework or to develop a backend that considers the information from intensity to accurately align the point clouds.

Thank You & Great Luck!

[Hack556]

Hello @saimanoj18 @Lukx19

I came across this issue when searching for a Velodyne GraphSLAM package for ROS.

Do either of you have any suggestions on how I would create a map of the ground reflectivity using a Velodyne LIDAR? My goal is to reproduce the results from this paper: http://www.roboticsproceedings.org/rss03/p16.pdf

Thank you!!!