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
Brandon,
If you're using a 3DR external GPS and compass module then there should be no need to modify the orientation and I'd guess that the differences are caused by bad offsets (something metal near the compasses?).
If it's not a 3DR GPS then yes, the orientation could be wrong. The external compass wiki page has some advice on how to figure out the orientation. i haven't tried this myself but it says the following:
Esteban,
So I guess the NEO-6M GPS/Compass is not from 3DR? If it's non-3dr I really don't know what's it's orientation should be but the above procedure could be used to figure it out. My guess is that if the manufacturer intended for it to be used with ArduCopter then they've made the orientation the same as the 3dr one but I really don't know.
Had three flights flights today: first one seemed totally fine. Last two ended in nasty crashes.
So at the start of my second flight, I rose up a bit and switched into Loiter and it started to slowly toilet bowl, and then it got worse and worse and worse. Hindsight being what it is, I should have put it into Stabilize, I tried RTL but that did nothing. I really had no control over it and it started moving faster and faster in a circular motion and eventually crashed very hard. Broke all props, gps mast and some other things got roughed up a bit.
So after taking it back home, fixing it up a bit, I replaced the gps mast and GPS (first flights had the m8, but after that I went back to the standard 3DR 6H gps). It seemed like I fixed it up ok so I took it back out. Before I flew it, I calibrated everything again, mainly to account for the change in GPS. Took it up in the air and it seemed to fly fine. Put it in loiter, and it didn't move much other than some bobbing up and down (which it was doing previously anyway). So then I tried to switch on EKF (i have it setup on ch. 8) and as soon as I flipped it on, it absolutely DOVE straight into the ground. Never seen anything like that. EKF always worked fine before. Broke more props and another GPS mast.. yay..
I have no clue what's going on, but these two crashes are the first two that I have had that weren't caused by obvious pilot error. They may have nothing to do 3.2 (I believe I'm running rc11), but I honestly don't know. I would love it if someone could check the logs and let me know what they find.
Thanks in advance.
156.BIN
158.BIN
Re "So at the start of my second flight, I rose up a bit and switched into Loiter and it started to slowly toilet bowl, and then it got worse and worse and worse. Hindsight being what it is, I should have put it into Stabilize, I tried RTL but that did nothing. I really had no control over it and it started moving faster and faster in a circular motion and eventually crashed very hard. Broke all props, gps mast and some other things got roughed up a bit. "
That sounds EXACTLY what happened to me except my quad was never found. It started to toilet bowl and I basically lost full input control. I could effect it's flight somewhat but it would not fly in a straight line no matter what I did. I did switch to stabilize as a last ditch effort but by then it was so far away I could never establish orientation before it flew out of sight. I was flying with a M8gps. Im not flying with anything but a 3dr ublox until I know better.
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.
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.
-
83
-
84
-
85
-
86
-
87
of 262 Next