Blogs

I finally had a bit of time to work on my quad project.  I think Im nearly finished with the top and bottom plate and I'm printing out the GoPro tilt mount as I type this.  The project is coming along and I'm excited to put it in the air soon.  Here are some Sketchup pics of my mockup file and the test fit model coming together.  Any suggestions on the components?  I am a little split on using a spare KK board, a DJI or a APM.  

Hello All, 

First I will say, Great job guys (developers).

And now....

I like to show our setup with AdaFruit digital Navigation RGB-Led's:

The cool thing with this setup is, each RGB-Led is separated to control.

To let this work well, we decided to use a Nano board to control the Led's.

And we are using the defined COPTER-LED 1 true 6 on the APM2/APM2.5 board.

I have included some code in the original leds.pde and system.pde, after some tests I will show the code here soon.

In this code I've added some extra functions like:

 RGB_LED_1 = Armed/DisArmed function
 RGB_LED_2 = GPS Fix function
 RGB_LED_3 = Battery Low
 RGB_LED_4 = AltHold mode
 RGB_LED_5 = Loiter mode
 RGB_LED_6 = Dancing Led's (sensor calibration)

These function are not yet visible on the first showed video's !

Here a first impression video including all functions:

A better video is coming soon, this depends on the weather in Holland :-)

I hope you all like this setup.

Best regards,

Marten

After years of development, I can finally announce the project I've been working on... the NanoQ Copter and Mimix Controller.  It's a tilt-controlled, palm-sized, quad with multi-team aerial gaming.  We've just launched it on Kickstarter, so checkout the video of it flying at http://KickstartMimix.com!

Now for some specs...

NanoQ Copter Specs

• Size - 5.25" from motor to motor
• Weight - 35 Grams
• Batteries - Single Cell Lithium Polymer
• Battery Charger - Dual Port, USB Compatible
• Flight Time - 8-10 mins
• Range - 30+ meters (RF digital comms)
• Max Payload - 10 grams (does effect flight time)

Mimix Controller Specs:

• Designed for Ease of Use, Ergonomics, and Aesthetics
• One Handed Control
• Works in both left and right hands
• Battery - USB Rechargable Lithium Polymer
• Operating time - 3-4 hours

I'm opening up both our RF Digital Communications Protocol, Onboard Serial Protocol, and the IR Gaming Protocol for people to make their own add-ons, modify the controls, and stream back telemetry.  There will also a USB radio dongle so you can send and receive messages from your computer.

There's lots additional information on our webpage (http://KickstartMimix.com), so take a look.  I'd be glad to answer any questions!

I believe Channel 10 were putting together the "Official Documentary" of the OBC. This report briefly features the OBC at Kingaroy, Quads, FPV, and the usual reckless-hobbyist/privacy/laws-behind-technology rhetoric.

Just a heads-up that Teensy my favorite small form factor Arduino compatible board, just got a solid upgrade with the 32bit ARM Cortex-M4 48mhz based Teensy 3.0. The Teensy 2.0 has pretty much been my bread and butter board for homegrown experiments (and some work related ones also). Looking forward to playing with the capabilities of the new one. The creator also aims to keep Arduino compatibility with the new ARM chip, if you don't want to talk directly to the hardware.

More information about the Teensy 3.0 should become available once the Kickstarter pre-order is completed and the Teensy 3.0 becomes official in the PJRC.com store.

But a quick highlight of the specification are:

• 32 bit ARM Cortex-M4 48 MHz CPU (M4 = DSP extensions)
• 128K Flash Memory, 16K RAM, 2K EEPROM
• 14* High Resolution Analog Inputs (13 bits usable, 16 bit hardware)
• 34* Digital I/O Pins (10 shared with analog)
• 10 PWM outputs
• 8 Timers for intervals/delays, separate from PWM
• USB with dedicated DMA memory transfers
• 3 UARTs (serial ports)
• SPI, I2C, I2S, IR modulator
• I2S (for high quality audio interface)
• Real Time Clock (with user-added 32.768 crystal and battery)
• 4 general purpose DMA channels (separate from USB)
• Touch Sensor Inputs

The brilliant Alexis Madrigal at the Atlantic has a great and historically fascinating piece on the fuzzy legal question regarding drones and privacy. Short form: the laws are vague, vary from place to place and nobody really knows what the rules are until they're tested in the courts. Precedents go all the way back to the first hot-air balloons!

It's really worth reading the whole thing, but here's one sample quote:

"This idea of a reasonable expectation of privacy has always been accepted as the standard and the interface of that privacy right and emerging UAV technology is fascinating," Ravitch said. "There is not an answer. The best we can do is arrive at laws and practices of the then-existing sensibilities of the population."

APM 2.0   firmware 2.7.3

MediaTek  and barometer  no sonar

As promised last time, here is another successful mission with a T-Rex 450.

The day looked very good for flying, but as we arrived on the flying field the wind picked up very much with gusts.  Despite the wind I flew anyway, because I had a friend with me who also flies T-Rex 450.

