Developer

ArduCopter-3.2.1 Beta Testing

ArduCopter 3.2.1-rc2 (release candidate #2) has completed beta testing and has been released as the official version available through the mission planner and other ground stations.

Changes from AC3.2 are listed below and in the ReleaseNotes:
1) Enhancements:
    a) reduced twitch when passing Spline waypoints
    b) Faster disarm after landing in Auto, Land, RTL
    c) Pixhawk LED turns green before arming only after GPS HDOP falls below 2.3 (only in flight modes requiring GPS)
2) Safety Features:
    a) Add desired descent rate check to reduce chance of false-positive on landing check
    b) improved MPU6k health monitoring and re-configuration in case of in-flight failure
    c) Rally point distance check reduced to 300m (reduces chance of RTL to far away forgotten Rally point)
    d) auto-disarm if vehicle is landed for 15seconds even in Auto, Guided, RTL, Circle
    e) fence breach while vehicle is landed causes vehicle to disarm (previously did RTL)
3) Bug Fixes:
    a) Check flight mode even when arming from GCS (previously it was possible to arm in RTL mode if arming was initiated from GCS)
    b) Send vehicle target destination in RTL, Guided (allows GCS to show where vehicle is flying to in these modes)
    c) PosHold wind compensation fix
    d) prevent infinite loop with do-jump commands pointing at each other
    e) pixhawk memory corruption fix when connecting via USB
    f) vehicle stops at fence's alt limit in Loiter, AltHold, PosHold (as it did in AC3.1.5)
    g) protect against multiple arming messages from GCS causing gyro calibratoin failure

Thanks to Raph for the video.  This is actually a video from AC3.2 until we have one specific to AC3.2.1.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

          • I've found the more I've taken off and flown in Stab the less I think about the 50% rule when switching modes. My "thumbs" just know it's a manual mode.

            Best,SC

            • thats FINE if you have the RCTX in hand and are actively flying the craft with it..

              this however is GCS guided flight where the xmitter is NOT in hand but powered on as a backup control and the GCS is the main control in hand...and again this occurred in a commanded landing sequence from 10 meters up..

                     hzl

          • I agree, I am nervous with stabilize mode for exactly this reason. It's possible to set it to zero and it to fly like a brick. I would prefer there was some kind of stabilize fail safe level where you can't put the throttle lower than that and it does a controlled landing. Maybe it should do just that - switch to land if the throttle goes below a certain level.

  • If you graph the actual GPS height it looks ok.  When the GPS locked in it must have miss calculated the relative height.

     

    Barometer looks good as it seems to be following the pressure.

    Throttle out though doesn't seem to be following RCIN though.

     

    • The 'miscalculation of relative height' though has been a constant for the past few days. Here's another log of another test I just did, same problem, same rough landing. I did another test because I eliminated what I thought could have been a potential source of vibration, but no cigar.

      I have no idea why the throttle is behaving that way, I'm happy to hear any good guess.

      47.BIN

      https://storage.ning.com/topology/rest/1.0/file/get/3702552718?profile=original
      • I have swapped in a spare pixhawk (brand new) and the sudden jump in relative altitude that I've seen at boot went away. I had tried completely wiping the old pixhawk parameters to default before going for the swap and that didn't fix it.

        I think I'm going to try loading the old parameter file in the new pixhawk and see if the problem shows up again.

        What kind of hardware problem could cause something like this? The IMU reads seem legit and I haven't swapped the GPS unit so it's got to be something in the pixhawk. Bad barometer? But the barometric altitude looks fine, what is used to compute the GPS relative altitude?

  • Since the last couple of days my hexacopter has been exhibiting weird altitude changes in loiter. It files fine in stabilize:

    3701951144?profile=original

    There seem to be some discrepancy between the barometric and GPS altitude (Log Attached). I would suspect the barometer but it has never done this before and the configuration hasn't changer. Any pointer on what to look for?

    Thanks,

    Alex

    45.BIN

    https://storage.ning.com/topology/rest/1.0/file/get/3701951066?profile=original
  • I think it's in 3.2.0 as well don't know when it got broken.  I think it will be fixed in 3.3.

    Can you change your channel mapping to see if that fixes the issue?

    I don't know how the bug effects the channels exactly.

     

    • Can you point we in the code where you think this is happening? I did quite a detailed look at 3.2.1 and could not see anything obvious, the rcmap logic seems sound (although there are some methods in RC_Channel that could mess this up, but these seem not used in APM:Copter). Even if it's something to do with the offsets, the hard over-never returning behaviour is not consistent with that.

      • I don't know where that is but I did change my RC input to match yours.

        First I just reversed the channels and did a test.  All went well and the copter work as before.

        Then I did the radio calibration as you would due.  After that I could not arm the copter  Throttle failsafe.

        I disabled the Throttle Failsafe and continued.

        Guess what, Just a touch on the throttle and it wants to flip over to the right.  Logs match what you are getting.

        Maybe the good news here is don't do the radio calibration after switching back...

         

This reply was deleted.

Activity