ArduCopter-3.2 beta testing

Warning #1: PX4/Pixhawk users upgrading from AC3.1.5 (or earlier) may need to re-do their compass and accelerometer calibration because AC3.2 also uses the backup compass and accels.  Pre-arm checks have been added to ensure this has been done.

Warning #2: on the APM2.x the logs must be downloaded using MAVlink instead of the terminal.

AC3.2-rc14 is now available for BetaTesters through the mission planner’s Beta Firmwares link.  The full release notes can be found in ReleaseNotes.txt and changes from -rc13 can be seen below.

     Feel free to raise issues found during testing on this discussion or in the new support section in the APM Forum.

     It’s a big release with “the onion” restructure and a bunch of new features (including these 57 closed items) so we need to re-test almost everything including all flight modes, all mission commands and all the new features.  Marco and I will be maintaining (and adding to) this testing list.  Issues reported will first be checked by Jonathan, Marco and I and then confirmed bugs/issues will be put on the github issues list (and then hopefully fixed).

     Thanks especially to the beta testers who put their copters at risk testing each release.  Enjoy!

Changes from 3.2-rc13
1) Safety Features:
     a) fail to arm if second gyro calibration fails (can be disabled with ARMING_CHECK)
2) Bug fixes:
    a) DCM-check to require one continuous second of bad heading before triggering LAND
    b) I2C bug that could lead to Pixhawk freezing up if I2C bus is noisy
    c) reset DCM and EKF gyro bias estimates after gyro calibration (DCM heading could drift after takeoff due to sudden change in gyro values)
    d) use primary GPS for LED status (instead of always using first GPS)

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


        • Developer


          Yes, sorry, forgot to mention that only Pixhawk users (or VRBrain users) might be forced to re-calibrate their compasses (or they may choose to override the need to recalibrate by following the instructions you've quoted).

      • Developer


        It is probably easier just to redo the compass calibration if the pre-arm checks tell you the compass must be re-calibrated.

        • What does one do if the inner compass checks fail due to high offsets [ - 150 isn ] ? Aluminum foil? Something like this? Is aluminum the best shield? I see This so it makes me think aluminum is one option. I do not want to fly with checks off again at least so when the fail over is resolved the inner is ready to be an option. I have a new pixhawk on the way gonna try a few things but if you or anybody had thoughts on things to try I'd sure like to know! First thing I am going to try is setting the pixhawk on a 4mm or so flat piece of aluminum. Then maybe paint the battery cover with that EMI/RFI paint mentioned above. I'll report if I see any improvement. That would be fantastic if that paint worked. Light weight and would easily work on all set ups. ps I did post this in another thread and got zero response. I try that at least I know this thread can get WAY off topic. 

          • Developer


            Ok, thanks for the report.  I'm going to increase the allowance to maybe 200 or 250 for the Pixhawk.  I think the 150 limit was reasonable for the APM but I think the overall mag field length is longer on the Pixhawk so slightly longer should be ok.

    • Thx for the hard work and lol.... This came just after I've finished brand new rc9 install with erased eeprom....
    • Hi Randy,

      Regarding the landing detector checks, would it not be better to set the overall throttle<5% instead of 25%. Usually just before touch down you power down to idle anyway right. On the flight controller called X aircraft there are cases where the copter disarms in mid air due throttle being below 25% while descending rapidly. Just my thoughts to prevent such a case.



      • Developer

        Chandruth, Euan,

        It's actually not a hard-coded 25% but rather it's 1/2 the THR_MID value (which is by default 500 = 50% of throttle).  This is also the maximum throttle level used to provide feedback to the pilot as the throttle is raised (but before the vehicle takes off) in AltHold, Loiter, PosHold.

        This means that for copter's like Euan's, setting the THR_MID parameter is quite important.  For these copters, if the pilot ever wanted to transition back to stabilize it would be quite important to get that right anyway.

        So the problem with making the level lower is that we don't allow the throttle to get lower than a value that would affect attitude control.  We haven't set a specific minimum but instead we set a flag each time the "stability patch" (aka the motor mixer) reports that it couldn't achieve the low throttle requested because it would mean sacrificing roll, pitch or yaw control.  Whenever the autopilot (i.e. Alt Hold controller) sees that flag set it stops reducing the throttle.  Overall this means the throttle doesn't drop far below what it needs to to land... so it will never get down to 5%.

        Leonard and I have discussed enhancing the AltHold / landing controller so that it does allow the throttle to get lower by giving up on attitude control slowly.  This would also help landing on slopes.  It's a little tricky though so we haven't done it yet.

        • Hi Randy,

          If its the stability patch that doesn't go down to 5%, how about using the RC transmitter PWM values from throttle input. Use 0%-5% of calibrated RC Throttle PWM. This should be separate from the Desired Throttle to the motor mixer right?



          • Developer

            You've got me thinking a bit more about this ...above I said this:

            Whenever the autopilot (i.e. Alt Hold controller) sees that flag set it stops reducing the throttle.  Overall this means the throttle doesn't drop far below what it needs to to land... so it will never get down to 5%.

            .. but now that we have a two-stage landing process we could make an exception so the autopilot does keep reducing the throttle if it thinks we've landed.  We could then reduce the overall-throttle requirement for the 2nd stage of the landing detector (which is the more critical stage).

            By the way, 25% sounds high perhaps but remember the THR_MIN for most copters is 13%.  That 25% includes the deadband at the bottom of the ESCs.

            I'm a bit reluctant to make any further changes to AC3.2 unless they're absolutely required but I'll think about this a bit more..

            • Hi Randy,

              Take your time with it. If it comes to point there can always be a 3.2.1. Releasing 3.2 takes priority. Just thought a RC throttle 0%-5% check might remedy what users of X Aircraft flight controllers were facing. I was looking at it in a RC stick position percentage rather than overall throttle. Regarding the spring throttle, even those you have to lower to idle for a second or two to complete the landing. I think with those larger 30 inch prop quadcopters on 12S, THR_MIN will surely go below 13% due to the Power to Weight aspect of it. As for the second level of the landing check, in the case of a false positive and throttle starts reducing, is the pilot still able to throttle back up to safety? Anyway no rush for this if the current landing detector works well enough.



This reply was deleted.


Shivchand Jaysaval liked Shivchand Jaysaval's profile
Aug 25