One of the more important features that will arrive with Copter-3.4 (still in beta testing) is the Polygon Fence (the full list of features can be seen in the ReleaseNotes.txt).

Plane has had the polygon fence for years but when we added it to Copter, we also added the ability to stop at the fence in Loiter mode and when using Guided mode's velocity controller.  This stop-at-the-fence feature is quite exciting, not only because it's a feature people have been asking for for a long time but because it's also a solid step towards reliable object avoidance.

If you want to give it a try now and are happy to accept the risks of beta testing, there's a quick how-to video below showing how to define and upload the fence using the Mission Planner (MAVProxy can also be used but other GCSs don't yet support this feature).  Over the coming weeks we will update the wiki to include this info.  For those not looking to become beta testers you can look forward to it once Copter-3.4 is official released.

You can also find the code showing how we implemented stop-at-the-fence here.

Some extra info and a couple of warnings:

• The fence can theoretically have up to 84 points but I have not tested with more than about 10 so far.  As the number of points grows, it does require a small amount of additional CPU so we will keep an eye on the "PM" (performance management) dataflash log message to see if the real limit is less than 84.
• There is also a slight issue with very acute angles meaning the vehicle might be able to breach the fence if you create a fence that looks like Bart Simpson's hair.  Nothing horrible will happen except that the vehicle will RTL as it normally does when it breaches the fence.

By the way, the stop-at-the-fence feature works with the circular fence as well. If you define both a circular and a polygon fence, the vehicle will stop at whichever barrier it hits first (i.e. the green lines shown below)

As I mentioned above, if you do give it a try, remember that Copter-3.4-rc2 is still beta so although it seems quite solid it's best to keep your eyes our for troubles, don't test on a vehicle that you could not stand to be involved in a crash and report any issues on our discourse server.

Thanks in particular to Leonard Hall and Daniel Ricketts for the code to stop the vehicle at the fence.

ArduPilot's Antenna Tracker firmware has been making some quiet progress over the past few months.  They're all documented in the Release Notes but at a high level the improvements include:

• More accurate control due to bug fixes in how the vehicle's position estimation was done
• Smoother movement through additional filtering
• Separate servo types possible for yaw and pitch axes
• Tilt compensation meaning it tracks the vehicle accurately even when the tracker is leaned over
• Improved Mission Planner setup screen (i.e. Extended tuning page)

The parts I used to build my tracker included:

• Emlid.com's NAVIO2 with RPI2
• Servo City PT785-S Pan & Tilt system
• Circular Wireless's 11db Antenna
• TP-Link TL-WN722N Wifi dongle

I used a NAVIO2 instead of a Pixhawk mostly because it's easier to make a Wifi connection this way.

I haven't yet tested the range of the telemetry connection to the Bebop2 but I suspect it's between 1km ~ 2km.  In fact, the antenna used here is not ideal for use with the Bebop2, a simpler non-Helical antenna like this one would likely do better.

Some limitations of this setup:

• we don't yet support receiving live video from the Bebop2 but this is coming within the next couple of months so during this test I simply had telemetry data from both Tracker and Bebop2 visible in the Mission Planner
• the networking connection between the PC to the RPI2 was quite simple but not very flexible.  For whatever reason the PC and RPI2 nearly always appear with the same IP addresses so the Tracker startup scripts were hardcoded to always uses these.  It would be better to setup dhcp on the RPI2 to set PC's IP address
• the bebop's Wifi ssid is hard-coded in the start_tracker.sh script on the RPI2.  If someone wanted to repeat this setup they would need to change this to match their particular Bebop.

In case people want to replicate this setup, I've uploaded an image to firmware.ardupilot.org here.

Thanks to the beta testers for their ideas and feedback and Stefan Lynka for his code contributions.

Copter-3.4-rc1 has been released for beta testing and can be downloaded using the Mission Planner's Install Firmware screen's beta firmware link.  Some of the changes since Copter-3.3.3 are listed below.

1) EKF2 allows "boat mode" (attitude initialisation without gyro calibration)
2) Throw mode by Paul Riseborough
3) Terrain following:
    a) Support terrain altitudes during missions using GCS's map data or rangefinder (i.e. Lidar)
    b) LightWare range finder driver fixes (I2C works but we still recommend using Serial interface)
    c) Bebop sonar support (we strongly recommend the Bebop2 over the original Bebop)
4) Precision Landing using IRLock sensor
5) Attitude controller re-organisation (all parameter changes automatically moved and scales adjusted)
    a) RATE_ parameters become ATC_RAT_ (i.e. RATE_RLL_P becomes ATC_RAT_RLL_P)
    b) Rate Roll, Pitch, Yaw P, D are reduced by 10% for X, V, H frames, increased by 27% for all other frames
    c) STB_ parameters becomes ATC_ANG_ (i.e. STB_RLL_P becomes ATC_ANG_RLL_P)
6) Motors library improvements:
    a) support OneShot ESCs (set MOT_PWM_TYPE to 0 for Normal, 1 for OneShot or 2 for OneShot125)
    b) TriCopter compensates for tail servo angle
    c) SingleCopter, CoaxCopter adjust control surfaces based on throttle output
    d) MOT_PWM_MIN, MAX allow specifying output ranges to ESCs which are difference from throttle input channel (i.e. RC3)
    e) TradHeli servo objects moved into heli class (HSV_ parameters become H_SV1_)
