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
Henry,
Thanks for the report.
After all the reports on this thread, Michael and I did a bunch of testing on the MP's compass calibration and found two problems, both of which are now fixed:
1. the 2nd compass's offsets would become near zero if the calibration was run twice in a row
2. the Auto-complete feature threshold was set too low which could lead to offsets being off a bit (in my tests on just one pixhawk I could get variations of about 6degrees).
Michael/Craig say both of these issues have been fixed in the latest Beta so I highly recommend that everyone who is using the Beta, pushes the "Check for BETA Updates" button on the Help screen and if you saw a suspect compass calibration (i.e. it finished too quickly) please re-do the calibration.
At the risk of sounding like I'm passing the buck, I want to point out that the compass calibration is completely within the mission planner, it's not directly related to AC3.2.
Yes, Mission Planner 1.3.12 (i suppose this is the latest) has very nice compass calibration like the one in MP 1.3.10. I did 3 auto flights with compass calibration from MP1.3.12 with no issues.
Hey Guys,
I just loaded ac 3.2 with mission planner 1.1.12 and it seems I have some issues. I almost had 3 flyaways today while in loiter. I just finished this big bird and have been having some ESC issues with it as well. I do not suspect the esc issues have much, if anything to do with the flyaways, but I thought I would include that as well. The vibration levels seem to be very good with the exception of a couple blips here and there coming from the gimbal. Which i suspect may have something to do with it.
I am using a 1200mm hex with avroto 3515's, 16*5.4 tmotor props, maytech opto 60a esc's(overkill i know) and 2 10000mah batteries. It flew very well with ac 3.15 would love an experts insight into my logs as to why I had these flyaways.
Hdop and sat counts are great throughout the flight.
Here is the log files
2014-11-15 15-44-17.zip
2014-11-15 15-43-11.tlog
Test: Compass = PASS - mag_field interference within limits (9.92%)
Max mag field length (559.10) > recommended (550.00)
A compass interference perhaps?
wouldnt compass interference only translate into yaw motion? it pitched over to 30 degrees and started flying away.
Wait expert answers but if it is desoriented i suppose it probably fly away, It doesn't know where north is.
Same thing here - pixhawk running the latest 3.2 and the calibration stops maybe 15-20 seconds in and gives me my offsets. What is concerning is that every time I do the compass calibration, the offsets are quite different. I am not getting any compass errors, and it does seem like the orientation on the map is OK.
Is this the new standard behavior for compass calibration? I thought it would run until I stopped it.
Mission Planner used to collect samples for 60 seconds and then run the calibration calculation. It was possible to get a bad calibration because the vehicle would not be rotated in each direction. Awhile ago we made it so that the compass routine required samples to be gathered from all over the sphere around the vehicle and there was a graphic display to help the operator point the vehicle in all directions but that could take a long time to gather enough points.
Now what we do is speed up compass messages and turn off most of the other messages. We also start calculating the solution after one second and perform the calibration continuously. The calibration stops automatically a) when points have been gathered with the vehicle pointing in all directions and b) when the solution converges.
Feed back is appreciated. Thanks!
I wish you would have spoke up sooner then because while it certainly was an improvement over the original method most of what we have had for feedback was negative.
As for gathering more points, once the solution converges, adding more points does not add any data or make the solution any better.
Terry, Randy & Michael identified an error earlier today where if you repeated the calibration multiple times on the same vehicle it would be incorrect for compass 2. I think that was the inconsistency people were seeing. That issue has been resolved and is corrected in the latest MP beta.
We are calibrating more than 100 vehicles per day in the factory (so about 2000 vehicles since this change) and the method has generated consistent results for all those vehicles.
I would say the biggest contributor to the consistency of the result is keeping the Pixhawk at the center of the rotation of the vehicle. Moving it around (ala "The Compass Dance" or moving it closer or farther away from some magnetic object makes for a poor calibration.
I saw somebody post a video where they placed their vehicle on an office chair and rotated the chair. While I think the concept is instructive to see the circles generated in the point cloud, I would expect there is enough magnetic interference from the metal in the chair to make the calibration invalid.
-
31
-
32
-
33
-
34
-
35
of 262 Next