matchScansLine() gives poor match hypotheses

1 次查看（过去 30 天）
Manan Shah
Manan Shah 2020-12-9
回答： Amrtanshu Raj 2020-12-29
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!
  2 个评论
Amrtanshu Raj
Amrtanshu Raj 2020-12-23
hi,
Can you share your scans dataset and code that you are using along with the parameters you used ?
Manan Shah
Manan Shah 2020-12-23
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!

请先登录，再进行评论。

请先登录，再回答此问题。

回答（1 个）

Amrtanshu Raj
Amrtanshu Raj 2020-12-29
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 !!

类别

在 Help Center 和 File Exchange 中查找有关 Biotech and Pharmaceutical 的更多信息

标签

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by