Jump to content

Towards a better PID controller.


nhnifong
 Share

Recommended Posts

Threads like this are the reason we started the Science Labs board. It's just awesome to see such an aggregation of brain power come together to tackle a difficult and interesting problem.

So, what I would consider to be the ideal solution to SAS is this: When enabled, it would hold the vessel's attitude to what it was when it was engaged (as it tries to do now), but if any input is applied by the player, it would allow you to command the attitude setpoint.

I think any solution to the SAS system will involve some sort of adaptive scheme. It could start off with default values, and by noting the input it's applying versus the reponse it's getting, it could adapt its parameters to something more suitable.

The problem is that this response might be buried in noise, or it might only become measurable after a delay, so grabbing good data isn't easy. Factor in the vibration from the vessel's own geometry, and it gets even worse.

I do have a few ideas about how to exclude the vibration from the input... We know where the CoM is in relation to the vessel transform, so we can take a cross vector of that against a 'pristine' CoM, calculated using the stored pristine coords for each part, instead of the actual part positions. That difference is your 'flex' vector, and we can exclude that from the vessel's actual rotation to get a 'rotation at CoM' value, and derive the angular velocity at CoM from that.

Excluding flex, we can hopefully have the true angular velocity for the vessel, with makes for a much more reliable input to any PID scheme.

EDIT: Better yet, instead of a cross vector, we can take a from-to quaternion, and use it to directly exclude the wobble from the vessel's rotation. The resulting rotation can then be used to find the flex-free angular velocity.

Cheers

Edited by HarvesteR
Link to comment
Share on other sites

Well the stock ASAS unit needs some tweaking, in a couple of areas.

Making it adaptive is one thing, so it adapts the PID-parameters after the size of the craft (and maybe available torque) is not that hard to do (if you neglect the I-part which in 99% of the cases is completely unnecessary and just always adds overshoot, windup and nasty stuff). And then it's the stuff around that, one thing is that instead of feedbacking to % of control output it should instead feedback to the amount of torque it produces. So for example activating RCS will instead of making it go haywire just reduce the control outputs so it produces the same amount of torque as before. But that requires some nifty programming to calculate the amount of torque the RCS-thrusters can provide in each direction so it has something to go after as well as the torque provided by gimballing engines (and control surfaces maybe if it's not to overkill). And then there are the biggest stuff which would be really appreciated, flex compensation and RCS balancing. But I trust you Harv that you will come up with something to fix that :P

And regarding to that attitude setpoint, it would be nice if we could snap that to the prograde/retrograde/normal/../Nodes etc (mechjeb style), and maybe even have an extra Navball icon to show where it is currently.

Link to comment
Share on other sites

Dropping the integral gain completely isn't a great idea, otherwise we'd all be using the avionics package on everything. You need at least a small integral gain to trim out non-zero-mean disturbances to get to zero steady-state error, for example while still in the atmosphere. Some better integrator reset and anti-windup should help prevent it acting up as much.

I like your idea of mapping rotational control input to torque though. If RCS is off, the torque limit is set by the command pod gyro capacity. When you enable RCS, the max torque limit obviously increases, but the thrusters should only have to fire if the desired control input torque is greater than what the pod gyros alone can provide.

Surface-mode ASAS is something I really want to see in stock, either by a toggle or by different choice of part. Particularly for planes, Avionics doesn't cut it since it requires constant fiddling with the trim to work properly, and fixed-point-in-space ASAS means my planes constantly pitch up.

I do have a few ideas about how to exclude the vibration from the input... We know where the CoM is in relation to the vessel transform, so we can take a cross vector of that against a 'pristine' CoM, calculated using the stored pristine coords for each part, instead of the actual part positions. That difference is your 'flex' vector, and we can exclude that from the vessel's actual rotation to get a 'rotation at CoM' value, and derive the angular velocity at CoM from that.

Excluding flex, we can hopefully have the true angular velocity for the vessel, with makes for a much more reliable input to any PID scheme.

EDIT: Better yet, instead of a cross vector, we can take a from-to quaternion, and use it to directly exclude the wobble from the vessel's rotation. The resulting rotation can then be used to find the flex-free angular velocity.

