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

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 trackFramedoesn’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:

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.

I like the idea of continuous integration testing, particularly when it’s easy. For a laugh, I thought I would try hooking my version of the AprilTags library into Travis-CI.

Unfortunately, I forgot that I was developing primarily for OpenCV 3.x, while standard Ubuntu is still using version 2.4.x. No problem, Travis allows installation from Launchpad PPAs. I’ll just, er, compile my own PPAs for OpenCV3.

So, several days (and a bazillion CPU cycles) later, I have: OpenCV 3.0.0 PPAs for Trusty and Precise. Sorry, I’ve only had time to do Precise (which Travis uses in its legacy stack) and Trusty (which I run on my compute machines) so far. Newer distos should be trivial based on Trusty…

Most importantly, I don’t know what the heck I’m doing, so if there’s something terribly wrong with them or you’d like new features, send ma pull!

I’ve been contracted to develop a WAN emulator for the testing of a teleconferencing-type application. The app runs on mobile devices and the expectation is that it will run most of the time on the cellular network. The app is designed for transmitting information from the field to a central location, so upload/uplink bandwidth is critical. Previously, we found the uplink bandwidth on the mobile carriers in Christchurch ranges from marginal to terrible.

So we’ve decided to turn the question around and measure how well the app performs for given amounts of bandwidth (and in the presence of other network properties like delay, etc.).

To do this I’ve taken the original network configuration:

and replaced the big scary uncontrollable internet blob in the middle with a Linux PC.

The major (and unavoidable) change is that the first hop from the mobile device is over Wifi, rather than 3G. Does that matter? Almost certainly yes. But, since I don’t have a test cell site sitting in the lab, I can’t see any way around it.

In the middle I’ve put a PC which acts as a wireless access point and router. Traffic between the the right and left sides of the diagram can be shaped using the network emulation (netem) layer in the Linux networking stack. At least that’s the plan.

The built-in NIC is connected to the greater internet and provides the main point of access to the machine.

Internally I’ve created two bridges, “outside” and “inside”. Each is assigned the x.x.x.1 address for a different subnet. The outside bridge contains one of the Intel NICs and the Wifi adaptor. The inside bridge contains the other Intel NIC.

Uses iptables to NAT traffic on the test networks to the outside world (iptables config provided at the end of the post).

Finally, I’m running two VirtualBox virtual machines, one on each of two test networks. They’re very simple Ubuntu Server installations, mostly so I can run quick validation tests without having both PCs running — or in case I need to give one of the PCs back. Part of the experiment will involve testing the VMs versus the “real” PCs to see if there is a significant performance difference. The two VMs use VirtualBox’s “bridged adaptor” to connect to the relevant bridges.

n.b. I’m running Ubuntu Server 13.04 on everything (the main PC, the test PCs, the VMs), with the “stock” versions of all the relevant software as provided from Ubuntu. That means VirtualBox 4.2.10 for now…

For reference, I’ve done the NAT configuration by hand in /etc/rc.local:

I recently purchased a Sierra Wireless (now Netgear) Aircard 320U USB 3G/4G modem for some testing. I selected the Aircard 320U based partly on its technical specs (compatibility with the major New Zealand providers), as well as the fact they actually bother to provide support for Linux.

The unit is supported by two kernel modules. sierra is a USB-serial module, which enumerates a number of /dev/ttyUSB* serial devices. These allow direct communication with the modem. For example, I’m using /dev/ttyUSB2 to send AT-style commands to the modem.

The sierra_net module appears as a USB-network driver. As such, the modem appears directly as a network device (wwan0 for me) without any additional mucking about with PPP, etc.

Sierra provides instruction for building their kernel source. Unfortunately, the last entry is for “v3.2_1740” for kernel 3.0.x. As I’m using a relatively recent Ubuntu installation, I’m running a 3.8 kernel.

The Linux 3.8 kernel provides the sierra (no version number) and sierra_net (v2.0) drivers, but I was unable to get these drivers to enumerate the Aircard 320U. The tarball from Sierra lists sierra v.1.7.40 and sierra_net v.3.2, but out of the box the Sierra code would not build under kernel 3.8.x (changing USB APIs, I imagine).

It seemed like a case of the kernel containing old code which was being ported forward with each new kernel rev, while the vendor was providing updated code, but not keeping up with kernel dev. Seemed like a straightforward call to forward-port the driver, which you see here.

I should disclaim I didn’t do this using my deep knowledge of the Linux kernel APIs, but by a “monkey-see-monkey-do” port between the Sierra code and the current kernel code. It works for me, on Ubuntu 13.04, with an Aircard 320U. Maybe it will work for you too?

I was briefly testing under Ubuntu 12.10, so I also ported to 3.6. I’ve also been able to use this code to run the Sierra on a RaspberryPi running Raspbian (kernel 3.6.y). Actually building the kernel modules was mildly inconvenient, instructions can be found on the internet.

I’ve been having a bit of browse through the forest of Open Source computer vision “applications” as of late. I quote “application” to mean packages with a high level of integration — either end-user applications, or high-level libraries which are one step from a demo application — in contrast to say, OpenCV or ANN which are very much at the nuts and bolts level.

I’ve made no effort to evaluate these packages, just to call out that they exist. I’m ambivalent to academic work which leads to large monolithic packages — I guess I just want things to be a bit more atomic so the quality visualizer from this project can be mated to the descriptor code from that project etc without completely knocking the two apart.

But on the other hand, these are wonderful repositories for knowledge and code — code for constructing and decomposing fundamental matrices, bundle adjustment, etc. There’s already far too much re-re-re-engineering of algorithms — although I’m as guilty as others, as re-implementation is a great way to learn an algorithm inside and out.

Of course, at this point I should mention OpenSLAM which aims to be a repository (in the philosophical and literal sense) for SLAM algorithms and test datasets.

Insight3d is a full 3D reconstruction application. Images in one side, point cloud (and geometric model?) out the other.

PTAM (Parallel Tracking and Mapping) is a SLAM-like toolkit/application designed for augmented reality, coming out of the Machine Vision group at Oxford.

I was flipping through an issue of New Scientist over lunch, and came across their Enigma column. It seemed like a pretty simple computational problem, so I thought I’d give it a try. Here’s the problem (link to New Scientist site):

Five integers

I have written down five single-digit positive integers.

The sum of the five integers is divisible by the fifth integer, but not by any of the first four. The sum of the first four integers is divisible by the fourth but not by any of the first three. The sum of the first three integers is divisible by the third but not by either of the first two. The sum of the first two integers is divisible by the second but not by the first.

List the five integers in the order in which I have written them down.

My code follows. It does the problem backwards, starting with a list of all 2-digit combinations, then deleting any that don’t meet the criteria. Then it expands the survivors to three digits, then eliminates any that don’t pass the test, etc. up to five digits.

I’ve just returned from three days at the IVCNZ 2011 (that’s Image and Vision Computing NZ) conference up in Auckland. It’s my first academic conference in a while (10+ years) and I’d have to say a good time had by all. It’s quite a small conference (~120 participants, one track), so it’s almost more of a club gathering than a conventional conference.

I’m trying to be good, working through my notes and whatnot.

Not 100% sure about the protocol when it comes to reproducing published material, so I won’t. Perhaps I’ll just give a shout-out to the presenters and material that caught my eye.