Discussions

Developer

ArduCopter-3.2 beta testing

Posted by Randy on May 11, 2014 at 7:45pm

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

Tags: 32, arducopter, beta, testing
Email me when people reply –
Follow

Replies

    • Bartek > Paul Hammond December 2, 2014 at 1:50am

      I think u have to flash copter software if  on APM is plane version or flash plane if u have copter on APM , that should erase eeprom to default values.

  • Rob Ratcliff November 28, 2014 at 5:38pm

    I have a Hexacopter with a Pixhawk and have the released version of Ardupilot 3.2 firmware loaded. I performed the accelerometer, compass and R/C calibrations out in the field. My goal was to test a simple mission of a few waypoints spaced at just a few yards apart with the copter tethered with a 100 foot line to avoid a runaway. 

    The first flight went great. The copter performed perfectly.  I moved the Hexacopter back to the center of my course, cycled the power and tried another mission. This time though, the copter went into this wild oscillation right after launching and ended up crashing. After the crash, I noticed that the Pixhawk had came loose from the double stick mounting pads that came with the Pixhawk. I'm not sure if it came loose due to the crash or was in the process of coming loose, which may have contributed to the behavior. 

    Here is a video:

    http://youtu.be/Hl93Gt90KFM

    I didn't notice anything obviously wrong in the logs except for the wildly oscillating pitch, roll and yaw. I've attached the logs from the crash in case anybody can see an apparent problem.

    (I'll try it again with the Pixhawk more secured, once I fix the broken mounting points in the frame. )

    Thanks for any feedback!

    Rob

    2014-11-28 12-04-49-wobble-crash.bin

    2014-11-28 12-04-49-wobble-crash.log

    • Moderator
      Nathaniel Caner > Rob Ratcliff November 29, 2014 at 12:09pm

      Hi Rob,

      I've been thinking about what you've described, and by the way, I think we're all glad you had a moment of ESP when you decided to tether you're Hexacopter; what is your WPNAV_RADIUS set to? I ask this because you describe the mission as "a few waypoints spaced at just a few yards apart". Thinking about this, if the waypoints were set apart less than twice (at least) the distance described by WPNAV_RADIUS, you would create a series of waypoints whose radius create circles with intersecting sections. This creates a unique circumstance where you could possibly create a zone where all waypoints could be "reached" at the same time. In theory this could result in some pretty wild oscillations.

      Consider the following examples:

      3702534048?profile=originalIn Figure 1 we have a box described by 4 waypoints that form a square; the waypoint radius in this example creates 3 distinct overlapping zones. The black circles indicate the circular zone created by the WPNAV_RADIUS around each WP indicated by the small red circles. In the Blue zone all four waypoints would be considered by the FC to have been reached. In the green zones 3 of four waypoints would be considered to have been reached, and in the yellow zones 2 waypoints would be considered to have been reached. Only in the white zones would the waypoints by individually described, and this would only be true if we overshot the waypoint.

      In Figure 2 the waypoint location has remained the same, but we have reduced the WPNAV_RADIUS shown in black. There are no overlapping zones so the FC would not oscillate.

      Lastly in Figure 3 we have moved the WP locations further apart and kept the same WPNAV_RADIUS as in Figure 1. Again we have no overlap, so the FC would not oscillate.

      Your WPNAV_RADIUS = 200, or 2 meters; so if your waypoints are spaced closer than 4 meters apart you are going to have at least some overlap as in Figure 1. The mroe your waypoints overlap, the greater the likelihood you might see some strange behaviors.

      Can you post a copy of you mission file, or a tlog from your flight?

      This is all just a theory, and I welcome the opportunity to either confirm or deny it.

      Regards,

      Nathaniel ~KD2DEY

      • Rob Ratcliff > Nathaniel Caner November 29, 2014 at 1:09pm

        Thanks for the reply. 

        I'm using an WPNAV_RADIUS of 2 m (200 cm). But, I noticed that I managed to place the first two waypoints on top of each other, which in the MP shows NAN for the gradient. I haven't looked at the code to see if a NAN for gradient would confuse the flight controller. 

        I've attached a picture of my waypoints and the mission description. 

        wobbly-mission.png

        wobbly-mission.txt

        • Michael Burmeister > Rob Ratcliff November 30, 2014 at 5:08am

          The flight was doomed from the start.  As soon as the copter armed the copter was told to bank hard left and forward.  Since it was on the ground at the time, it started flying in a circle which just confused the rest of the electronics to the point where it was over correcting and thought it was flying downward into the ground.

          It also looks like you are not using a Transmitter as RCIN was all zeros.

           

          • Rob Ratcliff > Michael Burmeister November 30, 2014 at 8:42am

            Thanks Michael for looking at the log.

            No transmitter was used in this test, only MAVLINK commands over the telemetry.

            What parameters in the log did look at to come to this conclusion? ATT/DesPitch and ATT/DesRoll?

            That is odd that roll and pitch was commanded. The only commands being sent over MAVLINK are RC OVERRIDE on Throttle just enough to get it into AUTO mode. Then the flight mode was set to AUTO. I noticed there is non-zero values for DesYaw as well. Not sure why that is.

            I wonder why the flight controller would command pitch, yaw and roll for TAKEOFF?

            One thing that I ended up having to do with my transmitter setup was remap the channels. If you notice, RCMAP_THROTTLE is 2 (usually 3) and RCMAP_PITCH is 3 (usually 2). Not sure if that is causing any confusion. It's worked fine on previous flights though. 

            I noticed that RCIN/C2 was at 1000, which should be 0% throttle in PWM. The normal value looks like its 0 for the RCIN commands. Shouldn't those all be at 1000?

            • Doug Walmsley > Rob Ratcliff December 1, 2014 at 7:07am

              Maybe I'm out in left field, but was all props checked to ensure they were tight to the motors?  After reviewing this, I recalled a year ago on my Hexa when I threw a prop and my Hex went into a crazy oscillation pretty much the way yours did.  Also check to see if any motors are loose on their mounts.  Just another thought to share.

              • Rob Ratcliff > Doug Walmsley December 1, 2014 at 8:28pm

                Thanks for taking the time to reply. My motors and props are all tight. 

                I should have the F-550 frame repaired this week by epoxying aluminum sheet metal across the breaks and will try a few simple tests to see what's going on. The biggest difference between the two flights was that the first one had the R/C on and the second didn't. I haven't had to have the R/C on in the past so I'm skeptical that there is a bug related to that, but its worth checking out.

            • Michael Burmeister > Rob Ratcliff November 30, 2014 at 10:19am

              Yes, that did confuse me.  Still the RCIN should be at a minimum of 1000 and a max of 2000. Yours are at 0.  That would mean Fly hard Left and Down.

              This is what the graph shows just before Auto was started.  Auto would then correct this because radio input is not used.

               

              Mike

               

               

              Wooble.png

              • Rob Ratcliff > Michael Burmeister November 30, 2014 at 11:54am

                I also noticed that the barometric altitude tracked opposite the integrated altitude, probably due to the wobble. I've seen this happen in the past when the vibrations are large. I wonder if the Kalman filter would do any better in situations like this?

                I would've hoped the flight control system could've recovered eventually. (Of course, if the Pixhawk was loose there wouldn't be much hope.)

                I've attached the plot.

                alt-pitch-roll-wobble.png

This reply was deleted.

Activity