Trying to implement a PID algorithm auto throttle

[overpro]

Hi all,

by using Export.lua, I can get the TAS - TrueAirSpeed and I can control the throttle position by using

 LoSetCommand(2004, throttlePosition) 

and I'm thinking to use TAS to control the throttle position by using PID algorithm, but I'm unfamiliar with this subject. By reading wikipedia I got some basic knowledge : http://en.wikipedia.org/wiki/PID_controller

 

Please see the attached image, the test shows it's not acceptable. The response speed is too slow, and overshoot is big, the stable error is large, and seems it's not even a stable control.

X is time in seconds, Y is KTAS, the target KTAS is 220.5

:doh::joystick:

 

this is my code:

local TargetTAS = 220.50    -- I want A10 to keep 220.50 KTAS
local LastTAS = 0.0             -- the previous sampled TAS
local TAS = 0.0                   -- the current sampled TAS
local Thrust = -0.5              -- set the initial Thrust position to -0.5
local T0, T1                       -- T0 is the last sample time, T1 is the current sample time
local lastDelta  = 0                  -- the TAS Delta ( the value of TAS - TargetTAS) of the last sample time, 
local IntegralSum = 0           --Integral sum, 

function AutoThrust()
   if T0 == nil then T0 = T1 return end

   local tDelta = T1 - T0      -- tDelta is the elapsed time between last sample time and the current sample time
   local Kp = 2                    -- PID value
   local Ki = 1
   local Kd = 1
   local TASDelta = TargetTAS - TAS   -- the speed delta between real and target speed
   local PID_P = Kp * TASDelta   -- calculate the P part
   -- calculate the IntegralSum
   IntegralSum = IntegralSum + TASDelta * tDelta
   -- integral  saturation
       if math.abs(IntegralSum) > 1000 then
       if IntegralSum > 0 then
           IntegralSum = 1000 
       elseif IntegralSum < 0 then
           IntegralSum = -1000
       end
   end


   local PID_I = Ki * IntegralSum
  
   -- the D part 
       local PID_D = Kd * (TASDelta - lastDelta) / tDelta
    -- P+I+D
   local Pout = PID_P + PID_I + PID_D
    -- map the PID value to Thrust position value [ -1, 1] , -1 is the max throttle, 
   Thrust = Pout / -2000

  --update some value
   lastDelta = TASDelta
   T0 = T1

   textOutput = string.format("t=%f;Thrust=%f;TAS=%f;TASDelta=%f;Pout=%f;P=%f;I=%f;D=%f;\n", T1, Thrust, TAS, TASDelta, Pout, PID_P, PID_I, PID_D )
   print( textOutput )
   logFile:write( textOutput )
end

I played xplane for long time and I know the auto throttle works very well: fast response, no overshoot, and it's stable.

any suggestions on how to implement an automation throttle is appreciated :)

 

If any one has the interesting to have a try, please download export.lua, tcpServer.lua

 

run tcpServer first by execute:

 lua tcpServer.lua

and start a A10 instant mission, engage the auto pilot. the data will be recored to export.log, use GNU Octave script to plot the TAS data by execute

plotA10Data("export.log") 

note: extract OctaveScriptsForPlotData_m.zip to YourOctavePath\share\octave\3.6.0\m\

 

The Kp, Ki, Kd is hardcoded in the tcpServer.lua script but you can change it on the fly by using script tcpClient.lua, usage:

lua tcpClient.lua 5 2 1  

5 2 1 is 3 numbers represent Kp Ki Kd

Export.lua

OctaveScriptsForPlotData_m.zip

tcpServer.lua

tcpClient.lua

Edited April 12, 2012 by overpro

[Depth]

Looks to me like you have to be pretty close to 220 IAS for it to work, assuming it stops adjusting the throttle when it hits the sweet spot. If it's under 220 it'll keep increasing the throttle until it overshoots, then reduce it until it undershoots. Like a yo-yo.

 

Different throttle adjustments at different deltas and some manual speedbrake input while using it should give some results but it will still be unresponsive.

[sobek]

I played xplane for long time and I know the auto throttle works very well: fast response, no overshoot, and it's stable.

any suggestions on how to implement an automation throttle is appreciated :)

 

The difference is probably that in X-plane the turbine lag is not modelled as severely as in DCS. I'll take a look at your code and see if i can make any suggestions, but no promises.

[ldnz]

Have a look at the Zeigler-Nichols method of PID tuning - its very effective for systems that are either already in place or too complex to practically model. The short version is that you set the integral and deriv gains to zero, then slowly increase proportional gain until you get the system to a stable oscillation. Once you have that, you use this gain and the frequency of the oscillation to give you starting values for all three gains. This will give you a stable (but not ideal) system with a little overshoot. Its not too hard from there to trim it in perfectly.

 

