ArduCopter 3.0 is ready for widespread use.  To make the transition easier, this time we are asking people to voluntarily upgrade from 2.9.1b for the next month or so before we make 3.0 the default firmware downloaded by the mission planner.  The new version can be found in the Mission Planner's Beta firmware's link,, GitHub and the new Downloads Area.

Warning #1: A bug was found in the FENCE in which if you lost GPS it could lean at extreme angles as it tried to maintain an invalid position.  This is fixed in AC3.0.1-rc1.

Warning #2: This release has not been fully tested on Traditional Helicopters

Warning #3: GPS glitches can cause sudden and aggressive position changes while in loiter mode.  You may wish to reduce the WPNAV_ACCEL to 100 and Loiter PID to 0.2 (from 1.0) to reduce aggressiveness.

Improvements over 2.9.1b include:

  • Inertial Navigation for Loiter and Auto meaning much more accurate control (Randy,Leonard,JonathanC)
  • 3D navigation controller follows straight lines in all dimensions between waypoints (Leonard,Randy)

         WPNAV_SPEED, WPNAV_SPEED_UP, WPNAV_SPEED_DN, WPNAV_ACCEL allows configuring speeds and acceleration during missions

  • "compassmot" to compensate for interference on compass from the pdb, motors, ESCs and battery.  (Randy,JonathanC) (Set-up video here)
  • Safety improvements:
    • simple Tin Can shaped Geo Fence
    • pre-arm checks to ensure all calibration has been performed before arming (can be disabled by setting ARMING_CHECK to zero).  (video description here)
    • GPS failsafe - switches to LAND if GPS is lost for 5 seconds
    • stability patch improvements to stop rapid climbs in very overpowered or overtuned copters
  • Circle mode improvements including "panorama" when CIRCLE_RADIUS set to zero (Randy,Leonard)
  • SONAR_GAIN parameter added to allow better tuning of sonar surface tracking
  • CH8 auxiliary switch (same features as CH7)
  • works on PX4 (some minor features still not available) (Tridge,PatH)

How to upgrade:

1. Make sure you are using Mission Planner 1.2.59 or newer.

2. Click on the MissionPlanner's Firmware screen and click the "Beta Firmwares" link on the bottom right.  The version numbers should update to "ArduCopter-3.0.1rc2", then click the appropriate frame icon and it should upgrade as per usual.

3. Reduce the Loiter and Alt Hold PIDs if you have modified them from the defaults.  The modified PID values for the 3dr frame can be seen in the image below.

Note: Nav parameters have been combined with Loiter so do not be concerned if you can't find them.

4. If you purchased an APM prior to March of 2013, update your PPM encoder to the latest firmware.

5. Try out the new version in stabilize mode first, then alt-hold, then loiter and finally RTL and Auto.

Special Thanks to MarcoDaveC and the rest of the beta testers for putting their copters at risk during the extended testing period.  Some of their videos can be found hereherehereherehere and here.  Thanks also to MichaelO for the MP changes required for this release.

All feedback welcome.  Please put your questions, comments (good and bad!) below.  

Added by Craig:

Please watch Randy's videos on setting up and flying APM-Copter 3.0 before you go flying.  They are excellent!

3DR Quad Set-Up Suggestions
AC 3.0 "Live" Compass Calibration
AC 3.0 CompassMot Setup      
AC 3.0 Pre-Arm Checks            
AC 3.0 Fence                               
AC 3.0 Maiden Flight Checks   

Views: 134270

Reply to This

Replies to This Discussion


     Sorry about your crash.

     Craig and I have had a look at your logs and we can see RTL was initiated by a transmitter/receiver failsafe.

     Re the crash, we strongly suspect the GPS position was very inaccurate when you first started the flight.  The NumSats was only 5 and the hdop value was 3.1 (good values are around or under 1.6).  The gps position improves over the flight and reaches 8 sats and 1.53 but because the home position was captured when the position was very bad (i.e. when you armed) this meant the copter was trying to return to a position that was probably quite far from your real starting position.

     We could verify this if you could provide the tlogs from the flight.  It looks like the one above is a very short connection where the copter is never armed.

     Can I ask, how long did you wait after connecting the battery and after you saw that you'd received a 3d lock?

     A few things that would help avoid this situation:

          1. if you have telemetry ensure that the position of your copter on the ground station map matches it's actual position

          2. check the num sats or more importantly hdop values in the mission planner's FlightData Quick screen to ensure a good position (we can make these display by default)

          3. reduce the Loiter PID P and WP_Accel as mentioned in the top of this discussion (we will change the defaults before we release 3.0.1)

