Blogs

We're now settling back into life at home after some exciting times in Queensland, so its time to write up what happened. This will be a fairly detailed report, not just because some people may be interested, but also as a way to remind ourselves of what went right and what went wrong for our next trip to Kingaroy.

The CanberraUAV team, which consists of 9 enthusiastic amateurs, have been preparing for the Outback Challenge since early 2011. We formed as a sub-group of the MakeHackVoid makers group in Canberra, and despite some setbacks managed to keep things going right up to the challenge flights in Kingaroy this month.

Right from the start we got lucky when CyberTechnology in Perth very kindly donated an airframe to us. It was a bigger airframe than we were used to, with a takeoff weight of around 16kg once we put our equipment in it, but it was eminently suited to the challenge itself.  The large runway and long distances at Kingaroy, along with high  winds, meant that the large airframe was really in its element.

Apart from the airframe, here is the list of the main pieces of equipment:

• 50CC petrol motor
• 3 litres of fuel
• APM2 autopilot
• Custom failsafe/termination board (AVR328 based)
• FrSky Receiver
• Turnigy 9x transmitter with FrSky TX and er9x firmware
• pandaboard ES (dual core ARM, 1GByte ram)
• 64GByte USB SSD
• PtGrey Chameleon colour camera
• Custom roll stabilisation system for camera
• Ubiquity Rocket M5 in plane with 2x5dBi omni antennas
• Ubiquity Bullet on ground station with 20dBi patch antenna
• RFD900 900MHz radios at both ends, with 6dBi yagi on ground, and 3dBi omni in plane
• Custom bottle release mechanism and small drogue parachute
• 7Ah SLA battery for pandaboard, APM and camera
• 2x2Ah LiFe batteries for servos and failsafe board
• UBlox 'birthday' GPS
• Linux based ground station laptops (3 laptops)

We've posted previously on the preparation we did over the last 18 months or so, so I'll start this debrief with the Kingaroy trip itself.

We drove up to Kingaroy over 2 days, leaving Canberra on Thursday the 27th of September and arriving on the Friday evening. Behind Jacks car we had the Dickson College trailer, which ended up playing an important role in our flights, both as a platform for our antenna tripod, and as a good source of shade for the ground stations to prevent screen glare.



The competition events didn't start till the Monday, giving us the weekend to ensure the aircraft was in good shape, and do final tests in the Kingaroy area. On the Saturday we tried a long range ground-to-ground antenna test of our  900MHz and 5.8GHz radio links. The results were quite disappointing, with a poor link on both radios. This wasn't  completely unexpected as both radios suffer badly when you don't have direct line of sight and there are some significant rises in the ground around Kingaroy which make it difficult to do line of sight tests over the distances needed for the competition (about 8 kilometers). It was worth a try though, as if it had worked then we would have been certain that the links would have been good once the plane was in the air.

With the long range tests failing we then went to the next stage of testing, while we tried to think of a way of confirming the radio equipment was in good shape. So that afternoon we tested the motor ran well on the ground, and checked the terrain elevation model of the competition search area by driving right around it and comparing heights in our terrain model to the observed heights on a Ublox GPS.

We were delighted to find that the terrain model was quite accurate - within about 7m or so at all points we tested. The model we were using was a combination of Geoscience Australia data (available free from their website) and  SRTM data. The GA survey data is available for all but the very southern tip of the mission boundary, so for most of  the area we were able to use the GA model. Stephen Dade had written a python module to link the two sets of data,  and hook it into our mission planning and ground station software.

The next morning (Sunday) we went back to radio testing. We realized that all we really were trying to confirm was  that the radios and antennas were undamaged, and that the background RF noise in Kingaroy wasn't high enough  to prevent a good link over the mission range. So what we did was a much shorter (2.2km) test over the length of the airport, and looked carefully at the amount of link margin available on both links. We found that we had more than  24dB of link margin on the 5.8 GHz link at that range, and even more on the 900MHz link in the direction of the plane to the ground. That implies a range of over 32km.

The link margin from the ground to the plane was lower, as we were getting a lot of noise in the radio at the plane  end of the link, even with the engine off.
The above graph shows that the RSSI (which scales as roughly 2x the signal in dB) was good at both ends, but the  noise level in the remote radio (the one in the plane) was too high. With some help from Seppo Sario that evening we worked out that the newly installed horizontal diversity antenna was picking up too much noise from the pandaboard. Removing the 2nd antenna from the RFD900 radio brought the noise levels under control, and we knew that the link would be good.

