Request Verification of 3D Cloud Quality

[jdemieville-ua]

Title: Request Verification of 3D Cloud Quality

Tags: 3D, laser, point, cloud

Description

Typical QC of laser data at gantry is done by looking at the preview PNGs. After a night of deployed reference 3D target, I loaded the PLY files into CloudCompare to see how it looked. Overlaying the east and west point clouds, it appeared that the east side had a curvature to it, as seen below. I see the curvature in both the aluminum stepped block and in the meter stick, both of which were set on a table (90cm in height).

The timestamp associated with this is 2018-10-25__04-20-26-988. The next night, the target was deployed again, but rotated 90 degrees. The corresponding timestamp is 2018-10-26__02-40-44-187.

I request input from someone familiar with the point cloud processing to confirm whether it's an issue with the data or user error in viewing the data.

[ZongyangLi]

@jdemieville-ua
I am not able to observe the 'curvature' from my software.

Could you please point me out what is 'curvature' mean and high light the curvature area.

[jdemieville-ua]

@ZongyangLi : Is that both East and West clouds? I'm not very familiar with CloudCompare, but loading with the default settings, the left edge on the East cloud appears to pull upwards in a front (looking West) view. The West cloud, in contrast, appears flat. I see this on both days mentioned. If you're able to load both East and West clouds and don't see the issue, then this should confirm that the instrument is working properly. Thanks for looking into this!

East:

West:

[ZongyangLi]

@jdemieville-ua @dlebauer

I also see those curvature in the east side point cloud, both in two day's data.

From my understanding, it should not curvature like this. This might due to a calibration problem, or some in-expected anamorphic lens problem. I will ask @pless for some further advise. We may also report this to LemnaTec.

[pless]

I have discussed this with Zongyang. We think:

(a) this looks like a calibration issue. The calibration for this type of sensor describes where the camera and laser are, relative to each other, and how they are oriented. If the calibration has an error, where, for example, the rotation of the camera is wrong, that could lead to an error where straight surfaces look like they are curved.

(b) Because this calibration procedure is proprietary, it is difficult to look inside it to figure out where the problem is.

(c) One quick thing to check might be to see if the "east facing" 3D scanner is accidentally using the "west facing" calibration file.

(d) Unless you have a long, flat surface visible in the point cloud data, it will be difficult to determine if the calibration is correct. As a corollary to that, the local, relative 3D structure that the scanner is capturing is likely to be close to correct.

(e) Next steps: 1. try quick-fix (c). 2. Ask for the east-scanner to be re-calibrated. 3. If there is any flexibility in opening up the proprietary "convert the depth maps into the point-cloud" code; i am excited to take a deeper dive to understand what is happening.

[jdemieville-ua]

Thanks, @pless and @ZongyangLi. A LemnaTec issue was created for this late last week. With the system being down for construction, we won't be able to verify that it is using the correct calibration file for a bit. I'll pass along this feedback to LemnaTec and keep you updated as to any results.

[max-zilla]

For reprocessing we reference this as a Known Issue in existing data so we can proceed with the las2height processing, then we can rerun early next year once fix is in place.

[max-zilla]

TODO: need to integrate the meeting notes from the call about this issue. For winter 2018-19 we are running current algorithm. Should reference this in extractor readme.

[dlebauer]

What is the status of this error? Appears that notes from a call in Nov 2018 are here: https://docs.google.com/document/d/11O1A1FFk-452NN5Mio3yPd7EaYWlmE5bTVmx4JxDaJg/edit

[jdemieville-ua]

@dlebauer : Going back through emails, my records show the following:

• @pless thought it was a calibration issue [5/21/2019]

• @rjstrand stated that it "has been discussed at length. Fraunhofer has said that a calibration is the first step in dealing with this kind of issue. Essentially, the group has been waiting for someone to determine the impact of the “bending” on the output data set. The group was then going to decide whether they wanted to pay for a calibration. To my knowledge, no decision has been made. Looking at the GitHub entries, Robert suggested a recalibration but things got sidetracked as we shut down for the extension. I can get an official quote from Fraunhofer for a calibration, but Fraunhofer wants to know who is paying so that they can properly address the quote.

I will also check with Fraunhofer for procedures to verify which calibrations are actually implemented in each of the units." [5/21/2019]

It took a while for us to get a quote and funding, perform the calibration, and implement the new calibration file. Calibration deployed 12/13/19. Data generated after 11/25/19 is processed using the new calibration file.

To the best of my knowledge, nobody has checked to see if the curvature issue is still present since the calibration was performed.