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


Oct 22 2010

Weekly Flight Progress (Week of 10/17/10)

This past week I got in 3 good flights at UMBC and New Jersey and learned a lot more about how to get things working well.

The first flight was at the pine barrens site in Pemberton, NJ.  I arrived at the site on Saturday to scout things out.  I met the local forest researcher Ken Clark and he showed me around the plot where I would be flying and we checked out the forest from atop a modular tower used for making meteorological measurements; I was not crazy about climbing the tower, but Ken had no problem.  I was up at 6am Sunday and at the site by 7:30.  By about 8am I had inflated all of my new huge 3' diameter balloons and set out to place these new aerial markers in the field.  This ended up working pretty well, although I think I put a tiny hole in one balloon and several balloons popped between the time I set them up and when I went to retrieve them.  It was gusting to about 13mph (according to the local met data, thanks Ken!) and the balloons blew around and into the trees throughout the morning.  Overall the flight went well, but I think that because of the gusty winds, the Hexa got blown of course several times and we may have issues with image overlap during the 3D reconstruction. Site prep took about 3 hours as it was more challenging to place the balloons in the field than when I am just using buckets on the ground.

The next flights were both on Thursday at the UMBC Herbert Run location.  I had everything set up by about 11am and then commenced with flight testing.  I think it is a good idea to use a spare battery for testing out the flying conditions on site prior to the actual image collection mission.  I found that the GPS and altitude were holding well, but that it was still quite windy.  At this site I use buckets instead of balloons as they are more stable and there are more open areas to place the buckets.  Things went well on the first flight, but the Xbee inexplicably cut out quite often.  I thought it was odd that the Xbee cut out so frequently because there was almost no data connection problem at the New Jersey site earlier in the week.  Also, it was apparent from the Garmin Astro track that the route was being affected by the wind.  I landed the unit after the flight and swapped in a new lipo, new camera battery and new camera memory card and proceeded with another flight at an altitude 40m above the first flight and along the same route.  The track of this flight showed a similar pattern as the previous one.  I posted more about the flight paths and looking at the tracks in an earlier post this week, here.  In all I got in two full flights in under an hour, by myself, with about one hour site prep. 

 

In summary, I had three good flights this week that I setup and flew on my own.  It looks like at each flight winds above 13 mph may have caused the Hexa to deviate from the flight path, hopefully not to the detriment of image overlap.  I think the procedure for preparing gear and setting up the site is finally getting honed down to a smooth operation.  And thank goodness for my station wagon!

Oct 19 2010

Flight Telemetry Data and Monitoring the Flight

We recently learned about the robust telemetry data that the Flight Control board creates when a MicroSD card is plugged into the onboard slot.  Since then we have always flown with the card in to capture the telemetry data and it is proving to be an invaluable part of the post-flight assessment process.

The next steps will require a *simple* GIS workflow to evaluate whether the actually flown path sufficiently matches the pre-planned path to provide the necessary image sidelap and endlap for 3D reconstruction.  

We have already seen first hand how deviations in the fight plan tracks result in gaps in the vision reconstruction and also how mis-aligned platform orientation results in gaps as well.  At a flight at SERC the platform and camera where oriented 90 degrees from the path of travel, resulting in no sidelap between parallel tracks, link to Photosynth.  At a recent flight in New Jersey the wind blew the little guy around a lot and even though the camera orientation was spot on, the width between some parallel tracks exceeded our flight plan for achieving side lap, again resulting in large scan gaps, link to Photosynth.

So what does this mean?  It is necessary not only to have spot-on preparation of camera orientation and flight planning prior to flight, but it will be necessary to run diagnostics in the field to evaluate whether the route flown was sufficient for 3D reconstruction.  I wrote a simple python script to translate the Mikrokopter GPX telemetry data into a text file for use in a spreadsheet or GIS program.  By doing this we can look at characteristics of the flight system through time (e.g., battery voltage vs. flight time) or space (e.g., Navi-Ctl status messages at each GPS point along the flight path).  The Python script that translates Mikrokopter GPX telemetry data to a text file is located on our Coding Corner page.

Oct 19 2010

The "Ups" and "Downs" of Remote Sensing with the Mikrokopter