7) uAvionix Ping sensor support (ADS-B vehicles appear on GCS, avoidance will come in future release)
8) Improved Solo support (gimbal and buttons now work)
9) Pixracer support
10) Safety:
    a) warning if GPS update rate is slow (under 5hz, does not stop arming)
    b) RTL cone (vehicle won't climb to the full RTL_ALT if it is RTL-ing from close to home)

Warning: It has been reported that Tower's Follow-Me mode causes a rapid descent with Copter-3.4 so we recommend not using Follow-Me until this is resolved (it's likely a mix-up as we've added support for absolute and terrain altitudes).

For this release we will be doing the support on the new ArduPilot discourse server instead of creating a monster thread here on DIYDrones.

This beta testing include both multicotpers and traditional helicopters.  We're also starting beta testing of the Antenna Tracker (Release Notes here).

Thanks in advance to the beta testers!

P.S. I would like to personally thank EnRoute (youtube channel) for stepping in to support my ongoing development efforts on ArduPilot and Colestl/GatewayGeospatial for their sponsorship of the Terrain following work.

The upcoming Copter-3.4 release will include terrain following support for mission commands using either Google earth altitude data or a Laser Range Finder.  This is a demonstration video shot at a ski hill near my home in Karuizawa Japan of this new feature.

For this test I used a venerable 3DR IRIS with a PulsedLight Lidar Lite.  This lidar is difficult to find but actually I recommend the sensors from Lightware (like the SF10) which, although they are quite a bit more expensive, are much more reliable and offer a greater range.

With this new feature, the pilot can input a mission with altitudes specified as either Terrain altitudes (i.e. altitude above the terrain), Absolute altitudes (i.e. 1300m) or the regular Alt-Above-Home that we've always supported.

In case you're wondering how we decide whether to use google earth data vs lidar, if the vehicle has a lidar attached it will use it, if not, and the mission specifies terrain altitudes, google earth data will be used (Note: the ground station must support sending the terrain data to the vehicle which Mission Planner and MAVProxy certainly do but I'm less sure about Tower, APPlanner2 and QGroundControl).

This was actually the third or fourth test flight of the feature.  Some of the others are below with varying levels of success :-).

Terrain following with Google earth data

Terrain following with Lidar but crashes because of weak battery

Short mission with straight line waypoints (successful)

Longer mission with spline waypoints (unsuccesful because of tuning and hits altitude fence)

The changes are under peer review and should end up in master within a few days.

The dataflash log of the flight can be found here.

Special thanks to Leonard Hall and Tridge who helped me at numerous points during the development of this feature.

After months of testing by the beta-testing team and no significant issue during the soft release, Copter-3.3 has been released.  You can load this version onto your vehicle using the Mission Planner or APPlanner2's Install Firmware screen.

As mentioned previously, this version and all future versions of Copter only work with fast CPU boards like the 3DR Pixhawk (and compatible) boards, VRBrain, NAVIO+, etc. Slower CPU boards (i.e APM2.x) can continue to load Copter-3.2.1 from the MP/AP2.

Support issues should be reported in the APM Forum.  Enhancement requests and confirmed bugs should go into the GitHub issues list.  The wiki has been mostly updated but if you spot missing items please report them to the wiki issues list.

The full set of changes can be seen in the Release Notes but the highlights are below.

Known Issues/Warnings:

• users will need to re-calibrate their accelerometers because of 5c (accelerometer range increase).
• FrSky telemetry users must set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions
• this version corrects a long standing issue in the HDOP reporting so values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
• TradHeli is still in beta testing so it remains on AC3.2.1 for now.

Changes vs Copter-3.2.1
1) EKF replaces DCM/InertialNav for attitude and position estimation which provides more feedback and robustness in case of sensors failures
2) Control improvements:
   a) battery voltage compensation should maintain control as voltage drops
   b) current limiting can be used to reduce the maximum current requested to reduce strain on battery and ESCs
   c) air pressure compensation should reduce need for re-tuning when flying at different altitudes
   d) improved throttle curve should reduce wobbles during descents
3) AutoTune for yaw
4) Cameras & Gimbal improvements:
   a) SToRM32 gimbal support
   b) do-mount-control mission command allows controlling absolute camera mount angle during missions
5) Vibration resistance:
   a) real-time reporting of vibration levels by clicking on Vibe field on HUD (also recorded to logs)
   b) noise weighted average of accelerometers used to weight IMU towards the one exposed to less vibration
   c) accelerometer range increased from 8G to 16G to allow use in higher vibration environments (i.e. reduced "clipping")
6) Other:
   a) improved landing on slopes
   b) retractable landing gear support
   c) channels 9 ~ 12 can be used as auxiliary switches (like ch7, 8)
   d) PX4flow (optical flow) support in Loiter
   e) Brake flight mode (stops vehicle quickly but requires GPS)
   f) allow GPS, Telemetry, SToRM32 gimbal to be connected to any telemetry/serial port
   g) Lidar-Lite V2 support
   h) bug fix to RCMAP - remapped channel's MIN, MAX were taken from incorrect parameters meaning all channel ranges had to be the same
7) Tricopter tail servo parameters (MOT_YAW_SV_MIN, MAX, TRIM, REV)
8) Safety items:
   a) crash check triggers with 30deg lean angle error (for 2 sec) even if pilot's throttle is non-zero
   b) modified pre-arm checks to ensure good quality GPS and compas data
   c) lost copter alarm (hold both sticks down and right)
   d) motor interlock & emergency motor stop features on auxiliary switches (ch7 ~ ch12)
   e) RTL_CLIMB_MIN parameter allows forcing vehicle to always climb a few meters at beginning of RTL
   f) LED flashes green quickly if disarmed with 3D lock and SBAS

Thanks to Marco and all the beta testers who risked their vehicles so we could iron out issues and ensure a more reliable firmware for the wider community. Here are some of their videos:

ChrisN #1, #2, Paul Atkin #1, #2, #3, Gervais #1, #2, #3, Gleb Falaleev #1, #2, Pomaroli, Michael, Robert Baumgartner, De Le, Robert Baumgartner, Robert Navoni, Maciej Karpinski

After months of testing by the beta-testing team, Copter-3.3 is ready for wider use.  Similar to the Copter-3.2 release this is a "soft launch" meaning that for the next couple of weeks, we are asking users to load the new version using the Mission Planner's "Beta firmwares" link on the Install page.  The MP will pop-up a "use at your own risk" message but rest assured, this firmware has been very thoroughly tested.

We also recommend that you use the Beta Mission planner until Copter-3.3 becomes the default (in about 2 weeks).  Open the Mission Planner and select Config/Tuning >> Planner and click the Beta Firmware checkbox.  Then Help >> "Check for Beta Updates".  The download and install will take a few minutes.

