[UPDATE: I've found an even better way that costs $25, is simpler and works perfectly. It's here]
Once again I started a weekend with a crazy idea and once again I had it working by Sunday evening. (Needless to say I'm not going to win any parenting award until this particular obsession runs its course). This time it was trying to resolve a problem that cropped up in our Googleplex UAV mission. Many of the photos from that series are from angles, rather than straight down as you'd want for Google Maps imagery, because the airplane was banking quite a lot to keep within the boundaries of the Google campus.
The aerial photography pros solve this problem with expensive gyro-stabilized camera platforms. But to keep to our credo of making UAVs as cheap and easy as possible, I used stuff lying around the house to make a totally functional gyro-stabilized camera mount for less than $100.
The secret ingredient is an off-the-shelf "heading hold" gyro made for a R/C helicopter. These can be found for as little as $40, but after some experimentation I found that you need one that has special circuitry to resist gyro drift (there are several of them here, ranging from $74 to $199. I'm going to test several of them to find the cheapest one that works; right now I'm using one I had that doesn't have drift cancellation and it won't work for anything but benchtop tests).
UPDATE: the test is here.
For the tilting camera mount and base, you'll need a sheet of relatively thin aluminum. I used a .032 X 6 X 12 sheet. Anything thicker won't bend properly. I cut out several prototypes from cardboard before committing to metal (and still had to do the metal twice, when the first sheet proved to be too thick). I've made a pdf that you can print out and use as a template (when printing, set "page scaling" to "none" so it prints full-size). This one was designed for a Canon Digital Elph camera (all the recent vintages, from the 500 to 900 series, are about the same size); if you're using a different camera you may need to modify some dimensions slightly to fit. More pictures to help you with bending are here.
One of the other problems that cropped up on the Googleplex mission was that we needed to take pictures much faster--at least twice a second. That means putting the camera in "continuous shooting" mode, which unfortunately can't be triggered with the computer-controlled IR trigger we used on the Pentax. So I also included a mechanical shutter switch, which is the blue servo in the top picture. It just holds the shutter down when activated, either by the on-board computer or manually with a switch on the R/C transmitter.
Here's a video of the whole thing at work, strapped to the bottom of our Predator UAV:
Comments
Unfortunately, this is much, much more complicated than ground plane stitching. To my knowledge, there are no commercial tools to do 3D reconstruction from a monocular camera. MDA (a Canadian space/robot firm) has licensed tech from EvolutionRobotics that uses SIFT feature matching to do 3D reconstruction. It is highly dependent on stereo imagery.
Here is an example [PDF]:
www.cs.ubc.ca/spider/se/papers/icra06.pdf
Note again, this is useless for high altitude. There just aren't enough pixels or varying perspective to get the 3D
A mount that allowed for a "rolling" camera, with a dropped weight large enough, might tend to point down as much as you need. Adding some damping might be enough to prevent wind and vibe from shaking the camera around.
http://www.ptgui.com/
"Cool thing. But didn't you forget the instability of the plane around the pitch axis?"
My answer:
Not forgotten at all, just not solved yet! Although in practice the tilting problem is much worse along the roll axis (which we have solved) than the pitch axis. That's because the plane doesn't have to pitch to turn and it's inherently more stable along that axis because of the conventional wing-and-elevator configuration (a flying wing would be tougher).
Also, the good thing about any instability around the pitch axis is that it leads to tilting that's along the path of the plane. So when the software tries to stitch the images together to make the strips that we mosaic to create an overhead map, it can at least find feature overlaps from adjacent images, even if they've been pitch tilted (they're either where we're going to be shortly or where we've just been). That's not the case if they've been roll tilted, since those images tend to be off to one side or the other.
Make sense?
-c