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
Phil,
Thanks for the additional log from the previous (good) flight. This one shows the actual velocity tracking the desired velocity very well while the bad log shows the heading is out by about 180degrees.
I really cannot explain why the compass is giving such a bad heading on the later flight. I've compared all the parameters and there's no clear cause. The offsets are a little different but not enough to explain the issue.
The compass is returning values meaning that it's probably healthy. There are no I2C errors reported.
I'll escalate this to the other developers and see if anyone can spot something that I may have missed.
Phill,
It looks pretty under control in terms of roll, pitch and yaw angle. This means the copter was tuned well and there was no radio failure.
I'm a little disappointed that our various compass checks could not catch the problem before take-off. It looks like the external compass was attached and it's initial heading was consistent with the internal compass. During flight they diverged quite a bit making me think that the internal compass has a lot of interference or it's offsets were quite bad. Still, the internal compass is only used as a reference so it's the external compass's heading that must have been bad.
Do you have any dataflash logs from successful flights with -rc9 or earlier versions?
My condolences!!!!!! Thanks for giving it up for the team so to speak.
Yes, looks like bad vibration levels. The latest Beta mission planner includes an updated automated log analyser and it includes an IMU consistency check and it's complaining as well that there's a vibration or accel calibration issue.
Plotting the Baro Alt vs Inertial Nav alt shows they're completely different which is also normal a sign of bad vibration but can be caused by the aerodynamic effect as well although normally the aerodynamic effect is only a meter or two while in this case there are differences of up to 20m so I suspect it's the vibes.
As you say, the GPS is having a lot of problems and FPV equipment is a very common cause. I suspect you can do a bench test where you plug in the FPV and check it's effect on the GPS hdop. We don't use the GPS altitude so I susepct the two problems are unrelated.
this is a known AC issue which is related to the aerodynamic effects of the fast forward flight. been there since I started using AC 2.9x or something, also gets worse with high vibration levels on the vertical axis. One thing though, why on the earth does the copter loose altitude when going one direction, but not the opposite? Fixing this would be a huge achievement for the community as even the simplest NAZA in ATTI mode will maintain its altitude no matter how fast you go. I tried multiple things, such as reducing vibrations to +/-1 putting apm in an airtight container with only one little hole in the bottom for wires and covering it with foam and tape with not much effect, still the copter would loose altitude if pushed beyond ~1500cm/s. For comparison taking NAZA M Lite from my cousin's phantom performed flawlessly on the same platform without any extra measures, just a dollar store double sided foam tape. I only hope this is a thing to accomplish for the 3.3 release.
I agree I drove myself nuts with this 'issue'. It is interesting it seems solved in Naza. I tried a snorkle aimed forward or backwards. Nothing seemed to work. Perhaps the Naza uses more gps / terrain info. But I guess this would be another thread.
my wild guess is that during forward flight naza applies a filter proportionally to a copter's speed. like they either did some extensive experiments to figure out how density of air changes with the respect to the air speed, or may be they emulated this data? or it is something totally different....
Oh, I see. than most likely, and if someone knows better plz correct me, during high rpm associated with the aggressive flying vibes go up and this is definatelly capable messing up with INAV and EKF. looking at your logs I see substantial difference between baroAlt and the inavAlt, where baro shoots high up inav alt registers a relatively small ascend. this is especially evident in the line 37-38(10^3) just right after Z axis acc registers -20 to + 12 vibration levels, while acceptable is -15 to -5. I think vibrations are the cause of those jumps and again if someone knows better I am happy to be corrected.
The EKF is much more robust as it leverages multiple sensors (baro and GPS for altitude for example) and it much more immune to sensor glitches, failures, and vibration. I highly recommend using it.
Pomaroli,
Thanks for your testing.
I can't help much with the DroidPlanner issues but feel free to post over on the Droid Planner issues list.
-
89
-
90
-
91
-
92
-
93
of 262 Next