Shaka

2010-Oct-18, 03:15 AM

I have written two Java Applets which do ballistic calculations for subsonic projectiles that are not fin-stabilized.

The first one asks for the following information and then calculates the straight range in meters, the wind deflection in meters, the impact speed in meters per second and the flight time in seconds.

Altitude above sea level in meters

Air temperature in degrees Celsius

Barometric pressure in inches of mercury

Muzzle velocity in meters per second

Launch angle in degrees

Diameter of steel ball in millimeters

Height of muzzle above ground in meters

Grade of hill in percent (+ uphill, - downhill)

Wind speed in meters per second

Wind direction in clock angles

This software is specifically for homemade mortars firing steel ball bearings. It can also be used for trebuchet-launched pumpkins by using a simple formula to determine the diameter of steel ball that is ballistically equivalent to your pumpkin.

This software assumes that drag is proportional to the square of velocity. A lot of software packages say this but, in the fine print, they add that they are going to “make some simplifying assumptions” or “drop the higher order terms.” Then they proceed to solve the much simpler case of drag being directly proportional to velocity. A word to the wise: If drag is proportional to the square of velocity, range can only be determined by an iterative method. If they are using table look-up (as I did in my pumpkin program) then they are rounding the results off in a way that is only acceptable for vegetables, not steel balls. If they have a formula in closed form – not a DO/UNTIL loop – then they are assuming that drag is proportional to velocity, which is dishonest unless they made that assumption clear.

This program uses an iterative method, so drag is indeed proportional to the square of velocity. This assumption is valid for velocities up to 240 m/s. From 240 m/s to 295 m/s, drag is proportional to velocity cubed. My program now takes account of this, which allows for higher initial velocities. It does not accurately model supersonic projectiles that decelerate through the speed of sound, 343 m/s, however, and should not be used for this purpose.

Air density is re-calculated at each step so, if the ball flies so high that the air is significantly thinner at its apex, this is taken into consideration. The coefficient of drag is also re-calculated at every step so it increases from 0.2 to 0.45 at the exact moment that the velocity falls below the critical point. Altitude, air pressure and temperature are all taken into consideration. Note that, so the isobars on weather maps are all in the same units, barometers are usually normalized to what they would read at sea level. This is also what you want because, since altitude is a separate parameter, if you reported the actual number of inches of mercury at your location, you would be over-estimating the effects of altitude.

I also have a Java Applet that is specifically for trebuchet design. It asks the user to input two of these three parameters and then finds the other one:

efficiency

angle

range

Both Java Applets can be accessed from this page (http://www.axiomaticeconomics.com/pumpkins.php), which contains a short paper on trebuchet design and explodes some common myths.

The first one asks for the following information and then calculates the straight range in meters, the wind deflection in meters, the impact speed in meters per second and the flight time in seconds.

Altitude above sea level in meters

Air temperature in degrees Celsius

Barometric pressure in inches of mercury

Muzzle velocity in meters per second

Launch angle in degrees

Diameter of steel ball in millimeters

Height of muzzle above ground in meters

Grade of hill in percent (+ uphill, - downhill)

Wind speed in meters per second

Wind direction in clock angles

This software is specifically for homemade mortars firing steel ball bearings. It can also be used for trebuchet-launched pumpkins by using a simple formula to determine the diameter of steel ball that is ballistically equivalent to your pumpkin.

This software assumes that drag is proportional to the square of velocity. A lot of software packages say this but, in the fine print, they add that they are going to “make some simplifying assumptions” or “drop the higher order terms.” Then they proceed to solve the much simpler case of drag being directly proportional to velocity. A word to the wise: If drag is proportional to the square of velocity, range can only be determined by an iterative method. If they are using table look-up (as I did in my pumpkin program) then they are rounding the results off in a way that is only acceptable for vegetables, not steel balls. If they have a formula in closed form – not a DO/UNTIL loop – then they are assuming that drag is proportional to velocity, which is dishonest unless they made that assumption clear.

This program uses an iterative method, so drag is indeed proportional to the square of velocity. This assumption is valid for velocities up to 240 m/s. From 240 m/s to 295 m/s, drag is proportional to velocity cubed. My program now takes account of this, which allows for higher initial velocities. It does not accurately model supersonic projectiles that decelerate through the speed of sound, 343 m/s, however, and should not be used for this purpose.

Air density is re-calculated at each step so, if the ball flies so high that the air is significantly thinner at its apex, this is taken into consideration. The coefficient of drag is also re-calculated at every step so it increases from 0.2 to 0.45 at the exact moment that the velocity falls below the critical point. Altitude, air pressure and temperature are all taken into consideration. Note that, so the isobars on weather maps are all in the same units, barometers are usually normalized to what they would read at sea level. This is also what you want because, since altitude is a separate parameter, if you reported the actual number of inches of mercury at your location, you would be over-estimating the effects of altitude.

I also have a Java Applet that is specifically for trebuchet design. It asks the user to input two of these three parameters and then finds the other one:

efficiency

angle

range

Both Java Applets can be accessed from this page (http://www.axiomaticeconomics.com/pumpkins.php), which contains a short paper on trebuchet design and explodes some common myths.