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
When I get home this evening, I will post another tlog and bin file. Last evenings flight showed that the NEO-7M had synch'd up almost immediately and very close (almost dead on) to the LEA-6H GPS. So maybe it's just taking a bit of time to resolve and store satellite information in it's memory. I also noted that a few days ago when I flew and upload logs that the K-Index was at 4 (yellow) for GPS intereference but yesterday is maintained 2 (green) throughout the day. So it's possible that the NEO-7M is a little more susceptible to GPS intereference. I will log more flights and testing to narrow down the differences of flights.
Thanks Randy. I'm now planning in acquiring the UBLOX M8 GPS unit that Marco recommended last week for comparison.
Just had an unexplained crash while flying with -rc6 on my pixhawk quad. I had two successful flights before hand with everything behaving great. Then just over 4 minutes into my 3rd flight while in poshold my copter appeared to cut the throttle and tumble out of the sky onto the pavement. I wasn't very high so had no chance of recovery but still did plenty of damage to my quad.
I'd be grateful if someone could look at my dataflash log and tell me what went wrong.
Thanks,
Fran
2014-09-03 19-25-01.bin
I'm really sorry about your crash. As Julien says, it's the false positive on the landing detector.
In case it's any consolation, I've reviewed the last second before the false positive and the two new checks in -rc7 would have easily caught that the vehicle was not landed and this would not have happened. In the last 3 columns we have the major checks (there's also a motor limits check but this is not logged). The "Gyro" column shows the vehicle was consistently rotating at about 1.5 radians/sec (ie. 90deg/sec), far higher than the 30deg/sec landing check. Also the ThrOut was averaging 406 (i.e. 40%) which is far higher than the 25% the new landing check requires.
Thanks Randy glad to know your fix would have caught this.
Is there any option to turn off the auto land detection? After this crash I'm still a bit nervous that the copter can just decide to cut its power mid air, all be it that much harder now with your fix.
You guys are doing great work and you efforts and support are very much appreciated.
Francis,
I know what you mean, Marco's asked for something similar. Certainly it's very unnerving to think there's a little elf in there making decisions on his own about whether to kill the motors or not.
Currently, there's no way to turn it off. We could add yet another check that the pilot's throttle is at minimum...we just need to be careful that there's no counter cases.. for example people landing slowly in loiter.. if they left their throttle above zero the vehicle would still try to do horizontal position hold until they brought the throttle all the way down so their vehicle might flip over...
I think it's definitely something that should be considered and discussed to have an option to disable it (for certain modes at least) and/or add a user throttle check. I think most people should be dropping their throttle when they've touched down.
For me personally I'd prefer to risk my copter tipping over when on the ground over it falling out of the sky.
I actually had at least two instances of my copter not automatically disarming on the ground with v3.1.5 where it did appear to throttle up and flip over. I guess this is why things were relaxed initially for v3.2? I had got into the habit of as soon as my copter touched down switching to stabilise and disarming to be on the safe side.
Such great work! I'm no dev, but I'm amazed of how committed you guys are to improving the code. Considering it's all free. Thank YOU Randy and devs! Any of you in Norway? I'm happy to get you a beer ;)
Francis,
You've got a fake land detector, Randy has just made a fix for it, that should be available with rc7.
Your copter thought it was landed and started falling down. When it retrieved the "not_landed" condition, that was too late... the time to stabilize its attitude and send full throttle to motor, the copter was already crashed.
Julien
@ Julien
How does one discern by looking at the logs wether a event was called for from the TX or if the event was simply recorded? Odd the way the log in APM P looks different. It looks like the alt was flat lined at zero then the land event.
JD.jpg
-
229
-
230
-
231
-
232
-
233
of 373 Next