ardupilot icon indicating copy to clipboard operation
ardupilot copied to clipboard

AP_Arming: Allow memorizing ICE state

Open WickedShell opened this issue 1 year ago • 5 comments

With the options to start the engine while disarmed I've had some intermittent arming failures due to vibration on the ground causing a problem with the cube between the vibe and non vibe isolated IMU. This is amplified with ground resonance, which is triggering the accel inconsistent check.

This allows us to keep the benefit of having a reasonably tight check for the accelerometer consistency, but once the engine is started we simply remember if we were previously passing the check and keep the check passed.

This was tested on the plane that exhibits the problem, with the option set I can arm while the engine is running, even with a tight threshold on accelerometer consistency.

WickedShell avatar Jan 05 '24 22:01 WickedShell

needs rebase to re-trigger CI checks, as the above esp32 issue is now fixed.

davidbuzz avatar Jan 08 '24 09:01 davidbuzz

This has now been flown. Found a slight bug where I was comparing to if the state was starting or higher, but I needed to change it to start height delay or start height to cope with the problems from the engine still bouncing between starts when it doesn't fire up the first time.

WickedShell avatar Jan 12 '24 22:01 WickedShell

i think it would be simpler to skip that test in pre-arm if ICE reports the engine is running

I thought about it, what I liked about this method is it lets me still keep a protection level for a fundamentally bad set of IMU's. The check was clearly added for a reason, and it seemed like it was worth keeping. I could also have just raised the accelerometer threshold used in the test until it passed, but I did want to sanity check the accelerometers first, which if we skip the test means we don't get the protection anymore.

WickedShell avatar Jan 16 '24 18:01 WickedShell

@WickedShell another possibility is that we offer another data product from AP_InertialSensor or AP_AHRS which is a much lower frequency filtered IMU. Maybe 3Hz or so? This could be calculated in AP_AHRS in the update() function, filtering the current filtered IMU data but at a fixed low frequency. Using 3Hz should be enough to avoid engine RPM, which would usually be above 30Hz

tridge avatar Apr 22 '24 00:04 tridge

@WickedShell can you upload a log where the issue is shown? I can apply a 3Hz filter to it and see if it would work

tridge avatar Apr 22 '24 00:04 tridge