Development_of_a_Digital_Mortar_Aiming_System

Transcription

UPTEC F 15061
Examensarbete 30 hp
22 September 2015
Development of a Digital Mortar
Aiming System
Oskar Wåglund
Abstract
Development of a Digital Mortar Aiming System
Oskar Wåglund
Teknisk- naturvetenskaplig fakultet
UTH-enheten
Besöksadress:
Ångströmlaboratoriet
Lägerhyddsvägen 1
Hus 4, Plan 0
Postadress:
Box 536
751 21 Uppsala
Telefon:
018 – 471 30 03
Telefax:
018 – 471 30 00
In this thesis, the plausibility of developing a portable light-weight artillery computer
has been investigated. The main goal of the project has been to replace the traditional
methods that the Swedish Armed Forces are using today to find firing solutions for
their mortar, the GRK m/84. A computational core has been written in Java that
simulates the trajectory of a shell using the model in NATO's STANAG 4355. The
developed system finds firing solutions by using shooting methods and the
multi-dimensional Newton Raphson's method. A Graphical User Interface (GUI)
tailored to mobile computers has been designed in Android.
The computational core along with the GUI has been installed on a rugged hand held
computer and the whole unit has been tested at Markstridsskolan (MSS). The tests
showed that the computational core delivers firing solutions that coincide very well
with the actual firing solutions needed to hit the desired target.
Hemsida:
http://www.teknat.uu.se/student
Handledare: Olov Wilander
Ämnesgranskare: Ken Mattsson
Examinator: Tomas Nyberg
ISSN: 1401-5757, UPTEC F 15061
Populärvetenskaplig sammanfattning
I väpnad strid är det vanligt att båda de stridande sidorna utnyttjar artilleri
för att skaffa sig taktiska fördelar mot sina fiender. Ett vanligt förekommande
vapen är då så kallade granatkastare, som skjuter iväg granater i hög bana
mot identifierade fiendetrupper eller byggnader. Hur långt granaten färdas
beror på hur soldaterna vinklar eldröret, och för att träffa det önskade målet
måste de hitta precis rätt vinkel. En grad för högt eller lågt innebär oftast
att målet inte ens påverkas av granaten.
Försvarsmakten har två typer av granatkastare, varav den mindre ofta
används i så kallade jägaroperationer. Begreppet innebär att soldaterna som
manövrerar granatkastaren ständigt måste röra sig för att inte bli inringade
av fiender. Med begränsad utrustning måste de snabbt kunna hitta rätt
eldrörsvinkel och avfyra en salva granater innan de rör sig till nästa plats.
Då datorer är för otympliga för att bära med sig så använder soldaterna
skjuttabeller med uträknade vinklar för vissa avstånd. Att slå i tabellerna
är en långsam process och kräver samtidigt en stor sinnesnärvaro från den
stressade soldaten.
I det här examensarbetet har en prototyp av en portabel artilleridator
tagits fram i samarbete med Försvarets Materialverk (FMV). Artilleridatorns
syfte är att finna så kallade skjutelement, vilket är benämningen för de
vinklar som behövs för att träffa ett givet mål. En beräkningskärna har
programmerats från grunden för att kunna simulera en granats flykt genom
luften. Kärnan har sedan knutits ihop med ett användargränssnitt på en
handdator anpassad för militärt bruk. Enheten har testats tillsammans med
FMV på en skjutövning där det visade sig att beräkningskärnans simuleringar
stämde väl överens med en verklig granat.
1
Contents
1 Introduction
5
2 Mortar usage
2.1 GRK m/84 . . . . . . . . . . . .
2.2 Shells . . . . . . . . . . . . . . .
2.3 Operating a mortar . . . . . . . .
2.4 Aiming without digital assistance
2.5 Current artillery computers . . .
2.6 Weather . . . . . . . . . . . . . .
3 Mathematical model
3.1 Coordinate system .
3.2 Gravitational force .
3.3 Coriolis force . . . .
3.4 Drag force . . . . . .
3.5 Equation of motion .
3.6 Standard atmosphere
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
7
7
8
12
12
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
15
15
17
17
4 Computation
4.1 Calculating a trajectory . . . . . . . . . . . . . . . .
4.1.1 Order reduction . . . . . . . . . . . . . . . .
4.1.2 Numerical methods . . . . . . . . . . . . . . .
4.1.3 Comparison between the methods . . . . . .
4.1.4 Verification of the Runge-Kutta method . . .
4.1.5 Oscillation in the Runge-Kutta method . . .
4.1.6 Choosing a numerical method . . . . . . . . .
4.2 Finding a firing solution . . . . . . . . . . . . . . . .
4.3 The multi dimensional Newton-Raphson’s method .
4.4 Applying Newton-Raphson’s method to this problem
4.5 Optimization problem . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
20
21
23
23
23
25
25
26
27
31
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Development
5.1 Environments . . . . . . . . . . . . . .
5.2 The computational core . . . . . . . .
5.2.1 FCI-files . . . . . . . . . . . . .
5.2.2 The ballistics module . . . . .
5.2.3 Search method module . . . . .
5.3 GUI . . . . . . . . . . . . . . . . . . .
5.3.1 Views . . . . . . . . . . . . . .
5.3.2 Activity . . . . . . . . . . . . .
5.3.3 Input . . . . . . . . . . . . . .
5.3.4 Error prevention and warnings
5.4 Structure . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
33
33
33
34
34
34
35
35
36
37
6 System safety
38
6.1 Risks, accidents and hazardous events . . . . . . . . . . . . . 38
6.2 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.1 Risk of faulty implementation of numerical method . . 40
6.2.2 Risk of faulty implementation of mathematical model 40
6.2.3 Risk of corrupted files . . . . . . . . . . . . . . . . . . 40
7 Result
7.1 Search method . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Tests against another artillery computer . . . . . . . . . .
7.2.1 Live exercise . . . . . . . . . . . . . . . . . . . . .
7.2.2 Additional tests . . . . . . . . . . . . . . . . . . . .
7.3 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Registering a target . . . . . . . . . . . . . . . . .
7.3.2 Registering, solving and completing a fire mission .
7.3.3 Registering a METCM . . . . . . . . . . . . . . . .
8 Discussion
8.1 Numerical method for trajectory computations
8.2 Search method . . . . . . . . . . . . . . . . . .
8.3 GUI . . . . . . . . . . . . . . . . . . . . . . . .
8.4 Future work . . . . . . . . . . . . . . . . . . . .
8.5 Conclusion . . . . . . . . . . . . . . . . . . . .
9 Acknowledgement
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
42
42
42
42
45
45
46
49
.
.
.
.
.
50
50
50
51
51
51
52
3
Appendices
54
A Terminology
54
B State graphs of trajectory
56
C Runge Kutta convergence for different state components
58
D Comparison of artillery computers
63
E Glossary
66
4
1
Introduction
A mortar is a weapon that is used to fire projectiles, called shells, in a high
trajectory over long distances. The weapon is commonly characterized by a
barrel which is supported by two legs and some sort of stabilizing platform
at the end of the barrel. The purpose of a mortar may vary, but common
tasks are to destroy, suppress, obscure or illuminate a target.
Due to its versatility and range, a mortar is often used to help friendly
infantry advance in combat. To provide effective support the mortar operator
has to find the correct bearing, which is the angle between due north and the
barrel (the compass direction), and the elevation angle, the angle between
the ground and the barrel, in order to connect with the target. Usually the
projectile’s initial velocity can be altered by the operator as well to enable
shorter or longer trajectories. Finding the correct bearing and elevation is
not a trivial task, and increases in difficulty when varying weather conditions
are considered. The natural stress element present in all forms of combat
puts further pressure on the mortar operator.
This project focuses on relieving as much stress as possible for the operator
by creating a program that quickly computes and presents the correct bearing
and elevation. This program will be uploaded on a hand held computer along
with a comprehensive graphical user interface (GUI). The project is carried
out in close cooperation with the Swedish Armed Forces, who are the only
possible end users of this software.
5
Figure 1: The GRK m/84 mounted and ready for use.
2
Mortar usage
This section explains how mortars are used by the Swedish Armed Forces,
and is meant to give a quick overview of the environment of the problem.
Some words and concepts are described further in Appendix A.
2.1
GRK m/84
The GRK m/84 is the smaller one of the two types of mortars that the
Swedish Armed Forces have at their disposal. The weapon features an 81
mm barrel and can fire shells that weigh around 4 kg at targets up to 6 km
away. Unlike the Swedish Armed Forces’ bigger mortar, the GRK m/41, the
GRK m/84 is portable when split into three parts, with a total weight of
around 50 kg. Due to its “light” weight it is often used without any sort of
vehicle assistance, and thus the soldiers operating the mortar has to carry
all needed equipment on their backs.
A shell is launched by dropping it into the barrel and letting it slide down
to the bottom. Upon reaching the bottom the baseline charge of the shell
connects with a propulsion pin and ignites automatically. This detonates the
baseline charge and also any additional charges that have been attached to
it, and the sudden increase in pressure drives the shell out of the barrel at
high speed.
6
2.2
Shells
A shell consists of the payload, fuze, baseline charge and stabilizing fins, see
Figure 2. The wide center part contains the payload which may be explosive
or have another function such as smoke. The payload is triggered by a fuze,
or ignition device, which sits in the front of the shell. The fuze may trigger
from impact, time, magnetic fields or other criteria depending on the type
of shell. Behind the payload is a tube which contains the baseline charge
that gives the shell its initial velocity. When the charge detonates the gas
from the explosion exits through the circular vents in the tube and builds
pressure behind the payload. Additional propulsion charges (from now on
referred to as charges) can be attached to the tube to increase the velocity.
At the very back are fins which stabilize the shell throughout its flight.
The Swedish Armed Forces use four types of shells as of today. Two of
them are explosive shells which are used to destroy or suppress a target. The
shells explode and shatter the casing which causes high velocity shrapnel.
The difference between the two is not the force of the explosion or amount
of shrapnel, but rather the fuze. The first shell, called “80R”, detonates
on impact with an object. It can also be set to armor penetrating mode,
which delays the detonation when the fuze is triggered. This allows the
shell to penetrate light armor before detonating. The second shell, called
“80Z”, is proximity triggered. A doppler radar senses when the shell is a
few meters above ground and detonates the shell while still in the air. This
causes shrapnel to cover a larger area and is used mainly against unprotected
infantry units.
There are also smoke and illumination shells. Both shells have a timed
fuze which is set by the mortar operator prior to each shot. The smoke shell
releases a canister which creates smoke over a period of time. This is used
to conceal friendly troops or to simply reduce the enemy’s vision on the
battlefield. The illumination shell releases a light source that is attached
to a small parachute and drifts to the ground slowly while illuminating the
ground below. This is used during nighttime when friendly soldiers need
vision of the area ahead.
2.3
Operating a mortar
Effectively operating a mortar is not a one man job. A mortar unit usually
consists of around 10 soldiers which all have specific tasks and responsibilities,
especially during assembly and disassembly of the mortar. Apart from the
soldiers at the mortar location, one or more forward observers are often
7
Figure 2: Three smoke shells ready for launch. To the left on each shell is
the baseline charge and the fins, and one additional charge has been put on.
The wide part contains the smoke canister, and the front tip of the shell is
the fuze, which in this case is timed.
needed to identify targets [3]. The forward observer’s mission is to provide
target coordinates to the mortar operator, who then can calculate the best
way to fulfill the mission. If the shell would miss, which is a common incident,
the mortar operator receives an adjustment from the forward observer, so
that the next shell hopefully hits closer to the target.
2.4
Aiming without digital assistance
The software in this project aims to replace the traditional way the soldiers
operating the GRK m/84 uses to find the correct firing solution for a fire
misson. The computations are currently performed without any sort of
digital assistance and requires a great prescence of mind to be carried out in
a quick and correct manner.
The squad carries a variety of tools with them, in addition to the mortar
itself, gathered in a bag, see Figure 3. The two most important contents of
it are the drawing board and the firing tables. The drawing board has a
grid printed on it that can be used as a guideline for an improvised map, see
Figure 4.
8
Once a map has been established the mortar location should be marked.
A coordinate is put onto the map by using the gridlines and a measuring
disk, see Figure 5. The sides of the disk have distance scales and the center
part features a protractor graded in mils. A thin notch leaps in the zero mil
direction which enables drawing lines in any angle if necessary.
With the mortar location in place the soldier is ready to receive fire
missions. A mission is delivered via radio with information about the target
coordinate, the requested shell type and so on. The target is marked on
the map in the same fashion as the mortar location, and the firing distance
should then be determined. This is measured with a “rotating ruler” with
a slider attached to it, see Figure 4. The ruler rotates around a slightly
magnetic disk with a hole in the center which indicates the origin of the
measurement.
Once the distance has been measured an appropriate elevation angle is
found using a nomogram, or alignment chart, see Figure 6. The chart provides
a graphical way of evaluating the function needed for the approximate
elevation, and one chart is needed for each combination of shell type and
charge. An elevation is found by putting a slider in the channel corresponding
to the desired charge, and then sliding it so that the slider’s index line
coincides with the required distance. Note that the rightmost diagram shows
how the index line should be drawn on a slider depending on the current
temperature. A temperature above 15 ◦ C will result in a downward sloping
index line, which means that the elevation will be a bit lower than at the
standard temperature. If several solutions are available it is up to the soldier
to decide the best one.
Another common task is to adjust the firing solution if a target is missed.
Since the mortar operator usually can not see the target it is the forward
observers responsibility to guide him or her to a better firing solution. The
forward observer informs the operator of how much the impact point should
be moved in width, i.e. left or right, and length, i.e. closer or farther. This
is however directions from the forward observer’s perspective, which means
that the correction has to be rotated before being applied to the mortar
operator’s map. That is why the forward observer also gives the observed
direction of the target in mils. This allows the mortar operator to transform
the correction to easting and northing by using a circular plastic disk. The
adjustment from the observer’s perspective is marked on the disk, and then
the disk is rotated corresponding to the observed direction. The new location
is marked on the map and the operator can look up a new firing solution.
9
Figure 3: A bag with tools for computing firing solutions.
Figure 4: A blank drawing board accompanied by the measuring tool. The
slider is missing in this picture.
Figure 5: A measuring disk used for scales 1:10 000, 1:20 000 and 1:50 000.
The protractor in the middle has a resolution of 10 mils.
Figure 6: The nomogram of the smoke shell elevations for charges 4 through
6. Note the rightmost diagram that shows how the index line varies with
temperature.
2.5
Current artillery computers
The concept of artillery computers is of course nothing new. The Swedish
Armed Forces has an artillery computer which is used frequently. The
problem is that it is large, heavy and mounted in an armored car, which
makes it unusable for the type of missions that this project aims to support.
When using the larger mortar, the GRK m/41, this computer is always used
as the mortar itself is transported by vehicle.
2.6
Weather
The current weather has a huge impact on how the fired shell behaves in
flight. The most obvious factor is of course the wind, but other conditions
such as air temperature and pressure, relative humidity and the temperature
of the powder in the projectile itself also affects the impact point. Usually
a Standard Computer Meteorological message (METCM) [5] is provided
shortly before a mission begins. The METCM consists of a header and a
body, which together describe the current weather in ascending layers of the
air.
The header contains information about where and when the weather
information is valid. The body then specifies the wind speed and direction,
pressure and temperature for ascending layers, or zones, of a few 100 meters
each. Zone 00 represents the ground level, zone 01 represents 0 to 200 meters
above ground, zone 02 represents 200 to 500 meters above ground and from
there on each zone covers 500 meters.
If a METCM is not available, the soldiers can estimate the wind, temperature and pressure at ground level. This data can then be used to compute
the temperature and pressure at a given height, see Section 3.6.
12
Figure 7: A typical METCM.
3
Mathematical model
The mathematical model of the projectile is based on the “NATO Armaments
Ballistic Kernel” (NABK) [6]. It is assumed that five forces act on the
projectile throughout its flight. These forces are the gravitational force, the
Coriolis force, the drag force, the Magnus force and the lift force. The last
two forces are however disregarded in this project since the projectiles fired
from the GRK m/84 do not spin, which causes the two forces to vanish.
A summary of all the notations used in the following formulae are shown
in Table 1.
3.1
Coordinate system
During the computations a cartesian, orthogonal, right-handed coordinate
system is used. The origin is located at sea level and on a line between the
mortar’s center platform and the center of the earth. The axes are laid out
such that the first axis, ~x, is pointed towards north, the second axis, ~y , is
pointed upwards and perpendicularly from the ground and the third axis, ~z,
is pointed towards east.
3.2
Gravitational force
The gravitational field of the earth will act on the projectile and pull it
towards the ground. The force is modeled as

