search

engcang / FAST-LIO-SAM-SC-QN

A SLAM implementation combining FAST-LIO2 with pose graph optimization and loop closing based on ScanContext, Quatro, and Nano-GICP
Other
75 stars 5 forks source link

Some questions about the frame #2

Closed yyh-pc closed 6 months ago

yyh-pc commented 6 months ago

hello, I find that in loopTimerFunc(), "keyframescopy = m_keyframes" this step consumes more and more time as the number of keyframes increases.

Firstly, I would like to ask if it is possible to reduce the time consumption by copying only the current frame and closest_keyframe instead of copying all the keyframes if we adopt the frame-to-frame approach of Quatro + NANO-GICP to detect loop so that the frequency of loop detection can be increased a little bit.

Secondly I would also like to ask if it would be better to have a higher loop detection frequency.

Thirdly, I would like to ask you why you don't have fastlio as an odometer output instead of fastlio2

Looking forward to your reply！

engcang commented 6 months ago

@yyh-pc Hi.

  1. Yes. You can modify my code into not copying whole frames but only the current keyframe and the closest keyframe +- subframes (subframes are used in icpKeyToSubKeys matching). I was too lazy to implement that with many mutexes locks and unlocks. And I did not want to see that there are may mutexes in one function.
  2. It depends on the situations. If the robot is moving fast, yeah slow loop detection might miss the real loop-closing. But in general, fast loop detection is not needed.
  3. Try to compare FAST-LIO1 and FAST-LIO2 yourself! Version "2" means the improved performance, right? :)
yyh-pc commented 6 months ago

thanks for you detailed reply, sorry I mean Faster-LIO,not Fast-LIO in 3.

engcang commented 6 months ago

@yyh-pc Aha, I got it. This repository mainly focuses on the loop-closing with Quatro to promote it and study GTSAM myself, as I wrote in the readme file. So any other odometries can be used interchangeably, though I just prefer FAST-LIO2.