More Math Woes

[Mr.Peanut]

Haha,
I wish I had read your post before I went ahead with second test for MK19 G_40mm_HE!
Four shots at four different altitudes:
K = (4.98 +/- 0.08)*10^-4
g = 9.81 +/- 0.02
First velocity measured = 238.71 +/- 0.28

Not bad, eh?  Now if you could dig through the weapon configs and get the muzzle velocities we would be set. I can also improve my function to take terrain slope into account.

edit:

If the value of 'a' is the total acceleration of the round with air friction, would that be equal to the muzzle velocity (v) that we plug into our old friend, the algorithm for angle of launch ((asin (gd / v^2)) * 0.5)? That would be excellent if it were. I'd highly prefer allowing ArmA's physics engine to handle the flight of the artillery shell over any other "creative" solution.

Um, why not use the code I provided? What you want to do is add and action to the cannon that calls a script. The script exits if it is not the gunner. The script calls my code. You can then display the range of the shot, and the height difference.

If you want to solve for what elevation to hit a given target, forget about it. I mean, it can be done, but it is non-trivial, at least to people without 2 years of undergraduate math or physics. There is also the problem that if your artillery has a large range of elevation and your target is in a certain range there are two solutions, a high angle and a low angle. A numerical solution is guaranteed, but not for the angle you may want. You would want the low angle for flat terrain becuase it hits the target sooner. You would want the high angle if there was terrain in the way.

Here is how it could be done. I don't think the ArmA engine could handle it without a few hiccups.
1) Use parabola to estimate the elevation required to hit the target. It there are two viable elevations keep them both.
2) For each parabola estiamte: plug the elevation into my code and get the impact point. Calculate whether shot went too far or too close. Adjust elevation. Try again. Repeat until within a given tolerance of target.
This is literally called "the shooting method" http://www.physics.louisville.edu/help/nr/bookfpdf/f17-1.pdf and uses an algorithm to decide what the next guesses for elevation should be.

A better solution is to fit a polynomial to the trajectory based on the elevation.

[drbobcat]

Oddly, the entry for the muzzle velocity is listed not in cfgWeapons or cfgAmmo, but rather cfgMagazines. 

Code: [Select]

_muzzleVelocity = (getNumber (configFile >> "cfgMagazines" >> "30Rnd_105mmHE_M119" >> "initSpeed"));
This happens to be 1100 m/s (or 3960 km/h: the same number I had mentioned briefly a page or so ago).

If you want to solve for what elevation to hit a given target, forget about it. I mean, it can be done, but it is non-trivial, at least to people without 2 years of undergraduate math or physics. There is also the problem that if your artillery has a large range of elevation and your target is in a certain range there are two solutions, a high angle and a low angle. A numerical solution is guaranteed, but not for the angle you may want. You would want the low angle for flat terrain becuase it hits the target sooner. You sould want the high angle if there was terrain in the way.

Ugh. I was so optimistic with our more recent discoveries and the possiblity that we'd be able to use them within the classic formulas. We will not be able to predict the angle of launch prior to firing or calculate the distance the round will travel? If that is true, the current system I have in place will suffice, I guess... *reluctance*

- dRb

[Mr.Peanut]

For a given weapon and muzzle, you can almost exactly fit a 3rd order polynomial to the trajectory with coefficients that appear linear with muzzle elevation. At least this is true for the Mk19 G_40mm_HE combination. Assuming shot is fired straight north from (0,0,0) with elevation _e:

Code: [Select]

_c3 = (-3.02 * _e - 29.30)*10^-9;
_c2 = (3.71 * _e - 93.733)*10^-6;
_c1 = (1.59 * _e + 0.57)*10^-2;
_c0 = 0.2585 * _e + 14.0383;
_z = ((_c3 * _y +_c2) * _y  + _c1) * _y + _c0;
Using this formula will get you within 10m of the target.  _z is ASL. It does not make it any easier to solve _e for a given target, but it is a much faster way to get an estimate of the trajectory.

Ugh. I was so optimistic with our more recent discoveries and the possiblity that we'd be able to use them within the classic formulas. We will not be able to predict the angle of launch prior to firing or calculate the distance the round will travel?

The equations involved are non-linear, which means they can not be solved analytically but numerically . In fact, people are still publishing solutions to these equations!  So you are out of luck solving for _e.

[h-]

Aww, mr.P you should know better not to post consecutively...

[Mr.Peanut]

What consecutive post? 

[DeanosBeano]

The guy from fdf released his ofp script with necessary calculations about 6 months ago , it works very well in arma too.
 One major problem is FPS , everything works fine in 1st person and all calculations are spot on, the problem is when you go into map screen or look at the sky and get a massive Fps increase , it seems to effect even the SQF version  I.e shell land a lot closer to ya and he is is sleeping his script at .001 intervals , i really hope your method works , i am desperate to blow the crap out of my buildings with some real nice arty.

[Mr.Peanut]

This is not likely to improve matters. Solution requires number crunching.

drbobcat, can you give me the config retrieval snippet for the air drag and ammo?