X1
R

F~G = m~g = −mg0 (R2 /r3 )~r = −mg0  1 −
X3
R

2X2
R

.
(1)
Due to the earth not being perfectly round, the magnitude of the gravitational
force, g0 , will vary with latitude according to
g0 = 9.80655(1 − 0.0026 cos(2lat)).
14
(2)
3.3
Coriolis force
Since the earth and the defined coordinate system is rotating, the projectile
will be affected by the fictive Coriolis force. The resulting force is
~ = −2m(~
F~C = mΛ
ω × ~u)
(3)
where


Ω cos(lat)


ω
~ =  Ω sin(lat) 
0
(4)
represents the rotational vector of earth. Keep in mind that this force is not
exerted on the projectile, it is rather a way of countering the fact that the
ground fixed coordinate system is rotating away from the projectile.
3.4
Drag force
The drag force caused by the surrounding air will push in the opposite
direction of the projectile’s velocity relative to the air velocity. This force
can be modeled as
πρd2
CD0 v~v .
F~D = −
(5)
8
~ −w
where ~v = U
~ represents the velocity of the projectile relative to the
surrounding air.
The air density ρ varies with pressure and temperature according to
ρ=
1 pd
pv
(
+
)
T Rd Rv
(6)
The partial vapor pressure pv is calculated as
7.5·T
pv = φ · 610.78 · 10 237.3+T
(7)
and the partial dry air pressure is then calculated as the remainder of the
total pressure
pd = p − pv .
(8)
The partial pressure model is not included in the NABK, but is taken
from NASA [9].
15
0.28
0.26
0.24
CD0
0.22
0.2
0.18
0.16
0.14
0.12
0
0.1
0.2
0.3
0.4
0.5 0.6 0.7
Mach number
0.8
0.9
1
1.1
Figure 8: The CD0 curve for the 80R shell.
Finally, the drag force depends on the factor CD0 . It is given in the
FCI file (see Appendix A) as a polynomial function of the Mach number on
different Mach intervals. A polynomial function section may have an order
between 0 and 4, and together the polynomials for a given shell type form a
continous function. A typical CD0 curve is seen in Figure 8.
CD0 = b0 + b1 M + b2 M 2 + b3 M 3
16
(bmin < M < bmax )
(9)
3.5
Equation of motion
Equations 1, 3 and 5 can be gathered into one equation of motion using
Newton’s second law of motion
~
dU
F~ = m
.
(10)
dt
Adding the forces together and dividing both sides by the mass yields
X
~
dU
1
= (F~G + F~C + F~D ).
dt
m
The initial values are defined by the muzzle position


lW cos(QE) cos(AZ)

~0 = 
X
 X2W + lW sin(QE) 
lW cos(QE) sin(AZ)
(11)
(12)
and the muzzle velocity


u0 cos(QE) cos(AZ)


