I had a few hours this week to debug issues with thread synchronization related to my refactor/overhaul. I have been testing with TUM’s Machine dataset — in the .PNG form — (part way down the page), and with my Zed as a monocular camera, primarily on my x86_64 desktop with backup testing on my Mac, but not on the Jetson.
The big difference between the two input types is that the stack of PNGs does not have an inherent framerate (fps = 0), so
trackFrame is called with
doBlock = true, and
trackFrame blocks while
mapThread does its thing. The Zed has a defined framerate (as would playing back a movie file), and
trackFrame doesn’t block. So you get slightly different synchronization issues. Similarly, I get different behaviors between debug and release builds, and between my desktop and MacBook due to different relative throughputs.
You can simulate the non-blocking behavior with a stack of PNGs by manually specifying a fps on the command line:
LSD –fps 30 –calib ../datasets/LSD_machine/cameraCalibration.cfg ../datasets/LSD_machine/images
I found a serious bug related to establishing keyframes. For me the symptom was losing tracking as soon as the first keyframe is selected (once the camera starts moving). I was able to debug that and a follow-on problem related to the lifecycle of frames which become keyframes — long story short I hadn’t turned all of the
Frame * into
These changes are now in the master branch at commit 805c285. As always, I apologize for my git commit discipline. Must get better at that.
There is still a bug in the reloading of old keyframes. That’s next on the list.
I also plan to add code to run LSD SLAM “live” with a conventional USB cam — mostly so I can test live video from my Mac. Should be a minor permutation on the movie player. Unfortunately, in that case you need to supply a camera calibration — so I’ll need to calibrate my Mac’s webcam.