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 –


              • Hi. If we use SBUS, is there any problem? Or it is just with PPM?

                • I guess if it is working for you then don't change anything. Each setup has its own little gremlins and differences!

              • Developer


                I tried to reproduce this issue today with an 8channel FlySky transmitter and D4R-II FrSky receiver but was only partially successful.  I was able to cause a radio failsafe (i.e both APM and Pixhawk were unable to read the ppmsum stream) but I wasn't able to change the value of ch5.  Any extra advice on how to cause ch5 to change?

                BTW, in any case it's a serious issue (with the FrSky TX/RX) and should be documented somewhere on the wiki (which I will do).

                • I noticed this with the Exuhf in my Taranis.  If channel 4 (rudder ... used for arming and disarming) is moved all the way right (more than 2ms) then mode on the HUD (and OSD) would change to RTL as the Pixhawk lost sync on the PPM stream.  

                  The issue is simply that the pulse width range in the pulse train is finite and if the pulses are outside the spec range, (2ms max) unpredictable things can happen.  individual manufacturers deal with very wide or very narrow pulses differently, some much better than others, but if you dig through the tech documentation, most will warn you against having all pulses "high" or all pulses "low" at the same time as the receiver can have difficulty with framing if you do this.  In the real world, this is very rare.  It is more common that a single pulse (one of the 8 or 12) will be too wide which steps on the timing for the subsequent pulse.  

                  When you look at the pulse train on a scope, its obvious when the pulses are too wide on a single channel, the timing generally goes bad for the whole frame.



                • I think this video is what Steve is referring to -

                  And this I think will also be helpful -

                  I now use orange openlrsng on my Taranis and with all 8 channels (all 8 on ppm to apm with 2 simultaneously on pwm to a video switch and gimbal controller) outputting there maximum 2020 per channel I still have no issues with any strange behaviour on any channel. That's with the stock frame of 22.5ms and 300u

              • Developer

                I had no idea about this 2ms limit and it's not good!

                I'll test and if this is really the case we need to document and add a pre-arm check.

                Thanks for pointing this out.

              • oh wow.  Yeah im at 1995 and 1011 now.  




    Here is a short video of loitering my 800 trad heli  in winds gusting to 20 knots.  I'm happy with the performance. Any comments?

    Question.  While flying splines, I have noticeable jerks at each waypoint.  I've tried turning down WPNAV_JERK, ATC_RP_ACCEL, and Rate.  What is the magic parameter that can help smooth WP transitions???

    803213 ekf 2000.param

    • Developer


      Looking good.

      Yes, I'm afraid unless you set the waypoint speed low (5m/s) it will jerk at each waypoint.  We won't be fixing that in the initial AC3.2 release at least.  Maybe with AC3.2.1 but certainly for AC3.3 it'll be sorted.

      • Thanks!

This reply was deleted.


DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord:
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident:
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: What a great way to connect why @diyrobocars community is so valuable and important! Have to start somewhere @IndyAChallenge…
Oct 23
DIY Robocars via Twitter
RT @DAVGtech:
Oct 23