We originally baselined on ArduCopter 4.2.3 and are currently using a slightly modified version of 4.3.7, using Throw mode to deploy an sUAS (the unit) from a moving aircraft.  It works as expected most of the time but occasionally has some very odd behavior we are trying to eliminate.  On occasion, it appears the unit loses all sense of altitude and/or uprightness.  Instead of maintaining altitude in an upright position, the unit exhibits one of several unacceptable behaviors.

1) The unit will constantly ascend with at least one motor at full speed. In one case CTUN.ALT shows a descent of ~148m/s while the unit is actually climbing at 15 m/s. CTUN.ALT resets every 10-11 seconds as the EKF resets, with both EKFs having errors in the same direction. In one case, the EKF errors started while the unit was in the aircraft waiting for release.

2) The unit will descend with at least one motor at MOT_SPIN_MIN.  Similar to item one above, but both EKFs erroring opposite to how they were in item one above.  The unit incorrectly thinks it is climbing and keeps motors running as slow as possible to try and prevent climbing.  Eventually, it runs into the ground.

3) The unit will alternate between the two states, ascending at full speed while under control of one EKF and descending at MOT_SPIN_MIN while under control of the other EKF.

Note that in the three cases above, switching to Stabilize mode permits full RC control of the unit and allows an RPIC to maintain controlled flight and land the unit safely.

4) But the most extreme case seems to be when the unit not only has an altitude error, but a significant pitch and roll error as well.  In these cases the unit will fly full speed in an unplanned direction and permit virtually no control while in Altitude Hold mode.  In addition, the unit will not respond as expected in Stabilized mode.  When this happens the best answer is to cut throttle or disarm mid-air over a safe landing zone.

Some other things to note:

1) GPS is not available early on in the process.  The EKF_SRC1_xxx parameters are set to not use GPS and GPS data flow is turned off at boot up and remains off until the unit has been released and had opportunity to obtain valid GPS.  After a successful THROW, the unit is placed into Altitude Hold mode (another minor modification).  When valid GPS is available GPS is turned on, the EKF_SRC1_xxx variables are updated to use GPS, and the aircraft is switched into a position-controlled mode such as AUTO.  This process is managed via script and works well.

2) The unit is powered on while inside another in-flight aircraft.  Twenty (20) seconds after boot-up a script starts running that places the unit into THROW mode and arms the unit.  When the aircraft gets to the designated release point the unit is released and THROW mode processing is initiated.  The modifications to Throw mode are as follows:

2.a) Throw detection has been simplified to check for any motion and for a timer set by the custom parameter LB_DETECT_MS.  When the unit is released, it senses a switch closure and waits the specified number of microseconds before declaring Throw_Detected.  This is done for two reasons.  One, waiting ensures the unit has time to clear the host aircraft before starting to spin motors.  Two, on occasion, related to the items above, the unit would think it was climbing and not falling and therefore not move to the next phase.  This simplified version will accept any vertical movement after the waiting period.

2.b) A duration check was added to the uprighting phase of Throw mode.  Initial testing indicated that a unit tumbling fast enough could still be unstable but momentarily be in an upright position at just the right time permitting the next phase to start prematurely.  The parameter LB_UPRIGHT_MS is typically set to 50 milliseconds.  With this setting Throw stage 3 is typically only reported once in the log file.  In File#43 it continues trying to find upright for ~600 milliseconds before eventually declaring it.

2.c) A duration check was added to the controlling height phase of Throw mode.  Initial testing indicated that the unit could declare that height was being controlled within a microsecond even though it was not quite stable.  To ensure that height was actually stable the parameter LB_HEIGHT_MS was added as a check to make sure altitude was maintained over a longer period.  Typically, it is set to 500 milliseconds and is satisfied immediately upon completion of the specified duration.  In File#43 it continues for 5.5 seconds before the RPIC switches to Stabilize mode, and eventually cuts throttle.

2.d) In addition, to the timers, in an attempt to overcome potential position control errors being induced when powering on and being placed into Throw mode while in motion, the command pos_Control->Standby_xyz_reset() was added to the Throw_Disarmed and Throw_Detecting cases.

As noted earlier, everything works as expected 9 out of 10 times.  When the unit recovers from Throw mode with good attitude and altitude control it consistently and properly works through the rest of the steps, switching modes, utilizing GPS, and flying an AUTO mission as expected.  We are having difficulty finding what root cause / edge case is causing the occasional ‘catastrophic’ failure.