Discussions

Developer

ArduCopter-3.2 beta testing

Posted by Randy on May 11, 2014 at 7:45pm

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)

You need to be a member of diydrones to add comments!

Join diydrones

Tags: 32, arducopter, beta, testing
Email me when people reply –
Follow

Replies

      • Francis O'Brien > Julien Dubois September 3, 2014 at 1:23pm

        Thanks for the analysis was fearing it was something like that but wasn't sure how to check for the landed condition :(

        At least the crash wasn't pilot error for me this time :)

  • stubugs September 3, 2014 at 8:03am
    Hi pixhawk with twin gps
    Would it be possible to get the pixhawk to use both gps to get a better gps position say halve way between the two
    Just a thought
    Stuart
    • Developer
      Randy > stubugs September 4, 2014 at 5:12am

      Longer term Paul Riseborough (EKF creator) will make the selection of the GPS a little more complicated.  I'm not sure if he will make it a weighted average (like the accelerometers) or just pick the one that agrees more with all the other data.

    • Julien Dubois > stubugs September 3, 2014 at 9:19am

      Hi Stuart,

      I think the current management is the best as the controller is currently using the GPS giving the best accuracy and stability of position.

      Doing a mix of both GPS modules would just degrade the quality of the best one.

      Julien

  • Robert Baumgartner September 2, 2014 at 12:00pm

    Randy,


    Thanks a lot, crystal clear, great job.


    Attached video of my mini quad with mini APM and RC6

    Best Regards


    RB

    • heliroberto > Robert Baumgartner September 3, 2014 at 1:41am

      Hi, yesterday I was flying with my hexacopter and firmware 3.2-RC5 after Autotune. The result was very good. In all flight modes I had a great performance. I tested Stabi, AltHold, Loiter, PosHold, Sports and RTL. My FC is a 3DR APM 2.52.

      Thanks to all for this great wort!!!

  • T3
    Thorsten September 2, 2014 at 11:41am

    Hi all,

    I am having some problems with AltHold/PosHold (Ac3.2rc6). The copter loses altitude while moving:

    3701820478?profile=original I am not sure if this is related to 3.2 and/or rc6. However, it is the first time that it is that dramatic. So I think I have to play with "Altitude Hold P" (THR_ALT_P).

    Anything else I could test?

    Thanks in advance!

    Thorsten

    • Developer
      Randy > Thorsten September 4, 2014 at 3:53am

      Thorsten,

      There shouldn't be any difference in AltHold performance but if you can provide a dataflash log file I'll have a look.  Ideally similar flights with AC3.1.5 and AC3.2 would be best but I understand that could be difficult.

      There's two possibilties I can think of:

          1. Baro disturbances, aka flattening out after fast forward flight.  This issue has existed since 2.9.1 but it gets brought up again and again.  We will have a look at it again for AC3.3 but it's an aerodynamic effect so could be hard to resolve in software.

          2. angle boost is not being applied.  This shows up in the CTUN message's AngBst column.

      • T3
        Thorsten > Randy September 5, 2014 at 5:44am

        Randy, 

        attached you find a log of a new flight showing the effect with THR_ALT_P = 3. It seems to be Baro disturbances. If you need more logs with special settings to parameters please let me know.

        As the copter is descending several meters AltHold is not really usable with this copter/settings. It would be great if there would be some solution. 

        Thanks for looking into this!

        Thorsten

        Speed_vs_Altitude.bin

        https://storage.ning.com/topology/rest/1.0/file/get/3702665688?profile=original
      • T3
        Thorsten > Randy September 4, 2014 at 4:13am

        Randy,

        thanks! It is a long endurance copter with up to 50 min flight time with one camera. So maybe not a typical system. I'll prepare a (3.2) log with a new flight tomorrow and I will test it with different payloads. 

        I'll also make a test with 3.1.5 at the weekend.

        Setting THR_ALT_P to 3 has almost no effect. Anything else you want to see tested? 

        Best regards,

        Thorsten

This reply was deleted.

Activity