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?
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
More ChibiOS fixes for I2C storm
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
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
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
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
mRobotics ControlZeroF7 board support
Motor Test fixed by removing delay that triggered CPU Watch Dog
Copter 3.6.10-rc1 08-Jul-2019
Changes from 3.6.9
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
Ublox F9 GPS support
Integrated CPU Watch Dog for STM boards including logging of reset reason
ChibiOS I/O firmware for ChibiOS builds to support Spektrum binding
Auxiliary switch changes always logged
CUAVv5 Nano LED fix
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
CX-OF flow sensor enabled on all boards
CUAVv5 Nano board support added
RangeFinders supported on all I2C ports
Compass maximum acceptable offsets increased
Septentrio GPS driver loses logging of camera feedback which could cause lag
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
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 ?