U~0 = 
u0 sin(QE)

u0 cos(QE) sin(AZ)
(13)
Equation 11 together with Equation 12 and 13 define the entire motion
of the fired projectile. The end condition is set by the target height yT .
3.6
Standard atmosphere
As mentioned in Section 2.6, the soldiers often provide an estimation of the
weather at ground level. This data can be used to simulate an atmosphere,
i.e. the pressure and temperature at a given height H, using a model from
ISO 2533 [7]. The model needs the ground level temperature Tb , ground level
pressure pb and the ground level height above sea level Hb . It also requires
certain values such as the gravitational acceleration g, the universal gas
constant R, and the temperature lapse rate β which is an estimated value of
how the temperature increases linearly with height. For standard atmospheres
this lapse rate is assumed to be −6.5◦ C/km, i.e. the temperature decreases
with increasing altitude, which is symbolized by the relation
T (H) = Tb + β(H − Hb ).
17
(14)
The pressure relation is less trivial.
− g
β
p(H) = pb 1 + (H − Hb ) βR
Tb
(15)
The pressure and temperature from Equation 14 and 15 can be used in
Equation 6 and 7 in order to compute the drag force.
18
m
Table 1: Notations used in mathematical formulae
Projectile mass
d
~
X
Projectile diameter
~0
X
~
U
Muzzle position relative to ground fixed coordinate system
U~0
Initial velocity of projectile relative to ground fixed coordinate system
u0
Initial speed of projectile relative to ground fixed coordinate system
AZ
Bearing angle
QE
Elevation angle
X2W
The height above sea level of the mortar’s baseplate
lW
The length of the barrel of the mortar
~g
The gravitational acceleration
g0
The magnitude of gravitational acceleration at ground level
R
The radius of Earth
~r
Projectile position relative to the center of earth
r
~
Λ
The distance between the projectile and the center of earth
ω
~
The rotational vector of earth
Ω
The angular velocity of earth
lat
Latitude
CD 0
Fitting factor used in drag force calculation, related to the mach number
~v
Projectile velocity relative to surrounding air
v
Projectile speed relative to surrounding air
w
~
Air velocity
p
Pressure at current projectile altitude
T
Temperature at current projectile altitude
ρ
Air density at current projectile altitude
Rv
The specific gas constant of water vapor
Rd
The specific gas constant of dry air
pv
The partial water vapor pressure
pd
The partial dry air pressure
β
Temperature lapse rate for increasing altitude
φ
The relative humidity
Projectile position relative to ground fixed coordinate system
Projectile velocity relative to ground fixed coordinate system
The Coriolis acceleration
4
Computation
Two separate problems have been considered in this project. The first and
perhaps most obvious problem is to calculate a complete trajectory of a
projectile with known initial position and velocity. This results in an initial
value problem with second order ordinary differential equations. The sought
solution is the position when the projectile hits the target height, or a
predefined height above it.
The intended use for this software, however, is not to calculate a trajectory
with a known firing solution. On the contrary, it is finding the firing solution
for a given target that is the objective. This is known as a two-point boundary
value problem. The mortar imposes one boundary condition on the system,
and the target imposes a second one. The solution in this case is the initial
values (the firing solution) that results in a trajectory through both the
mortar and the target.
4.1
4.1.1
Calculating a trajectory
Order reduction
Equation 11 in Section 3.5 describes the fundamental relation between force
and acceleration. But if it is to be used in a computer program it has to be
reduced to a system of first order ODEs. Expressing the equation in terms
of time derivatives results in
¨ = A(~x˙ , ~x)
~x
(16)
where the function A(~x˙ , ~x) represents the acceleration with respect to the
velocity and position. Replacing the velocity ẋ with a new variable u, and
replacing the acceleration ẍ with the velocity’s derivative u̇ gives the system
of equations
~u˙ = A(~u, ~x)
~x˙ = ~u.
(17)
Equation 16 has been reduced to two coupled equations, and standard
numerical methods can now be applied to the system. The vectors in
Equation 17 can be expanded to their respective components to enable a
better view of the problem.
20
u˙x = Ax ((xx , xy , xz ), (ux , uy , uz ))
u˙y = Ay ((xx , xy , xz ), (ux , uy , uz ))
u˙z = Az ((xx , xy , xz ), (ux , uy , uz ))
x˙x = ux
(18)
x˙y = uy
x˙z = uz
The six variables xx , xy , xz , ux , uy , uz can be referred to as state variables.
Together they describe the system’s, or projectile’s, state. It is clear that the
computationally expensive part lies in the three first equations, corresponding
to the acceleration evaluation. The change in position is simply the current
velocity which is applied directly to the system. For a summary of how the
state variables vary over time, see Appendix B.
4.1.2
Numerical methods
With the system obtained in Equation 17 the problem is ready to be solved
numerically. But there are countless numerical methods available, and thus
a motivated choice of a suitable method has to be made. Four common
numerical methods have been tested in this project. All four methods solve
the ordinary differential equation
y 0 (t) = f (t, y(t))
y(t0 ) = y0
(19)
where y can be a scalar or a vector dependent on t, which is an independent
variable. The methods start in the initial value y0 , and then “step” through
the vector field f (t, y(t)) using a step length h = tn+1 − tn . Note that the
first part of Equation 19 is applicable to Equation 17.
Euler’s method This is one of the oldest numerical methods and an
important part in the other methods tested in this project. The method was
described by Leonhard Euler in his work “Institutiones Calculi Integralis”,
which was published in 1768 [1]. The method is of order one and is not
expected to provide a satisfying result, but it is an interesting reference case
to compare the other methods against. The method is described as
k1 = f (t, yn )
yn+1 = yn + hk1 .
21
(20)
Heun’s method Heun’s method is a second order numerical method that
is often referred to as the improved Euler’s method. The method improves
Euler’s solution by taking an Euler step, calculating the derivative in the new
point and then taking another step from the same point with that derivative.
Averaging these two steps gives a better estimate to the right solution than
by simply using Euler’s method. The method is described as
k1 = f (t, yn )
k2 = f (t + h, yn + hk1 )
h
yn+1 = yn + (k1 + k2 ).
2
(21)
The midpoint method The midpoint method is similar to Heun’s method
in that it takes an intermediate step before taking the actual step to the next
point. The difference is that the midpoint method steps half a time step,
computes the derivative there, and then takes the step to the next point
using only the new derivative. The method is described as
k1 = f (t, yn )
h
h
k2 = f (t + , yn + k1 )
2
2
yn+1 = yn + hk2 .
(22)
The Runge-Kutta method (RK4) Calling a numerical method “The
Runge-Kutta method” is actually a bit confusing, since Runge-Kutta methods
are a family of numerical methods that can be written in a specific way.
However, RK4, or the classical Runge-Kutta method as it is sometimes
called, is very popular due to its stability. Therefore it is often called The
Runge-Kutta method. RK4 is a fourth order method, which means that it
takes more intermediate steps than the previously described methods. The
method is described as
k1 = f (t, yn )
h
h
k2 = f (t + , yn + k1 )
2
2
h
h
k3 = f (t + , yn + k2 )
2
2
k4 = f (t + h, yn + hk3 )
h
yn+1 = yn + (k1 + 2k2 + 2k3 + k4 ).
6
22
(23)
4.1.3
Comparison between the methods
When a differential equation is solved in discrete time steps there will
generally be an error compared to the analytical solution. This error depends
on several factors such as step length, the order of the numerical method,
the stiffness of the differential equation and so on. To find a viable candidate
for this particular software a test has been conducted to try to compare the
performance of the four methods.
Tables 2-5 show the error in the xx state variable for a shell fired at
an angle of about 45◦ over 20 seconds. The absolute error is presented for
different step lengths and numerical methods, and the rightmost columns
show how the error increases when the step length is doubled. The correct
solution is assumed to be achieved by using the Runge-Kutta method with
step length 2−20 , but this of course an estimate of its own. Still, it should
serve as a sufficiently close approximation to the correct solution.
All step lengths that have been tested are powers of 2 to avoid errors in
float representation of them.
4.1.4
Verification of the Runge-Kutta method
The Runge-Kutta method is used as a tool for getting the correct solution in
Section 4.1.3, but the numerical solver is written especially for this project,
and thus there are no guarantees that the solver is correct. To assure that
the solution is correct the whole trajectory computation has been rewritten
in MATLAB and executed with the same parameters as the Java convergence
test, but with a Runge-Kutta algorithm written for an educational textbook
[10]. The difference between the two different platforms lie around 0.1 mm. It
is unclear if this error comes from the use of slightly different float operations
in the different platforms, or if some element of the computation has been
written differently. The relatively small difference should however assure
that the Java implementation is in fact sufficiently correct.
4.1.5
Oscillation in the Runge-Kutta method
It should come as no surprise that the fourth order method completes the
computation with the smallest error among the numerical methods, but it
is harder to explain why it does not converge as intended. The error in the
other numerical methods converge according to the defintion of the order of
accuracy, which is
E(h) = Chn
(24)
23
·10−5
0.5
Error [m]
0
−0.5
−1
−1.5
−2
20
2−1
2−2
2−3
2−4 2−5 2−6
Step size h[s]
2−7
2−8
2−9
Figure 9: Convergence of the Runge-Kutta method for the x component of
the position vector.
where n is the order of accuracy. But judging from Figure 9 it seems like the
error of the Runge-Kutta method oscillates towards zero rather than steadily
approaching it. In Appendix C, the same convergence test for the xy , ux
and uy state variables shows that the error sometimes even grows larger for
smaller step lengths. The method is without doubt implemented correctly,
as the same phenomenon occurs for two independent implementations in
different programming languages.
It is more likely that the oscillating convergence occurs because of the
fact that the acceleration is not even C 1 smooth. As mentioned in Section
3.4, the CD0 function is given as a piecewise polynomial function, and for the
shells used by the Swedish Armed Forces the CD0 polynomials are of order
1, rendering them non-differentiable in the boundaries of each subdomain.
It is possible that the error caused by this discontinuity becomes large for
some unfortunate step lengths.
24
4.1.6
Choosing a numerical method
From the errors in Tables 2-5 on pages 29 and 30 it is clear that all methods,
except for perhaps Euler’s method, are viable for this particular computation.
Much larger errors arise when deciding coordinates of targets and mortar
locations or when rounding the bearing and elevation in the firing solution
to whole mils. It is of course always preferable to have a small error in
computations, but in this case it might be perfectly acceptable to miss a
target by one centimeter or even a meter.
The Runge-Kutta method with a step length of 1 second gives an error of
around 20 µm, which justifies the fact that it requires double the amount of
acceleration computations compared to the second order methods with the
same step length. It is, as in most differential equation systems, a perfectly
viable choice for this problem, and no further analysis of this part of the
problem is necessary.
4.2
Finding a firing solution
With the method from Section 4.1 and a known firing solution it is possible
to compute a trajectory and find the impact point. But the ultimate purpose
of the software is not to simulate arbitrary trajectories, but rather to find
the initial values necessary to reach a specific target, also known as a firing
solution. This type of problem is known as a two-point boundary value
problem, as mentioned in the beginning of Section 4.
The boundary conditions in this problem are imposed by two 3-dimensional
positions, which are the barrel’s muzzle and the target. There are no conditions for the velocity of the projectile at the time of launch or impact. Since
there is no known general way of solving these problems analytically, an
iterative method is needed. The trajectory is entirely decided by the initial
state, if the shell type and weather conditions are decided, and thus the
impact point can be described as a function of the initial state.
x~T = T (x~0 , u~0 )
(25)
The error in an impact point can thus be described as
D(x~0 , u~0 ) = |T (x~0 , u~0 ) − x~T ∗ |
(26)
where x~T ∗ is the target. This means that solving the equation
D(x~0 , u~0 ) = 0
25
(27)
is equivalent to finding a trajectory that fulfills the boundary conditions.
However, it is not possible to use arbitrary values for the initial position and
velocity. These are dependent on the bearing, elevation, charge, shell type
and so on. Therefore it makes more sense to express the impact point as a
function of the bearing and elevation, assuming that all other factors are
decided. This parametrization also reduces the number of variables in the
root from six to two, which of course is preferable.
D(AZ, QE) = |T (AZ, QE) − x~T ∗ |
(28)
Finding the bearing and elevation such that
D(AZ, QE) = 0
(29)
would give an actual firing solution that is applicable to the current fire
mission. An alternative is to split the impact point x~T into its two ground
parallel components xT x and xT z and then solve the resulting system of
equations
xT x (AZ, QE) = x∗T x
xT z (AZ, QE) = x∗T z .
4.3
(30)
The multi dimensional Newton-Raphson’s method
Equation 30 is solvable by using the multi dimensional Newton-Raphson’s
method [2]. The method is a generalization of the common Newton-Raphson’s
method that finds single dimensional roots. The left hand side of Equation
30 can be described as a multivariate vector function F~ (~v ), and the right
~ The objective of this problem
hand side can be summarized as a vector X.
is to find the vector ~v that solves the equation
~
F~ (~v ) = X.
(31)
Newton-Raphson’s method solves this problem with an iterative algorithm
that makes use of the current Jacobian matrix J, where
Jij =
δFi
.
δvj
(32)
As analytical derivatives rarely are available for these types of problems, the
Jacobian is usually approximated with additional function evaluations as
Fi (v0 , ..., vj + ∆vj , ...) − Fi (v0 , ..., vj , ...)
δFi
≈
.
δvj
∆vj
26
(33)
This means that n + 1 function evaluations are needed per iteration, where
n is the dimension of ~v .
Just as with its single dimensional counterpart, the multi dimensional
Newton-Raphson’s method is a root finding algorithm, which means that
it finds a set of variables that vanishes the function. To accomodate this
need, the relationship in Equation 31 is rewritten as a discrepancy vector
that should be reduced to a zero vector, i.e.
~ v) = X
~ − F~ (~v ) = ~0
H(~
(34)
The system can now be solved iteratively with the algorithm
J · v~δ = −H(v~k )
(35)
vk+1
~ = v~k + v~δ
Note that the first step requires the inverse of the Jacobian to acquire v~δ
and that an initial guess is needed for v~0 . The iteration is ended when a
~ v ) is obtained.
sufficiently small H(~
4.4
Applying Newton-Raphson’s method to this problem
Section 4.3 describes the multi dimensional Newton-Raphson’s method in
general. The method should now be applied to the problem in Equation 30.
In this case, the function F~ (~v ) in Equation 31 returns an impact point from
a trajectory simulation. F~ depends on the vector ~v , which consists of the
~
bearing AZ and the elevation QE. Finally, the right hand side vector X
∗
corresponds with the target location x~T . With these definitions the Jacobian
becomes
!
J=
δxT x
δAZ
δxT z
δAZ
δxT x
δQE
δxT z
δQE
.
(36)
Note that the low dimensionality of F~ and ~v facilitates the evaluation of
the Jacobian J and its inverse. As mentioned in the previous section, only
three function evaluations are needed to obtain J in each step. One is needed
for the actual impact point for the current bearing and elevation, another is
needed for the evaluation of the bearing dependent derivatives and a third
one is needed for the elevation dependent derivatives. Once the Jacobian is
found it is trivial to find the inverse of it with the formula
!
δxT z
δxT x
−
1
δQE
δQE
J −1 =
.
(37)
δxT x
Tz
|J| − δx
δAZ
δAZ
27
6,000
Range [m]
5,000
4,000
3,000
2,000
1,000
0
100
200
300
400 500 600
Elevation [mils]
700
800
900
Figure 10: The relation between elevation and range. This particular example
is for the 80R shell with charge 6 and standard weather conditions, but the
general shape of the curve is maintained for all combinations.
An initial guess for the bearing and elevation needs to be available for
every combination of shell type and charge. The bearing is easy to guess as
the direction of the target is known. The elevation is a bit more complicated
as the elevation to range relation is not trivial. Some sort of estimate should
be provided when solving, but it need not be very precise as the relation is a
steadily decreasing function without local extrema, see Figure 10.
28
Table 2: Euler’s method
h [s]
20
2−1
2−2
2−3
2−4
2−5
2−6
2−7
2−8
2−9
Distance [m]
T [s]
Absolute error [m]
E(h)
E(h/2)
1722.18206
1719.78969
1718.57106
1717.95583
1717.64669
1717.49174
1717.41417
1717.37536
1717.35595
1717.34624
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
-4.85·100
-2.45·100
-1.23·100
-6.19·10−1
-3.10·10−1
-1.55·10−1
-7.76·10−2
-3.88·10−2
-1.94·10−2
-9.71·10−3
1.98
1.99
1.99
2.00
2.00
2.00
2.00
2.00
2.00
*
Table 3: Heun’s method
h [s]
20
2−1
2−2
2−3
2−4
2−5
2−6
2−7
2−8
2−9
Distance [m]
T [s]
Absolute error [m]
E(h)
E(h/2)
1717.24158
1717.31334
1717.33080
1717.33511
1717.33618
1717.33644
1717.33651
1717.33652
1717.33653
1717.33653
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
9.50·10−2
2.32·10−2
5.73·10−3
1.42·10−3
3.55·10−4
8.86·10−5
2.21·10−5
5.54·10−6
1.38·10−6
3.46·10−7
4.10
4.04
4.03
4.01
4.01
4.00
4.00
4.00
3.99
*
Table 4: The midpoint method
h [s]
20
2−1
2−2
2−3
2−4
2−5
2−6
2−7
2−8
2−9
Distance [m]
T [s]
Absolute error [m]
E(h)
E(h/2)
1717.39159
1717.35121
1717.34032
1717.33749
1717.33677
1717.33659
1717.33655
1717.33653
1717.33653
1717.33653
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
-5.51·10−2
-1.47·10−2
-3.79·10−3
-9.60·10−4
-2.42·10−4
-6.06·10−5
-1.52·10−5
-3.81·10−6
-9.50·10−7
-2.37·10−7
3.75
3.87
3.95
3.96
3.99
3.99
3.99
4.01
4.00
*
Table 5: RK4
h [s]
20
2−1
2−2
2−3
2−4
2−5
2−6
2−7
2−8
2−9
Distance [m]
T [s]
Absolute error [m]
E(h)
E(h/2)
1717.33655
1717.33652
1717.33653
1717.33653
1717.33653
1717.33653
1717.33653
1717.33653
1717.33653
1717.33653
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
20.0
-1.95·10−5
6.24·10−6
-1.68·10−6
3.02·10−7
-1.44·10−7
1.98·10−8
6.01·10−9
-1.29·10−9
9.65·10−10
5.75·10−10
-3.13
-3.70
-5.57
-2.10
-7.26
3.30
-4.66
-1.34
1.68
*
4.5
Optimization problem
Defining the search method as an optimization problem could be a different
approach. The distance measure in Equation 28 has one single minimum
which corresponds to the correct firing solution. Solving the unconstrained
minimization problem
minimize D(AZ, QE)
(38)
AZ,QE
would mean finding the firing solution that minimizes the distance between
the target and the impact point which is equal to hitting the target. This
problem can be solved with a number of methods such as gradient descent or
a pattern search, but due to time restrictions this has been left unexplored
in this thesis.
31
5
Development
The models, methods and results from Section 3 and 4 have been implemented
in a Java program. The choice of Java is not obvious, as there are many
competing languages, but it has a few advantages that are worth mentioning.
One advantage is that Java is platform-independent, which means that it is
easy to deploy to a wide selection of computers, in addition to traditional
desktops and laptops. For this particular project it is desired to have a
program that can be used primarily in a handheld computer, but also on a
desktop computer. The fact that the mobile operating system Android runs
Java as its native language simplifies developing both the computational core
and the Graphical User Interface (GUI), which is a big part of the project.
The software can be split into two distinct parts. First there is the core
program that handles the ballistics and search method described in Section
4. This part is platform independent which means that it will work on both
PCs and handheld computers.
The second part is the GUI. The core is useless without a way of communicating with it, and this is the purpose of the GUI. Its only mission is
to receive input from the user, send it into the core, receive the result and
then present it to the user. This part can not be platform-independent, as
different operating systems have different ways of interpreting input and
showing information to a user.
5.1
Environments
The two parts of the program are kept in separate integrated development
environments (IDEs), to avoid confusion and because different IDEs are
suitable for different types of programming projects.
Eclipse Kepler SR2 is used for the core. It is a popular IDE for Java
projects and features a plugin system that allows the user to tailor the
environment to his or her needs.
Eclipse has been the official IDE for Android development for a long time,
thanks to the Android Development Tools (ADT) plugin. But in December
2014 Android Studio was released. The new IDE is specifically created for
Android development and offers more functionality than Eclipse, especially
when testing Android code directly on physical devices. In this project
Android Studio 1.1.0 is used for the Android part.
32
5.2
The computational core
The computational core has been written in pure Java. This allows the core
to be deployed to several platforms without having to rebuild it. The core
provides functionality to the GUI through a main class, currently called
DSG (the working title of the project), that represents the running session.
An instance of DSG has all the methods necessary to complete fire missions.
The instance also contains all data about the running session, such as fire
missions, battery locations and targets.
5.2.1
FCI-files
The FCI-files mentioned in Appendix A are crucial for finding the correct
firing solution. The format of the files is defined in [8].
The files are stored in the handheld computer’s file system and are
accessed each time the program boots up. Each file contains information of
how a shell behaves in flight. When DTV receives the FCI data it performs a
few ballistic simulations for each charge and fits a quadratic polynomial to
the relation between elevation and the resulting range. These polynomial
coefficients are stored as well and are used to find an inital estimate of a
firing solution when a fire mission should be solved.
5.2.2
The ballistics module
Trajectories are computed by a ballistics module that implements the mathematical models described in Section 3. A data package containing all
necessary information for the trajectory is sent to the module. This includes
the firing solution, the projectile data, the weather conditions, geographic
location and more. The system of differential equations is set up and then
integrated until the end condition is reached. The end condition may vary
depending on the shell. For explosive shells, such as the 80R and 80Z, the
trajectory should be simulated until the ground is reached. The other shells
are treated differently since they have a burst height that is set by the user.
The trajectory of the illumination shell is only computed until the light source
is released, but the smoke shell has a second stage, also known as secondary
ballistics, that must be considered. When the smoke canister is released the
projectile data is modified in the computation according to data provided
in the FCI file, and then the simulation continues until the canister reaches
the ground. After a simulation has been completed the module returns the
impact position in three dimensions as well as the flight and burst time of
the shell.
33
5.2.3
Search method module
When the user requests a firing solution for a fire mission the request is
sent to the search method module. This module’s goal is to find all the
firing solutions possible for a fire mission, and it does so by implementing
the methods from Section 4.4. The module searches for a firing solution for
each charge and saves found firing solutions. In some rare cases it might be
possible that two different firing solutions can be found for the same charge,
but in this implementation it is assumed that this is not the case.
When a firing solution for a particular charge should be found the search
method formulates an initial guess of the firing solution based on approximate
knowledge of how the selected shell behaves in standard weather conditions.
Then it lets the ballistics module simulate the resulting trajectory and
receives the impact point back. If the distance between the target and the
impact point is too great the firing solution is corrected before simulating a
new trajectory. This process is repeated until a shell falls sufficiently close
to the target or a set number of iterations are reached. The iteration limit is
set well above the usual amount of iterations and acts as a safety measure
to make sure that the program does not stall. When all charges have been
tested a list of found firing solutions is returned.
5.3
GUI
The GUI is what the mortar operator will communicate through when using
the software. As the operator will be stressed it is important that the GUI
is responsive and easy to understand. Android provides the tools needed
to accomplish this without spending too much time on tedious graphics
programming.
5.3.1
Views
The finished product should offer a lot of functionality to the user, and since
the screen of the device is relatively small it is important to split separate
functions into their own views in order to avoid excessive scrolling and to
keep a clean design that is easy to interpret. To accomplish this a menu
system has been created. The menu is always accessible in the top left corner
of the screen.
The contents of each view is maintained when a user switches to a different
view. This enables the user to quickly perform another urgent task without
risking loss of the current data on screen. This concept is realized with the
use of fragments, which is Android’s way of handling modular user interfaces.
34
In this application, each fragment represents a full screen view. When the
user switches to another view, the current fragment is put on a fragment
stack from which it can be accessed later, and a new fragment is brought up
and shown to the user.
5.3.2
Activity
The fragments can not communicate with each other directly, but they are all
monitored by the same activity, which handles the communication between
the computational core and the GUI. The activity creates all fragments when
first starting up, and is responsible for showing the appropriate fragment
when the user requests it.
The activity also gets an instance of the main class mentioned in Section
5.2 at application startup. This instance is then used whenever an action
needs to be performed, whether it is registering a target, finding a firing
solution or setting the current time.
5.3.3
Input
The user will spend most of his or her time entering data into the system,
which makes it even more important to have a clear GUI and an input
method that minimizes the risk of errors. Android provides a standard
on-screen keyboard, but it is not well-suited for this sort of application. The
exact layout of the keyboard varies with the current version of the Android
operating system, but common features such as a shift button for upper and
lower case letters, dot and comma buttons and “smiley”-buttons are often
added. As these features are completely useless in battle, a custom keyboard
has been created. It may not be as aesthetically pleasing as Android’s default
keyboard, but it is stripped of all the previously mentioned features. This
gives the user a less cluttered keyboard that is easier to use. The only buttons
except the letters and numbers are an erase button and a button for tabbing
between input fields, see Figure 11(a).
Even though unnecessary buttons are removed there are still 29 letter
buttons and 10 digits that should be fitted on a 5” screen. Therefore it is
recommended to use a stylus when operating the system. This is sometimes
more of a requirement than an option as operations often are carried out in
cold or wet environments, where gloves are needed.
For fields that require numeric input only there is an additional custom
keyboard. This keyboard features the 10 digits, a minus sign, an erase and
a tab button, see Figure 11(b). If a field should have a numeric value, the
35
(a) Alphanumeric keyboard
(b) Numeric keyboard
Figure 11: The two keyboards used in the GUI.
numeric keyboard is brought up automatically.
The input fields themselves use large uppercase letters and have a
monospace font which increases readability. Buttons are large, often covering
the entire screen in width. The goal has been to use as few fields and buttons
as possible without losing functionality. This in combination with the well
divided menu system gives the user an experience that is easy to quickly
interpret. With a little training it should be easy to quickly navigate the
program and complete the fire missions received.
5.3.4
Error prevention and warnings
The dangers of using a mortar are many, and because of that fact it is
important to prevent the users from entering incorrect information into the
system. Note that this only can be controlled to some extent. It is difficult
to argue against an air temperature of 21◦ C instead of 11◦ C, and such an
error will probably pass unnoticed. Still there are some measures which can
be taken in order to prevent the most severe errors.
Obvious input errors, such as stating a temperature of -60◦ C for example,
are denied when the user tries to register the input. Some other errors may
not be able to detect at registration, but they may surface when the operator
tries to execute a firing mission. If a firing solution results in an impact
point close to a forward observer, another mortar location or outside of a
designated fire area the user is warned. Symbolics and bold text is used to
warn the user that something dangerous is happening, see Figure 12. This
concept is covered further in Section 6.
36
Figure 12: A warning message.
5.4
Structure
The relation between all parts of the program is shown in Figure 13. Some
minor modules that are less interesting have been left out of this diagram.
Figure 13: A block diagram of the most essential parts of the system.
37
6
System safety
Extensive testing is always important when creating new software. Finding
and removing bugs can mean the difference between success and failure of
a product, whether it is code meant for a social media application or a
money transfer system. But a bug or a miscalculation in this program could
quite possibly result in serious injury or even death for an allied soldier or a
civilian. Therefore the Swedish Armed Forces demand that all software of
this type goes through a rigorous risk assessment before being delivered to
them. The assessment usually results in a risk log with every possible risk
listed, accompanied by the probabilities of any resulting accidents and how
severe the accident could become. If an accident is estimated to happen too
frequently in a system, appropriate actions should be proposed and carried
out so that the risk is reduced to an acceptible level. The system safety work
should build on HSystSäk [4], developed by the Swedish Armed Forces.
It is important to note that risks always will be present in these types
of systems due to the nature of the situation. A system that is somehow
involved in inflicting injury to others will always have some sort of risk
involved. If all risks were to be vanished, it would affect the usability and
purpose of the system to the point of it not accomplishing the initial objective.
This is why risks are reduced and not removed. It may seem counterintuitive
or inhumane, but some risks have to be accepted in order to maintain a
functioning system. One crippling injury every ten years, or one death every
50 years is of course not a desired outcome, but it may be necessary to accept
the risk in order to be able to use the system.
This is not a concept that is valid only in the military. Systems used in
heavy industry or medicine have to pass the same assessments before being
delivered to factories and hospitals. In fact, everything people do in their
daily life has some risk involved, but most risks are not as dangerous as these
ones. Getting hit by lightning while walking outside can be seen as a risk
that is already reduced by nature to a more than acceptible level.
6.1
Risks, accidents and hazardous events
The term risk in this context does not only imply the probability of an
accident, but also the consequences of said accident. An accident may lead
to a bruise, a death or anything in between and this means that different
risks can vary in severity while having the same probability of happening.
In a slightly unmathematical way, it is said that the risk is a function of
probability of an accident occuring and the consequences of that accident.
38
It is also important to note the difference between an accident and a
hazardous event. A hazardous event occurs when the system performs in
an undesired way that is potentially dangerous to its environment. But the
actual accident only happens if a person or object is damaged. Therefore
the risk assessment should always include the probability of each hazardous
event, but also the probability of exposure to this hazardous event. The
probability of the accident is the probability that both the hazardous event
and the exposure to it happens at the same time, which is calculated by
simply multiplying the two probabilities.
6.2
Assessment
The purpose of this product is to deliver firing solutions to a mortar operator
who then will aim the mortar according to the firing solution. The fact that
the system is disconnected from the mortar means that a human always will
act like a filter between them, and that the only hazardous event is that the
mortar is aimed in a direction that may cause unintended damage to humans
or buildings. This prevents any gravely miscalculated firing solutions from
being carried out. It may be difficult for a soldier to detect an error of 10
mils in elevation, but he or she ought to be suspicious if the barrel should be
aimed straight up, or in a completely different direction than before. Risks
that are created by the mortar itself are not considered, as they should have
been included in a separate risk assessment.
Even though there is only one hazardous event, there may be many
reasons for it to happen. There may be an error in the mathematical model,
the computational model, the weather function and so on. All these reasons
are put in the risk log as a separate post. By dividing the risks into smaller
pieces it is easier to identify critical program modules and focus on these
parts.
A few risks and appropriate actions to reduce them have already been
described throughout this paper. The warning messages mentioned in Section
5.3.4 is one way of reducing the risk of unintended damage to people or
other objects, but other risks require a more dedicated approach in order
to be reduced. Some of these risk reductions are explained in the following
sections.
39
6.2.1
Risk of faulty implementation of numerical method
One of the most obvious risks with the system is that the equation solver
has been wrongly implemented in the application and somehow returns the
wrong impact point from a firing solution. This could potentially lead to
shells landing far away from the designated target and damaging people or
property. Tables 2-5 show that three different numerical methods converge
to the same answer for a given firing solution. The Euler method does not
converge as quickly but seems to converge against the same value. This fact
strongly reduces the risk of a faulty equation solver, but there is of course
a very small probability that all tested equation solvers are implemented
improperly. This probability should however fall well within the accepted
risk.
6.2.2
Risk of faulty implementation of mathematical model
A slightly different risk leading to the same hazardous event is that the
actual acceleration model has been programmed in the wrong way. As there
is no known way of modeling the shell in another way and get the same
result, this has to verified in another way. As mentioned in Section 2.5 there
is already similar software available in Sweden today. An option could be
to use firing solutions to fire missions calculated by this software and then
run the same fire missions through this software. If the firing solutions from
the two independent programs agree with each other, at least within some
acceptable interval, it may be safe to assume that the acceleration model
is correct. The probability of both models having the same error in them
should be considered small.
Another option is to take the computer to an actual GRK m/84 and test
if the mortar can deliver shells to a target based on firing solutions from
the program. This test is very valuable if it is successful, since it actually
confirms that all trajectory related methods are in fact implemented as
intended.
6.2.3
Risk of corrupted files
The FCI-files are saved on separate files on the computers hard drive. As
hard drives are destined to fail sometime during their lifetime, sometimes
within a few years, it is possible that the system is run with a corrupted
FCI-file. This would most certainly lead to a hazardous event. Either the
whole program would crash when a computation is performed, leaving the
soldiers without firing solutions, or the corruption could lead to a datapoint
40
Figure 14: Two strings of text and their respective checksums represented in
hex code. Notice that even a small change completely alters the checksum.
being changed in the file so that a computation is executed with faulty
properties.
A standard way of reducing this risk is to create checksums for all files and
save them in a separate file. A checksum is a small block of data generated
from a checksum function. An array of bytes, a file, is sent to the checksum
function which returns a fixed length array of bits. The function is (usually)
invertible meaning that the file cannot be retrieved with the checksum, even
if the checksum function is known.
Checksums can be used to verify data integrity or data authenticity. In
this particular application it is data integrity that should be verified. Verifying
data authenticity requires more advanced checksums than for verifying data
integrity, but that is irrelevant here. For verifying data integrity only, a
simple 128 bit MD5 algorithm should suffice. The checksum function is not
interesting to study here, but two examples of MD5 results are presented in
Figure 14.
To reduce the risk of corrupt files, a separate file with previously evaluated
checksums of the FCI-files is added to the system. At startup, a new checksum
is produced for each FCI-file, and if they match the checksums stored in
the checksum file the program starts. If one checksum does not match the
user must be alerted of this somehow, but it is not sure that terminating the
program is the best option, as other functions of the software still may work.
As the MD5 checksum contains 128 bits, there are 2128 possible results
when running it. The probability of a corrupt file producing the same
checksum as the original should then be 2−128 , and thus the risk of undetected
corruptions should be reduced below any imaginable safety requirements.
41
7
Result
7.1
Search method
The convergence in the search method has been investigated for different
scenarios. It was found that Newton-Raphson’s method converged to within
1 meter of the target in under 5 iterations, even for the most extreme weather
conditions, but usually even less. A test was conducted where a fire mission
with a shooting range of 5 km was solved with -10◦ C temperature and a
wind of 40 m/s. The results are presented in Tables 6-9.
The search method is very fast when compared to the manual work of
using firing tables. A complete search for all firing solutions to a fire mission
finishes in a fraction of a second. If the user is able to create a firing mission
quickly the whole process of getting a firing solution should be much faster.
7.2
7.2.1
Tests against another artillery computer
Live exercise
On May 5th there was a live firing exercise at Markstridsskolan in Kvarn with
the GRK m/84. 80R and smoke shells were fired against targets designated
by a forward observer (located 30 meters away from the mortar location).
The distance to the targets never exceeded 2 km, which meant that only
charge 1 and 2 were tested.
The firing solutions were calculated by the current car mounted artillery
computer and the same firing missions were solved in the handheld computer.
The 80R results never deviated more than 1 mil in elevation from the artillery
computer’s firing solutions. The smoke shell results were not as accurate,
but sufficiently close to assume that the project is viable with more time.
The results for the smoke shells are presented in Table 10.
7.2.2
Additional tests
Additional tests for all 4 shell types have been carried out against previously
computed values from the current artillery computer. Ten targets were
selected at different distances from the battery location, and an appropriate
charge was determined for each of them, see Table 16. A firing solution was
then found by the artillery computer for each combination of target and shell
type. This test has been repeated with the software from this project. The
result of the comparison with the artillery computer’s results is shown in
Appendix D.
42
Table 6: Convergence of search method for northward wind of 40 m/s
Iteration Bearing (mils) Elevation (mils) Diff N (m) Diff E (m)
1
0.0
394.6
872.3
10.9
2
6398.4
523.4
-162.5
0.9
3
6398.1
505.8
-2.9
-0.1
4
6398.1
505.5
0.0
0.0
Table 7: Convergence of search method for eastward wind of 40 m/s
1
0.0
394.6
98.8
523.4
2
6294.3
405.1
-27.3
11.2
3
6292.7
400.7
-0.2
0.0
Table 8: Convergence of search method for southward wind of 40 m/s
1
0.0
394.6
-771.5
7.1
2
6398.0
261.1
-148.8
-1.8
3
6398.3
219.3
-14.9
0.0
4
6398.3
214.1
-0.3
0.0
Table 9: Convergence of search method for westward wind of 40 m/s
1
0.0
394.6
100.1
-505.3
2
102.2
405.1
-25.0
-10.7
3
103.7
401.0
-0.2
0.0
Table 10: The results from the smoke shell computations. The ArtComp
columns contain the values produced by the artillery computer that the
Swedish Armed Forces uses. The DSG rows show the values from the
handheld computer.
Target 1
1393 m
ArtComp
DSG
Diff
Bearing [mils]
1421
1421
0
Elevation [mils]
315
317
2
Burst time [s]
20.1
20.3
0.2
Target 2
1694 m
ArtComp
DSG
Diff
1212
1212
0
220
224
4
18.3
18.6
0.3
Target 3
1085 m
ArtComp
DSG
Diff
1545
1545
0
566
561
-5
23.6
23.6
0
Target 4
1084 m
ArtComp
DSG
Diff
1564
1564
0
566
561
-5
23.6
23.6
0
Figure 15: The view for registering targets. The position can be given in
either absolute or relative coordinates by pressing the coordinate switch in
the lower right part of the grey area.
7.3
GUI
The GUI has been successfully implemented in the handheld computer. The
following sections describe how the user navigates in order to complete some
of the common tasks the program can handle. As the GUI is in Swedish, the
reader may benefit from studying the glossary in Appendix E.
7.3.1
Registering a target
Targets, mortar locations, forward observers and RPs are registered in views
that look similar to each other. The views have a name field and a location
field to be filled in. The position can either be given as an absolute coordinate
in MGRS format or relative to an already registered location by pressing the
switch in the lower right corner of the position field. The target view also
has an RP selection for fire missions that associate a target with a previously
registered RP. The target is registered by pressing the “Register” button.
Figure 15 illustrates this view.
45
Figure 16: The view for registering a fire mission. The target and the shell
type are selected from lists. In the right image a Time To Fire order has
been set for 10:30.
7.3.2
Registering, solving and completing a fire mission
Once a target has been registered it is possible to register a fire mission. The
user enters a name for the fire mission and selects a registered target from a
list. The shell type is chosen from a separate list. A text field for the burst
height is enabled depending on the choice of shell type. If the explosive shells
are selected, i.e. the 80R or the 80Z shell, the field remains disabled. It is
also possible to set up a timed strike by checking the timed strike checkbox.
The user toggles between TOT and TTF by pressing a button and writes
the time into the text field. Figure 16 shows how a fire mission is registered.
To solve the fire mission the user switches to another view and selects
the fire mission and mortar location from their respective lists. The user also
enters the current temperature of the powder in the shell. The reason for this
field being in this view is that the powder temperature often varies quickly.
If some shells have been laying in the snow or in the sun for an extended
period of time, the operator can change the powder temperature and acquire
a new firing solution without registering a new fire mission. By pressing the
“Find solutions” button the search method is triggered. After a short while a
list of all possible firing solutions is shown. The user can examine the filght
46
Figure 17: The user finds a firing solution by selecting a fire mission, a
mortar location and a powder temperature. The possible firing solutions are
presented in a new window. By pressing a firing solution the user is taken to
a new view. Note the warning in the right image.
or burst time, the bearing and the elevation for each charge before choosing
a firing solution by pressing it. This process is illustrated in Figure 17.
Upon pressing a firing solution the user is taken to yet another view
which shows the current firing solution and any warnings, if there are any. In
the case of multiple warnings the two most important ones are shown based
on a priority system. If time on target is used a countdown is shown as well.
At the bottom of the view there are two buttons. One for adjusting fire, and
one for registering the target as an RP.
If the “Adjustment” button is pressed a dialog window is opened. The
user enters the observer direction, the width and the height adjustment. If
the current shell uses a burst height the option of adjusting it is enabled as
well. By pressing the “Adjust” button the adjustment is added to the fire
mission and a new firing solution for the same charge is found.
The “Register RP” button opens another dialog window. The total
adjustment of the fire mission is shown, and by entering a name and pressing
the “Register” button the user registers a new RP.
47
Figure 18: The user may adjust fire by pressing the Adjustment (sv. Reglering) button and entering the adjustment into the new window.
Figure 19: The user may register the fire mission as an RP by pressing the
Register RP button.
Figure 20: The METCM editor. When zones are entered new lines appear.
The first four zones from Figure 7 have been entered in the right image. The
relative humidity is entered in the bottom left text field.
7.3.3
Registering a METCM
A special editor for METCMs has been created in Android. The view features
four textfields at the top for the header of the message, and the first of them
has the mandatory METCM filled in. Then follows textfields for the body of
the message, where there is only one line available at first. Once the user
has filled in a line a new one appears under it. After the user has entered
the relative humidity, he or she presses the register button in the bottom
right corner to register the weather. Figure 20 illustrates this process.
49
8
8.1
Discussion
Numerical method for trajectory computations
It is concluded in Section 4.1.6 that the Runge-Kutta method is more than
accurate enough to solve the trajectory computation. It is shown that the
error in the distance is in the tens of µm, which of course is a ridiculous
precision considering that the lethal blast radius of the shells is at least 50
m, with some shrapnel possibly reaching over 100 m.
The irregular convergence of the Runge-Kutta method does not cause a
problem in this application, but it would be interesting to investigate why
this phenomenon occurs. As discussed in Section 4.1.5, it may be caused by
the non-differentiable junctions in the acceleration function. A search for
papers that report similar behaviors has been conducted, but so far nothing
relevant has been found.
It is interesting to note that the second order methods would be sufficient
to use instead of the Runge-Kutta method. If memory was an extremely
expensive resource in the hardware these methods could be used instead.
The midpoint method can even discard the Euler derivative and save the new
derivative at that memory address since only the second derivative is used
in the actual step forward, see Equation 22. There is, however, an excess of
memory available in this particular computer, so this does not have to be
considered for this project.
8.2
Search method
The multi-dimensional Newton-Raphson’s method was discovered early in the
project and was therefore implemented straight away in the search method
module. Although there are plenty of ways to solve this problem, this method
seems stable and fast enough to render any additional investigation obsolete.
The found firing solutions in Section 7.2.2 correspond fairly well with the
artillery computer’s, but not exactly. The two explosive shells, 80R and 80Z,
are mostly correct within 2 mils, with only one exception of 3 mils.
The two shells with burst height, the smoke shell and the illumination
shell, are slightly worse. Elevation angles often differ by 4 mils, and one
outlier differs by 13 mils. It seems strange that one firing solution would
differ much more than all others, but the explanation is probably that the
target is far away for such a low charge. The underlying error is possibly
magnified when the elevation angle is low.
50
One should consider that a mil is a relatively small unit and that the
resulting change in range varies with the elevation angle. The range is
affected more if the elevation angle is high, see Figure 10 at page 28. The
two firing solutions with the highest elevation angles never differ more than
2 mils from the artillery computers firing solutions. This would correspond
to a difference of about 10 meters or less. This is an acceptible difference
considering that the way the other artillery computer is implemented is
unknown.
8.3
GUI
Android has performed as expected and there is virtually no lag in the GUI
when using the software. The application uses a clean and simple layout,
which hopefully is preferred to “flashy” animations and other features which
are common in social apps. The software has however not been tested by
actual soldiers. Such a test would give valuable opinions on what could be
changed to improve the GUI and make it even more comprehensive.
8.4
Future work
There is a lot of work left to do before considering this software a finished
product. As an example, it seems like the ballistics core has to be tuned a
bit to produce the same result as existing artillery computers. The software
should also be tested more extensively than what it has been so far.
There are also many required functions that have not been implemented
yet. A map to visualize the registered locations would help the operator and
assure him or her that the locations have been registered correctly. There
should also be a night mode available for the GUI which minimizes light
emitted from the screen.
As the Swedish Armed Forces have shown interest in the product, these
problems and many more will be investigated further in the future.
8.5
Conclusion
The ultimate goal of this thesis work was to prove that it is possible to create
a program on a portable unit that replaces the methods that are used by the
Swedish Armed Forces for mortar usage today. A proof of concept has been
developed and tested against existing software. The tests seem to indicate
that the project has been a success and that the developed software can be
used as a foundation for a more advanced version.
51
9
Acknowledgement
I have a lot of people to thank for making this thesis possible. It has been a
true pleasure to work with each and every one of them, and I am looking
forward to continue working with them in the future. So, without further
ado, I would like to express my greatest gratitude to
Olov Wilander, my supervisor, who have supported me throughout this
thesis work with invaluable knowledge of computational methods, mathematical aspects, proper thesis writing customs and much more. Our regular
Friday afternoon meetings have been a keystone in this sometimes confusing
but persistently enjoyable project.
Stefan Sandén, my “second” supervisor and go-to-hacker, who always
seems to have an answer when my code is acting up. Having an experienced
programmer next door has saved me more times than I dare count.
Lennart Öhman, my project manager, for proposing this project and then
guiding me through it. Taking me to the headquarters of the Swedish Defence
Materiel Administration and multiple live firing exercises has made this thesis
work even more delightful.
Maud Holma von Heijne, my boss, who made the decision to take me in
at Sjöland & Thyselius in my oddysey to find a suitable thesis work and has
been supportive ever since.
Lars Kron at Markstridsskolan, Kvarn, for showing me how to find firing
solutions without an artillery computer and sharing his expert knowledge of
how a mortar is used.
Ken Mattson at the Department of Information Technology at Uppsala
University, for examining my work and helping me with my numerical methods.
Last, but not least, I would like to thank all the people at Sjöland &
Thyselius who I have had the pleasure of meeting during this spring. Movie
nights, boat trips, jam sessions and a conference in Berlin has made me feel
more welcome than I could ever hope for.
52
References
[1] Hairer E., Nørsett S. P., Wanner G., Solving Ordinary Differential Equations I, 2nd revised edition, Springer, Berlin, 2000.
[2] Press W. H., Teukolsky S. A., Vetterling W. T., Flannery B. P., Numerical
Recipes, 3rd edition, Cambridge University Press, New York, 2007.
[3] Försvarets Materielverk, SkjutR Art Grk (Skjutreglemente för artilleri
och granatkastare), Citec Information AB, 2007, M7739-353005.
[4] Försvarets Materielverk, H SystSäk (Handbok för Systemsäkerhet), Fälth
& Hässler, Värnamo, 2011, M7739-352022.
[5] NATO, STANAG 4082 - Adoption of a standard artillery computer
meteorological message, 2nd ed., 1969.
[6] NATO, STANAG 4355 - The modified point mass and five degrees of
freedom trajectory models, 3rd ed., 2009.
[7] ISO, ISO 2533 - Standard Atmosphere, 1st ed., 1975.
[8] U.S. Army ARDEC, Database Design Specification for the NATO Armaments Ballistic Kernel (Release 10.0), Version 5.4, 2008.
[9] NASA, Humidity, retrieved from
http://atmos.nmsu.edu/education and outreach/encyclopedia/humidity.htm
2015-08-20, webpage updated 2015-07-15.
[10] John H. Mathews, NUMERICAL METHODS: MATLAB Programs,
Prentice Hall, New Jersey, 1995.
53
Appendices
A
Terminology
This section explains the most fundamental mortar related terms used in
this thesis.
Mils Mils are the standard way of measuring angles in the Swedish Armed
Forces. There are 6400 mils in a full rotation, meaning that one mil is equal
to 0.05625◦ . A mil is roughly equal to a milliradian, and thus a cone with
one mil’s width is about a meter wide one kilometer away.
Elevation angle The elevation angle, or simply elevation, represents the
angle between the ground and the barrel of the mortar. The Swedish Armed
Forces define an elevation angle of 0 mils as 700 mils from the ground, which
means that an elevation angle of 900 mils results in 1600 mils, i.e. the barrel
pointing straight up. In this way all elevation angles can be given with three
digits, (mortars are never fired with an angle lower than 800 mils between
the barrel and the ground).
Bearing
The bearing is the compass direction in which the barrel is pointed.
Shell The projectile that is fired from a mortar is called a shell. The shells
can have different functions, which are explained further in Section 2.2.
Charge Although charge can refer to a variety of things in this context,
it is the propulsion clip attached to a shell that is implied. The propulsion
clips build additional pressure at launch, causing the muzzle velocity of the
shell to increase. As an example, charge 3 means that three propulsion clips
should be attached to the shell before launch.
Fire mission A fire mission is sent to the mortar operator whenever the
mortar should be used. The fire mission states a target and the shell type
that should be used. The number of shells to be fired and time requirements
may also be specified.
Firing solution A firing solution is a collective name for the bearing,
elevation, shell type and charge needed to complete a fire mission.
54
Registration point A registration point (RP) is a way of countering
errors in the strategic material that is available. If multiple firing solutions
result in similar misses there may be reason to believe that a consistent error
is present in the weather report, position designator equipment or something
else. The deviation from the target can then be registered as an RP and
subsequent fire missions can be adjusted before the first shell is launched.
FCI file Fire Control Input files (FCI files) are formatted database files
that describe ballistic properties of weapon systems. The files come in plain
text format in order to be valid on all platforms. One FCI file may define the
ballistic properties of a single projectile only. If there are several projectiles
available for a weapon system there should be one FCI file per projectile.
Time On Target A Time On Target (TOT) order is issued if the first
shell in a strike should detonate on a specific time of day, followed by more
shells.
Time To Fire A Time To Fire (TTF) order is issued if the last shell in a
strike should detonate on a specific time of day. It should be safe to move
into the target area after the specified time.
55
B
State graphs of trajectory
The state of the differential equation (see Equation 18) and the corresponding
acceleration for a 6000 meter shot is shown in Figures 21-23. The bearing of
this shot is 0000, and the z component has therefore been excluded in all
graphs. The Corliolis effect is too small to give interesting curves in any of
the graphs, and there are no other forces that act in the z direction.
x component
y component
Position [m]
6,000
4,000
2,000
0
0
5
10
15
20
Time [s]
25
30
35
40
Figure 21: The position components over time in a 6000 meter shot.
56
Velocity [m/s]
200
100
0
−100
x component
y component
−200
0
5
10
15
20
Time [s]
25
30
35
40
Figure 22: The velocity components over time in a 6000 meter shot.
Acceleration [m/s2 ]
0
−5
−10
−15
−20
x component
y component
0
5
10
15
20
Time [s]
25
30
35
40
Figure 23: The acceleration components over time in a 6000 meter shot.
C
Runge Kutta convergence for different state components
In Section 4.1.5 it was discovered that the Runge Kutta method shows an
oscillating convergence for decreasing step sizes. Tables 11-14 and Figures
24-27 show this phenomenon in four state components. The z component of
the position and velocity has been left out. All graphs are plotted from the
same shot.
58
Table 11: The approximate error of the Runge Kutta method in the x
component of the position.
h (s)
Error (m)
E(h)
E(h/2)
20
-1.95·10−5
-3.13
2−1
6.24·10−6
-3.70
2−2
-1.68·10−6
-5.57
2−3
3.02·10−7
-2.10
2−4
-1.44·10−7
-7.26
2−5
1.98·10−8
3.30
2−6
6.01·10−9
-4.66
2−7
-1.29·10−9
-1.34
2−8
9.65·10−10
1.68
2−9
5.75·10−10
*
·10−5
Error [m]
0
−1
−2
20
2−1
2−2
2−3 2−4 2−5 2−6
Step length h [s]
2−7
2−8
2−9
Figure 24: The convergence of the Runge Kutta method for the x component
of the position.
Table 12: The approximate error of the Runge Kutta method in the y
component of the position.
h (s)
Error (m)
E(h)
E(h/2)
20
4.48·10−5
6.26
2−1
7.15·10−6
-149.90
2−2
-4.77·10−8
-0.19
2−3
2.49·10−7
-2.11
2−4
-1.18·10−7
-8.42
2−5
1.40·10−8
4.01
2−6
3.50·10−9
-2.17
2−7
-1.61·10−9
-5.20
2−8
3.10·10−10
1.88
2−9
1.65·10−10
*
·10−5
Error [m]
4
3
2
1
0
20
2−1
2−2
2−3 2−4 2−5 2−6
Step length h [s]
2−7
2−8
2−9
Figure 25: The convergence of the Runge Kutta method for the y component
of the position.
Table 13: The approximate error of the Runge Kutta method in the x
component of the velocity.
h (s)
Error (m)
E(h)
E(h/2)
20
-1.89·10−6
-4.13
2−1
4.57·10−7
-1.96
2−2
-2.33·10−7
-14.47
2−3
1.61·10−8
-2.34
2−4
-6.89·10−9
-5.71
2−5
1.21·10−9
2.91
2−6
4.14·10−10
-13.50
2−7
-3.06·10−11
-0.48
2−8
6.34·10−11
2.48
2−9
2.55·10−11
*
·10−6
0.5
Error [m]
0
−0.5
−1
−1.5
−2
20
2−1
2−2
2−3 2−4 2−5 2−6
Step length h [s]
2−7
2−8
2−9
Figure 26: The convergence of the Runge Kutta method for the x component
of the velocity.
Table 14: The approximate error of the Runge Kutta method in the y
component of the velocity.
h (s)
Error (m)
E(h)
E(h/2)
20
-6.10·10−7
-15.22
2−1
4.00·10−8
0.39
2−2
1.04·10−7
8.93
2−3
1.16·10−8
-1.76
2−4
-6.61·10−9
-11.44
2−5
5.78·10−10
5.45
2−6
1.06·10−10
-0.92
2−7
-1.15·10−10
-20.50
2−8
5.60·10−12
0.58
2−9
9.65·10−12
*
·10−7
Error [m]
0
−2
−4
−6
20
2−1
2−2
2−3 2−4 2−5 2−6
Step length h [s]
2−7
2−8
2−9
Figure 27: The convergence of the Runge Kutta method for the y component
of the velocity.
D
Comparison of artillery computers
The computational core has been compared against the current artillery
computer. Firing solutions were sought for ten targets for each shell type.
The targets are listed in Table 16. The comparisons for each shell are listed
in Table 17-20.
Table 15: The mortar location used in the tests.
Mortar Easting Northing Height [m]
1
Target
47 2887
649 3458
103
Table 16: The targets used in the tests.
Easting Northing Distance [m] Height [m]
Charge
1
47 4380
649 3850
1544
103
1
2
47 6160
649 4320
3385
103
3
3
47 8430
649 4800
5703
103
6
4
47 4860
649 3970
2038
103
2
5
47 6300
649 4300
3515
103
4
6
47 7420
649 4600
4675
103
6
7
47 6890
649 4470
4129
103
5
8
47 6910
649 4540
4166
103
5
9
47 4150
649 3770
1301
103
2
10
47 5050
649 4040
2240
103
4
63
Target
Table 17: Comparison of bearing, elevation and flight time against the
artillery computer for the 80R shell.
Bearing [mils] Difference [mils] Elevation [mils] Difference [mils] Flight time [s]
Difference [s]
1
1337
0
285
0
21.9
0.0
2
1336
0
318
2
34.5
0.1
3
1356
0
332
-3
46.8
-0.1
4
1340
0
472
1
31.6
0.0
5
1351
0
472
2
42.4
0.0
6
1346
0
482
-1
50.4
-0.1
7
1345
0
480
0
47.0
0.0
8
1330
0
475
0
46.9
0.0
9
1352
0
649
0
33.5
0.0
10
1330
0
651
1
45.0
0.0
Table 18: Comparison of bearing, elevation and flight time against the
artillery computer for the 80Z shell.
Bearing [mils] Difference [mils] Elevation [mils] Difference [mils] Flight time [s]
Difference [s]
Target
1
1337
0
232
0
20.7
0.0
2
1336
0
280
2
33.2
0.0
3
1356
0
281
0
44.5
0.0
4
1340
0
447
0
30.7
0.0
5
1351
0
448
1
41.3
0.1
6
1346
0
455
0
48.9
0.0
7
1345
0
457
2
45.7
0.1
8
1330
0
451
2
45.6
0.1
9
1352
0
637
0
32.8
0.0
10
1330
0
640
1
44.2
0.1
Table 19: Comparison of bearing and elevation against the artillery computer
for the smoke shell. A * means that a firing solution could not be found.
Target Bearing [mils] Difference [mils] Elevation [mils] Difference [mils]
1
1337
0
362
2
2
1336
0
327
-5
3
*
*
*
*
4
1340
0
493
-3
5
1351
0
456
-3
6
1346
0
397
-3
7
1345
0
435
-1
8
1330
0
429
-2
9
1352
0
661
-2
10
1330
0
644
-1
Table 20: Comparison of bearing and elevation against the artillery computer
for the illumination shell. A * means that a firing solution could not be
found.
Target Bearing [mils] Difference [mils] Elevation [mils] Difference [mils]
1
*
*
*
*
2
1336
0
299
4
3
1356
0
213
-13
4
1340
0
458
2
5
1351
-1
456
2
6
1346
0
433
-4
7
1345
0
453
-4
8
1330
0
447
-4
9
1352
0
645
0
10
1330
0
645
1
E
Glossary
English
Swedish
Adjustment
Reglering
Bearing
Bäring
Elevation angle
Elevationsvinkel
Fire mission
Elduppdrag
Firing solution
Skjutlösning
Registration point (RP)
Utgångspunkt (UP)
Shell
Granat
Time On Target
Fråntidsskjutning
Time To Fire
Tilltidsskjutning
66

Development_of_a_Digital_Mortar_Aiming_System

Transcription

Similar documents

REMOTE FIRING PLATFORM

The M198 Howitzer - Bps

to learn about our values and mission to support

How to use a pestle and mortar

AMERICAN AIRLINES CENTER American Airlines Center is a multi

` A S H B O R O U G H `

Shell is recruiting...

Repair Mortar LM-1100

Document 6576697

Document 6493468