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)

Views: 305686

Reply to This

Replies to This Discussion

Thanks Randy, I'm much more confortable now to go on with 3.2.

Just curious and I may have forgotten, does the pixhawk read sonar or Lidar (if equipped) information when landing?

Hello Randy and developers.
We experienced a catastrophic failure on our geo-surveying Turbo Ace Matrix quadcopter. 

It was our first auto-pilot mission with this aircraft. 

I will describe the all the steps we took.
1. We powered up the aircraft, and made sure we had good gps lock, idle for ~5-10 minutes. while we wrote the waypoints.

2. We took off in Stablized mode, once at ~20ft, we switched to altitude hold. Once that was satisfactory, we switched to AUTO.

3. Auto began to climb, and we realized our altitude was set far too high, 200 meters, so we decided to abort the mission by hitting the RTL mode switch. At around ~80 meters up.

4. Copter began RTL, and started to descend.

5. When copter was ~50 ft above the ground, we switched to Loiter, to bring it down manually, and all the sudden #1 motor failed, and it tumbled out of the air.

6. I switched to Stablized, and tried to straight out the aircraft, but still had a very hard belly landing, followed by a bounce, and another failure of the #1 motor, which resulted in a mangled mess.

I visibly saw the #1 motor fail, and stop spinning, but it only happened when I switched mode from Auto to Loiter. This is confirmed by the log, which pixhawk clearly demands 100% throttle from the #1 motor, but no luck from there.

I've attached a log below, Please advise on what steps we should take next to prevent this type of mishap from happening. We are planning to replace #1 esc already. 

Why would a motor lose "sync" after a mode change? Everything was going perfectly fine from that. Is it bad to switch from Auto directly to Loiter? Is there a bug in the code, where upon mode change, it may send confusing signals to the ESC making it lose sync?

Thank you!


You may get a better answer from someone else but here's my guess. I've had a sync crash although not in this circumstance. My guess is the FC gave the ESC enough of a throttle blip when you switched modes to cause the sync failure. Now I always do a sync test on any new combination of ESCs and motors to be sure this is not an issue. If you have a servo tester it works best but even your transmitter will give you a pretty good idea. Strap the quad down (very securely at each motor) and power up. In stabilize mode flail the throttle on you TX and see if you can get the motors to loose sync. The servo tester will give even sharper acceleration.  

I can't believe the Auto Pilot is the cause of this crash.  If there was an issue with the sync it should have effected all of the motors and not just motor 1.


The logs show that motor one was starting to fail before it went completely.  Could be an ESC failure or got to hot or maybe a loose wire connection.


Switching mode may have just shutdown the ESC long enough for it start it back up before it just failed again.  Would not put to much into the mode switching.


I have flown many missions with this version and have not seen this issue.  I have although seen my prop fly away and have my copter tumble to the ground.


Have you checked for other causes?


These are just my thoughts.



Hi Michael, Thanks for your insight.

Could you explain to me where you see the #1 motor failing? I fail to see where the motor one was starting to fail, because when I look on the log, on RCOUT on CH1, the 100% demand was right when I switched to Loiter from RTL. This is exactly the moment, the copter started to tumble. 

I am not blaming the autopilot, I will replace the affected #1 ESC and the damaged #4 motor. I am just curious if anyone had a random sync issue.

BTW, the aircraft has had dozens of good stablize-althold-loiter-rtl flights, but I cannot test further as pixhawk was crushed on the crash.

Thank you for your reply, It does seem like a sync issue. I just cannot find another point of failure, as I have followed the WIKI to a letter, and followed all the pre-flight and setup perfectly.

We are quiet bummed about this crash. 

Hi Mike, I don't know how often all the motors are effected but very often it is only one. Where the sync is marginal or if the FC legitimately puts more acceleration on one motor which was the case in my crash, only that motor will loose sync. All that said it could also be the FC but only testing sync will eliminate that issue.


Is it possible the prop spun loose on #1? I double check about every 3-4 flights as I have on occasion

found one to be slowly loosening up. I hear ya about being bummed.. :[ 

Hi Richard, the prop is the bolt on type, with two screws and a retaining plate. The prop didn't move at all.

I visibly saw the #1 motor stop turning entirely... :/

We have a spare pixhawk to throw on there, but now we are back to square one.... We are considering scrapping the motor/esc set that we have and go with a different brand such as T-motor. But thats at a considerable cost. 

I will do what terry suggested, and do a rapid mode changes and throttle changes with the new esc in place to make sure the sync issue doesn't surface its ugly head again....

any other ideas on what could've happened? could I call this a sync related failure?

If you do your test the way Randy suggests doing the compass mot test (flip the props and rotate all of them one position clockwise) you can do it on the ground without any danger of a crash.

It may be a compatibility issue between the motor and ESC. ESCs with the SimonK firmware and low KV motors used to be a problem until the software parameters were updated. you might have something similar.


    Yes it does but perhaps not quite as you'd expect..  You know how when landing from a high altitude it descends at about 1.5m/s (WPNAV_SPEED_DN) but then around 10m it suddenly slows to 50cm/s (LAND_SPEED)?  With a lidar attached it will reduce it's descent to the lower speed the moment it senses something below (with the lidar/sonar).  Now that you bring this up this could be a bit annoying with a 40cm lidar!  Maybe we should fix that.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service