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
@Para in Andropilot? I clicked Follow me, it used to switch to guided mode but didnt. so then i manually switched to guided mode on the tablet and it still didnt do anything. for Drodplanner i had teh wrong beta version so i cant test the new beta until monday or so but inn the video yes i was in guided mode for driodplanner
I have Guided as one of my 6 flight modes. I select it on my TX then grab the tablet and hit Follow. Last I played with it was in July and it kinda' worked.
There's some behaviour I don't like. It won't hold the altitude you start with. It will climb or descend to the default navigation altitude you've set for Auto missions. It won't keep the distance to the tablet when you stop. The copter comes right above it. And course changes (yaw) are pretty sudden and violent on an otherwise smooth-flying machine.
It probably amounts to the Android device quality, accuracy of its GPS, processing speed, etc...
Thanks for confirmation Thor !
In MP under 'Mandatory Hardware' then 'FailSafe' I set "FailSafe Options" back to 'Disabled' and the messages seemed to go away.
Then to see if I could duplicate the issue, I tried turning 'FailSafe Optinos' back to "Enabled always RTL" (which I had it previously set to) and now I don't seem to get these errors.
I was also playing with "AHRS_EKF_USE" enabled and disabled. It didn't seem to affect this, but I did notice that "EKF_CHECK_THRI" (?? maybe it should read "EKF_CHECK_THRESH" ?) was blank, so I set it to "Default". I'm not sure why it was previously blank, as I had previously issued a factory data reset in terminal.
I'm now totally confused.
Rich,
Thanks for the report.
The EKF_CHECK_THRESH not appearing as the default in the drop-down in mission planner is because I forgot to update the parameter descriptions when I increased the default. This patch will fix it but it may take some time for the mission planner to pick it up. It doesn't matter unless you set the AHRS_EKF_USE to "1" in any case. If you do plan to enable the EKF, I'd recommend checking that EKF_CHECK_THRESH is set to 0.8.
The FS_THR_VALUE pre-arm check is #11 on the pre-arm check wiki page. The RC3_MIN must be at least 10 pwm lower than FS_THR_VALUE. If they are too close then it's possible that just pulling your throttle to minimum could trigger the failsafe. This pre-arm check is making sure the params are set so that doesn't happen. My guess is that the failsafe in the tx/rx isn't setup so that the throttle is pulled very low or the FS_THR_VALUE is set too high or the radio calibration hasn't been done in a while and the RC3_MIN value it has currently is inaccurate.
Hope that helps.
Randy,
Ok, as you will see by my other post, setting FS_THR_VALUE to be 11 lower than RC3_MIN, I was able to ge rid of the 'check FS_THR_VALUE' messages. thanks. Please also see that post for an improvement suggestion.As you suggested, I also changed EKF_CHECK_THRESH to be 0.8.
But now, sitting on my desk, I can ARM, but I can't DISARM using my radio.
If I push my rudder stick hard right with throttle down, the PixHawk will ARM.
But then if I hold the throttle down and push the rudder to the right, I can't get the PixHawk to Disarm. The only way to get it to disarm is to hold the thottle all the way down and wait, after some time it disarms itself.
Am I doing something wrong now?
I don't remember this type of action before updating to RC9.
Isn't it down and to the left to disarm?
did they change something or is my memory going! LOL
I could have sworn that I use down to the right to ARM or to DISARM before RC9.
But trying it to the left, does seem to disarm it right away. Thanks!
I had a weird issue with FS_THR_VALUE as well (in -rc7:n if I remember correctly).
When I set the Throttle failsafe value to too low (around 970) I got this error. I got rid of it, when I increased failsafe value to 985. (My actual link-loss failsafe PWM is 982) Normal throttle range is calibrated and working fine: 1000-2000PWM.
Didn't make any sense at all. On earlier setups and older software versions I could set failsafe value to 920 or 910 without any problems, now I can't get below 980....
Pekka,
There haven't been any changes in this particular part of the code (as compared with AC3.1.5). There is a minimum acceptable value on the FS_THR_VALUE but it's really low. It's not allowed to be less than 910.
-
198
-
199
-
200
-
201
-
202
of 373 Next