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
Phil, to test out a DO_SET_SERVO sequence like that does the copter need to be armed and motors spinning ?
Martin
Martin,
I did the test on my kitchen table with the PixHawk armed and the throttle about half way with motors disconnected. Same for the tests using the 3.1.x versions of the code. I haven't tried it with the PixHawk disarmed since I assumed it wouldn't work.
I've since increased the complexity of the test by doing four DO-SET-SERVO and DO-DIGICAM commands at PWM values that give me a complete panorama column top to bottom, then using the DO-JUMP command to cycle through it eight times with the thought that I would add a CONDITION-YAW 45 degrees relative in the next test step to get a complete panorama. My hexacopter is brand new and I'm not willing fly beta software on it so the yaw test will have to wait.
I did try the same sequence on the 3.1.5 release but could not make it work. This time it saw the waypoint with 0 Lat, 0 Lon, and 0 Alt and said it needed to move a long way (over 32000 I think) towards Africa before it got there.
I did some more testing on my dining room table and got the sequence to work in 3.5.1 provided I made the following changes:
1. Every Waypoint had to have at least a 1 second delay or the subsequent "DO" command was skipped.
2. Waypoints with 0 Lat and 0 Lon had to be changed to a waypoint with my current position. 0 Alt was OK but using zero for Lat and Lon hung up the sequence with a display on the HUD of 37070>11 with 11 being the waypoint that had 0 Lat and 0 Lon. I saw the bug that was entered for 3.2 (#1145 ensure lat, lon, alt all zero is handled without flying to africa) but I didn't think it applied to regular waypoints in 3.1.5)
If there are any tricks or dependencies in using waypoints with 0 Lat and 0 Lon I'd love to hear about them.
Phil,
So the difference is because of the rewritten AP_Mission library with AC3.2. The do-digicam-control does work with AC3.1.5 though. I used it successfully to drop the tennis ball at last year sparkfun AVC competition. The issue I think is that in the mission it's not giving any time for the do-set-servo command to run between the waypoint commands. I would still expect the 2 second delay on the 2nd waypoint command would give it enough time to complete though so I'm unsure why you're finding that that one isn't working.
Glad to hear that it's working well on AC3.2 though. AC3.2 better handles "do" commands that appear at the beginning or end of missions in particular.
Randy, as with the GPS glitch detection would it be worth having an altitude jump detection? So if the altitude jumps by more than the average or above average copter is capable of then this protection would stop massive attempts to change altitude (or is this built into the GPS glitch detection?)
Graham,
Yes it's a very worthwhile feature to have and it's on the to-do list here. It's actually already built-in to the EKF which can be enabled on AC3.2 using AHRS_EKF_USE parameter. I'm undecided whether it's worth re-implementing this check for the existing inertial-nav or whether we should just continue to put up with the risk until EKF becomes the standard position estimation method (that will happen with AC3.3).
Hi Randy,
Regarding Altitude glitch detection:
If you manage to fit EKF in the APM2 I would say to wait to EKF being the standard position estimation method.
If not, please consider to include it in current inertial-nav ;)
Miguel
I am not sure, but I think the processor requirements of the EKF were beyond the capabilities of the APM board.. could be mistaken though?
Just Thought the group would like this, Like Google street view But with Drones http://www.travelbydrone.com/ what will they think of next?
This is awesome! Bravo!
-
322
-
323
-
324
-
325
-
326
of 373 Next