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 –


    • I think u have to flash copter software if  on APM is plane version or flash plane if u have copter on APM , that should erase eeprom to default values.

  • I have a Hexacopter with a Pixhawk and have the released version of Ardupilot 3.2 firmware loaded. I performed the accelerometer, compass and R/C calibrations out in the field. My goal was to test a simple mission of a few waypoints spaced at just a few yards apart with the copter tethered with a 100 foot line to avoid a runaway. 

    The first flight went great. The copter performed perfectly.  I moved the Hexacopter back to the center of my course, cycled the power and tried another mission. This time though, the copter went into this wild oscillation right after launching and ended up crashing. After the crash, I noticed that the Pixhawk had came loose from the double stick mounting pads that came with the Pixhawk. I'm not sure if it came loose due to the crash or was in the process of coming loose, which may have contributed to the behavior. 

    Here is a video:

    I didn't notice anything obviously wrong in the logs except for the wildly oscillating pitch, roll and yaw. I've attached the logs from the crash in case anybody can see an apparent problem.

    (I'll try it again with the Pixhawk more secured, once I fix the broken mounting points in the frame. )

    Thanks for any feedback!


    2014-11-28 12-04-49-wobble-crash.bin

    2014-11-28 12-04-49-wobble-crash.log

    • Moderator

      Hi Rob,

      I've been thinking about what you've described, and by the way, I think we're all glad you had a moment of ESP when you decided to tether you're Hexacopter; what is your WPNAV_RADIUS set to? I ask this because you describe the mission as "a few waypoints spaced at just a few yards apart". Thinking about this, if the waypoints were set apart less than twice (at least) the distance described by WPNAV_RADIUS, you would create a series of waypoints whose radius create circles with intersecting sections. This creates a unique circumstance where you could possibly create a zone where all waypoints could be "reached" at the same time. In theory this could result in some pretty wild oscillations.

      Consider the following examples:

      3702534048?profile=originalIn Figure 1 we have a box described by 4 waypoints that form a square; the waypoint radius in this example creates 3 distinct overlapping zones. The black circles indicate the circular zone created by the WPNAV_RADIUS around each WP indicated by the small red circles. In the Blue zone all four waypoints would be considered by the FC to have been reached. In the green zones 3 of four waypoints would be considered to have been reached, and in the yellow zones 2 waypoints would be considered to have been reached. Only in the white zones would the waypoints by individually described, and this would only be true if we overshot the waypoint.

      In Figure 2 the waypoint location has remained the same, but we have reduced the WPNAV_RADIUS shown in black. There are no overlapping zones so the FC would not oscillate.

      Lastly in Figure 3 we have moved the WP locations further apart and kept the same WPNAV_RADIUS as in Figure 1. Again we have no overlap, so the FC would not oscillate.

      Your WPNAV_RADIUS = 200, or 2 meters; so if your waypoints are spaced closer than 4 meters apart you are going to have at least some overlap as in Figure 1. The mroe your waypoints overlap, the greater the likelihood you might see some strange behaviors.

      Can you post a copy of you mission file, or a tlog from your flight?

      This is all just a theory, and I welcome the opportunity to either confirm or deny it.


      Nathaniel ~KD2DEY

      • Thanks for the reply. 

        I'm using an WPNAV_RADIUS of 2 m (200 cm). But, I noticed that I managed to place the first two waypoints on top of each other, which in the MP shows NAN for the gradient. I haven't looked at the code to see if a NAN for gradient would confuse the flight controller. 

        I've attached a picture of my waypoints and the mission description. 



        • The flight was doomed from the start.  As soon as the copter armed the copter was told to bank hard left and forward.  Since it was on the ground at the time, it started flying in a circle which just confused the rest of the electronics to the point where it was over correcting and thought it was flying downward into the ground.

          It also looks like you are not using a Transmitter as RCIN was all zeros.


          • Thanks Michael for looking at the log.

            No transmitter was used in this test, only MAVLINK commands over the telemetry.

            What parameters in the log did look at to come to this conclusion? ATT/DesPitch and ATT/DesRoll?

            That is odd that roll and pitch was commanded. The only commands being sent over MAVLINK are RC OVERRIDE on Throttle just enough to get it into AUTO mode. Then the flight mode was set to AUTO. I noticed there is non-zero values for DesYaw as well. Not sure why that is.

            I wonder why the flight controller would command pitch, yaw and roll for TAKEOFF?

            One thing that I ended up having to do with my transmitter setup was remap the channels. If you notice, RCMAP_THROTTLE is 2 (usually 3) and RCMAP_PITCH is 3 (usually 2). Not sure if that is causing any confusion. It's worked fine on previous flights though. 

            I noticed that RCIN/C2 was at 1000, which should be 0% throttle in PWM. The normal value looks like its 0 for the RCIN commands. Shouldn't those all be at 1000?

            • Maybe I'm out in left field, but was all props checked to ensure they were tight to the motors?  After reviewing this, I recalled a year ago on my Hexa when I threw a prop and my Hex went into a crazy oscillation pretty much the way yours did.  Also check to see if any motors are loose on their mounts.  Just another thought to share.

              • Thanks for taking the time to reply. My motors and props are all tight. 

                I should have the F-550 frame repaired this week by epoxying aluminum sheet metal across the breaks and will try a few simple tests to see what's going on. The biggest difference between the two flights was that the first one had the R/C on and the second didn't. I haven't had to have the R/C on in the past so I'm skeptical that there is a bug related to that, but its worth checking out.

            • Yes, that did confuse me.  Still the RCIN should be at a minimum of 1000 and a max of 2000. Yours are at 0.  That would mean Fly hard Left and Down.

              This is what the graph shows just before Auto was started.  Auto would then correct this because radio input is not used.






              • I also noticed that the barometric altitude tracked opposite the integrated altitude, probably due to the wobble. I've seen this happen in the past when the vibrations are large. I wonder if the Kalman filter would do any better in situations like this?

                I would've hoped the flight control system could've recovered eventually. (Of course, if the Pixhawk was loose there wouldn't be much hope.)

                I've attached the plot.


This reply was deleted.


Gremsy liked Gremsy's profile
Mar 12
DIY Robocars via Twitter
RT @chr1sa: Donkeycar 4.4 released with tons of new features, including path learning (useful with GPS outdoors), better Web and Lidar supp…
Nov 27, 2022
DIY Robocars via Twitter
RT @NXP: We are already biting our nails in anticipation of the #NXPCupEMEA challenge! 😉 Did you know there are great cash prizes to be won…
Nov 24, 2022
DIY Robocars via Twitter
RT @gclue_akira: レースまであと3日。今回のコースは激ムズかも。あと一歩 #jetracer
Nov 24, 2022
DIY Robocars via Twitter
UC Berkeley's DIY robocar program
Nov 24, 2022
DIY Robocars via Twitter
RT @chr1sa: The next @DIYRobocars autonomous car race at @circuitlaunch will be on Sat, Dec 10. Thrills, spills and a Brazilian BBQ. Fun…
Nov 24, 2022
DIY Robocars via Twitter
RT @arthiak_tc: Donkey car platform ... Still training uses behavioral cloning #TCXpo #diyrobocar @OttawaAVGroup
Nov 20, 2022
DIY Robocars via Twitter
RT @emurmur77: Points for style. @donkeycar racing in @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video.…
Nov 20, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Going to @diyrobocars race at @UCSDJacobs
Nov 8, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Race @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video.
Nov 8, 2022
DIY Robocars via Twitter
RT @PiWarsRobotics: Presenting: the Hacky Racers Robotic Racing Series in collaboration with #PiWars. Find out more and register your inter…
Oct 23, 2022
DIY Robocars via Twitter
RT @Hacky_Racers: There will be three classes at this event: A4, A2, and Hacky Racer! A4 and A2 are based around UK paper sizing and existi…
Oct 23, 2022
DIY Robocars via Twitter
Oct 23, 2022
DIY Robocars via Twitter
Oct 19, 2022
DIY Robocars via Twitter
Oct 18, 2022
DIY Robocars via Twitter
RT @NeaveEng: Calling all UK based folks interested in @diyrobocars, @f1tenth, @donkey_car, and similar robot racing competitions! @hacky_r…
Oct 13, 2022