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

Feb 29 2012


I found that I might be able to create my own control points if I use the resection function of the total station. Basically what the instrument does is it takes multiple measurements  between two points from a central travers set up. Then what it does is it takes the standard deviation of all those points. From there if there was a measurement that has a particuarly high sigma you can throw it out. this technique will make throwing my own control points easier hopefully since I am already have a useful set of reference control points.  The problem I was having with setting up my own control points before was that I had nothing to go off of except assumed coordinates which have to eventually be rotated onto UTM coordinates in order to actually have  been able to do any of the stake out that we have so far.

Feb 29 2012

64-bit Python Computing

Recently I ran into a memory problem running large point cloud arrays through Python and Numpy.  I quickly determined that I was asking Numpy to work on massive arrays that were exceeding the limits of the 32-bit Python process in Windows.  I came up with a workaround whereby I truncate the UTM X-Y coordinate information so I can store the numbers as 32-bit floating point values without losing precision, then add the extra numbers back at the end.  Basically, I translated the X-Y coordinates (352845.49 4346713.91 --> 2845.49 6713.91) then back again to the original UTM values after computation.  This was OK, but I wanted to overcome the 32-bit limit in Python.

There are unofficial 64-bit builds available here, but I wanted to try something established.  I got one of our machines running dual-boot Windows 7 / Ubuntu 11.10 64-bit and compiled all the Python, Scipy, and Numpy libs in Ubuntu.  These builds are inherently 64-bit because of the 64-bit OS install, so there are no issues with addressing large arrays of data.  Back to work!

Feb 27 2012

SERC Leaf-off Hexakopter Mission

This past Sunday (2/26/2012) Jonathan, Shelby, and I went to the Smithsonian Environmental Research Center to fly a hexakopter mission during leaf-off.  The image on the left was taken by the camera mounted to "Sally" as it was coming in for a landing.

Since "Raven" still has what we believe is a motor controller issue (contacting Nisarg about this), we brought "Roflkopter and "Sally" to SERC.  Initially "Roflkopter" was designated the primary flight hexakopter, because "Sally" had been noticed as having stripped threads on one of the propeller mounts on top of a motor.  Since the other two holes in the propeller mount were not stripped, we still considered "Sally" flightworthy, just not primary.

Once on site, Shelby and I set up a series of twelve orange contractor buckets along the road through the forest we were surveying.  Jonathan had programmed the rough distribution of them into the dog-tracker GPS to follow when we were setting them out.  Then throughout the rest of the day during flights and other work, we used a handheld GPS tool to determine the precise coordinates of each bucket.  These coordinates will be applied to the buckets in the point cloud representation.

As it turned out, "Roflkopter" was not our best choice for primary hexakopter.  Although it was certainly flightworthy, during flight it bobbed up and down instead of flying in a straight line.  Jonathan believes it is due to the hexakopter's vertical lock setting being miscalibrated or otherwise dysfunctional. 

We decided to fly "Sally" to see if we could collect data from a smooth flight.  After some test flights, we determined that the stripped screw on "Sally's" propeller mount was not going to be an issue this mission, although it will still be replaced.  On "Sally's" first mission, everything seemed to go well but when it returned the camera had run out of battery.  This was odd since the battery we used was most definitely fresh.  The camera did not seem to respond well to new batteries either, so we flagged it for later investigation and switched to a new camera.  Finally, "Sally" flew a successful flight and collected what looks like it will be a complete set of pictures of the forest canopy.

Feb 20 2012

Week of 2/13/2012: Flying the hexakoptors and surveying in Herbert Run

This week Stephen and I finally got to fly the hexakoptors.  It did not take long for us to realize that it is rather difficult to learn to fly them.  We will be practicing on flight simulators before we take the hexakoptors out again.

During the weekend, Andrew and I went to Herbert Run and surveyed the area to make a grid.  We accomplished to get a fourth of all of the points done!  Hopefully we can be as progressive in weeks to come.

Picture 1: Hexakoptor in flight.


Picture 2: Me after a day of surveying.

Feb 18 2012

New Undergrads learn the ropes of flying the Hexakopter

Shelby and I are the new mechE undergraduates for the Ecosynth project.  This past week we started learning the ropes to flying the hexakopters.  We started by bringing all three hexacopters to flight-readiness.  "Sally" was already operational, so we used her a s a model for repairing the other two. 