DRAFT: We have had great successes with the Mikrokopter Hexakopter for collecting digital photos for 3D computer vision reconstruction, but there are still many challenges yet to be overcome. 

We are now able to plan a flight with GIS to cover a particular 250m x 250m area with a desired amount of image overlap and translate that into a flight plan for the Mikrokopter to follow.  We have successfully demonstrated this at each site, however some other complications have become apparent. 

One challenge that remains is the control of camera exposure.  I purchased a camera calibration card a few weeks ago and have incorporated that into the pre-flight checklist, but that technique is not quite perfected.   

Sep 21 2010

You've got to let the little guy's leash out!

This afternoon I worked with Nisarg to better understand how to setup a path for collecting aerial photos with the Hexakopter.  We quickly found that doing so would not be difficult and that adding our own custom waypoint list to the Mikrotool was straightforward.  However, during the fligh test we learned about an important setting to be aware of in the Navi-Ctl that really limited our test today.  By changing the settings as described below, we should be out flying over the entire Knoll in no time!  I think Nisarg is going to post later about the Mikrotool Map software that he was working with that provides an easy system for getting a Google Earth image into the Mikrotool OSD.

 

In testing our waypoint options, Nisarg was able to create an output text file (a .wpl file) of the Mikrotool OSD waypoints.  The file looks like this:

[General]
FileVersion=1
NumberOfWaypoints=10
[Waypoint0]
Latitude=39.253988
Longitude=-76.71177
Radius=10
DelayTime=1
[Waypoint1]
Latitude=39.251826
Longitude=-76.711718
Radius=10
DelayTime=1
[Waypoint2]
...
...

I looked at that and thought, “Well I can make that!” and set about generating a waypoint file over a route we wanted to fly for the Knoll site on campus in ArcGIS.  We had been discussing flight strategies and how to achieve image overlap and I showed Nisarg and Garrett a little bit of the kind of map making and simple spatial functions that can be done in ArcGIS: Garrett seemed more impressed than Nisarg.  I have been consulting Elements of Photogrammetry a lot recently for flight planning and also some simple calculations I made of the amount of overlap and area observed by a camera at a given height above the ground surface. I will be posting more about that later.

Anyway.  We came up with the a simple parallel grid track for the Hexakopter to navigate over the Knoll with 50m spacing between tracks.  I estimated that at about 70m altitude from the ground (@ Home) I would achieve the desired overlap even over the Knoll and trees. We went outside with the gear, climbed up to the top of the parking garage and went for it.  We also had a Garmin Edge GPS attached to the top of the dome to provide a track of where the little guy was going: not sure if the MKGPS can record tracks.  From the beginning it seemed like something was wrong.  It was kind of flying in the correct pattern, but it did not seem like it was going far enough across the forest.  We brought it back down and took a look at the GPS track.

As you can see in this somewhat messy image, the little guy did not go exactly where we wanted him to. 

A brief legend:

  • - Blue lines are the intended route
  • - Green dots are the intended waypoints given to the Mikrokopter
  • - House symbol is flight home
  • - Large yellow arc is a 250m buffer around the quad, more on this below
  • - Small yellow circle is a 100m buffer around fight home

So what happened?  The Hexakopter tried its best to fly those waypoints, but kept hitting an invisible wall and was forced to come back.  The units come preset with a GPS maximum range of 100m.  So our guy was flying his path, hit that 100m mark and was deflected along his route without hitting all the points.  Through a bit of research we came across the issue on the forums, http://forum.mikrokopter.de/topic-13563.html, and the solution on the Wiki (linked from the forums): http://www.mikrokopter.de/ucwiki/MK-Parameter/Navi-Ctrl_2 .

The units still will not fly beyond 250m with GPS with the current setup.  We thought that this was the default setting and hence set up our route to fly at max 250m across the Knoll from an intended Home in the quad, that is why the larger yellow arc is not centered. 

From here we are going to update the Navi-Ctl setting to allow us to fly to the max 250m from home and I am going to put together a small script in Python to turn an ArcGIS point file table into the waypoint format needed for the Mikrotool…but maybe not by Friday!

refs: Wolf, P., DeWitt, B., 2000. Elements of Photogrammetry with Applications in GIS 3rd Edition, McGraw Hill.