Rpanion-server 0.7 has been released!

Rpanion-Server is an Open-Source software package for a managing the companion computer (such as the Raspberry Pi) connected to an ArduPilot or PX4 flight controller. It will run on most Linux-based systems.

Rpanion-Server consists of a network manager, MAVLink telemetry routing, flight logging and a low latency video streaming server. All can be managed via a web-based user interface.

Documentation and pre-built disk images for the Raspberry Pi are available at https://www.docs.rpanion.com/software/rpanion-server. Source code is at https://github.com/stephendade/Rpanion-server

New in 0.7 is:

• Support MJPEG cameras for video streaming
• Added button to disable all Wi-Fi adapters
• GUI overhaul, using the Bootstrap framework
• Various bug fixes

The latest version of Pi-Connect Lite board has been released. It's a minor increment over the previous version, with better power switch placement and clearer labels.

It is ideal for anyone wanting a quick and simple way to integrate a Raspberry Pi board with a MAVLink-based flight controller, with a high capacity power supply and Pixhawk-standard JST-GH telemetry connector. It also features a power switch for safely shutting down the Pi.

Take a look at the full specifications over at: https://www.rpanion.com/product/pi-connect-lite/

I'm pleased to announce that after 9 months of design and testing, the Pi-Connect (Lite) is now available!

The Pi-Connect Lite is a HAT addon board for the Raspberry Pi that integrates the following into a single board:

• 5.1V/3A BEC with high quality components
• Telemetry port for connection to Ardupilot/PX4 based flight controller
• Power switch for safety shutting down the Raspberry Pi

By putting all 3 functions into a single board, it makes for a far simpler (just plug it in and go) and reliable (all connectors are positively locked) setup when including a Raspberry Pi in an Ardupilot/PX4 powered vehicle.

For more information (and webstore), see www.rpanion.com

After 6 months of research, development and testing, I've launched the Pi-Connect on Indiegogo. The Pi-Connect is an addon board (HAT) for the Raspberry Pi that provides easy and reliable integration with autonomous vehicles.

It provides:

• 5.1V / 3.5A power supply
• JSH-GH telemetry port for connection to a flight controller
• 2x powered UART ports in "FTDI" 0.1" headers for connection to on-board serial devices
• ADC (MCP3008) for monitoring of voltage rails or other sensors
• Power button that safely shuts down the Raspberry Pi

I'm using Indigogo to fund a small production run, so if you want a board go to https://igg.me/at/piMdxRo2YBg/x/2660470#/

