Onion Eater
Well-known member
- Joined
- Jun 28, 2008
- Messages
- 753
- Reaction score
- 139
- Location
- Scottsdale, AZ
- Gender
- Male
- Political Leaning
- Libertarian
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, 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, which contains a short paper on trebuchet design and explodes some common myths.
