PID vs Dynamic Inversion

[seanmcleod70]

Feel free to ask questions if you have any!

Here goes.

What if the proportoinal term in the PID (which is stable but wrong!) could be replaced with a term that computes the correct output location directly? Instead of fishing around to find the correct place to drive the output to zero, couldn't we just model the system and directly compute the correct output?

I happen to be reading up on the F-35's flight control law design - The F-35 Lightning II: From Concept to Cockpit and what you're describing is pretty similar to Dynamic Inversion for control.

$\dot{x} = Ax + Bu$

If you know the desired state rates, $\dot{x}_{des}$, plus the current state $x$, then you can solve for $u$.

$u = B^{-1} [ \dot{x}_{des} - Ax]$

This does imply that you've computed $A$, aircraft dynamics matrix (stability derivatives) and $B$, control effectiveness matrix.

Which I know you mentioned you're trying to avoid, i.e. having to come up with a full detailed model of the aircraft 😉 Typically done via some combination of CFD, wind-tunnel testing, and then fine-tuned with System Identification techniques from actual flight data.

In a sense you're describing a "small scale" System Identification from flight data.

So from raw flight test data we can directly derive a simple function that estimates the required aileron command to produce a specified roll rate given the current airspeed!

In the F-35 case they've implemented a Nonlinear Dynamic Inversion (NDI) based controller, with a very highly detailed aircraft model.

In terms of your initial roll rate example in terms of mapping a requested roll rate $p$ to an aileron deflection $\delta_a$ based on processing and sampling flight data don't you run the risk of the mapping being skewed depending on whether your flight data has enough periods of steady state roll rate $p_{ss}$ data?

For example take a look at A-4 - Skyhawk Roll Performance in terms of this graph plotting roll rate versus time and the roll rate acceleration versus the steady state roll rate.

That plot is for a fixed aileron deflection at some dynamic pressure, showing the roll rate acceleration plus the effect of roll damping in terms of then settling down to a steady state roll rate.

If in your test flight data processing a large percentage of the samples were taken for the periods before reaching the steady state roll rate then your control system is going to be too 'twitchy' and always overshoot the steady state roll rate that the pilot is trying to achieve.

I am driving towards a real world demonstration with a small (RC scale) type fixed wing flying model.

How far along are you?

Cheers

[clolsonus]

Hi Sean, I think yes to everything you have said. Especially if you are flying a warbird or any aerobatic plane that is getting out into the very nonlinear edges of the envelope you need a good model using real stability derivatives. Also you are correct on needing a good representative range of data to least squares fit through. It's easy to end up with a big ball of noise and a fit that is nonsense.

I have been imagining much more docile GA aircraft or survey drones that spend most of their time in the safe predictable range of the envelope. I have a pretty compelling simulator proof of concept, but it's based on some data I can't share, so I have been slowly working towads a demo with one of my model airplanes. (But I'm doing this for fun, not on a deadline and this summer I've been distracted with completely rewriting my ground station gui.) I just went out yesterday though and collected 3.5 hours of flight data, so I'm looking forward to starting to crunch through that and see if I can extract anything useful here. If it does look promising then I do plan to code up some simple control laws around this idea and see if I can demo it in real flight.

So for example, in real flight test data and in a simulator model I was able to pull out a strong correlation between roll rate and aileron deflection * qbar ... especially in the regions of the envelope a GA pilot would spend 100% of their time flying in. Similarly I found a strong linear relationship between elevator position and Accel_z / qbar. Accel_z / qbar also strongly correlates with Alpha. Of course there are more terms to consider in a complete model, but this seems to be a pretty dominant term. My RC model plane has a high pitch line so there is also a strong correlation between power and pitch rate (or the amount of elevator needed to keep pitch rate at zero.)

Oh, and one more wrinkle ... if you keep the model really simple ... you can collect data as you fly and update your least squares fit ... the system can "learn to fly" your airplane in it's current configuration ... cg ... weight ... etc. You can probably do this with a more complicated model too, but it might be riskier if your terms cross couple or the noise gets put in the wrong bucket ... I could see a risk of a more complicated model diverging, especially if peg the plane at a single flight condition for a long time.

What I had pretty good success with in simulation was to fit these relationships (in flight or in post) and using that as an "open loop" model to drive the ouput based on the pilot's stick request (roll rate and load factor). Then I added a damper "D" to slow down all the dynamics that I hadn't accounted for in my model. And finally I pasted an integrator (actually a "PI" controller) at the end of the pipeline to account for any modeling errors/environment factors.

I could watch the output of the integrator as an indicator of my model fit quality. If the model is perfect the integrator would have nothing to do and be close to zero. If the integrator needed to saturate out the control surface range, then I'd know my model was really bad (or I'm in a spin, or on the ground, or something not accounted for in my model.) Yes, the integrator can jump at the start of a step maneuver ... probably my model not accounting for the dynamics as you point out.

In a real scenario you would also have to account for things like flap position that can significantly change/affect the aerodynamic model.

I haven't observed any twitchiness ... but I could see getting into a state like that depending on how you've crafted up your control law flow.

I would never say that in general this would be a good way to approach creating your control laws. But there has seemed to be a lot of goodness flowing out of this approach and some positives I've stumbled into by accident, and my sim tests have been very promising ... so I do want to push forward and see how far I can take this.

