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

          • So it looks like I'm back up and running now. Took it for a flight, and it seems good. Only issue, rather odd one at that, is that the props don't spin when armed. This is a new behavior.... they always spun slowly before. 

            So I checked the parameters, mot_spin_armed is set to 70 and thr_min is 130. So they SHOULD spin. I recently re-calibrated the ESCs and also re-did the radio calibration (not sure if that had anything to do with it). But I'm stumped why they don't spin when armed. They also don't spin when the throttle is at minimum, so in testing (with props off), I'll put it into stabilize or alt hold and at throttle minimum, the props don't spin at all. Move the throttle up a tiny bit and they come to life and it otherwise seems to fly fine. Will do more testing today though. 

            Any ideas? Should I try and do another clean install of AC?

            • +1

              I'm seeing the same thing on my Y6.

          • Randy,

            I wanted to post to this the other day when it was first posted. Could the issue I had here: http://diydrones.com/forum/topics/arducopter-3-2-beta-testing?comme...

            be the same thing or related? Mine happened when turning EKF off and I believe I had it on channel 7.

            • I have to say the whole sync issue freaks me out a little. I had one serious crash and I'm not sure whether it was an arm pulling loose or loss of sync. I have tested my quads using the radio by flailing the throttle with no sync issues but, if the FC is able to increase the speed requested to the SC much more rapidly than my tests, then sync issues could be lurking unknown until an event like EKF is engaged or some other rapid evasive move. Maybe it's already there but, would it make sense to have a parameter that limits the rate of throttle increase requested by the FC?  

            • Developer

              George,

              Thanks for bringing this up again.  It definitely could be.  It looks nearly identical in the logs except that in this case, as you say, it happened as you turned EKF off (while for Kristian it happened when EKF was turned on).

              Your vehicle falls forward and left (instead of Kristian's forward and right).  Also looking at the raw motor outputs Kristian's front right motor stays at max the whole time until the crash while your front-left motor recovers.  I'm guessing a bit but the shock of the crazy number could lead to a sudden change in the request to the motor which could lead to an ESC sync issue.  Maybe your vehicle's motor/esc recovered by Kristian's did not.  It's a bit hard to say.

              3702872274?profile=original3702872157?profile=original

              • Thanks for the response Randy.

                I won't rule out sync issues however I have spent many hours working on sync issues from when I had my hex with the same motors and esc's. I switched all of my esc's over to BlHeli firmware from SimonK along with strapping the quad down to the table to see which settings eliminated the sync issues. From the testing that I did with correct timing settings I could not get them to go out of sync. Even using a throttle hold switch to make the pwm signal instant to eliminate any delay from moving the throttle stick as fast as I could. 

                I guess it could be possible that there is a sync issue as I am sure the signal from the pixhawk going to the esc is faster than a signal coming from the radio -> rx -> pixhawk -> esc. Testing it to that extent is beyond me.

        • Developer

          Kristian,

          I've had a look at the 158.bin log in which it suddenly crashes the moment that EKF is enabled.  It looks like a mechanical failure but more specifically I suspect a ESC sync issue on the front-right motor because the vehicle suddenly rolls right (+ve roll) and forward (pitch goes -ve).  Also when looking at the motor output this front-right motor goes to full (which means the attitude controller wanted maximum power from this motor) which means it was getting much less than it wanted/needed.

          It's obviously extremely suspicious that this happens at exactly the moment that the EKF is engaged so I'll escalate to Paul and the rest of the devs to see if people can find something I haven't.

          3702769160?profile=original

        • Developer

          Kristian,

          The good log (155.bin) has near perfect tracking of desired velocity to actual velocity and DCM & EKF only disagree by about 15deg (which is still a bit high actually) so the vehicle's heading is good.  The gyro biases are very similar between the good and bad flights so I don't think it's the gyro that is the cause.

          So this leaves us with the compass as the likely problem.  I suspect it'll be incorrectly calculated offsets (you re-did the compass calibration after replacing the GPS/compass module?) or interference from the power wires (any chance you could share a picture of where the compass is mounted?).

          • Thanks for looking into this further. Yes, I definitely did the compass recalibration each time I replaced the external gps. That I know for sure. I had several good flights with this setup, which is why it seemed rather out-of-the-blue. Any suggestion on how to avoid this would be great or if I need to change my setup around a bit.

            Although right now I'm still trying to resurrect my Pixhawk as I still can't get it to come alive after the second crash.

            Here are a couple shots of my setup:

            3702829551?profile=original

            3702829697?profile=original

            • Bit of topic, but i really like this red-blue dumpening under pixhawk.

              Where did you get it from?

This reply was deleted.

Activity