LSD-SLAM External Dependencies

As noted in the README, LSD-SLAM uses a number of “non-standard” external dependencies. For a number of reasons, I’ve provided the option to have CMake build a copy of those dependencies “in-tree” with LSD-SLAM — though this can be disabled with the BUILD_LOCAL_* flags in CMake. This was largely a matter of control. Most of the external deps had some slight wierdness or prickliness (or not-quite-right-CMake-iness). It made sense to essentially provide written instructions on getting the right configuration.

In a most cases I’ve taken the further step of using my own forks of a few of the repos within the LSD-SLAM code. In general these are for some fairly minor edits (could I do it with patch files instead?), but I thought it was worth documenting why I’d done what I’ve done.

  • G2O. Their original CMakeLists.txt was using @rpath for the libraries on OS X. I wanted full control over library paths to ensure we were always using the in-tree builds, so I made changes to CMakeLists. It might be possible to achieve the same thing by manipulating CMake on the command line. I might also be doing the rpath thing wrong.
  • g3log. Started by disabling the generated_definitions.hpp file which was causing extraneous rebuilding in the external project. This concern was reduced somewhat by removing the external projects from make all and sequestering them in make dep. I subsequently added an #define-level option to disable DEBUG messages as something of a halfway house to full dynamic logging.
  • Pangolin. I was having problems with OpenGL error 1280 with XQuartz on OS X. Don’t know the root of the problem, so I explicitly squelch it in the error reporting function. Also fiddled with the RPath settings for the dylib on OS X and issues with the FFMpeg API.

The following external projects are unchanged:

Status report, June 10th

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 shared_ptr.

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.