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
Do you know what could cause this as it was fine with rc 13
Stuart
@stubugs,
I've tried to recreate the problem but I'm having troubles. Can you tell me what your vehicle's LOG_BITMASK is and how you're finding the problem. I've done this:
1. set LOG_BITMASK to "NearlyAll"
2. connected to MP with USB cable, armed, disarmed, downloaded log.
3. disconnected USB cable, reconnected USB cable
4. connected, all logs are there.
I've repeated the above tests with LOG_BITMASK set to "All+DisarmedLogging" and the results were the same.
The only things I noticed that I hadn't noticed before was that you can't download logs while the vehicle is armed. Also if you download the latest log (i.e. the one that is currently being written to), when you re-arm the vehicle, that last log doesn't seem to grow. It seems when you download a log, logging is stopped and it can't be restarted unless the board is rebooted.
hi randy
set log-bitmask to nearly all
armed whiles plugged into laptop mission planner bit of throttle disarmed
went to download via mavlink attached log was downloaded
disconnected usb and battery reconnected battery and usb mavlink log has disappeared
no logs
also got bad ahrs not shure what it is but still armed ?
many thanks stuart
2014-11-07 16-37-48.log
Randy,
Wouldn't having the log bitmask set to "All+DisarmedLogging" explain this? Can the beta MP set this yet or would it need to be set manually?
Regards,
Nathaniel ~KD2DEY
Testing AC 3.2-RC14 on full auto with spline waypoints. Pls see attached...
Hello All,
Here are a couple of logs from RC14 on my FPV250. The initial log is with 5030 props which are ok. I then tried 5040 Gemfan but these are impossible to centre correctly. As a result I got some strange low frequency oscillations in the frame that seem to push the ACCL and EKF readings off. The quad still performed well and did not do too many strange things. I did notice a bit of overshoot in YAW and higher error readings in the EKF and AHRS. However, none of these produced a catastrophic crash.
These logs are mainly just for your interest but it is interesting to see the difference good and bad props make to the APM readings. The PID's are basically from auto tune and seem to be working but very different to what I got using earlier RC's. I now seem to get very close to flipping but it has always recovered so far, even when I try to push it over.
Anyway, I hope these help in some small way.
Logs attached
Alex,
hmm.. a number of people have reported issues with AutoTune. The only thing we've done is extend the highest and lowest numbers that it can reach. Perhaps we should back that out..
i agree too, it was working very good on AC 3.1.5., i think it is better to go back to this version.
perhaps there could be made a paramter which makes it adjustable for density.
Pomaroli,
Leonard and I had a chat and we'd like to make sure that we're separating general flight issues from issues with AutoTune. So we'd ask you do three flights each with a fresh battery and all with the IMU logging turned on.
1. hover in stabilize for 30 seconds, hover in alt hold for 30 seconds, a few maneuvers like you would normally do to test your PIDs
2. do an AutoTune
3. repeat the first flight
If you could then post all 3 logs here, that'd be great. Leonard and/or I will have a look at them.
-
55
-
56
-
57
-
58
-
59
of 373 Next