ArduCopter 3.0.1 has been released and is now available in the Mission Planner,, GitHub and the new Downloads Area.

Warning #1: Compass calibration and reducing interference is far more important than with 2.9.1b

Warning #2: GPS glitches can cause sudden and aggressive position changes while in loiter mode.  You may wish to reduce the Loiter PID P to 0.5 (from 1.0) to reduce aggressiveness (see image below of where this gain can be found in mission planner).

Warning #3: optical flow is not supported but will be back in the next release (AC-3.0.2 or AC-3.1.0).

Warning #4: loiter turns does not maintain altitude.  This bug will be fixed in AC-3.0.2.

Warning #5: This release has only been lightly tested on Traditional Helicopters.

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 (get it here)

2. Click on the MissionPlanner's Hardware, Install Firmware screen.  The version numbers should appear as "ArduCopter-3.0.1", 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. Although not directly related to this release, if you purchased an APM prior to March of 2013, update your PPM encoder to the latest firmware (instructions here).

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

Numerous How-To videos are available:

Special Thanks to MarcoDaveC and the large number of testers on the pre-release thread who put 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.

Views: 385479

Reply to This

Replies to This Discussion

I have autotuned (3.1RC5) 2 different hexas now, about 6 times in total, and the Rate Roll/Pitch P and I values always come out as the same number. Is autotune supposed to do that? The flight characteristicts are very tight (a little twitchy) so I have not said anything at this point because you can not argue with the results, but it seems odd that P and I become the same number. Once, all 4 (rool and pitch P and I) were all the same... Or does this just mean my battery is centered perfectly? ;)

Yes P and I are supposed to be the same after autotune. I should put this in the wiki.

You can increase I further if you like but I=P should be the minimum.

If you find it too twichy you can reduce Stab P. The autotuned values should give close to the best Rate P and D terms but Stab P should be regarded as the maximum and Rate I the minimum. You can adjust them to suit your flying taste.

Yeh block up clean section and do the tune again. I will look over your logs tonight.

Thanks for testing this!


I am a bit confused here. Autotune (as per Wiki) tunes to adjust the Stabilize_P and Rate_P and RATE_D terms.

What about the RATE_I term? Should we set this ourselves? I am asking this because after my previous autotune my RATE_I was 0. Could you shed some light ;)?


 autotune should set Rate I as well. I guess, from what leonardthall just said, you can set the I term to the same value as the P term, but you should probably just run the autotune again.

Hi Randy,

I checked the above procedure. APM goes into LAND mode on the bench. However I had quite some moment today. I hit the range limit on my 2.4 Ghz flying fpv. It started tumbling as if all controls were thrown at their full deflection yaw rotatate pitch roll tumbling) for about 2-3 seconds before going to RTL. Locking at the log I can confirm that pitch_in, roll_in, and yaw_in went to their extreme low value. before RTL was initiated. I did a bench test again and just by switching off the tx all channel data including throttle is are set to 900 right after switch off (my receiver is cutting the ppm stream upon link loss). Looking at the wiki failsafe diagramm this shouldn't be the case as roll/pitch/yaw should be at 1500 with only throttle set to the low failsafe value.

I hop you can see my point. What am I doing wrong? And why does it obviously take 2-4 seconds between link loss and initiating RTL?



Ok, so the good news is that it switch to RTL eventually.  The 2 second delay is the designed delay between when the ppmsum stream stops arriving and when the AC decides it's time to initiate an RTL.

The channels moving to minimum sounds like a ppmencoder problem and so I wonder if you've got an out-of-date ppmencoder on that APM.  There are instructions here on how to update it.

I'm afraid that setting the receiver failsafe so it cuts the ppm stream doesn't work particularly well with the APM2.  The problem is that the ppmencoder normally (ie. if you're using the most up-to-date value) overrides the missing values with numbers around 1500 except for throttle which goes to 900.

By the way, AC3.1-rc5 (available through the mission planner's firmware, beta Firmwares link) has some improvements in the failsafe handling in particular it ignores flight mode changes and switch movement changes if they happen during the failsafe.  This probably wouldn't have helped in your case.

Thank you Randy.

I found the 2000ms delay in radio.pde. Why doesn't it continue to check for the throttle pwm being less than the f/s value even when valid_channels is 0? With this check while waiting for the timeout it would have switched to RTL after 3 cycles as it would do with PWM f/s set.

The board is a genuine 3DR board bought a few weeks ago. Shouldn't it have tje latest PPM encoder?

Btw: This is the sequence of events

8730 Roll/Yaw/Pitch_in go to their min values (900)

8878 Err 2,2 (Radio late frame)

8879 Mode RTL

8880 Err 5,1 (failsafe occured)

How do I calculate the time between lines, e.g. 8730 to 8878?

Thanks for your help


Hi Randy .. I have been sitting back reading and learning with all the emails I get everyday of the chit chat on this forum page.. I notice you say in the above   I quote " 3.1 rc5 it ignores flight mode changes and switch movement changes if they happen during the failsafe"  This concerns me as, if we have a situation where the machine decides it is going to come home due to fence RTL or other failsafe .. If we want to regain control (because we see an obstacle in the flight path) we will not be able too ? 

Randy does this comment you advised earlier still apply in rc4 to get better throttle height control stability?

"Re Throttle Accel vs Throttle Rate, generally you should only need to tune the throttle accel P and I terms. Remember to keep the ratio of P to I the same as the default. I.e. raise or lower both by 20% (or whatever)."

In the Wiki it seems to recommends tuning THROTTLE_P which I am assuming is THR_RATE_P as its listed under the full parameter list and not THR_ACCEL_P?

"The same is true for Altitude hold. Throttle Rate P needs to be adjusted to get optimum altitude performance."

"My copter increasingly swings up and down in alt hold. It eventually get’s down to the ground: Your THROTTLE_P is too high or low. You don’t need a lot of P to do alt hold. Think of how much you move the throttle to hold alt perfectly. Not much! That’s what you need P to do. I will ramp up as your battery goes lower to make up the difference."

I also assume its best to fine tune Roll/Pitch RATE P first before doing the throttle tuning?


I will wait to see how Randy answer the ^^^^ question. I wonder it myself as well...

Anyone have any ideas on this?

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service