We have moved! Please visit us at ANTHROECOLOGY.ORG. This website is for archival purposes only.

Mar 30 2011

Python Success!

I (with the help of Jonathan) have sccessfully written the Python coordinate transformation program! This program uses the scipy optimization module to run a least squares function, which requires a function to calculate the residuals, an initial approximation for the unknowns, and our arbitrary and calculated X,Y,Z values as inputs. The least squares function returns the best approximation for the 7 unknown rotation, scaling, and translation parameters. Experiments with changing the initial approximation reveal a greater sensitivity of the rotation parameters, but good results are given when staying within a reasonable limit with the initial approximations.

Mar 17 2011

Microdrones on NPR

NPR just posted an interesting piece on drones- It's A Bird! It's A Plane! It's A Drone!  The piece highlights their growing popularity, the challenges of gaining FAA approval and interviews Chris Anderson of DIYDrones (and founder of Wired).

Hopefully this will stimulate the FAA to finally unleash the microdrone revolution!

Mar 15 2011

Noise Removal

Photoscan is demonstrably superior in many respects to Bundler, but it seems to have problems whenever the horizon is in the picture.  Silhouettes being incorrectly matched causes a lot of noise in the data.   What I ended up doing to deal with this was primarily based on computing nearest neighbor distance in Point Set -> Estimate Radius from Density filter, and then selecting and deleting points using the Selection -> Conditional Vertex Selection filter based on rad.  If the noise is significantly different in color, rad can be combined with spectral metrics from the r, g, and b variables to make equations like "(rad > 0.6) AND (b > 100)".

Here is the before and after comparison:

I've also prepared a video on the process:

Mar 15 2011

"Simple" Pointcloud Georeferencing

I'm aware that we have multiple transform optimization algorithms of varying completeness in the pipeline, but I decided to try and figure out the simplest means of georeferencing a pointcloud last night.  This is a crude, error-prone method that is only usable when flat ground can be identified.  It performs better when the flat area is large in both X and Y dimensions.  A warning - ArcGIS took tens of seconds to display and classify my pointcloud, and minutes to spatially adjust it.  Shut it down, and you may lose previous work, not just what you're currently doing.  Plan on this taking a while, and multitask.

1. Place readily identifiable markers in your sample area.

2. Take GPS points of those markers using an accurate, WAAS-corrected signal.

3. Take photos.

4. Synth photos.

5. Denoise synth.

6. Convert those GPS points to shapefile format.

7. In Meshlab's Render menu, select the bounding box and labelled axes.  Use the Normals, Curvatures & Orientation -> Transform: Rotate tool in Meshlab with the 'barycenter' option selected to rotate the synth until the flat ground is coplanar with at the X-Y plane.

8. Export the pointcloud as a .ply with non-binary(plaintext) encoding.

9. Rename the .ply to .txt extension.

10. Open the .txt file in Notepad.

11. Replace the header information with space-delimited 'x y z r g b alpha'  and save.

12. Open the .txt file in Excel as a space-delimited spreadsheet.

14. Save as a .csv file.

15. Open the .csv in your planning document in ArcMap, where you already have the GPS points open with UTM coordinate system.

16. Use 'Add XY data' and use the X and Y columns.

17. Right click on the new 'Events' layer and export it as a new shapefile.  Add it to your map.

18. Begin editing that new shapefile.

19. Symbolize the points by color or color ratios using R, G, B columns and cross-reference manually with Meshlab in order to locate your markers.

20. In column alpha (which should have the default value 255), set the marker points to 1.  Symbolize by alpha, unique categories, to make the markers stand out.  Save your edits.

21. Write down the X and Y coordinates of each marker after finding them using 'select by attributes'.

22. Enable the 'Spatial Adjustment' extension, put a check next to the similarity feature, and set adjust data to all features in your pointcloud layer.

23. Place a new displacement link for each marker with the first end at your marker in the pointcloud, and the other end at the corresponding GPS marker in ArcGIS.

24. Hit the 'Adjust' button. 

25. Save your edits and stop editing.

26. Optional: Use SQRT(X^2+Y^2) to determine the distance between two markers in your original coordinate system.  Use the ruler to detemine the distance between them in UTM.  Using the field calculator, multiply the Z factor by the ratio of UTM distance to pointcloud distance.

Mar 15 2011

