I took a quick look, and the way I see it you stalled it. Airspeed went as low as 7,5 m/s, you pitched up slightly and stalled the plane.
When you tip stall a wing plane (such as the Zephyr), it will most likely result in the well known death spiral. (google it)
Easy ways to remedy this:
1: Fly faster
2: Move CG forwards.
3: Go easy on the control surfaces. You might want to reduce throw a little bit.
And some general advice: Don't try to fly tight corners with your wing plane, it isn't built to do so.
Have fun flying!
Thanks for the response. I was the "pilot" for the events Michael described above. Actually, we are reasonable sure that both death-spiral events were triggered by tip stalls. The issue we are trying to address is that in "STAB" mode, APM appears to be unable to recover from such an event. In both cases it drove the ailerons to full left and held elevator neutral. In both cases we had a GoPro mounted in the nose, and the spiral mode is incredibly axial. Manual intervention while in "STAB" mode was ineffective - I could not override the AP commands, but in both cases, switching to manual mode immediately stopped the roll, and a bit of up elevator recovered stable flight.
The issue I think we are trying to make is that without manual intervention, it would appear that APM is unable to recover from a tip-stall, in fact it exacerbates the problem, guaranteeing failure. Certainly one approach is to push the lower speed limit up in an attempt to avoid stall. However, I would suggest that if that is the sole solution for the problem, one would be advised to never utilize APM in anything expensive or dangerous.
Not having gone through the control loops used in "STAB" mode, but based on surface deflections on the ground due to roll and pitch, it appears that gyros are not used at all, and that STAB control laws are based entirely on accelerometers. I'm curious if a nose-down attitude results in a sort of Gimbal Lock due to a "divide-by-zero."
You are correct sir!
APM hasn't got any coding to detect stalls (yet)
Your best bet is to tune and fly the plane so, that tip stalls are avoided.
If my plane stalls, it it stalls like a brick. Eventually it will gain enough speed in a nosedive that the APM recovers. But only if I fly in FBWA.
If I fly in cruise mode and let it stall on purpose by setting the airspeed limit way to low, it will recover, only to stall again quickly afterwards.
Best is to avoid stalls all together while the APM is in control, at least until a stall detection algorithm is coded in a possible future release.
Oh: If you set your limits right, and you use an airspeed sensor, you will find it nearly inpossible to stall the plane in cruise mode and all other automatic flight modes. At least, I am unable to!
And: I never use STAB. I find it an annoying flight mode. (I gain is not used in STAB, not sure about the D) I switch between FBWA - CRUISE and MANUAL
Thanks for the response. The "I" gain doesn't really work in "STAB" mode, or at least I think not in the way that most people would want. Since APM stabilizes with respect to an inertial rather than body frame, the "I" gain will cause the aircraft to return to it's initial heading upon release of the stick, rather than to a particular bank angle. I've never seen another autopilot (except those specifically made for multicopters) that works this way. It doesn't appear to use rates for anything.
Possibly we should abandon "STAB" mode. I think the guide still suggests that we use it to tune the inner-loop gains before moving to any of the NAV modes, but perhaps the FBW modes are just as good for that.
We have not experienced the death spiral yet when in NAV mode, but most likely because we keep the airspeed pretty high. We're getting ready to work on auto takeoff and landing though, when we will necessarily need or want to be slower, and we also fly in a fair bit of wind, so I'm leery of hitting stall when the wind drops out during autoland.
We've purposefully made the aircraft stall several times in manual flight, just to see how it behaves, and it is not a big deal, in fact in straight flight, it drops the nose straight rather than a tip stall most of the time. It's the fact that APM gets confused and forces max roll during the event that we'd like to fix. The best solution would be to drive roll-rate to zero, and then pull pitch as airspeed picks up. Since APM appears not to use rates, instead it gets the divide-by-zero in the accelerometers, and forces max roll rate in some failed attempt to right the situation. I'm not sure stall detection is what is needed specifically, but rather rate-based control laws.
for rate based controller laws you might want to try out the new ACRO mode. It works pretty well.
And for the autotakeoff and landing mode, the TECS controller does an amazing job of keeping the airspeed above the minimum. so if you're on auto approach, and wind drops the controller will either throttle up or pitch down a bit to keep airspeed above its minimum.
A couple of extra notes on this. First off, the gyros are most definitely used for stabilization, in fact the gyros are the most important sensor for stabilization in all modes except MANUAL.
The recommended mode for tuning is FBWA. If you can point me to any docs that recommend STABILIZE mode then that would be appreciated, as I'd like to fix it. The STABILIZE mode is really only still in APM for compatibility with existing setups. It is not a good mode for most uses.
Regarding stalls and spins, APM has no stall detection or recovery code. Stall detection and recovery is a difficult problem in autopilots, partly because the right strategy for stall recovery varies so much between airframes and partly because you need to have a very low false positive rate for detecting stall, as if you enter stall recovery when you are not in fact stalled then that could induce a stall (or at least a very rapid descent).
So APM would have been just trying to fly normally during your stall, which means it was trying to level the wings and bring the roll rate to zero. In many flying wings that is the wrong thing to do, instead you should either use neutral aileron input or even turn into the spin.
I have been thinking of adding an optional STALL_RECOVERY option to allow users to set a recovery strategy for stalls, but I haven't started on it yet. It is quite a lot of work, especially as flight sims tend to be bad at simulating stalls, so it involves a lot of testing with real aircraft of different types.
Thanks for the feedback and the call. The only thing I can offer up is that APM's response to a vertical, nose-down attitude is to give full roll and what appears to be no elevator (through elevons on a Zephyr II). This wreaks of having a z-accelerometer give a zero reading, and APM attempting to use ailerons to drive the z-accelerometer back to g, which of course it cannot do when the nose is pointed straight down. Of course the correct response would be to use gyros to drive the roll rate to zero and then when airspeed indicates sufficient flight speed, pull up a bit to recover.
I know you tell me that control laws use gyros (guess we can difg through the code to confirm), but we have not yet discovered a test that would indicate any control-surface response to pitch or roll rates. We'll try to induce a notional airspeed by biasing the airspeed sensor (either through software or a bit of pressure on the pitot sensor) and see if this changes the behavior, but it doesn't appear to us that there is any inner-loop damping that is rate-based.
I have never seen an airplane where the stall recovery scheme wasn't to let go of the controls until the aircraft picks up speed, and then pull elevator balancing altitude and speed loops. Is there another way? You are right about flight sims. The ones that do simulate stall generally make it way too graceful. I've never seen a tip-stall in any flight simulator.
I was too hasty in telling you APM doesn't suffer from gimbal lock. The attitude estimation code doesn't have a problem, but you are right that the control laws can.
The underlying control systems for the surfaces are rate based, and use the gyros as the primary input for estimating the rate error, but the higher level controllers that feed into the rate based controllers to decide what the target rates should be on each axis are based on Euler angles, and thus do break down at +/- 90 degrees pitch. So if you point the nose straight down then the roll axis can indeed do entirely the wrong thing.
So if you point the nose straight down and take your hands off the sticks in STABILIZE or FBWA mode then APM will try to "correct" roll at the same time it will try to correct pitch. The roll correction will be counter-productive, especially on an elevon plane.
I'll talk to Paul to see if a simple fix of forcing neutral roll control when the pitch is close to +/- degrees makes sense to him. Perhaps multiplying the demanded roll rate by a linear decease starting at 70 degrees pitch and ending at zero roll rate demand at 90 degrees would work.
It would be better to work entirely with DCM matrices and remove the Euler intermediates in the control laws, but that is going to take longer. We do need that sort of change for true automatic acro flight (eg. a auto rolling loop would be nice!), but hopefully a simpler fix will do the job for the situation you have.
I think probably we should drop the topic of stall - I think everyone is in agreement that stall should just be avoided. For our group, I think the larger issue is that vertical flight cannot be tolerated. Pointing the nose straight up or straight down, whether accidentally or on purpose, is a fatal mistake, only recoverable with manual control. We haven't explored the ACRO modes which may handle this, as I suspect they are more like flybarless controllers for RC helicopters. This may not be a topic that most of the community is interested in, as I suspect most folks want to fly fairly benign way-point paths that involve little or no vertical movement. However, we want to autonomously perform aerobatics that will likely involve vertical flight segments, so we will need to find a way to get around this limitation.
Also, maybe you could elaborate a bit on the first paragraph. The inner loop of the APM controller typically seems to only have a P-gain, with zero for I and D gains (default settings). These gains are clearly w.r.t. absolute angles measured from "level," as a P-gain gives a surface deflection that is proportional to the displacement. All other autopilots and all gyros made for the RC community that I have used have the PID gains correspond to pitch/roll/yaw rates rather than angles. A P-gain in these other systems only tries to remove a rate, but is unaffected by absolute angles. The I-gain usually takes care of the integrated displacement. With APM, using an I-gain in the inner loop has the unexpected effect of actually returning the aircraft to its initial heading after releasing a stick - not just level, but actually removing whatever heading change the pilot might have induced. It seems clear in this approach that the I-gain should probably never be used. We have not attempted to use a D-gain for the inner loop, as most control schemes use the D-gain to stabilize the I-gain, but we have no I-gain.
Do you suggest that we try a non-zero D-gain in the inner loop? If so, what are typical values you might try?
Thanks for your help.
I need to correct my previous post. When we had previously attempted to use the I-gain for servo roll, it had the odd effect of trying to return the aircraft to its original heading, rather than returning it to level flight, when the stick was released. Based on discussions with Tridge (read about it above), we abandoned STAB mode and went back to FBW-A, and the I gain now has a more expected behavior. There are several factors that could have caused this:
1). We used to perform elevon mixing in the Tx, but had to swap channels 1 & 2 to get the surface movement correct. APM seemed to allow for this, as we were able to get it to provide the correct surface movement when the aircraft was pitched and rolled, but perhaps there was something counteracting this in software. In the new software there is a new elevon option that lets us send raw elevator/aileron inputs from the Tx, and APM performs the mix. This allowed us to swap the channels back so that channel 1 is the right elevon.
2). We are several major software revisions beyond the test where we originally ran into issues with FBW-A and moved to STAB mode.
I'm still curious about how the I-gain is implemented in the APM inner loop (servo pitch/roll/yaw). With the I-gain tuned to zero, we see that the control surfaces deflect in direct proportion to angular displacement from "level". With modern helicopter gyros, this would be considered a "heading-hold" behavior, and would require that an I-gain be included, as gyros only provide rate information by themselves - integration is required to get a response proportional to absolute movement. However, we see a proportional response when the I-gain is zero which seems to imply that either there is a hidden (and therefore un-tuneable) I-gain, or that rather than gyros, accelerometers are used for the inner loop, as the surface movement is exactly proportional to what accelerometers would read. Oddly, no matter how fast we pitch or roll the APM, we cannot see any rate-based movements of the surfaces. This looks pretty much like the ASSIST mode on most multi-rotor controllers.
At some point I guess I need to get my feet wet with the source code, and see what is actually done. ;-)
I'm on Kevin's team. Just to augment his post:
we first saw the FBWA issues for elevons back in January 2013. We were on Plane version 2.6x. We are now able to get FBWA working in 2.75.
We're quite confused about the movement of the surfaces in FBWA (as he describes above). If somebody can pipe up w.r.t. to the expected loop behavior for roll/pitch (inner loop -- is it supposed to be rate based?) that would be helpful.