I see no reason why PID based auto throttle could not be effective in both maintaining a set speed and responding to a change in speed (step response). Once the basic principles are in place additional things such as a bit of feed-forward (ie setting a base throttle amount for a given speed - gets you in the ball park quicker) can be added.

 

I see that wiki page has some notes on Z-N tuning - that should give you the basics.

[PeterP]

my suggestion is to implement a second temporary target speed. exactly between your current speed and your final.

Once this temp-target-speed is reached you calculate a new temp-target-speed following the same rules.

Limit it to do it 10 times so it will not go to infinity.

 

-please don't ask me how to code this :P (I didn't read the link), but once implemented, it should be robust enough to remove the yo-yo effect and be able to handle the lagging-trust.

Edited April 12, 2012 by PeterP

[sobek]

[...]

 

As the system response will be largely altitude dependant but quasi stationary in the time domain, don't you think that an adaptive controller might be better suited for the task?

[Yo-Yo]

And do not forget that the system itself is NOT-LINEAR that can ruin all tuning methods based on linear or quasi-linear systems.

THe system is non-linear in terms of sustained response (Thrust vs THrottle) and in terms of dynamic response because time constant is very different near idle and near MAX.

[ldnz]

Adaptive control algorithms generally over complicate the coding problem (and stability if done badly!) for what would probably be limited gains in this system. I would be very surprised if PID was not sufficient for the job. Once the basic loop is stable in both steady state and step response I would consider adding in feed forward terms (for faster step response) - good point about considering altitude as well. The altitude and speed terms can be very broad brush - they would only be used as starting throttle positions for PID to then correct.

 

The basic code given above looks like a correct implementation of the PID algorithm though you may have to play with the integral saturation value.

 

Unfortunately I've not played with LUA in DCS yet! If you could send me the file and a quick guide on where to put it and how to trigger it I'd be happy to play around with fine tuning it. Day off work today!

 

Note: yes outside of physics experiment land nothing is linear - but PID is still the most widely used algorithm out there because a) its well understood and b) its easy to use and c) it works well enough in most situations.

Edited April 12, 2012 by ldnz
Nothing is linear!

[ldnz]

I've used what is basically the same code (optimised for fixed point math) to implement a cruise control on a motorbike - similar problems including a widely variable throttle/torque map.

[sobek]

And do not forget that the system itself is NOT-LINEAR that can ruin all tuning methods based on linear or quasi-linear systems.

THe system is non-linear in terms of sustained response (Thrust vs THrottle) and in terms of dynamic response because time constant is very different near idle and near MAX.

 

 

Indeed, a real can of worms once you start to think about it.:P:)

Edited April 12, 2012 by sobek

[overpro]

my suggestion is to implement a second temporary target speed. exactly between your current speed and your final.

Once this temp-target-speed is reached you calculate a new temp-target-speed following the same rules.

Limit it to do it 10 times so it will not go to infinity.

 

-please don't ask me how to code this :P (I didn't read the link), but once implemented, it should be robust enough to remove the yo-yo effect and be able to handle the lagging-trust.

 

ah, this is interesting! I will have a try.

[overpro]

I noticed the algorithm is not correct:

-- the D part          
local PID_D = Kd * (TASDelta - [b][i][u]LastTAS[/u][/i][/b]) / tDelta

 

I think it should be

-- the D part          
local PID_D = Kd * (TASDelta -[u][i][b] lastDelta[/b][/i][/u][b][i][/i][/b]) / tDelta

 

because D part is the error's change rate. I have updated my original post as well as the attachement.

[ldnz]

Code is fine - changed KP to 100, KI and KD to 0 and it works nicely as a basic proportional controller. Stable and fast. Now digging out MATLAB to get some charts and tune it properly.

[overpro]

Code is fine - changed KP to 100, KI and KD to 0 and it works nicely as a basic proportional controller. Stable and fast. Now digging out MATLAB to get some charts and tune it properly.

 

I have rewrite the tcpServer.lua and uploaded a new file : tcpClient.lua. it's for change Kp, Ki, Kd during tcpServer.lua is running.

 

usage:

lua tcpClient.lua 100 10 1

100 -- Kp

10 -- Ki

1 -- Kd

 

Please note that the tcpServer.lua is updated, you need to download it again :)

[Speed]

Indeed, a real can of worms once you start to think about it.:P:)

 

Not only is throttle position vs. thrust non-linear, there is a big phase delay between throttle position and thrust, and another phase delay between thrust and speed...

 

PID control is perhaps over-complicating the problem a bit for a first step. Why not just try proportional control (as ldnz suggests)? I donno, maybe add a hysteresis into it too?

 

Anyway, not a control system engineer myself though, and I only have vague memories of the class. I just think it would be better to start basic, and only implement a more advanced control scheme if the basic one doesn't work.

[ldnz]

Well the beauty of PID is that it can be P/I/D or any combination. In this case I've got it working well enough as a reasonably high gain proportional controller with very limited integral action to lower the steady state error. Still working on some tweaking to the saturation limits of the integral that will hopefully allow more integral action to be applied to achieve a quicker steady state.

 

