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)
What I do is to update to plane and them arducopter, when you change vehicle I understand that reset all.
Thanks guys. I considered doing this, but wasn't sure if it would work. I appreciate the validation!
FYI the external compass is working so the I2C splitter seems fine. If anybody had an easy way to test an external LED on the bench or something I'd at least know if it's just my end of is it 3.2 or something. Thx
I do like this to update to 3.2 rc10 and works for me
Thanks, I posted by request for the df logs actually just as you posted them so my response above was based on the info I pulled from the df binary file. I'm still pretty convinced that it's a mechanical issue. The changes between -rc5 and -rc10 are pretty much all bug fixes and landing-check improvements (to make it more strict) and for me, the most convincing bit of evidence is how it the pitch control degrades over the last minute before the crash.
One small thing I see in your logs, is that the Rate Roll/Pitch IMAX is still 500 but the new default is 1000. The higher number can help with persistent attitude errors like in your logs. This wouldn't save the vehicle from the crash though.
By the way, there's a video on this page which shows how to calibrate the current monitor.
I strongly suspect that a small amount of yaw input (from the pilot) has gotten through and has caused it to think that the pilot wants to take manual control of the yaw. Normally even after pilot input it will reset the yaw to point at the next waypoint just before it reaches the previous one.
It's a bit hard to conclusively prove this from the tlogs, if you have a dataflash log I may have better luck finding the cause.
If you're really not inputing yaw control then a few things might help:
1. re-do the radio calibration
2. make the RC4_DZ larger (i.e. yaw deadband)
3. check the radio for glitches. Sometimes you can see these (if they're happening) on the MP's radio calibration screen
On Arducopter Standard Parameter it is saying Default=500, see link below. Maybe this page is not updated. Would you please let me know how to interpret this.
|Roll Axis Rate Controller I gain Maximum||(RATE_PIT_IMAX||
Roll axis rate controller I gain Maximum. Constrains the maximum motor output that the I gain will output. Default = 500
Hi Randy, thanks once again for the support. I would re-build the quad, and first flight test RC5 and in the flying field itself, will upload RC10, do necessary calibrations, set IMAX to 1000 and will report.
Without load the voltage displayed by the APM matches with that of Quanum telemetry voltage display but when load increases, voltage displayed by the APM goes much down while voltage display by Quanum decreases only very less as is expected.
I followed the procedure for voltage and current calibration. It is my observation that in overall the voltage & current measurement of APM is not that accurate as of Quanum as a result it is very difficult to rely on it.
Is the horizon in the HUD stable ? Is compass health okay ?, If not then the 3.3V regulator (Package: SOT-23-5) has blown, replace it but if not then in mission planner do contrl+F, there is option to wipe the EEPROM, you can try that and give reset to the APM.
Jeepers, so many out-of-date wiki pages, so little time. I've added it to my to-do list to update or remove that page.
How did you find that page by the way? I'm trying to find a link to it but not having much luck..