Unfortunately this version and all future versions of Copter only work with fast CPU boards like the 3DR Pixhawk (and compatible) boards, VRBrain, NAVIO+, etc.  Slower CPU boards will continue to be able to load the Copter-3.2.1 release.

Issues should be reported in the APM Forum.
The wiki has been mostly updated but if you spot missing items please report them to the wiki issues list.

The full set of changes can be seen in the Release Notes but the highlights are below.

Known Issues/Warnings:

• users will need to re-calibrate their accelerometers because of 5c (accelerometer range increase).
• FrSky telemetry users must set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions
• this version corrects a long standing issue in the HDOP reporting so values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.

Changes vs Copter-3.2.1
1) EKF replaces DCM/InertialNav for attitude and position estimation which provides more feedback and robustness in case of sensors failures
2) Control improvements:
   a) battery voltage compensation should maintain control as voltage drops
   b) current limiting can be used to reduce the maximum current requested to reduce strain on battery and ESCs
   c) air pressure compensation should reduce need for re-tuning when flying at different altitudes
   d) improved throttle curve should reduce wobbles during descents
3) AutoTune for yaw
4) Cameras & Gimbal improvements:
  a) SToRM32 gimbal support
  b) do-mount-control mission command allows controlling absolute camera mount angle during missions
5) Vibration resistance:
  a) real-time reporting of vibration levels by clicking on Vibe field on HUD (also recorded to logs)
  b) noise weighted average of accelerometers used to weight IMU towards the one exposed to less vibration
  c) accelerometer range increased from 8G to 16G to allow use in higher vibration environments (i.e. reduced "clipping")
6) Other:
  a) improved landing on slopes
  b) retractable landing gear support
  c) channels 9 ~ 12 can be used as auxiliary switches (like ch7, 8)
  d) PX4flow (optical flow) support in Loiter
  e) Brake flight mode (stops vehicle quickly but requires GPS)
  f) allow GPS, Telemetry, SToRM32 gimbal to be connected to any telemetry/serial port
  g) Lidar-Lite V2 support
  h) bug fix to RCMAP - remapped channel's MIN, MAX were taken from incorrect parameters meaning all channel ranges had to be the same
7) Tricopter tail servo parameters (MOT_YAW_SV_MIN, MAX, TRIM, REV)
8) Safety items:
  a) crash check triggers with 30deg lean angle error (for 2 sec) even if pilot's throttle is non-zero
  b) modified pre-arm checks to ensure good quality GPS and compas data
  c) lost copter alarm (hold both sticks down and right)
  d) motor interlock & emergency motor stop features on auxiliary switches (ch7 ~ ch12)
  e) RTL_CLIMB_MIN parameter allows forcing vehicle to always climb a few meters at beginning of RTL
  f) LED flashes green quickly if disarmed with 3D lock and SBAS

Special thanks to Marco and all the beta testers who put their vehicles at risk so we could iron out the problems during the testing phase and ensure a more reliable firmware for the wider community.  Here are some of their videos:

ChrisN #1, #2, Paul Atkin #1, #2, #3, Gervais #1, #2, #3, Gleb Falaleev #1, #2, Pomaroli, Michael, Robert Baumgartner, De Le, Robert Baumgartner, Robert Navoni, Maciej Karpinski

Click here to skip the commentary and just see the vehicle flying.

The video above shows my first attempt (which was successful) to fly APM:Copter using a Linux board (the NAVIO+ shield + RaspberryPi2 from emlid.com).  Ardupilot and APM:Copter have flown before on Linux computers (Tridge flew ArduPlane Aug 2014, and Victor Mayoral first flew APM:Copter using an Erle-Brain board) but it was a first for me and is still fairly rare.

Compared to the Pixhawk the NAVIO+/RPi2 has enormous amount of CPU power (quad core 900Mhz) meaning it should be good for vision applications like red balloon popping, visual follow-me, precision landing and maybe wifi broadcast for real-time video all without the need for an extra companion computer.  We also hope the extra CPU will allow 4kHz sampling of the IMU which will nearly eliminate aliasing and the need for vibration isolation (we currently sample at 1kHz).

We don't yet take advantage of that extra computing power within ardupilot though so it flies much like an APM2 or Pixhawk with all the same flight modes and most of the same features.  A few things are not supported yet including the safety switch, external LEDs, buzzer and Optical Flow.

The setup for the board is more difficult than the Pixhawk, in particular upgrading to the latest version of APM:Copter involves logging into the RPi2 and then downloading and installing a package.  Alternatively you can download the firmware directly from the ardupilot github repo and compile it right on the board.  The emlid site has good documentation on this procedure.

During the setup I had some specific problems:

• I did not use an external compass and the internal compass's offsets were huge (1000 on Y axis!) which required disabling the compass arming check.  Surprisingly though the IRIS flew fine even in Loiter and Auto modes.
• The RC receiver is not powered from the NAVIO+ board meaning a BEC must be used (or I hacked an I2C cable and connected it to the servo rail) which is inconvenient for bench testing.  I hope in future versions of the board this is changed.
• The two-board sandwich is taller than an APM2 or Pixhawk which meant I had to bend some pins to make it fit within the IRIS case (see pic below).  Perhaps a future version could include right angle headers.

On the software side there's still some work we need to do to improve the Linux experience so if there are developers out there who would like to help us with this, please contact the dev team on gitter or on drones-discuss@googlegroups.com.  Linux is the future and we've got a lot of fun work to do!

Note: in the video I incorrectly say SBUS isn't support but it is supported!

For some tasks (like Search and Rescue and mapping) what you can do with one vehicle, you can probably do faster with multiple vehicles.  To test how well it works in practice I tested controlling three Pixhawk powered IRISs at the same time from the Mission Planner using an Antenna Tracker and six 3DR radios (jump here to skip the intro).  A transmitter was attached but I didn't use it.

This test was done with APM:Copter 3.3-rc3 (AC3.2.1 should also work), Antenna Tracker 0.7 (ver 0.6 will work but only for two vehicles), and the latest Mission Planner.