A side note (and I'm not sure how much of this I've said before, sorry if I'm totally repeating myself.) If you made a PID based system and added a bunch of feed forward terms ... you've done almost exactly what I've done and arrived in almost exactly the same place ... just from a different direction. My goal is to generate everything from data instead of going out and tuning knobs until it feels about right. And of course at the end, you may do a lot of tuning away from some metric of "optimal" to get a better feel for pilot preference. You might want softer gains for ride comfort, or loser tracking so the system doesn't feel as mechanical, or slowly changing power output (taking whatever hit on performance you have to) to avoid a lot of annoying power hunting and throttle changes.

I'm writing all of this before I look at yesterday's data ... if I get some good signal out of the noise I will be thrilled and might start coding things up sooner ... if it's just a big ball of noise then I may have to go away and think some more. :-) Hopefully a bit of this makes some sense ... I'm running down an idea, it still could prove to be a dead end ... or in order to make it work well I'll end up needing to go read up on the F-35 system and eventually get around to doing it all the "right" way ... we'll see!

[seanmcleod70]

Hi Curtis. Thanks for the feedback and the update.

Talking of 'twitchy' flight I'm not sure if you've flown Zaretto's F-15 in FlightGear? While looking into roll performance a month or so ago I noticed the aileron control power in the model was off by an order of magnitude. So if you fly it now it should feel quite different.

See - Zaretto/F-15#1

And of course at the end, you may do a lot of tuning away from some metric of "optimal" to get a better feel for pilot preference.

I know you want to try out your current approach in terms of mapping a pilot command like commanded roll-rate to a surface deflection via your dynamics mapping approach, so take this as a bit more F-35 spam for now 😉

So, although I mentioned that the F-35 based approach of using Dynamic Inversion was somewhat similar to your approach, they don't actually do a mapping directly from pilot command, e.g. roll rate command to surface deflection using Dynamic Inversion.

The commands module translates the pilot’s stick,
throttle, and pedal inputs into desired aircraft movement. The regulator directly
sets good low-order-equivalent system parameters to ensure classical handling
qualities for the pilot while achieving this motion. This is generally defined in
terms of traditional flying qualities parameters, such as short-period frequency
and damping, or Tier II flying qualities metrics, such as pitch attitude bandwidth,
Neal-Smith criteria, and so forth. Those flying qualities goals are embedded
directly in the F-35 regulator because the remaining control architecture creates
the inversion

Here is an example from the roll regulator.

So once the required roll acceleration is calculated, $\dot{p}$, then the dynamic inversion is performed to work out the required surface deflection to achieve this acceleration.

...feel for pilot preference

In the F-35 example this could be tweaked as a combination of changing the roll command gearing, i.e. lateral stick deflection to commanded roll rate and also by changing the roll time constant in the regulator $\tau_{roll}$.

[clolsonus]

I don't want this to sound like we are talking past each other, and I don't want to get overly pedantic. But again I think everything you have said appears to be right on. I have nothing to disagree with! There is a lot here I don't know about. My background is computer science, so I struggle to wrap my brain around any information presented in the frequency domain ... I'm still trying to grok frequency domain and when I spend too much time thinking about it, my brain hertz!

So that said, the F-35 is going to have powerful actuators that can move the control surfaces against extreme hinge moments at all the craziest places in the flight envelope. This means in 99.9% of the flight envelope the actuators will have far more capability than actually needed. And then this means that you could /way/ over drive the system and you probably do need to think carefully about shaping the acceleration response, you don't want to just slam the control surfaces around for fastest convergence.

I am picturing RC airplanes or GA airplanes where you maybe have just barely enough actuation to meet your steady state requirements, or you have corners of the envelope that get clipped off because you don't have enough torque or rate (power) to get there and maybe you live with that because airplanes are a series of compromises that you hope come out to a net positive.

So I'm coming at this from the other direction where I don't think I have enough actuation and I'll take whatever I can get (compared to the F-35 where you have an excess so you need to decide how to limit rates and then you might as well do it in a way that feels really good to the pilot.)

I could very well be completely wrong on my assumptions! Maybe accel shaping is really important and I just haven't discovered that yet. This is very possible!

I have some flight data now so I will try to put some plots together to show more clearly what I am thinking ... but it is real world flight data on a really crappy slow airplane, so bear in mind this is not going to look like a pristine textbook matlab plot! And we have to guess how much of the noise is due to modelling error (or not considering enough relevant terms) versus turbulence, versus this being a foam-not-very-rigid airframe.

[clolsonus]

Apologies in advance ... my axes aren't all labelled properly, my data is noisy, the airplane is crappy, I'm flying at a very low/noisy qbar (20 kts airspeed), it is a hot sunny day, so there is quite a bit of turbulence relative to my aircraft size/speed. These are /not/ clean theoretical s-function plots out of matlab. I have proved this to work /really/ well in flight simulation, so I'm now working towards migrating this idea to an actual fixed wing RC model airplane. This is my first stab at it looking at the data ...

So let's first look at the roll axis because that's easy/simple, right?

Here is a plot of x = roll rate (rad/sec) vs. y = normalized aileron deflection * qbar

You can see maybe there is some signal there in the big ball of noise. The question to ask is if this noise is due to other terms not being included or is it turbulence, sensor noise, airframe flexibility, etc. I will just assert for now that it is more due to unpredictable external effects, but folks may know better or have their own thoughts on this, or trust me and continue reading!

I can do a simple least squares fit of this data and come up with this formula:

p = 0.0935 + 0.0062*ail*qbar

or

p_rps (roll rate) = 0.0935 + 0.0062*aileron_pos*qbar

If I have a desired roll rate (from pilot stick position or outer loop autopilot controller) and know my current airspeed (qbar) now I can rearrange terms and compute exactly what aileron position gives me that roll rate. Edit: it's just simple algebra to rearrange the terms to invert the equation ... but it's a simple form of inversion!

In a direct control aircraft, aileron position is directly proportional to stick deflection. In this simple new controller, aileron position is still directly proportional to stick deflection (but scaled for qbar.) So this should intuitively make sense that it should work and fly just fine. The model doesn't perfectly account for every effect, and it may not be a great fit ... but if the pilot needs more roll, they push the stick further ... to the pilot it flies great, just like the real airplane ... just with different stick/force scaling.

So how good is this model? Maybe not great, or maybe our data is super noisy? Here is a plot of the actual aileron position (orange) versus what the model predicts the aileron position should be to get the observed roll rate. The steady state behavior might be there, but there is a lot of error.

So what can be done to improve this?

• Include more relevant terms in the model
• Add a roll/aileron damper to slow down some of the wiggles
• Add an integrator on the back end to close the gap in model uncertainty.
• Maybe the existing traditional PID-based roll controller that I flew on this test flight is way over driving the system?

[clolsonus]

Continued ...

Additional terms make the model fit better

As it turns out with this specific aircraft, roll rate is highly coupled to rudder and aileron ... rudder may be even more effective than aileron. Skipping ahead, this is a prop plane so we know there is some correlation with power/prop ... whether that be p-factor, torque, swirling prop wash ... or some combination of all that. These effects are not all linear but we have limited flight data signals, incomplete coverage of the flight envelope, so maybe we can treat throttle command as a linear effect to at least improve our model. And just for fun let's throw in az (vertical acceleration) as a proxy for alpha stability effects and ay as a proxy for beta stability effects. This aircraft doesn't have an alpha/beta boom so we don't have perfect data. So let's dump the new terms into our model and see what happens.

The previous fit of just aileron*qbar vs. roll rate had a standard deviation of 0.191 ... adding the new terms lowers our standard deviation to 0.174 so we improved our model fit. It's still noisy, but here is the new formula, does it make any sense:

• p = 0.0966 + 0.0005*aileron*qbar + 0.0291*rudder*qbar + 0.0023*throttle*qbar + 0.0011*az + 0.0285*ay

We are seeing that rudder has a bigger effect on roll rate than aileron! This is a fat / slow foamy glider airplane so that actually is plausible ... many RC gliders are flown rudder only with no ailerons. We see that throttle has some affect as does az (proxy for alpha) and ay (our proxy for beta) actually has a pretty big effect as well.

Multiple inputs (multiple outputs)

So I have a big problem now, I just painted myself into a corner by considering the effect of rudder on roll rate! I will assume throttle will be set by some other controller (speed or altitude or energy) but now I have two inputs (rudder and aileron) that drive one output ... how can I solve for the best combination of these two inputs? Maybe I could link them proportionally as a single input variable ... and that works. RC models often mix aileron and rudder in a fixed proportion to reduce adverse yaw in turns.

I would like to propose a crazy different idea. Hopefully an intuitive build up will make some sense.

For the roll axis I do want to control roll rate. But for the yaw axis what do I want to control? My first thought is yaw rate. But on second thought, what I really want to control is beta (side slip.) Most of the time I want beta to be zero unless I command the aircraft into a sideslip and then I want some different beta that I've commanded.

I have asserted that az/qbar is proportional to alpha, so az/qbar (load factor) can be a proxy term for alpha. Notice that if we are solving for elevator*qbar and use az as one of the terms, and then we invert that equation, we end up with an az/qbar term ... so if it looks like I'm being sloppy with where qbar shows up, I'm not really being sloppy, I'm just not showing all the math steps very well.

I will assert that if az/qbar is a proxy term for alpha, then ay/qbar can be a proxy term for beta. That is not a great assertion, but it's the closest I can get to a beta estimate with my flight data and my instrumentation.

Ok, so here is the setup. I want to model p (roll rate) and ay (sorta beta) from the other relevant terms I am able to measure/compute.

My output states will be ["p", "ay"] and my input states will be ["aileron*qbar", "rudder*qbar", "throttle*qbar", "az", "r"]

Oh, notice I snuck in "r" which is yaw rate ... the more the merrier!?! I didn't include "ay" as an input state because it is there as an output state. I don't want a circular reference here, but some variation of this approach that computes change in ay could be interesting ... a subject for some other day! Here is what the least squares fit spits out:

• p = 0.0922 + 0.0052*aileron*qbar + 0.0118*rudder*qbar + 0.0018*throttle*qbar - 0.0020*az - 0.2994*r
• ay = 0.1678 - 0.0390*aileron*qbar + 0.0548*rudder*qbar + 0.0080*throttle*qbar - 0.0010*az - 1.8388*r

This airplane is not symmetrical ... it is battle tested with a significantly warped fuselage and a rebuilt wing. Don't expect symmetry in these formulas ... in fact, I'm excited to see that the flight data captures how out of trim this airframe actually is!

Here is a quick word of explanation. Time on the X-axis but the units are sample points not time, ay on the Y-axis. Orange is the original sample ay signal and accelerations are typically quite noisy, so that is expected. Blue is the model estimate of what ay would be given the same inputs as were observed in the flight data. This is a backwards approach, but if the prediction matches the data to some reasonable level of confidence then: we can we can have some degree of confidence (hopefully?) that when we invert the formula, we can derive the correct control surface outputs for the desired ay (usually 0 for coordinated flight) given the other relevant state variables in the system.

Did you see what I did there?

If you look at the above two equations, p and ay are values that I want set from some external source such as the pilot inceptors or an outer loop controller, so these values will be known. I can measure az and r so those values are known. Throttle will be set by some other independent control loop so that value is known. Airspeed can be measured so qbar is known. The only two unknown variables in this system of equations is aileron and rudder position. We have two linear equations, two unknowns. This is easy to solve!

Obvious issues and work-arounds

1. This model is far from perfect. What happens when we predict a control surface output, move it there, and get the wrong result? First it is only slightly wrong, and second, we could put a "partial authority" integrator on the back end of this system to cover the expected error range of our model (but no more). Thus we can close the model gap quickly, but in a situation where we are on the ground, the integrator only winds up to some small percent of the total range of motion and doesn't cause a problem. Or if we somehow find ourselves in the air with the integrator off, the outer loop can easily compensate for the inner loop not quite getting to it's reference goal.
2. There is no consideration for the dynamics of the system ... how fast the system is moving towards or away from the reference value. However, we can throw a simple damper "D-term" also on the back end of this system and in practice that sufficiently accounts for dynamic terms.
3. Flaps, gear and other things that change the aerodynamic stability derivatives. In my simulator proof of concept I built separate models for each permutation of these conditions and then interpolated between them to minimize transients. But yeah, these are real things that need to be consider on a real aircraft.
4. There are no other issue, this is all so perfect! Hah, LOL, if you disagree I want to learn from you!

Summary

• I am working with terms that are directly measurable or directly computed from measurable quantities (which is relatively easy). I don't need to fly careful maneuvers and extract traditional stability derivatives (relatively hard, might need an aerospace engineering degree!)
• I am building a simple "linear" model but out of non-linear terms so it covers a good range of the flight envelope.
• The system is simple enough that I could consider collecting in-flight data and updating the least squares fit in flight. I can talk about that another day, but I came up with a trick that makes this work out really well and is robust. This system could realistically self adapt to changes in CG, weight, per-aircraft variations, external conditions, etc. The controller could learn to fly it's specific aircraft and get more and more dialed in as more and more of the flight envelope gets covered over time.
• Are any aerospace engineers loving this idea? I don't think so ... but are there any not-quite-aero engineer phd people out there wanting to achieve a well tuned controller for a complex system quickly and simply ... I don't know maybe? I am n=1, I don't know if there are any more like me in the world.

Edit: Did you see what I did there 2.0, Summary 2.0

• What I built analytically directly from flight test data is almost equivalent to what you'd get if you started with a traditional PID added those same elements as feed forward terms and then turned the knobs until the system behaved nicely! In my system I have far fewer knobs to turn via trial and error.
• This is an OPEN LOOP controller ... with a small integrator and damper on the back end to account for open-loop modeling errors.
• Will this system work on an F-35? Only if you promise to drive it like a minivan.
• A traditional PID is a model of your system, just one that doesn't start out knowing very much other than assuming changing the output changes the input in a predictable direction (doesn't have to be linear though.)

