This shaky little video shows me debugging an app with Android Studio over a wireless connection to my Samsung Galaxy S4.  The app, DroidPlanner, connects to a 3DRobotics Iris over a 915 MHz radio plugged into the Galaxy's micro USB port, making the USB unavailable for debugging.  Thanks to these instructions:

  http://developer.android.com/guide/topics/connectivity/usb/index.html

I was able to connect to the phone over my local wifi network, freeing up the USB port for the 915 Mhz radio.  The end of the video shows the steady green LED on the radio, indicating a connection to the Iris.

This is a full flight video of a Mamba UAV 370p. The camera placement made for a interesting view. 

Maiden Flight testing- FPV configuration and tuning for a customer.

Adjustments to the FPV system as well as testing the different flight modes, including the invocation of RTL - Return to Launch, however none are individually noted in the video yet. The new aircraft performed very well with only minor adjustments to be made. The Pixhawk on this platforms very well, the controls are crisp and precise. Several times I stop it abruptly to see if it will mis-behave and it reacts quickly returning to a very stable flight immediately. Although all of the components worked very well, and the Pixhawk still impresses me each time I place it on a flight deck.

I had fun with the music so that it could be watchable, as it is a flight test video.

Its been a while since I posted part 1 on this project. Since then I have been working on the HUD as well as building myself a test copter. Oh, and I've also finally got my 3dr pixhawk,

There is nothing much to show today except the HUD. I did not use the camera here to get a better view of what it looks like.

As you can see it is very like the HUD in mission planner. I have looked a lot at the Mission Planner code when creating this to get it as similar as possible without overdoing it at this stage.

The basic idea here is that the HUD should always be straight ahead so when I tilt my head the HUD stays in its original position. This way I always know what is straight and hopefully also get a better sense of immersion. If I turn off the head tracking the gimbal is put in neutral position and the HUD will also lock its position in the center of my view.

At this stage there's really not much more to say about it. It is drawn using Direct2d to a texture that is then placed on a polygon and rendered in Direct3d. There is still a lot of work to do on it but the main parts are in place.

Hopefully I will be able to do some test flights this week if the weather allows, will post an update then.

. 

Helibaits HB06 is possibly the first drone designed to cary bait and unload it in a specified area. Fisher man all over the world may benefit from this concept. Simple but useful.

This could be nice upgrade of hobby, even if you don't catch any fish, you can always check the area, or make a nice movie.

After tuning my PID parameters for both my 3D printed quadcopters crossfire and miniflame, I succeeded in having some decent test-flights. The flight controller used is an own built controller inspired by KK2, AeroQuad and ArduCopter. Future development: including a GPS module.

Google now gives "a drone" as the fourth most popular answer to the search term "I want to buy..."! Data from the New York Times

Another datapoint on the mainstreaming of drones: a long cover story in New York Magazine. Cool inside art, too (see below). Here's a sample of the piece:

Drones are a different kind of new technology from what we’re used to. The communications breakthroughs of the past two decades have multiplied the connections within society, but drones offer something else: the conquest of physical space, the extension of society’s compass, the ability to be anywhere and see anything. This physical presence can be creepy when seen from the ground, in ways that echo the imaginings of science fiction. “Flying,” says Illah Nourbakhsh, who ran the robotics program at NASA’s Ames facility, “creates this dynamic where people are no longer on top.” And yet to the drone pilot, maneuvering through the air, it is liberating.

It’s an incredible thing, extreme elevation. It makes you feel both alone and unsurpassable. Send a drone up, equipped with a camera, the control in your hands and your laptop rigged to see what the camera sees, and what you feel is not displacement but extension. Each of these flying robots, more than anything else, changes your perspective. Now anyone with a drone can watch the Earth from a point of view that once implied great power. This summer, the pastor of a prominent Evangelical megachurch in Texas delivered a series of sermons comparing God to a Predator drone.

...

There is something uncanny about the drone perspective that creeps up on you, the more videos like this you watch. The drone’s point of view emphasizes the mass scale over the individual. One of the early drone videos that got around, enough to collect nearly 2 million views, is a vision of last year’s Burning Man, roving across the encampments—the huge sculptures, the big empty desert beyond. From high above the festival, individual distinctions blur and the people look almost choreographed. The man who shot it, a San Franciscan named Eddie Codel, had been going to the festival for years, and he told me he was intrigued by the way the drone removed you from the usual individual perspective—­circumscribed, on the ground—and let you see the “organized chaos” of Burning Man as a whole.

One step closer to a Phantom Vision+ setup, or simply allowing you to use your tablet or smartphone to combine both Droidplanner software and see flight video to line up your gimbal shots more accurately. It means you don't have to carry a separate fpv monitor.

http://www.goodluckbuy.com/diy-wifi-video-transmission-module-with-camera-lens-for-rc-cars-copters.html

Some FPV addicted drone pilots are racing their drones in the woods in France

