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,

    What about Rally points? As I told you, it no work and when it's set it cause RTL behaviour! (AC3.2Rc3 PIXHAWK, and I check release notes for AC3.2Rc4....)

    Condition YAW absolute ok but relative no work.(if I set 90° relative, copter only achieve 30-45°, I thinks issue for condition yaw relative is due to use current yaw at intant when Condition YAW is invoked..I think that for condition yaw relative work finly, is better to calculate relative yaw from the expected yaw between 2 waypoints, what do you think?

    For pause auto-mission, it works, but there is possible to move current waypoint number variable to eeprom? like this even when copter no finish big mission due battery level, and auto invoke rtl and land and we change batteries (reboot), when we restart mission, automatically copter go to waypoint targeted just before rtl?

    also I noticed that when switch back to auto mission mode after having paused, all the functions such as do_set  or condition_ commands are not reactivated, it would be possible to ensure that all (or the last ones) of the do_set_  and conditon_ be before current waypoint be reprocessed when switching back to automission?

    Regarding RC4 and direct throttle feedback from pilot thr input before takeoff in LOITER ALHOLD POSHOLD no work.....Just little difference with RC3 is that when pilot star to up throttle, RC4 step up by 10% throttle off motors, and take off when pilot throttle input goes up by 50%, So no direct feedback before take off like dji...

  • Hello all,     I am currently loading 3.2 rc4 onto my quad. I noticed a new line in the code: "# define FRSKY_TELEM_ENABLED           DISABLED    // disable the FRSKY TELEM".

    I send telemetry out of my APM which feeds into a JD-IOboard, and that feeds into the side of a Frsky Tx which is read on a small screen on my Rx. If the Frsky telemetry is disabled with the above command will the telemetry I have always used be disabled or does the new line of code refer to something else?

    Also, If I enable Frsky telemetry by commenting out the line of code the firmware won't compile. I am not sure why this is happening, would anyone know?

    Would anyone be able to help me with this?

    Cheers, Cameron.

  • Tested today AC3.2-rc4....brief oscillations observed before in both pitch and roll are gone.  Spline waypoints are now rather smooth including ascend and descend between waypoints. Thank you so much.  Flight modes such as stab, althold, poshold, auto, rtl...are great! I tried loiter circle, the copter moved backwards, then started its way to complete 2 circle turns as specified, however, the nose of the copter did not point to the center of the circle as described in here:  Maybe, i just missed something. Anyway, overall AC3.2-rc4 is simply amazing!

  • Developer

    Ok, so one problem with -rc4 is that the barometer glitch protection is too sensitive.  Until -rc5 goes out, could people please increases the BAROGLTCH_DIST parameter to 500?

    • upped baroglitch_dist to 500 , hovers nicely, any horizontal movement in alt hold, results in 1-2meter alt changes either plus or minus.  bumped to 800, at first 2 min i though this fixed everything, however after 2 mins, the same behavior, maybe even bigger alt changes. 

      • Developer


        I think what you're seeing is the "drop after fast foward flight" issue.  This is a well known issue that's been around since we introduced inertial navigation (in fact it was probably around before then we just didn't notice).  Amazingly we didn't have an issue raised for it so here it is.

        Changing the baro glitch params won't help I'm afraid.

        • Oh yes, I am very well aware of that issue, its just that it was usually rather gradual, this time its almost instanteneous, just barelly started moving and bam, drops like a stone a meter. Also, regarding the issue you discribed, for some reason it used to happen to my drones ONLY when moving forward, reverse and side movements simply stay at the same alt, only at extreme rolls, usually repetative ones, I would loos alt.
          • Developer


                 If you have a log, I'm happy to take a look and see if I can see what's going on.

This reply was deleted.