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)

Views: 305522

Reply to This

Replies to This Discussion

So if one is still flying the AC3.1.5 the issue is still going on then?

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 was flying with 3.2, but it appeared to go into AUTO mode when there were was no mission defined. (The mission waypoints aren't in the log file right, you can only retrieve them from the copter via MAVLINK?)

Thanks for your support Randy, you've been a great help over the years!  Its been great to see the project flourish!

I actually told the copter to LAND myself as well with MAVLINK then the pilot with the R/C switched it to RTL. (Switching to stabilize would've probably been the best bet in retrospect.)

I'll check out the AHRS_TRIM values and compare those to values when the copter was able to hover in stabilize mode.

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.

Randy you have been a tremendous help to all of us and then entire project would be out of luck without your efforts. Frankly I have no idea how in the world you can research and reply to so many issues. You deserve a PAID vacation!

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?

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.

Attachments:

So basically from what you are saying and have tested, we should not go to "Auto" when no mission defined. And that is exactly what I have been doing since the incident I described above.

Rob,

    If you can reproduce the issue and send a log to Rob Lefebvre that would be great.  The vehicle should either get into AUTO with a valid command or it shouldn't go into AUTO.  It's possible to clear the mission after the vehicle is in AUTO and that should lead to the vehicle attempting to complete the current command it's working on and then it'll switch out of AUTO to Land or Loiter.

@Alex,

     I have personally tested (some time back) going into AUTO with no mission defined and it operated as expected (i.e. it doesn't go into AUTO).  Please remember that Rob Ratcliff is testing with a personally developed GCS, this is not like a regular user of Mission Planner or DroidPlanner.  It's a previously untested combination.

Rob,

I've created a new discussion here for you, me and Rob Lefebvre so we can follow-up on issues you find during your GCS development.

I'm having some problems with position hold on 3.2 pixhawk. Everything is working well including loiter. But position hold just drifts and does not hold. My droidplanner confirms that position hold is engaged but the copter flies like its still in alt hold or stabilize. Any idea why? I've included my latest log file. 

Attachments:

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service