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
You're right, sometimes it flips!
I had to deal with that issue and made a smoothed stick command to avoid it with hybrid, even with previous 3.1.5 FW. Anyways, the smoothed command is not perfect and we have those flips even in hybrid mode.
The right and more general solution would be actually to review the way rate_bf_target.x & y are computed/limited as you suggest.
Reduce roll and pitch P terms proportionnally to the copter speed in roll & pitch axis to avoid a sudden flip back could be a solution but we should not reduce too much to remain responsive enough. Maybe act on the angle_rate_rp_max limits...
Anyways, this stability issue is there because the tuning of the stab parameters is made more or less loitering with no velocity and with a hovering throttle, this is not a constant state when you fly, you move and change the motors thrust!
I thought of a whole stability patch that would adapt all the PID terms related to the copter thrust and velocities because external forces and motors forces are not constant. So the PID terms should not be constant if we want a constant good behaviour.
That's a lot of work with no time right now for me... but probably someone could work on it.
Maybe It is better to make the way (MP parameters) do turn breaking (for AltHold mode) OFF or set it's softness ? Sharp breaking is not good for any mode.
AC3.1.5 breaking is much better...
hi,
maybe RC3 has an issue and ANGLE_MAX parameter has been ignored during breaking.
I've flipped in windy conditions MANY times.. I'm always astounded how easily it happens... :/
Flip is normal, but flip when I just release the roll/pitch stick to 0 is not normal ! AltHold breaking at AC3.2rc3 is too sharp. At hight speed it makes too big first turn to break the copter. At low speed AltHold breaking is normal. How can I make It softer like at AC3.1.5 ?
Same issue here. Not flips but my quad goes completely vertical when letting go of stick in medium/fast flight. Dropping the Stab Roll and Pitch P by 20% has helped greatly. 3.1.5 and previous releases did not behave like this.
I may be on to something here. After reading up on the Alt Hold wiki page, it indicated that powerful machines may benifit from lowering THR_ACCEL_P & THR_ACCEL_I. I reduced mine by 20% (.600 & 1.200). Just finished my third flight and it seems to have a big difference all around. I don't experience near the 'kick-back' and I'm able to add back the 20% to the Stab Roll/Pitch P I removed in the above post.
Randy, maybe is there some issue at AC3.2 that makes us to lowering PID to fix Overshoot (breaking) problem ?
Why do this Overshoot problem exists ?
Thanks Micheal, I will try It when I'll get home in a 10 days.
Leonid,
My guess is that it's because AC3.2-rc3 has "feedforward" enabled which makes it more responsive but it can overshoot if the PIDs are too high. I think for AC3.2-rc4 we will turn off the feedforward and the acceleration limiting by default.
Thanks Randy. Please tell me more about feedforward. What does it mean?
-
287
-
288
-
289
-
290
-
291
of 373 Next