Parachute deployed for no reason?

Log here

Vehicle was sitting stationary for 30ish seconds and then the autopilot deployed the parachute. Vehicle was stable until then. Parachute was not triggered manually. Has anyone seen anything like this before? Any ideas as to what caused it?

Arducopter 3.6.8
Relevant HW:
Emlid Edge
Frsky Horus X10s w/ R9M 900 module.
R9 Slim.

Please update to copter 3.6.12

Was there a change there that would cause this to happen? I didn’t see anything in the change-logs. Updating our particular setup is not an easy task as we have quite a few vehicles that would need to be gone through.

I would guess what amilcarlucas is referring to is I2C storm. This is reason enough to update regardless of the issue you are seeing. Note in your flight log how ~100msec before the Chute message logging stops for many variables. Baro for example.

We aren’t using I2C, aren’t running Chibios, and aren’t using the cube. We are planning on updating soon, but I’m looking for reasons the aircraft decided it was crashing when it wasn’t. It seems like this could be a serious issue. According to the documentation nothing has changed with the parachute logic so I don’t see how updating would fix that particular issue.

How sure are you that the various EKF fixes do not solve your issue?

Copter 3.6.12 13-Dec-2019 / 3.6.12-rc1 06-Dec-2019
Changes from 3.6.11

  1. More ChibiOS fixes for I2C storm
  2. COMPASS_SCALE param to allow manual correction of compass scaling

Copter 3.6.11 01-Oct-2019 / 3.6.11-rc1 16-Sep-2019
Changes from 3.6.10

  1. EKF and IMU improvements:
    a) IMU3 enabled by default if present
    b) IMU3 fast sampling enabled by default on Cube autopilots
    c) EKF protection against large baro spikes causing attitude error
    d) EKF origin fixes (consistent across cores, set externally only when not using GPS)
    e) EKF logging of 3rd core
  2. Minor enhancements:
    a) Land mode supports heading requests (ie. ROI)
    b) Support Hexa-H frame
    c) MatekF405-STD binaries created
    d) Benewake TFminiPlus lidar support
  3. Bug Fixes
    a) Barometer health checks include sanity check of temperature
    b) Lightware serial driver handles invalid distances
    c) IO firmware fix involving delayed writes to serial ports (ChibiOS only)
    d) CAN Compass fis to for unintialised device IDs
    e) mRo x2.1-777 USB ID fix
    f) ChibiOS fix for I2C storm

Copter 3.6.10 29-Jul-2019 / 3.6.10-rc2 2-Jul-2019
Changes from 3.6.10-rc1

  1. mRobotics ControlZeroF7 board support
  2. Motor Test fixed by removing delay that triggered CPU Watch Dog

Copter 3.6.10-rc1 08-Jul-2019
Changes from 3.6.9

  1. EKF improvements:
    a) learns biases even for inactive IMUs
    b) EKF uses earth magnetic field model to reduce in-flight compass errors
    c) EKF switches to first healthy IMU when disarmed
    d) IMU fix for dropped samples during high CPU usage
    e) Optical flow fusion start fix when some gyros disabled
  2. Ublox F9 GPS support
  3. Integrated CPU Watch Dog for STM boards including logging of reset reason
  4. ChibiOS I/O firmware for ChibiOS builds to support Spektrum binding
  5. Auxiliary switch changes always logged
  6. CUAVv5 Nano LED fix
  7. Solo Gimbal fix when some gyros disabled

Copter 3.6.9 27-May-2019 / 3.6.9-rc1/rc2 30-Apr-2019
Changes from 3.6.8

  1. CX-OF flow sensor enabled on all boards
  2. CUAVv5 Nano board support added
  3. RangeFinders supported on all I2C ports
  4. Compass maximum acceptable offsets increased
  5. Septentrio GPS driver loses logging of camera feedback which could cause lag
  6. Bug Fixes:
    a) Acro mode leveling fix for when ACRO_TRAINER was 1
    b) Tradheli collective position pre-arm check removed
    c) Fallback to microSD for storage fixed
    d) GPS blending memory access fix that could lead to unhealthy GPS
    e) fixed POWR flags for 2nd power module on fmuv3 boards
  7. bootloader binary update for many boards

A custom version of AC 3.6.8?

Thank you, that answers my question a lot better than just saying “go update”

It has a custom mixer.

If we can believe the crash_check.cpp:180 line, then the chute was released manually. Since there were no RC control and copter was in guided mode, it could be a command from the GCS. Do you have Mavlink log from the GCS to check this ?