Development of a Digital Mortar Aiming System

(1)

UPTEC F 15061

Examensarbete 30 hp 22 September 2015

Development of a Digital Mortar Aiming System

Oskar Wåglund

(2)

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

Hemsida:

http://www.teknat.uu.se/student

Abstract

Development of a Digital Mortar Aiming System

Oskar Wåglund

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.

(3)

Popul¨ arvetenskaplig sammanfattning

I väpnad strid är det vanligt att b˚ada de stridande sidorna utnyttjar artilleri för att skaffa sig taktiska fördelar mot sina fiender. Ett vanligt förekommande vapen är d˚a s˚a kallade granatkastare, som skjuter iväg granater i hög bana mot identifierade fiendetrupper eller byggnader. Hur l˚angt granaten färdas beror p˚a hur soldaterna vinklar eldröret, och för att träffa det önskade m˚alet m˚aste de hitta precis rätt vinkel. En grad för högt eller l˚agt innebär oftast att m˚alet inte ens p˚averkas av granaten.

Försvarsmakten har tv˚a typer av granatkastare, varav den mindre ofta används i s˚a kallade jägaroperationer. Begreppet innebär att soldaterna som manövrerar granatkastaren ständigt m˚aste röra sig för att inte bli inringade av fiender. Med begränsad utrustning m˚aste de snabbt kunna hitta rätt eldrörsvinkel och avfyra en salva granater innan de rör sig till nästa plats.

D˚a datorer är för otympliga för att bära med sig s˚a använder soldaterna skjuttabeller med uträknade vinklar för vissa avst˚and. Att sl˚a i tabellerna

¨

ar en l˚angsam process och kr¨aver samtidigt en stor sinnesn¨arvaro fr˚an den stressade soldaten.

I det här examensarbetet har en prototyp av en portabel artilleridator tagits fram i samarbete med Försvarets Materialverk (FMV). Artilleridatorns syfte är att finna s˚a kallade skjutelement, vilket är benämningen för de vinklar som behövs för att träffa ett givet m˚al. En beräkningskärna har programmerats fr˚an grunden för att kunna simulera en granats flykt genom luften. Kärnan har sedan knutits ihop med ett användargränssnitt p˚a en handdator anpassad för militärt bruk. Enheten har testats tillsammans med FMV p˚a en skjutövning där det visade sig att beräkningskärnans simuleringar stämde väl överens med en verklig granat.

1