Cheers

Interesting, I hope you get a chance to try that out and let us know whether it works! Regarding adapting the gains dynamically online, I have a quote for you by the president of the IEEE Control Systems Society: "There was a brawl in a bar one night, and then an adaptive control session broke out."

Edited by tavert
Link to comment
Share on other sites

So, what I would consider to be the ideal solution to SAS is this: When enabled, it would hold the vessel's attitude to what it was when it was engaged (as it tries to do now), but if any input is applied by the player, it would allow you to command the attitude setpoint.

I've been trying to implement something like that for flight simulation for a couple of years now. Of course, it's a slightly different problem there. I want the aircraft to maintain altitude and airspeed if no control is applied, but allow for free control if it is. Essentially, I want it to trim itself without the player having to do anything. Hell of a problem. I've had a few almost working solutions, but nothing I've been satisfied with. It's easier for a rocket in vacuum, but still, if you figure out a good implementation, I would love to take a look at it.

For the principal-axis dynamics, the linear-problem approximation only breaks down in corner cases

Precisely what I was trying to get to.

Link to comment
Share on other sites

Great discussion here! I've been thinking about this on and off ever since the first time I designed a rocket that ASAS wobbled into pieces on me.

I think any solution to the SAS system will involve some sort of adaptive scheme. It could start off with default values, and by noting the input it's applying versus the reponse it's getting, it could adapt its parameters to something more suitable.

<...>

EDIT: Better yet, instead of a cross vector, we can take a from-to quaternion, and use it to directly exclude the wobble from the vessel's rotation. The resulting rotation can then be used to find the flex-free angular velocity.

Cheers

This strikes me as... problematic. For two reasons:

1) doing a machine-learning style adaptive controller that observes true output to tune itself seems to me like killing mosquitos with anti-aircraft guns. This would be pretty complicated to implement, would probably take a few minutes of flight to dial itself in (which would always be those super-sensitive few minutes during heavy atmo at launch). I don't see that it would get you anything better than one-time calculation of optimal PID or L1/L2 controller gains when loading the craft into the launchpad - if you assume a target rotation time, you already have all the info you need to solve for these. I recognize this doesn't take wobble into account, however...

2) dealing with deviations from the ideal math, like rocket wobble, is not worth the effort IMHO. The current ASAS is waaaaaaay suboptimal, and just tuning its gains per craft would be a huge improvement. If your rocket design is so wobbly it can't be controlled with a PID/L1 tuned via MoI/thruster torques and desired rotation time, then I think your space program has bigger problems than your ASAS control model. :D If you manage to design a reasonably stiff rocket that hits a resonance with the control inputs (I anticipate this would be rare), you could just ask for a different maneuver time and calculate some different gains that don't resonate with your rocket.

Also Harvester, you could mitigate the wobble issues with the controller in a much more optimal way by.. .well... fixing the wobble issues in KSP, generally. :sticktongue: Any chance you can weigh in on that thread?

Link to comment
Share on other sites

I've been trying to implement something like that for flight simulation for a couple of years now. Of course, it's a slightly different problem there. I want the aircraft to maintain altitude and airspeed if no control is applied, but allow for free control if it is. Essentially, I want it to trim itself without the player having to do anything. Hell of a problem. I've had a few almost working solutions, but nothing I've been satisfied with. It's easier for a rocket in vacuum, but still, if you figure out a good implementation, I would love to take a look at it.

Perhaps you should be looking into how Honeywell, Rockwell Collins, etc do it?

I found a gold-mine presentation on the math you need to do for adaptive control to work properly: http://www.cds.caltech.edu/archive/help/uploads/wiki/files/140/IEEE_WorkShop_Slides_Lavretsky.pdf

It starts with the required background in Lyapunov stability, then gets into the meat of adaptive control from slide 42.

Link to comment
Share on other sites

Looks like a good read. I'll go through it in more detail when I have a moment. Thank you.