The Australian Government has recently registered an amendment to the Civil Aviation Legislation Amendment (Part 101) - concerning the regulations of Remotely Piloted Vehicles (RPA's).

Some of the more interesting changes are:

4 classes of RPA, based on all-up-weight:

• Micro RPA (0-100g)
• Very Small RPA (100g-2kg)
• Small RPA (2kg-25kg)
• Medium RPA (25kg-150kg)

Commercial Operation

No training or licences required to operate Micro and Very Small RPA's commercially in standard flight conditions. However, CASA does have to be notified 5 working days beforehand.

Operation over Private Land

Small RPA's and below can operated over private land (the landowner/occupier must own the RPA) in standard flight conditions without requiring any licences or training.

Licensing

New “Remote Pilot Licenses” to replace UAV Controller Certificate.

Standard Flight Conditions

Standard (not needing an exemption from CASA) conditions have been tweaked slightly to:

• Under 400ft AGL
• Outside of 30m from other people
• Not over a populous area
• Not within 3nm of an airport
• Not in a restricted or prohibited area
• Not over an area where public safety or emergency operations are being conducted (without their prior permission)
• Is within visual line of sight by the operator

The full changes to the legislation are available at https://www.legislation.gov.au/Details/F2016L00400

EDIT:

Note this legislation does not come into effect until 1 October 2016

Last week CanberraUAV gave a presentation and flight demonstration to the Canberra branch of the Royal Aeronautical Society (RAes).

This covered the history of CanberraUAV in competing in the UAV Outback Challenges in 2012 and 2014, the group's purpose and past/current R&D activities. This also included an introduction to the world of open-source UAV development by Ardupilot developer (and CanberraUAV member) Andrew Tridgell.

At the end there was a flight demo of a quadplane, showing off it's autonomous flight modes.

Cobham have recently released their "Aviator 200 UAV" - a satellite datalink system specifically made for small UAV's.

Although you'll likely need deep pockets to afford one, it shows that the satellite communications industry has realised there is a market for small UAV's that require beyond-line-of-sight communications. As more manufacturers come onboard the competition should start driving the price down.

Specifications:

Weight: 1.45kg

Dimensions: 24x16x6cm

Datarate: up to 200kbps

Coverage: near-global (uses the INMARSAT-4 satellites). Does not cover the Arctic/Antarctic regions.

Power usage: 28W

By having this sort of technology, operating small UAV's over longer ranges become much more practical and safer, via the presence of a reliable and high-bandwidth datalink that is not range constrained.

Manufacturer's brochure: https://www.cobham.com/communications-and-connectivity/satcom/cockpit-and-cabin-communication/uav-satcom-systems/aviator-uav-200/aviator-uav-200-brochure/

For most people running electric vehicles, it has always been assumed that the motor(s) will always use far more power than the flight controller and associated control systems.

However, for those people running internal combustion engines (or gliders, balloons, etc) for long duration flights the question of power consumption of the flight controller becomes a much more important question.

I spent some time measuring the power requirements of a Pixhawk flight controller and thought I'd share the results with the community.

I cut up a USB cable in order to run it through my multimeter. The same was done for another cable with an XT60 connector. This would allow current readings over both USB and battery power.

Over USB power a standard Pixhawk setup (Pixhawk running APM:Plane 3.3.0, GPS/Compass modules, safety switch, buzzer, 433 MHz telemetry radio) a total of 280mA current is drawn. Breaking this down by component gives the following plot:

Of note in the above pie chart is the GPS module uses almost 1/5 of the total current requirements. The Pixhawk itself uses the vast majority of the power, as expected (with its comparatively high-powered CPU and many diagnostic LED's).

There was very little difference with the APM:Copter and APMRover2 software running in both armed and disarmed states. All 3 APM branches are consistent with their power usage.

Moving on to the other 2 power supply inputs (Pixhawk power module, ESC into servo rail), it was noticed that the main LED on the Pixhawk is very high powered - on the order of a 1/2 Watt.

In comparing the different power supplies, using total power consumption (Watts) is most appropriate. Note when using USB power the USB port on my PC was measured to be 4.5V rather than the 5V standard.

The above chart uses a full (GPS, compass, radio, safety switch) setup. The “min” and “max” refer to the power draw with the main LED of the Pixhawk off and on respectively.

The Pixhawk does use more power when connected via battery. I put this down to the various LED’s (and possibly a few IC’s) using more power as they would be operating at a higher voltage (5V clean power vs the 4.5V USB power).

The difference between the power consumption via the Power Module and via the ESC would be likely due to a lower efficiency 5V regulator in the ESC. However, the gap (~0.3W) seems a little wide to account for all of it. Some of it may be due to the way power is routed through the protection diodes in the Pixhawk.

Next is a comparison with the old APM2. The APM2 uses a far less powerful processor (both in terms of power usage and data processing capacity) and has fewer sensors on-board. So it would be expected to use less power:

The APM2 uses roughly 1/3 as much power as the Pixhawk (not including external components). The APM2 is remarkably efficient with its power usage – a maximum of 0.5W!

Putting this together with the appropriate external components and a standard Lipo battery gives us an expected operational time:

Once the GPS, radios, etc. are included, the gap between the Pixhawk and APM2 narrows. Using a standard 3-cell 2000 mAH battery gives in excess of 8 hours operating time for a Pixhawk and over 10 hours for the APM2, which allows for some very long-duration flights.

In conclusion, for a standard Pixhawk setup, allow 2 to 2.5W power consumption. If this is an issue, look at disabling the main LED and removing non-essential external components.

If power consumption is truly important, it would be worth going back to an APM2, which only uses 0.5W by itself.

After our win at the 2014 UAV Outback Challenge and the many subsequent team discussions, CanberraUAV has developed a detailed set of goals for the next couple of years (see below).

The general theme is that we want to build up a capability to run real-life Search and Rescue scenarios in concert with the emergency services. We also want to collaborate with other like-minded organisations to do the same.

And as always, we remain committed to publishing our documentation and source code and remaining an “open” organisation dedicated to advancing the field of civilian UAV technology.

We always welcome new members. So if you see something on the list of goals that you’re interested in contributing to, let us know.

Finally, it’s been an amazing 4 years since the beginning of CanberraUAV and we can’t wait for what the next 4 years will being!

The following goals we aim to complete in the 2015-2016 timeframe.

Imaging

Lead: Tridge

• Researching new cameras that are able to detect a shoe sized object at 100m altitude
• Imaging software improvement to detect the aforementioned shoe
• Record a reference set of images of an area with items strewn in it, to be used for development of imaging software
• Support use of common cameras (ie Gopro), and document shortfalls
• Provide comparison images between cameras (multi-camera flights)
• Start using thermal cameras (if not too expensive) in the future

Airframe development

Lead: Jack, James, Greg, Darrell

• Development of a rugged airframe (Bushmaster mk II) that can carry an imaging payload for a 1 hour flight and does not require a prepared runway for takeoff and landing
• Investigate use of petrol helicopters and high efficiency multicopters as option
• Development of a simple small foam airframe (Techpod, etc) fitted out with CanberraUAV electronics. Test and develop range, duration stats

Ground Equipment

Lead: Chris, Matt

• Develop a compact catapult/launch system capable of rapid deployment in remote locations as a possible solution to absence of runway. Suitable for 4-10kg airframes
• Develop capture mechanism/procedure for recovering airframe in remote locations to minimise damage to airframe e.g. chutes, net etc
• Improve transportability and readiness of our equipment to allow for short notice deployments when interesting opportunities arise. Know the capabilities and limits of our airframes and suitability for the particular scenario
• Fitting out the Ground Control Van in a better way, based on our OBC 2014 experiences
• Develop a ruggedised mini Ground Control Station (pelican case) to enable small footprint operations

Running a mini-OBC

• Research the feasibility of running a small scale competition/challenge with the objective of finding multiple large and small objects in a given area
• Running a “Drone Day Out” in conjunction with mini-OBC, to showcase technologies and provide information to the interested public

Radio data link R&D

Lead: Tridge, Stephen

• Look at using 915-928 MHz ISM radios for high-datarate datalinks, as they give better range
• Antenna Tracker improvements (depends on radio used)
• Develop a 3G/4G solution for situations where it is appropriate
• Look at the feasibility of a satellite data link
• Enhanced link aggregation and failover
• Investigate 2.4 GHz Ubqiuti radios if the 900 MHz radios don’t work out
• Main goal is a long range / “high” bandwidth radio that can fit on small aircraft (ie. Skywalker)

Safety Management System

Lead: Chris, Jono, James

• Develop and implement a mature safety system for CanberraUAV’s operations
• Create checklists, procedures for each position. Includes abort modes and airframe/engine hours/battery cycle tracking
• Create an occurrence form to track and identify hazards, incidents and accident
• Try to continuously improve CanberraUAV’s safety by performing ad-hoc safety management activities.
• Develop a safety management system for CanberraUAV
• After 12 months, the goal would be to transition to the SMS, which would be ongoing and more mature way to continuously improve safety (compared to ad-hoc safety management)

Documentation and Admin

Lead: Stephen

• Update documentation for the cuav and MAVProxy software packages
• Investigate more effective ways to manage and publish documentation
• General updates of the CanberraUAV website and “admin” github repository
• Collating documentation into a “how to” guide for S&R organisations to quickly replicate our setup. Include data on different systems (ie. compare cameras)
• Gain UAV Operators Certificate to enable non-hobbyist operations
• Document a “how to” guide to enable prospective users to build our system step by step (suggest video/series of videos on youtube). This would include ground station setup, telemetry links, MAVProxy.

Collaboration

• More work with universities, high schools and SAR organisations
• Work with landcare or similar groups for environment monitoring type tasks
• Build relationships with emergency services/SAR organisations (ie SES)

Now that we’ve returned to Canberra and taken a well-earned break, we have spent some time reviewing our performance at the OBC. The following article is a review of what we did and didn’t do well as a group at the OBC.

Winning the OBC, whilst an awesome achievement, has also provided us the chance to act out a search and rescue scenario as a team. Thus a review of our performance at the OBC provides some valuable information on how we can improve ourselves in future “real life” S&R scenarios, in addition to providing hints and tips for other likeminded UAV organisations.

Note that this review is from a generally non-technical perspective. Fellow team member Andrew Tridgell has written an excellent technical review of our performance at the OBC.

Things we did well:

The two radio systems (5.8 GHz Ubiquiti Rockets and 928MHz RFD900’s) used for telemetry and imagery worked quite well. The automatic failover between the two links worked flawlessly and enabled us to easily work outside of the range of the 5.8GHz datalinks for parts of the mission.

The Pixhawk/APM:Plane flight controller tracked the waypoints during the mission extremely well during periods of strong gusting winds.

Our image recognition hardware/software found the missing bushwalker easily and quickly displayed it on our screens. Repeated passes over Joe allowed us to get a high accuracy on our estimated position of him.

The wind correction algorithm for our bottle drop, whilst simple, worked extremely well. During testing, we’d used our data to develop an empirical formula for predicting the bottle drop location based on the aircraft’s position and speed and the direction/velocity of the wind.

Things we didn’t do so well:

Labelling of power ports – during setup, we accidentally killed the ethernet switch used in the Ground Control Station (GCS) network (as we had multiple GCS operators/laptops) by plugging the switch into a 12V plug instead of the 7.5V plug. Fortunately, we’d bought a spare switch with us!

Checklists and communications were definitely an item we’d not tested and developed enough. There was confusion about who was doing which check and when on the checklists. Some critical items were left out of the checklists.

Our takeoff and landing (done automatically by the APM) were marginal, far below our usual quality. The takeoff in particular raised some  concerns from the OBC Judges, as the UAV was blown off course towards the GCS and Judge’s tents during takeoff. From an organisational perspective, several things did NOT happen:

• We did not take the wind into account during our takeoff preparations
• Lack of practice in taking off in windy conditions
• Lack of communication between the GCS and Pilot as to the wind conditions
• Lack of practice in aborting automated takeoffs

At the end of the day, we were very focussed on gaining the extra points in the OBC (for an automated takeoff and landing) and we never stopped to properly consider the circumstances under which the automated takeoff would not be appropriate.

During the mission itself, our antenna tracker required slight offsets to track the UAV properly. Part of this was due to a different magnetic environment at Kingaroy (compared to our home base in Canberra) degrading the compass accuracy. In addition, we’d never considered having to set up the antenna on non-flat ground!

As mentioned previously, the landing to Kingaroy airport also presented some issues. One again, the wind had its own ideas and carried the aircraft past our nominal landing point and it did not land until much further down the runway, finishing up very close to the geofence. As with the takeoff, we did not consider the effect of strong winds on our aircraft during this phase, nor did we have experience in landing in strong winds.

So, for other UAV operators out there, we offer the following advice:

• Don’t just have checklists – use them regularly and continuously improve them
• Practice flights in a variety of wind conditions. Know the limits of the airframe and of the automatic flight modes in these wind conditions
• Ensure that safety is always put first - have a safety management system. UAV’s do have the potential to hurt or severely injure people!
• If operating in a team, make sure that everyone clearly knows what their responsibilities are. Checklists and operations manuals work well for this. Following this, regular practice with a full UAV/GCS setup with the entire team is a must

A full review list is available at https://canberrauav.readthedocs.org/en/latest/lessons/OBC2014/review.html

We'd like to thank 3DRobotics for their very generous support of CanberraUAV for the 2014 UAV Outback Challenge. Thanks also go to all the individuals we've collaborated with, to further the field of S&R UAV platforms.

It's that time again!

With only 2 weeks until the UAV Outback Challenge (OBC) 2014, there is a record 20 teams from around the world ready to win the Challenge.

The OBC is a civilian UAV competition where teams must design, build and operate a UAV that is capable of finding a missing hiker and dropping a bottle of lifesaving water to them. It is held in Kingaroy (Australia) every second year and has attracted many hobbyist and university teams.

First prize is $50,000 and is yet to be claimed, giving an idea of the technical challenges involved in the OBC.

Many of the teams involved are using open source flight controllers (such as APM:Plane) and do contribute back to the community, furthering the hobbyist UAV movement.

The full list of entrants is:

• Aeolus (Singapore)
• Open UAS (Netherlands)
• NCSU Aerial Robotics Club (USA)
• Team Condor (Australia)
• Monash UAS (Australia)
• Perth UAV (Australia)
• IRSA Group (Iran)
• Compass UAV (Australia)
• Swiss Fang (Switzerland)
• MelAvio (Poland)
• VAMUdeS (Canada)
• SFWA (Australia)
• TinBox UAV 2 (Australia)
• Robota (USA)
• Rescue Robotics (Australia)
• Team Aetournos (France)
• H2Joe (Australia)
• MUROC Wild Hogs (Australia)
• Canberra UAV (Australia)
• Team Thunder (Australia)

As the manager of the CanberraUAV team (that were first place winners in the 2012 OBC), I'd like to offer the best of luck to all teams competing in the 2014 OBC, and we'll see you all in Kingaroy in 2 weeks!

I recently ran a build-your-own-quadcopter workshop in Canberra (Australia), where 9 people learned how to construct, tune and fly quadcopters based on the Pixhawk flight controller.

This workshop is the second one I've run (1st workshop here). There have been several improvements this time around: A stronger frame, pre-soldered connectors and usage of the Pixhawk.

There were of course minor technical difficulties (such as not ordering enough standoffs!) along the way, but we got there in the end and everyone had a great time!

For those that want to run their own workshops, I've published the documentation for this workshop here. It includes a full workshop manual, APM:Copter parameters file, materials list and useful links.

In Canberra (Australia) we recently ran a "How to use MAVProxy" workshop at the MHV workspace. We had a dozen or so people turn up and we spent the afternoon going through the software and it's numerous modules.

For those who don't know about MAVProxy, it is a UAV ground control station (much like Mission Planner). The emphasis is on portability, stability and low use of system resources. It was the ground station software used by the CanberraUAV team in the 2012 Outback UAV Challenge.

By itself it runs on the console, but can be extended via modules which provide a (basic) GUI. It works on any Windows or Linux machine (via Python) and is compatible with any UAV using the MAVLink protocol, such as the APM and PX4/PIXHAWK.

The documentation for MAVProxy has recently been updated and can be found at http://tridge.github.io/MAVProxy/

A documentary called "Robots in Flight", following the events of the 2012 UAV Outback Challenge has now been released to Youtube:

A number of teams (such as CompassUAV, TGIF and the 1st placed CanberraUAV) used the APM as the flight controller in their airframes.

The rules and dates of the 2014 UAV Outback Challenge have been released - http://www.uavoutbackchallenge.com.au/index.cfm?contentID=49

The aim of this challenge is to design/build/operate a UAV beyond line-of-sight to search and 2.5km area for a missing hiker and drop a bottle of water to them within a 60 minute time limit.

The is a AU$50,000 prize for the winner, which is yet to be claimed.

Last year's first-place holder CanberraUAV used a APM2 based Mugin UAV and successfully found the missing hiker. Unfortunately, the bottle drop mechanism malfunctioned before they were over the hiker.

This competition attracts entrants (both amateur and university based) from across the world and it would be awesome to see more representation from the DIYDrones community.

(FYI - I am part of the CanberraUAV team, so I'm happy to provide further advice about the challenge)

Over the last 4 weeks in Canberra (Australia) I've been a running a build-and-fly-your-own-quadcopter workshop, based on the APM.

We had a dozen excited people attend the workshop and all were successfully able to build their quadcopters. The flying lessons were mostly successful - we only had a 25% crash rate (mostly broken arms, easily replaced).

Full documentation for the workshop is available at https://canberrauav.readthedocs.org/en/latest/lessons/quadcopter-workshop.html if others in the community want to run their own workshops, which I definitely encourage!

It's a great way to promote civilian usage and education of multicopters/drones. I've also found these workshops to be massively popular. I only had 12 spots available in this workshop, all of which filled up within 48 hours. I think this demonstrates the massive interest in multicopters.

Finally, a time lapse video of one of the workshop sessions:

The CanberraUAV team spent last Sunday playing with our new Hero 3 camera.

This is our X8 flying wing (piloted by Tridge) running through it's paces at CMAC:

MAVProxy is a open source minimalist and plugin-based GCS for Mavlink based autopilots (such as the APM). Until recently, it was only able to run on Linux systems. It has since been updated by Tridge and myself to include full compatibility for Windows systems.

MAVProxy can be found at https://github.com/tridge/MAVProxy and an installation and user's guide is available at http://www.qgroundcontrol.org/mavlink/mavproxy_startpage.

And the obligatory screenshot of MAVProxy running in Windows and Linux at the same time (above)

Following on from Tridge’s article (here), this article focuses on the bottle drop malfunction in CanberraUAV’s flight at the UAV Outback Challenge 2012.

The aim is to show the evidence and theories about why/how the bottle came off, with an emphasis on post-flight analysis on the flight logs. This will hopefully assist other users and developers in analysing their own flights.

What we know

• Takeoff was at 13:43 (local time)
• We entered the search area at 13:46
• The bottle sensor showed “dropped” at 13:53
• Over the next couple of minutes, our speed dropped to 50%
• Exited the search area at 14:33
• We landed back at the airport at 14:35
• The UAV looked like this after landing:

• The bottle was found in a field in the search area in 1 piece, undamaged.

It was obvious that the bottle had come off mid-flight. The parachute became tangled in the propeller. There was a large chip in the propeller that indicated a large collision with it, possibly from the bottle (note the propeller was brand new at the start of the competition).

As for any investigation, the aim is to review the events and data leading up to the event of interest. Fortunately, we have full flight logs (here). They were captured via MAVProxy. The analysis was performed using the Mavlink examples.

Analysis          

We had our bottle drop sensor (digital microswitch) connected to the voltage sensor on the APM.

Considering the speed drop after the bottle drop, a reasonable theory was that bottle “hung around” (possible caught on the tail) for a while, adding drag to the UAV. However, the throttle compensation needed to maintain cruise speed was needed throughout the entire flight after the bottle drop. This indicates a permanent effect – possibly engine damage.

Let’s take a look at that:

mavgraph.py flight.log VFR_HUD.airspeed VFR_HUD.groundspeed SYS_STATUS.voltage_battery:2

(The “:2” tells mavgraph to use the right-hand axis for the aforementioned variable)

So, we have the speed scale (m/s) of the left and microswitch voltage (mV) on the right.

This graph shows us the speed did definitely go down at around 13:56, several minutes after the bottle drop sensor showed dropped. Thus there was some time between the bottle coming off and the engine being affected.

Also of interest is the “almost drops” 5 times before the final drop. This could indicate that the microswitch was rapidly switching on/off for ~15 seconds on a number of occasions. Possibly the bottle was already loose and was rolling off the sensor.

The question is why the bottle was rolling off the sensor at these times. There seemed to be a possible relation to groundspeed though.

So, let’s have a look at what direction the UAV was flying in:

mavgraph.py flight.log VFR_HUD.heading SYS_STATUS.voltage_battery:2

This shows quite clearly that each time the UAV did a 90 degree turn, the bottle rolled off it’s sensor.

We can also look at the UAV’s roll and pitch:

mavgraph.py flight.log ‘degrees(ATTITUDE.roll)’ ‘degrees(ATTITUDE.pitch)’ SYS_STATUS.voltage_battery:2

(note roll and pitch are logged in radians. Mavgraph can do the conversion though, and any other basic maths)

Each time the UAV rolled, the bottle slipped a bit on the sensor. Maybe it was a bit loose?

As for the final drop, it would be possible that this would have imparted a large force of the UAV – if it was a sudden, forceful event (such as the propeller initially getting fouled with the parachute). So let’s take a look at the accelerometers and gyros for any evidence of this:

mavgraph.py flight.log RAW_IMU.xacc RAW_IMU.yacc RAW_IMU.zacc SYS_STATUS.voltage_battery:2

mavgraph.py flight.log ‘degrees(ATTITUDE.rollspeed) ‘degrees(ATTITUDE.pitchspeed)’ ‘degrees(ATTITUDE.yawspeed)’ SYS_STATUS.voltage_battery:2

Nope, nothing significant - no sudden large forces.

Thus the event would have not been particularly violent. It was most likely spread over some time.

Conclusions

Thus, given that:

• The bottle coming off the UAV was not particularly violent
• The UAV started slowing down a few minutes after the bottle came off
• The bottle was starting to let loose during turns, when the UAV was rolling at ~60 degrees
• The bottle itself show no signs of damage (thus was not caught in the propeller)

It is our best guess that:

1. Some string from the parachute came loose during flight
2. The rolls that the UAV was experiencing during turns may have moved the bottle assembly enough to let the string loose
3. Once the string was extended far enough back, it got fouled in the propeller
4. The bottle got partially ripped off – enough to trip the sensor, but not enough to completely release from the UAV
5. The force of this let the parachute string slip freely around the propeller
6. After several minutes, the propeller caught the string again, ripping off the bottle for good. As it came off, the rest of the parachute string caught on the engine block, damaging it
7. As a result of this damage, the engine could not maintain speed at the given throttle level.
8. The UAV continued slowing down until the Ground Station commanded a ~20% throttle increase.

And that’s how you analyse an incident with your UAV/drone:

• Look at the physical evidence
• Look at the flight logs for any unusual readings
• Look for links (i.e. occurred at the same time) between different data variables and the physical evidence
• Develop a timeline of events, with a focus on why one event led to another event and so forth until you reach the incident in question
  
• Come up with the most likely, logical explanation for the incident.

Note: a full list of all the MAVlink datafields collected in a standard log is here. Note not all autopilots use all the datafields. Some may be blank.

We won't be able to begin the (long) process of uploading the photos and imagery of CanberraUAV until we get back home, but I've uploaded a few of the "best of" photos taken from our UAV inflight:

(Flying over Joe)

(Passing over the Range Official's tent)

More images can be found on the CanberraUAV Flickr Group.