[clolsonus]

Ok, one more update, still with lousy plots. Looking at elevator vs. az/qbar now:

Deriving the load factor control law

I want my longitudinal inner loop to control load factor, not pitch rate.

Here is elevator position on the y-axis and corresponding az/qbar on the x-axis. It is a big ball of noise, but you can see a correlation emerging, even though I only flew over a fairly narrow portion of the flight envelope. From other experiments I predict this correlation will continue to be pretty linear across the envelope I care about.

Additionally this test aircraft is a pusher configuration with the motor mounted aft of the wing and a high thrust line, so there is a significant elevator correction needed with power change. When I throw all this into my least squares fitting code I get the following formula:

• elevator = -0.0700 + 0.4162*az/qbar - 0.3493*throttle

Ok, so to break that down: The pilot inceptor is mapped to a load factor (az) request scaled by qbar. Power is being controlled by an independent control loop so we have that value already. We can just plug the load factor request, qbar, and current throttle position into the above formula to get the estimate elevator required. This is an open-loop controller, but I predict it will be pretty good.

If you study the formula, there is a direct linear relationship between inceptor position and elevator position, just scaled by qbar. There is nothing complicated or mystical here ... it's really just a direct one-to-one mapping ... not that much different from direct control. Then we add in a term to correct for the nose down moment that power introduces. (Note my system doesn't record power, so throttle position is a proxy for that.)

