I was delighted when Mark Bolt of BoltRC rang me up recently and offered to send me a TechPod to review. I'd been looking at the TechPod as a possible search aircraft for long distance search and rescue tasks, which is an interest of mine, so I jumped at the chance to give it a try!
After spending quite some time building the TechPod I finally took it for a first flight yesterday. With a small bit of tuning it flew very nicely, but it does have some quirks that are worth noting that affect tuning it for auto flight with an APM, so I thought I'd write up a tuning guide as part of this review in the hope that it will help other TechPod owners.

Building the TechPod

First a bit of information about the build. I'm not a really experienced builder and I had heard the TechPod is a challenging build, so I was expecting some difficulties. I've only built about 10 ARF planes since getting into the hobby and the TechPod is certainly the most difficult build I've done.
Luckily there are some good online resources to help with the build. Wayne's build videos are great, although very long and as such not ideal to use as a reference when you hit a tricky part of the build. I found Mark's build log the most useful guide.
All up I spent well over 20 hours on the build (including APM install), although I suspect if I built another one then that would probably come down to under 5 hours. It isn't a build that can be rushed too much as there are a number of steps where you need to wait for epoxy to fully dry.

I made a few small changes to the recommended build:

• I used 15 minute epoxy instead of JB-Weld, as JB-Weld wasn't available locally in Canberra. The epoxy worked well.
• I used UHU Por for foam gluing (eg. wings), which worked nicely.
• I only glued one half of the main pod onto the frame, and held the other half on with tightly applied 20mm fiber tape on all seams. That will allow me to more easily open up the fuselage if I want to make more internal changes (eg. changing the motor).
• I didn't use the glass fiber when gluing the motor mount to the frame, and just used epoxy. It is plenty strong enough with the small G10 motor I'm using.
• I used a tape hinge at the front to hold the pod hatch on, and fabric pins at the back. That reduced the metal near the compass, and is faster and easier to open the pod up. It is a tight fit, so I'm very confident it will hold well. I'm not planning on flying this plane inverted!

With a 4S 5Ah LiPo installed the total weight came to 2.0 Kg.
One of the trickier parts of the build is running the elevator servo cable up the vertical stabilizer. This is the technique I used in case it helps anyone else:

• pushed the rudder control rod through the vertical stabilizer for the initial hole
• expanded the hole by pushing a chopstick in from both ends, pulling it back out with pliers
• folded over a coat-hanger and pushed it through the hole, then put the servo cable through the coat-hanger wire loop and pulled on the coat-hanger wire to bring the wire back through the channel

