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
Ok, thanks for confirming. This must be a droid planner issue then so could you raise it on the DroidPlanner issues list?
The fact that it persists across reboots of the flight controller really shows that it must be in teh ground station.
Txs for the report, hopefully Arthur can sort this out.
this is also possbile i was testing both too.
yep can confirm same here.....
Congratulations (not) on this thread now running to over 200 pages, fascinating in their diversity of subject matter and overall stream-of-consciousness structure, and a reminder that the only way to find anything within these forums (and so-called blogs that aren't actually blogs) without going sleepless and eventually blind is to search from outside the site, using Google, with the syntax
diydrones.com: findthis
For example, the search term diydrones.com: pixhawk tarannis Tx
returns 16,000+ hits, rather a lot but if that's what you're looking for it's one hell of a lot more fruitful than slogging through the foggy swamps of forums and "blogs".
Might suggest you place your concern out in the main Blog Post vice in this one? You have a valid point and it's not necessarily being viewed by everyone but just this group. I'm sure others in other groups and discussions feel the same way. Just my two cents on the topic.
Hi Peter,
Please upload a log, it will help you see what happened but could also help other users if they have a similar problem.
Generally with each release candidate (RC) the issues will get smaller and smaller until none, I would advise uploading the log and staying with RC11 until RC12 is released some time soon. By the time you get your parts 3.2 will probably be ready to go!
Or fly with 3.1.5 which is the "stable" version at the moment.
Hi Brandon,
the 3.1.5 version will not work for me. Okay, it works but i have to use a ppm-encoder. This is the copter:
http://netzfunker.de/h4680.jpg
The very short crash-log is attached.
Yesterday i deleted my first post here because i found the download-Section for previous versions.
This copter flew very well with rc9.
Thanks for response.
Peter
2014-10-09 17-05-52.log
Randy, what was the hash # of RC5 ? and how I can download the source code of AC3.2RC5 from Github ?
AC3.2RC5 is the most reliable to fly, done more than 400 missions without any issue. One day uploaded RC10, quad crashed, replaced the damaged motors, reverted back to RC5, everything is ok.
Hash # of AC3.2_RC5: 515cb7c6710b98ea27d4da85155b35d4b7e3c97c
https://github.com/diydrones/ardupilot/tree/515cb7c6710b98ea27d4da8...
https://github.com/diydrones/ardupilot/archive/515cb7c6710b98ea27d4...
Rana,
I did a pretty thorough review of your log from -rc10. Did you eventually look into why your voltage monitor seems incorrect? Have you checked the voltage of the battery using a stand-alone voltage monitor after a flight to see how low it's getting and whether it agrees with the AttoPilot voltage monitor?
-
125
-
126
-
127
-
128
-
129
of 373 Next