Open facontidavide opened 5 years ago
Hi,
I would like to start by exploring the scan matching approach. Usually a dense approach is computationally demanding, but I would like to see how much we can optimize the code to make it efficient. If it fails, we can try the feature base approach.
I already have a MatchSurface3D class :smile:
I already created a new branch called slam3d-dev
with the MatchSurface3D class in it.
I already have a MatchSurface3D class smile
Awesome
Hi Eurico @eupedrosa ,
I was wondering is the slam3d-dev
now workable?
I'm really looking forward to see the extension of LaMa ROS
from 2D to 3D, capable to work with the 3D point clouds data collected by the 3D LiDAR.
Thanks and best regards, William
Hi @WilliamWoo45,
The slam3d-dev
is not workable. Right now it is not a priority for me. Furthermore, I do not have access to a 3D LiDAR, which also reduces the motivation. Although, this may change in the future.
But 3D is not forgoten. Hopefully LaMa will have 3D solutions in the future.
Hi Eurico,
Thanks for your prompt response. Definitely I'll stay tuned for the 3D solutions of LaMa :)
Take care and all the best! William
Hi,
as we started discussed in the ROS related repository, it would be cool to explore the evolution to 3D, using the foundation we have already.
I started getting familiar with Slam2D and I guess that the first tiny step would be to implement the MatchSurface3D class.
I am not an expert, but as far as I understand, software live loam_velodyne and Lego_LOAM extract features (planar and corners), whilst Cartographer has a Ceres based scan matching.
https://github.com/googlecartographer/cartographer/issues/1539
I guess that the latter approach is more similar to MatchSurface2D, but the former has been proved to be a very effective heuristic.
Any thought?