The setup was:

• Each vehicle had a 3DR radio which was paired to a 3DR radio on the antenna tracker.  Before the test I connected to each 3DR radio individually once and set their NetIDs to be "23" for the first IRIS and 1st 3DR radio on the tracker, "24" for the second pair, "25" for the 3rd pair.
• The 3DR radios on the tracker were plugged into the Tracker Pixhawk's Telem1, Telem2 and Serial 4/5 ports.
• Changed the Tracker Pixhawk's SERIAL4_PROTOCOL to "1" to redefine the Serial 4/5 port as a MAVLink channel (this is the new piece that's not available in Tracker 0.6 but will be released very soon).
• Connected the Tracker to my Windows PC using a USB cable

To control the vehicles, I:

• plugged in all three vehicles, started MissionPlanner and connected to the tracker and voila!  All four vehicles (tracker + 3 IRISs) appeared on the map.
• switched between vehicles using the MP's hidden "Ctrl-X" keystroke.  When you switch, the map re-centers on the new vehicle and the HUD, action tabs, etc all show information or allow control of that vehicle.
• The MP's dataflash screen's Action tab can be used to arm the vehicles, and right-mouse-button-clicking on the map and selecting "Take-off" allowed me to get the vehicles into the air without touching the RC transmitter.
• Used the action tab to change each vehicle into "AUTO" mode.  I could have done other things like drag them around individually in Guided mode too.

Of course, there were some issues (I ran the test 3 times, the video is from the 2nd time).  The biggest problem was that there was too much network traffic clogging up the 3DR radio links so sometimes the vehicle wouldn't respond quickly to the actions sent from the mission planner.  So in my first test it was hard to arm and take-off before the vehicle auto-disarmed.  We think the issue is that I didn't reduce the data rate and the antenna tracker combines all mavlink streams and then resends them out on all channels.  This means a lot of bandwidth is being wasted sending, for example, copter's #1's position to copter #2.  We probably want some vehicle information (like position) sent to all vehicles but other data (like IMU readings) isn't useful.

Another small issue was the Mission Planner would not let me send new commands until the last command was accepted/rejected by the vehicle.  Makes sense in a single vehicle environment, but at times I wanted to submit a command to each vehicle in rapid succession without waiting for the first vehicle's response.

If I was going to do this often, I would change the setup so that there was a single TX/RX for each vehicle to allow faster manual take-over of a single vehicle.  I could of course bring all three vehicles down by switching to stabilize and cutting the throttle, or I could switch a single vehicle to Loiter through the MP and then take-over with the RC but that's all a little clunky in an emergency situation.

I might also use RFD900 radios (or re-flash the 3DR radios with the RFD900 firmware) which would remove the need for the antenna tracker completely because it support multi-point communication.

So some more work to do including getting other GCSs like Droid Planner to handle multiple vehicles as well as the MP but still, I was pretty happy that it worked and I wanted others to know that this multi-vehicle style flying is possible.

Warning: there was a period of about 12 hours after this blog was first posted where an older version (AC3.1.2) replaced AC3.2.1 for APM2.  If you think you may have downloaded for the APM2 during these initial period, please check the version on your board by looking at the title bar of the Mission Planner (see the 5th comment from me below for a screenshot)

ArduCopter 3.2.1 has completed beta testing and has been released as the official version available through the mission planner and other ground stations.  If upgrading from AC3.2 there should be no need to re-do any configuration.

Changes from AC3.2 are listed below and in the ReleaseNotes:
1) Enhancements:
    a) reduced twitch when passing Spline waypoints
    b) Faster disarm after landing in Auto, Land, RTL
    c) Pixhawk LED turns green before arming only after GPS HDOP falls below 2.3 (only in flight modes requiring GPS)
2) Safety Features:
    a) Add desired descent rate check to reduce chance of false-positive on landing check
    b) improved MPU6k health monitoring and re-configuration in case of in-flight failure
    c) Rally point distance check reduced to 300m (reduces chance of RTL to far away forgotten Rally point)
    d) auto-disarm if vehicle is landed for 15seconds even in Auto, Guided, RTL, Circle
    e) fence breach while vehicle is landed causes vehicle to disarm (previously did RTL)
3) Bug Fixes:
    a) Check flight mode even when arming from GCS (previously it was possible to arm in RTL mode if arming was initiated from GCS)
    b) Send vehicle target destination in RTL, Guided (allows GCS to show where vehicle is flying to in these modes)
    c) PosHold wind compensation fix
    d) prevent infinite loop with do-jump commands pointing at each other
    e) pixhawk memory corruption fix when connecting via USB
    f) vehicle stops at fence's alt limit in Loiter, AltHold, PosHold (as it did in AC3.1.5)
    g) protect against multiple arming messages from GCS causing gyro calibratoin failure

Thanks very much to Marco and our beta testers who put their copters at risk over the past several weeks to help us iron out these issues.  Also Thanks to Raph for the video (this is actually a video from AC3.2).

We seem to have a lot of natural disasters here in Japan (eruptions, mud slides, earthquakes) and like everywhere else we are counting on UAVs to help out in these situations by producing 3D maps to improve "situational awareness" so that rescue efforts can be used effectively and eventually to actually find people.

The video above (and below) are some more steps towards this by EnRoute (3DR retailer in Japan) and Tohoku University that I work with on Search & Rescue projects.  Some of the important bits:

• Test Site was Sakura-jima in Kyushu, Japan.  It's an active volcano but shouldn't be confused with On-take that claimed 57 lives a couple of months ago.
• EnRoute QC 730 quadcopter which uses 340KV motors and massive 6-cell Lipo to achieve over 40min of flight time under normal conditions
• ArduCopter 3.2 on Pixhawk
• Mapping mission took 20min, the copter traveled a total of 8km including a 1.2km climb at 10m/s.  The battery was at 56% after the mission was complete.
• X-Link video system (1.2Ghz)
• 2.4Ghz telemetry system based on ZigBee with very high gain antenna but no antenna tracker.  You can see the telemetry connection remained pretty solid the entire time which was a major improvement over previous tests.  Japan has strict regulations which don't allow the use of the RFD900.
• The camera was a GoPro Hero3+ Black Edition
• The 3d reconstructions software was Agisoft Photoscan which does a good job of stitching together the images even when there's a large change in altitude.

