Post Reply 
 
Thread Rating:
  • 3 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Solved the projectile aiming calcs with drag
2017-02-25, 02:51 AM (This post was last modified: 2017-02-25 02:52 AM by moonruner.)
Post: #71
RE: Solved the projectile aiming calcs with drag
target prediction:
I tried 1st, 2nd, and 3rd order prediction and cheap Fourier transform on lua. However 2nd order was the best.
Always the targeted craft is possible to change movement after the gunner fired. Any assumption does nothing. Ultimately, gunner have to know random generator in targeted craft.

Imagine a game. I write 10 numbers. Open the first 5. You estimate the 10th number. I open the last 5.
Do you have any chance to win? the 10 number maybe
639, 438, 310, 621, 317, (Hey! predict this!) 421, 861, 489, 756, 955. Did you hit?
If movement of target was restricted you have chance to hit. The above numbers were 1 to 1000 so you had 0.1% chance.
Most reasonable restriction is acceleration. If those numbers must incremented -1 ~ +1 from previous number, you have 10% of chance.
Find all posts by this user
Quote this message in a reply
2017-02-25, 03:05 AM
Post: #72
RE: Solved the projectile aiming calcs with drag
(2017-02-25 01:11 AM)Narushima Wrote:  
(2017-02-25 12:21 AM)HerpeDerp Wrote:  
(2017-02-25 12:04 AM)Narushima Wrote:  Why make the calculations in real time? Wouldn't it be better to do the calculations when the gun is created then put the values in a table. Think how a real gunner would aim. They'd have a set aiming point then they'd adjust for drag.

So for each gun you'd have a table of corrections (at distance x adjust elevation and lead by y and z).

You also have movement of the gun and movement of the target giving you a whopping 8, possibly 9 variables (you can't just use the difference in velocity of the two because of the drag). If you want, say, 10 values for each variable in your table (which isn't all that much really) you'd end up with a billion (10^8) entries in your table, each consisting most likely of 2 floats meaning 1.6GB of data which is way too big to be usable

You don't need to put all that data in a table. All you need is bullet drop and speed at given distance, and you can calculate the rest in real time. The point I'm making is you don't have to actually calculate the drag, you can just use values for every X meters. Ideally you'd want x to be logarithmic, so for example the table would look something like this

DISTANCE SPEED DROP
200m 500 1
150m 490 1.2
190m 482 1.45
215m 465 1.88

Once you acquire the target you aim at it, look at the table and adjust, then calculate the extra adjustments (averaged speed, vector, etc...) and then fire.

To give more detail to why this is limited, remember that the effect of drag depends on launch velocity (if you launch a projectile in the same direction as your movement, it will slow down faster in your reference frame than if you had launched it at rest). Similarly, firing toward a different elevation throws off calculations (at an extreme, firing straight down, the speed change is positive and the drop is zero!). Gunnery tables work quite well when these extra variables are nearly constant (vehicle speed is much smaller than projectile speed, and the target is at the same altitude) or at extremely close ranges, but it is at best an optimization to choose a better starting point for an iterative algorithm in the more complicated situations FTD tends to.

Allr andask.
Find all posts by this user
Quote this message in a reply
2017-02-25, 04:10 AM
Post: #73
RE: Solved the projectile aiming calcs with drag
ahh I have to mention.
As far as I did RK4, when drag exists, accuracy of trajectory simulation falls down. it means you need more time steps and calculation time.
I hope just in time calc sides consider it.
Find all posts by this user
Quote this message in a reply
2017-02-25, 05:42 PM
Post: #74
RE: Solved the projectile aiming calcs with drag
People keep proposing Fourier transforms for predicting wobble, but such prediction can only really work in very limited circumstances and, even then, with difficulty. There are serious issues with using a DFT (more commonly known as a FFT) in this predictive setting.

Consider a 1-dimensional example. Here are my observed target locations:
[0,1,2,1,2,3,2,3,4]
If you caught on to the pattern I was thinking ("correct pattern" is an ill-defined statement), you would say [3,4,5,4,5,6...] is next. But we're using DFT "extrapolation." It cheerfully reports that the next numbers should actually be:
[0,1,2,1,2,3,2,3,4,0,1,2,1,2,3,2,3,4...]

An intrinsic assumption in the DFT is periodicity over the interval. Extrapolation is actually just cyclically wrapping back to the beginning. Further, only LUA vessels might achieve any motion that is particularly periodic, and only if it is fairly agnostic to the target. The binary control of the AI decisons (even if filtered through a PID controller) creates wobble that is as much chaotic as periodic.

