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
Richard,
Was you M8gps a M8Q unit? I have one but there is no compass associated with it. I also have it as a backup to my LEA-6H. Based on what I've read above, it sounds as if you used your M8 as a single/primary gps unit. So my question now is, was the toilet bowl caused by the gps or the compass?
The GPS/Compass I was using at the time of the first big toilet-bowling crash as the M8 gps from Virtual Robotix. It does have the compass built in and was basically plug-and-play (except for needing a compass recalibration of course). I'm back to the stock 3DR external gps/compass now (as seen in pic, but the VR gps I was using was mounted in the same fashion).
Normally I do perform the compassmot calibration, but I can't recall specifically if I did it the last time I installed a software update. Will definitely be more vigilant about it now. Maybe Randy or someone else can say whether it was caused by GPS or compass.
I too was using the M8 gps [ and compass ] from Virtual Robotics when my copter toilet bowled to the extent I was not able to regain control and it flew away. However... there is no way I will ever know if it was a hardware issue, firmware issue, or mechanical issue as I never located the copter so any chance of evaluating the log is gone. I was flying with checks off as my offsets where -250 ish as I recall and could not arm with cheeks on. I'll never know but I have a hunch the compass was the issue and unfortunately the firmware was not able to use the back-up on board compass as a back up. That's just a guess.
I have another VR M8 on the way I will be installing it on my new 'test quad' with another Pixhawk to see if I can duplicate the problem. I've been flying the test quad with the pixhawk and 3DR GPS with zero issues so far. All flights have been with EKF on.
:(
Hope you now use a gps tracker.
I got a TK102 which saved me hours or days of searching after crashing into a forest over a mile away on a mission where I underestimated the altitude owing to google earth's low spatial resolution.
50g extra weight is a small price to pay for piece of mind.
ps it was 3.2 RC10
Toilet bowling is caused by a difference between the compass heading and the motion direction calculated from GPS motion.
If you have toilet bowling, the compass reading is a problem. If you change compasses, it is vital that you do a calibration. The compass has to be calibrated to minimize the difference between the GPS motion direction and the magnetic heading calculated by the compass. If your M8 does not have a compass, the Pixhawk will use its internal compass which generally has really high offsets.
Also be aware that some compasses from clone vendors (whitespy) are oriented upside down compared to the 3DR compass... this means that the orientation has to be 180 for that one...
Bottom line, the compass has to indicate the correct direction within a fairly small margin... you can see this on mission planner... The craft heading should match landmarks on display... if it is off by more than ~15 degrees you will have toilet bowling. The bigger the miss match in heading, the worse the toilet bowling.
Richard,
Toiletbowling is caused by the vehicle having an incorrect heading so as it leans to try and correct a position error, it keeps missing it and this leads to circling. The circles can get larger or smaller depending upon how bad the heading is. If the heading is off by less than 45deg they'll generally get smaller, but if it's more than 45 they'll get larger.In these situations, it's normally not possible to succesfully take control while in Loiter mode because in Loiter mode the pilot is really pushing around a target position which the autopilot then tries to fly to. Really the pilot must retake control in a more manual mode like AltHold or Stabilize. PosHold mode may also work but I wouldn't recommend trying because the pilot would have to keep inputting roll and pitch commands to keep the autopilot from trying to control the horizontal position.
By the way, here's a video of toiletbowling taken when the phenomenon was first noticed with AC3.0.
Kristian,
Could you include the log of your good flight as well?
In the 156 flight, It looks like the vehicle's heading estimate is off which is leading to the toilet bowling. I think this because the EKF and DCM disagree about the heading by 50~60deg.
It's slightly unclear to me whether it's the compass calibration (ie.. offsets) that are bad or the gyro bias. Hopefully by looking at your good-flight's logs we can tell.
By all means. Here's the previous flight (literally minutes before on another battery pack) which didn't seem to have any issues, that I could tell at least.
155.BIN
Kristian,
Sorry for all the posts but Tridge and I reviewed the 158 log in which the vehicle crashed just as the EKF was engaged. We found a bug that could cause invalid (incredibly large) positions and velocities to come out of the EKF for the first loop that it's engaged. We've got a couple of fixes that we will release with AC3.2-rc12 tomorrow. I've updated the warnings in the main part of this discussion to warn people about switching the EKF on and off with the ch7/ch8 switch.
It's a bit hard to directly tie this to your crash but expect and kinda hope that it is.
Really sorry about your crash.
-
127
-
128
-
129
-
130
-
131
of 373 Next