edit: Okay here is a proof of concept. Fire a shot. After the shell lands, a script calculates the theoretical trajectory and then the impact points are plotted on the map. Green square is you. Red hatches are where you zoom in on map. Zoomed in are a small red and blue circle of 20 and 10m radii. The red circle is where a bullet cam says the shell hit. The smaller blue dot is where the calculation says it landed.

[drbobcat]

Alright.

Code: [Select]

_airFriction = (getNumber (configFile >> "CfgAmmo" >> "SH_105_HE" >> "airFriction"));
I will now test and experiment with the script you provided, Mr.Peanut. However, it does not seem to lead us very far from the artillery script by Jones that Mandoble hinted at on the first page. I so badly wanted to be able to provide the player either an angle to fire at to reach a certain distance or just the distance his current round will reach. Guessing is quite inefficient. Creating a table is a tiresome chore that'd I rather avoid as a last resort. *grumble*

- dRb

[Mr.Peanut]

I found a bug in my script. Please re-download. I am working on the solution to the problem you describe, but I am now drunk and not making progress. Stay tuned. There is a solution, but it is hard to debug when drunk.

How can I get the muzzle velocity?
_muzzleVelocity = getNumber (configFile >> "cfgMagazines" >> "30Rnd_105mmHE_M119" >> "initSpeed");
A fired eventhandler returns M119 as muzzle. How can I derive the muzzle argument "30Rnd_105mmHE_M119"?

[drbobcat]

The fired event handler does not return the magazine currently in use. Therefore, we'll have to utlize a switch-do database setup that detects the type of weapon being fired and then plugging in a value for the corresponding magazine....

Code: [Select]

_wep = _this select 1;
_mag = "";

switch (_wep) do
{
     case "M119": {_mag = "30Rnd_105mmHE_M119"};
};

...

_muzzleVelocity = getNumber (configFile >> "cfgMagazines" >> _mag >> "initSpeed");
I just realized that we could easily derive the distance prior to firing by simulating the firing of one by using a gamelogic and raised numerical values. What I mean is that we could "fire" a game logic a certain distance based on the current angle of the barrel and the velocity the shell would take were it to be shot. After the logic has completed its journey, we can measure the distance between the gun and the logic. That would roughly yield the same distance the actual round would take once it was fired. Is that reasonable? By raising the numerical values, I am implying that we could raise many of the numbers within the formula by a fixed power so that the calculation does not take 20+ seconds to do.

- dRb

EDIT: A better, more dynamic solution to derive the magazine value would be to use the array equivalent of the getNumber command...

Code: [Select]

_mag = ((getArray (configFile >> "CfgWeapons" >> _wep >> "magazines")) select 0);
_muzzleVelocity = getNumber (configFile >> "cfgMagazines" >> _mag >> "initSpeed");

[Mr.Peanut]

drbob,

I guess the gamelogic idea would work though  I have no idea if a game logic has a drag coefficient.

I have cracked this nut(ow!), but my code is still in a very rough prototype stage. It works, but has no error handling and has not been optimised.  Because the code is demanding for the ArmA engine, it would best be run from a little dialog so that the player is sheltered from the stuttering( and perhaps to simulate using a battle computer). I don't do dialogs but my finished code will be flexible. I have a couple ideas to improve the numerical methods used (maybe 50% faster) and also tell the user if the shot is possible i.e. whether terrain blocks the shot. The solution time will then be about 10-20 seconds(I hope).

I will continue to make this mostly a function based solution, with a parameter for sleep time in the main loop.

I need a couple more things. One is the proper case "M119": {_mag = "30Rnd_105mmHE_M119"}; stuff for the mk19 g40 round, the other is how to get at the ammo lifetime values. I will use the lifeTime to calculate the ideal maximum range so that my code can make a graceful exit if the target is out of range. Presently that situation causes a nasty division by zero error.

[drbobcat]

To answer your first question, we'd determine the muzzle velocity of the G_40mm_HE round the same way. I still very much recommend you use the second method I provided, as it is the most efficient and can obtain the initSpeed no matter what weapon we're using.

Code: [Select]

_wep = _this select 1; // A "fired" eventHandler passes the weapon as its second argument

_mag = ((getArray (configFile >> "CfgWeapons" >> _wep >> "magazines")) select 0);
_muzzleVelocity = getNumber (configFile >> "cfgMagazines" >> _mag >> "initSpeed");
If you must know the magazine name for the Mk19, it is 48Rnd_40mm_MK19.

As for finding the lifetime of a round, that is a property in CfgAmmo. We can again use getNumber to ascertain what that value actually is...

Code: [Select]

_ammo = _this select 4; // Ammo is passed as the fifth argument by a "fired" eventhandler

_timeToLive = getNumber (configFile >> "cfgAmmo" >> _ammo >> "timeToLive");
Finally, I meant that we'd apply the velocity (including the drag coefficient of the round) of the round yet to be shot to a gameLogic after the player engages an action such as "Determine Range". We now know how to obtain the muzzle velocity of a round, its drag coefficient (k), and its timeToLive. If these were all put into a simulation using a gamelogic, I believe we'd then be safely able to know where the shell would land if it were fired. Your calculations are able to yield a parabolic curve with all the known ArmA variables taken into consideration, are they not? I've yet to encounter any other contributing phenomena in ArmA that'd we would have to wary of in reality, such as wind, changing air pressure, or any others. I am curious as to what you think would be the best method in finding the range?