Learning Photoscan

I've really gotten my hands dirty in Photoscan this past week.  I've learned a number of things:

  • A periodic sampling regime ("Every third photo", etc) can produce a *SUBSTANTIALLY* worse pointcloud than every-photo for complex surfaces.  Simple surfaces aren't affected as much.  This could be applied selectively to cut down on runtime.
  • The "Estimating Scene Structure" time remaining display is only useful as a minimum bound, and may be 10-100x what is currently displayed.  The other estimators seem to be accurate.
  • Due to speed penalties at high imagecounts, choosing image subsets is going to play a very important role in synthing areas of interest, and we need to develop better methods for this.
  • Paused photoscan has a 'sleep mode' where it shifts down to a fraction of the memory (10GB -> 1.3GB) and no CPU, but it needs 10 or 15 minutes to enter it after pause is initiated, and uses full memory and 95% CPU during that time.
  • Tree trunks are readily identifiable in Photoscan given full-resolution pictures and a rapid frame rate, but care must be taken during turns to unify the synth using extra pictures
  • For small image sets, periodic subsetting (every other picture) may be attempted, and then supplemented with extra information in corners.
  • Photoscan is relatively noise-free for aerial photos, but anything that includes the sky will cause serious noise problems on silhouettes - points of sky and tree will appear in a distinctive projected pattern in what should be air.  Photosynth does not suffer from these problems.
  • Markers need to be sizable and textured to be seen in a synth.  Strings don't come close to working, though their directionality is very useful for walking consistant transects without good visibility.  The pin flags work very occasionally, but it would probable be better adding flat, 8.5x11 textured bullseyes as well.  GPSing those markers gets you a crude georeferencing, but in small forested transects this is not very useful due to the error bounds on the GPS.  Increasing the lateral dimension of the synth using a cross transect would make georeferencing much easier.
  • Symmetrically cropping the edges out of pictures (keeping the same centerpoint) can be an effective way to cut down noise and processing time in a camera held in a constant orientation.  Removing the top and bottom significantly decreased sky noise and processing time on a test dataset.
  • Our tree database is not very accurate.  It's missing stems < 12cm, but even the big ones are very hard to locate in the synth using relative positions.  A set of 'reference trees' would be very helpful here as a complement to GPS markers.
Mar 14 2011

Getting Friendly With Python

We made great process today on our Python coordinate transformation algorithm. We are using scipy and the optimization module to find the best approximation for our transformation parameters, and are almost done finding a solution. Much thanks to Jonathan for being super helpful!

Mar 05 2011

Field Day with the 485 Class

We had a great field day with the GES 485 class on Saturday flying the Hexakopter at the Herbert Run site and developing field work and 'ground-synthing' techniques.

The weather was actually quite good for a data collection.  The sky was overcast and there was no wind, meaning that the Hexakopter was able to stay on track and the light was relatively diffuse so there are few shadows in the images.  I gave a large set of about 2000 photos to Photoscan for processing on Saturday afternoon and it is still running.  This is a great software, but I don't yet have enough of my own benchmarking data with large sets to really test out how it is going to work. I hope the point cloud looks good!

Regarding our Xbee testing, I used the MKUSB to upload waypoints, but then discovered that when I power down and then power back up to swap out the battery and plug in the wireless Xbee module I cannot read waypoints from the MK, or they are not stored on board.  But, I was able to upload waypoints wirelessly with the new Xbee configuration and the real-time telemetry communication during the flight was OK.  At least the current setup is no worse than what we had before.  More to come.

Mar 03 2011

New Field Equipment for 3D Forestry

Our new forestry mapping equipment is going to make collecting 3D tree and canopy data a lot easier!

We recently acquired a Trimble GeoXT GPS and TruPulse 360B laser range-finder for use in our forestry field data collection work.  The GeoXT is a high grade mobile-mapping, mobile GIS, GPS unit that offers sub-meter accuracy after post-processing in the lab. 

By itself this would allow us to collect sub-meter (0.5m – 0.7m) accurate positions of tree trunks or other features on the ground.  The TruPulse is used for measuring distances and heights using a built in laser and inclinometer that automatically does all that pesky math that would be needed when using an analog clinometer.  The 360B model has built in Bluetooth communication, which means that with a little configuration in the lab the unit can wirelessly beam positional and height data to the GeoXT.

