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

  • 3 Vote(s) - 4.67 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Cinematic aircraft AI. 2.0: dogfights galore

I was thinking, just as LoSboccacc pointed out, or more accurately because LoSboccacc pointed it out, that rating a PID based on its ability to achieve an impossible reference point isn't a good idea.

Instead, I was thinking on rating it by overshoots and small errors and doing the right thing (ie saturate the output).

If the pid is saturated and doesn't overshoot => 0 points - It's the correct output, the weak actuator is not the fault of the pid
If the pid is not saturated and doesn't overshoot => 1 point for degree of difference - The pid is at fault for not actuating enough
If the pid overshoots => 1 points for degree of difference + 1 point for angular velocity - The pid is at fault for actuating too much

what about something that's linear?

if deviation is high we want angular momentum to be high and in the direction that reduces the error (so we don't punish on the error)

if deviation is low we want low angular momentum because that's what causing oscillations (and since we cannot stop momentum on a whim we need to have it proportional to deviation)*c...n+-1+and+1

where c is deviation, a is momentum, and they are signed in the direction (you can see if deviation is positive and momentum is negative, error is 0 and all is fine, if they have the same sign pid is controlling the plane away)

I think I might be able to implement this without changing anything in the base classes which is fine.

lol haven't done control stuff in ages, can't remember a thing. at least this error function is derivable, so if everything fail I?ll implement backpropagation

Nice surface, the ridge at the bottom might be an issue though.

We kinda want a surface like c*c + |2*a*c| +a*a between -1 and 1 though.

Edit: And my grammar defo is an issue.

Edit2: I'm not sure about this, the actually seems like a good idea on second though.

the ridge is because it's where the angular momentum is in the direction needed for the angle to match the wanted direction

to avoid it it's best to add a third term to punish non saturating the controls when angle is far from the wanted direction

something like
yawError*yawError + 2*yawError*yawMomentum +yawMomentum*yawMomentum + math.abs(previousOutput*previousOutput*math.abs(yawError) - yawError*yawError)

( )

edit: simplified saturation error term - if control is low and error is large is unhappy, if error is low it doesn't care about control, and if error is high and control is high is equally happy - it's important that we don't punish the pid for having an integral term which may be needed to keep the craft nose up

0.95 released, has the optimizer enabled with that scoring system, but values are all over the place. how do you get the optimizer to try smaller changes to pid values?
gets high on math

It's awkward but I have not gotten around to do anything about it yet, add a hint for every axis you want to explore.

(I'm re-using W for how large you want the initial step to be)


My optimizer needs a way to reject obviously bad solutions.

I found an error in the optimizer where it keeps the worst solutions instead of the best. Will update later this week with fixed version.

ok thank you for looking into it! I really hope it will solve the wobblyness Big Grin

I'll just work on adding more situational maneuvers, found a handbook of attacking and defensive maneuvers that seems perfect for what I had in mind.
gets high on math

Updated simplex.

However I have noticed some issues with it where it works really poorly if the initial pid is saturated. As far as scoring is concerned a saturated pid looks exactly the same as a slightly less saturated pid.

so I can just get it off the other post?
gets high on math

Forum Jump:

Users browsing this thread:
1 Guest(s)