Ryan I just watched the video again.  Did you arm between a bunch of trees where you did not have a clear view of the sky?  The tlog you included was not from this flight so we can't analyze it.  I'm sure it would show a bad position right from the start of the flight.  BTW, you don't need to include the raw log (rlog) file.  We don't use it for flight analysis.

Oliver, John,

My mot log looks similar and I am sure COG is fine. So I had a second look at the log and think what we see is a difference in CW and CCW motor directions, If your quad is also configured X Mot 1 and 2 are the pusher props and are diagonal to each other. Is it possible that some of the props provide different thrust for ccw and cw? (

How are your ESCs set up. SimonK and all 4 in one direction (reversing by swapping motor wires) or SimonK Norm/Rev firmware flashed (does the reversing by software)?


Your tlog worked fine for me.

Regarding my today's crash, it sounds like RelAlt variable get crazy, what's the meaning of this value compared to baro alt ? It is suppose to be similar ?

Thanks for your help !

Hi Pierre i suspect a PID problem, in the log your rate P is set at 0.07. This is quite low.

I've seen that you were using channel 6 to adjust PID settings. What is your failsafe value for channel 6 ?

And more globally what are your failsafe values for each channel ?

Before the crash did you change the PID settings through CH6 ?

It could be a hardware problem too, battery low, motor or connectors problem. Unfortunately you do not have battery monitoring.

You don't have throttle failsafe enable as well. Because of that we do not have a radio failsafe reporting.

Could you give your frame / motors / battery / ESC / propellers / connectors details ?

As a side note, you did get a lot of GPS loss at the beginning of the flight. I suppose that you had some obstacle around.

You could read this Wiki page about the GPS so that you will be able to prevent some risks when flying in Loiter or auto mode specially at low altitudes.

Without APM failsafe, the log reporting is less accurate. We cannot differentiate easily between a user initiated RTL and a RTL initiated by the receiver failsafe.

There are other disadvantages reported by Bill and Randy.

The thottle failsafe is the recommended method, because it will leave the APM decide about the right strategy depending about the flight conditions and will let the APM manage the recovery action.

So using the throttle failsafe is the best and simpler way to get the right APM answer to a system anomaly. The APM will take care of the other failsafe status before taking a recovery decision (GPS, GCS, Battery). And those strategies will certainly be enhanced with new recovery modes. For example we could add a parachute output with a wrong attitude detection, or an auto auto-rotation mode for helicopters.

Thank you Randy. I read the page you linked to and I got confused a bit. The APM failsafe is lot more complicated than I thought. There are so many things going on there. I will need some time to digest all of them. But I liked all the options that are available as opposed to only one simple action the Tx failsafe provides.

One conclusion I got (please correct me if I am wrong): If I want to use APM failsafe, then Tx failsafe MUST be disabled otherwise APM will never get a chance to perform its own failsafe because Tx/Rx failsafe command will kind of override APM's. Am I correct on this?

I wait until the blue light on the gps blinks and the little GPS symbol on the OSD shows up before i fly.  Im pretty sure this log is for the flight.  It was the last one on the log list and the last GPS cord's are pretty close to where it crashed.  Didn't do anything different than normal.  Never had a problem with the RTL until i updated to the newere firmware virsion.  I usually use the RTL to bring it back and land it while i pack up my FPV stuff.  RTL would also kick in almost every flight when i was using a normal DSM receiver because i always flew to far away.  This was the second flight with the dragon Link system.  not sure why it lost signal. 


Just by one tree.  Have a clear view of the sky.  Waited for teh blue light and the GPS symbol on teh osd.  Those were the last logs on teh apm and the gps cords match where it crashed.

I just installed 3.0.1rc1 over 3.0rc6 on a 6kg octo and am trying to get rid of the infamous TBE. It must be a declination issue so I'm going to tune that with ch6 but in the mean time I noticed in the magnetometer section the log calibration so I tried that using the previous flight flog. Just some hovering and small circles overhead. What I got was -35, 49, -95. Is that within range? I've never had any magnetometer interference with this that I know of because the APM is pretty far from the PDB.

Also should I still do the Live Calibration or does one overwrite the other?

Is there an rc2 around the corner?

The copter never arms in the tlog you sent.  It is not the log file for the flight.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service