This combo is used for ‘offset-mapping’ where the user stands in one location with both GPS and laser in hand and by using the laser is able to map to the GPS the XYZ position of other objects that are not nearby (typically less than 200m based on the power of the laser).  For us, this means I can map the position of tree tops in 3D space and automatically record the tree height to the mapping GPS with relative ease and greater precision than when using paper and pencil field notes.  This type of data collection is necessary for the calibration and validation of Ecosynth 3D point clouds, http://ecotope.org/ecosynth/methods/ecology/.

We will roll out this tech in the field in the coming few weeks as we move into the growing season, but in the mean time my initial results suggest that this will be a high-quality approach for mapping the position of tree crowns, a vital and challenging task.

The photo below doesn’t look like much, but it shows a sample of some of this 3D data.  This is an oblique shot looking through a 3D point cloud of the Knoll at UMBC.  The yellow area at the bottom is a digital terrain model of the land underneath the canopy; the blue points are the Ecosynth 3D point cloud of the site; and the red points are 3D points of tree tops and tree base mapped using the GPS  / laser combination.  This screen capture doesn’t do it justice, but trust me when I say that it looks good in 3D!

Hey Evan, are you sure you don’t want to come back to continue the forestry work?

Mar 03 2011

Camera Constraints - Testing to failure

Ground synthing development is going to require lots of pictures, and given a team of volunteers it is going to require coordinating picture-taking to an unprecedented degree.  In order to plan our workflow, we need to know how long the cameras can remain in continuous shooting mode.  In order to figure this out, I decided to run the two primary models of camera we are currently using, the Canon SD4000 IS and the Casio Exilim EX-FS10, in continuous mode until they failed.

Both cameras were set to ISO 200, maximum resolution, fine compression JPEG.

Here are the results:


Canon SD4000 IS

  • *6186 photos, 12.0 gigabytes
  • *155 photos per minute
  • *Battery fails at 40 minutes shooting time, 16GB card has enough space for 48 minutes shooting time


Casio Exilim EX-FS10

  • *5937 photos, 9.8 gigabytes
  • *84 photos per minute
  • *Battery fails at 71 minutes shooting time, 16GB card has enough space for 106 minutes shooting time
Mar 02 2011

Xbee Solutions?

Is the solution to our Xbee problems to not use them at all?

You may recall several posts and rants about our problems with Xbees, http://ecotope.org/ecosynth/blog/?tag=/XBee, and we have been actively looking for a solution.  The picture at left shows a potential new system for transferring data from the field computer to the Hexakopter on the ground and then in the air.  In this picture is the Mikrokopter MKUSB module that is used for hard-wired USB data communication between the Hexakopter and the Mikrokopter tool software; a new Sparkfun USB Explorer Regulated board; 2 Digikey Xbee Pro 900 modules; and a Sparkfun Xbee Explorer USB module.

The plan is to use the MKUSB module to upload waypoints and control settings to the Hexa prior to flight, then pop on the Xbee wireless configuration for spotty telemetry during flight.

Our problem for months now has been very unpredictable performance with the Xbees for wireless telemetry communication.  The set up was: 2 Xbee Pro 900’s both mounted to Sparkfun Xbee Explorer USB modules.  One Explorer USB was set up for USB communication with the laptop (the module shown at right in the image) and one Explorer USB had a ribbon cable soldered to it for plugging into the Hexa (image not shown).  At first, this seemed to work OK, but for some very odd reason, this set up started failing, to the point where it was impossible to wirelessly upload waypoints to the Hexa from the laptop within just a few feet of the unit.  I do not want to think about the countless hours wasted on this.

This new setup aims to 1) circumvent the need to us Xbees for mission critical steps (waypoint and configuration upload) and 2) use a different hardware configuration to attempt to re-establish successful wireless telemetry communication using Xbees during flight.

We will use the MKUSB in the field to transmit waypoints and configuration settings to the Hexa via wired communication and then use the Sparkfun / Digikey configuration shown above for getting what wireless telemetry data we can during flight (with the assumption that the Xbees will still fail or be spotty).  Sparkfun recommends this configuration over the use of 2 Explorer USB modules and we are not entirely sure why we have the configuration that we have been using.

With a leaf-off flight planned for the UMBC Herbert Run site on Saturday, I hope to have some positive results to report next week!