The next day, Monday, was when we finally got to meet the other teams, and was also the day for both static and flight scrutineering. We were very impressed by the range of ideas and equipment that the other teams were showing, although we were also very sad that our good friends from team TGIF would not be able to fly as they had crashed their plane in final tests the day before near Brisbane.

The field had thus been reduced to just 5 teams. We thought the two favorites were Muroc and OpenUAS, as both were more experienced than we were, and Muroc had some incredibly advanced camera and radio equipment from UAS Vision systems. We were also impressed by the amount of work that Forward Robotics had put into their self-designed autopilot, and the thought that had gone into the 3G radio links that CompassUAV had in their plane. It looked like it would be a close competition!

The static scrutineering didn't start well for us. During static scrutineering the scrutineers examine the plane very carefully for safety and compliance with the rules. Despite having done full ground tests that morning, our v-tail  mixer, which is integrated into our failsafe board, failed during scrutineering! The scrutineers quite rightly asked us to fix it on the spot. We quickly swapped out the mixer for an external mixer (of the same type) and we were back in business. Thank goodness for spares!

Next came the geo-fencing test. The plane was setup ready to fly, then carried across the boundary of the geo-fence while in manual mode. As expected, the APM geo-fencing code triggered, sending all control surfaces to maximum. We were now ready for the flight tests.

Muroc were up first, and did the required manual takeoff. Unfortunately their pilot wasn't quite as careful with the edge of the geo-fence as he could have been, and his plane clipped the edge of the virtual fence near the car park.  As is required in the rules, once the plane crosses the fence there is no recovery, and in a heart rending moment for everyone watching it dived into the ground at high speed. There was very little left. To see two years of development effort end so quickly was terrible.

Soon it was our turn, and we took the plane out to the runway and setup our ground station. As we were setting up the head scrutineer went through the flight plan, and my heart nearly stopped for the 2nd time that day. He pointed  out that the flight test would include a "comms failure" test. Amazingly, despite having gone over the rules so carefully so many times, we had missed the fact that a comms failure test was part of the scrutineering flight. We  supported comms failure of course, and in fact had built support into the OBC module in ArduPlane, but our carefully prepared scrutineering flight plan did not include a comms hold waypoint. After quietly kicking myself I created a new flight plan in emacs while the others setup the ground station, then quickly flew it in the SITL simulator on my laptop, iincluding testing of comms failure, to ensure it was OK. We were all set.

Jack did a good takeoff, and started flying circuits under the direction of the scrutineers. Steve and I carefully watched the flight on the ground station, ready to tell our pilot Jack over the walkie talkies if he approached the geo-fence boundary. We really didn't want to hit the fence like Muroc did! After a simulated dead-stick approach, Jack switched the plane to auto and it took off around the simple 4 point circuit. It flew beautifully. It really was wonderful seeing it fly the mission so well above Kingaroy airport. Once the scrutineers were satisfied Jack brought it down in manual. There was some discussion that we may been closer to the western side of the geo-fence than we should have been during the landing approach, but examination of the logs showed we had around 7 seconds  leeway, which is quite a lot for an RC model.



The other teams were not so lucky. Both Forward Robotics and CompassUAV had technical issues which delayed their scrutineering flights, although both managed to sort them out eventually. The CompassUAV issue was a bent  ground pin on an APM2.5 radio connector, which was solved by swapping out the APM. I don't know what the delay was with Forward Robotics, but they did fly in the end and passed scrutineering with no problems.

The final team, OpenUAS, crashed almost immediately on takeoff in what must have been a terrible moment for them. They were using a 37MHz RC transmitter, and had not setup any debouncing on the termination rule that requires the plane to terminate if RC control is lost during manual flight. That meant as soon as they lost a single  radio frame from their transmitter to the plane it immediately went into termination and dived into the ground hard. It looked like their attempt at the challenge for 2012 was over.

In what must have been one of the most heroic efforts of the competition they didn't give up. They stayed up all night and managed to piece their glider back together using glue and sticky tape. After adding debouncing to their failsafe module, they then flew the scrutineering flight on Tuesday morning and passed. So 4 teams got the go to fly in the main competition flight.

Names were then drawn out of a hat, and after some changes to ensure OpenUAS had time to charge their batteries after their scrutineering flight, we were put in the 3rd position, due to fly sometime after lunch.

