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

  • Hi Randy,

    i don't know if you saw my post below to go sure i post it again. I would be happy if you can look on it, it seems likely impossible to me that this is caused by mechanical issue.

    Origin message :


    unfortunately today i was having another crash because of the flip issue in acro mode.
    This is the third of this kind.
    slowly it becomes more and more expensive. Therefore i've really hope we can find out the issue.

    Could you take a look to the attached log please ?

    This is what happened.
    i was doing speed and climb tests today. Also if done some slow and fast Roll's in acro mode, all went fine till the first Flip which ended in a big crash.

    i positioned the copter preparing it for a flip in acro mode. then after the flip i've realized that the copter is going to lose stabilisation, i've tried to stabilize it manually in acro mode but the copter didn't respond to any input at all.
     After i realized that i cannot stabilize it manually i've switched to stabilize mode and raised throttle, you see clearly in the log that the Throttle was completely maximized but the motors have not respond.
    the force of impact seems to  be about 5g.

    Until we have not found the source of this issue i'll go back to AC 3.1.5 and will wait until a solution is available for testing otherwise i think that i will not upgrade anymore.

    20141008183106.zip

    https://storage.ning.com/topology/rest/1.0/file/get/3701847774?profile=original
    • Developer

      Pomaroli,

      Txs for bringing this up again.  So it looks like you try to recover in stabilize mode but the vehicle doesn't respond and stays mostly inverted.

      The CTUN ThrOut staying low doesn't mean that the output of each motor was low though, it just means the overall throttle was low but individual motors can still be much higher in order to control the attitude.  Unfortunately the logs don't include the RCOUT messages so we can't see the individual motor out.  In case you ever try again, could you set the LOG_BITMASK to "NearlyAll"?

      I'll do some tests in the simulator to see if I can reproduce the issue.  If we can reproduce it, we can fix it.

      • Randy, attached you'll find the new log from today.

        As expected fast and slow rolls in Acro mode are working like charme.

        The first flip was nearby ok, was this luck ?
        Second flip and *bam*, there it lies.

        Same scenario as last time but slightly different :
        1 Flip -> copter lose control and motors are spinning slowly, pilot inputs are ignored.
        2 Switching back to Stabilize
        3 during fall to ground, the copter seems reaching the right attitude,was it luck ?
        4 what happens next the motors were fully spin up just quick.
        5 then *bam* there it lies.

        This time "only" 5  props decided in collective to leave the copter

        3702670979?profile=original

        2014-10-11 17-14-26.zip

      • I've changed many things since the first crash, the copter now has 600 Hz ESC's and T-Motors.
        It was weird that it was not possible to correct the position manually in acro mode, there was no response to the input's.
        normaly by switching to stabilize it corrects his position immediately, but in this case this wasn't so. seen by eye's the motors were spinning at different speeds but very slow.

        So i guess i'll try it again :) and will take the risk of crashing. i will change the log settings as you wrote. If you find something in the mean time let me know.

        By the way as you see in the log there are no GPS errors while in acro mode, did you change something as we discuss previously ?

  • Developer

    AC-3.2-rc12 is now available through the Mission Planner’s Beta Firmwares link.  The updates are in the ReleaseNotes.txt but also listed below.
         1) disable sonar on APM1 and TradHeli (APM1 & APM2) to allow code to fit
         2) Add pre-arm and health check that gyro calibration succeeded
         3) Bug fix to EKF reporting invalid position and velocity when switched on in flight with Ch7/Ch8 switch
         4) Fix to give users at least 15 seconds after engaging AutoTrim before vehicle disarms (previously was 5 seconds)

    Not too many changes but #2 and #3 were in response to crashes we saw on this thread.

    If testing goes ok, we plan to rename this version to AC3.2 in about a week and will then ask the wider community to start flying it.  Two weeks after that (assuming all goes well) we will make AC3.2 the default version loaded by the mission planner (AC3.1.5 will still be available through the “Pick Previous Firmwares” link).

    All feedback welcome and thanks again for all your testing!

  • Hi,

    rc12 is not yet mentioned on top of this page but available in the mission planner.

    i just setup copter no. 2 with this firmware and will start the test-fligt in an hour or so.

    if there are any "last-minute-changes" in the file that i did not catch: stop me :-)

    • Back again. I had two flights with the rc12 and i am happy again. Everything works fine.

      • Developer

        Peter,

        Great, thanks for testing that.  I got a little distracted but the release notes are now out there, thanks!

  • During PosHold mode slow flying, Quad Freefalling from 20 meter. APM2.6, AC3.2rc10. No Power module. power apm from 1 esc bec only and rx connect to PPM sum. can someone take a look for me the logs? tq

    3701849452?profile=original

    is that power issues?

    maybe power to APM seems cause the issue

    i connect 1 bec esc to output rail only to power apm2.6.

    • Developer

      @ultrojo,

      It's hard to be sure but I suspect it's a brown-out.  The logs end suddenly while the vehicle is 40m in the air.  There is actually some data in the logs after this but I think it's junk from a previous flight because time goes backwards (i.e. if you graph TimeMS of any of the messages you'll see it goes backwards at that point).

      3702524819?profile=originalThe voltage of the board (as you've posted above) is quite low right from the beginning, dipping to 4.6v a few times.  It looks like the vehicle was using about 80% throttle at the time it stopped recording logs so it's possible the ESCs couldn't provide power to both the board and the motors.

      The most reliable way to power an APM2.x is using a power module because it provides a nice reliable and stable power source.  The number of brownouts we saw dropped massively once 3DR started selling power-modules as standard equipment with the flight controllers.

This reply was deleted.

Activity

Neville Rodrigues liked Neville Rodrigues's profile
Jun 30
Santiago Perez liked Santiago Perez's profile
Jun 21
More…