Great stuff!

I'm creating some torrents of the images I ended up with ...

Update: I've linked to torrents of the image files (and instructions for downloading them) at the H20NUTZ wiki page, here: http://publiclab.org/wiki/waterchestnuts

Nice work, all. It will be interesting to see the followup results. I was also interested in the details on: - construction of the HackrBlimp; is that a fill tube, shown at the end? Brief description of materials and assembly would be of general interest. DIY schematics would be neat. - Helium supply and availability observations, were you able to get it on short notice for your flight, or did you have it cached from before? - camera(s) connection to HackrBlimp or line and rigging details, e.g., use of the four connection points. - gps considerations; sounds like it was with Chris on the ground. Was there a constraint that prevented you from flying another gps with the cameras?

Thanks for sharing these nice results.

Pat, I agree that details of the construction of the HackrBlimp would be of interest. That blimp cost less than US$10 and performed very well in some windy conditions. The seams are quite strong. I have some photos if someone wants to use them in a note. I did not hear the final cost of helium, but it sounded like a filling of the 5+ foot diameter neoprene balloon cost about $40 and had great lift with a dual camera rig. I did not sense that it was hard to procure helium.

The reason we did not fly a GPS with the cameras is than Don did not offer his Garmin watch!! Having the 3D track of the balloon path is very cool, but I fail to see how the data could be used in any meaningful way. On the other hand, having a good GPS track of something on the ground that is visible in the air photos could allow better geolocation of the photos.

Hi Pat, Chris,

Chris: it'd be good to grab any additional photos you have of the blimp -- we can post those in a research note soon, as well as details re: the seams and the rigging.

The cost of helium was $50 for an 80 cu ft tank (plus a $100 deposit); we went through a local supply company (Ivey Industries) that was able to provide helium with a few days' notice (and I think they would've provided it on yet shorter notice).

Chris -- alas, my Garmin watch was in a box nearby, eager to fly, but forgotten by me. Next time!

Re: GPS data -- I just grabbed these boards from Adafruit: an RGB color sensor (http://www.adafruit.com/products/1334), as well as a sensor that has both full-spectrum and infrared diodes (http://learn.adafruit.com/tsl2561). I also have a GPS breakout board (http://learn.adafruit.com/adafruit-ultimate-gps). Would it be useful for calibrating & geo-referencing these photos to have an Arduino-based prototype that e.g. records GPS as well as R,G,B, NIR sensor data?

Thanks guys, sounds like more will be coming soon and we'll all welcome the results.

Don, I think it would be very useful to have an an Arduino-based prototype that records GPS as well as R,G,B, NIR sensor data.

Re: why fly a gps? While it is different from the the artisanal, hand-crafted maps we make with Mapknitter or desktop tools like PhotoShop, there are at least two cloud-based for-fee services that take sets of geotagged images and produce georeferenced maps and digital elevation models, e.g., Dronemapper.com and Pix4d.com. For some users, willing to pay, this approach can enable them to quickly get map results of their flights.

Glad to hear you can get helium, essentially on demand. Hasn't been that way in the Bay area, but I haven't checked recently.

Hi,

Re a GPS on board with the cameras, I'm trying to understand how one would use that to georeference an image in GIS with good accuracy. I'm used to the traditional GIS georectification method where you have ground control points (at least four, hopefully more) that are in different locations on the image. So how would the GPS on the side work? I guess it would be associated with the pixel in the center of the image?

-- Charlie Schweik, UMass Amherst

Charlie, Some of the structure from motion programs that make 3D terrain models from aerial photos do not need any input other than the photos themselves (maybe including some EXIF data about the lens). These can take a long time to figure out how the photos overlap and eventually where the camera was for each photo. It took several hours to process the 76 photos for this model. If you give the program a hint about where the camera was for each photo, it can reduce computation time. I don't know how much this can improve the final result, because all the programs have to figure out the camera positions and orientations one way or another. But some programs will not work without GPS data for the camera for each shot. Pat, do those programs want x,y,z data? Do some also want orientation data (which way the camera was pointed)? Do these programs all make 3D models or is GPS data also used to make 2D maps from the air photos? Automatically stitching air photos into 2D maps with good ground control (georeferencing) would be an important advance over Microsoft ICE which does a good job stitching but can freely distort the photos to get them to stitch with no regard for geography.

Chris, I'm not a expert user of the two cloudbased services, Dronemapper.com and Pix4d.com. I've only processed test cases. Pix4d.com, used to want the orientation data, but has relaxed the requirement. So both now accept images with the gps info coded into the EXIF info. Both make geo-referenced 2D mosaics and 3D surface models (with additional charges for the 3D models). These are not for everyone, but to me indicate where the professional surveying approach is going - fly the site, autoprocess the images, produce the map and model. There has been some discussion with Stewart and Jeff about whether our tools like Mapknitter could exploit the gps info, but not toward autoprocessing. To me, it's just another tool in the kit.