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
Any idea why a compass would lose it's calibration? It unplugged and then plugged it back in and the next time it was fine. I'll try and dig out the log if it's there. I never armed it does it still create a log? Anyway the compass wigged out after several good flights. I'm really starting to wonder about this gps / mag. It's mounted on a mast several inches from the esc's
https://www.youtube.com/watch?v=v1YINzcbtHg&feature=youtu.be
Richard,
That may not be a compass issue but rather a gyro issue or possibly a combination of the two. -rc13 will include a LOG_BITMASK setting that will (optinoally) allow creating a log from start-up (at the moment it only creates a log when it's armed).
Until -rc13 is out, if it's continuing to do this could you set the ARMING_CHECK to zero temporarily, arm the vehicle, produce a log and post it here?
Off to work.... thanks Randy I will post a log tonight.
Hi,
Is there any size limitation for dataflash logs? I was recording IMU during my last flight (38minutes), and dataflash log only contains the last part of my flight, however telemetry log is fine.
Manu,
Yes, there is a limit. According to the 3DR store the APM2.x is 4Megabytes (I actually thought it was larger). The Pixhawk writes it's logs to the SD card so it depends how large the card is but I think the Pixhawk comes with a 2Gig card.
What about automatically overwriting the oldest log (like a FIFO) ?
Daniela,
Yes, that's what it does on the APM2 boards. If the log is long enough though it will eventually even start to overwrite the beginning of the current log that's being written.
I had no log files before the flight, but with IMU logging and about 40min flight time, it was overwritting in the same file. FYI .bin file is about 4Mo, .log at 11Mo on APM 2.6.
Manu,
Ok, so that totally makes sense then. The .bin file is the same format as is on the dataflash (or SD card) so 4Meg would fill up the entire dataflash. IMU is very fast logging (50hz I believe) so if you drop that it'll likely get much much smaller.
Vishakh,
A radio failsafe can occur when the throttle drops below the FS_THR_VALUE parameter (defaults to 975) or when the receiver stops sending signals. How the receiver reacts when it loses contact with the transmitter depends upon the receiver. Futaba receivers pull the throttle low, FrSky receivers can be set up either to pull the throttle low or simply stop sending signals. Of course all receivers stop sending signals when they lose power or are disconnected.
So I suspect in this case the receiver simply stopped sending signals and this triggered the radio failsafe. It's not possible to directly see that the receiver stopped sending signals but you can see that the RCIN values didn't change for the 0.2 seconds just before the radio failsafe triggered.
This behaviour is not completely documented on the radio failsafe wiki page but it's on the to-do list to explain this a little better there.
By the way, your vehicle's logs are a little unusual in that they're missing the information about the software and hardware being used and the parameter values. Did you manually chop the logs or was there something different about the software/hardware that you're using?
Is there anything unusual about
-
93
-
94
-
95
-
96
-
97
of 373 Next