Side note: when I did manual mixing and just turned the dial until it felt about right, I came up with a throttle correction value of 0.4 so this new analytical method feels to me like it is getting the right answers.

Here is how the model fit looks (snippet from the larger flight):

Envelope protection

• If I want to limit the max/min load factor, I can just clamp the requested az value to those limits. The model fit isn't perfect and there could be external forces from turbulence, so you need to build in a bit of structural margin, but enforcing simple load limits is almost trivial.
• Stall protection? This is maybe a longer discussion, but az/qbar maps pretty linearly to alpha (angle of attack) assuming static stable system, ignoring dynamics. So .... I am proposing to myself that I can just pick a value of az/qbar that I think will be safe and then never let the system command something bigger than that. As speed slows, az/qbar will increase. At some point it will hit my threshold and I will need to start limiting the value of az to keep az/qbar under the threshold. Simple stall protection if you believe my numbers and my correlations. This will work in slow level flight, it will work in higher speed steep turns. There are additional terms that a purist might want to consider, but to keep the control laws and protections simple, analyzable, and clear maybe I don't want to add additional complicated terms.

[seanmcleod70]

My background is computer science,...

Don't worry, my background is also a computer science degree, no formal training in terms of control systems, so definitely don't take any of my comments about control systems as if they're coming from an expert 😉