My hope is that over the next year or so we get to the point where we can:

• Include a companion computer with a modified version of Tridge's Outback challenge software to automatically recognize people or objects that stand-out from the background.
• Send groups of vehicles (probably mostly copters) to cover more area in the same amount of time without adding anymore people to the flight crew.
• Incorporate IR cameras for night-time flights because rescue efforts currently seem once it gets dark leaving people stranded on the mountain until morning.
• Get the vehicles travelling closer to the face of the mountain using LIDAR sensors and Terrain Following.
• Find people by narrowing in on their cell phone signals (?)

Thanks to EnRoute and Tohoku University for including ArduCopter and the APM/Pixhawk in their S&R efforts.

ArduCopter 3.2 (aka APM:Copter) has been released as the default version replacing AC3.1.5. This is the exact same version that we invited all users to test two weeks ago.  Users who wish continue using AC3.1.5 can find it under the "Pick previous firmware" version on the MP's Install Firmware screen.

The full list of changes can be found in the ReleaseNotes but here are the highlights:
Flight Mode Enhancements:

• PosHold flight mode: similar to Loiter but with direct response to pilot input during repositioning
• ACRO mode handling improvement EXPO (for faster rotations)
• Drift mode uses "throttle assist" (similar to AltHold)
• Smoother transitions between flight modes (i..e when entering Loiter or RTL from high speeds)

Mission Enhancements/Fixes:

• Spline waypoints
• Do_Jump, Conditional_Distance, Conditional_Delay fixed
• Do_Set_ROI persistent across waypoints
• Condition_Yaw accepts relative heading (i.e. current heading + 20)
• Reset horizontal position target when taking off in AUTO to avoid lean due to GPS position drift
• Rally points (Pixhawk only)

New Sensors/Devices:

• Lidar-Lite Range Finder, SF02, MaxBotix I2C sonar and Analog sonar (which was missing for Pixhawk)
• EPM Gripper

Safety Features:

• EKF/DCM check will switch to LAND mode if heading error > 60deg for 1 second
• Baro glitch detection
• Pre-arm check for Gyro calibration success
• Pre-arm check that internal & external sensors (gyros, accels and compass) are consistent (Pixhawk only)
• Parachute support (Pixhawk only)
• Feedback to Pilot when taking off in AltHold, Loiter, PosHold (i.e. motors spin up a little as throttle is raised)
• EKF (new attitude and position estimate system only used for reference in this release)

Bug Fixes:

• Pixhawk GPS driver buffer overflow that could lead to missed GPS messages
• Pixhawk I2C bug that could lead freeze up if I2C bus is noisy

Known issues/Warnings:

• Pixhawk users will need to recalibrate their compasses
• PosHold won't show up as option on FlightMode screen if you have an old version of mission planner. Please select Help > Check for Updates.
• Landing detector is more strict meaning it may take longer to disarm after RTL, AUTO.
• Set THR_MID parameter especially if you have a very powerful copter because "Feedback to Pilot" raises throttle to 1/2 of THR_MID
• Spline twitches slightly as it passes a waypoint especially if WPNAV_SPEED is set > 500.
• Dropped support for NMEA and SIRF GPS on APM boards (ran out of Flash space)
• Dropped support for sonar for MultiCopters on APM1 and TradHeli on APM1 & APM2 (ran out of Flash space)

If you hit issues, please post them in the APM Forum and include a dataflash log file if possible.

Special thanks to Marco and the Beta Testing team from the AC3.2 beta testing thread who put their copters at risk in the pursuit of a smooth, safe release. Here are links to some of their videos: Marco's DJIs900, Holger's Water Tower, Josh's Acro, Ray's TradHeli2&FPV, Raph's Hawaii, PhillS's CommandYaw, Thor's Zombie Run&FollowMe, Phanivyas's Test, Rob's TradHeli, Christian's Test1&Test2, Balloon's Spline, JimJ's FPV, Ultrojo's ROI & Spline&FollowMe1&FollowMe2, Troy's Mission

Thanks also to the code contributors to this release including Tridge, Jonathan, Leonard, RobL, Paul Riseborough, MichaelO, Julien Dubois, David Dewey, Andrew Chapman, Emile, Allyson and many more. If you want to get involved check-out our dev wiki.

After months of testing, ArduCopter 3.2 (aka APM:Copter) is ready for widespread use and we invite all users to give it a try.  In order to manage the support load at first it will be available only through the Mission Planner and APM Planner2's Beta Firmwares link.  This link is visible from the regular "Install Firmware" page if you check the "Advanced View" on the Config/Tuning >> Planner page.  On APM Planner2 the "Advanced View" it is under the File menu.

In about two weeks we plan to replace AC3.1.5 with AC3.2 as the default version dispensed by the ground stations.

The full list of changes can be found in the ReleaseNotes but here are the highlights:
Flight Mode Enhancements:

• PosHold flight mode: similar to Loiter but with direct response to pilot input during repositioning
• ACRO mode handling improvement EXPO (for faster rotations)
• Drift mode uses "throttle assist" (similar to AltHold)
• Smoother transitions between flight modes (i..e when entering Loiter or RTL from high speeds)

Mission Enhancements/Fixes:

• Spline waypoints
• Do_Jump, Conditional_Distance, Conditional_Delay fixed
• Do_Set_ROI persistent across waypoints
• Condition_Yaw accepts relative heading (i.e. current heading + 20)
• Reset horizontal position target when taking off in AUTO to avoid lean due to GPS position drift
• Rally points (Pixhawk only)

New Sensors/Devices:

• Lidar-Lite Range Finder, SF02, MaxBotix I2C sonar and Analog sonar (which was missing for Pixhawk)
• EPM Gripper

Safety Features:

• EKF/DCM check will switch to LAND mode if heading error > 60deg for 1 second
• Baro glitch detection
• Pre-arm check for Gyro calibration success
• Pre-arm check that internal & external sensors (gyros, accels and compass) are consistent (Pixhawk only)
• Parachute support (Pixhawk only)
• Feedback to Pilot when taking off in AltHold, Loiter, PosHold (i.e. motors spin up a little as throttle is raised)
• EKF (new attitude and position estimate system only used for reference in this release)

Bug Fixes:

• Pixhawk GPS driver buffer overflow that could lead to missed GPS messages
• Pixhawk I2C bug that could lead freeze up if I2C bus is noisy

Known issues/Warnings:

• Pixhawk users will need to recalibrate their compasses
• PosHold won't show up as option on FlightMode screen if you have an old version of mission planner.  Please select Help > Check for Updates
• Landing detector is more strict meaning it may take longer to disarm after RTL, AUTO
• Set THR_MID parameter especially if you have a very powerful copter because "Feedback to Pilot" raises throttle to 1/2 of THR_MID
• Spline twitches slightly as it passes a waypoint especially if WPNAV_SPEED is set > 500.
• Dropped support for NMEA and SIRF GPS on APM boards (ran out of Flash space)
• Dropped ssupport for sonar for MultiCopters on APM1 and TradHeli on APM1 & APM2 (ran out of Flash space)

If you hit issues, please post them in the APM Forum and include a dataflash log file if possible.

Special thanks the Marco and the Beta Testing team from the AC3.2 beta testing thread who put their copters at risk in the pursuit of a smooth, safe release.  Here are links to some of their videos: Marco's DJIs900, Holger's Water Tower, Josh's Acro, Ray's TradHeli2&FPV, Raph's Hawaii, PhillS's CommandYaw,  Thor's Zombie Run&FollowMe, Phanivyas's Test, Rob's TradHeli, Christian's Test1&Test2, Balloon's Spline, JimJ's FPV, Ultrojo's ROI & Spline&FollowMe1&FollowMe2, Troy's Mission

Thanks also to the code contributors to this release including Tridge, Jonathan, Leonard, RobL, Paul Riseborough, MichaelO, Julien Dubois, David Dewey, Andrew Chapman, Emile, Allyson and many more.  If you want to get involved check-out our dev wiki.

As many probably know, this year's Sparkfun Autonomous Vehicle Competition (AVC) is similar to last year's except that a new challenge has been added in which we can gain extra points by finding and popping 1m red balloons.  It's pretty difficult to do (see failed attempts #1, #2, #3) but as you can see from the video above it's finally getting the balloons.

The setup is detailed on this page on the developer wiki (scroll down to the Red Balloon in the Example Projects section) but in any case, it uses a Pixhawk running a modified version of AC3.2 (code here, AC3.2 testing thread here).  The Pixhawk has all the regular ArduCopter functionality but in addition it accepts commands from an external navigation computer, an Odroid U3 when it is in the Guided flight mode, or in AUTO and running a newly created MAVLink NAV_GUIDED mission command.  This NAV_GUIDED command takes some special arguments like a timeout (in seconds), a min and max altitude, and a maximum distance and if the Odroid takes too long to find the balloon, or gives crazy commands that cause the copter to fly away, the Pixhawk retakes control.

So while the Odroid is in control, it first requests the pixhawk to rotate the copter slowly around while it pulls images from the Logitech C920 web cam and uses OpenCV to search for blobs of red in the images.  During the search it keeps track of the largest red blob it saw so after the copter has rotate 360 degrees it sends commands to point the vehicle in the direction of that blob and then sends 3D velocity requests 5 times per second to guide the copter towards the top of the balloon. Leonard Hall helped me greatly in improving the control algorithm both for the new velocity controller that was added to ArduCopter and also with the strategy the Odroid should use to best get to the balloon..

All of the communication between Pixhawk and Odroid uses Kevin Hester's Drone API and Tridge's MavProxy.  It's relatively easy to use and allowed me to write all the code in Python.  That code is all here.

A couple of extra things that came out of this was I managed to use Python's MultiProcessing to allow the image capture and image processing to run in separate processes (so they run in parallel).  It seems that unless images are pulled from the camera at 15 ~ 30hz, they become extremely laggy.  In one test I measured a 1.3 second lag in the images from the camera!  With MultiProcessing that's down to less than 0.2 seconds and there are 2 more cores still free on the Odroid so there's room for more sophisticated work to be done!

For testing, at Tridge's suggestion, I set-up a balloon simulator that works within SITL.  It used the simulated copter's position and attitude and then created a simulated image of the horizon and the balloon (if it was within the field of view of the simulated camera).  This fake image was then fed into the image recognition python code making it an end-to-end test.  This was all possible because both the Odroid and our Simulator run on Ubuntu.  Having the simulator allowed a lot of bench testing before any real flights happened.

If you want to see a really impressive use of image processing in ArduPlane, check out Michael Darling's video here of one arduplane following another.  Michael's set-up is similar in that he uses the same camera and an external nav computer (a beagle bone black) and OpenCV.  I'm not sure what communication method he used between the BBB and the Pixhawk.

Also I hope that over the next year we will enable more image processing computers to work with ArduCopter (and ArduPlane, ArduRover) and maybe lead to the safe precision landings Jesper Andersen suggested in this blog post.

All feedback welcome!

