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, You want the log files? about rally point, condition YAW?

          And what about idea for pause automission improvement? what do you think?

      • Yes, noticed that too. Does your tri "pulsate" in alt hold?
        • Hello Artem. I'm not seeing any pulsating in alt hold.

  • Randy,

        Before day, I had test RC4 (Stabilize, ALT Hold, Loiter, PosHold, Auto, Guided, RTL) with EKF is very perfect. But, I have problem is no auto disarmed when have battery failsafe with itself when down to land. I need move throttle down for disarmed after it have to land.

    • Developer


          Thanks for the report.  I think that's always been the behaviour even with AC3.1.5... when the vehicle lands it requires the pilot to put the throttle to zero before disarming,  The only time this doesn't apply is during a radio/throttle failsafe because the pilot has no control of the throttle.

  • Got a weird one with betas rc3 and rc4. DIY hex, all 3DR components including PPM encoder btw, older Futaba radio. Flew well with everything including and prior to rc2. Now getting funky motor behavior, won't complete ESC cal, did all individually, seemed ok, when armed only 2, or 4 will spin. Did ALL set ups and calibrations, power cycles, many times, no go with rc3 and rc4... It will arm but don't get the last 2 beeps. Only 2, sometimes 4, motors will spin. Redid ESC cals, full set ups, many many times. With no changes after loading rc3 or 4, etc, then reverting back to rc2 and 3.1.5, it works very well. PPM issue?
  • Beta bug report – Waypoints,  Condition-Yaw and RTL Fail

    I finally got up the nerve to try the latest RC4 on my Tarot 680 Pro Hex with RC Timer Gimbal and Canon camera. The mission I flew was designed to capture a 360 degree panorama using the pitch control of the gimbal via a Set-Servo command to position the camera at 4 different pitch angles and using the Condition-Yaw command to position the camera at eight different yaw angles. This would, if successful, result in a panorama mosaic four rows high by eight columns around.

    The mission starts out by positioning the Hex facing West and the camera pitched up to row number one and takes a picture. It then moves the camera down to each row and takes another picture. At the end, it rotates the hex by 45 degrees CW relative to its current position and does a Do-Jump back to the top for another column of photos. After eight Do-Jumps, it does an RTL. If everything worked, that is.

    Problem No. 1

    A Waypoint command with 0 Lat, 0 Lon, and 0 Alt changes ATT/DesYaw to be the current yaw angle every time the Waypoint command is executed.   On my hex there’s always a couple of degrees error and it’s almost always positive, so after the 12 waypoint commands required to do one column of photos the camera is pointing 20 or 30 degrees CW from where it’s supposed to point. A Waypoint with 0 Lat, 0 Lon, and 0 Alt should not change the DesYaw. There is also a noticeable jerk each time the waypoint command is executed, perhaps because it’s getting a new DesYaw angle.  See Flash Log 1 and Mission file. Do we still need a Waypoint associated with each Do and Condition command? Is there any way to have a long sequence of Do and Condition commands without the need for a Waypoint command after each Do and Condition command?

    Problem No. 2

    The Condition-Yaw command with a relative yaw increment does not work. It uses the increment value as an absolute value (e.g., it interprets “yaw CW by 90 degrees” as “point East”). See Flash Log 1 and Mission file.

    Problem No. 3

    Manually invoking RTL did not land the copter. It just stayed at altitude. See flash logs # 1 and 2

    Flash Log 1.BIN

    Flash Log 2.BIN

    Panorama 4x8 Start Facing West 2014-08-02.txt
    • Developer


            Thanks for the report.  The one re the yaw is just as you say, it's using the current heading instead of the target.  There's even a to-do in the code about it so this is fairly easy to sort out.

            As for why RTL is getting stuck, I've looked at the logs but haven't figured it out quite yet.

      • @Randy

        Regarding the broken Condition-Yaw Relative command: I've commented on Github issue 310 ( with my proposed correction to the code. The existing "else" control statement at line 489 of control_auto.pde is clearly wrong. Mine may be equally wrong but it should look something like that.

      • I’ve done a few more tests, here’s an update on my problems:

        Problem No. 1 – Waypoint Yaw Behavior

        I found a configuration variable called WP_YAW_BEHAVIOR. I changed this from 1 to 0 and it solved my problem for now. A side effect of this is that the hex no longer faces towards the next waypoint when I use non-zero waypoints. It would be better to treat Waypoints with zero Lat, Long and Alt as though WP_YAW_BEHAVIOR was zero, and real waypoints based on the actual value of WP_YAW_BEHAVIOR.

        Problem No. 2 – Relative Condition-Yaw

        It’s still broken but I’m using a workaround until this is fixed. I’ve abandoned using the Do-Jump loop with a relative Condition-Yaw command and expanded the number of mission commands. I had to delete the top row of photos to keep the number of commands below the 165 command limit.  

        Problem No. 3 – RTL

        RTL will work for me in the following scenarios:

        1. As a result of a battery failsafe
        2. As the result of hitting an RTL command in a mission
        3. After lifting off in Stabilize and switching to Loiter then issuing the RTL command from the transmitter switch.
This reply was deleted.


DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
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…
Nov 25
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord:
Nov 23
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…
Nov 23
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