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

        Wesley,

        I had a look at your logs and it also looks like a brown-out.  In this log though we're slightly lucky in that we can clearly see the main battery voltage dropping to 8V in the last 0.5sec of the log.  Obviously it's not a "lucky" situation that the vehicle crashed but "lucky" in that it points pretty conclusively towards the cause of the problem (a power issue).  Can you describe how the board is powered?

        3702672820?profile=original

    • 100KM

      Happened to me last week, flying around in Loiter (AC3.2RC12), next thing copter lost all power (motors stopped spinning) and fell to the ground. All connectors checked out, etc. Auto analysis reports looks exactly like yours incl the VCC warning.

      • Moderator

        Same thing happened to me, crash after motors just stopped, with the logs truncated. Almost identical to the two above.

        http://ardupilot.com/forum/viewtopic.php?f=25&t=8769

        • Developer

          Graham,

          Looks like that report was while running AC3.1.5.  It does appear to be a brown-out, although we can't see any evidence to prove it except that the logs suddenly stop.  The board voltage is relatively stable between 5.12 ~ 5.26 volts.  A 0.15V variation is fairly common.  The battery voltage and throttle out are all pretty normal.

          3702770519?profile=originalMy guess is that at times we're stressing the battery, ESC or powermodule with requests they can't handle and the flight controller isn't getting the 5V it needs.  I would be overjoyed if someone was able to reproduce the problem on a bench so we could investigate it more and see if there's something in the firmware that we could do to reduce the pressure.  I think, for example, it should be possible on these copters to make the flight controller black out by flipping the propellers over (and rotate them one position) and then really stress the system with fast increases in throttle.  This could be done in stabilize mode using some transmitter programming to make the throttle go between 0 and maximum at the flick of a switch.  On the otherhand if the pixhawk never blacked out that would point towards the problem not being a power issue (i.e. points back at the firmware).

    • Developer

      Rana,

      On the surface at least, it looks like a brown-out.  The logs suddenly stop 2.1 seconds after entering Guided mode when the vehicle is about 3m in the air.  A catastrophic software bug might also look the same but there's no evidence of that.  All the navigation values (i.e. NTUN messages) look sensible.

      3702528816?profile=originalIs this a custom version of the firmware?  The version name is a little different and the rate of the CURR message is higher than I would expect.

      • Today again, I tried to simulate the same condition and had again a test flight with AC3.2_RC12 with APM2.6.  I took off in Loiter and at 3mt altitude, using latest DroidPlanner 2, while, the quad was in loitering, set follow-me from the phone.

        Within a second, of touching follow-me, all motors were stopped and the quad fell like a rock. Attaching the flash and telemetry logs. So there seems a nasty s/w bug in the code which at least me able to demonstrate.

        In telemetry log, Quad arms at 73% of the telemetry log file.

        Auto analysis report:

        Log File C:/Users/Narpat/Desktop/Telemetry Logs, Videos, EEPROM & Flash uploads/Telemetry Logs/AC3.2_RC12, APM2,6 Crash (2014-10-26 17-29-22)/2014-10-26 17-32-19.log
        Size (kb) 352.9453125
        No of lines 5098
        Duration 0:01:24
        Vehicletype ArduCopter
        Firmware Version V3.2_RC12
        Firmware Hash
        Hardware Type
        Free Mem 0
        Skipped Lines 0

        Test: Autotune = UNKNOWN - No ATUN log data
        Test: Balance/Twist = GOOD -
        Test: Brownout = FAIL - Truncated Log? Ends while armed at altitude 3.91m
        Test: Compass = GOOD - No MAG data, unable to test mag_field interference

        Test: Dupe Log Data = GOOD -
        Test: Empty = GOOD -
        Test: Event/Failsafe = GOOD -
        Test: GPS = GOOD -
        Test: Parameters = GOOD -
        Test: PM = GOOD -
        Test: Pitch/Roll = GOOD -
        Test: Thrust = GOOD -
        Test: VCC = WARN - VCC min/max diff 4.898v, should be <0.3v


        2014-10-26 17-32-19.bin

        2014-10-26 17-32-19.log

      • Hi Randy,

        Yes, this was a compiled version, since at the time when I tested RC12, it was not available in Mission planner.

        In this version, Mount: Disable, Cam_Trig: Disabled, Pos_Hold: Disabled, Frame: Quad, Fensing: Disabled, Loging: Enabled, Autotune: Enabled.

        Compiled AC3.2RC12 was uploaded using Arduino-Ardupilot 1.03.

        On CURR message, I can't say anything, I used parameters of RC5, with which I have no failure since months when It was out.

        • To avoid any issues, why don't you in the future get the firmware from:

          http://firmware.diydrones.com/Copter/latest/

          Even if the firmware is reported as released and not in mission planner, you can always get it from there.

          Just download the correct platform version and load the firmware file in mission planner using the custom firmware option.

  • Hi,

    yesterday i loaded the rc13 to my new Tarot 650 with 6S 380kv 15x5,5 Props and RTFhawk with M8GPS from csg.

    The first flight test was ok. Smooth flight in Stablize but toilet bowling in PosHold.  After the flight with about 35% throttle i have set the Throttle MId parameter to 398 and have done a compass mot. Then today  i have done three flights. First flight i have done a autotune witch you can see in Log 1 and there are a lot of EKF errors. 

    After the Autotune the Tatot is swinging/vibrating extreme when i switch to poshod. (see log 2 and 3)

    So i think the Autotune parameters are not ok.

    The second stange thing is the battery fail safe you ca see in the logs. In the params all FS functions are disabled.

    Hope you can find something out in the log about auotune / vibrations and BAT FS.

    Regards

    Sven 

     

    Tarot_650_Autotune.zip

    Tarotnach autotune.param

    https://storage.ning.com/topology/rest/1.0/file/get/3701859649?profile=original