(the TechPod doesn't like to share the couch)

Installing an APM

Once the TechPod was built I needed to install an APM, airspeed sensor, GPS, battery etc. I stared at the pod cavity for about 10 minutes before I found a decent layout. The problem is that the internals of the pod is mostly curved surfaces, which is not great for mounting an autopilot. I finally realized that one of the side surfaces of the pod is flat, and the perfect size for an APM, so with a bit of velcro I ended up with an install that looks like this:

The ESC is installed on the opposite wall of the pod from the APM, leaving the mid section with enough room to put a hand in to get at the cables right at the back, also held on with velcro. The GPS/Compass combo is installed with clear view of the sky on top, on a little flat area I cut out with a hobby knife then held together with fiber tape.
For the airspeed sensor I originally thought I'd put it on a wing, but it looked like the cable tangle when putting on the wings at the field was already going to be quite bad, so I decided to instead keep it in the pod, protruding out the front of the camera dome. I used a screwdriver to bore a small hole in the foam to hold the pitot tube, which you can see in the lower right corner of the photo. The flight logs showed that this position works very well, with not much positional error in the airspeed reading.
I mounted the telemetry radio on the right wall of the pod, next to the battery, with the antenna poking out the bottom of the pod by a few millimeters, but not far enough that it will scrape on the ground on landing. Having the antenna pointing down is always a bonus, as the ground control station is usually below the aircraft.
The battery was a bit of a trouble to install at first. I like my batteries to be very secure, and I found that the single surface available for velcro on the bottom of the battery didn't hold it well enough, especially with the gap in the foam floor for the downward facing camera port. I ended up using a rubber band plus wire hook harness as extra security in addition to the velcro, with the rubber band going right through the pod base on either side of the battery.
For the flaps, I set them up with about 35 degree full deflection and controlled by a transmitter knob (using two channels, as the flap layout is unfortunately setup on the wing without the right reversal). I often setup flaps with manual control like this so I can easily see the impact of the flaps while flying. They can be moved to auto-flaps later once you know how they behave.
I setup the CoG at the recommended position below the wing spar, although I later found that may not be ideal.

Initial Parameters

I decided to takeoff for the first test flight in FBWA mode, then to switch to manual to trim the plane. For that I needed some basic conservative roll and pitch stabilisation gains.
To get these initial parameters I looked at the parameters that Wayne used for his recent 170 minute flight, plus some advice Mark provided on what he found worked well in manual and set the following parameters:

RLL2SRV_P        0.80
RLL2SRV_I        0.00
RLL2SRV_D        0.02

PTCH2SRV_P       0.60
PTCH2SRV_I       0.00
PTCH2SRV_D       0.02

I wasn't expecting these to fly the plane well, I just wanted it to get in the air for an initial tuning session.
So I could try a loiter I also set the airspeed range, which is critical for good flight under airspeed control.

ARSPD_FBW_MAX    18
ARSPD_FBW_MIN    9

Most of the rest I left at default, apart from things like the battery/voltage/current setup and of course the orientation of the APM and compass (I needed AHRS_ORIENTATION=16 and COMPASS_ORIENT=16).

First Flight

I met with three friends from the CanberraUAV team at the CMAC field for the initial test flights. Darrell also owns a TechPod (not built yet), so he was interested in seeing how it flew, plus he offered to get some photos. Chris and Jack offered to help as safety pilots while I did the tuning, which really makes life a lot easier when setting up a new plane with APM. Having two safety pilots is nice when flying a plane that can stay in the air for as long as the TechPod can, as it can get quite tiring standing there for an hour keeping an eye on a plane against the clouds!
The first flight was not a great success, lasting less than 30 seconds, although luckily there was no damage! The throw was fine, but the plane refused to climb even with full elevator. It was quite stable, but stubbornly refused to go above about 2m even with some throttle adjustment, so I just let it glide in to land in the grass. It snagged a wing when it touched down, which resulted in a couple of nicks on the wing, but nothing to worry about.
We then had a chat to try to work out why it wouldn't climb. We think the problem is probably that the horizontal stabilizer is generating a bit too much lift - the exact angle of a horizontal stabilizer is a bit tricky to get right when building a foam plane, and I think mine is presenting too high an angle of attack, causing it to lift up the tail.
I had noticed in Wayne's flight logs that his pitch tuning was pretty bad, with a lot of up elevator applied even when in level flight and the plane not achieving the demanded pitch, so I suspect this problem isn't unique to my plane.


The workaround is very simple though. I made 4 small changes for the next flight:

• moved the battery about 1.5cm further back
• went to 125% throws on the elevator
• applied about 20 degrees of flaps on takeoff
• took off with about 30% throttle

That worked very nicely, and the TechPod took off very easily on it's second flight, climbing steadily to 100m with graceful turns over the field.
It is an interesting plane to fly - similar in many ways to a SkyWalker 1900, but with wings that flap a bit more! It was very easy to steer around the sky in FBWA, and also very easy in manual once I had the surfaces trimmed (I found I needed quite a lot of up elevator trim). I used the TRIM_AUTO method of trimming the surfaces, which consists of:

• set the TRIM_AUTO parameter to 1 before takeoff
• fly in FBWA
• flick to manual, and see how the attitude changes
• change back to FBWA, and then adjust transmitter trims based on what it did in manual
• change to manual again and keep looping until it flies nice and level in manual with no stick input

It is a very low stress way of trimming a new plane.
One thing that became very clear quite quickly was that the motor/battery/prop combination I'd chosen was way overpowered for this plane.  I'd installed a Turnigy G10 810kV motor with a 4S battery and a 12x6 APC prop.  That combination is mentioned by several people as recommended for a TechPod, but it really is far too much, at least with the 2.0Kg flying weight that I had. According to eCalc that gives around 500W of mechanical power, and I think a combination that aims for about 200W or perhaps even less would be a better choice. Most of the second flight I was using less than 75W of electrical power, and given that electric motors are very inefficient when operating well below their peak power I was probably only getting around 37W of mechanical power (eCalc thinks efficiency would be below 50% for this setup at the current I measured).
Luckily being overpowered didn't worry the APM, as the TECS controller just adjusts the throttle down accordingly, so it still flew fine, but it would fly for a lot longer with a better motor setup.

Tuning the roll/pitch loops

Once it was in the air the next job is to tune the roll and pitch loops. It was actually flying OK with my pre-flight guesses, but I knew that how well a plane seems to be flying is often quite deceptive, and you won't get good performance in AUTO and LOITER unless you get the roll and pitch loops properly tuned.
The way to do that is to graph the demanded versus actual pitch and roll. I popped up graphs on the GCS of NAV_CONTROLLER_OUTPUT.nav_roll and ATTITUDE.roll, which is what is needed for roll tuning. It was immediately very obvious the tuning was way off.

as you can see, the TechPod is not following the roll demand at all well. All the gains are far too small, which is quite common for a first flight. It is usually better to guess quite low gains when doing initial setup, as it will avoid oscillations which could make the plane unflyable (and potentially stress the airframe beyond the design limits).
Following the tuning guide, I raised the P, added some I and raised D a bit, and got the following result:

That is much better. It isn't tracking roll exactly when level, but that isn't uncommon in an airframe that is so wind affected. A bit more D might eliminate that, but I left things at the above and moved on to pitch.

The roll gains I ended up with are:

RLL2SRV_P       1.50
RLL2SRV_I       0.10
RLL2SRV_D       0.06
RLL2SRV_IMAX    2500

The initial pitch tuning was as bad, or worse, than the roll.



it obviously needs a lot more gain, as it isn't tracking at all, and wasn't oscillating. Following the same procedure (more P, adjust I, add some D) gave the following:

now the APM is much happier. When it asks for the aircraft to change to a specified roll/pitch the TechPod quickly responds to do exactly what is asked of it.

The pitch tuning I ended up with is:

PTCH2SRV_P      1.50
PTCH2SRV_I      0.10
PTCH2SRV_D      0.04
PTCH2SRV_IMAX   2500

I actually did the above roll/pitch tuning in AUTO, which is a bit unusual. Normally you want to do the initial tuning in FBWA mode, so you don't have any navigation control loops to deal with. I did it in AUTO as I'd tried a brief loiter after takeoff and found it quite stable, so I thought that a full tuning while flying a small rectangular circuit in AUTO would work well, and indeed it did.
I'd also like to point out that if you are reading this and thinking you'll just copy these parameters for your TechPod then please be careful! The correct tuning values are very dependent on lots of factors that tend to vary between airframes of the same type. You might have slower/faster servos than me, or use different holes in the servo horns, or have a different takeoff weight. It is better to start with some low conservative gains then tune it for your airframe than to just grab someone elses gains, otherwise you risk nasty oscillations if the gains you copy are too high for your setup.
Eventually we'd like to add a "auto tuning" mode to the code so you can just change to AUTOTUNE and let it fly for a couple of minutes to tune the plane, but for now you do need to read the tuning guide and tune APM manually.

Tuning Navigation

The next step was to tune the L1 navigation controller. There is really just one parameter that needs to be tuned for L1 for most aircraft, the NAVL1_PERIOD. This defaults to 25, which is higher than most airframes need. The default is chosen for maximum stability with a wide variety of airframes, not for great waypoint tracking. Before takeoff I'd set it down to 18, as I was pretty sure that the TechPod wouldn't need 25, and indeed it worked very well. Here is the first AUTO test track:


I ended up lowering NAVL1_PERIOD a bit more (to 16) later, which helped it cope with higher airspeeds and a bit more wind, but the initial value was certainly good enough.

A quick test of loiter confirmed the settings are working well



Tuning TECS

The next step is to see if TECS is behaving itself. TECS is the new Total Energy Control System which is the speed/height controller in APM. It is very common that the TECS defaults work well, and indeed I found they worked nicely for the TechPod too.
As the TECS tuning guide suggests the main thing to tune is the turn handling, to ensure the aircraft didn't gain or lose too much altitude in turns. I found this was fine already, with a typical altitude change in turns of around 2m or so, which is hardly noticeable when flying at 100m.
The trickier part was tuning TECS for overall altitude hold in the face of gusts and updrafts. When flying at 11m/s this was the result for altitude and airspeed deviation:

The airspeed control is quite good, varying by about 1m/s either side of the target, but the altitude is varying by up to 8m. The strange thing was that this altitude change didn't correspond well to turns. Paul and I looked at this together later and we think what is happening is the TechPod was getting quite strongly affected by updrafts and downdrafts. The logs show quite a few occasions where it had the motor off, and was climbing without losing airspeed. The energy has to be coming from somewhere, and the only likely explanation is a thermal. It really is a glider.
We could try to compensate for this in the tuning if exact altitude hold is critical, but as my aim was for long distance flight I wasn't worried about a few meters of altitude deviation, so I didn't spend any time on it during the flight and just moved on to looking at battery usage at different airspeeds.

Current versus Airspeed

My interest in the TechPod is for search and rescue, where the key is maximizing range, not endurance. That usually means a bit higher airspeed than the speed you would want for maximum endurance.
What I found was a bit surprising, although I will need some more flights to confirm it. I flew the TechPod in an AUTO circuit, slowly raising the target airspeed over a 20 minute period. I started off at 9m/s and raised it up to 18m/s. The following graph shows smoothed airspeed and current draw numbers from the test:
The thing that surprised me is how close to linear the relationship between airspeed and current was over this range. I expected the current to rise a lot faster than the airspeed. It either means we are on the flat part of the power/airspeed curve, or perhaps we are seeing the impact of increased motor efficiency at higher current, combined with the lower drag profile at higher speeds.
As far as how the plane was in the air, it looked very comfortable at 11m/s and above. Below that it wafted about a bit, but above 11m/s it looked nice in the air. Above 18m/s it started to get too twitchy, so I think the comfort zone is 11 to 18m/s (that is 22 to 36 knots).

Maximizing endurance

After this tuning flight (which lasted a bit over 50 minutes) we flew the TechPod again, but this time letting it sit at 10m/s the whole time and just let it fly in a circuit to see what endurance it could achieve.
In total it flew for 71 minutes, with about 20% battery spare at the end (according to my LiPo charger). That is certainly good, but nothing like the 170 minutes that Wayne recorded.
The main difference is I had a much smaller battery. I used a 5Ah 4S whereas Wayne had a 10Ah 6S, which means 3 times as much battery capacity. I suspect Waynes motor was probably running much closer to its optimal operating power too - as I mentioned previously mine was running at about 50% efficiency, whereas 80% should be achievable (at least according to eCalc).
I'll do some more experiments soon with some alternative motor setups to see if I can get a bit more range from the TechPod. I wouldn't be surprised if someone (perhaps Wayne?) posts a 4 hour log soon.

Final comments

It was really fun trying out the TechPod, and I'd like to thank Mark from BoltRC for sending it to me! It is the most affordable long endurance plane that can carry enough camera payload to be useful that I know of, and I think that as long as you don't mind flying in light winds it could indeed be useful for search and rescue tasks.
There are a few ways it could be improved though. I suspect the build could be made a bit simpler. It probably won't get down to the level of building a Bixler2 (which takes around 30 minutes if you have done one before), but I think it could be brought down a lot from the level it is at now.
I also think the horizontal stabilizer might be able to be improved. Paul and I suspect it is giving too much lift, which is pushing the nose down. That will be cutting the flight time a bit. Paul also suggested that the elevator should extend all the way across the stabilizer, which would give more pitch authority, and also be aerodynamically more efficient.
I also think the pod could have a few more flat surfaces in it, and have a bit better layout for equipment.
Overall though it is a very efficient airframe, and works very nicely with APM!

Many thanks to Darrell Burkey, Jack Pittar and Chris Gough for helping with the tests of the TechPod

The CanberraUAV Outback Challenge team has put together a package that will allow anyone to try the image recognition system we developed for our successful 2012 OBC entry. We hope that by releasing this in an easier to use form that other OBC teams and anyone interested in image recognition in UAVs will be able to reproduce what we've done and build upon it for their own systems.

The fundamental problem that our system is meant to solve is providing real-time recognition of objects on the ground from a UAV, while requiring only a low bandwidth radio link between the aircraft and the ground station. A lot of UAVs are run using analog video links from the plane to the ground, but we think that is not a good way to do many search and rescue and environmental tasks. The problems with an analog video link are:

• the quality of the video is often greatly degraded by being sent over the analog link, making it hard to spot small objects
• the task of an operator staring at a video screen for hours is much too hard. The operator may notice something flash by, then has to decide whether to rewind (possibly missing something else in the search) or to skip the object
• in many (most?) parts of the world analog video links may violate local radio licensing regulations

We think the solution is for the aircraft to do an initial pass of image recognition to find "interesting" objects on the ground, and then to show small (low bandwidth) thumbnails of those objects on the ground station, overlaid on a satellite map of the area. The operator can then select which of these thumbnails to look at more closely, bringing down a full high resolution image around that object from the plane over the telemetry link when needed. When using this method the operator gets a complete overview of the search area, and can quickly focus on areas of interest, using the human to decide which of the objects that the computer shows up are worth investigating. That was the strategy we successfully used in our 2012 OBC flight.

Up to now the image recognition code we developed for that competition was fairly deeply embedded in the MAVProxy module we used, making it hard for other teams or UAV researchers to run the algorithm over their own data to see how it performs. So to address that we have now put together a set of packages that can be installed on Linux, Windows or MacOS to try the system for yourself.

The new tool is called geosearch.py, and is a standalone UAV search tool that operates offline on a set of images, using either EXIF positioning data in the images, or a MAVLink telemetry log for geo-referencing. It runs the same code that we use in our real-time system embedded in the aircraft, but converted to run as a local GUI tool on a desktop computer. Note that the algorithms we use are tuned for speed. They are not state of the art computer vision algorithms, but they are fast, allowing them to run in real-time on a low power ARM Linux box embedded in an aircraft. We originally tried to use algorithms from the excellent OpenCV system, but found them too slow for our application. We do however use some OpenCV helper functions in our code to make the system a bit simpler.

Release of data from our OBC flight

As a companion to this tool we have released the images captured from our OBC 2012 flight for anyone to download, along with the telemetry logs and other files needed to reproduce the result. The images are kindly hosted by CSIRO in Australia, and are available from the CSIRO Outback Challenge website.

On that site you will find a set of 20 zip files containing the raw images from our flight. If you download and extract those zip files you will end up with a directory called 'raw' which contains 17042 pgm image files. Those files are 8 bit raw Bayer grid files of 1280x960, which are the raw images from our PtGrey Chameleon camera. We're hoping those files will be useful to anyone wanting a decent sized set of UAV images for research, or for training an algorithm for the next Outback Challenge.

(NOTE: as of the time of writing the CSIRO site has the images as 17k separate image files, those should be converted to the 20 zip files for easier download soon).

We also provide a tool called pgm_convert.py which will take those pgm raw images and convert them to other formats, most commonly to lossless PNG files.

How to try our system for yourself

If you watch the video and want to try our system on your own data, or on the data from our OBC flight, then you will need to install a set of python packages that provide the basic system tools we use in our code.

On Windows you need Python 2.7, plus a set of extra python packages. To make life easier for windows users we have collected all of the packages you need in this directory. Note that this includes both the packages needed to run our tools, and the packages needed to build our tools for yourself for when you want to modify the code.On Linux installing the basic python tools is a bit easier. For example, on an Ubuntu Linux system the following command should be enough:

  sudo apt-get install python-wxgtk2.8 python-matplotlib python-numpy python-pyexiv2 python-opencv python-httplib2 libjpeg-turbo-progs

If you are using MacOS, then you should install a suitable Python 2.7 package first, then use easy_install to add the required additional packages.

Once you have the basic tools installed, the next step is to install the 3 CanberraUAV python packages, pymavlink, MAVProxy and cuav. You can get those packages from the python packaging index:

• https://pypi.python.org/pypi/pymavlink
• https://pypi.python.org/pypi/MAVProxy
• https://pypi.python.org/pypi/cuav

That will allow you to download tar balls or windows installers for each package. If you are going to modify the code, then you will be better off downloading the source from our github repository.

To build the packages yourself (instead of using the pre-built packages), you would use the following commands in each of the 3 package directories. For Linux or MacOS, use this:

  python setup.py build install --user

for Windows use this:

  python setup.py build -c mingw32 install

Note that for building on WIndows you also need to install the MinGW package.

How it all works

To see how it all works, you can either read the code (just follow the above links to our code repository) or you can watch a presentation I gave in January 2012 which explains the algorithm to some extent (video and slides).

We'd also encourage you to ask questions on the CanberraUAV mailing list, or on the Outback Challenge discussion group.

How much bandwidth does it use?

The aim of this system is to allow for real-time UAV search with only a low bandwidth telemetry link to the aircraft. It is possible to run the system with a 64 kbit/s ISM band radio, such as the excellent RFD900 radio.

To make this possible we developed a new network transport protocol called block_xmit (mp4-video, ogg-video, slides, implementation), which allows us to intermix low bandwidth thumbnail images and python objects with normal MAVLink telemetry over a single radio link. The system also scales up to higher bandwidth links, so if you happen to have a high bandwidth ethernet bridge (such as a Ubiquity Bullet) in your aircraft, and you are close enough to the ground station to have a good link, then the system will transmit real-time images that gives the effect of a digital video link. That capability can be seen in the demonstration video above.

The block_xmit protocol also prioritizes images based on the image score from the recognition algorithm, so you can set quite a low threshold for what images to send, and if a high scoring object (such as Joe!) turns up it will jump the queue in the radio link and be shown to the operator quickly.

For our aircraft we combine both types of radio link, with the results of our imaging system coming over both a 5.8GHz Ubiquity ethernet bridge and a 900MHz RFD900 telemetry radio (with smaller thumbnail sizes to save bandwidth). That gives us redundancy in case a particular radio technology does not perform well on the day.

Geo-referencing

Included in the system is a geo-referencing system that uses the MAVLink telemetry stream along with image timestamps to work out the geographic location (latitude/longitude) of any region of interest in the image. These are displayed on the map in various formats (degrees decimal, degrees/minutes/seconds and UTM grid coordinates).

If you instead have a camera with a built-in GPS that tags images with EXIF geo-referencing tags the the code can instead use those for geo-referencing. That tends to result in much less accuracy however, as the EXIF tags don't contain nearly as much information about the aircraft attitude, which makes a big difference.

Also note that our current system uses local timestamps in the raw pgm filenames to work match the time to the MAVLink log. That is a mistake which we will fix in a future release. It means that if you are using our OBC data in a timezone other than Queensland you need to use the time offset option in the geosearch.py program to adjust the time to match the times in the MAVLink log. For example, if you are perth, which is 2 hours west of Queensland, then you would use an offset of -7200 seconds.

Next Steps

Some parts of our algorithm were tuned for the expected object sizes of the OBC competition (about 2 meters by 0.5 meters) and for the altitude and images sizes we used. We'd like to parametrize those aspects of the code to make it easier to use for a wider variety of tasks and camera systems.

We'd also like to make it easier to plug in different scoring filters. The recognition algorithm works in two stages, a first stage that finds anything unusual in the image, then a second stage that converts that region to HSV colour space and applies some simple heuristics to score the region. We'd like users to be able to easily plugin different scoring systems to suit their own image search task, as not everyone is looking for a lost hiker wearing blue jeans and a yellow shirt!

We are also interested in adapting our system to thermal cameras, such as the Tamarisk 640, and we hope to do some testing with that system later this year.

Please share your improvements

If you use this code in your own system then please share your improvements! You can clone our repository on github, or post an issue, or just discuss your changes on our mailing list. If we work together we can create a system which will end up saving lives, so please don't just keep your improvements to yourself.

I've flown a lot of different planes while working on ArduPlane, but it wasn't till yesterday that I first flew what is perhaps the most popular plane for new ArduPlane users - the Bixler2.

While setting it up on Saturday evening I had a bit of a look through some Bixler build logs in the forums, and I was surprised to find that none of the suggested ways of mounting the APM were really convenient. Some people put it in the bottom of the fuselage, which makes it difficult to get cables to, and hard to work on. Some used custom or commercial mounting systems for putting the APM on the top at the front, but that makes the Bixler less aerodynamic, and trying to cram all the accessories like telemetry radio and GPS in makes it a tricky fit.

The solution I came up with is to mount the APM upside down on the underside of the canopy. ArduPlane has supported the AHRS_ORIENTATION option for a few releases now, which allows you to have your APM mounted in a lot of different orientations. In this case it seemed perfect to use AHRS_ORIENTATION=8 and mount it upside down on the bottom of the canopy. The advantages are:

• it is easy to get at the APM for programming it, or accessing the pins, as you just pull the canopy off, and the APM comes with it
• when you remove the canopy it makes it easy to get to the battery space, as the APM is out of the way
• it leaves plenty of room for the receiver and GPS on the top part of the canopy
• it is clear of any wind effects, well shielded in the fuselage

I also used a pin through the plastic top of the canopy to hold the canopy on more firmly, as I don't really trust the magnets. You will also notice a couple of pins stopping the wings coming loose - those fuselage screws are rather loose and one came loose on the first flight.

This mounting system is also ideal for a PX4. I happened to use an APM2.5 for this build as I was doing bench tests on my PX4, but either one works with the AHRS_ORIENTATION option.

One thing to watch for with AHRS_ORIENTATION is that you need to reboot and then re-level your plane after setting it. It is best to use the CLI full accel calibration, so it can properly adjust for the slight pitch of the canopy bottom surface.

Cheers, Tridge

Development moved to github

We moved APM development from subversion to git quite a while ago, and it was a big improvement, but we've been noticing quite a few rough edges to the git support on code.google.com. Meanwhile, github.com has been rapidly developing as a great platform for projects like ours, with a really nice workflow and great issue tracking. One of the big advantages of git is that it's easy to move to a new host, so we decided to move APM development to github.com. The new master repository is at https://github.com/diydrones/ardupilot and the old repository on code.google.com has been frozen with no new commits.

One of the big advantages of github is a nicer system for people to submit patches for inclusion in the master tree. On github this is called a "pull request" and it is explained nicely in the documentation. I'd encourage all APM developers to have a look through the github documentation.

The pull request system also has the advantage that it is much easier for everyone to see what patches are pending review and inclusion in the tree.

Another major change is that we've reduced the number of people that have direct access to pushing new code in the master branch. The way we worked previously was that if you submitted a couple of good patches then you would be given direct push access for future work. That sometimes led to patches going in that didn't really have adequate review, but it was the least painful way to do things with the code.google.com system. Given the nice pull request interface on github we're trying a different approach, where nearly all developers, even people who have been contributing for years, will get their code into the tree via a pull request. Only 3 developers (Pat, Randy and myself) currently have access to accept pull requests, which we hope will lead to a bit more code review and higher quality code. We'll have to see how it works out over the coming months!

Issues now tracked on github

As part of the move to github we've adopted the github issue tracking system. This integrates very nicely with git commits, so we can for example add "fixes issue #7" in a commit message and the issue automatically updates to note the fix.

One tricky decision was whether we import over the old issues from code.google.com to the new system. After much discussion we decided not to, as we'd been so slack in keeping the old issue system well maintained that most of the issues were not relevant any more. There are some important ones in there though, so if your favourite issue has been lost then please post it into the new system (after checking if its has already been dealt it!).

New developer mailing lists

Another big change is the creation of two new mailing lists, drones-discuss and drones-devel. In the past we've had a private developer mailing list, which Chris invited people to join when they made a contribution to the code. That private list really originated from the time where there was a much smaller group of APM developers, and there is no good reason why it was still private, so we've created the two new lists as public for anyone to join, and shutdown the old private list. So if you want to get involved in APM development or just want to lurk in the developer discussions then please join the drones-discuss list!

Please don't post to the drones-devel list though - this is just for coordinating releases. It is a public list, so anyone can join and listen in, but we want to keep the noise on it low if we can.

We'd also like to emphasize that these lists are not the place for help requests - they are meant for development discussions only, such as discussing new features as they are being developed. The diydrones forums are still the right place for user discussion.

AP_HAL - the Hardware Abstraction Layer

The biggest change in the APM code itself comes from the new HAL (Hardware Abstraction Layer) pioneered by Pat Hickey. If you have a look at the current git tree then you'll see some new directories under libraries that start with AP_HAL. The AP_HAL directory itself defines the new API that abstracts out the differences between the various autopilot board types we support. Then we have a separate AP_HAL_$board directory for each board. The code for the APM1 and APM2, which are based on AVR CPUs, is in AP_HAL_AVR, but you may notice there are some other board types in there as well.

The main motivation for the AP_HAL work was to give us a clean way to support the new PX4 autopilot, which is based on a 32 bit ARM core, but it does a lot more than that. It gives us a very nice way to make all of the APM vehicle types portable to a lot more types of hardware with very little work.

In our code you will notice that we have a new 'hal' object which contains methods to access the hardware specific functions. For example, to set IO pin 17 as an output pin we would now do this:

  hal.gpio->pinMode(17, GPIO_OUTPUT);

the HAL API replaces the Arduino specific calls which we used previously, and gives us a lot of flexibility to implement all the board specific functions in different ways for each board.

We think that the ArduCopter 2.9 release which is in its final release candidate now will be the last "pre-HAL" release. The master branch is fully converted to AP_HAL, and has all of the features from 2.9 merged in. It is also flying very well!

One thing to watch out for is that if you are building the APM code using the Arduino development IDE then you will need a special patched version to support the new AP_HAL based code. We've released zip files of the patched IDE for Windows and MacOS. If you build on Linux then please use the 'make' command.

PX4 support

The big test of the new AP_HAL system was the PX4 port. We've had the PX4 hardware for months now, but the software port was lagging behind badly. It was really quite tricky to port the code across to the new NuttX RTOS based platform cleanly. With the introduction of the AP_HAL system it was incredibly easy, and just a few days after we got AP_HAL into the tree we had our first successful flights of both ArduPlane and ArduCopter on PX4 boards on the same day!

So if you have a PX4 then it is now possible to use it with any of the 3 vehicle types we support (copter, plane and rover). There are still some interesting issues with how to plug in servos and radios, but if you don't mind a bit of creative wiring then it does work. We will be posting some instructions soon.

I'd also encourage you to have a good look around the PX4 website. Lorenz and the whole PX4 development team have done a fantastic job with this board, creating something that gives us an incredible scope for future development. The work they have done on the sensor drivers and ORB integration is top notch, and I found it really nice to work with the system they have created in doing the APM port.

If you want to build the APM code for PX4 yourself then it's worth noting that one of the things we don't have yet is a good way to build the APM code for PX4 on Windows - it's building fine on MacOS and Linux, but the Windows build system still isn't ready. We'll post an update when we have that working. The core PX4 code does build on Windows with Eclipse, but we just haven't done the extra bits needed to allow the APM code to build within that development environment yet.

Meanwhile, if you want to build on MacOS or Linux then you'll need the PX4 firmware tree somewhere on your system, and you need to use the "make px4", "make px4-clean" and "make px4-upload" commands.

There are still some missing features on PX4, for example we don't yet have analog inputs, so no airspeed sensor on ArduPlane, but we'll get that sort of thing fixed up pretty quickly I think. Even so, I've done around a dozen flights with my PX4 equipped SkyFun so far, and it is flying very nicely! Both Pat and Randy have flown ArduCopter on PX4 as well, and both found it flew very well. Here is a video showing Pat flying the master git branch on PX4

Note that the port to PX4 doesn't mean we are abandoning the APM1 and APM2. All the APM code builds on all 3 platforms (plus the 'SITL' simulator platform), and our plan is to continue to support the APM1 and APM2 for as long as we can. What we expect to happen is that some new CPU and memory intensive features will only be enabled when you build for PX4, where we have so much more CPU and memory available.

Happy Flying!

I hope the above gives everyone a bit better idea of what has been happening. The pace of development has been very high over the last month, and if you've noticed that some of us have been a bit quiet on the forums then this is why. Over a thousand patches have gone into our git tree in the last 2 months to make all this possible, so we've actually been quite busy!

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.

The dev team is delighted to give a Christmas present to ArduPlane users in the form of a new geo-fencing feature!

Geo-fencing allows you to define a GPS fence around your flying area, plus a minimum and maximum altitude. Within the fence you can fly ArduPlane normally in any mode you like. If you go outside the fenced area then the APM will automatically take over and bring the plane back to a pre-defined return point, ready for you to have another go.

We're hoping that this feature will both help beginners learn to fly, and also allow experts to perfect complex aerobatic stunts while minimising the risk of a crash. It is also ideal for ensuring that local club rules on flight boundaries and maximum altitude are followed.

You can read all about how to setup and use the new feature in the ArduPlane wiki, but I thought it might be fun to tell you about a test I did of geo-fencing yesterday at my local flying field.

It was Christmas eve, and I was at CMAC testing the geo-fencing code. A family had turned up to watch the planes flying, including Wilson, a 5 year old who loves aeroplanes

I thought this would be the perfect opportunity to test geo-fencing as a training tool, so I asked Wilson if he'd like to try flying a plane by himself. As you might imagine, he enthusiastically agreed!

I took up my SkyWalker with the APM2 fitted, and then enabled the geo-fence. At first I put it in a loiter at about 70 meters, and showed Wilson how he could control the loiter using the transmitter sticks. After mastering that we put the plane in FBWA mode, and Wilson flew it himself. He was delighted!

The fencing really made a difference, as he made some mistakes and flew outside the defined area or too low a few times, but each time the APM took over and brought the plane back to the return point, where it loitered ready for him to have another go. We then flicked the trainer switch to give him control again, and he took the plane around more than a dozen circuits. Not bad for the first time flying a plane at that age!

I also did some test flights with my SkyFun yesterday, and I was delighted to find it worked very well with geo-fencing. One of the reasons I added the geo-fencing feature was to help me improve my manual flying skills. I've found that flying with the APM stabiliser enabled means that my flying skills don't improve as much as I'd like, so I really wanted to practice flying more in manual mode, but I also found that in manual I tend to crash far too often. With the geo-fence enabled I can fly in manual with a safety net. That allows me to really improve my flying skills without crashing. It means I don't need to remember to change modes when I get in trouble - the APM is constantly monitoring my position and altitude, and if I am about to crash it takes over and brings the plane back ready for another try. Great fun!

Many thanks to Wilson for test flying the new ArduPlane code and happy Christmas to ArduPlane users everywhere!

I've been working on the ArduPlane code for the new APM2 boards for a while now, so I was delighted to watch it loitering above my local flying field today for the first time. I'd flown it once before two weeks ago, but that was a very short flight as I had the aileron controls reversed (I don't have much experience with elevon planes!), so it was quite tricky to steer. It 'landed' in a tree that time. I also had no telemetry for that flight as we hadn't yet worked out the MUX switching needed for the telemetry UART in the APM2.

Pat and I fixed the MUX switching problem last weekend, so this weekend was my first chance to fly APM2 with a ground station and full telemetry. The weekend started off with an interesting problem. I took it out to the field yesterday and got it ready to fly, then waited for GPS lock. It takes a while to get GPS lock in Canberra, so I was waiting a few minutes. As soon as it got GPS locked I was surprised when the ground station reported that the board was rebooting! Time to take it back home for more bench testing.

I added a patch that faked up GPS lock after a specified period of time, which allowed me to reproduce the bug on my bench, and after a couple of hours of false starts I finally found and fixed the bug this morning. Time to flight test it!

Since I'd last flown my SkyFun (with an APM1 board) I had replaced the hinges, put in a bigger motor and a new ESC, so I was expecting the tuning to be a bit off. It sure was! I only switched to manual once in the flight and it dived hard - it looks like my CoG is a bit off with the new setup. I did the rest of the flight with the APM2 stabiliser enabled, letting the code take care of the trim. It's easy to get lazy with trim when you have an autopilot :-)

I did two flights today, of about 10 minutes each. It can probably fly for 20 minutes or more, but I don't have a current sensor fitted, so I didn't want to push it. In both flights I did a few minutes of LOITER, which is a good test that everything is working well in the code, as it needs all the sensors and logic to be working to keep it going around in circles in one place.

As you can see, the LOITER went perfectly, despite quite a strong wind and poor tuning.

The APM2 really is a great board, and the smaller size makes it perfect for little foam planes. I also like the fact that the inputs and outputs are at opposite ends of the board, making wiring neater.

Of course, best of all, the APM2 can fly!

The development team is always trying to find ways to improve our testing and the quality of our code. We've recently add a new automatic testing system that should help a lot with finding bugs and ensuring that the huge range of features that we have added (and plan to add!) to the code keep working.

If you have a look at http://autotest.diydrones.com you'll see the results from 'Tools/autotest', a test system that runs on every change to the ArduPilot and ArduCopter code. The test script currently checks the following:

• that both ArduPilot and ArduCopter build on the 1280 and 2560 based APM boards
• that both ArduPilot and ArduCopter can build with the 'desktop' build system
• that ArduCopter can fly in both manual and automatic (mission) mode
• that we can download the flight logs

It also keeps detailed logs, and produces a KML file which you can load in googleearth to look at how the flight went.

The flight itself is controlled using a python scripting system that flies ArduCopter using MAVLInk commands. Currently that script does the following:

• starts up the simulator at my local flying field
• arms the motors (using virtual transmitter sticks to control the rudder and throttle)
• switches the quadcopter to STABILIZE mode
• does a manual takeoff using throttle, until the altitude reaches 30 meters
• uses the rudder to turn the quad until it is facing north (it starts up facing west)
• uses the elevator and aileron sticks to manually fly a square circuit about 50m on a side
• switches to LOITER mode, and checks that it holds altitude for 10 seconds
• switches back to STABILIZE and decreases throttle, to bring the quad in for a gentle landing
• loads a 9 waypoint mission into EEPROM
• switches to AUTO mode and flies the mission, which involves a zig-zag route over the field
• the last mission step is a RTL, which brings the quad home
• then it switches to STABILIZE, brings the quad in for a landing, and disarms the motors

You can see a track of the test flight in the above googleearth screenshot.

Running these test steps every time we make a change to the code is already ensuring that a lot of our code works, but we have plans to greatly expand this test suite. What we'd like to do is have every ArduPlane and ArduCopter feature tested, with code that validates that it actually does the right thing. At the moment the test suite only has very rudimentary testing of whether the flight was actually correct, whereas we should be checking lots of parameters (roll, pitch, altitude, speed etc) throughout the flight.

The other obvious missing piece is ArduPlane testing. The test suite checks that ArduPlane builds, but doesn't yet check that it flies correctly. I hope to fix that this weekend, with ArduPlane flying some simple missions plus some 'manual' (ie. python scripted) flying. I'll probably do this by interfacing with FlightGear, but jsbsim linkage of even a new physics model is a possibility.

Under the covers

This new test system involves quite a few new bits of code, some of which we hope will be used for things other than automatic testing. The quadcopter simulator itself is a simple physics simulator written in python, which Michael has since translated into C# for use in the planner (thats how you can fly quadcopter HIL in the planner now). The communication between the various pieces uses pymavlink, a MAVLink implementation in python. That uses a bunch of helper scripts that make it fairly easy to script a ArduPilot vehicle. I'm hoping this system will be used for scripting real copters and planes in the future, along the lines of the acrobatic scripting system we discussed earlier in the year.

The other big part of this autotest system is the 'desktop' (also known as SIL for "software in the loop") build of ArduPlane and ArduCopter. This builds the code using a normal C++ compiler, and creates executables which run directly on your desktop computer, rather than on an APM board. The advantage of this is that we can use all the debug tools (such as gdb and valgrind) which are normally used for C++ development, but also it runs much faster and doesn't rely on hardware being plugged in. We've already taken advantage of the ability to run ArduCopter under valgrind to find some bugs, and it really increases our confidence in the code to be able to run that sort of sophisticated memory checking on every commit.

If you want to have a look at autotest, then start by grabbing the latest APM code and having a look in Tools/autotest. You might like to start by looking at arducopter.py and seeing how it controls the quad. We're hoping that we will get contributions of new tests. We also plan on putting up a wiki page describing how you can run the autotest system on your own computers (right now it only runs on Linux and MacOS, although Micheal has had some limited success on Windows using cygwin).

How you can help

The autotest system is already quite useful and it has already helped us find some subtle bugs in the QuadCopter code, but we'd love to expand it to cover more aircraft and features. Here are a few things that it would be great to get contributions on if someone has the time:

• we need physics simulations for more multi-copter frame types (start with quadcopter.py, and create ones for hexa, octa etc)
• I'd like to produce a nice picture of the flight path from a KML file using a script, so devs don't have to load googleearth to quickly check it looks OK
• we need some interesting test missions to look at. I hope to support loading missions in planner format soon to make this easier
• we need python code to more carefully check the flight is OK. It may be easier to wait on this until we develop some better helper functions, but if you are a python coder then feel free to jump in now

Hopefully this will be the beginning of a much more rigorous testing effort for ArduPilot. We'll post more information as the system develops!

While flying our Telemaster last Sunday with two APMs we noticed something very strange about LOITER mode. The above track is a small snippet from our flight path. We entered LOITER mode on the left, with a loiter radius of 25m. As you can see from the spiral path, the plane did not loiter at all well, instead spiralling to the right.

It would be easy to dismiss this sort of behaviour as just a one off, but I've seen this before. Our plane has loitered well sometimes, but sometimes it was way off, often spiralling away from the right position just like this. I wanted to get to the bottom of it, and I thought that explaining the process of diagnosing and fixing a bug in APM might help other people to better understand their own UAVs. So read on for a long story of a set of bugs in the APM/ACM magnetometer driver.

The first thing I needed to do was look more closely at the raw data that I had logged for this flight. To do that I wrote a little utility called mavgraph.py, built on top of pymavlink. It takes MAVLink logs and allows you to graph arbitrary mathimatical expressions of any of the MAVLink fields. Someday I'll write up a proper tutorial for mavgraph, but for now if you want to use it have a look at the pymavlink github repository. The utility you want is examples/mavgraph.py. You'll probably find you will need to install a bunch of python packages to make it work. As I mentioned, some day I'll add instructions to the APM wiki unless someone else beats me to it (hint hint!).

If you are wondering how you get MAVLink logs, the major ground stations can record them. mavgraph will accept the format that the planner uses, or the format that mavproxy and qgroundcontrol use. I haven't tried it with HK GCS.

The key to good loitering is heading, so lets plot the GPS and compass headings we got in the above loiter:

  mavgraph.py --condition='SYS_STATUS.mode==4 and SYS_STATUS.nav_mode==8 and RAW_IMU.usec > 908942404' Telemaster/logs/2011-08-07/flight8/mav.log VFR_HUD.heading GPS_RAW.hdg

That gives this:

as you can see, the GPS and compass headings did not agree at all well! As we had two GPSes on this plane, I was able to confirm that the GPS values were OK, so what was up with the compass? It looks like its range is badly squashed. That certainly explains why the plane couldn't loiter, as it didn't know which way to fly!

The next thing was to check if this was a problem during the whole flight, or just at certain times. If it was the whole flight then perhaps the compass is broken. We can run this to show just the times the plane is flying:

  mavgraph.py --condition='VFR_HUD.groundspeed>3' Telemaster/logs/2011-08-07/flight8/mav.log VFR_HUD.heading GPS_RAW.hdg

as you can see, the compass did track the GPS heading for some parts of the flight, but for a lot of the flight it was terrible. You can also see that I mostly did left hand circuits during this flight!

I started to suspect the magnetometer offsets. The magnetomers used by APM/ACM have two types of calibration. One is a linear scaling, and is computed at startup by asking the magnetometer to apply a 'strap' excitation and measuring the resulting field. The other is a set of offsets that account for local magnetic fields in the plane, and the properties of the magnetometer chips. The offsets are updated dynamically at runtime using a system called 'offset nulling' invented by Bill Premerlani and implemented by Doug Weibel. You can see the code for APM in libraries/AP_Compass/Compass.cpp.

Unfortunately the offsets that the null offsets code calculates were not being logged by APM (more on that later). So all we could do was use the RAW_IMU log, which does contain the x, y and z magnetometer readings after the offsets are applied. We can use those values to post-compute the heading from the raw magnetometer values. The formula is in the APM Compass code, and it translates into this rather long mavgraph command:

mavgraph.py --condition='VFR_HUD.groundspeed>3' Telemaster/logs/2011-08-07/flight8/mav.log 'VFR_HUD.heading' GPS_RAW.hdg 'fmod(degrees(atan2(-(RAW_IMU.ymag*cos(ATTITUDE.roll) - RAW_IMU.zmag*sin(ATTITUDE.roll)), RAW_IMU.xmag*cos(ATTITUDE.pitch) + RAW_IMU.ymag*sin(ATTITUDE.roll)*sin(ATTITUDE.pitch) + RAW_IMU.zmag*cos(ATTITUDE.roll)*sin(ATTITUDE.pitch)))+360,360)' --labels='APM heading,GPS heading,computed_heading'

Here is one part of that graph:

this shows that the basic compass calculations in APM are not at fault. The post-computed heading does match what APM calculated while flying (roughly!). So, what is the problem?

To get to the bottom of this we need a few more bits of information. First off, we need to start logging magnetometer offsets and other sensor offsets in our MAVLink logs, so we can properly check all the calculations in a post flight analysis. I added this patch to MAVLink and the code in APM to use it. So now we can get MAVLink logs showing the raw sensor offsets, not only for the magnetometer, but also for the gyros, and barometer.

Next I needed a reproducible test case. Waiting for the fault to show up again while flying didn't sound like a good idea, so I built a little test rig on my desk.

The test rig consists of a pan/tilt mount with two APMs mounted on top, both with magnetometers. The pan/tilt is controlled by servo outputs from one of the APMs. I then wrote a test script using pymavlink to run the test. The test script pans the two APMs around and tilts it when going in one direction, leaving it flat in the other direction. It also resets the magnetometer offsets at the start of each test (using another APM MAVLink message I added for this test).

This test rig allowed me to capture good logs of the two APMs moving about in a predictable manner. On one of the APMs I put a 5883L magnetometer, and on the other I put a older 5843. Here is the result, along with the 'true' heading calculated from measurements I took using a bushwalking compass.

(I should note that I am skipping quite a few intermediate steps I took this week in finding this bug. I don't want this post to turn into a book!).

As you can see from the above graph, the 5843 did track the true heading fairly well, but the 5883L didn't. So it looks like we have a bug in the 5883L driver. That means it's probably my fault, as I was the last one to work on that driver. So I am on the hook for fixing it. Darn!

Also note that this test is the worst possible case. It starts with zero offsets, and it only rotates the mags through less than 180 degrees, and doesn't roll them at all (I only have a 2-D mount available). So if you are wondering why your 5883L does better than this, then that is probably why.

The above result led me to start looking very carefully at the 5883L driver in APM. I found several problems. One was that we just accepted the first value from the mags for calibration purposes, but logging showed that sometimes that first value wasn't very good. So I added code to get at least 5 good values, where 'good' means not more than 30% off the expected value for the strap field. I also noticed that the expected values for each axis didn't match what the specification said they should be. The spec says that the X and Y values should be higher during calibration, and the Z value a bit lower. I found that the X was higher, and the Y and Z about equal. That was easy to fix in the code as well.

Next, I looked carefully at the gains used. The 5843 mag uses a strap field of 0.55Ga, whereas the 5883L uses a strap of 1.1Ga. That means you need to use different gain values during calibration of the 5883L than during runtime, as otherwise you either risk overflowing during calibration, or you will get lower sensitivity than we would like. So we use two gain values for the 5883L, and only one for the 5843. The problem was we were not scaling the resulting calibration values for the change in gain on the 5883L.

Finally, and perhaps most importantly, we were mucking up the rotation of the 5883L compass. The 5843 and 5883L mags have different orientations, so we apply a matrix multiply to fix that. Unfortunately we had some chicken and egg bugs related to that rotation. The compass init code was using the read() routine to get its values, and that applied the rotation, but the output of the init routine was used at runtime before the rotation is applied. That meant the calibration was incorrectly rotated. It also left some bugs related to init order, as we need to know what sort of mag it is to get the rotation right, but we also need to setup the rotation before we init, as init relied on the rotation. Nasty.

The fix was to extract out a read_raw() routine which didn't do any rotation or apply any offsets, and use that in the init() call, and also use that as the core of the runtime read() call. Thanks to Randy Mackay for this suggestion. Randy and I spent quite a lot of time on this problem together via skype screen sharing, and his suggestions were very helpful.

After all those fixes, this is the result of running the same experiment with the new code:

That's much better! We can also have a look at how the mag offsets evolve during this test, here are the 5883L offsets:

you can really see how the null offsets code is converging on reasonable values. It looks like it converges in about 10 minutes or so, but the heading is good much faster than that.

I'm still not completely happy with the performance of the mag driver, but it's better than it was. If you look at the 'good' graph above you will see that the 'true heading' matches the mag heading over a wide range of values, but the true heading peaks higher. I've double checked the measurements on my table using my bushwalking compass, and I think this is a real effect. It looks like we may be off by 20 degrees or so in some cases for both mag types. That means more investigation and logging. Meanwhile, I think APM/ACM will just treat it as a bit of 'wind' and will fly fine. I'll find out tomorrow when I take the Telemaster up again.

We took our Telemaster up again today, this time with two APMs on board. There were two aims with this flight. The first was to get an idea of how much two APMs would vary in their attitude and altitude solution, and the second was to test a new experimental GPS that one of the CanberraUAV team members received as a birthday present from his brother (his brother builds GPS modules for a living).

For the outback challenge competition we plan on having two APMs in our plane. The idea is that the mission control computer on the plane (a pandaboard) will constantly monitor both APMs and will switch over to the backup APM if the first one starts misbehaving. To do that we need to know how much variation between the two APMs we normally should expect, so we know when we should be thinking about switching between them. The logs from todays flight gives us some idea of what variance we should expect.

The setup we used today was that both APMs were connected via USB to the pandaboard, plus one of them was connected to the normal servos, receiver etc, and was used when we were in stabilise or loiter mode. Both APMs logged detailed telemetry to the SSD on the pandaboard via mavproxy.

Apart from being in slightly different positions in the plane, the only other differences between the two APMs were:

• one used a 5883L magnetometer and the other used a 5843.
• one was connected to the planes pitot tube airspeed sensor and the other wasn't

To analyse the results, I wrote a little graphing utility (mavgraph.py) for MAVLink logs, which I have put in the examples directory for pymavlink.The raw logs are here and here.

While looking at the results I found that the magnetometer on the 2nd APM hadn't initialised, which means its yaw and heading values are rubbish. We'll need to do more flights in the future after ensuring that both magnetometers initialise correctly. I'll also need to add a warning message to mavproxy for when the magnetometer doesn't produce good data.

Results

The first thing I wanted to look at was the roll/pitch solutions. Here is a typical graph for a short section of the flight.

The tracking between the two APMs was reasonable, although not as good as I had hoped for. The two IMUs will of course have had slightly different calibration, so we expect a constant offset, but the graph shows that the offset isn't constant. Sometimes the 2nd APM shows a larger roll, and sometimes the first one does.

The altitude solutions show a similar variance:

The VFR_HUD altitudes are from the two barometers, the GPS_RAW values are from the GPSes, both are in meters above sea level. The two height estimates tracked each other quite nicely, with the variance small enough not to bother a plane. A quadcopter hovering might have some problems at low altitude, but at the altitude we were flying at today (around 100m or so) it wasn't an issue for the Telemaster.

The airspeed/groundspeed values were about what I expected:

the pitot tube produces a much noisier signal than the GPS does, and the two GPSes tracked each other quite nicely. The difference between the pitot and GPS readings could well have just been the wind, which was several meters/second.

I was curious to see if the raw gyro readings tracked each other. The MAVLink RAW_IMU packet allows us to see the raw sensor values before that are processed by the APM, and I wanted to see how much noise showed up:

They tracked better than I expected them to! I have the hardware sensor filters enabled on both IMUs, and I suspect this shows that those sensors are doing their job quite well.

We'll be looking at these log files a lot more closely in the coming weeks, but this quick look has already told us a lot of what we need to know for designing our OBC avionics, and working out how to do failover between the two APMs.

The CanberraUAV team has submitted its deliverable 1 report for the outback challenge, so we are back to doing development and testing of our test platforms again.

The main platform we have been using lately is a Senior Telemaster, which I got 2nd hand from another club member at CMAC. It has been a great test plane, and I'd highly recommend it for doing UAV development.

I was initially concerned it may be a bit too big for my car, but I found that it did fit (just!), although it is also a fairly tight fit in my study at home when I put the wings on to do a CoG test.

The plane came without a motor, so the first thing to do was work out what motor/prop/ESC/battery combination would work. I knew I'd be loading it up with a lot of electronics, so I aimed for enough thrust to handle well over 6kg flight weight (its total flight weight with all the electronics ended up at 6.5kg). Because it is a front-prop plane, it had to be electric as otherwise we'd get too much gunk on the cameras. After playing with a prop calculator for a while, I worked out what a E-flite 32 would do the job nicely, with 2x5Ah 4S LiPos in parallel to drive it and a 13x6.5 prop. I got a 100A ESC and isolated it from the rest of the electronics by cutting the +ve wire on the throttle lead, and the plane was setup for power. Now that we've flown it a bit the E-flite 32 turned out to be a great choice. It takes off in just a few meters and has plenty of power, and gives us flight times of about 35 minutes, despite the heavy load. I wanted a sedate slow flying plane as a camera platform, and this turned out to be ideal. The watt meter shows it pulls a little over 60A at full throttle, which should be just under the 60A limit of the motor once its through the ESC. It cruises at below 1/3 throttle.

Making room for the electronics

The next step was to get the fuselage ready for a pile of electronics. The rudder and elevator servos were right under the wing where the fuselage is largest, which was also where we wanted to put all the electronics, so Jack moved then back to behind the wing for me. It's handy having someone on the team who is good with balsa!

After that we just needed to fit the electronics in. This aim for this plane is to be a scaled down test version of the Mugin we are using for the OBC competition, so we put in as many of the same electronics as we will be using in the competition as possible. That means a pandaboard, a 32G SSD, a Ubiquity bullet TDMA radio, a PoE injector for the radio, and a couple of cameras on the bottom. We also added a pitot tube for airspeed, a mixer for flaperons (for really slow easy landings!), a UBLOX GPS and of course a UBEC to power all the electronics (a castle creations 10A).

The cameras take still images, one in IR grey-scale, the other IR-filtered colour. The IR camera is a ptgrey chameleon machine vision camera. We'll probably use a 2nd ptgey chameleon colour camera for the competition, but for now we're using a Philips webcam for the colour images (a SPC 900NC). The idea behind the dual camera system is to give us better rejection of false positives in the IR search for 'Outback Joe' by looking for places with a high IR signature but low on the IR filtered camera. The colour camera also looks for the distinctive coloured clothing that Joe should be wearing.

Software setup

The pandaboard runs the Ubuntu Natty Linux distribution, and on top of that it runs the mission control software, which is mostly python scripts using pymavlink, in particular MAVProxy, which proxies the MAVLink stream from the APM to the ground control station (which runs another copy of MAVProxy). It also runs the camera capture software, which does the gain and exposure control to keep the images at a reasonable level for finding the IR lamp. The ptgrey chameleon camera really shines at that, with most of our exposures taken at around a 100us exposure or so, which means no blurry images! That is pretty good given we have a IR-pass filter in front of the lens blocking all the visible parts of the spectrum.

Radio Link

We link from the plane to the ground using an ethernet bridge radio, a Ubiquity Bullet which is a 300mW radio at 5.8GHz. On the plane we currently had a 5dBi omni antenna, although we will probably switch to a higher gain antenna soon and start using servos and the APM attitude values to keep it pointing straight down. We did some range testing on the radios yesterday with a 20dBi phased array antenna on the ground station, and got a good link at 5.2km. We're aiming for a high quality link at over 10km, with about 5Mbit of bandwidth or better (we want to send a H.264 video stream from an IP camera on the plane).

We also have an XbeePro900 straight from the APM to the GCS, and we're planning on having a DroneCell as well for a GSM link. We will probably also upgrade the 900MHz link from an Xbee to something with a bit more power. The idea is for the ground station to monitor all the links in parallel, and auto-switch between the links according to a priority order, so if we lose the main 5.8GHz link we still have full telemetry and control via the secondary links.

Ground setup

While on the ground we have a ground power lead, so we can do all our electronics setup without running the avionics battery out. We also use our sunlight readable laptop to ensure we can use the GCS easily at the field. The GCS also reads out key data using a text to speech package, so we know if (for example) we're running low on power in the batteries on the plane. All of that info is transmitted via MAVLink from the plane.

All up this plane has turned out to be pretty much perfect for us to prepare for the outback challenge. Once we've perfected it we'll move onto the larger Mugin, but for now, the Telemaster is great!

Do you have an APM1280 board? Are you worried that you won't be able to use it with the latest bleeding edge APM code? Read on for some tips on how to get some life from that old board.

The current generation APM board is based on the APM2560, which has 256k of flash instead of the 128k of flash of the APM1280. As has been discussed before, the rate of code development is such that we are rapidly getting to the stage that if you build with all the latest features enabled you won't fit all the code onto an older APM1280 board. Don't despair though, you can keep using a APM1280 for quite some time!

The first thing to know is that the dev team is working hard on keeping the code size small. In fact, over the last few weeks through some optimisation and code refactoring the total code size of the latest development APM code has shrunk, so it now fits on a APM1280 again with all features enabled.

Development will continue though, and new features are being added at a rapid rate, so it won't be long before the default image grows beyond the 128k boundary again. When that happens you have a few choices for your 1280 board.

Optimise your build for your needs

The key to staying on the bleeding edge with your APM1280 is to optimise the build for your needs. The default options of the APM build are designed to work for as many people as possible out of the box. This means that lots of code is enabled that you won't need on your plane/copter. If you open up the arduino environment and build the image yourself then its easy to disable a few features that you don't need and free up plenty of flash for future development.

To customise your image, just edit your APM_Config.h and add a few lines. Here are some space saving examples:

#define GPS_PROTOCOL GPS_PROTOCOL_MTK16

Choosing a specific GPS module instead of the default GPS_PROTOCOL_AUTO will save you about 4k of flash. You probably only have one type of GPS anyway!

#define LOGGING_ENABLED DISABLED

Disabling on-board logging saves more than 10k of flash. Personally I prefer to log my flights to a ground station over MAVLink, so if you are like me and don't need the on-board logging then you can save plenty of flash space.

#define CLI_ENABLED DISABLED

Disabling the command line interface will save you over 17k of flash. Up till recently it wasn't possible to setup an APM properly without having the command line interface, as you needed it to setup your flight modes and your radio ranges. Thanks to some great work on the APM Mission Planner by Michael Oborne you can now do the complete setup from the planner. That is still a very new feature, so you may find some rough edges, but you can be sure that the dev team are working on making that easier.

There are other examples of how to shrink your build, just take a look in config.h and look for things that are marked as ENABLED by default. If you don't need it then disable it and watch the image shrink.

If you disabled all 3 examples above then you would save over 32k of flash. That's a lot of room for more features, and should keep your APM1280 flying on the bleeding edge for a long time to come.

Using an APM1280 as a HIL simulation board

What if you've decided to get an APM2560 anyway, what can you do with your old APM1280 board?

My favourite use for an old APM1280 board is for HIL simulation. I keep my main APM2560 board in my plane along with my IMU, and I prefer to leave it in the plane between flights, so I'm not constantly having to disassemble things, which can put needless stress on the wires.

My older APM1280 board is kept on my desk, and I use it to fly HIL simulations. The trick to doing this is knowing how to configure your APM1280 to run HIL simulation without an IMU boad. I only have one IMU board, and I prefer to leave that in my plane, but the default APM build for HIL will try to access the IMU board, and will crash if its not there.

This is easily solved. The trick is to know that when built for HIL simulation there are only 2 things that the APM code tries to access on the IMU board - the slider switch and the 16MB data log. So if you disable the CLI and the on-board logging then you will find that your APM1280 will fly a HIL simulation perfectly. The defines you will need are:

#define LOGGING_ENABLED DISABLED
#define CLI_ENABLED DISABLED
#define HIL_MODE HIL_MODE_ATTITUDE

The resulting image will be just 66k in size, which means that your APM1280 will be able to fly HIL simulations with the latest bleeding edge code for a long time to come!

To connect your APM1280 for HIL, all you need is a FTDI cable, and of course a flight simulator. I prefer FlightGear, as I can hack on the code, but a lot of people use X-Plane with great success.

So, don't put that APM1280 in your parts bin just yet. There is plenty of life left in it if you tweak things a bit!

Just how important vibration isolation is with an APM become clear to CanberraUAV this week. We were testing flying Jacks SkyRaider (a low wing sports plane with a 0.5ci engine) on Sunday, and found that we got severe gyro drift. The first minute or so of flight was OK, but the plane quickly developed severe roll and pitch drift when it stabilize mode. We were recording the flight using a mavlink log which showed that the roll went from -2.97 radians to 3.09 radians, when in fact we were flying fairly level!

We tried swapping out various APM components with known good bits from my SkyWalker, with no luck. Chris Gough then suggested that the problem may be vibration, given that the SkyRaider has a glow engine,  and the only vibration isolation was some double sided tape between the APM and the fuselage. On Wednesday we tried again with a thick layer of foam beneath the APM (see the above picture), and it worked fantastically! We would quite surprised quite how much vibration isolation mattered.

I've mounted the APM for my Senior Telemaster with an even thicker layer of foam:

I thought it would be fun to have an 'inverted flight' switch on my transmitter. With an APM, it's easy! I just added a check for a PWM value above 1700 on channel 7 in read_control_switch(), and when it is above 1700 it sets a inverted_flight boolean. That adds 180 degrees to the nav_roll, which is the target roll for the stabiliser, and it switches the sense of the elevator stabilisation in the main stabilize() code. The result is this patch to the current ArduPilotMega code.

I tried this out a few times with HIL simulation using FlightGear first, then took it flying today with my SkyWalker. There was a lot of wind, so not exactly ideal conditions to be trying experimental patches, but I didn't want to wait for next weekend so I took a chance. It works perfectly!

I setup a spring loaded switch on my transmitter to set channel 7 to 1900 while I held the switch. That allows me to takeoff normally, then whenever I hold the switch in the on position the plane immediately flips over and holds nicely stable flight upside down. You can direct it reasonably well while inverted, although it certainly isn't as responsive as with upright flight (a glider like the SkyWalker isn't really designed for this sort of thing!). The manual mixing of elevator is inverted while upside down (just like it is when you flight upside down manually), which makes this patch good for practising inverted flight, as you can get used to the controls.

The only tricky part of the patch was the change to stabilize() to handle wrap of nav_roll at plus and minus 180 degrees. I originally wrapped it just based on the value, but the HIL simulation showed there was a discontinuity in the stability control at exactly 180 degrees, so the plane would suddenly try to flip over again while upside down as you passed the 180 degree mark. This turned out to be an interaction between the wrapping of the dcm roll_sensor and the nav_roll wrap. The fix was to wrap the nav_roll variable based on the sign of the dcm.roll_sensor variable, and that leads to really nice inverted flight with no crazy behaviour near 180 degrees.

This patch works with any of the stabilised flight modes (ie. anything but manual), which means you can flick the switch for inverted flight while flying a mission, or while in any of the other autopilot modes. It should add a bit of interest to longer missions!

(thanks to Stan for taking the video and coping with the gale blowing at the time)

The CanberraUAV team did our first flights with our full onboard computer system (a pandaboard) on a SkyWalker test plane this weekend. This allows us to capture images of the IR lamp used in the outback challenge from the air, combined with the telemetry we need to start working on our image recognition algorithms.

In the above photo you can see our basic setup. We have the pandaboard, a USB hub (powered), a 64GByte SSD, a ptgrey chameleon greyscale camera with a IR pass filter, a UBEC to power it all, and of course the usual APM, GPS, magnetometer and XBee radio.

Rather than cutting a hole in the side of the plane as most people do for a SkyWalker, we cut the foam barrier out from under the wing (where some people put an extra battery), which gave a good top access hatch to the main compartment. The pandaboard and other electronics fit nicely down into the plane from there, and it provides easy access to the ethernet interface on the pandaboard for diagnostics, as well as all of the USB ports.

This is what it looks like when we put all the bits inside the plane:

One quite unusual aspect of the setup is that the APM is connected via USB instead of FTDI. The USB cable goes to the pandaboard, which runs a copy of mavproxy to gather the telemetry. The panda also controls the camera, which means the same clock is used for time-stamping both the telemetry and the images, which really helps in matching them up for image recognition.

The camera was fitted in the bottom of the plane, below the leading edge of the wing, pointing straight down through a large hole in the fuselage, with a large IR pass filter in front of the lens.

We flew several missions over the weekend. The first was a simple search pattern (the same 18 point pattern we flew last weekend), to ensure the camera system was working well. We captured over 3000 images (each at 1280x960 in 16 bit greyscale), and got some quite nice ones of the new runway at CMAC:

On saturday afternoon I concentrated on improving my flying skills. I flew over 90 takeoffs and landings that afternoon, which really improved my confidence.

On Sunday morning we flew a search mission again, but this time with the IR lamp in place to allow us to get a better idea of what 'Joe' will look like from the air. You can see the IR lamp in the picture below (circled in red with the circle automatically placed by our very simple search code).

You can also see the edge of the foam hole in the plane near the bottom of the image. The velcro we were using to keep the camera centered on the hole was not as good as we'd hoped.

At the end of this flight we had our first crash with this plane. The USB connector between the APM and the pandaboard came loose, causing mavproxy to reconnect, which rebooted the APM. The reboot process took 5 seconds, during which time the plane went crazy, flying upside down for some of the time!

I knew this could happen (as I hadn't found a way to stop the DTR drop on the USB serial link from the panda, the normal termios calls don't work), so I had the APM setup for air-start. Unfortunately I didn't realise the APM had rebooted until later, and at the time I thought a control surface had come loose. I switched to manual and tried to bring it under control, but failed, and it hit the ground. There wasn't much damage (the SkyWalker is tough!), but it is a shame I didn't just trust in the autopilot to regain control after rebooting, as it would have been a good test. The mavlink logs show the reboot took 5 seconds.

After that we added a bit more tape to the nose where it suffered some crumple damage and went flying again. Andrew and Steve had some time flying the plane to get some practice in, then I started some more serious practice as part of my long term goal of earning my MAAA wings. After practicing takeoffs and landings on Saturday I thought it was time for something more ambitious, and did some barrell rolls and loops. It sure is easier doing acrobatics with STABILIZE mode to recover! I did quite a few rolls and loops over a period of a couple of hours before calling it a day.

Overall, a great weekend!

After yesterdays transmitter failure, we flew the SkyWalker again today with Jacks Spektrum transmitter. This time everything went very well, and we successfully flew a search pattern over the CMAC field.

The flight we did was:

 - takeoff in fly-by-wire-A mode
 - switched to GPS loiter, worked well
 - switched to full auto, and flew a "mow the lawn" 18 waypoint search
   pattern over CMAC

The plane flew beautifully and the APM behaved perfectly. The audio feedback from mavproxy was really useful (it called out the waypoint numbers automatically during the flight for example). The wind was quite strong, and the SkyWalker coped well, although its speed upwind was affected quite a lot. From the GPS log, the upwind speed in auto mode was around 21km/h, whereas the downwind speed was around 48km/h, which means we were fighting a 27km/h wind. The upwind track ended up with a lot of curves in it, whereas the downwind tracks were fairly straight.

Tracks for the fully automatic part of the flight are here:

 http://samba.org/tridge/UAV/SkyWalker/logs/2011-04-26/f2/CMAC-search.kml
 
The planned search pattern is here:

 http://samba.org/tridge/UAV/SkyWalker/logs/2011-04-26/f2/CMAC-search-plan.kml

as you can see, the wind really pushed it off course!

There are a few photos here:

http://photos.tridgell.net/v/CanberraUAV/SkyWalker/

and a video of the auto-search here:

https://www.youtube.com/watch?v=rUr55J0T4_Q&feature=channel_video_title

We flew with 2x2200mAh 3S LiPos wired in parallel, and after the plane landed we measured the amount of charge the charger would put in as around 900maH per battery. From that, we estimate we'll get around a 1hr flight time if we switch to a 5000mAh 4S battery.

We're now planning on adding the pandaboard and ptgrey camera this week, and we will try a search pattern with the camera in the SkyWalker next weekend. That will give us the image data we need combined with full telemetry (attitude, GPS, altitude etc) to get back to the image processing and 'find Joe' task for the outback challenge.

I finished my SkyWalker build last night, and went out to CMAC to take it for its first flight. All the ground tests looked good (including the new 'system check' in mavproxy) so we took it for the first flight. About 60 meters into the flight I heard "MODE STABILIZE" from mavproxy, and I lost control. Jack and I watched as the SkyWalker glided gracefully to a perfect landing in the grass while we wondered what had happened.

After looking at the mavlink logs, we saw that the APM had started to receive failsafe values from the receiver soon after takeoff. Jack thought the antenna on the receiver might be a bit dodgy, so we replaced it with a 2nd receiver I happened to have in my box of spares, and we tried again. It was almost an exact repeat of the first flight, losing transmitter control soon after takeoff, APM going to STABILIZE mode, and the SkyWalker landing perfectly in the grass.

We then started to do more extensive ground tests and found that the Turnigy TGY 9X transmitter had failed. It has previously had good range, but for some as yet unexplained reason it now doesn't do more than 60 meters or so.

We had a good look inside the transmitter module, and we can't see anything wrong. The antenna cable is a little bit abraded on the transmitter, although it isn't clear if that is the cause of the issue. Strangely, the range test button doesn't find the problem. I get the same range with the range test button pressed as when its off. When I got home I checked the range test switch in case it was faulty and it seemed to be working fine (at least as far as my multimeter can tell). It looks like I might need to buy a more expensive transmitter. Pity, as otherwise the TGY 9X has performed well!

The real hero of the flight was the APM. The failsafe values in my receiver had the mode switch set to STABILIZE, and it glided the plane down to a perfect landing both times. I don't have it set to RTL for failsafe as it would be a breach of the club rules to circle above the takeoff point (you'd be going over the clubhouse).

