hi Marc,
I’ve been through this log in detail now, and also talked to Paul about controller changes that we can make to avoid it.
First off, here is the key graph that shows all of the features that led to the crash:
http://uav.tridgell.net/MarcMerlin/guided_crash.png
It is a very busy graph, so I’ll try and explain the key features.
This graph covers only the time your plane was in GUIDED on the fence breach. The red line shows the height, which initially rises a bit, then descends from 70m down to zero.
The orange line shows TECS.sp, which is the TECS version of the airspeed estimate. This is a smoothed version of the airspeed, converted to a true airspeed. You can see airspeed gets as low as 7m/s at one point.
The light brown line is TECS.sp_dem, which is the TECS demanded airspeed. That doesn’t change much from the configured minimum airspeed.
The black line is PIDP.I, which is the pitch integrator. That plays a vital role in the crash. More on that later.
The grey line is RCOU.Ch2 which is the elevator servo output. The trim elevator was 1532, and numbers below 1532 are demanding up elevator.
The yellow line is throttle, where 1800 is maximum throttle (due to THR_MAX being 80).
The sequence of events is as follows:
- fence breach, and enter guided mode, trying to climb
- the TECS controller immediately demands pitch up and starts ramping the throttle up. We are now at 9:26:12 on the graph X time axis
- the plane responds and does initially pitch up. It also starts to lose airspeed.
- at 9:26:13 it enters an underspeed condition as the airspeed drops below the critical ARSPD_FBW_MIN level. Throttle is immediately pegged at maximum (which is 80%) and pitch demand goes down to try to gain speed.
- At this point we see the first breakdown of pitch control. The demanded pitch (blue) and actual pitch (green) start to separate. The pitch controller is not managing to produce the down pitch that is wanted. The pitch controller starts to pile on more down elevator (grey line) to try to produce the down pitch that is wanted. Eventually at 9:26:15 the pitch does come briefly under control.
Now I should explain a bit about the underspeed state which the plane is in at this point. Underspeed is declared when airspeed is below 0.9 of the minimum airspeed. Once underspeed is declared then throttle goes to maximum and the TECS pitch controller tries to control airspeed, aiming for the minimum configured airspeed (which is 12m/s for this plane). The idea is that a plane at maximum throttle with airspeed at minimum airspeed should produce a maximum safe climb without stalling. The underspeed condition is not cleared until the plane reaches its desired altitude.
This emergency condition assumes that the plane will respond properly to pitch control while at maximum throttle, and this is where things really start to go wrong in this flight. The TECS controller is demanding down pitch at full throttle but the plane doesn’t initially start to speed up. It is not till several seconds later (at 9:26:21) that the plane finally start to gain speed beyond the target speed.
When it does finally gain speed the TECS controller starts to release the downpitch demand, and starts demanding positive pitch at 9:26:23. The elevator is initially still down, and that is because the pitch controller integrator (the black line) has wound up. The TECS controller ends up saturating at a demanded positive pitch angle of 15 degrees (at 9:26:24) but by this time the pitch controller has completely lost control of the pitch. The actual pitch (green) bears very little resemblance to the demanded pitch (blue).
There are two causes of this. One is the pitch integrator. The PTCH2SRC_I value is quite low, which implies a long slow time constant. It takes a long time for that integrator to unwind and slowly apply more up elevator. The second problem is the pitch gain (the P value) is too low. That can be seen earlier in the flight when pitch control is also not good.
ok, so what can we do about it? I think we will be making several code changes because of this, although not perhaps the ones you may be expecting.
The first thing Paul and I want to add is a detector for “full throttle is pushing the nose down”. It looks like when the underspeed condition triggered full throttle that it caused pitch control to get much worse. The plane just can’t handle sustained full throttle while maintaining pitch control. What we are thinking of doing is adding a rule like this:
- if the following conditions are all true for 2 seconds:
- we are in underspeed condition
- we are more than 20% above the minimum speed
- we are descending
then we will cut throttle back to the TRIM_THROTTLE, only allowing it to slew back up over another 2 seconds. This should give the airframe time to recover from the “too high throttle” state.
The second thing we are going to do is work out a minimum acceptable level of I term for the pitch controller (ie. PTCH2SRV_I). Too many issues are caused by the very slow response of the integrator in pitch, as happens in this flight. We will set the minimum I term to correspond to a time constant of around 3 seconds. That should reduce the problems of TECS not getting the pitch it is demanding.
The log doesn’t actually show a TECS bug. TECS is actually operating as it was designed to operate. It just assumed that airframes respond in a reasonable manner, and some airframes don’t respond well to full throttle.
I would still be interested in knowing what your flaps setup was on this plane, just because there is a possibility that flaps contributed to the loss of pitch control.
