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
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....
Randy, Richard and Artem
I believe the altitude issue would be fairly simple to solve in 3.3. The craft piles up air molecules in front as the velocity increases so if it were to calculate the 3d velocity vector (or at least 2d .. x and y) to establish overall speed and then apply a new parameter (altitude_cor) and then apply the correction to the indicated altitude the issue could be solved. Tuning would be easy by setting up the parameter on channel 6 and dialing it in with a few high speed passes. Once a default value was established I'm pretty sure it would serve most craft without extra tuning.
Hi,
I am aware of that "issue" but this is something different... Normally it drift lower while in ALT HOLD when high pressure then goes slightly up... This is STRAIGHT UP at full juice. Its not like I started flying my quad differently, I have done alt hold as fast as possible for multiple runs even setting my max lean to 7000 compared to what I flew here at 45 and it wouldnt even go up like this... If I had a video I think you would rule that out as well. Unless recent changes are making this issue even worse... which I hope is not the case.
Edit: I do have more vibrations in this frame ATM because I am just using some bad props until I get all the kinks worked out but I have flown with multiple "bent" props before and these with no issue like this.
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.
Thank you, that does point to the vibes causing this... Tomorrow I am going to first, repeat it, then try to repeat with EKF, put on some new props and test again. I would have thought that the code would compare the board alt VS baro and GPS,, then this problem would not happen... Maybe that's what ekf does? (i am not familiar on the HOW this works as you can tell!)
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.
Log..
2014-10-06 14-20-39.log
i'm a good step further concerning the issues i was having on the hexa :
Inacurate Autotune
autotune in AC3.2 seems to be more sensible to wind and other factors which may influence the calibration. Also an accurate RC/ESC calibration seems to be important.
I've done some test with no wind and was having good results, the STB R/P seems to be much lower.
Crash while Flip in Acro
I've done some tests and noticed that flips/rolls as such is not the problem, but if they are combined to fast flip and roll there seems to be a small stabilsation lose issue.
smaller things i noticed
1. Droidplanner : touching a screen position starts the guided mode but the drone does not fly to the position, starting from second input all is fine
From my point of view AC3.2. seems to work, althold is pretty good, compassmot is working amazing. Also Acro mode seems to be improved. To test all the new features i'll need much more time ....
-
135
-
136
-
137
-
138
-
139
of 373 Next