I have spent a fair amount of time over the last 15 years or so developing a ground based VSS (Variable Stability System) simulator for test pilot training. Which involved a fair bit of self-study in terms of the classical aerodynamic coefficients in order to make them available for tuning to demonstrate particular side-effects of them to the test pilot students etc., using JSBSim as the basis.

compared to the F-35 where you have an excess so you need to decide how to limit rates and then you might as well do it in a way that feels really good to the pilot.

I get the feeling that pilot 'feel' was more a driver than an afterthought. So, in addition to qbar independent and consistent commanded roll rates for a given stick deflection they also wanted a consistent time constant across qbar and commanded roll rates.

But again, I'm not suggesting you abandon your approach and try to mimic the F-35 approach, just pointing out some differences in the approach.

For the roll axis I do want to control roll rate. But for the yaw axis what do I want to control? My first thought is yaw rate. But on second thought, what I really want to control is beta (side slip.) Most of the time I want beta to be zero unless I command the aircraft into a sideslip and then I want some different beta that I've commanded.

Yep, keeping beta=0 during a roll will result in a roll around the velocity vector, which is generally what modern fighter jet FBW systems do.

In terms of your fitting and scaling in terms of qbar, I'm just wondering how much variation in qbar do you have in your test flight? Given the type of aircraft you're testing with you're not going to see a change in air density, so it's going to come down to how much variation in speed there is.

p = 0.0966 + 0.0005aileronqbar + 0.0291rudderqbar + 0.0023throttleqbar + 0.0011az + 0.0285ay
We are seeing that rudder has a bigger effect on roll rate than aileron!

Two orders of magnitude larger!

A traditional PID is a model of your system, just one that doesn't start out knowing very much other than assuming changing the output changes the input in a predictable direction (doesn't have to be linear though.)

Not so sure that when PID controllers are designed for aircraft that the starting point is not knowing much about the dynamics other than the sign of the input to the output response, and that you then sort of just start trying to tweak the P gain etc. I'm sure that is the case for general hobbyists with RC planes etc. but not the general case for real systems like the PI based controller for the Eurofighter for example 😉

Generally for the professional cases there will be some model of the flight dynamics, with a transfer function modelling the response say between the elevator input and the pitch rate output from the aircraft. For example, equation 10.3 below.

The transfer function for the plant/aircraft modelling this response from input to output is then included when calculations are done using PID design tools in order to choose PID gains that match some specific requirements, e.g. specific rise time, maximum overshoot etc.

Example of the optional FBW command law setup I implemented for the VSS sim for test pilot training.

Now the PID gains are then typically gain scheduled particularly for aircraft with large operating envelopes. So yes, a lot of work to come up with the transfer function in terms of getting the relevant stability coefficients, then going through a PID tuning process, and then gain scheduling.

So yes, if you can come up with an automated/semi-automated mapping with some basic flight testing, even doing it on the fly then it could be quite useful for certain scenairos.

Coming back to the roll case, when you look at/zoom in at the roll rate data are there obvious periods where a steady state roll rate is achieved? Difficult to tell from your plots above, but it looks like the roll rate data doesn't really have much data with steady state roll rates?

If there is, I'd be interested to see the difference in the least squares mapping if you only considered the blue dot samples and excluded the red dot samples.

To see what the mapping from elevator position to steady-state roll rate looks like with qbar etc. Under the steady state roll rate conditions the roll damping moment and aileron control power moment are equal.

P.S
I didn't mean to close this discussion earlier. I accidently clicked on the close discussion button while I was still busy composing my reply, as my monitor was going into sleep I wiggled the mouse and clicked to keep the monitor alive and happened to be over the close discussion button. So I've re-opened it now with this comment/reply.

[seanmcleod70]

I asked about the amount of variation in qbar above.

In terms of your fitting and scaling in terms of qbar, I'm just wondering how much variation in qbar do you have in your test flight? Given the type of aircraft you're testing with you're not going to see a change in air density, so it's going to come down to how much variation in speed there is.

Looking at A4 Skyhawk Roll Performance again I noticed that the steady state roll rate isn't proportional to qbar, it's proportional to the TAS, $u_0$.

$\Large p_{ss} = -\frac{2u_0}{b} \frac{C_{l \delta a}}{C_{lp}} \Delta \delta_a$

So I ran a roll rate comparison on the 737 model in JSBSim at 160KTAS and 320KTAS to compare the roll response.

I assumed roll coordination, without explicitly implementing roll coordinate, so I just set the 737's $C_{l_{\beta}}$ to 0.

So doubling TAS results in ~doubling of steady state roll rate and not 4x roll rate due to qbar increasing by a factor of 4.

[seanmcleod70]

Curtis, I came across this LinkedIn post recently which includes a copy of the paper as well -
Adaptive Flight Control of an F-16 Without Prior Modeling

[clolsonus]

You've written a lot, and I want to respond to it all, but life has been busy recently, but let me try to hit a couple things quickly.