This is a pre event that happend in france, organized by airgonay, a quadcopter racing fanatic association. Drones are not only for spying or doing the headlines when they fall in the streets. 
Follow us on facebook: www.facebook.com/airgonay

Looks like fun! 

A staggering fact is that motors and motor driven systems account for between 43 percent and 46 percent of all global electricity consumption. Needless to say, if electric motors could be made to  run more efficiently, energy consumption would fall. With research out of Rice University back in 2011 demonstrating that carbon nanotubes braided into wires could outperform copper in conducting electricity, it looked like there would soon be a new way to create those improved efficiencies.

Building on that research, a team at the Lappeenranta University of Technology (LUT) in Finland hasreplaced the copper windings used to conduct electricity in electric motors with a woven material made from threads of carbon nanotubes and achieved remarkable new efficiencies in the motors.

"If we keep the electrical machine design parameters unchanged and only replace copper with future carbon nanotube wires, it is possible to reduce the Joule losses in the windings to half of the present-day machine losses,” said Professor Juha Pyrhönen, who has led the design of the prototype at LUT, in a press release.

Copper windings have traditionally been used because they are the second best metal at conducting electricity at room temperature, and they come relatively cheap. However, despite their high conductivity, they do offer some resistance—to the point where Joule losses are often referred to as “copper losses.”

Meanwhile carbon nanotubes have conductivity far beyond the best metals and their limits of conductivity have not been found: some have been measured at 100 millisiemens/meter, compared to ultra-pure copper at 58.65 MS/m. With this kind of conductivity, carbon nanotube-based windings could result in double the conductivity of today’s copper windings, according to the Finnish researchers. And as Pyrhönen claimed, Joule losses could be cut in half with the carbon nanotube yarn.

In the prototype motor made by the Finnish team, the carbon nanotube yarns are spun and converted into an isolated tape by a Japanese-Dutch company Teijin Aramid. (The actual spinning technology was developed in collaboration with Rice University.)  Since this industrial use of the carbon nanotube yarn is still at its early stages, the production capacity has not been ramped up. This will have to be addressed if the new wire is to replace the ubiquitous copper windings.

However, the performance improvements are significant enough to warrant at least an investigation into whether it can become a realistic replacement for copper wiring.

"There is a significant improvement potential in the electrical machines, but we are now facing the limits of material physics set by traditional winding materials,” said Dr. Marcin Otto, business development manager of Teijin Aramid, in the press release. “We expect that in the future, the conductivity of carbon nanotube yarns could be even three times the practical conductivity of copper in electrical machines. In addition, carbon is abundant while copper needs to be mined or recycled by heavy industrial processes."

Sounds as though there’s a company that has a firm belief in the potential of their product in this application. And with the potential to put a big dent in the 45 percent of global electricity consumption that comes from the use of electrical motors, why not be confident?

A video of the motor equipped with the carbon nanotube windings is below.

source: http://spectrum.ieee.org/nanoclast/semiconductors/nanotechnology/carbon-nanotube-yarns-set-to-replace-copper-windings-in-electric-motors

We've now had a few days to get back into a normal routine after the excitement of the Outback Challenge last week, so I thought this is a good time to write up a report on how things went for team I was part of, CanberraUAV. There have been plenty of posts already about the competition results, so I will concentrate on the technical details of our OBC entry, what went right and what went badly wrong.

For comparison, you might like to have a look at the debrief I wrote two years ago for the 2012 OBC. In 2012 there were far fewer teams, and nobody won the grand prize, although CanberraUAV went quite close. This year there were more than 3 times as many teams and 4 teams completed the criterion for the challenge, with the winner coming down to points. That means the Outback Challenge is well and truly "done", which reflects the huge advances in amateur UAV technology over the last few years.

The drama for CanberraUAV really started several weeks before the challenge. Our primary competition aircraft was the "Bushmaster", a custom built tail dragger with 50cc petrol motor designed by our chief pilot, Jack Pittar. Jack had designed the aircraft to have both plenty of room inside for whatever payload the rest of the team came up with, and to easily fit in the back of a station wagon. To achieve this he had designed it with a novel folding fuselage. Jack (along with several other team members) had put hundreds of hours into building the Bushmaster and had done a great job. It was beautifully laid out inside, and really was a purpose built Outback Challenge aircraft.

Just a couple of days after our D3 deliverable was sent in we had an unfortunate accident. A member of our local flying club was flying his CAP232 aerobatic plane at the same time we we were doing a test mission, and he misjudged a loop. The CAP232 loop went right through the rear of the Bushmaster fuselage, slicing it off. The Bushmaster hit the ground at 180 km/h, with predictable results.

Jack and Greg set to work on a huge effort to build a new Bushmaster, but we didn't manage to get it done in time. Luckily the OBC organisers allowed us to switch to our backup aircraft, a VQ Porter 2.7m RTF with some customisations. We had included the Porter in our D2 deliverable just in case it was needed, and already had plenty of autonomous hours up on it as we had been using it as a test aircraft for all our systems. It was the same basic style as the Bushmaster (a petrol powered tail dragger), but was a bit more cramped inside for fitting our equipment and used a bit smaller engine (a DLE35).

