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
Maybe it's an unimaginative question, but when ends the 3.2 betastatus?
Greetz Chris
My two friends got radom crash with latest AC 3.2 rc9 due to bad GPS condition. After 25 sec of flying HDOP increased from 1.5 to 7 several times! Then he lost throttle response and finally crashed. Original 3DR Lea-6H.
LOG: https://db.tt/NASeXzyK
Video: https://www.youtube.com/watch?v=-YpNyWtYa0M
Someone got this problem too: https://groups.google.com/forum/#!topic/drones-discuss/iZmeopHOLGM
Shagge, not sure why this crash happened. However, after building and flying several APM/Pixhawk based Hexes and Quads over the past couple of years I am astonished and, to be blunt, horrified to learn via the Google Groups link you provide that Stabilize mode has a GPS component! And worse yet that it can't be turned off!
All this time, whenever I have been in GPS-based modes (Loiter, Position Hold/Hybrid, RTL, etc.), especially here in our tree and hill infested topography, I have "bailed out" whenever GPS gets squirrely by switching into Stabilize, with the presumption that I'm no longer involved with all the glitches, multipathing errors, etc. etc. that are an all too common part of the GPS environment. I always take off and land in Stabilize, and I never fly below about five meters AGL or so in anything but Stabilize. The last thing I want or need is an unreliable and ultimately unpredictable outside influence on the FC during these critical flight phases.
Perhaps having a GPS assist in Stabilize mode is a useful protection for some people, especially those who cannot yet call themselves "pilots," but for the rest of us it simply MUST be arranged so it can be turned off! I now must wonder how many of the dozens and dozens of unexplained crashes, especially flip-overs and tip-overs, reported in these pages were in fact due to erroneous GPS intervention during Stabilize Mode operations.
We all know that GPS reliability is the elephant in the room of autonomous and semi-autonomos flight. Why would be want to fall back onto a backup system that uses the exact same thing?
It appear that I am not the only experienced APM pilot who knew nothing of the existence of this "feature" and is now concerned about this threat to his aircraft. I must also wonder about the thinking behind this. A safety feature that by its fundamental nature will itself cause crashes is something that we should be able to individually decide if and when to use. To impose something like this, especially without saying much if anything about it, is IMHO ill-advised at best and dangerous at worst.
I've created a short video showing the impact of the GPS velocities on the attitude estimate (with DCM) including how to turn off the correction completely if you so wish (in-short you can set the AHRS_GPS_USE parameter to zero). As you'll see in the video, the impact is quite subtle.
Chim,
I hear what you're saying and we (me perhaps most of all) want the flight controller software to be reliable. In this case there is no reason for panic though. Before we have a crisis of confidence, let’s remember that:
It's likely that the centrifugal correction (based on GPS) can be disabled by setting the AHRS_GPS_USE or AHRS_GPS_GAIN parameters to 0 but before we do that's let us do some proper testing of the maximum angular disturbance that can actually be caused by a GPS glitch.
Let's not jump to the conclusion that this issue is causing fly-aways or crashes until we actually see one (with DCM). In my considerable experience the main causes of crashes are compass issues or mechanical failures. When there are "unexplained crashes" it's normally because there aren't enough people with deep understanding of log file analysis to provide the pilot with the answer.
I just read through the developer comments on Google Groups...This is a problem... when I switch to stabilize or fly indoors in stabilize, I am expecting...actually betting my well being and those around me that the GPS is going to be ignored... After investing thousands of hours and dollars in this FC, I am really taken back by this.
It is simply dangerous to to take GPS into account in any way when in stabilize in many circumstances.
Lastly, the reasoning for using the GPS in stabilize seem weak at best. There are dozens of competing FC's that fly perfectly well in stabilize without a GPS at all...
Dev's Please make the change to remove GPS from stabilize.
Steve
Scratch that, it is looked at in DCM too but only relied on if the GPS is reporting a 3D lock. I'll hush up now :)
Ekf offers value for gps modes.... but it is not switchable on and off by mode it is on or off for all modes.... it would be a bad outcome if a user were to be forced to decide between using ekf in any mode and the safety of turning off gps in stabilize.
I believe this is only the case when using the EKF, but I am not 100% positive on that. For now, if you leave it disabled, you should be ok.
Shaggee,
There is a very large motor imbalance between the clockwise and counter-clockwise motors. The ch1 motor (front right) is at full speed for much of the flight. An imbalance of perhaps 100 between CW and CCW is ok, but the imbalance here is a bit over 300 between the farthest apart motors (#1:front-right is very high while #4:back-right is very low).
By the end of the logs (perhaps as the battery weakens) two motors are nearly pegged to the top of the range while the other two are alternating hitting the bottom of the range. I think the vehicle simply cannot maintain it's attitude anymore and comes down.
-
179
-
180
-
181
-
182
-
183
of 373 Next