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
Thx Marco,
So I guess it just needs a few seconds to normalize pressure before one does a new take off.
Question about position hold on V3.2rc12;
in several quads, when flying fast in POSHOLD and release the sticks, the quad slows down, tilts against the flight direction and stops. (basically this sould be th end of the stop) but it then tilts back in flight direction slightly, flys forward a bit more and comes to a complete stop.
which parameter would you tune in this case?
as mentioned it happens in 4-5 different local quads with different setups.
Same here, would also like to see ho to get rid of this.
It may happen if the quad it braking to hard, pitch overshooting if facing wind for example.
Normally, the POSHOLD gets its current position at the end of the braking phasis, mix brake and loiter commands during a while to avoid any twitch and then loiters at that initialized position.
So, maybe the GPS signal drifting a bit, or a strong wind that makes the copter overshoot...
If you could post a video + log, that would help
I did notice in POSHOLD with EKF in strong wind the following:
After a long (about 1 min) period holding position in strong continuous wind (Gusts 11-17kmh) all seemed good. Quad held position very well. In fact it seemed to hold within a 50cm square. Altitude was stable.
When the wind dropped it developed the need to move forward a quite a rate and continued to do so for a about 30 seconds. This may be due to me trying to manually hold position by pitching up (back) in an effort to keep it in one place. If I let it go (ie no pilot input) it moved forward at quite a speed.
Eventually it settled down and returned to normal behaviour. My only issue is that if I simply let it for it would have flown off a long way before it settled down. This might not be a problem and more tuning when the wind stops might fix this.
This seemed to be worse with Rate Feed Forward enabled and EKF MAG Learning on. I ran out of battery so I didn't get a chance to confirm that feed forward was the culprit.
Otherwise, all seems great with RC12 so far. No problems with STAB, ALTHOLD, POSHOLD, AUTO, LIOTER, TAKEOFF, LAND and DRIFT that a bit more tuning wont fix (I hope).
I have a large compass offset in the Z axis but this seems to have no real effect. Probably due to the camera being too close but as it is a small frame I don't have anywhere else to put it other than next to RF transmitters. I figured that it would be best to have a constant source of interference rather than one that varies..
Once again my TBS took a flip on auto take off in auto mode, broken 8 carbon fiber props so far :-(
Not sure if this has anything to do with it, but both times is when I was in the mountains, not in Florida where I live.
3.2 rc 12, APM 2.6, uBlox, TBS Disco Pro
Randy, everything looked good at take off according to Droid Planner, no clue why this keeps happening but I can no longer trust or use auto take off.
I was in the smokies hoping to make you a new spline video now I cant :-(
2014-10-19 10-17-54.log
Edgar,
Thanks for the report. It's looks very bug-like. In the logs we see the nav controller requesting a very large roll and pitch request as soon as it thinks it's taken off. There is this similar report in the issues list which seems to be the same thing. We will push this to the top of the to-do list and hopefully we can find and fix for -rc13 which will go out shortly.
Im not sure if this has anything to do with it, but the take off point was at a slight angle, about a 10 deg slope, with nose pointing in the upward direction, they are on a hill so its all I had.
Thanks, Ed,
Edgar,
I've tested leaning the vehicle during take-off (in the simulator) and it's uncovered another potential issue. The issue is that the lean angles of the vehicle are captured at the moment the vehicle is switched into AUTO mode. These lean angles are then loaded into the navigation controller so that when it takes off it will start by commanding these angles. This is probably not the best thing to do during take-off because we'd probably prefer the vehicle take-off straight up.
The effect is that when taking off from a hill, the vehicle will initially shoot out in the direction it's current lean points it. it will then likely snake it's way up to the target point.
In the simulator testing this doesn't lead to the vehicle flipping or leaning over at 45deg or anything though.
Edgar,
Ah, that could be important. I'll check that case.
I may have found and fixed the issue. At least in the simulator I could reproduce a rare case where the roll and pitch could go to maximum on AUTO takeoff due to a timing issue. It's very rare though as it relies on the clock ticking to the next millisecond just as the take-off happens.
-
102
-
103
-
104
-
105
-
106
of 373 Next