AC3.1 is going out very soon and includes a new safety feature called GPS glitch detection.  There's a wiki page about it but I'd like to highlight how it works because it's near the top of the list of safety issues.  The method itself comes from Craig who apparently used something similar on undersea robots.  The way it works is:

    Step 0: the very first GPS position received is simply "accepted"

    Step 1: when we receive a new message from the GPS we first calculate a "projected position" based on the previously accepted position and velocity assuming that the copter had just flown straight ahead.

    Step 2: we compare the new position to this projected position and if it's within 2m (configurable with the GPSGLITCH_RADIUS parameter) then we 'accept' the new position and we move back to Step #1 and wait for the next update.

    Step 3: if it's outside 2m then we calculate another circle of acceptability which is an estimate of how far the vehicle could have travelled since that last accepted position.  We assume the vehicle can accelerate at 10m/s/s in any direction (value held in the GPSGLITCH_ACCEL param).  So for example if it's been 1sec since the last accepted position, the radius would be 1/2 * 10m/s/s * 1s * 1s = 5m.  This radius starts out small but grows quickly so after 5sec it's 125m, after 10seconds it's 500m.  If the new position still isn't within this radius then we're officially "glitching".  We throw away the GPS position (so we rely only on the inertial nav estimate), we display "Bad GPS Position" on the Mission Planner's HUD and then go back to Step #1 and hope the next sample is better.

     Now after 5 seconds of not having an acceptable GPS position the GPS Failsafe kicks in and the copter Lands or switches to Alt Hold (user configurable using the FS_GPS_ENABLE parameter).

     If on the other hand the GPS position corrects itself (i.e. comes back within the radius) we instantly reset the inertial nav position to this new GPS position.  This reset is important because it saves the inertial nav filter from getting confused about it's velocity and acceleration due to the jump which would lead to the copter flying wonkily even after the glitch has cleared.

     This doesn't mean that GPS glitches are a thing of the past, we still need to get these two parameters (GPSGLITCH_RADIUS and ACCEL) set so they catch most glitches without causing too many false positives but hopefully it's save some copters and this may grow into better algorithsm.

     By the way, before implementating this glitch detection we tried to use the GPSs HDOP values (the GPS's measure of how accurate it's position is) but we found the number trails the actual glitch by up to 2 seconds so by the time the GPS tells you, things have already gone horribly wrong.

All feedback welcome, you can see the code here and a simulated video here which simulates an actual event reported by Garrick Merrill (gps location changed to protect the innocent).  Here's a video showing how quickly the inertial nav position drifts without the GPS.

As a follow-up to the rover drops #1 and #2 I spent a day with Assistant Professor Nagatani-san of Tohoku university in Japan (and his students) and Izu-san of EnRoute (a company that specialises in Industrial use multicopters and hobby use RC vehicles here in Japan and China) at Karuizawa's Mt Asama attempting to autonomously drop a 2.5kg rover from a large (4kg+) EnRoute "ZionPro" hexacopter.

The flight was completely autonomous including activating the servo release which held the rover to the hexacopter (we used the camera shutter release).  After being released the rover was "lowered" on a 30m wire wound around a brushless motor which was meant to slow it's descent (with mixed results).  If you've never heard of this mechanism before, it seems if you connect the bullet connectors of a brushless motor together it resists being turned.  If you attach a resistor between the bullet connectors it will resist less strongly.  In this way we could somewhat adjust the speed at which the rover descended at.

A couple of things that we learned from this test in case you try something similar:

• the altitude reported by a Ublox GPS (i.e. APM/PX4) vs a hand held GPS can vary by 10m.
• the altitude reported in google maps (and thus the mission planner) can vary by 20m from reality because they only provide the average altitude for the area.  I'm not sure how big that area is but we found that google maps altitudes could be high or low from reality depending upon where you were on the slope.
• trying to drop from a wire is tough!  we need a more reliable system for the next test.  Maybe use a range finder to get the copter closer to the surface without hitting it or perhaps measure the motor output to determine when the dangling rover has reached the ground.
• the hexacopter and battery were more than sufficient to carry the rover the 600m covered in this test.  At least twice that distance would have been possible.
• AC3.0.1 is very capable of the accuracy required for this mission.  It was a thing of beauty.

There will be one more attempt within the next 2 months which should be pretty much the same except the distance will be further and the dropping mechanism will be improved!

Thanks and all comments, input welcome!

Two years after the March 11th tsunami in Japan that triggered the Nuclear disaster at the Fukushima power plant, there are still just over 300 thousand people who have not been able to return to their homes due to high radiation levels.  The government has decided that radiation levels must be below 1 micro sieverts/hour (=5mSv/year, see here for what this means) before children can return to school in the area (adults may return to their home at 1.9micro-sieverts/hour, 10mSv/year) and there is a building-by-building clean-up effort that is going on to try and get the radiation levels down to the required levels.

The radiation levels are being measured from manned helicopters flying at approximately 300m but the issue is that the ground level where people actually live can only be estimated roughly from the air.  To get the more accurate "human level" readings the government is relying on mobile surveying trucks or individuals wearing protective clothing but there has also been some limited use of UAVs.

In particular the very top image was taken at the Yamakiya elementary school (40km from the plant) using the Chiba University's MiniSurveyor hexacopter outfitted with a geiger counter.  The readings were performed twice, once back in August 2012 and then again in December.

What you can see is that over the 4 months that significant portions of the school ground has returned to near natural levels and the part of the ground that was high radiation (2 ~ 3 micro-sieverts/hour) has mostly fallen to 1~2 micro-sieverts/hour.  This area, by the way, is where the top few cm of earth from the school playground was removed and placed in the middle of the ground and covered by a plastic sheet.

During this test an EBA Japan Hyper-spectral camera was also used (although, in fact it was mounted on a manned helicopter mostly because it weighs 2kg and the mini-surveyor was perhaps unable to lift that weight for an extended period).  These sorts of cameras can produce an image broken down into hundreds of bands of bands of light which can be used to determine what surface the radiation has fallen on.  This is important because the level of radiation remaining at a site is greatly determined by the surface.  For example it has been found that different types of trees retain radiation differently.  A cedar will retain 50% of the radiation within it's leaves while an oak will only retain 20% (the rest falls to the ground).

After the clean-up is done, having a UAV capable of travelling over all the various different surfaces and verifying the success of the effort is another good use that's been put forward.

The Mini-surveyor was developed under the guidance of Professor Nonami (who wrote this book).  It costs about about $15k each including a fancy simulator for learning how to use it.  It apparently uses a "physical model" instead of PID controllers for attitude control.  You can see a video of it flying here.