For RC model test data I have not flown over a large qbar range, but for some other experiments I have. My system can't tell me what the true relationships are, but it can tell me if one term correlates better than another and so far what I've seen is that roll rate correlates best with aileron*qbar (not velocity). But that in no way means anything fundamental about physics, just that's what I have seen.

For pilot feel, I'm not sure what to think. I'm certainly not an expert in what fighter pilots like to feel, and how to accomplish that. I am inclined to think that it would be nice if the aircraft performance matched the stick deflection as closely as possible without delaying or speeding that up ... but I'm sure there is much nuance here that is simply out of my range of vision because I've never attempted to develop real control laws for real high performance aircraft. My proof of concept will be with an RC plane so the pilot won't have any direct feel at all, so my use-case could send me in a different direction entirely.

Fair point that big aircraft programs won't just take a wag at gains and turn the knobs until it feels about right. They will do a careful detailed model of their aircraft, and design the control laws to meet specific measurable criteria, they'll do careful filtering to avoid flutter or short period, and they'll probably have some crazy analysis tools and techniques and people with 40 years of experience doing these exact things.

When you say transfer function and start using "S" terms, my eyes glaze over and my brain goes into shutdown mode, sorry! :-)

Your thought about just analyzing the steady state roll cases vs. taking all data ... fair point, but I'm hoping that the variations in both directions cancel each other out mostly ... and I'm hoping for a /lot/ of help from Mr. Guassian.

Roll response vs. aircraft velocity: I am hoping for a system that gives a consistent roll response for a specific stick deflection across the entire flight envelope (or as much as possible with physics and aerodynamics.) So for example, I'm hoping full stick deflection will command something like 30-40 degrees per second roll rate no matter what speed I'm flying ... until I get too slow and full deflection can't give me that rate any more.

I think I noticed that same paper on linked in. I'm not very fluent in phd so I often struggle to make sense of these kinds of papaers. I was really hoping to find out more information about what sysid terms they were modeling and fitting. Maybe I got lost in the notation but I didn't see any real information there ... they were more interested in describing their higher level fitting/modeling approach and less about the terms they were modeling (from what I could glean so far ...) But from what I could see, they are in the middle of the same space that I'm nibbling on the edges of.

I'm still hoping to get a real proof of concept of these ideas (built offline with past flight test data) flying sometime this fall, but life continues to be busy and full of obligations and distractions!

[clolsonus]

(Oh, and I was hasty in my last post ... I meant to say that you clearly know a lot of things that I haven't learned about yet. So I don't mean to shrug off those parts. I'm still trying to learn the more technical/fundamental aspects of this field, but many of these things don't grok in my brain yet. I never formally studied much of the time domain stuff or the engineering representations of these things.)

[seanmcleod70]

but life has been busy recently

No problem, I'm also fairly busy work wise, so I also don't respond immediately, plus often don't have time to respond to everything you post. I did notice, via YouTube figuring out to highlight some of your recent videos that you've been busy with some RC flying in terms auto-land testing?

I never formally studied much of the time domain stuff or the engineering representations of these things.

I'm in the same boat. My ideal ~35 years ago would've been to study computer science, electrical engineering, aerospace engineering and become a test pilot, but I had to choose just one so went with computer science.

you clearly know a lot of things that I haven't learned about yet.

Mostly "know of", as opposed to being a practicing expert in.

they are in the middle of the same space that I'm nibbling on the edges of...

Yep, that's why I thought you might be interested in the paper.

what I've seen is that roll rate correlates best with aileron*qbar (not velocity). But that in no way means anything fundamental about physics, just that's what I have seen.

Your thought about just analyzing the steady state roll cases vs. taking all data ... fair point, but I'm hoping that the variations in

I would imagine that if a large percentage of the sample points are sampled before reaching a steady state roll rate then in theory you would be underestimating the mapping from aileron deflection to roll rate.

Looking at some of the data you posted above it doesn't really look like you ever really have any periods of steady state roll rates?

Also if you look at equation 2 in - A4 Skyhawk Roll Performance you'll see that the roll moment due to aileron deflection is directly proportional to qbar. So if the roll damping is very small and/or you're not letting the aircraft get close to a steady state roll rate, i.e. so $p$ is small so there is only a small roll damping moment, then yes the best correlation between aileron deflection and roll rate will be proportional to qbar as opposed to TAS.

It would be ideal if you could get data across a wide range of speeds with steady state roll rates.

[clolsonus]

I'm slowly working in the direction of getting better data. Part of the issue is my controller is not tuned as well as I thought it was, especially at slower speeds, especially in pitch. Part of the issue is the airframe is literally floppy and my flight controller board is not as rigidly mounted as it should be ... sort of ok-ish for testing higher level mission/task/logic stuff but pretty bad for doing anything at the inner loop level.

My thought is that I will redo my flight controller with some of the ideas discussed here which should (if all my theory and sim testing works out) make the airplane a lot more stable and predictable across the range ... and that should lead to better data (at least up to a point.) What comes out of this stupid airplane will never look like textbook or full size aircraft, but it could probably an order of magnitude better if I put energy to it.

Previously I was doing most of my development with a U of MN owned airframe (XUAV Talon) and it was setup much better and I was getting cleaner data and had better tuning. Now that I'm no longer at that job, I've reverted to my skywalker which is a piece of junk in comparison.