This reply was deleted.

Activity

DIY Robocars via Twitter
RT @a1k0n: @DanielChiaJH @diyrobocars @circuitlaunch Here's my car's view of that race. About 8.4 second lap times for laps 2 and 3... both…
yesterday
DIY Robocars via Twitter
RT @DanielChiaJH: Great racing against @a1k0n today at @diyrobocars! Pretty cool to both break sun-9s at the track today I think I got very…
Sunday
DIY Robocars via Twitter
Broadcasting the @circuitlaunch race live now at https://m.twitch.tv/diyrobocars Races begin around 2:00pm PT
Saturday
DIY Robocars via Twitter
RT @a1k0n: ran a huge number of hyperparameter tuning experiments yesterday; now I can train a new policy, far with better quality, in 15 m…
Saturday
DIY Robocars via Twitter
RT @a1k0n: Did I get rid of hand-tuned parameters? Yes. Am I still hand-tuning more parameters? Also yes. I have a few knobs to address the…
Sep 26
DIY Robocars via Twitter
RT @a1k0n: I'm not going to spoil it, but (after charging the battery) this works way better than it has any right to. The car is now faste…
Sep 26
DIY Robocars via Twitter
RT @a1k0n: Decided to just see what happens if I run the sim-trained neural net on the car, with some safety rails around max throttle slew…
Sep 26
DIY Robocars via Twitter
Sep 24
DIY Robocars via Twitter
RT @SmallpixelCar: @a1k0n @diyrobocars I learned from this. This is my speed profile. Looks like I am too conservative on the right side of…
Sep 24
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars Dot color is speed; brighter is faster. Yeah, it has less room to explore in the tighter part, and t…
Sep 24
DIY Robocars via Twitter
RT @a1k0n: I'm gonna try to do proper offline reinforcement learning for @diyrobocars and throw away all my manual parameter tuning for the…
Sep 23
DIY Robocars via Twitter
RT @circuitlaunch: DIY Robocars & Brazilian BBQ - Sat 10/1. Our track combines hairpin curves with an intersection for max danger. Take tha…
Sep 22
DIY Robocars via Twitter
RT @SmallpixelCar: Had an great test today on @RAMS_RC_Club track. However the car starts to drift at 40mph. Some experts recommended to ch…
Sep 11
DIY Robocars via Twitter
RT @gclue_akira: 世界最速 チームtamiyaのaiカー https://t.co/1Qq2zOeftG
Sep 10
DIY Robocars via Twitter
RT @DanielChiaJH: Always a good time working on my @diyrobocars car at @circuitlaunch. Still got some work to do if I’m to beat @a1k0n howe…
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: My new speed profile for @RAMS_RC_Club track https://t.co/RtLb7TcgIJ
Sep 10
More…