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
Hey Guys ,
I want to know if 12 or 16 channel PPM passthrough + PWM RSSI is supported on the pixhawk with 3.2..
I have an EZUHF 8CH diversity Rx I would like to have 8 channels for control and mode changes, while the other channels will pass through the pixhawk for other uses...Is this possible with the current version ?
AKcopter,
Yes, it should work with AC3.2. AUX1 ~ AUX4 can be used for pass through from the transmitter/receiver's channel 9 ~ 12 respectively. You can switch AUX5 and AUX6 into PWM outputs (instead of the default Relays) to get two more by increasing the BRD_PWM_COUNT from "4" to "6".
Hi all,
Thorsten,
This is really a development questions so let's keep this on the drones-discuss@googlegroups.com list instead of here.
@Vishakh,
That error can come from the Tx/Rx going out of range but it can also be caused by the FrSky issue being discussed.
@Alex,
I've tested a bunch more of the D4R-II receivers that 3DR had sent me and it turns out that all the receivers 3DR sells now have been updated with the newer firmware which resolves this issue. It's just one older one that seems to have the old firmware on it that exhibits this issue.
3.2-rc14 crash. Any insight would be appreciated.
Just when I was gaining confidence in this setup it went bad in a hurry. 7 minutes in to the second flight of the day it lost gps which I detected as it started moving out of Position hold. Looking back I should have chopped throttle right then but as I tried to regain control it shot of sideways at high speed and cartwheeled on impact.
Quad with pixhawk and external gps/mag
The first flight went well and was my first attempt at an auto mission analysis below:
Log File C:/Program Files (x86)/Mission Planner/logs/QUADROTOR/1/2014-11-03 10-42-30.log
Size (kb) 9674.7021484375
No of lines 129491
Duration 0:09:01
Vehicletype ArduCopter
Firmware Version V3.2-rc14
Firmware Hash 3a292db7
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Balance/Twist = GOOD -
Test: Brownout = GOOD -
Test: Compass = FAIL - Large compass off params (X:-58.00, Y:12.00, Z:177.00)
Large compass offset in MAG data:
Z: 177.00
mag_field interference within limits (10.25%)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = GOOD -
Test: IMU Mismatch = GOOD - (Mismatch: 0.58, WARN: 0.75, FAIL: 1.50)
Test: Parameters = GOOD -
Test: PM = GOOD -
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = GOOD -
Second flight went well for 7 minutes.
Log File C:/Program Files (x86)/Mission Planner/logs/QUADROTOR/1/2014-11-03 15-59-56.log
Size (kb) 8112.34375
No of lines 107922
Duration 0:07:30
Vehicletype ArduCopter
Firmware Version V3.2-rc14
Firmware Hash 3a292db7
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Balance/Twist = GOOD -
Test: Brownout = GOOD -
Test: Compass = FAIL - Large compass off params (X:-58.00, Y:12.00, Z:177.00)
Large compass offset in MAG data:
Z: 177.00
Moderate change in mag_field (34.31%)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = FAIL - ERRs found: GPS_GLITCH FLT_MODE
Test: GPS = FAIL - GPS glitch errors found (1)
Min satellites: 0, Max HDop: 99.99
Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 2.16, WARN: 0.75, FAIL: 1.50)
Test: Parameters = GOOD -
Test: PM = GOOD -
Test: Pitch/Roll = FAIL - Roll (-150.86, line 102979) > maximum lean angle (45.00)
Test: Thrust = GOOD -
Test: VCC = GOOD -
2014-11-03 15-59-56.zip
Greg,
The problem is a GPS glitch that Inertial Nav didn't ignore completely. So the GPS Glitch protection caught the glitch but then after a moment it thought it had cleared and let the position updates flow through to the inertial nav. This led to inaccurate velocity estimates which it tried to resolve by leaning over hard.
The only things I can suggest are:
1. tightening up on the GPSGlitch detection. So reduce GPS_GLITCH_ACCEL to 800 (i.e. max vehicle acceleration of 8m/s/s) and reduce GPS_GLITCH_RADIUS to 170 (glitch of less than 1.7m are always accepted).
2. a more radical solution is to switch over to the EKF which apparently recognised the glitch and did not try to use the GPS for the duration of the flight. This can be done by setting AHRS_EKF_USE to "1". The EKF seems to be fairly reliable but realistically it hasn't been through all the massive amount of testing for us to be completely sure that it's reliable.
Thanks for the report and sorry about the crash.
Randy,
Thanks for taking the time to look and for the detailed response.
Is there any reason to not combine suggestions 1 and 2?
Is there anyway to determine why these types of GPS glitches occur?
How do you suddenly drop to a 0 Sat number?
Yesterday i had a new crash with my Hexacopter.
Last month i used v3.1.5, now i´m using 3.2 rc.14 for a few days.
Everthing was great, but my copter had a bad crash, when i activated the RTL Mode and it lands into the highest tree ón the field!
Can anybody check my logfile please, i can´t found something who explain the crash :(
https://www.dropbox.com/sh/2dzrrsscxnr3sgs/AABoD-WasKkvcOoTo60BsQFO...
Best regards and thanks.
Dominik
Dominic,
The major problem is the GPS is only updating at 1hz. This causes a huge number (81) of GPS glitches and four DCM Check failures as well.
The vehicle refused to go into RTL once because of those glitches but the second time, at that precise moment it wasn't glitching so it allowed it. It's no surprise that it wasn't able to do the RTL well.
I'll add a to-do to add another pre-arm check to ensure the GPS is updating at the correct rate.
I guess you didn't notice the LEDs flashing and buzzer going off?
-
59
-
60
-
61
-
62
-
63
of 373 Next