Tomorrow we're going to try a different transmitter and see if the SkyWalker can live up to its reputation as a great UAV. We've got a "mow the lawn" search pattern setup to simulate the type of search we will be doing for the outback challenge. If that goes well we will put the pandaboard and ptgrey camera in the plane and get back to testing our algorithms for finding Joe.

Once things look OK with the SkyWalker we'll see about putting all the equipment in our CyberHawk UAV, which is what we plan to use for the OBC next year.

This video shows the result of modifying a T41 Thinkpad to give a full colour sunlight readable display:

Full credit for both the idea and the modification should go to Nic Schraudolph from the Canberra MakeHackVoid group. I just supplied the old thinkpad to modify when Nic suggested that this would be a good way to get a sunlight readable GCS for the CanberraUAV project. Thanks Nic!

There are some more photos of Nic modifying the laptop here:

http://photos.tridgell.net/v/CanberraUAV/GCS/

My quad (recently renamed to the "flying duckling") had a bit of a mishap today

the angle on that left motor and the shape of the prop isn't just an optical illusion unfortunately! Luckily I had already ordered some spares from jdrones, so I should be flying again tomorrow.

The crash happened when I was successfully flying in LOITER mode for the first time. The quad was holding nicely at about 20m, with just a little bit of wind drift, when one motor suddenly stopped. Unfortunately I didn't have my ground station running at the time, so I have no clue as to why it stopped. I certainly can confirm that a quad flies very badly on 3 motors - it tumbled to the ground and hit pretty hard. I think I was lucky it was on grass, and I only lost one arm and a prop.

