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: 386579

Reply to This

Replies to This Discussion

Guys, we should really bust this out into a new thread.  It's a very interesting discussion, you both have some great ideas and data, and it's just going to get lost in the noise in thread.  Pun intended. :)

This very much is a chicken or the egg discussion Michael.  Are vibes creating thruster noise, or noise creating oscillation.  I have no idea how to tell.  We should really try to get Leonard in on this.

What I find interesting is your data seems to show that it is related to airspeed, instead of ground speed.  It doesn't solve the chicken/egg question, but it is very interesting.  It's clear that the vibrations go up a fair amount, but not as bad as it appears.  If you look closely, you can see signal in that noise.  There are high frequency vibes imposed on top of low frequency vibes.  

I do not believe it's an algorithm problem.  It's a physical effect.  Either airflow causes flapping, which causes vibes, which creates noise on the alt-hold controller.  Or, it's possible that at higher airspeeds, the props have more control-response than they do at low airflows.  As such, they are overgained at high speeds when tuned to be critically damped at low speeds.

I know for sure this is a factor with helis.  Just never seen evidence of it with quads.  It's theoretically sound, but I don't know what speed you would need to cause the problem.

Rob, if you want to start a discussion go for it, and I'll repost my data there (or you can use it however you want). Just for the sake of clarity, I was flying on a calm day. So GS ~ AS. The flapping phenomenon is very easily understood if you consider prop blades as wings, which can have a variable angle of attack. With any crosswind, the AOA of each prop blade becomes sinusoidal... lift is proportional to AOA... 2+2 = sinusoidal lift, and we get a lot of vibes.


I don't mind posting to a new thread.


I'd like to trust your theory that this is induced by vibrations that in turn are caused by aerodynamic effects. But shouldn't I see the same vibrations flying manually? Have a look at my auto2 jpg. As soon as I switch to stabilize (36.2) the z acc log returns to normal values. At this point the quad had the same speed and keep in mind also the same motor/prop rpm. So if flapping had caused this there would have been no immediate change of z acc at the switching point.

And you are right, this should be fixable with adjusting gains. And I indeed saw a change with lowering the PID's. In fact increasing PID's makes the system even more responsive to disturbances. But it seems that I can not lower them below a set limit. I am not deep enough in the software to find if the gains have fixed low limits.

What I would like to try as a quick and dirty trial is some smoothing / low pass filtering on the motor outputs. I am convinced that the SimonK ESC's have an in this case undesired effect on the sensitivity of the controller. I guess what I am saying is that if the control loop works for standard ESC's it might be too sensitive for SimonK's. Makes sense?

Oh, and Rob. If you get in contact with Leonard please ask him what he did to fix the violent twitches when switching to Loiter mode in 3.0. I was the guy that sent him logs and he responded that he found a problem when switching to Loiter with SimonK ESC's.


Please post your log file

Just want to let you know I am reading this discussion.  It may be because we can't run the alt hold controller fast enough so it's output becomes choppy under rough conditions.  It's running at 40hz max on the APM.  We could try boosting that up to 100hz on the pixhawk to see if that helps.  In general we're going to try increasing the rates of everything by 2 to 4x on the pixhawk.

ah, good, thanks for the feedback.

ok sure.  Actually -rc4 will be out within a week so I'll include it by default in that build.


     It's smoother in -rc3 than it was in AC3.0.1 but we will slow it down a bit more for -rc4.  I haven't made the change yet but I will for -rc4.


     AC3.1-rc3 is now out in the mission planner's Beta Firmwares and includes improvements for the APM2 including GPS Glitch protection and a first attempt at an auto-tuner.  It is becoming nearly impossible to add new features to the APM due to CPU and Flash (i.e. program size) constraints so after AC3.1 any new features for the APM2 will need to replace existing (less used) features.  ArduCopter on the Pixhawk board is where you're going to continue to see real growth and improvements.


    hmm..that doesn't sound good!  60 waypoints should not be a problem, we have space for somewhere around 120.  Can you easily reproduce the issue?  If yes, maybe you could give the precise order of things you do to recreate it including the mission file you're using?  Feel free to send it to me via DIYDrones PM or email me at rmackay9 @ yahoo . com


    Yes, it's fairly high on my to-do list.  I think that'll go in for -rc4.


    Yes, after Rob Lefebvre's post re his octo issues we've been digging into the APM performance in more detail and it's quite clear that the first control to be lost when the CPU load gets bad is altitude hold.  We've found some efficiency gains and we're also going to reprioritise the alt hold controller higher in the scheduler so that when things get tight another feature will slow down instead.  In particular dataflash logging seems like a good choice to be slowed down if necessary.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service