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.

Views: 57437

Reply to This

Replies to This Discussion

What happened in your Tx to make it force the mode change to stabilize?

I reviewed the flight logs related to this incident.

You did not set up the Throttle Failsafe system on this. FS_THR_ENABLE = 0, and FS_THR_VALUE = 975. So these are default settings. RC3_MIN is 985.

I imagine what happened is that your RCTx automatically shut itself off due to inactivity. Your RCRx appears to be programmed to set Ch3 to min, 986 in this case. Ch5 goes from 1305, which is Mode 2 (Loiter) to 1171 (Stabilize). Since the Ch5 changes to something other than min, I assume you have programmed the failsafe in the Rx. You did not program it to drop below the FS_THR_VALUE, nor did you turn on FS_THR_ENABLE.

If you had set up the FS_THR system as recommended, your copter would not have crashed.

re-2. it should NEVER be possible to command a return to stabilize mode with throttle at zero in a copter that is in flight ! period!

I have [ in windy conditions or a very low battery ] chopped the throttle to low and hit stabilize mode while the copter is still several inches in the air over grass. It's the safest way to do something that you know for sure it's going to stop spinning the props.  If I land it alt hold the second it touch's the ground I chop the throttle and hit stabilize. Would it know it's landed?? There is that second or two it's not sure  [ or I'm not sure it does ] it's landed. If it's windy it can blow over and break a prop. Killing the throttle and hitting stab is very common.

But I do catch your drift. Maybe is should check it's above 10 meters and you hit stab with the throttle low it flies at 1/2 throttle until the pilot moves his throttle stick to 1/3??  Food for thought I guess. 

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.

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.


Hi Rob,

    I tried on multiple occasions to get THR_FS set.(why is this NOT set in the IRIS configs as delivered?)

it stayed greyed  out in mission planner (release and current git pull)  is there some secret to setting this?

whether I used the original radio TH-9X  gear at 2.4 or the OpenLRSng/OrangeRX gear I was working with.

I concur on the settings you observed byproduct of E9xR in the 9XR as delivered and what was found during setup.

RCTX was active and running.. as I said I got a beep indicating a comms error and then the preempt by the RCTX over the commanded flight mode from the GCS...

the last is what the problem is... its the preemption by the RCTX on a comms error over a GCS commanded flight mode.



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..


Hi Rob.

actually revise the above.. THR_FS somehow was unset as I did set this before

.. I remember doing so.. the grey out was related to another issue

     and again its the preemption on a RCTX error resetting GCS commanded modes I am having a problem with here..

and so will most purchasers of the IRIS+ whether the defect results in a crash or simply a near miss..

and when it occurs at 10 meter up during landing?? its a disaster...think falling brick with pointy feet :(

A FMS precedence and preemption algorithm specified as a formal mechanism and not simply a THR_FS is what is needed here to prevent these occurrences..

I am SURE I  am NOT the only one verifying tablet GCS/telemetry modes and finding these issues...

I may be the only one willing to make a strong effort at having it change ..

I am looking at the code to see if a precedence/preemption can be specified safely in the present code structure or if things need to be refactored to accommodate same...


ps I would venture to say I could put most of the required code to prevent this  into control_stabilize.pde.. and flight_mode.pde.. but I am seeing NO code at present to decide precedence of the current control channel and whether preemption allowed  for any mode..

  am I missing something here?? ie was preemption planned for and allowed or did it just grow this way from code drift and  decisions not oriented with safety as the overarching goal..?

The preemption is both planned and allowed, and is not a bug or omission.  At present, it remains the only mechanism to stop motor power when using the tablet as primary controller.  At present, the only other way to stop motor power when using the tablet control, is to switch to Stabilize mode from the tablet flight mode pick-box.  This takes significantly longer to do, and also poses it's own set of risks, because the mere fact that stabilize mode is in that pick-list makes it too easy to select it be accident, with the exact same results you experienced.

Since most tablet controllers do not even have "virtual sticks" there is no way to "raise the throttle", and stabilize mode is basically kill-mode.  However, the reality of this situation is not obvious to most beginners "What is Stabilize mode?  Oh no."

I am actually concerned about that problem, and there is already discussion to remove the acro and stabilize modes from the tablet pick-list.  However, this puts us in exactly the same problem... if you have no RC Tx, you have no ability to kill power, AT ALL.  And that cannot be allowed.

As stated on drones discuss, I believe the proper path forward, is add a kill-switch function to the tablet flight screen.  Then and only then can we discuss removing acro and stabilize from the pick-list, and preventing RC Tx pre-emption.

And what if you are trying to land at the top of a 10m hill in wind?  What if you are trying to prevent injury to a boy who has climbed a 10m tree?  What if a manned aircraft has unexpectedly appeared on an engine-out short-final, and you need to drop out of the way FAST.

The system should NEVER second guess the pilot's primary and ONLY ability to stop those props when needed.

That kill mode sounds like a damn good idea Rob. Perhaps 2 or maybe even 3 quick taps on the screen so no mistakes. 

hey rob.. separate kill/CRASHME switch is what I suggested (and still dont think is safe.)

if this function is needed in the first place

just DONT tie it to a flight mode such as stabilize and you lose my objections..

and lock off stab switch/thr=0 and get a precedence system in there instead of catch as can as it presently is..

btw these systems ARE being flown over folks heads by 3DR employees(dont even get me started on Maker Faire last year) and others on a daily basis.. time to get used to that reality and code appropriately..

does any GCS have virtual sticks currently??

the code is long out of droidplanner/tower  and no longer works at present when compiled back in.....

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service