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

      • Developer

        Steve,

        The board voltage looks very stable before the crash but we think brown-outs often happen very suddenly and we don't log the voltages very often.  We talked about this and what we can do about determining for sure whether a crash is caused by a brown-out or something else and we may try some changes in logging in a future release.

        I'm afraid that in-air reboots don't work out well because the board comes up in a disarmed state.  We discuss trying to make these work but it's very difficult to get the board to come up in a good state and provide the correct attitude in the very short amount of time.

        • Well I'm lucky it happened at 10 meters and not 1000 :) Just some small damage. I don't think it was a brownout but as you said, there is no way to tell without improving the logging on volts. Thanks for taking a look!

    • I am not an expert on this nor did I look at your logs but I can't see how this was caused by a GPS failure.

      Say your GPS stopped working all of a sudden in flight. None of the IMU sensors (accels and gyros), not event the barometer located in the GPS module. You would just lose the GPS. Your compass also should be working. Technically you would just lose the ability to work with lon. lat. info which means if you are in loiter, you would lose the fixed position, if you are in some auto mode running a mission, mission would abort. You weren't in auto mode; you said that already. If you are in any GPS assisted mode like Loiter, position hold, losing GPS should leave you with everything but the GPS technically (so like stabilize or alt-hold). I can't find any logical explanation as to how a GPS failure could cause the copter to dive into ground at a 45 degree angle. It just doesn't add up...

      P.S. I took too long to type my comment. When I posted, I realized Randy's analysis was already up:))

    • Developer

      @Steve,

      The logs just suddenly end while the vehicle is in PosHold mode at about 10m.  So it looks like a brown-out but it could also be caused by a catastrophic software failure.  We don't really have a good way to be sure which one it is so we generally have to guess based on the battery voltage and board voltage.

      3702531869?profile=original

  • Yes I agree and from my side as well, I have been using other brands systems for more than a year now and I am very new to this open source fw and most of the time I dont know what I am reading Lol, but the amount of work and dedication is obvious so thank you very much.

  • Hi Randy and Everyone,

    I just wanted to say a big THANK YOU! I  have been following this thread from the beginning, and at the the time I was very much a newbie. This thread has been taught me so much!  All of the issues explained and troubleshot have helped me to truly understand how ArduCopter works, and taught me to make my builds better and to solve/prevent my own issues I have come across.  Thanks for all of the hard work!! 

  • @Randy, I also think it is because of vibrations. The foam tapes that I had put below the APM  about 5 months back had dried up. their softness has reduced considerably. so what happens is that when the craft is flown in winds there are more vibrations (can be actually heard)  along z axis so the craft begins to climb. when the winds are still the craft behaves normal. this is very interesting discovery. so today i will replace the anti-vibration foam tapes.

  • @johnex, i do not think this is a vibration issue. because before auto tune there was no issue with the craft even withe the changed props. the loiter was great. in fact i never had any issue with the craft in last one year starting form AC3.0.1. This has started only when i upgraded to to AC3.2-rc14 and ran an auto tune because of change of props. Yes, my propellers are accurately balanced. i always balance my props before installing them. i will now restore back  to params before autotune and then try. i also upgraded to new uBlox M7N GPS+compass. but i am sure it is not because of that.

    • Developer

      Ravi,

      If you have a dataflash log file we can take a look.  There's an easy way to get an objective view of the vibration levels if you're using a Pixhawk and that is to run the automated log analyser.  The test compares the average level of the two IMUs which allows us to see if any aliasing is affecting of them.

  • Had great flights this morning using AC3.2-rc14.

    Tarot 810 Hex frame with PixHawk, 3DR GPS+compass.

    Tested stabilize, alt hold, loiter, return to launch, and low battery failsafe.

    No autotuning done - all default PID settings.

    Everything is working fantastic - rock solid position keeping and response.

    Good job on the code development.

    Andrew

This reply was deleted.

Activity