The main problem I was having is that I don't have a particular expectation for how the aircraft should behave with applied input. I only have a model for behavior under neutral input. Specifically, I expect zero net torque and zero net force, corresponding to a trimmed flight. So when input is applied, I don't have a reference model to do the adaptation from. But maybe I'm missing something. Or maybe I could fake a reference model that would work for cases with input. I'll look into it. If you have any other reading you can suggest, I'd appreciate it.

Link to comment
Share on other sites

Are you trying to write a single controller that you want to get to work on a variety of aircraft without any knowledge of the important dimensions, control surface layout, etc? That could be quite tricky, if you don't have the luxury of a flight-test program and certification process to go through and do all the necessary tuning.

Link to comment
Share on other sites

I can take a list of parameters for each aircraft. These can include any information about aerodynamic configuration and even some performance data. But that doesn't help me with the model as much as you might think. I don't want to just have a model and PID the aircraft to that model. I want the aircraft to respond naturally to input, as it would if it was trimmed to the correct air speed. I just want the trim to happen automatically. The problem is that correct trim will depend on weight distribution, throttle, bank, etc. This isn't something I can just come up with a table of numbers for.

I suppose, I can adjust trim based on deviation from the model, which might not trim it quite right when input is applied, but it should converge to properly trimmed flight as input goes to neutral.

Link to comment
Share on other sites

It sounds like you just want the controller to hold its trim as soon as the pilot starts touching things? I imagine you tried something to that effect and the difficulty was what happens when the pilot lets go and stops applying manual input? The state's changed because of the manual inputs, so when the controller tries to pick back up where it left off the trim is all wrong and you get some screwy transient?

Link to comment
Share on other sites

Something like that. The main goal is to allow a novice pilot to fly a faithful sim or RC model. When you set the trim on a real aircraft, what that really does is change the neutral position of the controls. Instead, I have the pilot use a control stick that returns to predefined neutral position corresponding to 0 input. The system maps pilot input (-1, 0) to (-1, x) of the control surface and (0, 1) to (x, 1). I use linear mapping for both regions at the moment. So x corresponds to the trimmed neutral position of the surface, and the whole problem is to determine a good value for x for each of the control variables.

This leaves the question of what is a good value? I am looking at 3 control surface groups (rudder, elevator, and ailerons) and the throttle. Each one has slightly different requirements, but rudder and ailerons are easy and I have them working flawlessly. All they have to do is make sure your turns are coordinated without pilot having to actually touch the rudder controls. Elevator I found to be the trickiest. Effectively, the airplane should be stable at whatever angle of attack that it happens to be at the moment. Throttle is slightly easier. It should be set to provide enough thrust to offset the drag.

In practice, what this means is that if you let go of the controls, you are in level flight (or constant rate turn). If you want to speed up, you pitch down a bit and let go of controls again. If you want to descend, you pull back on the throttle, and letting go of controls will have the aircraft level off again. This should make takeoff, flight, and landing a piece of cake regardless of the aircraft performance. At the same time, if you want to perform a more complicated maneuver, the system provides no additional restriction beyond what the aircraft can do.

My initial thought was simply to find values that balance forces and torques at given speed, but what happens is that response never catches up with the system. So say I wanted to slow down a bit. I pull back on the stick and let go. The neutral position tries to balance forces, but there is just enough of the pitching motion left over for it to continue pitching up, slowing down, and eventually stalling. Or vice versa. If I pitch down, I end up leading the aircraft into a dive. In other words, static stability is easy, but I found no easy way to make it dynamically stable.

Obviously, I can just capture altitude and air speed when controls become neutral and PID to that until pilot starts moving sticks again, but this feels very unnatural and makes the aircraft feel heavier than it is. I still feel like there is a much better solution, dealing with the actual problem of stability, but I have not been able to come up with anything satisfactory yet.

Link to comment
Share on other sites

I may be completely misunderstanding, but from your post I have these questions: Why do you want to control airspeed with the elevator and altitude with the throttle, instead of vice versa? It sounds like you don't have dynamic stability because you are using naive uncoupled controllers on what are clearly coupled states/control inputs of the system, and you are encouraging the operator put the vehicle in unrecoverable states by how you interpret the sticks as commands. Is your goal to do something similar to the helicopter crash-protection systems we've had for years, that revert to hovering when you let go of the sticks? Or is it supposed to be actively compensating while the pilot is flying? And how is it different from a full autopilot that just takes speed and angular rate commands from the pilot?