It has been a week of unfortunately accidents for the CanberraUAV team. Last Sunday we were flying our UAV plane on autopilot for the first time, when we had a bad crash:

That bit of grey stuff on the right is the edge of the engine sticking out of the ground. It buried itself quite deep when it hit at nearly 30 m/s. Luckily we did have mavlink logging on for this one, and after looking at it for a bit we were able to determine that we'd screwed up the dip switch settings. We had the plane in elevon mode, which doesn't work well if you don't in fact have elevons!

We're trying again tomorrow with a cheaper foam plane, just to get some more experience with APM on a disposable plane. We'll move up to the more expensive planes again once we really know what we're doing.

Meanwhile, I'll put another arm on my copter, and make sure I turn on logging before my next flight, so I have some hope of working out why an engine stops (if it happens again). My best guess is that one of the connectors to an ESC may have become disconnected due to vibration, but thats just a guess. I'll also try running it on my bench for a while, in the hope that the problem may happen when its tied down.

More toys

Meanwhile, a new toy arrived from ebay. I bought a laser tachometer for the princely sum of $6.99 (plus $6.95 in postage). I used it to test the speed of the props on my quadcopter. Very handy! I just put little reflective stickers (which come with the tachometer) on the props and the tachometer quite happily locked onto them. You can see them in the above photo.

