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 –


      • @Randy

        screen shot my altitude. and during copter bumping to land, i try POSHOLD to takeover the throtle, but failed. seems RTL/LAND  continue his job.

        attached log

        LAND SPEED 50

        WP SPEED DN 300


      • Randy,

        Could this also caused by the copter being close to ground?

        I see bouncy landings with low profile copters a lot. When the baro sensor is very close to ground the sudden pressure increase deceives the baro sensor. Raising the platform (ex: by using a landing gear) solves this issue most of the time.

        But I also see perfect landings on many low profile multicopters (which don't use a raised landing gear assembly) as well so the land_speed parameter that you talking above could be the main reason. 


        • Developer


          Ah yes, you're right.  Another possibility is a baro disturbance near the ground.  There was a tri-copter report a few days ago in which baro alt drop by 4m when it came close to the ground.

  • Just put RC14 on my tricopter.  Redid all my calibration and im getting "prearm check fs_thr_value" warning for my prearm check.  my throttle off pwm is 982 and on is 993.  Failsafe is set to 984.  Any ideas?

    I would use my frsky x8r with sbus for failsafe but even though MP shows the  the pwm change from the x8r with its failsafe being set it wont engage the flight mode so im stuck doing it with mp

    • I found in setting mine up that fs_thr_value had to be at least 10 less than the throttle minimum value. I had to use the throttle trim on the transmitter to get it high enough to avoid the message. Looks like you need to adjust your transmitter trim to make your minimum at least 994 or more.

      • I pushed my trim to max and redid the radio calibration and im good.  Thanks!  Maybe this is something that could be addressed?

        • There is nothing to address, the code is doing what it should.  Instead of adjusting the tx trim, you may consider setting the throttle travel (on the "servo's" page in the FrSky to a lower number, say 80% ) so that at center trim, the pulse widthis 1000 (1ms) or more at minimum... and make sure it doesn't go over 2000 (2ms) at full throttle.  You will need to redo the radio call in the APM set up once you do this.


          • Thanks for the response steve.  Another question.  whats the problem with exceeding 2000?  My taranis hits 2006.  



            • The timing of the rc pulse stream can experience problems if the pulse width exceeds 2ms.  This happens because the 2ms pulse hasnt ended before the next pulse starts.   This problem can occur in the ppm stream decoded in the pixhawk or in the rc reciever.

              To see this in action use a exuhf module in the taranis   if you set a few chanels to more than 2ms you can change flight mode (ch5) by moving channel 4 (rudder).  

              The last thing you want in anything that flies is unreliability.   Keeping each pulse in your pulse train between 1 and 2 ms   helps keep the rc link reliable.


This reply was deleted.