So along with improving the skywalker, I am starting to think about building up a better test platform ... I have a couple airplanes here to work with. I have a senior telemaster that previously was instrumented for autonomous flight with a version of my flight controller from probably 10 years ago. I have a kadet senior which might make a nice gentle platform. I have actually my own XUAV Talon, but needs to be put together ... and I have a 2nd skaywalker also needs to get put together (and this time I would improve some things from my first attempt.) And I have a big composite flying wing from a previous life (7 2/3 foot wing span, whatever that is in inches) that I also want get back to instrumenting and flying. Too many ideas and not nearly enough time!

Also, I'm thinking in terms of adding some features (or re-activating previously features that got lost) in order to do more automated maneuvers ... chirps, doublets, glide tests, etc. to help collect data across a wider range of the envelope without having to manually fly from the ground (which is super imprecise.)

[clolsonus]

Lol, for another discussion on another day ... I have ideas for doing simulink type stuff, but with a simple text-based language (following a simplified "functional" programming paradigm ... that's buzzword laden, sorry if you haven't heard of it before.) The plan would be to design your whole FCS system and switching logic in this stripped down/simplified functional programming paradigm (which matches pretty well to a simulink diagram actually) and then emit C code to compile for the flight controller. Maybe someday make a simple interpreter that runs on the flight controller so you could edit code and run/interpret it directly instead of going through C code and recompiling. I have ideas, I just want it to do a few simple things ... I'm sure it won't turn into a 1000 hour project! But ... it wouldn't require licensing another matlab toolbox every time you turn around ... we have that at work and it's a nightmare how much money we shovel over to mathworks ... just crazy. But awesome for mathworks I guess. Just for my hobby stuff want to stay on the opposite side of the horizon from that sort of thing .... but be able to do things with similar capabilities.

[seanmcleod70]

Out of interest, what sort of programming do you do at work?

[clolsonus]

When I was at the U of MN (where I could talk specifics until people would get horrified looks on their faces) I did a lot of development of flight controller code and a bit of flight controller sensors/hardware. We had our own in-house EKF (attitude estimation) solution that we used heavily. I did a ton of work supporting agricultural aerial survey projects (map stitching etc.) I supported many student class and research projects. I tried to do as much of my work in python as possible (of course some of the core flight code needed to be C/C++) Being in the Aero department I started to pick up tricks and ideas I would never have thought of on my own and I pursued some of those either on my own or as part of projects. Towards the end of my time there I started getting more into visual motion tracking and extracting signal/energy out of large complex data sets (like for fluid flow.) Now I've had to pivot quite a bit, start to learn some new tools, and lately have been working a lot with flight simulation again (calling in a lot of favors to the past flightgear side of my brain!) I don't want to completely drop all the flight control work I've done over the years so I've been trying to poke at this project as much as possible evenings and weekends. I think of it more of an art project now. I'm not trying to rule the world or have everyone do it my way, I'm just happy to plod along and if anyone comes along and looks at it for 15 seconds and says "neat", I guess that's as much as I would hope for.

[seanmcleod70]

supporting agricultural aerial survey projects (map stitching etc.)

Ah, about 10 years ago I started doing some work in this line for a startup company, Aerobotics - https://aerobotics.com/drone-scan although not really on the stitching side, more on the processing side of the drone and satellite imagery, camera processing etc. They also used Skywalker UAVs in the early days.

I supported many student class and research projects
visual motion tracking and extracting signal/energy out of large complex data sets (like for fluid flow.)

Sounds like interesting work.

Does your current simulation work involve JSBSim by any chance?

[clolsonus]

Aerobotics looks like a pretty nice group, hope they continue to be successful! I know some people at Sentera ... they mostly sell UAV/Agricultural optimized camera systems and services around processing/stitching/identifying/tracking. Also a pretty cool company. They did not use a skywalker in their early days. :-) That had a really slick 1m (ish) wing span flying wing design that was really nicely engineered, their latest fixed wing design is an evolution from those earlier days. A lot of people use multirotors because they are easy to learn and operate, but fixed wing drones are so much more capable in terms of payload, speed, and endurance (you just have to know a bit more about launching and landing them.)

Currently we have used JSBSim some (that sentence may make partial sense?) I'd like to use JSBSim more in my own UAV hobby work, but there are some issues with modeling small electric powered fixed wing airplanes, trimming blows up, can't get any help/attention from current JSBSim developers ... when my colleagues have tracked things down and fixed things the patches have been rejected because of various reaons ... so I don't know ... I'm a little frustrated the past few years with JSBSim. It does a lot, but certainly has issues and limitations and things it simply can't (won't do) because developers don't think those things should get fixed ... anyway, just complaining!

[seanmcleod70]

can't get any help/attention from current JSBSim developers ...

I'm one of the current (since 2018) JSBSim developers with the second most commits since 2018 😉

https://github.com/JSBSim-Team/jsbsim/graphs/contributors

I'm fairly prolific in terms of commenting on issues and discussions on JSBSim.

https://github.com/JSBSim-Team/jsbsim/issues?q=is%3Aissue%20AND%20(commenter%3Aseanmcleod%20OR%20commenter%3Aseanmcleod70)

https://github.com/JSBSim-Team/jsbsim/discussions?discussions_q=commenter%3Aseanmcleod+is%3Adiscussion

https://github.com/JSBSim-Team/jsbsim/discussions?discussions_q=is%3Adiscussion+commenter%3Aseanmcleod70

Do you have some examples of issues/discussions where there was no help/attention from the JSBSim developers and rejected patches?

anyway, just complaining!

I'm not complaining 😉 and would be interested to see the sorts of issues that users had difficulty with.

[clolsonus]

