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
So is rc14 working fine? there're some ppl having bad accel/gyro/baro pre-arm alarms
Hi in RC14 i have Pre-arm : "Bad accel health", "Bad gyro"
Artur,
Generally this only pops up immediately after you upload the firmware. If you reboot does it still appear?
Hi,
Now i ok :)
This little quad didn't pass the word go.
Frame: Carbon fiber Quad 730 mm (motor shaft to motor shaft). CF tubes: od = 17.38mm tubes thickness 0.85mm
Main Batterie telemetry: Quanum.
Motors: Turnigy 3020B 600KV
ESC Turnigy DLUX
Props: 13x4 inches (330x102)
Main Battery: 4S 5A. Flying Batterie: 2S 1.5A. 5V regulator to power the APM 2.5 and the receiver.
Firmware version V3.2 RC-13 (yes I just saw RC-14 has been released)
First flight was done (stabilize mode only) without problem just to see if any trim were required.
Second flight took off in ALT HOLD: Rocket to the sky (in a very straight line) and wasn't able to control vertical anymore.
Did switch back to stabilize and it fell breaking the very fragile (too thin) CF tubes.
Props were "shortened".. :-)
My guess looking at the .bin file is that ACCZ +- 20 was real high. Should have look more carefully after first flight at the log file.
@Henri,
Yes, this certainly sounds like a high vibration issue. We're closing the noose on the problems but this one still remains unfortunately. It seems when vibration levels are high the accelerometers develop a bias and it's always in the same direction - it always thinks the vehicle is falling when it's actually climbing. So technically it's a hardware issue but we need to deal with it in software.
I don't think we will ever resolve the issue on the APM2. but the Pixhawk has two accelerometers and we hope by blending them we can recognise the problem when it happens and do something about it.
Randy, may I suggest something to you? Do you know how a noise canceling mic works on your cell phone? I assume yes you know, but will still explain: there are at least two mics one you speak in and the other one on the other side of the phone which picks up the surrounding sound, comparing the wave-forms from both mics audio chip cancels out those waves on the main line which have the same characteristics as those on the "noise" mic. I suggest implementing something like this: hard mounting a separate IMU directly on the frame to act as the "noise" mic... this way the 2nd IMU will pick up all the vibrations -> compare them to the measurements from the primary - dampened IMU and drop the vibration frames from the main line. I know this is a little complicated, but should work really good for those "dirty" platforms like heli and gassers.
Artem,
That's a very interesting (and new) idea. I know the 3DR hardware guys have experimented with putting a 3rd IMU that is not vibration dampened on an experimental/modified Pixhawk. The thinking was that it would tell us something about the vibration of the frame but more just as information not as a method to actually reverse out the vibrations.
One nice thing about the Pixhawk's 2 IMU solution is that they are different manufacturers and they have different sampling rates (the ST one is 800hz and the MPU6k is 1khz), the advantage of this is that they tend to alias at different frequencies.
Is it possible to connect amothe mpu6k via I2c or SPI?
I'm frankly not sure if it would just work or if some code changes would be required. With code changes it's certainly possible.
-
75
-
76
-
77
-
78
-
79
of 373 Next