I've been having a lot of fun with my new ArduCopter. My initial flight was interesting - due to me switching flight modes with the throttle up it jumped off the floor and flew straight at me. I now have a nice scar on my shoulder as a memento of that first flight :-)

Since then I've been taking things a bit more carefully. The above photo shows the copter tied down to a 20 litre tin of paint, so it can only rise about 10cm off the tin. It will be released from its string prison once I've got some of the glitches out.

The particular glitch that has me puzzled at the moment is ESC callibration. During some testing I suspected that the motors were not all running at the same speed, so I wrote this little tester and hacked it into the ArduCopterMega trunk:

static void run_testmode(void)
{
  Serial.println("Running motor test");
  for (uint16_t thr=1100; thr<=2000; thr += 100) {
   for (unsigned char i=0; i<4; i++) {
      Serial.printf_P(PSTR("motor test %u thr=%u\n"),
        (unsigned)i, (unsigned)thr);
      APM_RC.OutputCh(i, thr);
      delay(1000);
      APM_RC.OutputCh(i, 1000);
      delay(1000);
      if (Serial.read() != -1) {
      Serial.println("terminating motor test");
      for (unsigned char j=0; j<4; j++) {
        APM_RC.OutputCh(j, 1000);
      }
      return;
      }
   }
  }
  Serial.println("Finished motor test");
} 

