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)

Views: 305487

Reply to This

Replies to This Discussion

Thats disappointing News. i thought the request to make it like NAZA was set in stone (ITEM #6). i, for one, was looking forward to that type of Control out of APM. if this is the case i may have to reconsider my Flight controller needs. :(

Yes, the APM is in its case with the foam on the barometer but i can imagine that a closed frame like the DJI has a more precise baro reading. A V shaped frame is always a bit tricky anyway and it is a fast quad so that may be the reason. Tomorrow i will try to fine tune alt hold some more and see if there is an improvement.

About the hybrid loiter issue, I've found something in the WPNav and PosControl files related to new init_xy_controller function.

I'll inform Randy to try the fix and let you know once ready.

Don't be so disapointed, that's just a rc-1, not the final 3.2.

If you tune alt_hold to be more reactive, that will increase the altitude drop.

I tryed a manual fix (with potientiometer on my alpha tests) that lowers baro effect during the phasis I knew it was disturbed.

Results were very good but that was probably not a global fix. My issue was due to baro, so I trusted more accelerometer values. People could have a better baro reading and disturbed acc (vibration) and then my fix would not apply (actually, that would be even worse).

So, yeah, try to deal with params but I fear that will always suffer from baro disturbances.

@Julien I will wait out this release, its one of the changes i really wanted. i hope i dont misunderstand ITEM #6 on the list. thanks for your response.

I had the same issue some time ago and I solved putting a piece of electrical tape over the Ardu pins that not in use (because if I blow there altitude changes with the copter on the floor not moving) and solved

Steve,

     No, sonar for Pixhawk is still not working with -rc1.  It won't be in -rc2 either I think but it will be in one of the release candidates before the final release.

We're going to need to temporarily take back the MP's Beta Firmwares link so that we can test a patch for the official release.  This patch will be called AC3.1.5-rc1.  This will take a few days and then we will put back either AC3.2-rc1 or maybe AC3.2-rc2.

By the way, the bug we found in AC3.1.4 (the current official release) is that the user's roll, pitch and yaw inputs are not ignored while landing after a radio failsafe (aka throttle failsafe).  Some transmitters send crazy roll and pitch inputs during a radio failsafe so this can lead to the vehicle speeding off as it descends.

Thanks.  I'll continue to play around with it.

NAZA has no phone support, needs an iPad for ground station or PC and no ROI on the NAZAv2 so Id much rather stick to the APM.  I think this is going to be a good release.

Julien, I think I may have seen something else :(

well I was in alt hold, barely touched the throttle and it shot up as if I were past mid point...complete surprise for me again :)

heres that log

Attachments:

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service