EDIT: What I meant to say was that flying half a plane is a lot harder than flying the whole thing, because you have to guess and deal with what the other half is doing. Moreso if which half you're controlling changes periodically, i.e. which of the four sticks the operator is actually touching at the moment.

Link to comment
Share on other sites

The way you fly an airplane is you adjust air speed with attitude corrections and you adjust rate of climb/descent with throttle. Yes, if you want an immediate response, it's the other way around, but for sustained flight, it's all about balance.

And yes, the two are dynamically linked. I did actually take all of that into account. The entire model included the climb rate, bank angle, etc. And it derived the equilibrium conditions for the aforementioned controls. The problem was that this equilibrium was not dynamically stable even after coupling is looked after.

Is your goal to do something similar to the helicopter crash-protection systems we've had for years, that revert to hovering when you let go of the sticks? Or is it supposed to be actively compensating while the pilot is flying? And how is it different from a full autopilot that just takes speed and angular rate commands from the pilot?

I want the system to actively adjust while pilot is flying, but only to make sure that the response is fluid. If a player makes a correction, response should be as immediate as if the skilled pilot applied the same correction, re-adjusted trim, and relaxes on the stick. And the reason I can't simply have an auto-pilot is because the pilot should be able to apply greater input for a maneuver, and said maneuver should be executed as if no controller is in place.

I want the plane to be easy to fly for a beginner and I want a skilled pilot to not feel any restriction with this system.

Link to comment
Share on other sites

My initial thought was simply to find values that balance forces and torques at given speed, but what happens is that response never catches up with the system. So say I wanted to slow down a bit. I pull back on the stick and let go. The neutral position tries to balance forces, but there is just enough of the pitching motion left over for it to continue pitching up, slowing down, and eventually stalling. Or vice versa. If I pitch down, I end up leading the aircraft into a dive. In other words, static stability is easy, but I found no easy way to make it dynamically stable.

Obviously, I can just capture altitude and air speed when controls become neutral and PID to that until pilot starts moving sticks again, but this feels very unnatural and makes the aircraft feel heavier than it is. I still feel like there is a much better solution, dealing with the actual problem of stability, but I have not been able to come up with anything satisfactory yet.

So you're applying the equilibrium inputs, which won't damp out any residual transients. Since you probably can't accurately predict ahead of time when the user is going to let go, it sounds like what you need is just a temporary reference tracker to get rid of the transient and return to where the user left things (same as the ASAS toggle problem). As long as that reference tracker shuts off when the user starts controlling things again, what would be wrong with that? I'm not sure I get what you mean by feeling unnatural, but I'm not a pilot...

Link to comment
Share on other sites

For starters, you really feel the autopilot taking over. The overshot, the correction, all of the little adjustments it does. It's very different than letting go of controls on a trimmed aircraft. There is also how it responds to small adjustments. Say, I pull the stick very gently, then gently return it to neutral position. What will happen? The airplane will pitch up, climb a little and slow down as I pull the stick back. As I return it, it will dip, drop, and speed back up. When I let go of the controls, the air speed and altitude are essentially unchanged. It's like a damn cruise control. All because the trim remained constant until I let go of the controls, and by that point it picked up the same residual as before. In contrast, if I have the trim track the plane's attitude even when input is applied, and if I can make it work as described earlier, when you pull on the stick gently and then let go gently, the net result will be a slower flight.

Finally, the dynamics are linked, as robot pointed out. Say I want to descend a bit. I pull back on the throttle, plane slows down just a touch, enough for reduction of lift to dip the plane down. It starts to descend, picks up the speed and finds new equilibrium in nose-down attitude; descending at a constant rate. Now, suppose I also decide to slow down a bit, so I pull back on the stick just a little. I have to keep pulling on the stick to fly slower as described above. But as I slow down, the amount of lift and drag also change. Now I need a different throttle setting to maintain descent. But the neutral position for throttle hasn't changed. Say I was flying slow already, so reduction in speed and corresponding increase in AoA forces me to increase throttle. As I slide throttle up, past neutral position, suddenly the reference changes and instead of nudging throttle up just a bit, the engine suddenly revs up like I'm trying to take off. That's not good.

