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
Hi,
could anybody figure out what causes our issue?
that would be great if I could use auto mode and continue testing… :(
regards
Adrian
Hi,
I made several test flights, the issue is always the same… :(
Any ideas how to solve?
BR
Adrian
now I know what feels wrong with the Drift mode...(in my opinion) it should be executed with the yaw stick not the roll stick.. its not natural to yaw with the roll stick and that makes you feel like you will crash any moment because you have no control on yaw after you slow down. if you hover it should yaw with the yaw stick and even in fast moving you should still have a bit control on yaw if needed, but thats only my 2cents.
was thinking similarly... if the yaw stick acted like a rudder, it (drift) would be perfect.
How do you people calibrate your accel sensor??!!its almost impossible to do it properly...no way when you place your multi on legs,no legs are exactly the same...ok,i know,you can level by putting something equal size under arms but what about when you press Pixhawk and antivibration pads are not leveled any more when you release it...did any of you use leveler and check?no way you can place leveler on Pixhavk bcs of all stupid connectors on the top!
Another issue is putting your props in the same level with controller on a round carbon tubes...i put safety screw thru clamps,but still,if you hit something with arms and props its not leveled any more....but that's my problem when I deceide to use carbon round tubes instead of squere ones...
well you need to level your frame not your board, so all those connectors dont really matter :)
No,point is,your board have to be leveled with your frame!how else?????
no i dont think it does. in fact its not even possible with the flexi foam mounts etc.
the level function exists to counteract small differences between the board level point and the frame level point - you level the frame, not the board. the frame is the flying object.
I cannot agree with you....and I think its a bad practice not to level board with frame....I might be wrong ofcourse...thx for answer anyway..
Emin,
You level the frame. The whole point of the leveling exercise is to tell the flight controller when the frame is level. Ideally the board and frame are very close