You can cook-up toy examples where Fourier prediction might work in FtD, but I have serious skepticism that a practically-useful targeting algorithm will come of it. You could try a quadratic+periodic (simultaneous) fit and enforce sparsity over the periodic components to get something arguably useful, but that would involve forming a linear system and solving a LASSO optimization at each timestep. At some point it becomes computationally and mentally not worth it.
Find all posts by this user
Quote this message in a reply
2017-03-01, 10:30 AM (This post was last modified: 2017-03-01 10:30 AM by Tyr3n.)
Post: #75
RE: Solved the projectile aiming calcs with drag
And because it is difficult to predict wobble and it eats too much time figuring the AI out, one usually sticks with the Mighty Jingles: "throw enough spaghetti against a wall, some might stick."

Thats the main reason you have Lotsa 'eavy cannonz on your ships.

Compensate accuracy with amount of fired shell, may RNGeesus be with you.

______________
Gladyon for Dev! Big Grin
(2017-06-19 03:02 PM)Guaibee Wrote:  Every once in a while I see a surge of replies on multiple threads from the same person...
spooling up reply surge...
Find all posts by this user
Quote this message in a reply
2017-03-01, 11:45 AM
Post: #76
RE: Solved the projectile aiming calcs with drag
(2017-03-01 10:30 AM)Tyr3n Wrote:  And because it is difficult to predict wobble and it eats too much time figuring the AI out, one usually sticks with the Mighty Jingles: "throw enough spaghetti against a wall, some might stick."

Thats the main reason you have Lotsa 'eavy cannonz on your ships.

Compensate accuracy with amount of fired shell, may RNGeesus be with you.

The problem with that is that against circling thrustercraft, 100% of my shells end up behind the target.
I could fire more, that but would change nothing (I already fire a few thousands shells per minute...) because none of my shells have the capability to end up on the target as long as it's turning.
Against that type of targets, only fast shells have chance to hit, and I don't really like fast shells as they are stopped by shields.

We need a better prediction system.
Not a perfect one, but at least one that feels good. I think that taking into account position and speed, including rotation speed, should be enough to have a good feeling of the system.
Find all posts by this user
Quote this message in a reply
2017-03-01, 12:41 PM
Post: #77
RE: Solved the projectile aiming calcs with drag
Nah, the problem is that your weapons are just too accurate. With a good amount of spread you will hit...I do not mean the accuracy per gun, just per volley. All your guns converge at exactly one point, which is kind of stupid. A ship usually has different FCS for front and back turrets and they are literally unable to hit the exact same spot. But they are in FTD.

______________
Gladyon for Dev! Big Grin
(2017-06-19 03:02 PM)Guaibee Wrote:  Every once in a while I see a surge of replies on multiple threads from the same person...
spooling up reply surge...
Find all posts by this user
Quote this message in a reply
2017-03-01, 12:59 PM
Post: #78
RE: Solved the projectile aiming calcs with drag
(2017-03-01 12:41 PM)Tyr3n Wrote:  Nah, the problem is that your weapons are just too accurate. With a good amount of spread you will hit...I do not mean the accuracy per gun, just per volley. All your guns converge at exactly one point, which is kind of stupid. A ship usually has different FCS for front and back turrets and they are literally unable to hit the exact same spot. But they are in FTD.

That might be that, I have the habit of placing the firing piece at the back of the turret head so that a large portion of the barrels are within the turret head, and that part of the barrel usually is enough for the ammo controller values.
That means that with the part that extend out of the turret head I usually have a very good precision.

But that seems a little bit silly to be forced to have imprecise guns in order to actually hit a target... but if that's FtD's way, why not?
Find all posts by this user
Quote this message in a reply
2017-03-01, 01:51 PM
Post: #79
RE: Solved the projectile aiming calcs with drag
That actually happens in real life--some RN reports mention that the German battlecruisers were excessively accurate shooting at shadowing light cruisers; due to the latter chasing the fall of shot the Germans never had quite the right range, and the remarkable precision of their fire resulted in those errors leading to zero hits--they would have been better off detuning a bit. I recall mention of that in the Pacific war, too, with USN ships trying to avoid excessively tight volleys and noting that the Japanese were losing hits from excessive precision.

Allr andask.
Find all posts by this user
Quote this message in a reply
2017-03-01, 02:09 PM
Post: #80
RE: Solved the projectile aiming calcs with drag
I understand the principles, but what we have here is quite different.
It's just that the computer cannot interpolate the trajectory of a vehicle that turns at a constant rate.
It can only interpolate the trajectory of a vehicle that translate at a constant rate.

Most humans are able to precisely interpolate trajectories when the translation and the turning rate are constant.
In some sports such as tennis or baseball you have to interpolate the trajectories considering the acceleration, and a large proportion of humans are quite able to do that with some success.

I think that a targeting computer should at least do what the humans do very well (in fact, as it is only calculations, it could interpolate several degrees more, but I think that for FtD we only need something that feels good for most humans).
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)