After the mission was successfully completed he was very much impressed how the little heli mastered the mission and how well the APM performed. He actually considers now to fit his heli with an APM.

The Heli was flying pretty much on track; the altitude was sometimes off by about 4m.

You have always to see things in scale; this condition was for the little 1kg heli like to fly with a Robinson in gale force wind.

All the mission flies, log files and parameter files are in here:

T-Rex 450 on a 15 Waypoint Mission

So you can review the mission in your Mission planner.

Hi Guys,

Today OpenBee boards arrived from PCB factory and i just tested them and working fine :)

It is including Arduino 16Mhz ProMini bootloader and you can upload the code directly over Arduino with USB to Xbee Adapters. No need an external FTDI board or something.



We are producing OpenBee modules with U.FL socket. PCB also compatible with SMA connectors. 
OpenBee modules will be in stocks in 2-3 days on flytron.com


Now i'm writing some codes for OpenBee hardware and need your help. If you want to develop something over OpenBee, please contact me. 

Google code page will be ready in few days: http://code.google.com/p/openbee/

Thanks
Melih

We have seen blog posts about the Swinglet Cam from senseFly here and now the guys from senseFly have a new product, the eBee.

From the site

The eBee is lightweight enough to be launched by hand. It is fully autonomous during its entire flight. When it comes to landing, the eBee can either land in a circular clearing or, when space is limited, use its advanced ground sensing technology to make a fully autonomous straight-line landing.

The eBee comes with a mission planner

The included eMotion 2 software lets you plan, simulate, monitor and control the trajectory of the eBee both before and during flight. With simple drag&drop actions you can designate the area to be mapped, generate a flight plan and with a single mouse click you can update your mission or return the eBee to its starting location.

3D processing

With its 16MP high resolution camera, the eBee can capture images with a ground resolution of 3 to 30cm per pixel. Areas from 1.5 to 10km2 can be mapped in a single flight depending on image resolution and flight altitude. The eBee package includes Postflight Terra 3D (a fully automated 3D processing desktop software powered by Pix4D). After the initial data check in the field (overlap control and low resolution orthomosaic), Terra 3D automatically creates a precise geo-referenced orthomosaic and digital elevation model (DEM). Advanced users can further optimize their models through operator defined ground control points and seamlines.

Highlights

I haven't been able to find a price. The product will become available beginning of 2012. More information on the senseFly website: http://www.sensefly.com/products/ebee

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.

Another great post from Evan Ackerman at IEEE Spectrum:

This heterogeneous robotic team consists of a small autonomous UAV, an ASV (autonomous surfin’ surface vehicle), and an AUV (autonomous underwater vehicle). Here’s a rundown of the different bots and what they do, straight from the research paper:

• The Unicorn UAV is responsible for performing coverage of the entire survey region and provide up-to-date large-scale aerial imagery to the remote human scientists. After obtaining the expert-selected inspection sites, the UAV then re-broadcasts these waypoint directives to the other two robots underneath, while continuing to collect updated aerial footage of the entire region.
• The MARE ASV serves two primary roles: it is used to cache waypoint directives received from the Unicorn UAV, and it also relays these messages to the Aqua AUV when it surfaces. These roles are needed because the UAV has limited battery life, making it unable to wait until the Aqua UAV surfaces.
• The Aqua AUV is responsible for gathering fine-scale imagery by performing close-up inspection of the target sites. While Aqua mainly operates underwater to navigate to these sites and collect footage, it also regularly ascends to the surface to listen for further messages from MARE and to update its localization using GPS.

The overall idea here is that researchers, safe and dry on land, can easily interact with the entire swarm (which is autonomous) in real-time, using the imagery that the UAV sends back to select locations for detailed underwater inspection by the AUV. This can even be done ultra-remotely, through a web interface, meaning that you’ll never even have to go to what looks like an exotic tropical island in person. Watch the system in action, and you’ll see how simple it is to control:

Sameer Parkekh from FlyingRobotsNYC and Falkor Systems and I gave a main stage talk at Maker Faire NYC two weekends ago, and the video is now live. It starts with 10 minutes of overview on how I got started with drones and then Sameer does a cool demo with a AR.Drone hacked to recognize a kid wearing a t-shirt with the Falkor logo on it. It actually worked, although not quite as well as it had done in rehearsal. Lesson: if you plan to demo with a kid, don't practice with a 6'1" guy--the quad was hovering a bit too high.

More photos are here. 

Ok it was a very long wait for those of us who bought the wifi back pack to see our GoPro video on our iphone (and other devices too) 

But it's out today.  

I've tested it and there is like a 3-4 seconds delay so no live streaming that could help us to do cheap (near) FPV... but it's nice to make sure your landing gear/arm is not in the shot.  Also you can see if your lens is clean... 

It's pretty much it... kind of a bit sad there is such a long delay... maybe some firmware update will make it faster later.. 

Update your cineform software to latest before up update the wifi pack and gopro hero2 firmware. 

