matchScansLine() gives poor match hypotheses

I am trying to use the matchScansLine(currScan, refScan) value with a bunch of name-value pairs and trying to tune it.

However, I was getting poorly aligned scans. So I started looking at debugInfo output and also using exampleHelperShowLineFeaturesInScan(s1, s2, debugInfo, initGuess); This generates the two scans with their lines marked with their corresponding indices. My example identifies 10 lines in each scan.

Now the displacement between these scans is very low, and it is very easy to see manually which scans should match and I can visually write a match hypothesis: which lines in currScan match which lines in refScan.

However, debugInfo.MatchHypothesis seems to generate hypotheses that just don't make sense. Based on my understanding, the only tunable parameters that would affect the match hypothesis are CompatibilityScale and LineMergeThreshold. My LineMergeThreshold is very low since the two scans are very close by.

But after playing around with these parameters for a few days, I have no idea why the match hypotheses generated are bad. It would be interesting to know the exact algorithm being used to generate these data associations and try to troubleshoot it. This function was only introduced in 2018 and does not have any forum posts. Any other suggestions are also appreciated, thanks!

[Amrtanshu Raj]

hi,

Can you share your scans dataset and code that you are using along with the parameters you used ?

[Manan Shah]

Hi,

Thank you so much for reaching out. My bad, should've definitely shared the data and code above.

First I will share some observations on the documentation for matchScansLine which I think should be corrected (points 1-2) and then provide the data + code below (points 3+).

1. There is a discrepancy in the documentation for matchScansLine for matchHypothesis. In the example shared on the documentation page, it is implied that the indices of the matchHypothesis vector correspond to the reference scan and the values of the matchHypothesis vector correspond to the current scan, however, in the description of outputs at the bottom of the page says it is the other way around. From my observation, the latter is correct and the explanation in the example should be changed.
2. The behavior of MatchValue seems inconsistent with my interpretation of its explanation. Based on the explanation, I would expect it to be a vector showing scalar match values for each entry in matchHypothesis and in case of repeated matches for the same feature, the better match having a lower score. However, the observed behavior is that it is simply a scalar value as some sort of indication of the quality of the match, which is not helpful at all for troubleshooting/tuning.
3. You can download the text and .m file below. The text file has 20 rows, each row representing a scan with 150 range measurements each. The script reads this file and tries to match each pair of consecutive scans.
4. For some reason, LineMergeThreshold input seems to be influencing the detection of line features (when i change it, the number of features detected changes), which should not be the case, based on the documentation. CompatibilityScale and smoothnessRatio should only influence number of line features detected and the other three optional inputs should only influence the data association.
5. You can observe the match created for each step by placing a breakpoint at line 64. After quite some tuning, I have observed the best results with CompatibilityScale set at ~0.5. But at that best performance, I can still see at least 5-7 pairs matched very poorly in spite of having correctly detected features.
6. For my current project I have abandoned this approach. I am using matchScansLine simply to obtain the line features (normals, and the mask for points from debugInfo). I then use this information about normals in my own custom point-to-plane ICP implementation which is giving me significantly better results, accurately matching every pair of consecutive scans. (This is even performing better than pcregistericp in MATLAB, but probably not relevant here.) Hence, I would strongly suspect the data association portion of this function to have some bug, not the feature detection portion.

Apologies for the lengthy post, I hope this is helpful to find the exact needle in the haystack.

Thanks a lot!

Answer 1

[Amrtanshu Raj]

Hi,

I have made modifications to your code that give better match and position estimates. I advise you to go through the refrences mentioned in the end of the docuementation to get better understanding of the implementation.

Hope this helps !!