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

May 01 2012

New 3DR Radio Telemetry System


The 3DR radio telemetry system looks very promising!  It is intended to be an improved replacement for xBee radios.  We ordered a set as soon as we heard about them.  With improved performance specs and compatibility with Ardupilot, these radios look like they'll be flying on the next generation of Ecosynth aircraft.

In addition to these radios being specced better than the xBees, we'll be using them with directional antennas (the one on the ground station will point towards the sky; the one on the aircraft will be pointed down towards the earth).  We've always had trouble with xBee communication; even during standard flights the xBees are spotty at best once the kopter is up in the air.  These radios should be a welcome improvement. 

Update: 3DR Radios have come in, and they have been successful in connecting the arducopter to the ground station in the lab.  A flight test will follow soon.

Jul 18 2011

XBees Again

I think I have fixed the XBees, again, maybe…

I wanted to get our tablet laptop up and running again as a Hexakopter flying machine for the field – especially since I got the new Pentax WG-1 GPS camera in the mail today (I’ll post on that soon).  This laptop had already been running Mikrokopter-Tool v1.74a, allowing us to do 3D waypoint runs, but the XBees were not functioning at all.  I also had it in my head to install a SSD hard drive in this old laptop to give it a new lease on life – what better opportunity to try a fresh setup! 

A quick note to anyone that has found their way here with their own XBee woes, we are using XBee Pro DigiMesh 900 modules.  This post discusses the (hopefully) successful configuration of a pair of XBee Pro 900’s each mounted on an Xbee Explorer USB.  In a previous post, Xbee Solutions?, I suggested that it is necessary to have an Xbee Explorer Regulated on the MK end, but it seems that may not be necessary based on the results described below.

I got all the standard drivers and software installed and running (XCTU and  UART drivers) and plugged in the suspect Xbees.  Windows 7 said it correctly installed the new hardware, but when I opened up MikroKopter Tool I could not get any XBee communication. AAAAAAAH!

Back to the internet, I found this long thread about Xbee problems that offered promise: http://forum.mikrokopter.de/topic-21969.html

Taking from the thread, I set up two XBees on the same machine in two instances of XCTU to be able to effectively range test and compare parameters. Why had I never thought of that!? I read the modem configurations from each unit – mostly noting anything that was other than the default and confirming the baud rates were set correctly.  I quickly noted that the Modem VID numbers were different and read from the help dialog: “Only radio modems with matching VIDs can communicate with each other.”  One XBee was set to the default and another was set to a specific number.  I didn’t remember making this change but decided to set them both to the same number.  The range test was now working perfectly (see post picture).  Back in Mikrokopter Tool I was back in business with wireless telemetry, but I still couldn’t transfer waypoints.  I kept getting that ‘Communication Timeout’ error.

I tried another suggestion from this  post  in the same thread and manually adjusted the Destination Addressing fields on each unit.  I noted the high and low serial numbers for each unit (SL and SH) and manually configured the  high and low destination addresses to point at each other: XBee1 DL = XBee2SL, XBee1DH = XBee2SH, and vice-versa.

I flashed these settings, booted up MikroKopter Tool and was wirelessly transferring waypoints and receiving telemetry with no problems.

Of course, now we just have to see if it’s actually going to work in the field!

Next up: playing with the GPS camera!

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!

Jan 31 2011

Indoor / Outdoor "GPS" Tracking Camera

"A camera that remembers where you've been...even when you don't." That is the catch phrase for the newest in geo-aware digital cameras on the market, and the ploy / technology behind the advertisement has me very intrigued for the possibilities of computer vision enhanced ecology and remote sensing that it may enable.

While working on the ooo-gobs of other aspects of my current work (in other words, all that dissertation proposal and exam stuff), I wondered about the latest progress in GPS enabled digital cameras.  Generally, GPS positions tagged to images could be used to improve the computer vision, structure from motion process. Bundler is not enabled for this, but Noah Snavely suggests in his articles about Bundler that this would be possible.  I was thinking about how useful camera GPS positions would be as I was trying to subset out a set of photos to perform a pilot study of my phenology - color based analysis.  

After a brief web search, I came up with this puppy, the new Casio EXILIM EX-H20G shown here (image and source docs at http://exilim.casio.com/products_exh20g.shtml).  At first blush, it looks like a newer version of the EX-FS150 that we bought over the summer, but never used for much.

The kicker about the EX-H20G is the Hybrid GPS system that uses built-in accelerometers to track position when GPS signal is lost, for example when you go in a building ... or under a forest canopy...?  This a pretty new device and it is still relatively expensive (about $350) but the ability to track and geo-tag position when GPS signal is lost could prove to be very valuable for linking aerial and ground based 3D point clouds.  Unfortunately, a review of the manual indicates that continuous shooting mode is not available on this model, but it may be worth picking one up to see how it works.

Next then will be to soup up Bundler to use camera GPS positions to initialize that computationally dreadful bundle adjustment stage!


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.