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!

This past week I've been working on flashing the new firmware to fly altitude controlled waypoints. As it turns out there was no need for the newest hardware to use the latest firmware (FC 2.1ME, BL 2.0 required). After working out some compatibility issues with the old version of MKtools, I finally was able to connect to the Hexakopter. Today we were able to do a flight test, check out the video for yourself (best in full screen hd).

Next week I plan to flash the new firmware on to the other 2 remaining Hexakopters.

Last Friday we had our first sucessful multi-waypoint Hexakopter flight. Here is a video of that amazing achievement.

My, how far we’ve come! 

Just about one year ago I was out flying my kite almost everyday to get coverage over our two study sites on the UMBC campus.  Over this past week we have made a huge step forward, a systematic ‘test’ flight with the Mikrokopter Hexacopter over the Herbert Run forests.

Flying the large delta conyne kites (like the one shown here, image credit Into The Wind Kites http://www.intothewind.com/) was fun and got the camera in the air, but it was very hard to control both the altitude of the camera and its position over the forest.  This meant it was very difficult to test flight plans, or even begin to get at understanding the best flight plan strategy for use with computer vision.

Over the past summer we worked with several students from the UMBC GES and MECHE departments and a visiting intern from Clark University (thanks Evan, Nisarg, Garrett, and Noam) with the goal of using hobbyist aircraft to carry the cameras.  We moved away from using the Canon CHDK camera setup, instead using high-speed (~2 photos / sec) cameras with continuous shooting modes to collect huge numbers of overlapping photos.  We had a lot of promising flights and successes with the hobbyist aircraft, the Slow Sticks and Easy Stars.  But we also had a lot of technical challenges and crashes that made us question the sustainability and repeatability of the ultra-cheap systems for our scientific research and technological development stage.

Enter the Mikrokopter Hexacopter.  The Mikrokopter line of remote controlled aircraft offers precision control and GPS navigation.  Last Friday we made our first demonstration of the GPS-assisted navigation over the Herbert Run site.  The Photosynth generated from those photos is here, http://bit.ly/bqAhzL, and while it looks similar to the rest of our aerial synths, it is generated with photos taken along a pre-designated path at a constant altitude.  Remarkable!

I expect things to progress quickly this fall (that dissertation is calling) and we have set up another blog for weekly progress about the nitty-gritty of Ecosynth research, http://ecotope.org/ecosynth/blog/.  I will continue working with this blog as a reference for the methods and research progress and the ‘weekly’ should be a place to go for latest in weekly goings-on in the Ecosynth lab.

Thanks team, we could not have gotten here without all of your hard work.