Not a member yet? Why not Sign up today
Create an account  

  • 7 Vote(s) - 4.86 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
Advanced aerial AI (version 5.32)

#11
OP updated with version 2.5. This version includes a basic form of machine learning to learn the vehicles "pitch correction factor". This is the upwards angle the vehicle needs to keep in order to maintain level flight, which is useful for many kinds of thrustercraft in order to maintain their desired altitude.
Reply

#12
Heh, looks cool. By the way, your "machine learning" looks like it's just a kinda ad-hoc PID controller. The lack of anything that looks explicitly like a PID system suggests that you may not have encountered them before. I strongly suggest looking into it. It's actually pretty simple, and you seem to be using the "P" (proportional) part already, which is using the difference between the current and target values to influence the setting of the control value. A full PID system can be harder to tune, but there are probably some reasonable defaults that can be used for most craft.
Reply

#13
I'm aware of the existence of PID systems but I don't know anything about them. I'm actually looking for someone who *does* know about them to help me out. If you have a reference you can point me to, that would help. Even better, stop by the official Teamspeak server and we can discuss some possibilties.
Reply

#14
Well I find the wikipedia page: https://en.wikipedia.org/wiki/PID_contro...ral_windup fairly understable, but you might not.

A quick explaination is that you have two variables: a control variable and a measured variable. The control variable is the one that you can control and the measured variable is the one you want to control. For example, pitch can be considered a control variable, in order to change the measured variable altitude. You increase pitch to increase altitude and decrease pitch to decrease altitude, etc. etc.

The core of a PID controller is this equation:

Output = Kp * e(t) + Ki * e(T) + Kd * e'(t)

It's a bit mathy, but breaks down fairly easily: Kp, Ki, and Kd are the tuning values and therefore constant.

e(t) is the "error at time t", i.e. now. It's the difference between the measured valued and the target (or setpoint) value.

e(T) is the "integral error", which is just a fancy way of saying it's the accumulated error over time. The most basic implementation for this is to just add the error to an accumulator each time.

e'(t) is the derivate of the error, in this case, just the rate of change. Normally you can just use the difference between the previous error and the current error.

The way it works is that "Kp * e(t)" is the "proportional" term, so you alter your control variable based on how far you are from your target, this can result in oscillation around the target value and/or a failure to settle at the target value at all.

"Ki * e(T)" is the "integral" term, which improves the rate at which the target value is approached and prevents the value from being persistently under or over the target. It's clear how this works if you consider the fact that e(T) accumulates past error. Lets say you have a system that persistently stays under the target value, with an error of 1, after the first tick, the accumulated error is 1, the next tick it's 2, then 3, 4, 5, etc. As the accumulated error increases so does the control value. However, the integral term can increase overshoot and settling time.

"Kd * e'(t)" is the "derivative" term, which accounts for the rate at which the error is changing in order to compensate. This helps avoid overshoot and decreases settling time, at the expense of increasing the time it takes to reach the target value (though not normally by much). This is essentially like braking to a stop in a car. You don't wait until you're at the place you want to stop then slam the brakes on, you start braking ahead of time.

Hopefully that should get you started. They're actually quite easy to implement, at least in a basic form, playing with the values and seeing the effects can be pretty enlightening.
Reply

#15
https://www.youtube.com/watch?v=UR0hOmjaHp0

That guy helped me learn PID for some KSP PID autopilot mod.
Avatar credits go to DieMango
Reply

#16
So, a few questions for the experts that came to me after doing some research on PID controllers:

The current controllers the AI is using are either on or off. We can't tune their output as we can for thrusters, because control surfaces (tailplanes, ailerons) are binary. Can we still use a PID controller in this case?

It also strikes me that there are a lot of parameters that need to be tuned for each aircraft for a PID controller. This seems unreasonable to ask of everyone who downloads this AI. How can I ease this burden on players? Can these parameters be derived from ship stats somehow, or (quickly) learned via observation each time the AI starts up? Or perhaps there are some simpler parameters that the user can specify, like aircraft mass, that can be used to derive them?
Reply

#17
does this AI check other flying crafts to avoid collision?
Reply

#18
Only the target craft. If/when Nick adds the ability to know the locations of allied vehicles, I may do universal collision avoidance.
Reply

#19
Been testing the AI and going through the code. Works really well. Using it for an attack helicopter for more stable flight and attack run adjustments. Will leave a reference and link to this post in blueprint post.
The darkest heresy burns the brightest.
Reply

#20
(2015-08-18, 08:32 AM)Madwand Wrote: The current controllers the AI is using are either on or off. We can't tune their output as we can for thrusters, because control surfaces (tailplanes, ailerons) are binary. Can we still use a PID controller in this case?

You can translate a fractional value into an on-off-sequence (of differing on and off proportions). PWM, for example.

Quote:It also strikes me that there are a lot of parameters that need to be tuned for each aircraft for a PID controller. This seems unreasonable to ask of everyone who downloads this AI. How can I ease this burden on players? Can these parameters be derived from ship stats somehow, or (quickly) learned via observation each time the AI starts up? Or perhaps there are some simpler parameters that the user can specify, like aircraft mass, that can be used to derive them?

Well, you could implement some sort of auto-tuning. There are quite a number of software packages that offer that, though usually at a $$$$ rate. There are also a number of "rules of thumb" that may be sort-of OK. (Luckily you have an exact model of "the vessel in FTD" by running it there, and you don't risk anything if you crash and burn in the vehicle designer, so that is one plus most people don't have.)

Additionally, what are you going to do when parts of a player's vessel get shot off or exploded? Will the tuning hold? Or do you need adaptive control as a PID tuner? Or do you not need a PID tuner, but something more complex --- maybe something that checks each relevant block and adapts (as well as possible) to them going away and coming back? Basically simulating the vessel moving in FTD inside the Lua code inside the vessel inside FTD?

I'd go for a general "sort of works" tuning, whoever wants more can be told the tuning methods not under patent protection.

[Edit: And tune for which conditions and environments?
Do you want to be quickest on or near the new altitude/course/... no matter if you overshoot some? (That may bite you if you want to pass "just above" land or other vessels.)
Do you never ever want to overshoot? That means you take longer till you are close to your new setting.
Do you want to have the lowest error, the lowest square of error, or something else?
Do you want your weapons to bear at the earliest moment? That means any position where the weapons do not bear is equally bad --- and any where they do equally good --- it does not help you if you are not able to fire for 2 more seconds, no matter if the error is less by some 'square of error' calculation!
Do you want to have the weapons in range and the angle of change between you and your target low enough that lasers or guns can track good enough to keep hitting somewhere there at the earliest moment? Or maybe you prefer to minimise that angle of change to your target so you are as steady as possible so you can snipe ---- even if that means taking your time?

Without deciding what to optimise for anything but a coarse tuning will not help.

This is the same when you build a vessel and want to keep resource or RP usage low. Are you going against weakly armored, medium fast ships with mostly nasty lasers and some anti-missile lasers? Are you going against a swarm of small submarines? Are you going against an orbital platform launching 20+ missiles at once --- aiming at you straight from above? Or are you going to make an overpriced Jack of all Trades, sunken at once?]
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)