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
Randy,
I made some initial tests on a slightly different copter/frame with rc10 and tested two RTL landings. The first landing was perfect but the second ended in some longer wobble before it finally disarmed. I guess the problem was that the ground was not perfectly level.
Attached you find the log.
Best regards,
Thorsten
rc10_landing_wobble.bin
Thorsten,
Looks like it sat on the ground there for 7.3 seconds before it registered the landing. It got close to recognising it 3 times during that 7 seconds but the overall throttle was bumping up and down around 25% and this was throwing it off. The first landing, as you said, went much better with it registering the land in just over 1 second which is about as fast as it can ever be. It's certainly the overall throttle level that is causing the land check to not see the landing.. on the first landing it very quickly got the throttle down to about 15% while on the 2nd one it got stuck up at about 25%. It's not immediately clear to me why there's such a difference... but I suspect you're right that it's he slight lean of the vehicle that it's fighting against while landing. This could be keeping the throttle a bit high as it prioritises attitude over throttle.
Thanks for the log.
Randy,
I missed your reply. Thanks!
I made serval landings since then and everything worked fine. But all were on level ground. So in most cases it should work as expected - especially since no one else reported a problem. I'll make some tests next week trying to reproduce the effect.
Thorsten,
Sorry, I didn't get a chance to review your log today but I'll get to it tomorrow.
It appears that -rc11 is just a bit too big for the APM1 (on any frame type) and on the APM2, the TradHeli code isn't quite fitting. I'll sort this out over the next day or so. This doesn't affect the vast majority of users.
CPU load going crazy >2500% in mission planner and APM planner.
with firmware 3.2rc10 and 3.2rc11, if i disconnect GPS it goes down to around 15-20%
video on bench
Hardware : Pixhawk and 3DR GPS v2 nothing else connected
dataflash from outside test & setup
2014-10-05 13-43-52.bin
anyone that can tell me whats is wrong here, ????
2014-10-05 13-40-12.tlog
Richard,
So that's a graph of CPU load. It's true it's a little weird looking, when I look at my MP's Flight Data >> Tuning screen I see a more level 20% with no jumps back to zero. I wouldn't worry too much about it though if you're not seeing any other issues.
hi Randy
The top value is >25000, low value : 270 - 439 and this is divide by 10 ??
@param load Maximum usage in percent of the mainloop time, (0%: 0, 100%: 1000) should be always below 1000
https://github.com/diydrones/ardupilot/blob/master/libraries/GCS_MA...
This tlog has same value http://diydrones.com/xn/detail/705844:Comment:1797157
Thx anyway, i will wait for 3.2 final, can't test fly now, bad weather next few days
video link FIX
-
90
-
91
-
92
-
93
-
94
of 262 Next