(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

(8)

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

(9)

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

(10)

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.

(11)

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

(12)

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.

(13)

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.

(14)

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.

(15)

Figure 7: A typical METCM.

(16)

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

F~_G= m~g = −mg₀(R²/r³)~r = −mg₀







X1

R

1 −^2X_R²

X3

R





. (1)

Due to the earth not being perfectly round, the magnitude of the gravitational force, g0, will vary with latitude according to

g₀ = 9.80655(1 − 0.0026 cos(2lat)). (2)

(17)

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

F~C = m~Λ = −2m(~ω × ~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

F~_D = − πρd² 8

C_D₀v~v. (5)

where ~v = ~U − ~w represents the velocity of the projectile relative to the surrounding air.

The air density ρ varies with pressure and temperature according to ρ = 1

T(p_d R_d + p_v

R_v) (6)

The partial vapor pressure p_v is calculated as

p_v= φ · 610.78 · 10^237.3+T^7.5·T (7) and the partial dry air pressure is then calculated as the remainder of the total pressure

p_d= p − p_v. (8)

The partial pressure model is not included in the NABK, but is taken from NASA [9].

15

(18)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 0.12

0.14 0.16 0.18 0.2 0.22 0.24 0.26 0.28

Mach number CD0

Figure 8: The CD 0 curve for the 80R shell.

Finally, the drag force depends on the factor C_D₀. 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.

C_D₀ = b₀+ b₁M + b₂M²+ b₃M³ (b_min < M < b_max) (9)

(19)

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

X ~F = md ~U

dt . (10)

Adding the forces together and dividing both sides by the mass yields d ~U

dt = 1

m( ~F_G+ ~F_C + ~F_D). (11) The initial values are defined by the muzzle position

X~0 =







l_W cos(QE) cos(AZ) X2W + lWsin(QE) l_W cos(QE) sin(AZ)





 (12)

and the muzzle velocity

U~₀=







u₀cos(QE) cos(AZ) u0sin(QE) u₀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 y_T. 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 T_b, ground level pressure p_b and the ground level height above sea level H_b. 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) = T_b+ β(H − H_b). (14)

17

(20)

The pressure relation is less trivial.

p(H) = p_b

1 + β

T_b(H − H_b)

− g

βR (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.

(21)

Table 1: Notations used in mathematical formulae m Projectile mass

d Projectile diameter

X~ Projectile position relative to ground fixed coordinate system X~0 Muzzle position relative to ground fixed coordinate system U~ Projectile velocity 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 Coriolis acceleration

~

ω The rotational vector of earth Ω The angular velocity of earth lat Latitude

CD0 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 R_v The specific gas constant of water vapor R_d The specific gas constant of dry air p_v The partial water vapor pressure p_d The partial dry air pressure

β Temperature lapse rate for increasing altitude φ The relative humidity

(22)

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 Calculating a trajectory 4.1.1 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

~¨

x = A( ˙~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.

(23)

˙

u_x= A_x((x_x, x_y, x_z), (u_x, u_y, u_z))

˙

u_y = A_y((x_x, x_y, x_z), (u_x, u_y, u_z))

˙

u_z= A_z((x_x, x_y, x_z), (u_x, u_y, u_z))

˙ xx= ux

˙ xy = uy

˙ xz= uz

(18)

The six variables x_x, x_y, x_z, u_x, u_y, u_z 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⁰(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 = t_n+1− t_n. 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

k₁ = f (t, y_n)

y_n+1 = y_n+ hk₁. (20)

21

(24)

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

k₁ = f (t, y_n)

k₂ = f (t + h, y_n+ hk₁) yn+1= yn+h

2(k1+ k2).

(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) k₂ = f (t +h

2, y_n+ h 2k₁) y_n+1= y_n+ hk₂.

(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

k₁ = f (t, y_n) k2 = f (t +h

2, yn+h 2k1) k₃ = f (t +h

2, y_n+h 2k₂) k4 = f (t + h, yn+ hk3)

h

(23)

(25)

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⁻²⁰, 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) = Chⁿ (24)

23

(26)

2⁻⁹ 2⁻⁸ 2⁻⁷ 2⁻⁶ 2⁻⁵ 2⁻⁴ 2⁻³ 2⁻² 2⁻¹ 2⁰

−2

−1.5

−1

−0.5 0 0.5

·10⁻⁵

Step size h[s]

Error[m]

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 x_y, u_x 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¹ smooth. As mentioned in Section 3.4, the C_{D 0}function is given as a piecewise polynomial function, and for the shells used by the Swedish Armed Forces the CD 0 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.

(27)

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.

~

xT = T ( ~x0, ~u0) (25) The error in an impact point can thus be described as

D( ~x0, ~u0) = |T ( ~x0, ~u0) − ~xT∗| (26) where ~x_T^∗ is the target. This means that solving the equation

D( ~x₀, ~u₀) = 0 (27)

25

(28)

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) − ~xT∗| (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 x_{T x} and x_{T z} and then solve the resulting system of equations

x_{T x}(AZ, QE) = x^∗_{T x}

x_{T z}(AZ, QE) = x^∗_{T z}. (30) 4.3 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 hand side can be summarized as a vector ~X. The objective of this problem 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

J_ij = δFi

δv_j. (32)

As analytical derivatives rarely are available for these types of problems, the Jacobian is usually approximated with additional function evaluations as

δF F(v , ..., v + ∆v , ...) − F(v , ..., v , ...)

(29)

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.

H(~~ v) = ~X − ~F (~v) = ~0 (34) The system can now be solved iteratively with the algorithm

J · ~vδ= −H( ~vk)

~

v_k+1 = ~v_k+ ~v_δ (35)

Note that the first step requires the inverse of the Jacobian to acquire ~v_δ and that an initial guess is needed for ~v₀. The iteration is ended when a sufficiently small ~H(~v) is obtained.

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 x

δQE δxT z

δAZ δ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

J⁻¹= 1

|J |

δxT z

δQE −^δx_δQE^{T x}

−^δx_δAZ^{T z} ^δx_δAZ^{T x}

!

. (37)

27

(30)

100 200 300 400 500 600 700 800 900 0

1,000 2,000 3,000 4,000 5,000 6,000

Elevation [mils]

Range[m]

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.

(31)

Table 2: Euler’s method

h [s] Distance [m] T [s] Absolute error [m] _E(h/2)^E(h)

2⁰ 1722.18206 20.0 -4.85·10⁰ 1.98

2⁻¹ 1719.78969 20.0 -2.45·10⁰ 1.99 2⁻² 1718.57106 20.0 -1.23·10⁰ 1.99 2⁻³ 1717.95583 20.0 -6.19·10⁻¹ 2.00 2⁻⁴ 1717.64669 20.0 -3.10·10⁻¹ 2.00 2⁻⁵ 1717.49174 20.0 -1.55·10⁻¹ 2.00 2⁻⁶ 1717.41417 20.0 -7.76·10⁻² 2.00 2⁻⁷ 1717.37536 20.0 -3.88·10⁻² 2.00 2⁻⁸ 1717.35595 20.0 -1.94·10⁻² 2.00

2⁻⁹ 1717.34624 20.0 -9.71·10⁻³ *

Table 3: Heun’s method

h [s] Distance [m] T [s] Absolute error [m] _E(h/2)^E(h)

2⁰ 1717.24158 20.0 9.50·10⁻² 4.10

2⁻¹ 1717.31334 20.0 2.32·10⁻² 4.04 2⁻² 1717.33080 20.0 5.73·10⁻³ 4.03 2⁻³ 1717.33511 20.0 1.42·10⁻³ 4.01 2⁻⁴ 1717.33618 20.0 3.55·10⁻⁴ 4.01 2⁻⁵ 1717.33644 20.0 8.86·10⁻⁵ 4.00 2⁻⁶ 1717.33651 20.0 2.21·10⁻⁵ 4.00 2⁻⁷ 1717.33652 20.0 5.54·10⁻⁶ 4.00 2⁻⁸ 1717.33653 20.0 1.38·10⁻⁶ 3.99

2⁻⁹ 1717.33653 20.0 3.46·10⁻⁷ *

(32)

Table 4: The midpoint method

h [s] Distance [m] T [s] Absolute error [m] _E(h/2)^E(h) 2⁰ 1717.39159 20.0 -5.51·10⁻² 3.75 2⁻¹ 1717.35121 20.0 -1.47·10⁻² 3.87 2⁻² 1717.34032 20.0 -3.79·10⁻³ 3.95 2⁻³ 1717.33749 20.0 -9.60·10⁻⁴ 3.96 2⁻⁴ 1717.33677 20.0 -2.42·10⁻⁴ 3.99 2⁻⁵ 1717.33659 20.0 -6.06·10⁻⁵ 3.99 2⁻⁶ 1717.33655 20.0 -1.52·10⁻⁵ 3.99 2⁻⁷ 1717.33653 20.0 -3.81·10⁻⁶ 4.01 2⁻⁸ 1717.33653 20.0 -9.50·10⁻⁷ 4.00

2⁻⁹ 1717.33653 20.0 -2.37·10⁻⁷ *

Table 5: RK4

h [s] Distance [m] T [s] Absolute error [m] _E(h/2)^E(h) 2⁰ 1717.33655 20.0 -1.95·10⁻⁵ -3.13 2⁻¹ 1717.33652 20.0 6.24·10⁻⁶ -3.70 2⁻² 1717.33653 20.0 -1.68·10⁻⁶ -5.57 2⁻³ 1717.33653 20.0 3.02·10⁻⁷ -2.10 2⁻⁴ 1717.33653 20.0 -1.44·10⁻⁷ -7.26 2⁻⁵ 1717.33653 20.0 1.98·10⁻⁸ 3.30 2⁻⁶ 1717.33653 20.0 6.01·10⁻⁹ -4.66 2⁻⁷ 1717.33653 20.0 -1.29·10⁻⁹ -1.34 2⁻⁸ 1717.33653 20.0 9.65·10⁻¹⁰ 1.68

2⁻⁹ 1717.33653 20.0 5.75·10⁻¹⁰ *

(33)

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

AZ,QE D(AZ, QE) (38)

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

(34)

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 com- municating 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.

(35)

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

(36)

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

(37)

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

(38)

(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.

(39)

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

(40)

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 HSystS¨ak [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

(41)

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

(42)

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

(43)

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 2¹²⁸ possible results when running it. The probability of a corrupt file producing the same checksum as the original should then be 2⁻¹²⁸, and thus the risk of undetected corruptions should be reduced below any imaginable safety requirements.

41

Development of a Digital Mortar Aiming System

Examensarbete 30 hp 22 September 2015

Development of a Digital Mortar Aiming System

Oskar Wåglund

Abstract

Development of a Digital Mortar Aiming System

Popul¨ arvetenskaplig sammanfattning

Contents

1 Introduction

2 Mortar usage

3 Mathematical model

4 Computation

5 Development

6 System safety