Quadrucopter termination

Hi! Could someone help me analyze this log? We are experiencing a failsafe, but I’m not sure what the root cause might be

I have extracted the csv from the ulog and I have reviewed all the tables on the timestamp when the terminate trigger (second 732 aprox). We can observe a lack of data between seconds 732.4 and 734 in the following tables:

vehicle_gps_position_0

timestamp timestamp_sample time_utc_usec device_id lat lon alt alt_ellipsoid s_variance_m_s c_variance_rad eph epv hdop vdop noise_per_ms jamming_indicator vel_m_s vel_n_m_s vel_e_m_s vel_d_m_s cog_rad timestamp_time_relative heading heading_offset heading_accuracy rtcm_injection_rate automatic_gain_control fix_type jamming_state spoofing_state vel_ned_valid satellites_used selected_rtcm_instance
732223609 0 1756730244600000 8748035 432380268 -19741499 164240 213861 0.004096985 0.28634223 0.013999288 0.0109998835 0.5800781 0.8598633 0 0 0.12435434 -0.112 0.042000003 0.034 2.782822 0 nan nan nan 0 0 6 0 0 1 32 0
732414590 0 1756730244800000 8748035 432380266 -19741497 164240 213861 0.0043563843 0.33151084 0.013999288 0.012000201 0.5800781 0.8598633 0 0 0.12243366 -0.105000004 0.046000004 0.043 2.7286828 0 nan nan nan 0 0 6 0 0 1 32 0
734019320 0 1756730246400000 8748035 432380259 -19741478 164130 213751 0.009216309 0.17370577 0.013999288 0.01000083 0.5800781 0.8598633 0 0 0.67360675 0.19600001 0.12100001 0.633 0.55307704 0 nan nan nan 0 0 6 0 0 1 32 0

estimator_gps_status_0

timestamp timestamp_sample position_drift_rate_horizontal_m_s position_drift_rate_vertical_m_s filtered_horizontal_speed_m_s checks_passed check_fail_gps_fix check_fail_min_sat_count check_fail_max_pdop check_fail_max_horz_err check_fail_max_vert_err check_fail_max_spd_err check_fail_max_horz_drift check_fail_max_vert_drift check_fail_max_horz_spd_err check_fail_max_vert_spd_err
731701513 731522872 nan nan nan 1 0 0 0 0 0 0 0 0 0 0
732479021 732299607 nan nan nan 1 0 0 0 0 0 0 0 0 0 0
734083625 733904337 nan nan nan 1 0 0 0 0 0 0 0 0 0 0

estimator_gps_status_1:

timestamp timestamp_sample position_drift_rate_horizontal_m_s position_drift_rate_vertical_m_s filtered_horizontal_speed_m_s checks_passed check_fail_gps_fix check_fail_min_sat_count check_fail_max_pdop check_fail_max_horz_err check_fail_max_vert_err check_fail_max_spd_err check_fail_max_horz_drift check_fail_max_vert_drift check_fail_max_horz_spd_err check_fail_max_vert_spd_err
731481531 731294432 nan nan nan 1 0 0 0 0 0 0 0 0 0 0
732481793 732299200 nan nan nan 1 0 0 0 0 0 0 0 0 0 0
734097281 733903975 nan nan nan 1 0 0 0 0 0 0 0 0 0 0

estimator_gps_status_2

timestamp timestamp_sample position_drift_rate_horizontal_m_s position_drift_rate_vertical_m_s filtered_horizontal_speed_m_s checks_passed check_fail_gps_fix check_fail_min_sat_count check_fail_max_pdop check_fail_max_horz_err check_fail_max_vert_err check_fail_max_spd_err check_fail_max_horz_drift check_fail_max_vert_drift check_fail_max_horz_spd_err check_fail_max_vert_spd_err
731482641 731294570 nan nan nan 1 0 0 0 0 0 0 0 0 0 0
732479764 732299340 nan nan nan 1 0 0 0 0 0 0 0 0 0 0
734086189 733904070 nan nan nan 1 0 0 0 0 0 0 0 0 0 0

