Air Movement: Klift, Kmove, Etc.
-
Been trying to understand how Klift and other variables affect the behavior of air movement. I've read through the Blueprint Wiki:
KLift = 'n', -- Controller proportional parameter for vertical motion.
KLiftDamping = 'n', -- Controller damping parameter for vertical motion
KMove = 'n', -- Controller proportional parameter for horizontal motion.
KMoveDamping = 'n', -- Controller damping parameter for horizontal motion.
KRoll = 'n', -- Controller proportional parameter for roll changes.
KRollDamping = 'n', -- Controller damping parameter for roll changes.
KTurn = 'n', -- Controller proportional parameter for heading changes.
KTurnDamping = 'n', -- Controller damping parameter for heading changes.
LiftFactor = 'n', -- How much altitude the unit can gain/loose per second.Also looked at various units, and tried editing K variables to see how they behave. Still don't quite understand what K variables actually do. Are they related/affected by the LiftFactor? I'm trying to make an Air Transport more responsive to moving and dropping off units. My editing has so far caused it to perform worse or fly right through the map.
Control proportional parameter of what???
-
Welcome to hell: https://electronicscoach.com/proportional-derivative-controller.html
(not really, but buckle up rooster)
Those parameters are inputs for the aforementioned proportional derivative controller, an instance of which controls the motion of each aircraft.
A straight proportional controller would produce oscillatory motion around the target point that the aircraft is moving to. The introduction of a derivative (damping) term reduces oscillation while increasing the time to reach ("rise time") the target.
You can see about tuning PD controllers by hand here (ignore the integral Ki term, not relevant here), where Kp ~ KLift and Kd ~ KLiftDamping: https://www.ctrlaltftc.com/the-pid-controller/tuning-methods-of-a-pid-controller
Before any follow up questions, what's your level of math education?
-
@Hdt80bro you may find this interesting
-
@slicknixon
Calculus, but that was over a decade ago, so I am at zero for that these days. Still use algebra and trigonometry.
I assumed the damping effect was to reduce oscillation, after I sent the Transport through the map
-
You'll be fine. First, a little background.
1. A Little Background
Everything bolded is basic control theory terminology.
Think of the controller as a little computer, within which the distance between the current location of the aircraft and the target or desired location is referred to as error. For each term (P, I, or D) in a controller--be it a proportional (P), proportional-derivative (PD), or proportional-derivative-integral (PID) controller--the error, integral of the error, or derivative of the error is multiplied by a gain constant. The sum of the product of each of those modifications is then given as the output of the controller, translating into the force we want the thrusters of the aircraft to apply[0]. In a discrete system (like we have in a video game with sim beats, instead of the real world which is effectively continuous), that thrust is applied over the time of simulation step, or time step[1] (0.1 seconds, in our case), accelerating the aircraft on the desired trajectory towards the target location.
[0] This max force/thrust is capped at the maximum force that can be applied by the motor or thruster (think of a small electric motor--you can ask for a lot, but it will only give you as much as it will give, or light on fire, potentially). Max thrust may be a blueprint value, I don't have it in front of me. If it is, increasing maximum thrust will raise the ceiling of system performance.
[1] This may not be completely accurate in regards to the precise internals of the sim, but it's close enough for our purposes.
2. A Quick Calculus Refresher:
i. The derivative of the error is the rate of change of the error. This will be negative if we're moving towards our desired location (the error is becoming smaller and smaller with each sim step--the greater the rate it's becoming smaller, the greater the force it will ask for in the opposite direction) and positive if we're moving away from it, so increasing the derivative gain constant will reduce our tendency to overshoot the target while increasing the total time, or rise time, it takes us to reach the target (or reach the target for the first time, if we're oscillating around it).
ii. The integral of the error is the sum of all errors in each beat, from the start of the system to the present moment. If we're sitting across the room from each other not moving, the integral of the error between us will increase continuously (in a continuous system) by that amount each second, or by error*delta_t each sim beat, where delta_t is (again, in the case of FAF) 0.1 seconds. Introducing an integral term into the controller (which, as long as the aircraft has not reached its target, will ask for continuously more force from the motor or thruster) will compensate for steady-state error, or error introduced by steady state forces like gravity (in the case of an aircraft trying to maintain a given altitude). We're in a made up video game world, so we generally don't have to worry about steady state error. For this reason an integral term is not included in the controller in question (no "KLiftIntegral"), and we'll pay it no further heed.
3. What You Came For, Or the Brass Tacks
Adjusting the gain constants of a controller to produce the desired behavior is known as tuning the controller. There are analytical methods for tuning a system; they require knowledge of its internals (mass of the aircraft, drag, max thrust, etc.) and a certain baseline theoretical background. Given that calculus was the end of the line a long time ago, you're going to be tuning by hand (read as: trial and error). A basic tuning by hand heuristic is:
First the integral and derivative gains are set to zero. Increase the proportional gain until you observe oscillation in the output. Your proportional gain should then be set to roughly half this value. After the proportional gain is set, increase the integral gain until any offset is corrected for on a time scale appropriate for your system. If you increase this gain too much, you will observe significant overshoot of the SP value and instability in the circuit. Once the integral gain is set, the derivative gain can then be increased. Derivative gain will reduce overshoot and damp the system quickly to the SP value. If you increase the derivative gain too much, you will see large overshoot (due to the circuit being too slow to respond). By playing with the gain settings, you can maximize the performance of your PID circuit, resulting in a circuit that quickly responds to changes in the system and effectively damps out oscillation about the SP value.(SP refers to set point--target position, in your case. Remember, you can ignore the parts that mention an integral.)
Increasing bp.maxThrust[3] or decreasing bp.aircraftMass (which are proportional in their effect on the system as seen in Force = Mass * Acceleration, if they exist) will generally increase the possible performance of the system (read as: shorten the time it takes for the transport to settle on the desired location). Note that modifying either of those parameters will require retuning the gain constants.
[3] Assuming there's a bp.maxSpeed, you should be able to do this without throwing transport speed balance out of whack.
*EDIT:
Looking at the base air unit blueprint, there does not appear to be a MaxThrust (but there is a MaxAirspeed). I suspect increasing the gain constants will change flight characteristics without bound, as you discovered when you sent the little guy flying off the map.
You could look into dynamically adjusting the flight parameters via script when moving to pickup or dropoff to get the behavior you want. It's an intriguing enough idea that I might look into it myself if I get a minute.
-
Let me finish with a word of encouragement: like many of the physics-based elements in the game (looking at you, tactical missile trajectories), it's possible transport flight characteristics were developed to a "good enough" stage then shipped as is. Apply yourself here, with the benefit of time and the absence of a deadline, and it's possible you could make a serious improvement on GPG's initial effort.
Good luck.
-
Thanks for all the information. It actually does help to explain the variables, instead of them being some archaic text. I think the MaxThrust for vertical motion is the LiftFactor. I did send the transport through the map when I tried greatly increasing that value. And then it slowly lifted back up, like a demon from below!
-
Based on the comments on LiftFactor (though recognizing that you're the one who has experimented with it), it appears to be a limit on maximum vertical velocity, not acceleration/thrust.
Also, I lead you down a bit of a garden path with all my thrust talk--unit weight exists in the blueprints, but it's unused (1 in all cases, except SACUs which are set to 0 for some reason?). Without specific unit weights (but really masses--not economic mass, but physical mass) the notion of thrust is a nonstarter, and I'd be very surprised if it shows up anywhere in the engine. Even projectiles (missiles, mostly) define acceleration, not thrust.
