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


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!

Jul 15 2011

First Altitude Controlled Hexakopter Flight!!!

 

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.

 

                                                                                        Why are you reading this watch the video!

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!

Sep 17 2010

We get a new Tx/Rx and the Hexakopter flies waypoints!

Last week we had ordered a DX7 2.4 GHz Spektrum and an AR7000 DuaLink 7 channel receiver transmitter/receiver set from an online company. Unfortunately they had to send back their entire stock of Spektrum Tx/Rx due to a binding issue. On Monday Jonathan went down to Hobby Town USA and bought the set so that we could work on it during the week. By Tuesday morning, Jonathan had the transmitter charged so that we could work on binding it to the Hexakopter. First we had to pair the transmitter with the receiver, which we accomplished by powering the Rx with a small 5V NiCaD and pressing the bind button on the back of the Tx. Once the LED on the Rx glowed orange we tested it by hooking up a servo and moving the appropriate stick on the Tx.

Surprisingly, there was little work to do in order to connect the new receiver to the Flight Control board. We separated the main receiver from the external receiver. Then we clipped off one end so that we could solder the wires to the Flight Control board. Using a picture from the Mikrokopter Wiki we were able to solder the connections without a problem. Once we finished wiring the receiver we turned on the Hexakopter and the transmitter. However we soon found out via the “alarm clock style” buzzing from the Hexakopter that it was not receiving any signal. After a few minutes of trying to figure out what could be the issue, I changed the receiver setting on the Mikrokopter Tool from multi-signal (PPM) to spektrum satellite. This fixed the connection issue and allowed us to set up the altitude and GPS control.

Thursday we decided to test the Hexakopter and the new transmitter. First we tested the altitude control.  It was set up through the Mikrokopter Tool to be an adjustable altitude lock. We set this up so that once the altitude lock was set, you could adjust the height of the Hexakopter by moving the throttle stick up or down - a neutral stick meant that the Hexakopter was to hold position. After a few tries we managed to get the Hexakopter into altitude lock without a problem. We did notice however, that when the altitude lock was engaged near ground level (around 8 meters) the Hexakopter started to oscillate between around the locked height. We believe that this was caused by the propeller backwash and decided that any further flights would not engage the altitude control near the ground for extended periods. Afterwards we attempted to test the system's waypoint software. We started with the GPS lock mode, which held the Hexa at a position determined by when a 3-way switch on the Tx was moved to the middle position. The GPS lock mode had little issues and was easy to engage. However the main issue came when attempting to set waypoints. We could get it to fly to a single position by specifying a waypoint and switching the 3-way switch to GPS home mode but we were unable to get it to fly multiple waypoints.

Finally after some research on the Mikrokopter.us forums, we were ready to fly a set of waypoints. The issue was that we were not setting altitude lock and GPS lock before attempting to load. On Friday we set out to Herbert Run to test if the Hexa could fly a set of waypoints.