One of my colleagues submitted a patch related to engine/prop advance and it was rejected with a statement that this could all be done with scripting ... but if you do it through a script you can't use the trimmer to get to a trimmed state at initialization time. My colleague felt like not only was his patch rejected (he is an Aerospace engineering phd with Nasa and Boeing experience and isn't just an academic hack, he knows the right ways to do things and his stuff works) he was kinda slapped down in the process. More recently I've pointed out that the FlightGear rascal model can't trim in the air. I believe the issue is around the electric motor model somehow, but I couldn't get any serious attention on the matter and ran out of energy on my side so I gave up for now. Maybe I'll try again someday. I also see that the python interface to JSBSim carries some uninitialized state so that sometimes things blow up when you start, but if you can get started and fly around, subsequent startups work just fine. This is a tricky complicated one and I wouldn't even know where to start so I haven't even tried saying anything. Thanks, Curt.

…

On Sat, Aug 16, 2025 at 11:37 AM Sean McLeod ***@***.***> wrote: can't get any help/attention from current JSBSim developers ... I'm one of the current (since 2018) JSBSim developers with the second most commits since 2018 😉 https://github.com/JSBSim-Team/jsbsim/graphs/contributors I'm fairly prolific in terms of commenting on issues and discussions on JSBSim. https://github.com/JSBSim-Team/jsbsim/issues?q=is%3Aissue%20AND%20(commenter%3Aseanmcleod%20OR%20commenter%3Aseanmcleod70) https://github.com/JSBSim-Team/jsbsim/discussions?discussions_q=commenter%3Aseanmcleod+is%3Adiscussion Do you have some examples of issues/discussions where there was no help/attention from the JSBSim developers and rejected patches? anyway, just complaining! I'm not complaining 😉 and would be interested to see the sorts of issues that users had difficulty with. — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXYYDJW5Z6QTPBUDT5J72D3N5M3NAVCNFSM6AAAAACCMF3B5KVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJSG4ZDMNY> . You are receiving this because you commented.Message ID: <NorthStarUAS/. ***@***.***>

-- Curtis Olson

[seanmcleod70]

I'll take a look at the issues you mentioned. In terms of the Python issue, if you can come up with a reproducible case then log it as an issue and I'll take a look.

[clolsonus]

That's part of the problem, I don't really know how to reproduce it or shrink it down to an easy to run test case. My one laptop has a lot of trouble (until I get a good start) and then it seems ok after that. My desktop machine seems to usually do fine. I'm doing a ground init because the model can't init in the air (which I think may be due to being powered by an electric motor and the trimmer doesn't seem to be able to handle that configuration?)

[seanmcleod70]

I found your JSBSim report about the trim issues with the Rascal. As a quick test, I removed the engine as a factor by not starting it and then trying to find a trim solution for a glide. Similar approach I took for an engine on example to generate a trim envelope for the 737, see:

https://github.com/JSBSim-Team/jsbsim/blob/master/examples/python/Trim%20Envelope.ipynb

So with the following quick test I wasn't able to find a trim solution for the Rascal in a glide, so I doubt the trim issue is related to the engine. Will have to take a closer look to try and figure out why it fails to trim.

import jsbsim
import math
import numpy as np

AIRCRAFT_NAME="Rascal110"
# Path to JSBSim files, location of the folders "aircraft", "engines" and "systems"
PATH_TO_JSBSIM_FILES="../../jsbsim"

# Create a flight dynamics model (FDM) instance.
fdm = jsbsim.FGFDMExec(PATH_TO_JSBSIM_FILES)

# Load the aircraft model
fdm.load_model(AIRCRAFT_NAME)

# Avoid flooding the console with log messages
jsbsim.FGJSBBase().debug_lvl = 0

# Set engines running
#fdm['propulsion/set-running'] = -1

fdm.set_dt(0.001)  # 1000 Hz time step

# --- Simulation Parameters ---
# These lines set the simulation parameters.

# Set alpha range for trim solutions
fdm['aero/alpha-max-rad'] = math.radians(12)   # Maximum angle of attack in radians.
fdm['aero/alpha-min-rad'] = math.radians(-4.0) # Minimum angle of attack in radians.

# Set envelope limits
min_speed = 20    # Set the minimum calibrated airspeed (kts).
max_speed = 80    # Set the maximum calibrated airspeed (kts).
altitude = 100    # Set the altitude (ft).
min_gamma = -30   # Set the minimum flight path angle (deg).
max_gamma = -1    # Set the maximum flight path angle (deg).

for speed in np.linspace(min_speed, max_speed, 10):
    for gamma in np.linspace(min_gamma, max_gamma, 10):

        fdm['ic/vc-kts'] = speed
        fdm['ic/h-sl-ft'] = altitude  # altitude above sea level (ft)
        fdm['ic/vc-kts'] = speed      # calibrated airspeed (kts)
        fdm['ic/gamma-deg'] = gamma     # flight path angle (deg)

        fdm.run_ic()  # Run the initial conditions

        try:
            fdm['simulation/do_simple_trim'] = 1
            print(f'Trim succeeded for speed: {speed}  gamma: {gamma}')
        except jsbsim.TrimFailureError:
            print(f'Trim failed for speed: {speed}  gamma: {gamma}')
            pass

[clolsonus]

It will do a stable glide at 20-25 kts. With power I can cruise around all day at those speeds. I think the drag model is unrealistic and too low, but that shouldn't affect trimming (I don't think?) It has some drag.