The problem:

Up until now, most if not all auto-aim systems on the site have been designed for projectiles with constant velocity (like guns). None could properly calculate the intercept point for a ballistic trajectory (like cannons), you would always find they lagged the target or were offset from where they should’ve been aiming. The main barrier at the time was solving the quartic equation, which doing so through conventional means is very, very cumbersome.

The solution:

Thanks to some much smarter people than me on StackExchange and StackOverflow (see here and here), I’ve been able to take their work and transpose it into FT. Using the outlined vector equations and the approximate quartic solver (which i’m still not exactly sure why it works), I’ve been able to create an auto-aim that works for cannons.

See example below, a (small) 40mm projectile landing squarely on a tanker plane flying at a bank of 4° from a distance of +15miles:

That’s right, as a consequence of being able to solve the quartic, we can now also predict the target trajectory based in its acceleration as well (which was not previously possible). This means if a craft is experiencing some degree of constant acceleration (up, down, left, right, whatever), the auto-aim can compensate and predict the displacement due to the acceleration of the target. However, we now run into some limitations which were previously not envisioned.

The limitations (as of right now):

The biggest limitation concerning this method of calculating the flight time is the noisiness of the input data, specifically the noise associated with the target velocity and acceleration due to the use of the rate function. This is further exacerbated by the fact that we have 3 vector components, which mean three additional sources of noise, and that the acceleration is based directly off of the derivative of the velocity, which is already somewhat noisy.

This initially limited the applications of the auto-aim, but through some simply data processing/filtering (specifically using an Exponential Moving Average (EMA)), it was possible to tune the bias such that the noise was reduced but also the input lag was minimal.

An EMA simple takes the previous values and applies a weight onto them (corresponding to the graph below) and then takes the average of all the values. The decay is determined by the bias, which I discuss a bit more below.

This data filtering however may reduce the auto-aims ability to track very fast moving targets (especially at close ranges where the rate of change in the turret angle is high), however the nice thing about the filter is that we should be able to dynamically adjust the bias to match the best conditions for the target it is tracking. (Example: Use a slower but more stable filter value for longer distances and a faster but noisier filter value for shorter distances, etc.). I plan to upload full documentation when I release/finish tweaking the project.