It was a bit bumpy installation (firmware upgrade) but worked in the end. 

Let me know if you get better lag time... 

Dany

If you have a GoPro HD HERO2 camera there's a free firmware update that doubles the video bit rate, has a neutral white balance, and disables internal noise reduction, contrast adjustments, and sharpening. This dramatically improves the quality of the video and opens new doors for post processing of the video.

You can get the update from the GoPro website under support. It suggest updating through their CineForm video editing suite (also a free download).

I hope this makes it to the blog before it actually starts.

Earliest launch now 11:30AM MDT/17:30 GMT on October 9th

Red Bull Stratos is a mission to the edge of space that will try to surpass human limits that have existed for more than 50 years. Supported by a team of experts, Felix Baumgartner will undertake a stratospheric balloon flight to more than 120,000 feet / 36,576 meters and make a record-breaking freefall jump in the attempt to become the first man to break the speed of sound in freefall (an estimated 690 miles / 1,110 kilometers per hour), while delivering valuable data for medical and scientific advancement.

We set up onstage beforehand with Christopher and it was apparent even then that he was freaky smart. But then he does a demo programming a Parrot AR.Drone to fly geometric patterns with Mathematica, and then debugged the program in real time on stage in front of a packed house. Amazing. When I was 13, I was still having trouble remembering the months of the year. (Of course, he is the son of a genius. But still!)

Report from Makezine here:

Mathematica creator Stephen Wolfram gave a talk at World Maker Faire New York 2012, but his 13-year-old son Christopher stole the show by doing some Mathematica programming on the fly to control a quadricopter.

His plan was to have a single line of Mathematica code that would make the quadricopter fly a specified 3D path. He had a list of points for a square, entered the line of code, and pressed Shift-Return, and… nothing happened!
I guess Christopher has debugged quite a lot of code in his 13 years. And now he set about doing it in front of the audience. A missing function definition. A missing command to connect to the device. He was finding quite a few things. And I was getting ready to call out that he should just give up.
But then… the sound of quadricopter blades, and up the quadricopter goes… flying its loop on the stage, and landing.
It had actually worked! It was pretty neat, being able to just type one line of code into Mathematica, and then having some physical object fly around in the pattern one had specified:

Nothing DIY about this, but it was too cool to resist. From Gizmag:

Two Global Hawk unmanned aircraft have flown in close formation at distances as close as 30 feet (9 m) for the first time. The series of flights took place between January 11 and May 30 this year and marked a major milestone on the way to demonstrating the first autonomous aerial refueling between two unmanned, high-altitude aircraft as part of DARPA’s Autonomous High-Altitude Refueling (AHR) program.

The flights were conducted by a team from Northrop Grumman, DARPA and NASA Dryden Flight Research Center and involved two modified NASA Global Hawk UAVs. The trailing aircraft was configured as a tanker aircraft, while the lead aircraft was configured as a receiver and extended and retracted its aerial refueling hose several times during the flights. Fuel systems were also fully integrated into the UAVs and ground tested.

During the ninth and final test flight lasting over 2.5 hours, the two aircraft rendezvoused at 44,800 feet and spent the majority of the time flying autonomously within one wingspan (100 ft/30 m) of each other. This was designed to demonstrate that High Altitude Long Endurance (HALE) aircraft can safely and autonomously operate under the conditions of in-flight refueling.

Hi all,

Iam following APM since 1280, for remote sensing purposes. finally i used my two latest platforms ( Skiptrovamon & Bixler 2 and ground station for a full scale mission.  

i have had-like many fellows from DIYdrones - a great success with AP from APM, but the think that made me really excited was the real plug n play performance.  i just connected everything on APM2 and Bixler, load the param file from wiki and threw it on the sky! the latest code recognized all my new gear automaticaly (solderd onboard GPS, external ublox, RFD900) and Mission planner UI guided me throu a 5min setup.

No tuning! nor Balancing for the extra GoPro, nothing!   I just flew for 5-7 minutes for the auto declination do its magic and then switched to Auto!

if you are a new comer searching for a cheap trusty platform and for a super DIY autopilot you are in the right place!!   

cheers

James

What is HeX? Why do we want to do it?

HeX which is a portable robotic multi-rotors copter with a modular design and the abilities of auto tracking and filming

There are several reasons we wanted to do this at the first place:
First, We found robotic multiple-rotor copters are quit mature with a sophisticated ROS.
Second, with proper airborne peripherals and software, an air robot can accomplish various tasks in industrial, military and civilian uses. So if we put a camera and computer embed an efficient tracking algorithm on HeX to give it an ability to perceive and track a certain target, what this can be used in our lives?
Third, we find X-sports fans love to have someone else to film them when they are doing those spectacular moves. Bingo! would it be cool if HeX can track and film those X-sports fans automatically and it doesn't take a tech pro to set it off?

Then it comes the idea building an portable air robot for X-sports fans and family entertaining events.

more about HeX, please check out the website http://hex.angeleyes.it