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
Graham,
So as expected it's vibration in the vehicle frame (vibration wiki page here). I'm afraid at this point there's really no solution besides the physical one -- i.e. to try and reduce the sources of vibration and improve the vibration dampening foam. There's no question that this is a serious weakness of arducopter and it's been there ever since we introduced the inertial navigation for altitude hold back in AC2.9.1. With the advent of the Pixhawk which has more CPU power and Paul Riseborough's work on the EKF (which will replace DCM & Inertial nav as the default when AC3.3 goes out) we should be able to automatically identify high vibration and deal with it better but until then, I'm afraid we just need the frames to not vibrate too much.
Well went out to test today and at 50 seconds into a hover the multirotor just climbed at full throttle to about 170m and cut off, I tried loiter, rtl and back to althold but no reaction to gain control.
Quad spec's: 600mm quad, pixhawk, 25amp quattro esc, 3508 580kv motor, 13x5.5 carbon props very well balances as I recheck for this test, 5300mah lipo and auw 2.4kg.
Was monitoring the live vibration graph while in hover and nothing until it took off, shutdown and came plummeting down to earth . On rc10 it would be fine flying slowly but pick up some speed and the vibe woulds spike in z acc and it would climb to 25m or so and the I could get throttle control and get it down slowly.
The 170m crash happen on rc12 fw i loaded last night, this seems to be similar to Graham's throttle spike problem. My quad is wasted man!!
Pls have a look at the log file.
Thanks
Charl
2014-10-21 15-36-40.log.gpx
Charl,
sorry to hear about your crash, but be aware that we are testing beta RCs. Could you upload the .bin or .log file?
Sorry load wrong file before.
here we go.
2014-10-21 15-36-40.log
Charl,
Sorry for your crash. The climb is caused by extremely high vibration levels on the z-axis. The only way to recover in this case would have been to return to a manually controlled throttle (i.e. stabilize). I think it would have acted the same under AC3.1.5 or AC3.2.
It would have been possible to shake the landing detector out of this mistake by raising the throttle above 60%.
Jonathan and I had a long talk about what we can do about this and came to the conclusion that for AC3.2 the best we can do is add an additional barometer check to the landing detector. For AC3.3 the EKF will be on by default and it deals better with vibration and in fact, in this case, it knew that the vehicle was falling and thus the false-positive wouldn't have happened. The EKF is still pretty new though so we can't recommend to everyone to start using it yet.
Again, sorry for your crash. We will add a baro check to the landing detector and I guess you can look into the vehicle's vibration levels.. or maybe your next vehicle's vibration levels. :-(
Hi,
I'm trying to manually deploy a parachute with Ch8 to test it before takeoffCHUTE_ALT_MIN is set to zeroBut I get a message "Parachute: Too Low"
If you dont arm the copter or the copter think it is landed, parachute will not release and message is "too low". Try arming the copter and raise it a bit if your baro drifts
Thanks Manu
According to http://copter.ardupilot.com/wiki/parachute/ I thought that the only condition for manually deploy is CHUTE_ALT_MIN, and set it to zero is to disable CHUTE_ALT_MIN, so I shouldn't get the message "Too Low".
Stephane,
Perhaps we could change the warning message but in any case it will also display "Too Low" if it thinks it's landed no matter what the chute-alt-min is set to. I.e. you can't deploy the parachute while the vehicle thinks it's landed. I guess it makes tests a bit difficult but on the other hand it's a decent safety feature.
-
95
-
96
-
97
-
98
-
99
of 373 Next