on sensor_gps, we have data:

timestamp timestamp_sample time_utc_usec device_id lat lon alt alt_ellipsoid s_variance_m_s c_variance_rad eph epv hdop vdop noise_per_ms jamming_indicator vel_m_s vel_n_m_s vel_e_m_s vel_d_m_s cog_rad timestamp_time_relative heading heading_offset heading_accuracy rtcm_injection_rate automatic_gain_control fix_type jamming_state spoofing_state vel_ned_valid satellites_used selected_rtcm_instance
731409820 0 1756730219800000 8748035 432379983 -19742149 159560 209181 0.012992859 1624.1072 0.013999288 0.01000083 0.5698242 0.8598633 0 0 0.028142495 0.002 0.002 0.028 0.7853982 0 nan nan nan 0 0 6 0 0 1 32 0
732414590 0 1756730220800000 8748035 432379983 -19742149 159570 209191 0.005329132 2.3695562 0.013999288 0.01000083 0.5698242 0.8598633 0 0 0.049739324 0.032 -0.035 -0.015000001 -0.8301444 0 nan nan nan 0 0 6 0 0 1 32 0
733419523 0 1756730221800000 8748035 432379995 -19742161 160520 210141 0.013221741 0.2916324 0.013999288 0.0109998835 0.5698242 0.8598633 0 0 1.4803926 0.20400001 0.061000004 -1.465 0.29055712 0 nan nan nan 0 0 6 0 0 1 32 0

estimator_innovations:

timestamp timestamp_sample gps_hvel[0] gps_hvel[1] gps_vvel gps_hpos[0] gps_hpos[1] gps_vpos ev_hvel[0] ev_hvel[1] ev_vvel ev_hpos[0] ev_hpos[1] ev_vpos rng_vpos baro_vpos aux_hvel[0] aux_hvel[1] aux_vvel flow[0] flow[1] terr_flow[0] terr_flow[1] heading mag_field[0] mag_field[1] mag_field[2] gravity[0] gravity[1] gravity[2] drag[0] drag[1] airspeed beta hagl hagl_rate
732199754 732029648 -0.012723044 -0.003446214 -0.020076772 0.006489992 0.0031814575 -0.007370949 0 0 0 0 0 0 0 0.13182116 0 0 nan 0 0 0 0 0 -0.22372743 0.49772236 -0.32996523 -0.5582536 0.19394527 -0.009353897 0 0 0 0 0 0
732697905 732528014 -0.009713165 0.019469969 -0.024993958 0.013143063 -0.0047597885 -0.008559227 0 0 0 0 0 0 0 -0.09359217 0 0 nan 0 0 0 0 0 -0.21780257 0.46236062 -0.3248655 0.014335255 -0.011641783 4.1404975E-05 0 0 0 0 0 0
733196362 733026489 -0.009713165 0.019469969 -0.024993958 0.013143063 -0.0047597885 -0.008559227 0 0 0 0 0 0 0 0 0 0 nan 0 0 0 0 0 -0.21780257 0.46236062 -0.3248655 -0.4263883 0.31041643 -0.014648585 0 0 0 0 0 0
733694569 733524648 -0.009713165 0.019469969 -0.024993958 0.013143063 -0.0047597885 0 0 0 0 0 0 0 0 0 0 0 nan 0 0 0 0 0 -0.21780257 0.46236062 -0.3248655 0.21225813 0.37863955 -0.009634689 0 0 0 0 0 0

During the timestamp, the estimator innovations are static, and I suppose the EKF2 triggers the flag of attitude invalid, and the drone goes from OFFBOARD to TERMINATE mode.

  • if GPS data are not valid, why does EKF2 not take into account the IMU data?

  • How can I minimize this kind of issue?