When we started, "Raven" needed new propellers as well as ribbon cables.  "Roflkopter" (I'm very fond of that name) needed its computer reassembled and mounted, as well as new propellers and the arms secured on.  Shelby and I did these repairs with little prior experience, so we were actually a bit surprised when both "Raven" and "Roflkopter" flew successfully.

By the time we finished, none of the three hexacopters were flight-ready any more.  The attached video is actually my one successful landing, the hexakopter controls take a lot of finesse and a lot of practice.  I managed to break a propeller on "Sally" by tipping over on landing, and Shelby managed to break "Roflkopter" 's landing gear with a hard landing.  "Raven" stopped working because of an issue with one of the motor controllers.  We took it back to the lab for analysis, but we called it a day and decided to reconvene next week.

Shelby and I are looking forward to working with these hexakopters and the Ecosynth team.

Feb 14 2012

Surveying Friday 02/10/2012 with Kelly and Eric.

Today Eric and Kelly were able to accompany me in the field work. While we were out we were able to get 3 points layed out, determine a need for extra control and trouble shoot with instrument operations.

Surveying the first two points went just fine, but after the first two were staked out, I ran into a technical error that is best explained as the instrument was telling me to put the points in the wrong place 61 degrees away from where the points were supposed to go. It seems that whenever I want to re-establish my base line of 0 degrees, this particular instrument does not want me to do that. The only way to re-establish my baseline, or the line that I base all the other measurements with, is by completely re-entering the baseline station data. From now on this is what I will do to keep from wasting any more time.

Never the less we were able to stake-out three more points on the far east side of the Herbert run site. We had to do an offset for point number 152 because it was in the stream. What we did to obtain this point were two offsets one 7.12 m off of the point on the east side of the stream and another 2.68m off of the point on the west side of the stream. These two points are in line with each other and  if you pull an meter tape from one point toward the other the given distance for the offset you will be right on top of the point.

The first point 146 on the tree sampling grid, which was staked out the Friday 02/03/2012 prior to this one ended up 7 cm off. I am going to go ahead and wait till the grid is complete to restake this point out because it might be able to use a measuring tape instead of the total station.

Feb 01 2012

Some Thoughts on Fixing the Helmert Problem

I've gotten to a point where I think I understand what our coordinate transform code has been doing wrong, and how to fix it.

1. We start with our object, as it appears to us.

2. Because the Z variation is very low, it does not constrain the Helmert optimization process from picking a negative scale.  As it stands, if you take perfectly precise/accurate GCPs, and a perfect pointcloud, and try to fit it, there is a bifurcated optimization: half the time you end up with a perfect fit, half the time you end up with a good fit that inverts Z values.  A negatively-scaled pointcloud will be proportional, but chirally incorrect: There is no way to rotate it to fit it to the actual reference points.  It is "backwards".

3. Absent a significant Z variation, if the optimization ends up on the negative scale end, it will fit the points by rotating them so that the ground plane approximately matches, which will be approximately 180 degrees about the Z axis (blue in this diagram).

4. We do have a way to detect this and flat-out reject it (the scale parameter being negative), but as flawed as they are, these initial parameters accomplish an important task: they select a somewhat accurate up-down axis, and they determine the approximate magnitude of the scale.  Therefore, it is preferable to fix the fit rather than throwing it away.

To fix it, we can do some of the steps of the transform in reverse, without any optimization.

5. First, apply the Helmert transform parameters we initially determined.  Then, if the transform is negative, apply additional steps.

6. Step A) Apply a scale transform of negative 1.

7. Step B) Apply a 180 degree rotation about the Z axis.

8. Step C) Recenter based on centroid translation to get an approximate fit to reality.

 9. Step D) Run the Helmert optimization again.  With the residuals already minimized by a mostly well-fit system, it is unlikely to iteratively choose a negative scale again, but will tweak the rotation and translation to line things up closely.

Feb 01 2012

Ballon Aerial Photography, GoPro's and Photoscan

I stumbled on the website of a researcher Paul Illsley from Nova Scotia that works on remote sensing and has a hobby of photography.  He has a nice website description of a balloon aerial photography system and techniques for working with different cameras, including a GoPro Hero.  The picture at left shows a model he generated in Photoscan from a balloon survey of a building.  He suggests a technique for removing the GoPro lens distortion that I will definitely have to try out.

Photo source: http://www.paulillsley.com/airphoto/systems/B.jpg