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: 305687

Reply to This

Replies to This Discussion


i return with same issue, but now i have prearm logs:

i use 3.2 quad, i use default settings and done calibration all for my frame. AT home all working great, but if i go outside i have accel error: Accels not healthy. Outside is ~+5 celsius. I thing the error is from low temperature.
Can you help me?


I attempted ACC calibration this morning at -2C was not able to do it, copter went fine through the calibration process when I came inside. 

Randy, recently I had an issue when my copter running AC3.2 went full throttle, while I fully dropped throttle. I believe this issue is vibration related, however I have no idea what was the source of the vibration since for the previous 14min+ copter flew with vibrations under 0.5, more interestingly the only vibration axis which goes mayhem is Z axis on both IMUs. I will be attaching a log of this accident, its a lengthy one (I was checking new gains on a gimbal) and the interesting part is between lines 194 - 200. The exact moment when my RCIN3 goes to 0 and alt goes to 60m is in the lines between 195.4 - 196.1

After the flight it shows that copter flipped after landing, not sure if it is related to the delayed disarm or wind or grass, but no damage was done and I checked each and every piece of equipment on the copter everything was attached firmly, this is also proved by the lines 198+ in which all vibrations return to their normal 0.5 values.. 


You were lucky you switch to Stabilize when you did.  The Throttle Out went to maximum and stayed there until you switched to Stabilize.  The vibration seems to have happened after that so I don't think that did it.


With AC I learned a long time ago stabilize = my friend :)

It happened during pos.hold and I switched to alt.hold but that didn't help. The order of events you are saying is interesting, this would explain why vibes were only on the Zaxis. Will double check again, but would definatelly appreciate a reply either from Randy or one of the devs involved in pos.hold.  

Hi Artem,

I had a look at your log, I don't think it's related to poshold, but I'm really not sure of what happened.

We can see the Alt is no more (or much less) computed from the baroAlt, that means the controller did not rely on the barometer to compute the altitude, I don't know why, maybe a sanity check somewhere? EKF was ON so that's surprising to find such errors between baro and alt.

In the other hand, when your issue appeared (ie when the Climb_Rate started to higly decrease), we can see some oscillations on the IMU Z_axis_acc so, probably the weight of Acc is >> the weight of baro in the altitude estimation.

I don't understand why there was oscillations only on Z_axis (even if it could be possible) but what's most surprising is the vibrations are not related to thr_out... (26.2 to 26.7=>oscillation, then nothing! log line n° is 26 instead of 194 because i've removed the first part of the log)

The IMU2 seems less disturbed at the beginning but then both IMU were completely crazy.

You should make tests to check if your IMU are disturbed at high motor RPM.

Could it be turbulence (z axis only)? I was flying very low to the ground at about 1.5-2m head into the wind to check how footage would be affected by this... 

wow, I just edited my previous post adding like a paragraph to it and the forum s/w saved only the first sentence. 

15 min only to edit.

To make the picture is full I should mention that I have also installed retracts and was checking them too during that flight. I power them via a separate BEC plugged directly into the Rx, but I also use the power wire in the Rx -> Pixhawk -connection. I've left it connected so I have redundant power supply to FC, but the BEC runs at 5.4v could this be related? Pixhawk powering wiki says that it is safe to power pixhawk with up to 5.7v

Also, it was below 0 Centigrade and the first 3-4 power-ups I was getting ACC warning since I upgraded it to AC3.2 

Hi, I tried to make an adjustment in Loiter PID but  "HLD_LON_P " didn't set. Going to the full parameters list that item is missing. I'm using APM 2.5, latest MP and arducopter 3.2. That problem only occurs with 3.2, going back to 3.1.5 that's OK. I found the same problem reported here before but I couldn't find any comment. Does anybody know about it? Is it normal in 3.2, should I worry about it?



If you can update HLD_LAT_P then it should be fine.  We removed the HLD_LON_P because there shouldn't be any need to have a different P value for Latitude direction correction vs Longitude.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service