Strategy

Our basic strategy this year was the same as in 2012. We would search at a relatively low altitude (100m AGL this year, compared to 90m AGL in 2012), with a interleaved "mow the lawn" pattern. This year we setup the search with 60% overlap compared with 50% last year, and we had a longer turn around area at the end of each search leg to ensure the aircraft got back on track fully before it entered the search area. With that search pattern and a target airspeed of 28m/s we expected to cover the whole search area in 20 minutes, then we would cover it again in the reverse direction (with a 50m offset) if we didn't find Joe on the first pass.

As with 2012 we used an on-board computer to autonomously find Joe. This year we used an Odroid-XU, which is a quad core system running at 1.6GHz. That gave us a lot more CPU power than in 2012 (when we used a pandaboard), which allowed us to use more CPU intensive image recognition code. We did the first level histogram scanning at the full camera resolution this year (1280x960), whereas in 2012 we had run the first level scan at 640x480 to save CPU. That is why we were happy to fly a bit higher this year.

While the basic approach to image recognition was the same, we had improved the details of the implementation a lot in the last two years, with hundreds of small changes to the image scoring, communications and user interface. Using our 2012 image data as a guide (along with numerous test flights at our local flying field) we had refined the cuav code to provide much better object discrimination, and also to cope better with communication failures. We were pretty confident it could find Joe very reliably.

The takeoff

When the running order was drawn from a hat we were the 2nd last team on the list, so we ended up flying on the Friday. We'd been up early each morning anyway in case the order was changed (which does happen sometimes), and we'd actually been called out to the airfield on the Thursday afternoon, but didn't end up flying then due to high wind.

Our time to takeoff finally came just before 8am Friday morning. As with 2012 we did an auto takeoff, using the new tail-dragger takeoff coded added to APM:Plane just a couple of months before.

Unfortunately the takeoff did not go as planned. In fact, we were darn lucky the plane got into the air at all! As soon as Jack flicked the switch on the transmitter to put the plane into AUTO it started veering left on the runway, and nearly scraped a wing as it limped it's way into the air. A couple of seconds later it came quite close to the tents where the OBC organisers and our GCS was located.

It did get off the ground though, and missed the tents while it climbed, finally switching to normal navigation to the 2nd waypoint once it got to an altitude of 40m. Jack had his finger on the switch on the transmitter which would have taken manual control and very nearly aborted the takeoff. This would have to go down as one of the worst takeoffs in OBC history.

So why did it go so badly wrong? My initial analysis when I looked at the logs later was that the wind had pushed the plane sideways. After examining the logs more carefully though I discovered that while the wind did play a part, the biggest issue was the compass. For some reason the compass offsets we had loaded were quite different from the ones we had been testing with in all our flights in Canberra. I still don't know why the offsets changed, although the fact that we had compass learning enabled almost certainly played a part. We'd done dozens of auto takeoffs in Canberra with no issues, with the plane tracking beautifully down the center line of the runway. To have it go so badly wrong for the flight that matters was a disappointment.

I've decided that the best way to fix the issue for future flights is to make the auto takeoff code completely independent of the compass. Normally the compass is needed to get an initial yaw for the aircraft while it is not moving (as our hobby-grade GPS sensors can't give yaw when not moving), and that initial yaw is used to set the ground heading for the takeoff. That means that with the current code, any compass error at the time you change into AUTO will directly impact the takeoff.

Because takeoff is quite a short process (usually 20s or less), we can take an alternative approach. The gyros won't drift much in 20s, so what we can do is just keep a constant gyro heading until the aircraft is moving fast enough to guarantee a good GPS ground track. At that point we can add whatever gyro based yaw error has built up to the GPS ground course and use that as our navigation heading for the rest of the takeoff. That should make us completely independent of compass for takeoff, which should solve the problem for everyone, rather than just fixing it for our aircraft. I'm working on a set of patches to implement this, and expect it to be in the next release.

Note that once the initial takeoff is complete the compass plays almost no role in the flight of a fixed wing plane if you have the EKF enabled, unless you lose GPS lock. The EKF rejected our compass as being inconsistent, and happily got correct yaw from the fusion of GPS velocity and other sensors for the rest of the flight.

The search

After the takeoff things went much more smoothly. The plane headed off to the search area as planned, and tracked the mission extremely well. It is interesting to compare the navigation accuracy of this years mission compared to the 2012 mission. In 2012 we were using a simple vector field navigation algorithm, whereas we now use the L1 navigation code. This year we also used Paul's EKF for attitude and position estimation, and the TECS controller for speed/height control. The differences are really remarkable. We were quite pleased with how our Mugin flew in 2012, but this year it was massively better. The tracking along each leg of the search was right down the line, despite the 15 knot winds.

