search

PRBonn / kiss-icp

A LiDAR odometry pipeline that just works
https://www.ipb.uni-bonn.de/wp-content/papercite-data/pdf/vizzo2023ral.pdf
MIT License
1.6k stars 321 forks source link

Add param to force planarity #407

Closed ardabbour closed 1 week ago

ardabbour commented 1 week ago

There is probably a smarter way to do this, but for some environments it can be useful to have "2.5D" odometry. This just sets the z axis and roll and pitch angles to zero during registration

nachovizzo commented 1 week ago

@ardabbour, thanks for opening this PR. In fact, internally, we had a flag two_d_mode inspired in the robot_localization and the fuse package for a while. This eventually matured into https://github.com/PRBonn/kinematic-icp, which you already know. As we showed in the paper, this 2D-KISS is always underperforming kinematic-icp

image

I see cases where you don't have wheel odometry or are not a robot you can model with the unicycle, but I wonder if it makes sense to have this parametrization to the system.

I will wait for my colleagues to comment on this, but I'd vote not to take this PR. We strived to have a limited number of parameters to allow for some specific applications; kiss-icp was created to be the most general, easy-to-use solution; if customizations are needed, then it should be created, in principle, in different projects, like kinematic-icp.

On the other hand, and also a "pro-tip", although counter-intuitive, it's much faster to allow the registration system to perform estimation in 6D and later "flatten" the output. This you can do by setting to 0.0 the 6D vector that the optimization loop is spitting (the tangent space element). You can try it, and it's always faster and gives equally or even better results. When computing the jacobians in 2D, the solution converges slower as it has fewer degrees of freedom "to play with"

tizianoGuadagnino commented 1 week ago

I agree with the points made by @nachovizzo; KISS is, by our definition, a 3D LiDAR odometry system that estimates a 3D pose; any variation of this definition that is more specific (such as 2d odometry or similar) should be handled by a separate project, as we did for Kinematic-ICP. Thanks anyway @ardabbour for opening the PR(s) on both projects, much appreciated ;)