If you want a real world analogy that you might have actually come across without flying, have you ever driven a car with a crappy automatic transmission that switches with completely the wrong timing? It's kind of like that but with an airplane. It feels fake. It isn't any fun, and it can actually make landing more difficult than no assists.

So you're applying the equilibrium inputs, which won't damp out any residual transients.

Precisely. Are there any other methods of looking after that? I don't have to predict necessary damping perfectly. If the plane ends up going a little faster or a little slower after the pilot lets go of controls, it's not the end of the world. Just so long as it settles down and can easily be adjusted with small amount of input.

Link to comment
Share on other sites

If you want a real world analogy that you might have actually come across without flying, have you ever driven a car with a crappy automatic transmission that switches with completely the wrong timing? It's kind of like that but with an airplane. It feels fake. It isn't any fun, and it can actually make landing more difficult than no assists.

Yes, yes I have. The origin of my screen name is because I used to own a Trans Am convertible, which stupidly had the crap-tastic 4L60-E instead of the far superior T56 six-speed. Half of my lab actually works on semi-autonomous automotive control, that would seamlessly take over for a distracted talking-on-their-phone or out-of-control driver. Part of the difficulty is doing so in a way that the driver doesn't notice.

Precisely. Are there any other methods of looking after that? I don't have to predict necessary damping perfectly. If the plane ends up going a little faster or a little slower after the pilot lets go of controls, it's not the end of the world. Just so long as it settles down and can easily be adjusted with small amount of input.

I'm making up heuristics here, but what about maintaining two sets of trim commands. One primary equilibrium input based on positions, and a damping offset based on rates. You only actually apply the damping offset for a short time (with a quick decay factor to trail it off, whether or not it is able to stop things completely in that time) right after the user stops providing input. So if the user actually left things steady, it won't do anything. But if there's a residual transient, let your controller briefly try to slow it down, but not take over completely. This might also feel strange due to unexpected input spikes when you let go of the controls, so this would have to be an assistance mode in which the expectation is you don't leave things alone if anything's moving...

Link to comment
Share on other sites

.....I didn't take control theory, and this thread seems full of people who did; I'm going to be very cautious :D

So, what I would consider to be the ideal solution to SAS is this: When enabled, it would hold the vessel's attitude to what it was when it was engaged (as it tries to do now), but if any input is applied by the player, it would allow you to command the attitude setpoint.

With "command[ing] the attitude setpoint", do you mean that stick displacement translates to angular displacement from the currently locked attitude (could be called "angle command"), or that stick position commands a proportional angular velocity? ("rate command" as they called it at NASA)?

Both solutions have their strengths, actually I'd like to have choice between both: rate command should be good in space (especially with reaction wheel control, might be a bit thirsty with RCS) and fair in atmosphere with both joystick and keyboard; much better than what we have now for flying planes with the keyboard, I think. Angle command would be great in space for powered landing (locking to the zenith and flying helicopter-like), and also great in atmosphere with sticks if it auto-locks to the prograde direction - becoming "AoA command", which should make a lot of sense for planes.

Edited by thorfinn
Link to comment
Share on other sites

Having "stick" set rate while ASAS is engaged would probably be the best solution. PID requires very little modification to track a reference that rotates at a constant rate. And this would work naturally with the fine adjustment mode that's already in the game. It'd let you make very small corrections or make serious adjustments to course, all with ASAS is engaged.

Link to comment
Share on other sites

For your flight simulation project, don't you think that approximating the Airbus "normal law" should be adequate? In normal law stick forward/aft requests a load factor (AoA command compensated for IAS, I'd say), stick left/right commands roll rate, and the turns are auto coordinated - that last part you already accomplished, right?

Operating above that you have stall protection, overload and over speed protection, et cetera. This doesn't give altitude and velocity hold, but I think that it's more similar to what a layman would expect. Also, I think that the time constants for speed control (vertical and horizontal) are just too disparate from those involved with maneuvering to do both things well in the same system, if you want that feature it should operate at a higher logic level.