The code runs each of the motors in turn, starting at a PWM value of 1100 and rising to 2000. As I suspected, it showed that one of the ESCs (the one driving the front motor) is calibrated quite differently from the other 3. The front

ESC runs at 1100, when the other 3 don't run at all, and doesn't run at all at 1900 or 2000, while the other 3 do run up to and incuding at 2000.

I have been through ESC calibration, using this bit of code, which is based on some code from the ArduPirates tree:

static void calibrate_ESCs(void)
{
        Serial.println("Disconnect battery then hit enter");

  while (Serial.read() == -1) ;

 Serial.println("Now connect your battery. After beep beep, hit enter");

       while(1) {
         APM_RC.OutputCh(0, 2000);
          APM_RC.OutputCh(1, 2000);
          APM_RC.OutputCh(2, 2000);
          APM_RC.OutputCh(3, 2000);
          APM_RC.Force_Out0_Out1();
          APM_RC.Force_Out2_Out3();
          delay(20);
         if (Serial.read() != -1) break;
    }
        Serial.println("wait for beep then hit enter again");
        while(1) {
         APM_RC.OutputCh(0, 900);
           APM_RC.OutputCh(1, 900);
           APM_RC.OutputCh(2, 900);
           APM_RC.OutputCh(3, 900);
           APM_RC.Force_Out0_Out1();
          APM_RC.Force_Out2_Out3();
          delay(20);
         if (Serial.read() != -1) break;
    }
        Serial.println("disconnect your battery and then hit enter again");

   while (Serial.read() == -1) ;
}

If I understand correctly, that should have calibrated all 4 ESCs to the same value, but it didn't seem to work.

Does anyone have any suggestions? Is it just a matter of replacing the ESC that is out of kilter with the others?

UPDATE: I've solved it! The problem was I had misunderstood the importance of the timing in the ESC calibration instructions. I read the ESC manual, and noticed that the procedure for entering programming mode is actually the same as the initial steps for doing throttle callibration. The only difference is how long you wait after connecting the battery the first time. I was beiing "conservative" and waiting several seconds, and the ESCs were entering programming mode instead of doing throttle calibration.

I now have my 4 ESCs calibrated correctly, and it hovers quite nicely in its string prison. I will be able to try a real flight now, and see if it lasts a bit longer than the first one!