Developer

ArduCopter-3.2 beta testing

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

Email me when people reply –

Replies

  • I had an issue with bad RC calibration which I was trying to solve for almost 3 days! my tricopter would yaw clockwise no matter what I tried, I ruled out mag issue since in loiter it would not toilet bowl, but just yaw in the same spot +/- 1meter. you see I fly a tricopter so there are many potential yaw issues related to the mechanics and yaw PID, so I was trying to find an issue there, it turned out rc4 trim was 1498 instead of 1460. the reason why I didn't catch that, is because all other channels mid point is actually between 1497 and 1499. moreover the first 2 RC calibrations I did with only USB connections, both turned out to be incorrect, but than I was redoing my mag calibration just to se if this would help with telemetry connection, so I did RC calibration this way too, it immediately stroke me that the rc4 mid point moved compared to the old calibration, sure enough in the full parametrs list RC4 trim showed 1460. since than I have no issues with yaw. 

    • Bet you were glad to figure it out! Sometimes it's the littlest thing!

  • Hey!

    After some problems, I reconfigured my mag (rotation roll180 > none) and recalibrate it. Also I bought a new GPS (uBlox NEO-M8N) because my gps data are not really good. Today I start the next flighttests. But they are really bad. :-( First time, the led switches between blue/yellow. After a few minutes I've get a stable green signal... I think it tilt a little bit to one side, I start with more throttle and control to other side... The stabilize mode was ok. Then I change to stabilize super-simpel and it seems the control are inverted - back to stablize... At last flight the copter tilt to right side and grounded (1-2m). Only one prop was broken.

    I haven't any idea what's wrong. Could the pixhawk-hardware (sensors) have an error? The log is as attachement: 8.BIN

    Configuration: X8, Pixhawk 2.4, AC 3.2-rc9, HMC5983, Drotek uBlox NEO-M8N, AttoPilot 90A, SimonK-F30A, MN3110-26 (470KV) with 15x5.5

    LOGS_pixhawk_2.4_ac3.2-rc9.zip

  • when in loiter or poshold mode, what parameter to change if i want make copter ascending too fast.? like old poshold.
    • Developer

      ultrojo,

      PILOT_VELZ_MAX can be increased to make it climb faster.  The default is 250 (i.e. 2.5m/s).  Maybe try 500 (i.e. 5m/s)?

      Some of the controls are listed on the wiki's flight mode pages.  This particular parameter appears on the AltHold page but is also linked from the Loiter page.

  • Developer

    Here the RC9 in action, good watching...

    • Thank you, Marco.  Great flying.  Still on SBUS2 pin?  Regards

    • Thanks Marco, another great video as always, and very inspiring!

  • Developer

    AC3.2-rc10 is available now through the Mission Planner’s beta firmware’s link.  Release notes are below.

    One unfortunate thing is that we found an issue with the Compass device ids and this will mean that a number of people need to go in and do their compass calibration again.  I'm really sorry about this.  If you know your compass offsets are ok, you can get around having to redo the calibration by going into the full parameters list and:

         a) write down the COMPASS_DEVID and COMPASS_DEVID2 numbers that you see

         b) increase the numbers by 1 and press "Write Params"

         c) return the numbers to their originals and press "Write Params"

         d) reboot the board.

     

    ArduCopter 3.2-rc10 24-Sep-2014, Changes from 3.2-rc9:

    1) two-stage land-detector to reduce motor run-up when landing in Loiter, PosHold, RTL, Auto

    2) Allow passthrough from input to output of channels 9 ~ 14 (thanks Emile!)

    3) Add 4hz filter to vertical velocity error during AltHold

    4) Safety Feature:

        a) increase Alt Disparity pre-arm check threshold to 2m (was 1m)

        b) reset battery failsafe after disarming/arming (thanks AndKe!)

        c) EKF only apply centrifugal corrections when GPS has at least 6 satellites (Pixhawk with EKF enabled only)

    5) Bug fixes:

        a) to default compass devid to zero when no compass connected

        b) reduce motor run-up while landing in RTL

     

    All feedback welcome.

     

    We’ve now entered new ground as we’ve never had this many release candidates before an official release.  Hopefully we’re near the end but it really depends upon whether any significant issues are found during testing.  It’s certainly better to find any issues now (and fix them) rather than post an official release so a big thanks to the beta testers, keep it coming!

This reply was deleted.

Activity