search

norlab-ulaval / libpointmatcher

An Iterative Closest Point (ICP) library for 2D and 3D mapping in Robotics
BSD 3-Clause "New" or "Revised" License
1.63k stars 549 forks source link

libpointmatch seems to round data and lose precision? #226

Closed nickponline closed 6 years ago

nickponline commented 7 years ago

Hi @pomerlef

I registered a pointcloud to itself as a test and it appears to round the x and y values to the nearest whole number:

==> cloud.csv <==
x, y, z, R, G, B
539719.26,4065740.41,1.96,38807,34181,30583
539720.41,4065739.15,1.89,38036,33410,29555
539721.55,4065739.18,1.86,40092,34952,31354
539718.28,4065739.35,1.79,41120,36494,32896
539719.41,4065739.17,1.91,42662,38036,34181
==> cloud_registered.csv <==
539719 , 4.06574e+06 , 1.96032 , 38807,34181,30583
539720 , 4.06574e+06 , 1.89032 , 38036,33410,29555
539722 , 4.06574e+06 , 1.86033 , 40092,34952,31354
539718 , 4.06574e+06 , 1.79032 , 41120,36494,32896

Since my data is in meters the rounding is significant. I used the example pmicp binary.

Nick

pomerlef commented 7 years ago

The library can work with float or double. The executable pmicp used float by default.

You can change this line for:

typedef PointMatcher<double> PM;
nickponline commented 7 years ago

Do you think that is actually the issue, that's shouldn't cause the output value to be rounded to whole numbers?

pomerlef commented 7 years ago

From a C++ tutorial:

When outputting floating point numbers, std::cout has a default precision of 6 -- that is, it assumes all floating point variables are only significant to 6 digits, and hence it will truncate anything after that.

This would explain 539719.26 converted to 539719 and clearly 4065740.41 to 4.06574e+06.

Computing with floating point is faster than double precision, but I saw your problem when working with GPS coordinates. If you want to keep the computational speed, you can express your point cloud in a temporary frame that subtracts the repetitive information.

Did you try to change the template to double?

nickponline commented 7 years ago

Yeah I did try changing float to double. I will try centering the data by subtracting the mean. In general is that a good practice?

On Tue, Oct 17, 2017 at 9:54 AM, François Pomerleau < notifications@github.com> wrote:

From a C++ tutorial:

When outputting floating point numbers, std::cout has a default precision of 6 -- that is, it assumes all floating point variables are only significant to 6 digits, and hence it will truncate anything after that.

This would explain 539719.26 converted to 539719 and clearly 4065740.41 to 4.06574e+06.

Computing with floating point is faster than double precision, but I saw your problem when working with GPS coordinates. If you want to keep the computational speed, you can express your point cloud in a temporary frame that subtracts the repetitive information.

Did you try to change the template to double?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ethz-asl/libpointmatcher/issues/226#issuecomment-337283816, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkBRyboNMyKirSFh2q8M9SljAHWOMlSks5stNvbgaJpZM4P662G .

pomerlef commented 7 years ago

That's what is happening inside libpm anyway to properly resolve the rotations. So, there should be no harm in doing so to preserve the floating precision at the right place for meters.