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)
Replies
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.
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
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.
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...
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..
2014-12-31 07-56-37.zip
Hi,
i return with same issue, but now i have prearm logs:
2014-12-27 15-30-48 95.bin
2014-12-27 15-30-29 96.bin
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.
I'm again with the same issue but do another test, I fly in simple mode, when I go to my left little quick the cuad loose altitude and recovers when I stop, instead to rigth is a rock solid altitude, if I rotate the cuad, nose to left, same problem when I fly to my left (but the front of the cuad, and same thing if I rotate the cuad to the other side so, I suppose I discard the bubble problem; someone have same problem and resolve it? Thank's
2014-12-15 19-29-12.log
@Flyhigh
This can happen if you bump or move your trims. I would suggest you zero you trims and do a radio calibration and see if that does the trick. If nothing else you can then rule that out.
-
13
-
14
-
15
-
16
-
17
of 373 Next