EKF failsafe untriggered resulting in crash #1

[SudharssanMohan]

Bug report

Issue details

Reporting one of the discovered instance of an ArduCopter SITL execution , where the Extended Kalman Filter does not trigger fail safe landing, despite significant errors in Copter's mission resulting from compromised accelerometer values. EKF undergoes multiple lane and core switches, drone crashes before completing assigned mission. Significant deviation in position in the mission

Significant deviation in Velocity in the mission Version ArduCopter V4.3.0-dev (f5462df0)

Platform [X] Copter [X] Ardupilot SITL simulation

Logs Attached is the telemetry logs of the mission,BIN file for further log analysis and the mission used in this execution.

bug_report_1.zip

[amilcarlucas]

Can you please update to ArduCopter 4.4.0-beta3 and re-test?

[SudharssanMohan]

Thank you for getting back to me, does 4.5.0-dev work? That seems to be the latest version when I pulled from the repo now.

[rmackay9]

Hi @SudharssanMohan,

I think SITL is working fine in general and we have many automated tests that confirm that major features have not been broken. Can you explain what changes you made that led to the odd behaviour? Simply flying a mission should work and this is tested multiple times per day so if no changes were made then I suspect the issue is with the PC the tests are being run on.

[SudharssanMohan]

Hello @rmackay9 I am currently involved in a research project where we focus on making Ardupilot more resilient, especially to sensor spoofing attacks (attacks described in works like, example1 or example2 to give you an idea).

Therefore, the sensor values in the report is not the normal SITL-generated values but slightly modified to inject realistic malicious signals that can be generated in the real world (that is why I mentioned "compromised accelerometer values" in my initial report). Thus, I am reporting some instances I have discovered during my work, where EKF failsafe does not trigger to save the drone from a crash. The changes on my side is only in injecting malicious values in the accelerometer sensor generation phase of the SITL. Hope this clears some of your doubts!

[rmackay9]

@SudharssanMohan,

OK, interesting. So you've modified AP to somehow accept modified accelerometer values (perhaps by modifying AP_InertialSensor) so that you can inject some malicious values into the IMU readings. Hopefully those commits are self contained enough that you can rebase on master and come up to the latest version (4.5.0-DEV).

It's very possible that you'll see the same behaviour with 4.5.0 vs the earlier version but it would be good to be sure. That commit you've provided, f5462df0, is not a public commit so I can't see when it's from but it is probably a couple of years old.

It's also possible that AP's EKF failsafe is not tuned to notice malicious IMU input because it's been desired for more common real-life situations like high vibration or GPS glitches. By the way the EKF failsafe checks are here.

To investigate further it would be good to provide an onboard log. telemetry logs don't really have enough information to help with most investigations.

[SudharssanMohan]

@rmackay9 I believe I have provided both the .BIN logs apart from the .tlog for further analysis in my .zip file. If I misunderstood what you meant by onboard logs, do let me know. I am moving my tests to 4.5.0-dev in the meanwhile. Thank you for your time.

[SudharssanMohan]

@rmackay9 I have been porting my work to the latest version as asked, I have encountered similar cases to the one I reported in the older version (which I will report over time). Although this is a different case in terms of sensor values than the one reported initially, the nature of the bug report is the same. I am attaching the log for the lastest arducopter version for analysis. bin_and_telemetry_logs.zip Mission Plan used: mission.txt