CompassUAV were up first with their APM powered plane. I had high hopes for them, as they looked to be well prepared, but unfortunately they had forgotten one thing. They had never tested what happened when they turned off the RC transmitter when the plane went beyond line of sight for the main search.

As soon as they turned off the RC transmitter the plane immediately switched to manual mode. They hadn't setup their receiver failsafe correctly. They couldn't do anything as their plane dived into the ground. At that point we were very grateful that we had tested our receiver failsafe setup, and knew we could fly with the transmitter off.

Next came Forward Robotics from Canada. Their strategy was to fly over the search area gathering photos, then come back, land and run the photos through an image recognition system on the ground station to try to find Joe. After searching about 2/3 of the search area they came home and were immensely disappointed to find that a failure of their camera trigger mechanism meant their camera hadn't switched on properly. They had no images and no more time.

We flew 3rd, but I'll come to that later. After us OpenUAS flew, and they had a good hand-launched takeoff and initial flight, but unfortunately their glider crashed in the high winds a few minutes later. The OpenUAS team think that perhaps their repairs from the scrutineering crash weren't quite as good as they had thought they were.

Our own flight was full of unexpected drama. The wind was moderate on the ground (averaging about 20km/h), but there were frequent lulls in the wind if you were willing to wait for a few minutes. Our plan was that were would get the plane ready on the runway, and if we were fortunate enough to have a lull in the cross-wind we'd do a fully automatic takeoff, otherwise Jack would do the takeoff manually. After waiting a minute or so we did get a lull, and I  entered "wp set 3" in mavproxy, and the 50CC engine roared as it did a perfect automatic takeoff. That was quite a  moment for us! The cuav mavproxy module on the ground station then automatically disabled stick mixing and enabled rudder mixing, and we told Jack via the walkie talkies that he was cleared to turn off the transmitter. He switched it off and came over to the GCS trailer to watch the flight with the 3 GCS operators (Steve, Matt and myself). Although I didn't notice it at the time, apparently a TV crew was lurking over our shoulders the entire flight, so there should be some good footage available at some point.

Our ground station setup was quite complex, perhaps too complex. We had 3 Linux laptops (running Ubuntu and Mint), connected together on an ethernet switch, which was connected to the plane via the Ubiquity ethernet bridge. The 3 laptops were in black painted boxes to keep the sun away, plus we had a larger LCD monitor in the "chook pen", a larger wooden box set above the 3 laptops. The laptop on the left was controlled by Steve. It was his job to monitor the flight of the aircraft, making sure it flew the 119 waypoints as expected, kept enough airspeed and  ground speed, and didn't do anything unexpected. He had quite a few surprises during the flight!

The right laptop was the Matts imaging laptop. He monitored the results of the automatic Joe image detection  algorithm running on the pandaboard in the plane, plus ran the resulting images through a custom Joe scoring algorithm he had developed in the lead up to the competition.

The middle laptop was the main control laptop, and was the only one allowed to send commands to the plane (it ran mavproxy with mavfwd disabled on takeoff). It forwarded telemetry data and images to the other two laptops, and controlled the large screen with the moving map and main 'mosaic' image recognition display. It was also my job to call out the antenna pointing angle to my brother on top of the trailer, to ensure that the 20dBi 5.8GHz antenna kept pointing in the right direction.

The initial flight towards the search area was perfect, and things were looking good. I did make one mistake though - I had disabled saving of images to the 64GB SSD on the plane before takeoff to save a bit of disk space, and forgot to re-enable it on takeoff. Once the plane was in the air the ssh link to the pandaboard was so clogged with images that typing "camera set save_pgm 1" was difficult, so I left it for a while, thinking we won't need the hi-res images  later anyway - either we find Joe or we don't and the recognition results will come down to the GCS regardless of whether we save them to the SSD. Later in the flight I did re-enable saving to the SSD via our block_xmit 900MHz backdoor to the pandaboard (via "remote camera set save_pgm 1") but if you are wondering why our full flight image set starts part way through the search this is the reason.

