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,
Thanks for looking at my log and confirming the land bug. I really appreciate your and other devs hard work on this project
If somebody could look at this log I'd appreciate it.
First flight at higher altitude and speed with 3.2 rc6.
In pos hold, after a faster speed, it wigged out and tried flying off in all directions which was hard correct until I realized I should simply switch back to stabilize so there was no gps position input. After that it was fine. Not sure if it was the 3.2 rc6 or if it was the new ublox 6M gps I installed earlier that day. It had been working fine at low speed in my yard. The gps is mounted closer to the pixhawk than my previous installations but it seemed fine i.e. the compass heading did not change with throttle. However maybe that had something to do with it?? I do have checks off and I recalibrate several times... also rebooted but it still won't arm with checks on. Here's the log.... I think it's the right one.
wildpitchroll.bin
Richard,
My guess is the wild roll/pitch is because the GPS position is not great. I haven't exactly followed it through completely but just from looking at the HDOP (always above 2.0) and NumSats (always 8 or lower), I'm not surprised that it's not holding position well. The vehicle control (desired roll/pitch vs actual) generally seems ok.
The barometer glitch detection (i.e. BARO-2 error message) kicks in for a short moment. It's unclear what causes it exactly but it may be caused by a change in the copter's roll angle. I don't think this is the cause of any roll or pitch angles wildness though.
Those arming checks are there for a reason so we don't recommend turning them all off. It's much better to figure out why it's blocking the takeoff and fix the cause. Worst case just disable the specific check so other checks remain in place. Any chance you remember what the message was? It should appear on the HDOP.
Please please upgrade to -rc7 which includes the false-positive-landing-check fix!!
Thanks Randy.
Yes I am not impressed with my new M7 gps. I don't think it's the proximity to electronics but I now know I need to figure that out.... thank you. Looks like the not so great flight was not 3.2 so that's a good thing!
I do however still have that darn 'calibrate compass' issue. I have installed rc7 and calibrated several times with several re-boots so I'm at a loss. Here's a real small log.
14-09-07_20-49-12.bin
@ Richard Kennedy: Instead of the M7 I would highly recommend this one: NEO-M8N with HMC5983 compass Getting results so good with it, incredible!
Cheers
Re calibrated seems fine now.
it seems to be an issue with the BARO-2 like it was on mine.
Mine maintained altitude not bad it was just leaning over bad at neutral stick.
Today i went out for more test results and i was having a really bad crash during acro flight.
In this figure i'm flighing upwards to about 100m then i flip over to upsidedown by roll movement 180° and then back to normal by pitch movement 180°. We could say this is the short way to turn direction homewards ;)
Anyway after the first roll movement to upsidedown the Hexa ticket out an begun to circle like crazy and i could not gain back control. After that the hexa was falling like as stone from about 100m to ground.I've attached the logfile it seeems to be a BARO-2 issue ?
The flight started with some great flips this is all normal stuff no bug, you need to take a look at the end of the file.
2014-09-06 15-48-46.log
Pomaroli,
Thanks very much for the report and sorry about your crash, it looks like it was quite brutal.
The full list of sounds the Pixhawk makes are on this wiki page. Maybe you heard the GPS Glitch or Baro Glitch warning? This would make perfect sense if the vehicle was upside down but neither should affect ACRO.
It looks mostly like a mechanical failure although it's hard to be 100% sure because we've made some significant changes to ACRO since AC3.1.5 and the RCOUT logging is missing so we can't see exactly what's being sent to the ESCs.
What we can see is that for the first part of the log where it's doing lots of rolls there are no problems. Then when the vehicle attempts a backflip it loses yaw and pitch control. We see the desired pitch and yaw angles are being dragged around by the actual (this is normal when the vehicle can't control it's attitude).
After you switch to stabilize mode it doesn't recover which makes me think it's a mechical issue but it's hard to be completely sure. It's somewhat suspicious because it completes about 14 rolls but then crash on it's first flip.
I've repeated the maneuver in the simulator and it's executed without any problems. I'll investigate with more bench tests to see if there's anyway to make the code fail in this circumstance.
By the way, there's a fence breach error at the beginning as it flies above 150m but nothing happens because the fence-action is set to zero. I suspect this is how you wanted it but just FYI.