[Apologies that this is the first post about MaSCOT. I’ll try to keep up a development blog _and_ backfill with add’l project notes and resources. Maybe.]
The full MaSCOT system has been assembled and is ready for tank testing.
I ran the sealed system on the desktop for the first time last night. While it was on I recorder internal air temperatures using the Bosch BMP280 on the companion board, plus the Linux ACPI temperature values.
The system was idle for the majority of the test (overnight). I started using my recorder app at the end, hence the tail up.
The temperatures look relatively high, but this is with the system in air, not in water. This will sink heat away from the enclosure far better than air.
Also, there’s a clearly a bug with my code to read from sys (I’m using libudev, not a shell call), as it’s not updating its values. Back to the drawing board… Even with that issue, the on-die temperatures are somewhat lower than the air temperature, which I don’t believe for a second.
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:
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.