The drama really started about 8 minutes into our one hour flight. The first thing we noticed was that the plane was losing airspeed rapidly. It got down to 15.1 m/s at one point, which is below the stall speed. The plane was falling out  of the sky. I first thought that the engine must have stopped, but when it recovered a bit I knew it couldn't have, so I ran "param set TRIM_THROTTLE 55" to push the throttle set point higher. We normally fly at around 40%  throttle, giving us a cruise speed of around 100km/h. Using 55% throttle should have made us scream along much  faster than we usually want. The plane was still slow so I pushed it to 60, then 65. At that point the speed was still  slow, but was well above stall speed so I left it alone. Whatever was going on, I didn't want to kill the engine with too  much throttle for an hour.

It was at around this time we noticed that the red warning indicator for the bottle confirmation microswitch was showing on the GCS console. The plane was telling us that the bottle was no longer attached. Jack and Chris started working through scenarios that might explain the speed drop and bottle loss. They thought that perhaps the bottle had twisted sideways enough to release the microswitch and was causing drag.

The plane was still flying, and the image recognition was working well, so we decided to keep flying to find Joe. We had a spare bottle setup and ready to go so we knew that if the bottle was gone then we could come back and put another one on the plane then fly out again to drop it. None of that mattered if we didn't find Joe however.

The wind was really picking up at this stage, with the wind estimation algorithm in the APM estimating the gusts as around 50km/h, with an average of over 25km/h. Given we were only flying at around 85km/h due to the engine problem, that much wind was really affecting navigation. The APM was doing well, but the turns were not perfect, so I switched from GPS based heading to compass heading by running "param set COMPASS_USE 1". In a really fast plane the GPS is usually great for heading, as it doesn't suffer from any compass calibration problems. In high wind the compass navigation code does better, as it takes into account the wind vector to adjust the crabbing in a nicer way during turns, leading to less yaw error. After enabling compass heading the turns improved a lot, and I was very happy with the flight path. The ground station shows two plane icons, one with the GPS heading and the other with the compass heading. The two icons were at about 30 degrees from each other, showing that the plane was  crabbing down the course sideways, which is exactly what it is supposed to do.

The reason I cared about the turns was that we had setup for just 100m of extra distance beyond the end of each  search strip, which meant that the plane needed to get back on track within 100m of turning or we could miss Joe if  he was close to one end of the search area. The GPS based turns were sometimes taking over 200m to get back on  track in the wind, whereas the compass based turns took less than 100m.

Our search pattern was an interleaved "mowing the lawn" pattern, with 50% overlap. The idea was that we would cover every part of the search area twice, maximizing our chances. That meant we should have spotted Joe in the  first half of the search, but we didn't. The plane reached the eastern side of the search area with no Joes in sight, and turned around to start searching the other way. We did have a lovely set of photos of the fields near Kingaroy, and even a few buildings, but no Joe.

It turned out that we missed Joe on the first pass because of he was within 200m of the end of the search area, and the GPS based turns had been a bit wide on the first pass.

At 31 minutes into the flight, after a few false positives, we finally spotted Joe. The image was so clear and the score from the detection algorithm was so high that there was no room for error. We'd found Joe! Now if only we had a bottle to drop to him.

Michael wrote down the latitude and longitude the GCS calculated for Joe, and handed it to the judges. They came back a minute later and said we were off by more than 150m, so we did not have permission to drop the bottle.

We then decided to do a confirmation pass. We adjusted a couple of waypoints and told the plane to fly directly over the position we'd calculated for Joe. That gave us another 20 great images of Joe, with even higher scores. We were sure we had him.

The rules allowed for 3 tries, so I picked a second position from the confirmation pass and Michael again handed it to the judges. Again they came back saying that were were close, but still beyond 150m. We had one more try.

Our final try met with the same result, and the judges told us to we needed to fly home. We'd failed to rescue Joe.

All the way home (thats around 4 minutes of flight time) I was trying to work out how our coordinates could be so wrong. We should have been within 20m at the most, and given the confirmation pass, we expected to be quite a bit better than that. I thought perhaps we had a bug in the (rather complex) timing code that deals with the timing between the camera, the pandaboard and the APM.

The landing approach went well, but the plane was clearly flying too slowly. The revs were way down, and it was struggling in the wind, so Jack took over with manual control a few meters above the runway to bring it in safely. We lept into action to get everything packed up in our allotted 15 minutes tear-down time.

After landing we got a bit of a shock. The pitot tube was bent at 45 degrees, and the wire that holds the bottle in place was hanging below the plane. There was parachute cord around the motor shaft.

