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
FlyHigh,
Just to be clear though, adjusting the tx ranges only applies if you've changed RCMAP parameters. If you've left them as the default then this is not the issue.
Ah ok. I haven't changed RCMAP so I guess this isn't my problem then. Hrm
AC3.1.5 is not being shown in "previous versions of AC" of mission planner when installing firmware. i can see AC3.14. does anyone has any idea?
A few days ago I try again with Land switch from Pos hold and the copter not moving, when I switch to land, the motors stop and crash (near floor, no consecuences), It's possible that I had a false positive because the copter isn't moving? (I don't have the log this time) previous last landings I success, I'm not shure when fails, I'm going to try more.
I found what I believe to be an error in 3.2 but maybe its an error with pixhawk? I fly a quad. RC1-4 are my motors. RC 7 and 8 are gimbal and retracts. RC7 and RC8 will not currently function unless I press the safety switch. Pixhawk/apm should know I have a quad setup and only restrict 1-4 for the motors giving me access to rc 5-11 at all times.
This is not an error in AC3.2, but is by design.
What you present does have some merit, and might be considered, however, it would be complicated to do, so I'm not sure if it will be done for the next release.
Here's my second question: Has anybody had any experience with changing WPNAV_SPEED and WPNAV_LOIT_SPEED?
On a very well behaved second hexacopter today, we changed them from 500 cm/s to 1000 cm/s. When I had the copter execute the MISSION, it lost complete control and I could not recover with LAND or RTL and it didn't seem to respond to the R/C controls. We're going to look at the logs tomorrow, but anybody have an idea why doubling the horizontal speed could confuse the auto-pilot? (The first waypoint was straight up to 50 m after taking off to a 1 m height so I'm not sure why the horizontal speed would have impacted the flying.)
Its also possible that something else went wrong and the parameter changes weren't the reason for the behavior. I'll know more tomorrow.
I reviewed the log this morning and attempted to pull the waypoints from the Pixhawk, but it appears that the mission got cleared (likely by my code). So I'm wondering if there is an edge condition where engaging AUTO mode with no mission defined causes the copter to go out of control. I attached a few examples of the altitude changes, roll and pitch.
Has anybody engaged AUTO mode with no mission defined? I noticed that there is code to handle the mission ending, which either goes into LOITER or LAND mode depending on the condition. But, its possible that this code was never called. (The LAND command in the plot was my attempt at having it come down.)
auto-with-no-waypoints-zoomed.png
auto-with-no-waypoints.png
auto-with-no-waypoints-zoomed-roll-pitch.png
Rob, I can't see your logs but I do wee the EKF_CHECK failure which has triggered a land. This most likely means the position estimate went bad which could be be for a number of reasons including bad compass, GPS glitch.
Re the vehicle not flying level, I'd check the AHRS_TRIM_X and Y values. Those are set during the accelerometer calibration.
I guess you're writing your own code for the GCS or for the autopilot?
By the way, I'm completely overwhelmed with support and development so Rob Lefebvre will be around more from now on to help out. I think he's often best reached through the APM Forum although it might be possible to reach him in other ways as well.
I may have had a race condition that caused the issue. I tried an experiment where I issued a mission_clear_all and then immediately set the mode to AUTO and got the firmware to go into AUTO. (If I had an empty mission to start with, I could not get it to change to AUTO.)
I did this experiment in my office with the copter tied down to a 25 lb plate, but it definitely went into full throttle and stayed in AUTO.
It'd be great to have the mission definition in the log file as well so the other parameters could be synched with the mission definition.
auto-with-empty-mission.png
-
15
-
16
-
17
-
18
-
19
of 373 Next