- dRb

[Mr.Peanut]

My code solves for the range and the flight time. A game logic is not needed in the manner you suggest. One part of the solution is the same as in the demo I posted. It integrates the equations for a given initSpeed, drag and elevation to determine where the shell would land. The second part of the solution involves iterating to find the elevation to hit a given target.  It estimates the derivative of distance error by elevation and uses this to guess the next angle based on Newton-Raphson. All this I have done, but as I said, the code does not handle errors gracefully, and there are free parameters relevant to the numerical methods. Finding a good solution in as few iterations as possible depends on having good choices for these parameters. Bad choices either yield no solution or take 5 times as long to find a solution. Add to this the fact that some solutions are unphysical (i.e. elevation can not be greater than 90 degrees or less than ~-5 degrees) and make the solution unstable. This is not a difficult problem, but it is fussy and takes forever to test in-game. But I am very very close.

There are some special conditions:
1) Target is out of range(to close or too far). This leads to a division by zero error. Still to be coded.
2) Target is in range but shot is blocked by terrain. Solved.
3) There are two solutions for targets within a given range. A low elevation and a high elevation. Solved.
4) Getting ordnance data from config. Still to be coded

At the moment my code can determine accuracy within 1-2m, if desired. The ArmA engine slightly randomises the initial speed, so even with an exact solution, you are not always guaranteed a hit. I am pretty happy with the results but the code really is a mess so I am working to clean it a little before I post another demo for your perusal. Thanks for the config info, as using configs makes the script multipurpose. Most users need a script for which they do not have to look up config data.

I'll hopefully have a little time tonight to get up to a second demo. Until then...


edit: Oops! All you want is the range given an elevation? That part is easy! Do you want the "real" range i.e. takes terrain into account? This value can be misleading. Imagine the difference in range between a shell that hits a hilltop and a shell that just barely passes over! The problem is if you ignore terrain, then you have to arbitarily choose when to stop the shell. What I mean is you need to provide an above sea level height. One good choice would be either 0 ASL height, or the ASL of the artillery. The script that calculates range takes less than one second, during which it halts all other arma function, so it would not be good to call it constantly. In fact my traj.sqf script from my first demo already returns the target position, the flight time and  the range,  and takes terrain into account. The return = [_lastPos, _elapsed, _d]. _elasped is the flight time, _d is the range. If that is all you want then your problem is already solved.

Of course, I can still solve for elevation given a target

[drbobcat]

ArmA already has a command that returns the distance of one thing to another. Therefore, just comparing that against the current range based on launch angle is more than enough. You do not need to concern yourself with determining an accurate angle of launch if the former can just as easily be ascertained. They both achieve the desired result.

Additionally, you must also remember that the splash radius of an artillery shell in ArmA is at least 25 meters. If you can already achieve an accuracy of 1-2 meters, we're more than golden. However, it would be nice if when calculating range, we could take terrain into account. This would allow the gunner to switch to a higher angle in order to strike the same target. That would likely take much, much more time to do, though. As for height differences, perhaps an adjusted distance-to-target could be given so that the gunner can aim closer/further based on the height of the target in relation to the howitzer piece. What I mean is that the more extreme the difference in height, the more extreme the deviation of the round. It would most certainly behave like a triangle, if that makes any sense...

Sorry to be so short with you, Mr.Peanut. Today is just going to be a busy day for me. You've been doing a great job thus far and I am thoroughly impressed. There is no doubt that you will receive a great deal of credit once this resource if complete. Thank you.

- dRb

[Mandoble]

Just considering the specifications in the initial post you may consider the following very basic rules:
- For any elevation and initial muzzle vel you now the time required by the shell to reach 0m/s in the vertical plane just applying gravity + a constant decceleration due drag (which result in a constant negative acceleration).
- Now you have the predicted height of the projectile at 0 m/s which will start its "descension".
- It will need to descend the vertical distance between its predicted maximum height and the height of the target, both ASL.
- With this you know the time required by the shell to travel vertically that distance applying also the gravity - the constant drag for acceleration (with result in a constant positive acceleration).

With these basic calculations, before firing a shell, you already know its flight-time.
Now apply that flight time to a simplifyed horizontal speed calculation where only a constant drag affects the initial horizontal speed of the round. And that will give you the exact range of the round fired at that angle.

Now, to be able to simulate several shell types (with different muzzle vels and drag), you'll need to guide the shell in-flight applying the basic constant acceleration movement formulas for its velocity vector until impact. With this you have a "shell" trajectory simulator, where a script is applying speed, gravity effect and drag to the flying object.

This way you are no providing the elevation required to reach a particular range with the selected shell type, but you are providing the range for each angle of the gun and type of shell used. The gunner would only need to change gun elevation until the desired range is matched with the calculated one (you may show both using a hint or a titleRsc).