No good turns and multiple looks

One of the things we have been working on this summer is bringing online the fixed wing sUAS, variously known as The Catfish, Mr. Chow, Local Hawk, or simply "the fixie".  It is a foray into more travelled ground for sUAS in general than DeaconEye, but it brings with it a new set of problems for image analysis.  New cameras to be triggered, and new ways that imagery varies among missions to deal with.  One of the things that is very clearly different is that the fixie doesn't "mow the lawn" like a copter.  Turns put the un-gimbaled camera out of angle enough that we're not mowing, we're farming.  And when you're sowing, your turns at the end of the field are out of bounds--you use them to get the machinery turned around for the straight rows--and then you come back and plant the edges.  That's what we need to do with Local Hawk.  Set the straight parts of the flight plan to capture the imagery, and make the turns out of the desired scenes.

More generally, it'd be nice to start a set of python scripts for our image workflow that looks at the EXIF information and automatically leaves out pictures beyond a predefined bounding box for the imagery, and, given some of the severe cross-tracking in high  winds and roll during gusts, takes out images with high yaw
and roll values.  And, while we're wishing, it would be good to use the camera information, the plane position information, and the Maxwell Equations to generate footprints for each image and maps of the along-track and cross-track overlap.  When we are back in the lab puzzling over a gap in the DEM, or a failure to compute some 3D solutions, it'd be good to narrow down the likely areas causing the problem rather than relying on prejudice and voodoo to optimize the data products.

Of course, if one isn't limited by computing power, the other thing to do would be to fly every mission twice along  at least two different paths.  This "multilooked" imagery is important for radar remote sensing, allowing precise solutions for the geometric problems that arise.  Given the way that SfM techniques reconstruct pixel locations, our cross- and along-track overlaps might be enough, but another set of looks might be worthwhile.  Better to throw out information than to have to go back and get it.

But the big caveat stated above is that we're not limited by computing power.  Which has decidedly not been the case.  Which is why we created Big Deac, but that's another post altogether.