It was clear that we had lost the bottle when we lost speed in the early part of the flight. The really puzzling thing was the pitot. It is well in front of the bottle, so how does the bottle come forward on a plane flying at 100km/h and hit the pitot! Someone suggested it must have been a bird strike, and a few observers said they saw some eagles circling near the plane, so that was the hot theory. I starting trying to come up with something that might explain how  the damage might match the poor geo-referencing of Joe.

A couple of more experienced UAV pilots told us it definitely wasn't bird strike, given the lack of blood, but that left us with the puzzle of the damaged pitot tube. It seemed clear that something had hit our airframe hard during the flight, and a bird seemed the only explanation.

It wasn't till I had a chance to examine the more detailed flight logs on the SSD that we finally worked out what had happened. The flight logs showed that the pitot wasn't damaged during the flight, which meant it must have been damaged while we were collecting the plane from the runway after landing. It seems likely that Chris knocked it with his shoulder while carrying it. That means the only real evidence for bird-strike evaporated, and we knew that the bottle came off due to the parachute being dragged out of its holder by the wind. It then wrapped around the motor  shaft, possible dragging on the hall-effect sensor that controls the motor revs. That is why we had much less thrust than usual.

With that out of the way we just had the puzzle of the geo-referencing. I re-ran our flight logs through our  geo-referencing tool and kept coming up with the same result. We just couldn't see how it was wrong.

At that point the organisers released their official position for Joe, and we knew immediately something was wrong. The position they posted was under a tree on the road at the southern end of the search area, but our photos clearly showed Joe in an open field. Their position must be wrong.

It was Matt who finally realized what they'd done wrong. He suggested they must have used the wrong GPS datum, so I tried translating the position they had posted from AUS66 to WGS84, and found that their position matched our position within 10m.

We had a quick team meeting and decided not to say anything that evening. Jack was in hospital with a nasty case of sunscreen in his eyes, and everyone else was at the post competition party. We decided to wait till the next morning to tell the organisers.

The next morning we went out to the field and talked to the organisers. They were very busy with the school competition, but about lunch time they had a look at the GPS they had used, and found that it was indeed set to the wrong datum. It was set to AUS84, which is within a meter or so of the AUS66 that we'd tested with for that part of Queensland. That confirmed what had happened.

The organisers had a meeting and determined that it didn't change the result, as they thought we would not have been able to takeoff with the damaged pitot to drop the 2nd bottle, so the result of the competition didn't change, but it was nice to know we'd really found Joe! The organisers later calculated the error on our 3 positions as 6.56m, 4.40m and 3.16m, which are all within the expected measurement error of a handheld GPS. Not bad for a bunch of amateurs!

There are no hard feelings about the result. The GPS error was an easy one to make, and the organisers put a huge effort into the competition. We're delighted that they corrected the positioning error so quickly, and even more delighted that they awarded us a $10k encouragement prize!

The next day we started to unwind from the excitement of the competition, and decided to go out searching for the lost bottle. Looking at the logs we found 4 possible locations, spread over several minutes of flight. The first 2 locations were when the initial speed drop happened, the 3rd location was where the microswitch showed the final release of the bottle and the 4th location was when we had another speed drop.

With help from the Dickson College school team we found the bottle at the 3rd location, about 1km from where Joe had been hidden. It was undamaged, and we're thinking of dropping the same bottle again in the next competition. We didn't find the parachute, but we expect that was chopped up pretty badly by the propeller.

The Outback Challenge is hard, but not impossible. We were lucky to have such a great team, with skills in all the essential areas. We're looking forward to having another go in 2014!

Many thanks to our sponsors, CyberTechnology, 3DRobotics, Canberra Model Aircraft Club, MakeHackVoid, Paul Tridgell and Ron Graham. We couldn't have done it without you!

Also many thanks to the whole DiyDrones community. Together we've created a great autopilot that can take on the best in the world.

I'll do another article soon on the changes we made to ArduPlane in the lead up to the competition, and on the imaging system we used. Meanwhile, all of our code is available at the links below if you are curious:

• ArduPlane: https://code.google.com/r/tridge60-apm-wip (look in the OBC branch)
• MAVProxy: http://github.com/tridge/MAVProxy (ground station main code)
• mavlink: https://github.com/tridge/mavlink (MAVLink comms protocol)
• cuav: http://github.com/tridge/cuav (imaging and other misc stuff)
• SiK: http://github.com/tridge/SiK (the radio firmware for RFD900)

More photos here. Flight logs here.