As a follow up to an indoor test we did a about a month ago (blog post here), Assistant Professor Nagatani-san of Tohoku University, Izu-san of EnRoute (a primarily Japan based RC company) and I tested dropping a 2.5kg rover from a 4kg Hexacopter outfitted with an APM2.5 running ArduCopter 2.9.1.  The test was done on the side of a semi-active volcano, Shinmoe which is in Kyushu, Japan.

The flight was all in Loiter mode with the release of the Rover via a servo controlled by the Camera Shutter function attached to channel 7 on the transmitter.  The pilot (me) was positioned right near where the video was shot from.

Basically it worked but there we hit a number of issues:

• AC 2.9.1's Loiter has a 5m radius deadband meaning it moves back to it's original target unless you move more than 5m away (from the target).  This meant that repositioning the copter precisely was quite difficult.
• As it was shot on the side of a Volcano at >1100m elevation, the wind was relatively strong and pushed the copter around at times.
• the release mechanism for the rover was slightly damaged in transport meaning it took multiple attempts to get it to release.

Next time we will try to do it fully autonomously.

We also took the opportunity to fly a separate large Quad outfitted with a 10000mAh battery up for a view of the crater.  The flight took about 12min but it could have flown at least another 5min.  Problems we hit included:

• Like the large rover-carrying-hexa this quad had very large propellers which could be caught by the wind at times meaning  the controller had a lot of work to do to keep it upright at times.
• Arducopter 2.9.1 has a bug in that it proceeds to the next waypoint once it's reached the target lat/lon.  This is fine for mostly horizontal flights but it's serious trouble for a flight like this in which the vertical component takes longer than the horizontal.  The solution was to set the target take-off altitude to 150m and reduce the WP_SPEED to 2m.  We ended up overdoing it so we flew the mission higher and more slowly than necessary.

Still, it did the mission as planned.

All feedback welcome!

For those interested in using their multicopters to carry heavy objects you might be interested in the test that I performed today with Assistant Professor Nagatani-san of Tohoku university in Japan and Izu-san of EnRoute (a company that specialises mostly in Radio Controlled vehicles here in Japan and China).

The goal for later this year is to carry a rover to the top of Mt Asama (a volcano that errupts from time to time) and drop it in mostly as a proof of concept that it can be done.

Today was our first attempt at dropping one of the university's semi-autonomous rovers (2.5kg) from an ArduCopter equipped Zion Pro hexacopter (4.0kg not including the rover).

During the first try the copter was under manual control (stabilize mode) and the servo to drop the rover was activated by the tx/rx's channel 8 switch.  I was the pilot and although we were all fully expecting the copter to climb I was still surprised by the speed of the leap into the air and I couldn't keep the throttle low enough without cutting the engines completely.  You can see the disasterous result 44 seconds in.

After lunch and fixing the hexa the 2nd (1:02) and 3rd tests (1:11) went much better with lower weights (300g and 1kg) and this time using Alt-Hold.

The final test (1:24) was back again with the rover but this time using alt-hold and you can see how much better the new 2.9.1 Alt-Hold is than a human pilot (or at least this human pilot!) with the copter only climbing about 10cm or so.

So the moral of the story is sometimes it's best to trust the autopilot.

I received a 2D laser range finder from the good people at Hokuyo more than 1 year ago.  My plan was to try to use it to improve ArduCopter's altitude hold or collision avoidance but other priorities have taken up my time and it has ended up sitting in it's box all that time occasionally making me feel guilty so I'm giving it away!

It's a fairly expensive sensor I believe (>$1200), beyond what most people are willing to spend for a diy project but universities seem to use them regularly.  Some specifications which can also be found here:

    sensing field of 240 degrees

    range of 6cm ~ 10m with 1cm accuracy

    completes a full scan in 0.1 seconds

    Serial or USB interface

    500mA power consumption

    160g

Ideally I'd like it to go to someone who can do the following:

• build an arducopter library to communicate with the sensor.
• incorporate the sensor's output for altitude hold or object avoidance.  This would likely involve:
  • adding a new throttle or roll-pitch mode to the main code
  • if used for object avoidance, adding a new PID controller to allow setting the response to objects sensed
  • adding a new parameter to enable/disable the object avoidance
• perhaps most importantly you must have the time and desire to see the project through (something that I clearly failed at!).

By the way, this free sensor comes with free advice from me to help you overcome any code problems you face.

So if you're interested in this sensor please email or PM me and if you've got a better idea of how to use it than what I've written above that's also great!

I imagine a few people will want this sensor and I only have one so apologies in advance for those deserving people that I might not choose!

Most of the pro multicopter set-ups have feedback from the ESCs so the controller knows the status of the motors.  This is useful for all kinds of reason including:

    1. debugging the causes of crashes - the controller could log when a motor has stopped running.

    2. allows faster and better reaction to a motor failure perhaps saving you from a crash at least for hexas and octas.

    3. automatic generation of a linear thrust curve which makes life easier for the attitude controllers.

As a first step towards trying to make that functionality available for the hobby/diy market I've managed to hack a hobbyking RedBrick50Amp and load it with a modified SimonK firmware so that it sends back timing information using the SPI bus to an APM2.  This modified SimonK firmware is in my clone in the spi_feedback2 branch and the changes were pretty minor as you can see here.

Here's a picture of the set-up:

Now, it's really a first step, there are a few issues:

    - It only works on the RedBrick50Amp because that's one of the few ESCs that is not using the SPI bus's slave select pin to control one of the FETs also you can see I needed to do some careful soldering to attach a pin directly onto the Atmega8.  To make it available to all we'd need specially manufactured ESCs.

    - Using the SPI bus would mean a lot of wires to the APM2.  5 wires from each ESC (mosi, miso, reset, slave select, clock) and 4 wires + 1 wire per esc on the APM2 side.  I might look into trying to use I2C instead which would be just 2 wires per ESC.

    - the feedback is the timing (in nanoseconds?) from when the ESC last switched the polarity of power to one of the wires.  So the feedback is non-linear..you get very accurate feedback when it's moving slowly, but lose accuracy as it gets to the high end of it's range.

Still, a step in the right direction I think.  All feedback and advice welcome!