APM:Plane responds very poorly to a stall

As you can understand, testing this is scary and risks damage to your aircraft so I’ve not done a lot of it.

I believe you have to actually stall while in an auto mode. Then (probably) some I-terms build up and drive the ailerons/rudder/elevator hard over until you manually recover.

In the video above, I believe the plane was in a spin which needs a more active correction to recover from in short time.

Did you notice that in the OSD video from the cloud penetration, at 12 seconds into the video flight mode changes from AUTO to CRUZ while exactly in this moment the adventure begins.
At 15 seconds (3 secs later) flight mode changes to AUTO again.
Hardly a coincidence, right?
Any theories on this?

I don’t think my switch to cruise and back had any impact on the event. It just happened to occur right before the pitot got clogged.

how do you know it got clogged ?

Anyway - I see no actual stall-handling code. There is code to maintain desired airspeed, drop nose when needed - but I did not find anything that changes roll/yaw.

what control surfaces did the involved planes had ? ailerons, and rudder or more ?

[quote=“Noircogi”]Switching to manual does work to recover normally.

I think in the video above I just didn’t give it enough time in manual to recover from the extreme state it was in. I knew I was going to lose video any second.

You need to have the onset of the stall occur in an auto mode to get into this state. I know for certain auto and RTL will do it. I believe that it should also happen in cruise but I haven’t seen it myself.

Simply setting FBW_MIN/cruise close to stall speed, then hitting RTL with the plane heading away from launch will probably induce the situation in most cases. Once the spiral dive happens, you can switch to manual and pull it right back out.[/quote]

Flying in fbwa (I don’t have an airspeed sensor) and banking while at too slow an air speed will also cause the death spiral :frowning:

Happened to me, was flying too slow and didn’t realise it. Made a left bank to come back around and the plane just went full down elevator and full right aileron. Didn’t have time to react as I was at around 10-12meter high, but was high enough to smash in the front of my 1400mm Cessna :frowning:

MarkM - do you have the log from that event ?
It would eliminate the airspeed logic from being involved in this.

I have dug out and attached the log file and just uploaded the video from the flight as well.

I don’t have any telemetry logs as -

  1. I almost never use telemetry and
  2. the telemetry modules I have are 433mhz which I can’t use with my new UHF system

youtube.com/watch?v=AcfnEKs … Vn30YCftEw

MarkM : telemetry logs are not really helpful in this case.
the .log is clear , your specturum was not to blame (as you guessed in the video)

  • something very bad happened indeed, this is the proof I were hoping for - a good pixhawk-log - will spend some time reading it.

BTW: I got some corruption warning about 1 line when loading it - if you have the .BIN, feel free to post it :slight_smile:

  • I think the .log is good enough anyway.

Thanks for the log - first very clear proof, because it logs both RCIN and RCOUT

No bin file as its from an apm board.

Glad it’s helpful though.

I tried to reproduce something similar today after a commercial flight with arspd_use=1 - and covered the pitot.
Took of manually, switched to auto , IAS was ~2m/s min arspd was 13, still - all that happened was that AP leveled wings, set high throttle and lowered nose. , same for cruise and fbw-a

One day with more time to spare I’ll disable arspd_use , and retry then.