Artillery projectiles simulation

[DeadlyShadow]

Hi guys
I've been googling for awhile but sadly i can't find the answer i need (idk maybe because my googling skills suck :D)

I am Software developer and I'm trying to build 3D artillary simulator

I need some help on this one if u don't mind (I hope this is the right forum to post this)

here is the problem:

I have a moving target (3D world) i know its speed and its current position
there is an Artillary which i also know its speed and position . it fires projectiles to the air( iknow each projectile's mass and initial speed ).


i need to know at which position and at which angle i need to aim to hit the moving target

theoretically i can reduce this problem into a 2D world which will make it easier
but since i need to take "Gravity" "Drag' and "wind" forces into account this will get alittle bit messier

i really appreciate any help
thanks in advance :D

 

[BradP]

I think you will have a lot of differential equations. If you are looking for a place to start, consider F=ma in one direction. Disregard gravity for now. Let x' and x'' be the first and second derivatives of a particle moving in the positive x direction with respect to time.

The net force will be the drag force, which depends on velocity, x'. But you want the velocity of the projectile in relation to the air. So it is something like Fdrag = C(x' + wind). The equation ma=F would become mx'' = C(x' + wind). Then you need to solve that equation to find the function, x(t).

You can next set up an equation for the vertical component. Weight + Drag Force = ma. Weight is mg. Drag force is C(y' + wind). Equation ma=F becomes my'' = mg + C(y' + wind). Solve that for y(t).

//C is the coefficient of drag.

Then you have two equations, x(t) and y(t) for the coordinates of the particle at any point in time. You should be able to somehow equate x(t) and y(t) for the projectile to x(t) and y(t) for the target. There is definitely something else to finding the initial orientation and speed, but I need to take a break from thinking about this.

 

[DeadlyShadow]

"Differential Equations" . What the hell have i gotten my self into :D
thanks Bradp for your help.
I am going to let go of the "Drag" force for starter .
I found this
http://babek.info/libertybasicfiles/lbnews/nl130/proj3d.htm
and this
http://tutor4physics.com/projectilemotion.htm
idk.
they seem to be very helpful to refresh my high school rusty informations :Dhere is what i understand so far (please correct me if I'm wrong)

i have here three main forces( Gravity, Wind and Drag) apperantly Drag is a real pain in the *** so I'm going to drop it now

without Gravity my projectile will keep going forward . so gravity force will just pull the projectile down giving the projectile's path the shape of an arch

wind can be defined by 2 factors ( angle and speed) ,right?

so if i want to study the projectile considering only Gravity and wind i only need to take the sum of gravity force + wind force ,right?sorry if i made a physical mistake here .as i said i am a programmer and i haven't been in touch with physics in awhile :)

thanks for your help again

 

[K^2]

If you simulate drag (you have to include drag if you want to simulate wind properly), there is no simple way to predict in advance where the projectile will land. Real artillery operators use complicated pre-evaluated tables.

For a game, you have two main options.

Option 1: Do what virtually all artillery games do (2D and 3D), forget about real drag, and simulate "wind" as added horizontal acceleration, no different from gravity. In that case, your trajectory is always a parabola, albeit, tilted. You can compute necessary angle based on initial velocity by solving a quadratic equation.

Option 2: Actually simulate the projectile. Now, you cannot predict in advance where the shell will hit. However, using the fact that you can simulate projectiles a lot faster than they will fly in real time, you can run a number of trial simulations to see how different angles affect the point where you are going to hit. This essentially a simple case of non-linear minimization (you are minimizing the distance between where you hit and target's position).

Let me know which option you'd like to try, and I can run you through all necessary steps.

 

[airborne18]

If you simulate drag (you have to include drag if you want to simulate wind properly), there is no simple way to predict in advance where the projectile will land. Real artillery operators use complicated pre-evaluated tables.

For a game, you have two main options.

Option 1: Do what virtually all artillery games do (2D and 3D), forget about real drag, and simulate "wind" as added horizontal acceleration, no different from gravity. In that case, your trajectory is always a parabola, albeit, tilted. You can compute necessary angle based on initial velocity by solving a quadratic equation.

Option 2: Actually simulate the projectile. Now, you cannot predict in advance where the shell will hit. However, using the fact that you can simulate projectiles a lot faster than they will fly in real time, you can run a number of trial simulations to see how different angles affect the point where you are going to hit. This essentially a simple case of non-linear minimization (you are minimizing the distance between where you hit and target's position).

Let me know which option you'd like to try, and I can run you through all necessary steps.

I was in the Artillery in the Army, and I operated the Fire Direction computer. But I had to learn the manual way with those tables you speak of.

K^2 you have this stuff down.

Distance to target is a big factor in all of this, and the type of fire system involved. The large howitzers can be used for direct fire at close range, but that is really a measure of last defense when they are being overrun by the enemy.

Cannon's are employed in a direct fire, but they don't have the power of the big guns. And wind and drift are less of an issue.

And there are fire systems that can account for moving targets and guns with both cannon and howitzers ( the navy does this with the big 16 inch guns on battle ships, where they have to account for the gun rising and falling ).

You are correct about not being able to predict the impact zone, and the military does trial rounds and the person on the ground calls in corrections.

Also a factor is the type of ordinance. Honestly 50 meters is close enough and considered a direct hit for the large guns. Again it is a function of the target type and ordinance.

Once the corrections are made, they send more than one projectile down range. They send a barrage in most cases.

 

[DeadlyShadow]

If you simulate drag (you have to include drag if you want to simulate wind properly), there is no simple way to predict in advance where the projectile will land. Real artillery operators use complicated pre-evaluated tables.

For a game, you have two main options.

Option 1: Do what virtually all artillery games do (2D and 3D), forget about real drag, and simulate "wind" as added horizontal acceleration, no different from gravity. In that case, your trajectory is always a parabola, albeit, tilted. You can compute necessary angle based on initial velocity by solving a quadratic equation.

Option 2: Actually simulate the projectile. Now, you cannot predict in advance where the shell will hit. However, using the fact that you can simulate projectiles a lot faster than they will fly in real time, you can run a number of trial simulations to see how different angles affect the point where you are going to hit. This essentially a simple case of non-linear minimization (you are minimizing the distance between where you hit and target's position).

Let me know which option you'd like to try, and I can run you through all necessary steps.

thanks man
mmm...
i guess option 2 is more suitable for what I'm trying to achieve since i want my simulation to be a little bit real
Thanks for your help.
i really appreciate it
thanks again :D

 

[DeadlyShadow]

Also a factor is the type of ordinance. Honestly 50 meters is close enough and considered a direct hit for the large guns. Again it is a function of the target type and ordinance.

WOW 50 meters is considered as a direct hit.
interesting

 

[K^2]

i guess option 2 is more suitable for what I'm trying to achieve

Alright. Then the first thing you should do is write a sub-routine that actually computes where the shell is going to hit. The way you are going to do that is by evaluating the trajectory over small time intervals. You will define a constant timeStep to set how often you are going to re-evaluate the forces. I'll tell you in a moment how to find a good value for it.

Trajectory is going to depend on the following: Initial velocity, computed using muzzle velocity, direction angles, and velocity of the platform. Wind velocity, which will probably be a global parameter. Effective drag coefficient that you will estimate.

Your function will consist of the main loop that will repeat until you actually hit something, at which point you'll return coordinates where the hit took place. If there is a possibility for projectile to leave the map, you should account for it. You might also want to return the total amount of time that elapsed, if you want explosions to happen after proper delay.

For each iteration, you should perform following adjustments:

a = g - k*(v-w)^3/(m*|v-w|)
v = v + a * timeStep
x = x + v * timeStep

Here:
a - acceleration for this step
v - current velocity
x - current position
w - wind velocity
k - effective drag coefficient
g - free fall acceleration
m - mass of the shell

Keep in mind that x,v,w,a, and g are vectors, so you'll have to evaluate all 3 components separately. g only has non-zero component in z direction.

|v-w| is the norm of the vector difference. This is done because drag depends on (v-w)^2, and direction is set by (v-w)/|v-w|, which is unit vector in direction of (v-w). You compute the norm as usual: |b| = sqrt(b_x^2 + b_y^2 + b_z^2)

Before you enter the loop, x should be initialized to (x,y,z) of your cannon, and v should be initialized to the initial velocity vector you computed for the projectile. Both of these should probably be simply passed to the sub-routine.

A bit of explanation for values of k. This value comes from simplifying drag formula to one parameter. The full version is this.

[tex]F_D = \frac{1}{2}\rho A C_D v^2[/tex]

And we simplify the computations by defining

[tex]k = \frac{1}{2}\rho A C_D[/tex]

Here A is cross-section area of your shell. Pi*diameter^2/4 will be a good enough estimate, even though it's not entirely true for duration of flight. Rho is density of the air. I'd set it as a constant. Technically it depends on air pressure and temperature, so feel free to look up the complete formula. Value of rho = 1.2 kg/m^3 should work for you, though. (Make sure your units are consistent, by the way. If you are going to use feet, make sure to convert everything.)

The most complicated is value for C_D. That will depend on a whole lot of things, but you are not going to be able to get a super-precise result anyways. It will have to remain a parameter specific to the shell you are firing. Good values will be somewhere in the 0.1 to 0.3 range. Lower values will be affected less by wind and will go further.

Now that you have the subroutine set up and tested, you should figure out what value of timeStep to use. Here is how you do that. Set up a whole bunch of shots with identical initial conditions but use different timeStep for each. Keep decreasing it until the difference between consecutive shots becomes small enough to be considered identical. (A few meters from each other, perhaps.) Keep in mind, however, that smaller timeStep will increase the number of computations, so a value too small will slow down your program, and might cause lag.
Finally, aiming. This is a bit tricky. You need to have the trajectory subroutine working properly and timeStep firmly decided on. You will start with initial guess. There is no reason to be particularly tricky here. Set horizontal aim to point directly at target, set vertical aim to the following estimate:

[tex]\theta = \frac{1}{2}arcsin\left(\frac{R g}{V^2}\right)[/tex]

Here R is distance to target, g is acceleration due to gravity (just a number here, not a vector) and V is the initial velocity of the projectile. If nothing was moving and there was no air resistance, this would give you a perfect hit. Note that if the part you're taking arcsin of is > 1, then there is no solution. That is, target is out of range, and you shouldn't bother aiming at it.

Obviously, because things move, there are hills, drag, and wind, this solution will be wrong. But it's a fair first guess. Compute where the projectile would really land with these angles, and compute where you target expect to be at that time. Take the difference. Now you compute correction for your guess.

Suppose projectile landed at (p_x,p_y) and the coordinates you used for your guess are (t_x,t_y). Choose the following point: (2*t_x-p_x,2*t_y-p_y). Repeat the initial guess computations but for THIS point now. Then compute new impact point, and so on. With each iteration, your guess should land closer and closer to the target. You should repeat this until you either hit the target, OR you can no longer makes guess for an angle (arcsin(>1)), OR you've made too many guesses. Reason for this cutoff is that there might be an obstacle on the way, or wind/drag could be limiting range, or some other reason for why you can't hit the target now. If you don't stop it, it will keep making guesses forever. A good number to cut off would depend on how precisely you need hits, but I would be surprised if you'd need more than 10-20 consecutive guesses. Try starting with that, if it's not working well, increase it to a 100 or so.
And just in case, here is how you compute the horizontal part of the angle, given coordinates of the target at (t_x,t_y) (Note that I'm ignoring Z entirely. Aiming algorithm should converge regardless.) This coordinate is taken relative to platform you are firing from, so you get it from world coordinates after subtracting off x and y coordinates of your cannon.

Define:

s = t_x/sqrt(t_x^2 + t_y^2)
c = t_y/sqrt(t_x^2 + t_y^2)

If s>0: angle = arccos(c);
If s<0: angle = -arccos(c);

Notice that angle=0 corresponds to aim along x-axis and will vary from -pi to pi (-180° to 180°)I think that's everything you need. This should really be taken one thing at a time, because all together it may be a bit confusing. Let me know if anything isn't clear, or if you'll have problems with the code.

 

[DeadlyShadow]

OMG!
thanks man
do u take credit or cash (^_^)
I'll start coding . and if something happens i'll let u know
thanks again
great help!
thx

 

[rcgldr]

For each iteration, you should perform following adjustments:
a = g - k*(v-w)^3/(m*|v-w|)
v = v + a * timeStep
x = x + v * timeStep

You can improve the accuracy of this by using trapezoidal method:

// initial condition

x = ...
v = ...

// initialize a

a = g - k*(v-w)^3/(m*|v-w|)

// iteration for numerical integration step:

aold = a
vold = v
xold = x
a = g - k*(v-w)^3/(m*|v-w|)
v = vold + 1/2 * (aold + a) * timeStep
x = xold + 1/2* (vold + v) * timeStep

// a is one time step behind v and x with this iteration
// if you want to know the final acceleration it needs to be calculated based on the final v and x

a = g - k*(v-w)^3/(m*|v-w|)

 

[K^2]

Yes, that would improve convergence and allow you to use larger timeStep to get the same result, or get better result with same timeStep. Good idea.

P.S. You don't really need xold.

 

[DeadlyShadow]

Just one more question if that is ok
i've noticed a strange behavior (well ... strange to me)
i shot two object with the same properties but different masses .the one with the bigger mass crossed a distance X while the one with smaller mass crossed a distance Y WHERE Y<X (the one the small mass fell right on the ground shrotly after being shot while the other one(bigger mass) stayed in air for a while)
is this a normal behavior ?

 

[K^2]

Yes, this is perfectly normal. It may seem counterintuitive, but keep in mind that with equal initial velocity, you give heavier object more initial energy. Since both objects have the same drag, they will initially loose energy at the same rate. The lighter object, naturally, runs out faster.