Another big difference from 2012 is that we were using the new terrain following capability that we had added this year. In 2012 we used a python script to generate our waypoints and that script automatically added intermediate waypoints to follow the terrain of the search area. This year we just set all waypoints as 100 meters AGL and let the autopilot do its job. That made things a lot simpler and also resulted in better geo-referencing and search area coverage.

On our GCS imaging display we had 4 main windows up. One is a "live" view from the camera. That is setup to only update if there is plenty of spare bandwidth on our radio links, and is really just there to give us something to watch while the imaging code does its job, plus to give us some situational awareness of what the aircraft is tracking over.
The second window is the map, which shows the mission flight path, the geo-fence, two plane icons (AHRS position estimate and GPS position estimate) plus overlays of thumbnails from the image recognition system of any "interesting" objects the Odroid has found.

The 3rd window is the "Mosaic" window. That shows a grid of thumbnails from the image recognition system, and has menus and hot-keys to allow us to control the image recognition process and sort the thumbnails in various ways. We expected Joe to have a image score of over 1000, but we set the threshold for thumbnails to display in the mosaic as 500. Setting a lower threshold means we get shown a lot of not very interesting thumbnails (things like oddly shaped tree stumps and patches of dirt that are a bit out of the ordinary), but at least it means we can see the system is working, and it stops the search being quite so boring.

The final window is a still image window. That is filled with a full resolution image of whatever image we have selected for download from the aircraft, allowing us to get some context around a thumbnail if we want it. Often it is much easier to work out what an object is if you can see the surroundings.

On top of those imaging windows we also have the usual set of flight control windows. We had 3 laptops setup in our GCS tent, along with a 40" LCD TV for one of the laptops (my thinkpad). Stephen ran the flight monitoring on his laptop, and Matt helped with the imaging and the antenna tracker from his laptop. Splitting the task up in this way helped prevent overload of any one person, which made the whole experience more manageable.

On Stephens laptop he had the main MAVProxy console showing the status of the key parts of the autopilot, plus graphs showing the consistency of the various subsystems. The ardupilot code on Pixhawk has a lot of redundancy at both the sensor level and at the higher level algorithm level, and it is useful to plot graphs showing if we get any significant discrepancies, giving us a warning of a potential failure. For this flight everything went smoothly (apart from the takeoff) but it is nice to have enough screens to show this sort of information anyway. It also makes the whole setup look a bit more professional to have a few fancy graphs going :-)

About 20 minutes after takeoff the imaging system spotted Joe lying in his favourite position in a peanut field. We had covered nearly all of the first pass across the search area so we were glad to finally spot him. The images were very clear, so we didn't need to spend any time discussing if it really was Joe or not.

We clicked the "Show Position" menu item we'd added to the MAVProxy map, which pops up a window giving the position in various coordinate systems. Greg passed this to the judges who quickly confirmed it was within the required 100 meters of Joe.

The bottle drop

That initial position was only a rough estimate though. To refine the position we used a new trick we'd added to MAVProxy. The "wp movemulti" command allowed us to move and rotate a pre-defined confirmation flight pattern over the top of Joe. That setup the plane to fly a butterfly pattern over Joe at an altitude of 80 meters, passing over him with wings level. That gives an optimal set of images for our image recognition system to work with, and the tight turns allow the wind estimation algorithm in ardupilot to get an accurate idea of wind direction and speed.

In the weeks leading up to the competition we had spent a lot of time refining our bottle drop system. We realised the key to a good drop is timing consistency and accurate wind drift estimation.

To improve the timing consistency we had changed our bottle release mechanism to be in two stages. The bottle was held to the bottom of the Porter by two servos. One servo held the main weight of the bottle inside a plywood harness, while the second servo was attached to the top of the parachute by a wire, using a glider release mechanism.

The idea is that when approaching Joe for the drop the main servo releases first, which leaves the bottle hanging beneath the plane held by the glider release servo with the parachute unfurled. The wind drags the bottle at an angle behind the plane for 2 seconds before the 2nd servo is released. The result is much more consistent timing of the release, as there is no uncertainty in how long the bottle tumbles before the chute unfolds.

The second part of the bottle drop problem is good wind drift estimation. We had decided to use a small parachute as we were not certain the bottle would withstand the impact with the ground without a chute. That meant significant wind drift, which meant we really had to know the wind direction and speed quite accurately, and also needed some data on how fast the bottle would drift in the wind.

In the weeks before the competition we did a lot of bottle drops, but the really key one was a drop just a week before we left for Kingaroy. That was the first drop in completely still conditions, which meant it finally gave us a "zero wind" data point, which was important in calculating the wind drift. Combining that drop with some previous drop results we came up with a very simple formula giving the wind drift distance for a drop from 80 meters as 5 times the wind speed in meters/second, as long as we dropped directly into the wind.