The next problem is where this is actually useful. At the moment the code runs continuously locking the plane to a fixed speed (in level flight). I've not dug into the scripting possibilities too much yet but I see a use for this if it can be triggered only when the autopilot is engaged as an extra speed hold (as opposed to speed set and achieve) feature. This also allows better control optimisation as it only needs to stabilise for steady state conditions and not worry so much about step response (ie suddenly telling it you want to be 30 kn faster and leaving it to handle the acceleration).

[overpro]

The next problem is where this is actually useful. At the moment the code runs continuously locking the plane to a fixed speed (in level flight).

 

This is actually just for fun, with helios we can make a new control panel and set the desired speed in there, so people can set the desired speed.

 

And I think with a minor update to the tcpClient.lua I can change the target speed on the fly as well.

[GGTharos]

I wonder if servers will now start checking export.lua so that things like this don't get used, knowing past history.

[PhoenixBvo]

A very cool idea. I'll definitely check it out as soon as I find some time.

 

A while ago I guessed that the lua export feature might allow control loops to be added. Then I got the idea, and this would really be cheating, that if missile position and velocity would also be available, it should be possible to write a missile avoidance autopilot mode. Just for the fun of it, of course.

 

This would require an all channel controller and cover a large part of the flight envelope. You'd need a nonlinear approach, or at least gain scheduling, to achieve the desired dynamics. A good flight dynamics model of the A-10 should be the basis for the design process. Which can be extracted from the simulation by model identification in conjunction with the same lua exporting feature. On top of that would go a state machine deciding which behavior the situation requires (e.g. beaming, driving the missile into the ground etc.).

How is that for a project? If only I had the time... *dreaming on* :happy::thumbsup:

[GGTharos]

A while ago I guessed that the lua export feature might allow control loops to be added. Then I got the idea, and this would really be cheating, that if missile position and velocity would also be available, it should be possible to write a missile avoidance autopilot mode. Just for the fun of it, of course.

 

It has been thought of before, but with the A-10C you won't have enough performance to pull it off in most cases anyway, unless it's just against MANPADS and you happen to have over 300kt of energy. As for forcing missiles into the ground, that's pretty much cheating :D

[ldnz]

Challenge... it's tempting to have a go, but as mentioned with the A10 its an energy battle and you just don't have enough!

 

A very cool idea. I'll definitely check it out as soon as I find some time.

 

A while ago I guessed that the lua export feature might allow control loops to be added. Then I got the idea, and this would really be cheating, that if missile position and velocity would also be available, it should be possible to write a missile avoidance autopilot mode. Just for the fun of it, of course.

 

This would require an all channel controller and cover a large part of the flight envelope. You'd need a nonlinear approach, or at least gain scheduling, to achieve the desired dynamics. A good flight dynamics model of the A-10 should be the basis for the design process. Which can be extracted from the simulation by model identification in conjunction with the same lua exporting feature. On top of that would go a state machine deciding which behavior the situation requires (e.g. beaming, driving the missile into the ground etc.).

How is that for a project? If only I had the time... *dreaming on* :happy::thumbsup:

[overpro]

ha I don't think there are peoples implement such an auto control to cheat, why don't focus on the most demanding features such as a pure console based server application, the server keeps crashing and crashing ....

and I have to restart it manually, but you know it is frustrating.

[Speed]

I wonder if servers will now start checking export.lua so that things like this don't get used, knowing past history.

 

Well, there would go TARs. Tacview.. some of the other mods people are enjoying.

 

Maybe on public FC3 servers would this happen, but at this point, I don't think anyone cares enough because A-10/Ka-50 aren't usually going head-to-head on public servers.

 

But, I'm really hoping that ED to completes the improved integrity checking system they are either working or thinking about working on.

 

Honestly, what I need to work on is a Lua mods loading system. That could help the alleviate any potential problems, and also make it easier for multiple mods to work together, even within the same Lua environment.

[Ratfink]

Just a thought, but maybe a "Fuzzy PID" control method may be more suitable than a basic PID. It could help to provide more stable response if you need to take many factors into account.

 

Fuzzy logic provides a kind of percentage-based way of applying 'IF-THEN' statements, which can combine to produce a more 'human' like approach.

 

You can apply it to PID to make it adaptive, and provide some autotune :)

[ldnz]

Yep thats another option, but a simple PI controller seems to work fine for steady state flight.

 

To take this further a set of specifications need to be settled on ie:

1) maintain steady speed within 5kn of target

2) achieve the above with climb/dive angles of +/-10 degrees

3) handle a step change of set speed with a settling time of 20 seconds and a maximum overshoot of 5%

 

Obviously these are all made up but if a meaningful specification can be described (and is within the capabilities of the engines/airframe) there are many controller types to be tailored including state/space, fuzzy logic, PID with feed forward, various adaptive control algorithms etc.