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

Reply to This

Replies to This Discussion

Leonardo or Randy, I almost updated to the new beta today after having 6 successful flights without the surging problem. Then on my 7th flight it showed up again. I'm including the logs here. In the last part of the flight I was trying to provoke it and shooting around and on one of those hard pitch movements it did the surge also. Otherwise it would just randomly do it while trying to maintain a hover.
I think I've attached the right logs but if you don't find the problem let me know and I will upload another one. If this is the right log then it happens right in the first 30 seconds and all through the test.
The third attachment is an extra tlog just incase the other one isn't the right one. I'm pretty sure the flight is in the first two attachments but let me know if it's not and I will upload the other files.
BTW, what data field are you viewing in the log browser to see the problem?

Hello leonardthall

I had the same symptoms in 3.1 RC4 - the earlier versions (RC1-3) I haven't tried. So I thought its 3.1 in general. If the sensors would give wrong readings then it should show at a slower rate as well, or not? If speed affects the values then I would say there is a problem in the communication with the sensor like loosing data or grabbing outputs before those are stable?

The files...


Then what I said above is correct. Copter will still self level (even if Acro_Trainer is set to 0) till Acro_Ball_Roll & pitch parameter values set to 0. .

Is this right?

File 3


Yes, crash detection is possible.  There's an item on the issues list about it here.

There's people in both camps re having them spin by default or not.  I initially didn't like it but I like it now.  I'll try and gather up some more data on the percentage of people in each camp and maybe we will change the default for the big release...if not we can probably get MichaelO to add a warning after the firmware is downloaded.


    ok, great.  thanks for the feedback/info!

So the _D must be a rounding error so I wouldn't worry about that one.  Someone else also caught that IMAX 180 issue and MichaelO has apparently fixed it so hopefully the problem will go away once we all receive the next version of the mission planner.

thanks for the report!


     Thanks for the files.  The issue is most visible in the CTUN message's AngBst field.  It's output at 10hz so it likely doesn't catch every event (probably only 1/5th of them actually 'cuz the throttle controller runs at 50hz).  This problem makes us a bit uncomfortable actually.  Leonard and I will have a chat and then maybe we will send you a binary to bench test with.

Hey Graham, what is it exactly you're trying to do here?  I'm a little unclear what you want, but I'll try.

First thing to know is that there's no buzzer oscillate.  The oscillate was actually intended for the lights.  So, if you have a low battery event, the lights by default will blink fast to signal low battery. All-on, all-off, together.

If you turn on the oscillate feature, when you have a low battery event, they will oscillate, meaning half on, the other half off, and back and forth like a police car.

So just a couple of things..we don't sample the sensors any faster in AC3.1-rc5 than we do in AC3.0.1.  We do run some of the loops (including the throttle controller loop) faster because we made some CPU efficiency improvements.

I have two theories at this point:

1. the board voltage is changing by 0.4V in Bruce's log (you can map the HWSTATUS section's Vcc to see it) when the battery is plugged in and this may be affecting the gyro sensor readings.  Bruce, if you plug in the battery (and leave it plugged in) before connecting with the mission planner does the HUD still spin?

2. we're running out of memory.  In bruce's log the memory is getting down to only 550bytes free.  I'm a little surprised it's this low, I thought it was up at 850 during my personal testing but I did re-enable optical flow at the last moment before pushing out -rc5.  I'll check this.

So I don't think it's #2.  The cause of the low memory in Bruce's log is just that the accel calibration chews up 400bytes while it's running but that's a one time thing and not something that people would normally do and it can't be done in parallel with other memory hogging actions such as running loiter.

I've also tried recreating #1 by plugging my board into my USB expansion port that only delivers about 4.3 V to the APM and then plugged in the battery which can deliver about 5.0V and my gyros didn't misbehave at all.

So we need a new theory!

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service