We had added a new feature to APM:Plane to allow an exact "acceptance radius" for an individual waypoint to be set, overriding the global WP_RADIUS parameter. So once we had the wind speed and direction it was just a matter of asking MAVProxy to rotate the drop mission waypoints to match the wind (which was coming from -121 degrees) and to set the acceptance radius for the drop to 35 meters (70 meters for zero wind, minus 7 times 5 for the 7m/s wind the EKF had estimated).

The plane then slowed to 20m/s for the drop, and did a 350m approach to ensure the wings were nice and level at the drop point. As the drop happened we could see the parachute unfurl in the camera view from the aircraft, which was a nice confirmation that the bottle had been successfully dropped.

The mission was setup for the aircraft to go back to the butterfly confirmation pattern after the drop. We had done that to allow us to see where the bottle had actually landed relative to Joe, in case we wanted to do a 2nd drop. We had 3 bottles ready (one on the plane, two back at the airfield), and were ready to fit a new bottle and adjust the drop point if we'd been too far off.

As soon as we did the confirmation pass it became clear we didn't need to drop a 2nd bottle. We measured the distance of the bottle to Joe as under 3 meters using the imaging system (the judges measured it officially as 2.6m), so we asked the plane to come back and land.

The landing

This year we used a laser rangefinder (a SF/02 from LightWare) to help with the landing. Using a rangefinder really helps ensure the flare is at the right altitude and produces much more consistent landings.

The only real drama we had with the landing was that we came in a bit fast, and ballooned more than it should have on the flare. The issue was that we hadn't used a shallow enough approach. Combined with the quite strong (14 knot) cross-wind it was an "interesting" landing.

We also should have set the landing point a bit closer to the end of the runway. We had put it quite a way along the runway as we weren't sure if the laser rangefinder would pick up anything strange as it crossed over the road and airport boundary fence, but in hindsight we'd put the touchdown point a bit too close to the geofence. Full size glider operations running at the same time meant only part of the runway was available for OBC teams to use.