Edited by thorfinn
Link to comment
Share on other sites

That's kind of the point. I don't want overspeed and stall protection. I want a skilled pilot to sit down and feel almost no difference from directly controlling an aircraft save for not needing to touch the trim wheel.

Link to comment
Share on other sites

The protections operate at a higher logic level too, you'd just omit them ;)

Overspeed protection just means "IF (airspeed > (Vne - V_margin)) THEN pitch up F(airspeed) degrees", stall protection should be something like "IF alpha_normal(stick_pos, airspeed) > Alpha_prot THEN alpha_command = alpha_alternate(stick_pos) ELSE [...] "... see http://www.airbusdriver.net/airbus_fltlaws.htm

Edited by thorfinn
Link to comment
Share on other sites

Even with these things disabled, that thing behaves nothing like a normal aircraft. I understand perfectly why you'd want this on passenger plane. Makes for smoother, safer ride. But you aren't going to want this sort of thing on a fighter jet or a stunt plane. I really don't want this to turn into training wheels you'd disable when you get a hang of flying. I want it to be absolutely unnoticed by a skilled pilot while helping a novice. A smart enough system looking after the trim setting ought to do just that.

Link to comment
Share on other sites

Even with these things disabled, that thing behaves nothing like a normal aircraft.

Yes, if you have experience with "classic" mechanical aircraft, it would be quite disconcerting at first.

I understand perfectly why you'd want this on passenger plane. Makes for smoother, safer ride. But you aren't going to want this sort of thing on a fighter jet or a stunt plane.

Stunt plane, yes. Fighter jet... not anymore? From a NASA Dryden publication about the F-16: "The longitudinal control law is a blended pitch rate and normal acceleration command system (...) Lateral stick inputs are translated into a limited roll rate command". This article from a magazine by a US Navy pilot describes in great detail how the F-16 and F-18 fly, and there are very significant differences both from one another and from classic flight behaviour. And I've heard the VTOL control laws of the F-35 are so ridiculously user-friendly that helicopter pilots have actually remarked that it's cheating :D

Fighters actually fly with envelope and load factor protections on nowadays, so the pilot can yank the stick regardless of the current underslung loads. I assume that there is a manual override button available.

You could argue that it IS "training wheels" permanently on: I guess that the military wants them so that the pilot can concentrate on situational awareness, working the radar and ECM sets, and generally not getting shot down. I suspect that Airbus civilian FBW descends quite directly from French experience with the Mirage 2000.

Link to comment
Share on other sites

Oh, I know that any modern fighter will have all input filtered through a controller. When you want your aircraft physically unstable but stable with respect to pilot input, there is just no way around that. But the requirements there are still quite different from what you listed for Aerobus. Pitch control -> Load factor translation is very natural for large passenger or cargo plane, where you basically want to maintain something like 1G in the cabin during every maneuver. It's not what you want for precision flying, though. Having fine control of attitude is far more important than fine control over the load factor, especially if you are operating near critical AoA while flying formation.

And yeah, for a fighter sim, I wouldn't even worry about it. I'd have stick alter reference and PID to that. There's a reason why pilots call these things lawn darts. For the purposes of this discussion, think conventional aircraft with a cable or hydraulic controls and physical trim tabs on control surfaces.

It might sound like I'm being particularly picky, but this is the interesting problem. I know how to write a controller for a fighter jet or a commercial airliner. These are solved problems. This one does not seem to have a standard solution. That's what makes it worth solving.

Link to comment
Share on other sites

Do you have a good model of the process (aircraft, whaterver) you want this automatic trim on?

I did something similar back when I was a student. We designed and implemented a reversing regulator for a model King Hauler truck with two trailers, and it turned out that our angle sensors weren't up to measuring the angles between the parts of the system. We therefore designed and implemented a bias estimator (i.e. the measured angle = actual angle + meas bias), and used the actual angle for feedback instead of the measured angle. (We used the pole placement method for the estimator, nothing fancy.)

If you have a good model of the aircraft I think you'd be able to do something along the same lines and construct a trim estimator.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...