The landing was entirely successful, and was probably better than a manual landing would have been by me in the same wind conditions (I'm only a mediocre pilot, and landings are my weakest point), but we certainly can do better. Paul Riseborough is already looking at ways to improve the autoland to hopefully produce something that produces a round of applause from spectators in future landings.

Radio performance

Another part of the mission that is worth looking at is the radio performance. We had two radio links to the aircraft - one was a RFD900 900MHz radio, and that performed absolutely flawlessly as usual. We had around 40 dB of fade margin at a range of over 6km, which is absolutely huge. Every team that flew in the OBC this year used a RFD900, which is a great credit to Seppo and the team at RFDesign.

The 2nd radio was a Ubiquity Rocket M5, which is a 5.8GHz ethernet bridge. We used an active antenna tracker this year for the 5.8GHz link, with a 28dBi MIMO antenna on the ground, and a 10dBi MIMO omni antenna in the aircraft (the protrusion from the top of the fuselage is for the antenna). The 5.8GHz link gave us lots of bandwidth for the images, but was not nearly as reliable as the RFD900 link. It dropped out 6 times over the course of the mission, with the longest dropout lasting just over a minute. The dropouts were primarily caused by magnetometer calibration on the antenna tracker - during the mission we had to add some manual trim to the tracker to improve the alignment. That worked, but really we should have used a ground antenna with a bit less gain (maybe around 24dBi) to give us a wider beam width.

Another alternative would have been to use a lower frequency. The 5.8GHz Rocket gives fantastic bandwidth, but we don't really need that much bandwidth for our system. The Robota team used 2.4GHz Ubiquity radios and much simpler antennas and ended up with a much better link than we had. The difference in path loss between 2.4GHz and 5.8GHz is quite significant.

The reason we didn't use the 2.4GHz gear is that we do most of our testing at a local MAAA flying club, and we know that if someone crashes their expensive model while we have a powerful 2.4GHz radio running then there will always be the thought that our radio may have caused interference with their 2.4GHz RC link.

So we're now looking into the possibility of using a 900MHz ethernet bridge. The Ubiquity M900 looks like a real possibility. It doesn't offer nearly as much bandwidth as the 5.8GHz or 2.4GHz radios as Australia only has 13MHz of spectrum available in the 900MHz band for ISM use, but that should still be enough for our application. We have heard that the spread spectrum M900 doesn't significantly interfere with the RFD900 in the same band (as the RFD900 is a TDM frequency hopping radio), but we have yet to test that theory.

Alternatively we may use two RFD900s in the same aircraft, with different numbers of hopping channels and different air data rates to minimise interference. One would be dedicated to telemetry and the other to image data. A RFD900 at 128kbps should be plenty for our cuav imaging system as long as the "live camera view" window is set to quite a low resolution and update rate.

Team cooperation

One of the most notable things about this years competition was just how friendly the discussions between the teams were. The competition has a great spirit of cooperation and it really is a fantastic experience to work closely with so many UAV developers from all over the world.

I don't really have time to go through all the teams that attended, but I do want to mention some of the highlights for me. Top of the list would have to be meeting Ben and Daniel Dyer from team SFWA. They put in an absolutely incredible effort to build their own autopilot from scratch. Their build log at http://au.tono.my/log/index.html is incredible to read, and shows just what can be achieved in a short time with enough talent. It was fantastic that they completed the challenge (the first team to ever do so) and I look forward to seeing how they take their system forward.

I'd also like to offer a tip of the hat to Team Swiss Fang. They used the PX4 native stack on a Pixhawk and it was fantastic to see how far they pushed that autopilot stack in the lead up to the competition. That is one of the things that competitions like the OBC can do for an autopilot - push it to much higher levels.

Team OpenUAS also deserves a mention, and I was especially pleased to meet Christophe who is one of the key people behind the Paparrazzi autopilot. Paparrazzi is a real pioneer in the field of amateur autopilots. Many of the posts we make on "ardupilot has just achieved X" on diydrones could reasonably be responded to by saying "Paparrazzi did that 3 years ago". The OpenUAS team had bad luck in both the 2012 competition and again this year. This time round it was an airspeed sensor failure which led to a crash soon after takeoff which is really tragic given the effort they have put in and the pedigree of their autopilot stack.

The Robota team also did very well, coming in second behind our team. Particularly impressive was the performance of the Goose autopilot on a quite small foam plane in the wind over Kingaroy. The automatic landing was fantastic. The Robota team used a much simpler approach, just using a 2.4GHz Ubiquity link to send a digital video stream to 3 video monitors and having 3 people staring at those screens to find Joe. Extremely simple, but it worked. They were let down a bit by the drop accuracy in the wind, but a great effort done with style.

I was absolutely delighted when Team Thunder, who were also running APM:Plane, completed the challenge, coming in 4th place. They built their system partly on the image recognition code we had released, which is exactly what we hoped would happen. We want to see UAV developers building on each others work to make better and better systems, so having Team Thunder complete the mission was great.

Overall ardupilot really shone in the competition. Over half the teams that flew in the competition were running ardupilot. Our community has shown that we can put together systems that compete with the best in the world. We've come a long way in the last few years and I'm sure there is a bright future for more developments in the UAV S&R space that will see ardupilot saving lives on a regular basis.

Thank you

On behalf of CanberraUAV I'd like to offer a huge thank you to the OBC organisers for the massive effort they have put in over so many years to run the competition. Back in 2007 when the competition started it took real insight for Rod Walker and Jon Roberts to see that a competition of this nature could push amateur UAV technology ahead so much, and it took a massive amount of perseverance to keep it going to the point that teams were able to finally complete the competition. The OBC has had a huge impact on amateur UAV technology.

We'd also like to thank our sponsors, 3DRobotics, who have been a huge help for CanberraUAV. We really couldn't have done it without you. Working with 3DR on this sort of technology is a great pleasure.

Next steps

Completing the Outback Challenge isn't the end for CanberraUAV and we are already starting discussions on what we want to do next. I've posted some ideas on our mailing list and we would welcome suggestions from anyone who wants to take part. We've come a long way, but we're not yet at the point where putting together an effective S&R aircraft is easy.

A few weeks ago I made Public my latest project The Explorer 4, Since then I have had many emails asking how to build it even cheaper. How to save money on the Electronics?

Many people who are just starting out dont need a Taranis radio or FPV gear with gimball, they just want to learn to fly. I have Put together a Different parts list to be used with my frame that will get the quad flying for about 450usd including Transmitter/reciever and charger.

Due to the fact that the quad is designed to be a DIY project you can start with this basic setup and slowly add the Different motors, FPV gear and gimball as you wish.

Here is the link to the Parts list I have made: http://explorer4-quadcopter.com/?page_id=230

Let me know what you think.

I think the trouble with an awful lot of multirotor footage is that its all about the multirotor footage. I see way too many zoom climbs, reveals and drone films XYZ from above its just dull. I have a feeling the general viewing public is also getting used to it so for late arrivals they are going to have to work hard to get noticed.

This short film of Scottish cycling genius Danny MacAskill uses the RPAS to get the job done but does it in a way that adds to the story rather than being the centre of attention. Anybody that knows about Munros has heard the reputation the Cuillin Ridge has.

Of course all shot commercially and perfectly legally in the UK. Job well done Lec Park.

If you happen to be in the UK there will be a 30 minute documentary of the making of next Friday, look out for it on iPlayer.

Here's another Danny movie for those that are only hearing about him for the first time in this post

(Right-click here to download the first RAW video file in its native 324 resolution.)

(Right-click here to download the second RAW video file in its native 324 resolution.)

ConservationDrones tested a backpack for the FLIR Tau 2 Cores, which allows RAW digital data output from the FLIR to be recorded onto a USB stick (both video and stills). Not only is this digital video much clearer than a conventional analog output from the FLIR, but it also allows the user to read the temperature of each pixel on the video or still image using an accompanying ThermoViewer software! Additionally we can also parse flight data, such as GPS coordinate and altitude, directly onto the digital recording.

Markus Ax and Stephen Thamke are the two young founders and managing directors of the Germany-based start-up, TeAx Technology, who kindly provided us with a demo unit of this ThermalCapture backpack that they developed.  They are super responsive on the emails as well.

For this particular test, we were using a FLIR Tau 2 – 324 with 9 mm lens at 8.3 Hz refresh rate. The FLIR core, ThermalCapture and a dedicated battery weigh only 233 g! They were carried by a 3DR X8 multirotor. In the first video, it was flying at about 25 m above ground filming Serge Wich in the field. In the second video, the X8 started flying towards some cows in a field from about 100 m away.

Features at a glance:

• Store Digital RAW data on your USB-Stick
• No transmission errors in images any longer
• Hardware update possible for every existing FLIR camera
• Provides position and time (GPS) based on UAV downlink
• Weighs only 45g including housing
• Easy post-production due to free ThermalCapture software
• Auto conversion feature to reduce time
• Customer requests can be added at any time

This post looks at the top line results of the poll I did on drone delivery service - how much would you pay?

---

What do medicine, batteries, and forgotten anniversary gifts have in common?  They are the most likely items consumers will want delivered by drone once that service is available.  At least, that’s the verdict from the consumers I surveyed in August and September of this year. In my post Drone Delivery: How Much Would You Pay?, I ran a poll with three simple questions:

1. What’s the maximum amount you would be willing to pay for a package delivered by drone?
2. Which of ten items would you want delivered in 30 minutes?
3. Under what circumstance would you need something so quickly that you’d pay top dollar for it?

These are the top line results.  Read more here: http://droneanalyst.com/2014/10/02/drone-delivery-numbers/

You can see the companion summary presentation with more complete graphs and charts of the data here: http://www.slideshare.net/ColinSnow/drone-delivery-bythenumbers

He's 14 years old. The mind boggles.

From IEEE Spectrum:

Mihir Garimella, from Pittsburgh, (video above) figured out a way to make flying robots evade collisions with obstacles, moving and nonmoving, by behaving like fruit flies. Garimella got the idea for his system when his family returned from a trip, to find rotten bananas on a counter and a house full of fruit flies that seemed to be able to brilliantly evade swatting. Garimella’s uses the simple vision system of a fruit fly to allow an onboard computer to quickly detect and analyze a coming threat, and wrote algorithms to mimic the fruit fly’s tendency to dodge by moving first horizontally, then vertically to escape to the threat. Garmilla’s project won top honors in the 13-14 age group and the computer science award.

His full, and amazing, report is here. Summary:

Noting the limitations of approaches presented by previous work, I aimed to create a simpler, faster, and more practical method of onboard threat evasion, inspired by the way fruit flies detect and respond to threats. After reviewing relevant work in the fields of biology and robotics, I designed a computationally and physically lightweight sensor module, modeled after the fruit fly's rudimentary but fast visual system. I also created novel algorithms to model the trajectory of and escape from approaching threats by mimicking fruit fly escape behaviors, and verified the effectiveness of these algorithms both experimentally and through a still image comparison to fruit fly escape.

Team Thunder is a Sydney based team of RC enthusiasts who competed in this year's UAV Outback Search and Rescue Challenge in Kingaroy, Queensland, Australia, running the week of September 22-26, 2014. (http://www.uavoutbackchallenge.com.au/). The following is a description of our mission flight. A more technical report will follow.

The Flight

Friday came around and finally it was Team Thunder’s turn to find Joe. 

The wind was picking up over 15 knots but we knew our X8 flying wing was up for it.

Setup went smooth enough until the GCS operator (Peter) discovered that the USB serial link to the RFD900 radio link wasn’t being recognised by the Windows GCS laptop. A reboot but Windows wouldn’t start up again. A little bit of panic and thinking “What will Tridge think of these fools who decided to rely on Windows for a mission critical device?” A quick change to Marks backup PC got things going again. Luckily Windows eventually started on the main GCS PC again so things were back on track.

A bit of a time out due to air traffic, then started again and we had the plane on the launcher at the end of setup time. David had all the flight systems up, Mark had the bungee loaded, Lloyd had the image recognition system up running and communicating over the 3G and RFD900 links. The GCS was all ready to go so the thumbs up was given to the pilot Tim pushed the lever on the launcher. 9:00am and Thunderbird 1 was away.

https://www.facebook.com/video.php?v=841139339252746

Before we knew it, the plane was passing EL1 and then EL2 into the search area. Smiles all round. This was exciting. 

As there was a strong south-westerly blowing we had decided on north south runs, starting from the east to avoid overshooting downwind turns. We would be flying at 120m AGL, scanning 100m strips, leaving 50m gaps between the strips on the first pass that would be cleaned up on the second pass.

The first downwind turn was a little nerve racking but were soon at the north-eastern end of the search area and into our search runs.

Things were going well. Although it was windy and the plane was jumping around a bit, it was doing what it was meant to be doing and the upwind turns were working out ok.

Midway through the 3rd scan run and only 12 minutes into the mission, Mark called out that he had an automatic (thanks to Tridge’s algorithm) Joe position.

With a set of coordinates from Lloyd we got them away to the judges who passed on permission for us to drop the bottle.

We then passed over the Joe a number of times to get a more accurate averaged position. We uploaded the bottle drop waypoints. We were taking things very slowly and carefully now. We had heaps of battery and though the wind was strong, the X8 was handling it ok. Once we were happy we set off the sequence with a predefined routine from the GCS and the command “godrop” was given. Soon the bottle was away and Thunderbird 1 was on its way back to the airfield.

The marshals confirmed that the package separated from the aircraft ok to our relief.

3 minutes later, Thunderbird 1 was spotted approaching the airfield, ready to attempt an automatic landing. We underestimated the wind a little on our east-west landing at the end of the runway ending up in the long grass but a safe landing in one piece nonetheless.

https://www.facebook.com/video.php?v=841151805918166

The BOM recorded maximum wind for Friday was 43 km/h at 09:34. This was just as we landed.

The judges confirmed we had dropped the bottle within 100m of Joe and that 500ml of water had been recovered. Mission accomplished.

More details including documents, Joe Recognition System and flight logs to follow.

Team Thunder (left to right)

Tim Fu: Pilot and airframe
Lloyd Breckenridge:  Joe detection system
Peter Wlodarczyk: Leader and software
Mark Frasca: Search, bottle drop and airframe
David Creusot: Avionics

Acknowledgements:

Andrew Tridgell and Canberra UAV:  For the extraordinary open sourcing of everything they did, including APM software, MAVProxy, simulation environment, Joe recognition algorithm, RFD900 radio firmware, Joe image sets as well as advice during the course of the competition.

Michael Oborne: Developer of Mission Planner

The general Ardupilot developer community.

Orion Integration (http://www.orionintegration.com.au) : For the use of radios and camera and the tolerance of skunkworks by Lloyd.

Claudio Natoli: For the kind loan of a failsafe board.

Millswood Engineering (http://www.millswoodeng.com.au): For the design and kind donation of a spare failsafe board.

Seppo at RFDesign  (http://rfdesign.com.au): For an awesome RFD900 radio design and advice.

Hawkesbury Model Air Sports (HMAS) Club (http://www.hmas.org.au): Support, encouragement and an excellent field at Vineyards.

This video shows automated Hover-In-Place (HIP) using the PyQuadSim Python Quadrotor Simulator with OpenCV for optical flow.  This setup allows us to prototype HIP and other optical-flow-based algorithms for use with an actual optical-flow sensor like the PX4Flow.

The quadrotor is being flown over a simulated concrete floor using a FrSky R/C transmitter, allowing us to switch position-hold (HIP) on/off.  The small black window shows the pitch/roll/yaw/climb demands from the transmitter. The small gray window shows the optical flow computed by OpenCV from a downward-facing 128x128-pixel vision sensor created in V-REP.  (If you look carefully, you'll see that the side-to-side flow is backwards in the video. I have since corrected this problem in the online code.)

The position-hold signal is computed as the average X,Y pixel flow sampled every 16 pixels, converted to meters-per-second using trigonometry.  The second part of the video shows HIP facing a "breeze" from a blower.  Even without Kalman filtering or other smoothing, the optical-flow signal is sufficient to keep the vehicle more or less stationary.

This project is open source and available at

  http://home.wlu.edu/~levys/software/pyquadsim/

I was wondering how feasible it would be for a drone to deliver long distance by hitching a ride

by a passing train or transport etc... And getting off at the next building.

Maybe one day people will have personal drones to deliver our eBay sales etc, this way?

What is your idea about it ?

I feel like testing a flight by hopping on a passing train then drive to the next city

and have it fly hope off to me again. Going to ask my local train company permission to try or

I could just do like a hobo and call my drone the hobo drone. 

I'm delighted to announce that the Small UAV Coalition, an industry group led by 3DR, Amazon, Google, DJI, Parrot and Airware, is now up and running. You can visit the website here. 

The mandate of the group is as follows:

The Small UAV Coalition advocates for law and policy changes to permit the operation of small unmanned aerial vehicles (UAVs) beyond the line-of-sight, with varying degrees of autonomy, for commercial, consumer, recreational and philanthropic purposes.  Our members, including leading consumer and technology companies such as 3DR, Airware, Amazon Prime Air, DJI Innovations, Google[x], GoPro, and Parrot, believe that U.S. leadership in the research, development, and production of unmanned aerial vehicles will benefit consumers in all walks of life. We believe that, working together, we will be able to remove unnecessary policy or regulatory hurdles that impede small UAV development, sales, job creation, and services.

The Coalition is being run by the Washington DC law firm of Akin Gump, with a full professional staff, including former FAA officials. In my 3DR CEO role, I'm also the Chairman of the Coalition.