Relatorio Ingles

Simulation and Conceptions for the

Development of a Control System for

the Positioning of an Oil Platform

cand. el. Burkhard Sommer

Matrikel-Nr.: 2005171

7th April 2005

Contents

1. Introduction 4

2. Simulation 6

2.1. The Platform P-13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1. The non-linear Model . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2. Transformation of the coordinates . . . . . . . . . . . . . . . . . . 10

2.1.3. The linearized Model . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. Optimal distribution of the control variable 15

3.1. LAGRANGEn Multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1. Realization of the optimization . . . . . . . . . . . . . . . . . . . 17

3.1.2. Adaptation to the real conditions . . . . . . . . . . . . . . . . . . 20

3.1.3. Influence of the Delays . . . . . . . . . . . . . . . . . . . . . . . . 21

4. Perturbations 25

4.1. Simulation of the Waves . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5. Controlling 31

5.1. PID Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2. PID in the platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3. Numeric Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.4. Iterative Feedback Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.5. Design of a digital controller with IFT . . . . . . . . . . . . . . . . . . . 38

5.6. Controller Parameters with IFT . . . . . . . . . . . . . . . . . . . . . . . 40

5.7. Optimization via Matlab Response Optimization Toolbox . . . . . . . . . 40

5.8. Controlling via LQR/LTR and Fuzzy . . . . . . . . . . . . . . . . . . . . 43

2

Contents

6. Soft- and Hardware Implementation 46

6.1. The Microcontroller Board Rabbit RCM 3200 . . . . . . . . . . . . . . . 46

6.2. The Microcontroller ATMEL Mega64 . . . . . . . . . . . . . . . . . . . . 48

6.3. The Serial Communication Interface . . . . . . . . . . . . . . . . . . . . . 48

6.3.1. Low-Level Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.3.2. High-Level Kommunikation . . . . . . . . . . . . . . . . . . . . . 50

6.4. Alternative Communication Method . . . . . . . . . . . . . . . . . . . . . 52

6.5. Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7. Conclusion 54

A. The Matlab M-Files 55

A.1. Source Code Optimization via Lagrange (Propsim.m) . . . . . . . . . . . 55

A.2. Source Code (Propkonfsim.m) . . . . . . . . . . . . . . . . . . . . . . . . 57

A.3. Source Code Generation of Waves (wave02bs.m) . . . . . . . . . . . . . . 60

A.4. Source Code propdir.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A.5. Source Code itfdisc.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

B. Matlab Fuzzy Functions 66

C. Communication 68

C.1. Source Code Avr p13.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

C.2. Configuration of der Registers: . . . . . . . . . . . . . . . . . . . . . . . . 79

3

1. Introduction

The institute of controlling of the University of Rio de Janeiro has obtained a model of

the oil platform P13 from the company Petrobras for studying proposes (1:40). Some

studies should be done concerning the controllability of it with the intention to create

a simulation in order to design and test a positioning control, which should on the

one hand take the platform to a determined target position and on the other hand

to keep the platform on a determined position. This requires an active positioning

control, also within aggravating conditions due to a turbulent swell. A design also

should take some economical proposes in consideration that takes account of the usage

of the propellers and fuel consumption. As much tests as possible should be performed

in order to reduce the costs by using computer simulations. This, on the other hand,

requires the best knowledge of the platform model that is possible. The simulation

implementation should be the main part of this work. The mathematical models should

be put into a Mathworks Matlab and Simulink Simulation. A mathematical model is

already available. An institute of the Netherlands did already some tests that can be used

for this actual work. A simulation also has to include, in addition to the mathematical

platform model, an environment model in order to simulate the perturbations which

affect the platform, a model of the drive propulsion system, which includes physical

limitations like finite rotation velocities and limited run up speed of the propulsion

system. By using all of these parameters, a project of a suitable controller can be made

with this simulation. After these tests, it would be possible to implement the developed

algorithms in microcontrollers in order to simulate its behavior using the physical model.

These microcontrollers should control the platform’s engines in order to maneuver the

platform. For as much it, is not the objective of this project to design the perfect

controller. This would be too extensive. It’s more important to find out how one should

process in general, to program a simulation and to think about the available ways to

realize a hardware and software implementation for the model. Because of that my

work is separated into the following parts: Design of a Simulation with Matlab and

4

Simulink. This is explained in the second chapter. The integration and an optimization

of the propulsion system in the simulation can be found in the third chapter. The

simulation of the perturbations can be found in the fourth chapter. A design of some

controllers can be found in the fifth chapter. Some methods concerning a hard- and

software implementation are described in the last chapter.

Figure 1.1.: Model of the platform 1:40

5

2. Simulation

In order to realize the software simulation I use Matlab and Matlab Simulink. This

software is a relatively easy-to-use tool which is already very important for the whole

engineering industry. It offers a great amount of different toolboxes and libraries and

could be handled intuitively. In the case of Simulink the elements can be dragged

and dropped using a block diagram structure, similar to structures which are common

and frequently used in the control engineering. Starting with simple blocks like gains,

integrators, derivatives, saturation and mathematical signs and up to blocks of highest

complexity can be put, like microprocessor simulating blocks. It’s also possible to create

new blocks based on the principle of ”Black-Box”. When a block is ready, it is possible

to let only the inputs and outputs visible. Using this kind of hierarchy, very complex

and complicated systems can be designed, calculated and simulated. That mentioned

hierarchy I would like to use to realize my simulation, too. In the present case I need one

block for the platform, one for the perturbations, one or more blocks for the propulsion

and optimization system, one control system block and some additional blocks like the

Virtual Reality Toolbox to visualize in 3D the behavior of the platform. A graphical

visualization is always useful just to get a better feeling for the system response and can

be used for presentation proposes and will be realized with VRML and will be included,

too.

2.1. The Platform P-13

The platform P-13 of the company Petrobras is a platform of an older type. It has

been built in the year 1983 by the consortium UIE-CFEM in France and was actually

designed to make bore holes up to 8000 meters while anchored. The platform consists of

two swimmers, each of it are separated into three vertical columns. Four of these can be

used to store solid materials. Diagonal braces join the lower part of the structure with

the center of the deck. In the year 1993 the idea to convert the platform in a production

6

2.1. THE PLATFORM P-13

unit with a dynamic positioning control system has been born. This project is based on

that idea. There are already some measurements, parameters and equations available

which had been made by an institute from the Netherlands and which are used in this

work. Some technical of the platform specifications are following:

Figure 2.1.: Simulink Complete System

7


Specifications and Dimensions

Constructor UIE-CFEM Konsortium

Harbor of registration Monrovia, Liberia

Company BV

Launching 1983

Length 92 m

Width 74.824 m

Distance from keel to main deck 41 m

Swimmer

Length 92 m

Width 19.824m

Depth 6.1 m

Distance propeller mid point to keel 3.21 m

Columns

Diameter 9.4 m

Diameter with base 13 m

Braces

Diameter 2 m

Length 42 m

Height in relation to keel 11.2 m

Weight 34865 t

On order to begin with a project of the simulation it is necessary to put the mathemat-

ical model into the Simulink Simulation. The best way is to convert the mathematical

equations into a form which is easier to handle and implement. In the given case there

are a set of nonlinear differential equations with a lot of parameters. Because of this

nonlinearity of the equations it is not possible to implement them into a state-space-

8


format. The best format in would be a block diagram. The advantage of this display

format is the better overview and feasibility. Like it is explained in [8], the differential

equations can be converted into this form as follows. Let’s suppose a linear second order

equation of the following form.

mx + bx + cx = F (2.1)

x =1

m(F − bx− cx) (2.2)

This equation can be converted (see [6]), putting the variable of the highest degree of

derivative to the left side considering the relation∫

x dt = x and∫

x dt = x.

Figure 2.2.: PT2-System

Using this principle all of this non-linear, coupled differential equations can be put easily

into the Simulink model.

2.1.1. The non-linear Model

The non-linear mathematical model with its parameters that have been provided by a

the institute from the Netherlands [8]:

(M + a11)u− (M + a22)vr + b(1)11 + b

(2)11 u|u|+ c11x = XT + XE (2.3)

(M + a22)v − (M + a11)ur + b(1)22 + b

(2)22 v|v|+ c22y = YT + YE (2.4)

(Izz + a66)r + b(1)66 r + b

(2)66 r|r|+ c66φ = NT + NE (2.5)

9


It’s important to notice, that this equation system is a system of:

• Second Order

• Non-linear

• Coupled

• Three degrees of freedom

M = 34.865T Total mass of platform

Izz = 4, 3199 · 107Tm2 Inertia z-axis.

a11 = 20.000T Resulting hydrodynamical additional mass x-axis

a22 = 21.000T Resulting hydrodynamical additional mass y-axis

a66 = 30.000.000Tm2 Resulting hydrodynamical

additional inertia z-axis.

b(1)11 = −658, 798Ts

mlinear damping constant x-axis

b(2)11 = 1, 2592 · 103 Tm2

s2 quadratical damping constant x-axis

b(1)22 = −155, 6771Ts

mlinear damping constant y-axis

b(2)22 = 1, 6508 · 103 Ts2

m2 quadratical damping constant y-axis

b(1)66 = −1, 9520 · 105Ts2m linear damping constant φ

b(2)66 = 1, 9215 · 108Tms2 quadratical damping constant z-axis

c11 = 74KNm

Federkonstante x-axis (anchor)

c22 = 74KNm

Federkonstante y-axis (anchor)

c66 = 4KLAa√

2 sin(φ)φ

Non-linear Federkonstante (anchor)

The a-parameters are the result of the water mass and have been determined experi-

mentally. In the simulation I consider the anchorless case, all the c-parameters can be

set to zero.

2.1.2. Transformation of the coordinates

The equations above contain environment coordinates as well as body coordinates. The

transformation between these two systems is made as follows. See [1] and 2.8.

10


Figure 2.3.: Platform

xN = u cos φ− v sin φ (2.6)

yN = u sin φ + v cos φ (2.7)

φ = r (2.8)

2.1.3. The linearized Model

In order to project a controller it is useful to linearize the given equations. Using that,

the system could be seen as a linear system near to a determined operating point. A

linearization could be made as follows and results in the following system of differential

equations (All velocities and accelerations in the operation point are set to zero). By

seeing the position as the output, it looks like a standard LTI IT1 system.

∂f

∂q

∣∣∣∣AP

(q − q0) +∂f

∂q

∣∣∣∣AP

(q − q0) +∂f

∂q

∣∣∣∣AP

(q − q0) =∂f

∂u

∣∣∣∣AP

(u− u0) . . . (2.9)

A linearization is made by using the equations above. This results in the following.

11


Figure 2.4.: Velocity x

(M + a11)u + b(1)11 u = XT + XE (2.10)

(M + a22)v + b(1)22 v = YT + YE (2.11)

(IZZ + a66)r + b(1)66 r = NT + NE (2.12)

12


Figure 2.5.: Velocity y

Figure 2.6.: Angle velocity φ

13


Figure 2.7.: 3D simulation output

Figure 2.8.: Platform, coordinates and positions of the propellers

14

3. Optimal distribution of the control

variable

Like we already have seen, the relevant outputs we want to control are (x,y,φ). All of

the other dimensions we can’t control. The actors don’t allow the manipulation of it. In

order to control these left positions, the propulsion system can provide two forces Fx and

Fy and one moment M . The platform possesses eight propellers. Each of them can afford

a pointed thrust (Fi and alphai). In totally this results into 16 values which can be used

to deliver these above mentioned 3 values. This looks like an optimization task. Matlab

already offers a big amount of different optimization algorithms. The most of them make

use of the lagrange multiplier. I will use this kind of optimization, too. I have tested

some of the build-in algorithms of Matlab 1, but since they are working numerically the

calculation takes more time. And even if it would work, since the algorithms has to be

implemented in a microcontroller it would be necessary to convert the code into another

form. Because of that it is better to discover an analytic way, in order to implement it

in the controller.

3.1. LAGRANGEn Multiplier

The above mentioned Lagrange multiplier can be used ([11] and [10]) to solve an Ex-

tremwertaufgabe like f(x1, x2, ..., xn) with constrains g(x1, x2, ..., xn) = 0 with laplace

∇g 6= 0.

For the extremal value it has to be considered

df =∂f

∂x1

dx1 +∂f

∂x2

dx2 + . . . +∂f

∂xn

dxn = 0

1e.g. fmincon or lsqlin

15

3.1. LAGRANGEN MULTIPLIER

Because the constrains are constant, its derivatives have to be zero. This results into:

dg =∂g

∂x1

dx1 +∂g

∂x2

dx2 + . . . +∂g

∂xn

dxn = 0 (3.1)

The trick is to put the function, that should be minimized or maximized f , and the

constrain function g in just one equation. This is simple, because these two equations

are zero. The equation 3.1 will be multiplied by the langrange multiplier λ. This results

into:

( ∂f

∂x1

+ λ∂g

∂x1

dx1

)+

( ∂f

∂x2

+ λ∂g

∂x2

dx2

)+ . . . +

( ∂f

∂xn

+ λ∂g

∂xn

dxn

)= 0. (3.2)

To put it into a simpler way:

∂f

∂xk︸︷︷︸Funktion

+ λ∂g

∂xk︸︷︷︸Randbedingung

= 0 mit k = 1, 2, ...n. (3.3)

If there are more constrains g1 = 0, g2 = 0, . . . , gm = 0, we have correspondingly:

∇f = λ1∇g1 + λ2∇g2 + . . . + λm∇gm. (3.4)

Example: Distance of a point from a body. For a better explanation of the above

mentioned equations, a example will follow: The minimal distance of a point (x0 =

1, y0 = 1) from the eclipse 4x2 + 9y2 = 36 may be found. The first step is to determine

the function f(x, y) and the constrains g(x, y) = 0. If we convert the eclipse into the

following form, we will already have the required form.

g(x, y) = 4x2 + 9y2 − 36 = 0 (3.5)

The function that has to be minimized f(x, y) is the distance function that describes

the distance between a point (x, y) from the point (x0, y0). In the given case it’ll be:

A =√

(x− 1)2 + (y − 1)2 (3.6)

16


This is already the required function f(x, y) = A2. Introducing g(x, y) correspondingly

the equations above, it results in a non-linear system of differential equations of n + m

equations:

2(x− 1) + 8λx = 0 (3.7)

2(y − 1) + 18λy = 0 (3.8)

4x2 + 9y2 − 36 = 0 (3.9)

Utilizing Matlab, the solution is as follows:

syms Lambda x y

[Lambda,x,y]=solve(2*(x-1)+8*Lambda*x,2*(y-1)+18*Lambda*y,4*x^2+9*y^2-36)

double([Lambda,x,y])

ans =

-0.0500 1.2500 1.8181

-0.3360 -2.9070 -0.4941

-0.1681 - 0.0329i 2.6285 + 1.0563i -1.4620 + 0.8440i

-0.1681 + 0.0329i 2.6285 - 1.0563i -1.4620 - 0.8440i

3.1.1. Realization of the optimization

In the given case it’s about a quadratic optimization with linear constrains. This problem

is a little bit better to handle, because the problem can be transferred in a system of

linear equations, which can be solved using the well known standard methods. The

objective of the optimization is to find an optimal solution for the distribution of the

thrusts over the eight (or less, in the case of failure) propellers. The following three

values have to be achieved:

XReq is the force in direction x demanded by the controller.

YReq is the force in direction y demanded by the controller.

MReq is the yaw moment demanded by the controller.

17


The energy is supposed to be dependent of the quadratic sum of the eight propellers.

P ∼ T 2i (3.10)

Es gilt:

TTotal =√

T 2x + T 2

y (3.11)

Like described in 3.1, a cost function will be supposed like follows (function which has

to be optimized, respectively minimized).

Cost =

N1∑i=1

T 2i +

N2∑j=1

λj·constrainsj (3.12)

∑T = Treq

∑T − Treq = 0 (3.13)

∂Cost

∂(Ti, λj)= 0 (3.14)

A · ~T = ~B (3.15)

A ∈ <N,N , ~T ∧ ~B ∈ <N und N = 2n1 + n2 (3.16)

~T = A−1 · ~B (3.17)

Cost = J =8∑

i=1

T 2Xi +

8∑i=1

T 2Y i + λ1 ·

( 8∑i=1

TXi −XReq

)+

λ2 ·( 8∑

i=1

TY i − YReq

)+ λ3 ·

( 8∑i=1

(−dyi · TXi + dxi · TY i)−NReq

)(3.18)

Following 3.3 and 3.4:

18


2 · TX1 + λ1 − dy1 · λ3 = 0

2 · TX2 + λ1 − dy2 · λ3 = 0...

2 · TY 8 + λ2 + dx8 · λ3 = 08∑

i=1

TXi −XReq = 0

8∑i=1

TY i − YReq = 0

K∑i=1

(−dyi · TXi + dxi · TY i −NReq) = 0

This system can be written like a system of linear equation of this form:

A · ~T = ~B

That results in:

A =

2 · E16,16 18,1 08,1 − ~dy

08,1 18,1 ~dx

11,8 01,8

01,8 11,8

− ~dy ~dx

03,3

(3.19)

~T T =[~T T

X~T T

Y~λT

](3.20)

~BT =[01,16 XReq YReq NReq

](3.21)

This form is easy to calculate, to handle and to implement in microcontrollers. After

solving the equation system, the required values alphai and Ti can be found using ~T =

A−1 · ~B. And Ti =√

T 2Xi + T 2

Y i and αi = arctan(TY i

TXi). (See p13gui/Propeller Aloc).

To consider the case of a saturated propeller (this means that a propeller has reached

its maximum thrust), this algorithm has to be modified. Firstly, more constrains can

be used. But it would cause the problem to get non-linear. To keep the problem

linear another option would be to do the following: Once if the calculated thrust of

19


one propeller achieves more than the saturation value Ts, its real value has to be set to

Ts. The forces and the moment which still remain has to be calculated and distributed

again. That means that the optimization has to be done again, with the propellers that

that still left. In this case a redistribution of the remaining forces and the moment

would be done. The first suggestion would result into a non-linear problem. This useful

advantage would fall away. Because of that, I solved the problem with the second way.

IMPORTANT: The case of a saturated propeller will occur principally, when there is

already an asymmetric propeller configuration due to a failure in one or more propellers.

A saturation of a propeller in the symmetric case easily causes saturation in the whole

propulsion system. The source code can be found in the appendix.

3.1.2. Adaptation to the real conditions

The values that have been calculated by the algorithms described above can’t be realized

without delays. That means that a modification of the thrust or the angle won’t be

followed immediately. According Data Sheet [8] an azimuth velocity of αi = 2RPM and

a run up time of TAnlauf = 20s can be supposed. Because of the simplicity I implemented

a PT1 model, which can be integrated easily in Simulink using a state-space-block.

This is following [5]:

Ti,1 · Ti + Ti = Ti,soll

its solution is:

Ti(t) = Ti,soll · (1− e− t

Ti,1 )

Setting Ti(t=20)Ti,soll

= 99% and t = 20 results in Ti,1 ≈ 4.3s for the time constant. Putting

it to the form:

x = Ax + B (3.22)

y = Cx + D (3.23)

results in:

20


0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25

T (t)Tsoll

t

1− e−t

4.3

Figure 3.1.: System response of a PT1-System

A = − 1

Ti,1

· E8,8 (3.24)

B =1

Ti,1

· E8,8 (3.25)

C = E8,8 (3.26)

D = O8,8 (3.27)

With E as the identity matrix. This form can easily be implemented in the Simulink

model (p13gui/PT1).

azimuth velocity is realized in the block (p13gui/Azimut Delay).

3.1.3. Influence of the Delays

With the introduction of the allocation block and the following delay blocks, I have

introduced at the same time a new problem. To clarify this problem, let’s take a look

at picture 3.3 and 3.4. In this case, the controller demands two different force vectors.

In point I., the demanded Force jumps quickly from zero to Fx = 2000kN . Because

of the limited run up time, the propulsion system just achieves the desired thrust after

20s. This is the expected behaviour, because, like described above, a single propeller

was modelled like that. And the sum of all of them should behave equivalently. In point

21


Figure 3.2.: Delay of angle velocity

II., the value of the Thrust doesn’t change, but the direction changes from 0◦ to 90◦. In

this case the azimuth delay takes place, like it can be seen. This is an interesting point.

How can the system react? It could, for example, run down the propellers, than change

the thrust direction and after that run up again. This would reduce the influence of the

coupling, but it would slow down the response speed. In the given case it just changes

the direction without slowing down the rotation speed of the propellers. This causes that

coupling that can be seen in this point. In the last point the two forces are set to zero.

Because the system doesn’t know what command follows, it runs down and propellers

and changes the position at the same time. Although the force Fx doesn’t change at

this point, the change has an influence to iz, like it can be seen in the resulting thrust.

Since every value is zero at this point and will be zero future, it would be better, if the

propulsion system just switches the propellers off. But since it is not able to look into

the future, it doesn’t do it. Like we could see, the introduction of these blocks raises the

complexity of the whole system concerning the coupling and degree of the total system.

But the assumptions are just approximations to achieve a more realistic simulation of

the platform’s behaviour. However, a controller design should be robust. Later we will

see if the influence of these delays is really that big or not. Because of the relatively

big time constants in relation to the time constants of the propulsion system, I expect

that it won’t affect that much the system dynamic for positioning issues which just has

22


to take the platform from one place to another. But it’ll be a limitation in relation to

the disturbance rejection. Disturbance of higher frequencies won’t be compensated; a

low-pass which has to be adapted to the propulsion system should be used.

Figure 3.3.: Demanded force

23


Figure 3.4.: Resulting force

24

4. Perturbations

In order to perform realistic simulations, the environment of the platform has to be

simulated and modelled, too. That means that a mathematical description of the per-

turbations has to be found to implement it in the simulink simulation. On the other

hand the reaction of the platform is needed to be designed. That means that it is

necessary to, firstly, design a simulation, that means a mathematical description of the

environmental influences and secondly to analyze a system response in order to let the

simulated platform response to this modelled stimulus. First, let’s take a look at the

types of disturbances. In general there are three different kinds of them: The current,

the waves and the wind. The current can be seen one the one hand as a constant value,

a constant disturbance. But additionally one may not forget that this kind of pertur-

bation is a little bit problematic. Let’s suppose that there is a current. First it could

be seen as a constant force which influences the platform. The propulsion system can

compensate it generating a constant force on his side. But the propulsion system gen-

erates force generating a current itself. But the current is in this case a perturbation.

That means that the bigger the current is the smaller is the maximum thrust which

could be provided by the propellers. See [3]. But since the thrust of the propellers is

controlled by a PID this problem should not be that complicated if the current is not

that high. The PID will control the resulting force and not the resulting rotation speed

or flow velocity. But to put it in other words the maximal force to compensate the

current is smaller than 8 * Ts. The next disturbance is the wind. Wind consists, in

general, of a constant component and a high frequency component. High frequencies

almost won’t affect that big platform; just the constant part should be compensated.

The last disturbances are the waves. The waves consist of lower-frequency components,

which affect the platform. Because of the platform’s weight and big inertia and because

of the slowness of the propulsion system (like explained above), the waves are the most

important kind of perturbation, which has to be included in the simulation.

25

4.1. SIMULATION OF THE WAVES

4.1. Simulation of the Waves

To integrate a perturbation block into the simulation it is firstly necessary to determine

how it is compound and than it has to be analyzed how the platform reacts due to

this stimulus. In order to determine this, some tests were made by an institute from

the Netherlands. The model of the platform has been stimulated with some discrete

test frequencies, the system reaction were measured in three degrees of liberty. For this

see the pictures 4.2, 4.3 and 4.4. Transforming these measurements in a table a signal

transfer function can be determined which can directly be used to compute the system

response of this kind of stimulus.

In the given case a power density spectrum called JONSWAP has been integrated,

which describes a turbulent behaviour of the local sea. Following [2]:

S(ω) = 155H2

S

T 41 ω5

e

(−944

T41 ω4

)γY (4.1)

With the parameters:

Y = e−(

0,191ωT1−1√2σ

)2

(4.2)

σ =

0.07 fur ω ≤ 5.24T1

0.09 fur ω > 5.24T1

(4.3)

It is T1 = 0, 834 ·T0 and T0 = 1, 073 ·Tz and γ = 3, 3. It can vary between one and seven.

Using the parseval theorem and consider [4] follows:

A2i (ωi) = 2∆ωS(ωi) (4.4)

Considering the measured system response results in:

xjPO(t, β0) =n∑

i=1

√2S(ωi)RAOj(ωi, β0)2∆ωcos(ωit + phase(RAOj(ωi, β0)) + φj) (4.5)

After passing a total period of the deepest frequency, another random phase is calculated1. That means that the last two terms of the phase can be substituted by a random

1in order to suppress the high frequency part which occurs due to this step, a 4. order butterworth

filter with wg=1rads/sec has to be included in the simulation

26


Figure 4.1.: Unimodal Spectrum

phase 4.5. Derivate the equation two times gives the acceleration.

xjPO(t, β0) =n∑

i=1

ω2i ·

√2S(ωi)RAOj(ωi, β0)2∆ωcos(ωit + φj) (4.6)

ω 0,3 0,4 0,5 0,6 0,7 0,8 0,9xζ

0,9 0,74 0,58 0,42 0,26 0,1 0,1yζ

0,95 0,72 0,52 0,35 0,22 0,12 0,04φζ

0,16 0,06 0,07 0,07 0,06 0,07 0,07

Table 4.1.: Amplification function RAO

This can be connected directly with the mathematical model of the p13 platform (see

model). In order to considerate the orientation angle in relation to the incoming wave

front, the following equations have to be used:

xξ = xξPO · cos(Φ) (4.7)

yξ = yξPO · sin(Φ) (4.8)

Φξ = ΦξPO · sin2(Φ) (4.9)

27


xξ, yξ and Φξ are the experimental movements, as a result of the perturbation. The

PO-values xξPO, yξPO and ΦξPO are the system responses that were computed using the

RAO table 4.1. Also see source code A.3 in the appendix.

Figure 4.2.: Response of Surge x

28


Figure 4.3.: Response of Sway y

29


Figure 4.4.: Response of Surge φ

30

5. Controlling

In [1] is shown that the system behaviour can significantly improved by using the feed-

back principle. In the easiest case the controller gets the difference of the desired value

and the real value as an input. The controller tries to minimize this difference. A general

scheme of a system that has to be controlled with sensors, controller and actors is given

in 5.1.

Figure 5.1.: Usual controlling system

5.1. PID Controller

The PID Controller is a relatively simple controller which const of an proportional part,

an integral part and an derivative part. To show the general manner of operation I

would like to explain it with the Feder-Masse-Schwinger. The transfer function of 2.1 of

the fms with damping results after laplace transformation and with F = k0 · u.

GS(s) =X(s)

U(s)=

k0

ms2 + bs + c(5.1)

Refering to [1] the PID is compound as follows:

31

5.2. PID IN THE PLATFORM

u(t)p = Kp · qdiff (t) P-Regelung (5.2)

u(t)d = Kd · qdiff (t) D-Regelung (5.3)

u(t)i = Ki

∫ t

0

qdiff (τ)dτ I-Regelung (5.4)

u(t) = Kp · qdiff (t) + Kd · qdiff (t) + Ki

∫ t

0

qdiff (τ)dτ (5.5)

The transfer function of the controller results in 1:

GR(s) =U(s)

Qdiff (s)= Kp + Kd · s +

Ki

s(5.6)

With F0(s) = GS(s) · GR(s) as the transfer function of the open system, the close

system yields in

Qist(s)

Qsoll(s)=

F0(s)

1 + F0(s)=

k0(Kd · s2 + Kp · s + Ki)

ms3 + (b + k0 ·Kd)s2 + (c + k0 ·Kp)s + k0 ·Ki

(5.7)

The proportional part of the controller affects a control action that depends linearly

on the error, the integrator integrates the error signal over the time and increases

or decreases the output in that manner, that the error becomes zero (limt→∞ f(t) =

lims→0 F (s) is in this case every time Ki

Ki= 1) . The differential part influences directly

the damping of the system. With its help it is possible to avoid overshoots. Table 5.1

summarizes the most important feature of these controllers and combinations of it.

5.2. PID in the platform

Because the platform doesn’t have anchors, I suggest the following configuration:

1. There are no c-parameters in the differential equations. This means that no per-

manent output error is expected and an integrator is not needed. A slow PD

Controller with a big damping should be used for positioning proposes in order to

economize energy.

1Notice that an ideal derivative doesn’t exist. A filter must be used to model it

32

5.2. PID IN THE PLATFORM

Kind of Controller Features and Area of Application

P For lower requirements. Controls rapidly, but isn’t able to

compensate permanent errors. This error can be reduces with

an additional gain, proportional controller tends towards os-

cillations.

I Controls slowly, doesn’t have a permanent error.

PI It’s very common to provide a proportional controller with an

integrator in order to compenate the controlling difference.

PD This combination is less common, but used. It is used to react

faster to big changes of the input.

PID More complex controlling system. The proportional part

causes a fast control, the integrative part improves the ac-

curacy and reduces the permanent error and the derivative

part improves the controlling velocity.

Table 5.1.: The P,I and D and its combinations

2. In order to keep the platforms position stable even with perturbations, a stronger

and faster controller should be used which also is able to compensate permanent

errors which are caused by constant perturbations like current or wind. A PID

Controller is needed.

3. To soften the crossing area between these two controlling regions, the decision

which controller takes how much part could be taken by a fuzzy controller. An

eventually set of rules can contain the difference from the wanted position, the

actual velocity and an acceleration.

While trying to design a PID controller for the platform, one is confronted which the

first problem. A reasonable analytic design can only be made with the linear model.

The linearized model results in reference of 2.1.3 in an IT1 -system (if one takes the

position as the output xb = u, ...).

To design a PT2 similar response with D = 1 and approaching approximately 99% of the

desired position in 300s an ω0 = 0.0205 is needed. The closed-loop system results in :

1 + Kd

Kps

M+a11

Kps2 + b11(1)+Kd

Kps + 1

≈ K1

ω20s2 + 2D

ω0s + 1

(5.8)

33

5.3. NUMERIC ALGORITHM

Kp = w20(M + a11) = 23 (5.9)

Kd =2D

ω0

·Kp − b(1)11 = 2900 (5.10)

By doing this computation with all the 3 coordinates it results in the following controlling

parameters xb: Kp = 23, Kd = 2900. yb: Kp = 23.5, Kd = 2460 and for φ: Kp = 30000

and Kd = 3200000. In order to test the simulation I just implement the positioning

parameters.

5.3. Numeric Algorithm

Using the linearized form of the equations is mainly permitted when being near to the

operation point (e.g. if the intention is to keep the platform on a position and keep the

velocity and acceleration as small as possible, every value should be near zero), where

the equations had been linearized, it is obvious that the dynamical positioning perhaps

shouldn’t be done by using them. That means that there is not just one operation point.

On its way from one waypoint to another, the platform passes through a lot of different

states. Perhaps a simplification of the equations is not longer the best idea. But without

simplification, the mathematical model is non-linear and coupled. It should be used a

tool, that can even find suitable controller parameters, although this kind of model is

used. A numeric algorithm should solve this problem. The main idea is to start a first

attempt with a controller parameter vector, analyze the solution, try another vector,

analyze if this design got better or worse (gradient) and determine another solution

hoping that it converges and finds a local, or better, global optimum. In order to

describe how this kind of algorithm works, I will explain it with the iterative feedback

tuning.

5.4. Iterative Feedback Tuning

In general one can say that an optimal controller design requires a complete knowledge

of the system that has to be controlled and of the disturbance. In the reality that is

not often the fact. If the transfer matrix isn’t known or non-linear, it’s quite difficult to

34

5.4. ITERATIVE FEEDBACK TUNING

determine suitable controller parameters analytically. A good remedy can be found by

utilizing a frequently-used algorithm called Ziegler-Nichols 2.

A comparable technique is used by the algorithm called ”Iterative Feedback Tuning”

that I will describe here at this section. For more details see [13]. A opportunity to

design controller of restricted complexity, is to perform a plant model identification and

model-based controller update. That means that the idea is, to improve the identification

of the system using close-loop tests with the actual controller. This information helps

to improve the controller by successively applying the new data to the new controller.

To put it in other words closed-loop system identification is made, this exacter system

information helps to design a better controller and a better controller helps to identificate

the system even more exactly in order to design another better controller. But in [13]

is said that there are few results to support these expectations, except if a full-order

controller and full-order model is used, but this case is quite unrealistic (especially for

a PID Controller that is a lower-order controller). But the IFT algorithm works even

without system identification. The algorithm that I will explain here is the original

algorithm from [13] that has been simplified and adapted to the present case. Actually,

the original IFT considers disturbance, but because the algorithm doesn’t have to be

applied to a real plant, I don’t consider the disturbance for now. Let’s suppose a linear

time-invariant transfer function G0 (Like described in [13] this assumption even seems

to be allowed although the present system isn’t linear). The transfer function of the

controller is ρ. On a PID Controller this would be ρ = (Kp, Kd, Ki).

The criterion that should be minimized is:

J(ρ) =1

2N

[ N∑t=1

(Lyyt(ρ))2 + λN∑

t=1

(Luut(ρ))2

](5.11)

With y(ρ) = y(ρ) − yd as the difference between real system response y(ρ) and desired

response yd = Tdr. In order to obtain the minimum of the criterion, 5.11 has to be

derivated and set to zero.

0 =∂J

∂ρ(ρ) =

1

N

[ N∑t=1

yt(ρ)∂yt

∂ρ(ρ) + λ

N∑t=1

ut(ρ)∂ut

∂ρ(ρ)

](5.12)

2A model free procedure that was designed in the year 1942, to discover controller parameters for

simple controllers in unknown systems. It’s tried to achieve a closed-loop system-response that is

similar to the response of a PT1 with first order delay G(s) ' ke(−T s)

τs+1

35


If this gradient could be computed, a following iterative algorithm can be used:

ρi+1 = ρi − γiR−1i

∂J

∂ρ(ρi) (5.13)

R−1i is a positive definite matrix, typically a Gauss-Newton approximation of J and the

step size γi. Ri could also be the identity matrix. Following [13] the equation bellow

should lead to a fast convergence:

Ri =1

N

N∑t=1

([∂yt

∂ρ(ρi)

]·[∂yt

∂ρ(ρi)

]T

+ λ ·[∂ut

∂ρ(ρi)

]·[∂ut

∂ρ(ρi)

]T)

(5.14)

In can be noticed, that the big obstacle in 5.12 is to obtain a solution for the gradients∂eyt

∂ρ(ρ) and ∂ut

∂ρ(ρ). In order to obtain this, the author suggests to stimulate the system

with a signal r (e.g. step function) while measuring the output y1 and u1. That the

gradients can be determined by stimulating once again but with r − y1 as input. By

measuring its responses y2 and u2. See 5.20 and 5.21). This results in the following

algorithm.

1. Set the desired response yd = T d · r

2. Determine the transfer function of the controller C(ρ)

3. Determine the gradient ∂C∂ρ

(ρ)

4. Estimate a start vectorρ1

5. Set the parameters of the algorithms e.g. γ...)

6. Measure of u1 and y1 with r as input

7. Measure of u2 and y2 with r − y1 as input

8. Calculate the gradients ∂eyt

∂ρ(ρi) and ∂ut

∂ρ(ρi) via the equations 5.21 and 5.22.

9. Calculate the gradient ∂J∂ρ

(ρi) and the matrix R-1 R−1i with 5.12 and 5.14

10. Continue with 5 with the new vector ρi+1 calculated by 5.13

y1(ρi) =C(ρi) ·G0

1 + C(ρi) ·G0

· r (5.15)

36


u1(ρi) =G0

1 + C(ρi) ·G0

· r (5.16)

y2(ρi) =C(ρi) ·G0

1 + C(ρi) ·G0

· (r − y1(ρi)) (5.17)

u2(ρi) =G0

1 + C(ρi) ·G0

· (r − y1(ρi)) (5.18)

∂y

∂ρ=

∂y

∂C· ∂C

∂ρ=

∂( C(ρ)·G0

1+C(ρ)·G0

)∂C

· ∂C

∂ρ(5.19)

With u = C(ρ) · G0 and v = (1 + C(ρ) · G0)−1 and its derivative u′ = G0 and v′ =

−1 · (1 + C(ρ) ·G0)−2 ·G0 follows according to5.19:

∂y

∂ρ= u′v + v′u =

( G0

1 + C(ρ) ·G0

− G20 · C(ρ)

(1 + C(ρ) ·G0)2

)∂C(ρ)

∂ρ· r (5.20)

Setting 5.15 in 5.17 and by comparison of coefficients follows ∂y∂ρ

:

∂y

∂ρ(ρi) =

1

C(ρ)

∂C(ρ)

∂ρ· y2 (5.21)

Doing the same with ∂u∂ρ

(ρi) results in:

∂u

∂ρ(ρi) =

1

C(ρ)

∂C(ρ)

∂ρ· u2 (5.22)

Figure 5.2.: Blockschaltbild des ITF-Systems

37

5.5. DESIGN OF A DIGITAL CONTROLLER WITH IFT

5.5. Design of a digital controller with IFT

Applying this algorithm to a PT2-system with m = 1, d = 0.5 and c = 1 and the fixed

step size γ = 1 and λ = 0 with a desired response yd = (1−e−t

0.5 ). . The algorithm even

achieves a suitable solution after less iterations that is almost similar to the analytic

solution. But to begin with the algorithm, the PID has to be modified.

PD-Controller:

u(t) = Kp · e(t) + Kd · e(t) (5.23)

u(k) = Kp · e(k) + Kd ·e(k)− e(k − 1)

∆T(5.24)

U(z)

E(z)=

(Kp + Kd)z − Kd

∆T

z=

az − b

z(5.25)

I-Controller:

u(k) = u(k − 1) + ∆T ·Kiu(k − 1) (5.26)

U(z)

E(z)=

∆T ·Ki

z − 1=

c

z − 1(5.27)

It follows the discrete transfer function of a PID-Controller:

U(z)

E(z)=

az − b

z+

c

z − 1=

az2 + (c− b− a)z + b

z(z − 1)(5.28)

With a = Kp + Kd

∆T, b = Kd

∆Tand c = ∆T ·Ki follows that:

(Kp + Kd

∆T)z2 + (−2 Kd

∆T−Kp + Ki∆T )z + Kd

∆T

z2 − z(5.29)

Now just the partial derivatives are missing. These are:

∂C

∂Kp

=z2 − z

z2 − z= 1 (5.30)

∂C

∂Kd

=1

∆Tz2 − 2

∆Tz + 1

∆T

z2 − z(5.31)

∂C

∂Ki

=∆Tz

z2 − z(5.32)

38

5.5. DESIGN OF A DIGITAL CONTROLLER WITH IFT

Taking a look to 5.3 shows that got results were achieved for the PID. The calculated

parameters are: Kp = 0.9863, Kd = 1.9801 und Ki = 1.9797. Another start vector

(5.4)achieves after six iteration steps Kp = 0.9866, Kd = 1.9799 and Ki = 1.9799.

Figure 5.3.: Systemantwort nach Optimierung (Startwert: Kp = 1, Kd = 0.1, Ki = 1), 5

Schritte

The analytical solution is Kp = 1, Kd = 2 and Ki = 2. Here the poles are in the zeros.

The close-loop system behaves like a PT1-system.

Zeros:

sn1/2= −0.2500± 0.9682i

Poles:

sp1 = −2

sp2/3= −0.2500± 0.9682i

39

5.6. CONTROLLER PARAMETERS WITH IFT

Figure 5.4.: Systemantwort nach Optimierung (Startwert: Kp = 0.1, Kd = 0.1, Ki =

0.1), 6 Schritte

5.6. Controller Parameters with IFT

The algorithm above introduced algorithm of IFT is the SISO-Version of the algorithm.

Since the platform is a MIMO-system it has to be modified like it is explained in [14].

But my intention was only to explain this kind of alternative. But even if I try to apply

it to the platform, seeing it like an SISO system, with the input Fx and the output x,

the algorithm already brings a suitable convergent result like it can be seen in 5.5.

5.7. Optimization via Matlab Response Optimization

Toolbox

The most recent version of Matlab, Version 7 R14 brings some considerable improve-

ments with its new Toolbox Simulink Response Optimization. The intention and its

methods are quite similar to these of the IFT algorithm.

A easy to use method, which iteratively brings good results is the following:

• Positioning of Signal Constraint blocks at the output connectors.

40

5.7. OPTIMIZATION VIA MATLAB RESPONSE OPTIMIZATION TOOLBOX

Figure 5.5.: Systemantwort P13 auf Einheitsprung ITF

• Setting of certain response characteristics, like rise time, settling time, overshoot

and undershoot and its limits.

• Or/and a tracking reference signal (like ITF) can be used.

• To minimize the signal enery, it is possible to position RMS-blocks at the concern-

ing places.

• Determining a stimulus (Step-function, Chirp-Signal, ...)

• Estimating a start vectro

• Passing to the Signal Constrant Toolbox the controller parameters that may be

optimized and can be modified. If necessary maximum and minimum limits.

• Uncertain model parameters also can be passed to the toolbox.

In the given case of the platform a stimulus of 5.7 is used. From xs = ys = 0 the

xs-input is set to xs = 25 and ys is been hold to zero. After 300 seconds, the reference

is again xs = ys = 0 and after 600 seconds ys should be ys = 25. The paramters of

the controller that have to be modified are chosen the proportional and derivative part.

The integrative part of the controller is hold to zero. It results in a PD-Controller.

41

5.7. OPTIMIZATION VIA MATLAB RESPONSE OPTIMIZATION TOOLBOX

Since the platform is not anchored, the system can already be seen as a integrador.

There won’t be a controlling difference. A extra integrative part would be suppressed

by the Matlab algorithm via the remaining parameters. The toolbox tries now to find a

suitable solution for the coupled system that suppresses the coupling influences. Like it

can be seen in 5.8 and 5.9, matlab find successfully a suitable soultion. In particular the

disturbing effect that is described in 3 seems to be not so disturbant. Some parameters

that have passed to me by another student were less suitable. Like it can be seen in 5.10

the platform approaches oszillating to the desired position. With the new parameters

5.11 the platform reaches directly its position. The controller seems to by good. Its

right, that this controller isn’t already optimal, but this wasn’t the task. But I can say

that the parameters are good enough to be implemented into the platform model in

order to prove if the general assumptions are certain or not.

Figure 5.6.: Matlab Optimization Toolbox

PID Kp Ki Kd

x 50 0 4999

y 171.80 0 6000

Table 5.2.: Optimierte Reglerparameter

42

5.8. CONTROLLING VIA LQR/LTR AND FUZZY

Figure 5.7.: Stimulus

5.8. Controlling via LQR/LTR and Fuzzy

A LQR-LTR controller has also been implemented. I won’t describe at this place how

this approaches have been done. Please refer to the concerning reports of it.

The rules for the fuzzy controller that have been implemented by me just for testing

proposes and can be found in the appendix.

43


Figure 5.8.: System response on stimulus

Figure 5.9.: System response with coupling delay

44


Figure 5.10.: Trajectory with old parameters (Position 50,50,pi)

Figure 5.11.: Trajectory with new parameters (Position 50,50,pi)

45

6. Soft- and Hardware Implementation

With this parameters and algorithms it is possible to determine the best hard- and

software realization of the platform. First, what has to be controlled? The platform

is equipped by 8 propellers, each one has two motors, one for the force and one for

the angle. These eight propellers are distributed over the four corners of it. That

means that there are 4 motors at each corner. It would be possible to use either one

powerful controller with a lot of outputs to control all of them or to use one controller

which acts as a master and communicates with smaller ones. My idea is to connect one

powerful controller with four smaller ones, each one for each corner. The structure can

be seen in 6.1. One Personal Computer is connected via TCP/IP with a Rabbit 3000

Controller for monitoring purposes. This one is on the other hand connected with four

AVR Microcontroller, which control 16 motors, each one four of them via the PWM

outputs of them. See 2.8.

6.1. The Microcontroller Board Rabbit RCM 3200

As I have described above I have chosen the Rabbit 3000 µC. Rabbit Semiconductors

offers a big amount of different Board. For my purposes the Rabbit RCM 3200 is the

best choice. Following [12] the controller offers:

• Powerful Rabbit 3000 Main Processor with 44,2 Mhz

• 52 parallel 5 V tolerant I/O lines: 44 configurable for I/O, 4 fixed inputs, 4 fixed

outputs o 10/100Base-T RJ-45 Ethernet port

• 512K flash memory, 512K program execution SRAM, 256K data SRAM

• 6 Serial Ports (4 of them are compatible with SPI)

46

6.1. THE MICROCONTROLLER BOARD RABBIT RCM 3200

Figure 6.1.: Principle System Configuration

47

6.2. THE MICROCONTROLLER ATMEL MEGA64

6.2. The Microcontroller ATMEL Mega64

Like it can be seen in 6.1 I use four AVR microcontrollers. This µC family is frequently-

used controller set because of its good price, high performance and relatively easy-touse

development environment called CodeVision C. But which of these controllers of this

family is the optimal choose in my case? First let me list the criterions which the

controller has to fulfil and which features are needed:

• A common Serial Interface to communicate with the Rabbit 3000.

• Since I will control four drives by each controller, 4 PWM Channels are needed.

o Each of these four drives should be controlled by a PID algorithm with a ac-

tualization frequency of T = 10-3s-1, for this reason I need a controller which is

powerful enough to handle this. o At least one additional Timer (8-Bit or 16-Bit).

• Perhaps up to four Analog/Digital Converter.

• Low-Power Consumption would be a nice extra. Considering this, I have chosen

the ATmega64 controller, which more than fulfils all of these points above.

It looks like the ATMega 64 is the best choice for the present case. It can be programmed

comfortably with the STK 500 kit and STK 501 or STK 502 adapter kit.

Like already said, the Rabbit 3000 should run the main controlling algorithms. This

includes the acquirement of the actual position, a calculation of the controller response

and the optimization that was explained in chapter 3. The calculated values should be

sent to the AVR controllers. In order to do that, a communication interface that handles

the communication of this two different controllers have to be developed.

6.3. The Serial Communication Interface

The Rabbit Semiconductor Rabbit 3000 and the AVR ATmega 64 are two completely

different processors. In order to realize a starlike communication (What is allowed in

this case, I don’t think, that more than 4 AVR’s will be used. An the R3000 has enough

serial interfaces to manage this task). The serial communication has been implemented

in two levels. The low-level communication handles just a single incoming byte.

48

6.3. THE SERIAL COMMUNICATION INTERFACE

6.3.1. Low-Level Communication

To keep the processor free while no traffic is occurring on the serial bus, the low-level

communication has been realized by using an interrupt-routine. That means that the

CPU could do its controlling job without being disturbed by time-robbing check and

communication loops. Just when some data arrives the routine let the CPU handle

this request and after that it continues where it stopped. The only code concerning the

communication which has to be implemented in the main() routine is a short command

that verifies if the content of the receive buffer is larger than zero. If it is so, it signifies

that new data arrived. To put it into one sentence: Since the communication handler

uses interrupts and a receive buffer, it is possible to receive incoming data at any time

without loses, even when the processor is doing other things. Let’s take a look at the

process-diagram in such a case. I suppose that the CPU is occupied by the main()

method, which is doing most of the time (in the present case) its controlling job. Now

some data arrives via the serial port. What will happen? See 6.2.

1. The CPU is processing the main routine. Let’s suppose, that it’s it the middle of

it.

2. Some traffic on the serial bus arrives which causes the microcontroller to throw an

interrupt.

3. The task-switch saves all the used registers and the re-entry point and calls the

corresponding routine (in this case IHSC, Interrupt Handler Serial Communica-

tion).

4. The IHSC receives the data and puts it into a certain buffer. Note that since

interrupt routine are not called at a certain point, they can’t return a value nor have

parameters, in other words these functions can only manipulate global variables.

Because of that all the incoming data are stored in a global variable.

5. The control is being given back the to the TS, which restores all the registers and

recalls the routine which has been interrupted.

6. The main routine continues where it has been stopped. If it won’t be interrupted

again and when it arrives at the certain point, it processes the new data which is

still waiting for being treated.

49


Figure 6.2.: Process-Time-Diagram Low-Level Serial Communication

6.3.2. High-Level Communication

This part of the communication protocol, which I described above could be called as the

low-level communication, which just handles a single incoming byte. At a higher level I

implemented a communication interface using a relatively simple state-machine. These

states are: LISTEN, RECEIVE and COMMANDRECEIVED. See 6.3. This level uses on

his part a interrupt handler, too. But this time it is a Timer Interrupt. First, the state-

machine stays in the LISTEN state as long as other data than a predefined dataword

arrives at the receive buffer. Any arriving data would be discarded. When this start

byte arrives, the state-machine switches into the RECEIVE state. The microcontroller

starts one of its build-in timers to determinate a maximum transfer time and sends

a ready-to-send command. Now the Rabbit 3000 controller has to send its message

within this predetermined time. Actually the state-machine has n RECEIVE 1 states

in order to store a high-level command of the length n. If it would achieve it, the AVR

Controller will send a TIMEOUT command to the Rabbit 3000 and will return to the

LISTEN state. In that case that the command arrives successfully, the protocol switches

to the COMMANDRECEIVED state and will refuse any incoming data (That means

that these data will just be rejected at the high-level interface) until these are processed.

1This dataword can be seen as a start byte and may not be used as a data byte, otherwise it would

be possible to confuse it.

50


Those data the AVR would respond with another predefined code. In another words

the state-machine won’t be reset to the LISTEN state until the higher level controlling

algorithm resets it by picking these data up. If one likes to, a command buffer can be

introduced that is capable to buffer m commands. Since the AVR receives relatively

seldom commands, it isn’t necessary. See source code C.1.

Figure 6.3.: Statemachine of the High-Level Serial Communication

51

6.4. ALTERNATIVE COMMUNICATION METHOD

6.4. Alternative Communication Method

Another opportunity to realize a communication would be a communication via a com-

bination of the synchronous SPI interface and the Two-Wire-Interface of the AVR. The

SPI interface offers high speed serial communication with 4 wires. Its a master-slave-

protocol that is supported by both, the Rabbit and the AVR processor family. The TWI

is a bus system that is only supported by AVR. With it, it is possible to connect 128

processors with each other via 7 Bit addressing. The maximum data transfer velocity

is 400 kHz. See 6.4. Since the R3000 doesn’t support this standard, a single AVR con-

troller can be used to act as a bus controller. The big advantage of this structure is

its extendibility. If one more AVR is needed, it has just to be connected with the bus

without modifying it. Since in the present case 4 controllers are enough, there is not

need to implement it. But it is always a good idea to think in the future. The problem

of the bus system is that, if one cable is damaged, the whole communication system

would stop working. In the present case, a damaged cable won’t just cause to stop two

proppelers to work. If there is a suitable system that recognizes non-working propellers,

the optimization algorithm in 3 can considerate it and compute another solution with

the remaining propellers (The programmed algorithm is already capable to solve this

kind of problem).

Figure 6.4.: TWI Bus Connection

52

6.5. SENSORS

6.5. Sensors

In order to design a faultless controlling system, some different kinds of sensors have to

be mounted. The most important sensor is a positioning sensor that provides informa-

tion that are exact enough about the actual position. A standard GPS system with a

resolution of 1m should be enough. On the other hand, failure sensors that detect fail-

ures in the propulsion system have to be mounted, too, in order to help the optimization

algorithm to determine the optimal thrust.

53

7. Conclusion

In general, this project was an interesting mixture of practical simulation and imple-

mentation and of research aspects. As already said in the introduction, it wasn’t the

intention of this project to find the optimal controlling algorithm. But now the way is

almost clear to perform first test with the physical model, and basing on this simulation

and its controlling parameters, it will already be possible to discover, if the assumptions

made in this report are right. For me, I can say, that I learned very much. I got to know

Matlab and its toolboxes, I needed to learn C in order to program the microcontrollers.

I also realized a TCP based communication between a PC and the R3000, a realized a

simple communication protokoll between the R3000 and the AVR Microcontroller world

by using the important programming language C. And I also extended my knowledge

of the control system theory, a little bit of ship engineering and more. The fact, that

I did my project in Rio de Janeiro, Brazil and not in Germany without a doubt didn’t

make it easier, but it was an optimal opportunity to make some experiences in a foreign

country and to learn and improve a third language. I never would like to miss these

experiences which I made in that beautiful country.

54

A. The Matlab M-Files

A.1. Source Code Optimization via Lagrange

(Propsim.m)

1 function [Ptotalsim]=propsim (Eingang);

%Convert constant input vector

%e.g. [1 0 1 1 1 0 1 1] -> [2 6]

5

Eingang=Eingang’;

Pges=[1 2 3 4 5 6 7 8];

Plig=(Eingang (4:11))’;

P=diag (Plig)*Pges’;

10 [i,j]=find (P==0);

Pf=Pges;

Pf(i)=[];

Pges(Pf)=[];

defProp=Pges;

15

solved=0;

Fxg=Eingang(1);

Fyg=Eingang(2);

20 Mg=Eingang(3);

ohneProp=defProp;

Ps=[];

sol=0;

55

A.1. SOURCE CODE OPTIMIZATION VIA LAGRANGE (PROPSIM.M)

25 %Main routine which handles the saturation problem

%and calls the lagrange algorithm what is being realized

%in propkonsim.m

while solved~=1

30 [P,dtneu,A]=propkonfsim (Eingang(1:3), ohneProp);

if ~isempty(P) %if P is empty a det A=0 has been occured

saettigung=0;

[nrows,ncolumns]=size(P);

for i=1:nrows

35 if dtneu.Tprop(i)>820

dtneu.Tprop(i)=820;

saettigung=1;

Ps=[Ps; dtneu.Tf(i) dtneu.dx(i) dtneu.dy(i) 820 dtneu.alpha(i)];

end

40 end

if saettigung~=0

alpha=Ps(:,5);

dx=Ps(:,2);

dy=Ps(:,3);

45 Tysaet=820*(sin(alpha));

Txsaet=820*(cos(alpha));

Fxneu=Fxg-sum(Txsaet);

Fyneu=Fyg-sum(Tysaet);

Mprod1=dx’*Tysaet;

50 Mprod2=-dy’*Txsaet;

Mneu=Mg-Mprod1-Mprod2;

Eingang=[Fxneu Fyneu Mneu];

ohneProp=[defProp (Ps(:,1)’)];

solved=0;

55 dt=dtneu; %if det A=0, set old value

else

solved=1;

56

A.2. SOURCE CODE (PROPKONFSIM.M)

dt=dtneu;

sol=1;

60 end

else

sol=0; %requested input has been reached?

solved=1; %det A problem

end

65 end

%Cuts superflouos lines

presto= [dt.Tf dt.dx dt.dy dt.Tprop dt.alpha];

70 [i,j]=find (presto==820);

presto(i,:)=[];

Ptotal=[Ps; presto];

%The output vector is being generated here

75

[pfz,pfs]=size (defProp);

nf=pfs;

if nf~=0

Ptotalwithdef=[Ptotal; defProp’ (zeros(nf,4))];

80 else

Ptotalwithdef=Ptotal;

end

Ptotalwithdef=sortrows(Ptotalwithdef);

Ptotalsim=[Ptotalwithdef(1:8,4); Ptotalwithdef(1:8,5)];

A.2. Source Code (Propkonfsim.m)

1 function [Pout, Ft_0,A]=propkonfsim(Ft_1, pf);

global dx dy Tprop alphaprop A

% pf=Numbers of non-working propellers.

57


5 % Start with the lower number. e.g. : [1 4 6]

Pout=[];

Ft_0=[];

10 if nargin < 2

pf=[];

end

[pfz,pfs]=size (pf);

15 nf=pfs;

%coordinates of the propellers

dx=[-42.75, -23.9, 23.9, 42.75, -42.75, -23.90, 23.90, 42.75]’;

20 dy=[-22.53, -32.47, -32.47, -22.53, 22.53, 32.47, 32.47, 22.53]’;

Tf=[ 1 2 3 4 5 6 7 8]’;

P=[ Tf dx dy];

25 n1=8;

dxa=dx;

dya=dy;

Tfa=Tf;

30 Pa=P;

sort (pf);

35 %Number of propellers which has to be

%considerated in calculation

n1=n1-nf;

58


dx(pf)=[];

40 dy(pf)=[];

Tf(pf)=[];

P(pf,:)=[];

dxa(Tf)=[];

45 dya(Tf)=[];

Tfa(Tf)=[];

Pa(Tf,:)=[];

50 %Number of restrictions

n2=3;

N=2*n1+n2;

%The Lagrange Multipier is being used here

55

A= [(2*eye (2*n1,2*n1)) [(ones(n1,1)) (zeros (n1,1)) (-dy); ...

(zeros(n1,1)) (ones(n1,1)) (dx)]; [(ones(1,n1)) (zeros(1,n1)); ...

(zeros(1,n1)) (ones(1,n1)); (-dy)’ (dx)’] (zeros(n2,n2))];

B= [(zeros (1,2*n1)) Ft_1]’;

60

if det(A)~=0

T=(A^-1)*B;

65 Tx=(T(1:n1));

Ty=(T(n1+1:2*n1));

Tprop=sqrt(((Tx).^2)+(Ty).^2);

70 alpha=atan2 (Ty,Tx);

M=-dy.*Tx+dx.*Ty;

59

A.3. SOURCE CODE GENERATION OF WAVES (WAVE02BS.M)

P=[P Tx Ty Tprop alpha];

75 Ft_0.P_desc=’P=[Number dx dy ForceX ForceY TotalForce Angle]’;

Ft_0.T=T;

Ft_0.A=A;

Ft_0.B=B;

Ft_0.Tf=Tf;

80 Ft_0.Tx=Tx;

Ft_0.Ty=Ty;

Ft_0.dx=dx;

Ft_0.dy=dy;

Ft_0.P=P;

85 Ft_0.M=M;

Ft_0.dxa=dxa;

Ft_0.dya=dya;

Ft_0.Tfa=Tfa;

Ft_0.Tprop=Tprop;

90 Ft_0.alpha=alpha;

Pout=P;

end

A.3. Source Code Generation of Waves (wave02bs.m)

1 function [wave]=wave02bs (input);

time=input(1);

phi=input(2);

5 global phaseww;

% Hier wird die Welle nach dem Schema JONSWAP simuliert.

Hs=7.8; % Signif. Wellenhoehe

10 T0=16.20; % Modales Spektrum

T1=0.834*T0; % Mittl. Periodenlaenge

60

A.4. SOURCE CODE PROPDIR.M

gamma=3.3;

deltaomega=0.1;

15 step=round(2*pi/deltaomega);

if mod(time,step)<=1e-5;

phaseww=2*pi*rand(7,3);

end

20 RAO = [.3 .4 .5 .6 .7 .8 .9;... %omega

.9 .74 .58 .42 .26 .1 .1;... %x

.95 .72 .52 .35 .22 .12 .04;... %y

.16 .06 .07 .07 .06 .07 .07]’; %phi

25 omega=RAO(:,1);

sigma = 0.07 + (omega<=5.24/T1)*0.02;

Y=exp(-((0.191.*omega*T1-1).^2./(sqrt(2)*sigma)));

S=155*Hs^2./((omega.^5)*T1^4).*exp(-944./((omega.^4)*T1^4)).*gamma.^Y;

30 x1=(omega).^2.*sqrt(2*S.*RAO(:,2).^2*deltaomega).*cos(omega.*time+phaseww(:,1));

x2=(omega).^2.*sqrt(2*S.*RAO(:,3).^2*deltaomega).*cos(omega.*time+phaseww(:,2));

x6=(pi/180)*(omega).^2.*sqrt(2*S.*RAO(:,4).^2*deltaomega).*cos(omega.*time+phaseww(:,3));

wave=[(sum(x1)*cos(phi)) (sum(x2)*sin(phi)) (sum(x6)*sin(2*phi))];

A.4. Source Code propdir.m

1 function [direction]=propdir (phi);

%propdir determines the right rotation direction of the azimut

%[direction] propdir ([phiref, phireal])

%direction = 1 anti-clockwise

5 %direction = -1 clockwise

%direction = 0 don’t rotate

ps=phi(1);

61

A.5. SOURCE CODE ITFDISC.M

pr=phi(2);

10

%$if (ps~=pr)

if ((abs(ps-pr))>=10^(-4))

if (ps>pr)

15 if ((ps-pr)<=pi)

direction=1; %1=links rum, -1 rechts rum, 0 keine drehung

else

direction=-1;

end

20 else

if ((pr-ps)<=pi)

direction=-1;

else

direction=1;

25 end

end

else

direction=0;

end

30

A.5. Source Code itfdisc.m

1 % Controller Optimization. In this case PD.

clear rho;

hold off

5 plot (td,yd,’red’);

hold on;

%Startvector

62


10 Kp=1; %start kp

Kd=1; %start kd

deltaT=0.01;

15

%Ri=[1 0; 0 1];%search direction

gamma=1; %step size

Ly=1; %frq. weighting factor

Lu=1; %frq. weighting factor

20 lambda=0; %control weighting

%simparameter

25 accuracy=0.01; %genauigkeit

endtime=10; %simulationsendzeit

amplitude=1;

%%%% controller has to be known.

30

C=tf([Kp+Kd/deltaT -Kd/deltaT], [1 0],deltaT); %Controller Function

dC_drho=tf ({[1]; [1 -1]}, {1;[deltaT 0]},deltaT); %derivative of C

35 dy_drho_i=1/C*dC_drho

first=3; %display the first n steps

40 solved=0;

%%%

i=0;

63


rho(:,1)=[Kp;Kd];

45 while (solved==0)

i=i+1;

Kp=rho(1,i);

Kd=rho(2,i);

50

C=tf([Kp+Kd/deltaT -Kd/deltaT], [1 0],deltaT); % contr. function

dC_drho=tf ({[1]; [1 -1]}, {1;[deltaT 0]},deltaT); %der. of C

55

t=[0:accuracy:endtime]’;

r=amplitude * ones(length(t),1);

[t1,x1,y1,u1,fake1,fake2]=sim(’piditfdisc’);

60

r1 = interp1(t,r,t1,’cubic’);

r=r1-y1;

t=t1;

65 [t2,x2,y2,u2,du_drho_i,dy_drho_i]=sim(’piditfdisc’);

ydi=interp1(td,yd,t2,’cubic’); %interpolate to same time-base t2

y1i=interp1(t1,y1,t2,’cubic’);

ytil=y1i-ydi;

70 %%%

% ytil, y1,y2

if max(abs(ytil))<=0.01

75 disp(’solved’);

solved=1;

end

64


dJ_drho_i=ytil’*dy_drho_i/length(ytil)

80

%Ri=dy_drho_i’*dy_drho_i/length(dy_drho_i)+lambda*du_drho_i’*du_drho_i/length(du_drho_i) %Gauss-Newton

Ri=dy_drho_i’*dy_drho_i/length(dy_drho_i)

rho(:,i+1)=rho(:,i)-gamma*(Ri^-1)*dJ_drho_i’

85 disp(’max ytil: ’); max(abs(ytil))

if (first~=0)

plot (t1,y1);

first=first-1;

end

90

if (mod(i,10)==0)

plot (t1,y1);end

end

plot (t1,y1);

95

100

65

B. Matlab Fuzzy Functions

Figure B.1.: Membership function Input xdiff

Figure B.2.: Membership function Input xdiff

WENN deltaX==negativ DANN Fx=negativ

WENN deltaX==positiv DANN Fx=positiv

WENN deltaX==positiv nahe AND xpunkt==positiv DANN Fx=negativ

66

WENN deltaX==positiv nahe AND xpunkt==negativ DANN Fx=positiv

WENN deltaX==negativ nahe AND xpunkt==positiv DANN Fx=negativ

WENN deltaX==negativ nahe AND xpunkt==negativDANN Fx=positiv

Figure B.3.: Membership function zur Bewertung der Ausgangsgroße Fx

Figure B.4.: Matlab Fuzzy Ruleviewer

67

C. Communication

C.1. Source Code Avr p13.c

1 /*********************************************

This program was produced by the

CodeWizardAVR V1.24.0 Standard

Automatic Program Generator

5 c© Copyright 1998-2003 HP InfoTech s.r.l.

http://www.hpinfotech.ro

e-mail:[email protected]

Project :

10 Version :

Date : 11/1/2005

Author : Burkhard Sommer

Company :

Comments:

15

Chip type : ATmega32

Program type : Application

Clock frequency : 3,690000 MHz

20 Memory model : Small

External SRAM size : 0

Data Stack size : 512

*********************************************/

25 #include <mega32.h>

68

C.1. SOURCE CODE AVR P13.C

#include <delay.h>

#define RXB8 1

#define TXB8 0

30 #define UPE 2

#define OVR 3

#define FE 4

#define UDRE 5

#define RXC 7

35

#define FRAMING_ERROR (1<<FE)

#define PARITY_ERROR (1<<UPE)

#define DATA_OVERRUN (1<<OVR)

#define DATA_REGISTER_EMPTY (1<<UDRE)

40 #define RX_COMPLETE (1<<RXC)

//User defined...

45 #define COMMAND_LENGTH 4 //in bytes

#define INIT 0

#define LISTEN 1

#define RECEIVE 2

#define COMMANDRECEIVED 3

50 #define NOWAITCLOSE 4

#define COMMOK 255

#define COMMNOTOK 0

#define OVERFLOW 1

55

//User defined...

// USART Receiver buffer

#define RX_BUFFER_SIZE 48

69


60 char rx_buffer[RX_BUFFER_SIZE];

unsigned char rx_wr_index,rx_rd_index,rx_counter;

// This flag is set on USART Receiver buffer overflow

bit rx_buffer_overflow;

65 // USART Receiver interrupt service routine

#pragma savereg-

interrupt [USART_RXC] void usart_rx_isr(void) //***LOW-LEVEL Kommunikation***

{

char status,data;

70 #asm

push r26

push r27

push r30

push r31

75 in r26,sreg

push r26

#endasm

status=UCSRA;

data=UDR;

80 if ((status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN))==0)

{

rx_buffer[rx_wr_index]=data;

if (++rx_wr_index == RX_BUFFER_SIZE) rx_wr_index=0;

if (++rx_counter == RX_BUFFER_SIZE)

85 {

rx_counter=0;

rx_buffer_overflow=1;

};

};

90 #asm

pop r26

out sreg,r26

pop r31

70


pop r30

95 pop r27

pop r26

#endasm

}

#pragma savereg+

100

#ifndef _DEBUG_TERMINAL_IO_

// Get a character from the USART Receiver buffer

#define _ALTERNATE_GETCHAR_

#pragma used+

105 char getchar(void)

{

char data;

while (rx_counter==0);

data=rx_buffer[rx_rd_index];

110 if (++rx_rd_index == RX_BUFFER_SIZE) rx_rd_index=0;

#asm("cli")

--rx_counter;

#asm("sei")

return data;

115 }

#pragma used-

#endif

120

// Standard Input/Output functions

#include <stdio.h>

125 // Declare your global variables here

int timeroverflow;

71


130

// Timer 0 overflow interrupt service routine //****Fur TIMOUT seriell****

interrupt [TIM0_OVF] void timer0_ovf_isr(void)

{

// Place your code here 8 Bit timer

135 timeroverflow=1;

//printf("TIMEOUT");

}

140

typedef struct{

int state;

int command[COMMAND_LENGTH];

145 int input,output,bytecounter;

int commandreceived;

} Comm;

150 void Init_Comm(Comm *comm){

comm->state=LISTEN;

comm->bytecounter=0;

comm->commandreceived=0;

}

155

//8bit

160 void CommTimerStart(){

TCCR0=0x05; //Timer running CLK/1024

72


}

void CommTimerReset(){

timeroverflow=0;

165 TCCR0=0x00; //Timer Stopped

}

//8bit

170 void Controller(){

delay_ms(50);

PORTC=~(PORTC ^ 0xFE); //invertiertes XOR. Nur bit,

delay_ms(50); //was auf Null ist, soll geaendert werden.

PORTC=~(PORTC ^ 0xFE); //Blinken einer LED.

175 //Nur ubergangsweise, um zu sehen, dass der

} //Algorithmus nicht dauerhaft unterbrochen wird.

void processcmd(Comm *comm){

180 int i;

if (comm->state==COMMANDRECEIVED){

for (i=0; i<=3; i++) { //Was soll mit dem Befehl gemacht werden?

//printf("Command: %d \n\r",comm->command[i]);

185 }; //for

comm->state=LISTEN;

}; //if

190 }

void main(void)

{

195 // Declare your local variables here

73


Comm comm;

Init_Comm(&comm);

timeroverflow=0;

200

// Input/Output Ports initialization

// Port A initialization

// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=In Func6=In Func7=In

// State0=T State1=T State2=T State3=T State4=T State5=T State6=T State7=T

205 PORTA=0x00;

DDRA=0x00;

// Port B initialization


210 // State0=T State1=T State2=T State3=T State4=T State5=T State6=T State7=T

PORTB=0x00;

DDRB=0x00;

// Port C initialization

215 // Func0=In Func1=In Func2=In Func3=In Func4=In Func5=In Func6=In Func7=In


PORTC=0x0F;

DDRC=0xFF;

220 // Port D initialization



PORTD=0x00;

DDRD=0x00;

225

// Timer/Counter 0 initialization

// Clock source: System Clock

// Clock value: Timer 0 Stopped

// Mode: Normal top=FFh

74


230 // OC0 output: Disconnected

TCCR0=0x00;

TCNT0=0x00;

OCR0=0x00;

235



// Clock value: 3,604 kHz

// Mode: Normal top=FFFFh

240 // OC1A output: Discon.

// OC1B output: Discon.

// Noise Canceler: Off

// Input Capture on Falling Edge

TCCR1A=0x00; // Timer

245 TCCR1B=0x00; // stopped

TCNT1H=0xF8; // Initial

TCNT1L=0xFB; // Value

ICR1H=0x00;

ICR1L=0x00;

250 OCR1AH=0x00;

OCR1AL=0x00;

OCR1BH=0x00;

OCR1BL=0x00;

255



// Clock value: Timer 2 Stopped

260 // Mode: Normal top=FFh

// OC2 output: Disconnected

ASSR=0x00;

TCCR2=0x00;

75


TCNT2=0x00;

265 OCR2=0x00;

// External Interrupt(s) initialization

// INT0: Off

// INT1: Off

270 // INT2: Off

MCUCR=0x00;

MCUCSR=0x00;

275 // Timer(s)/Counter(s) Interrupt(s) initialization TIMER

//TIMSK=0x04; //16 bit t1

TIMSK=0x01; //8 bit timer overflow

280 // USART initialization

// Communication Parameters: 8 Data, 1 Stop, No Parity

// USART Receiver: On

// USART Transmitter: On

// USART Mode: Asynchronous

285 // USART Baud rate: 9600

UCSRA=0x00;

UCSRB=0x98;

UCSRC=0x86;

UBRRH=0x00;

290 UBRRL=0x0B;

// Analog Comparator initialization

// Analog Comparator: Off

// Analog Comparator Input Capture by Timer/Counter 1: Off

295 // Analog Comparator Output: Off

ACSR=0x80;

SFIOR=0x00;

76


// Global enable interrupts

300 #asm("sei")

305 while (1)

{

if (timeroverflow==1) {comm.state=LISTEN; CommTimerReset();}

310

if (rx_counter > 0){ //counter //***HIGH-LEVEL Kommunikation***

comm.input = getchar();

switch (comm.state) {

315 case LISTEN:

if (comm.input==COMMOK) {comm.state=RECEIVE;

//printf("Switching to RECEIVE STATE\r\n");

putchar(COMMOK); //ready to receive

CommTimerStart();}

320

break;

case RECEIVE:

325 //printf("Is Received \r\n");

comm.command[comm.bytecounter]=comm.input;

comm.bytecounter++;

if (comm.bytecounter==COMMAND_LENGTH) {

putchar(COMMOK);

330 comm.state=COMMANDRECEIVED;

comm.bytecounter=0;

77


CommTimerReset();

}

break;

335

case COMMANDRECEIVED:

putchar(COMMNOTOK); //not ready to receive new command

break;

340 }; //switch

PORTC=~(PORTC ^ 0xFD);

//printf("Received: %d ...\n\r",comm.input);

345

delay_ms(1); //Blinken einer LED,

PORTC=~(PORTC ^ 0xFD); //um Byteempfang anzuzeigen

350

}//counter

355 processcmd(&comm); //Empfangenen Befehl verarbeiten

Controller(); //Regelalgorithmus fortsetzen

};

360 }

78

C.2. CONFIGURATION OF DER REGISTERS:

C.2. Configuration of der Registers:

Serial Communication with Timeout Interrupt: Using an n Bit Timer, the Timer

while generate 2n ticks passing from the beginning to the end. This will take tc = pclkIO

·2n

seconds. p=prescaler.

With a clock speed of 3, 69 Mhz, 8 Bit and a prescaler of 1024 it will take almost 70ms.

Assuming a transfer rate of 19200 Baud it is theoretically possible to transfer 168 Byte

within this time window. I want to achieve the following settings: USART: Receive and

Transmit: On, Mode: Asyn, Rate: 19200, 8N1, Interrupt at timer overflow of Timer 0.

I use the following configuration:

7 6 5 4 3 2 1 0

TIMSK OCIE2 TOIE2 TICIE1 OCIE1A OCIE1B TOIE1 OCIE0 TOIE0

0 0 0 0 0 0 0 1

Timer/Counter0, Overflow Interrupt Enable TOIE1: Enable 8-Bit Timer 0 Overflow

Interrupt (Global Interrupts have to be enabled, too). All the other Timer Interrupts

are disabled.

7 6 5 4 3 2 1 0

TCCR0 FOC0 WGM00 COM01 COM00 WGM01 CS02 CS01 CS00

0 0 0 0 0 0/1 0 0/1

The bits 7-3 in TCCR0 control the PWM functionality. Since I just use its timer features,

only the bits CS02 and CS00 are used. Timer stopped: CS02 = CS00 = 0, Timer

enabled, internal clock, Prescaler 1024: CS02 = CS00 = 1. For further information see

the ATmega manual.

7 6 5 4 3 2 1 0

UCSRA RXC TXC UDRE FE DOR UPE U2X MPCM

0 0 0 0 0 0 0 0

UCSRA: Bit 7 – RXC: USART Receive Complete

Bit 6 – TXC: USART Transmit Complete

79


Bit 5 – UDRE: USART Data Register Empty

Bit 4 – FE: Frame Error

Bit 3 – DOR: Data OverRun

Bit 2 – PE: Parity Error

Bit 1 – U2X: Double the USART Transmission Speed

Bit 0 – MPCM: Multi-processor Communication Mode

7 6 5 4 3 2 1 0

UCSRB RXCIE TXCIE UDRIE RXEN TXEN UCSZ2 RXB8 TXB8

1 0 0 1 1 0 0 0

UCSRB: RXCIE: RX Complete Interrupt Enable=1,

TXCIE: TX Complete Interrupt Enable=0,

UDRIE: USART Data Register Empty Interrupt Enable=0,

RXEN: Receiver Enable=1,

TXEN: Transmitter Enable=1,

UCSZ2: Character Size (See UCSRC),

RX8B and TX8B: Have to be 1 when operating with serial frames of nine data bits.

This case: 0.

7 6 5 4 3 2 1 0

UCSRC URSEL/- UMSEL UPM1 UPM0 USBS UCSZ1 UCSZ0 UCPOL

1/0 0 0 0 0 1 1 0

UCSRC: ATmega 32: Bit 7=1, ATmega 64: Bit 7=0! No Parity (UPM1=UPM0=0),

1 Stop Bit (USBS=0), 8 Data Bit (UCSZ2=0 in UCSRB, UCSZ1=1 and UCSZ0=1).

UCPOL=0 since Async Mode is used.

UBRR: The register UBRR determines the Transfer Rate: Refer to the manual for

details. At 3,69 Mhz and 19200 Baud is has to be set to 0x000B.

80


7 6 5 4 3 2 1 0

UBRRH – – – – UBRR11 UBRR10 UBRR9 UBRR8

0 0 0 0 0 0 0 0

UBRRL UBRR7 UBRR6 UBRR5 UBRR4 UBRR3 UBRR2 UBRR1 UBRR0

0 0 0 0 1 0 1 1

81

List of Figures

1.1. Model of the platform 1:40 . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1. Simulink Complete System . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. PT2-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4. Velocity x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5. Velocity y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6. Angle velocity φ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7. 3D simulation output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.8. Platform, coordinates and positions of the propellers . . . . . . . . . . . 14

3.1. System response of a PT1-System . . . . . . . . . . . . . . . . . . . . . . 21

3.2. Delay of angle velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3. Demanded force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4. Resulting force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1. Unimodal Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2. Response of Surge x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3. Response of Sway y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4. Response of Surge φ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1. Usual controlling system . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2. Blockschaltbild des ITF-Systems . . . . . . . . . . . . . . . . . . . . . . . 37

5.3. Systemantwort nach Optimierung (Startwert: Kp = 1, Kd = 0.1, Ki = 1),

5 Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

82

List of Figures

5.4. Systemantwort nach Optimierung (Startwert: Kp = 0.1, Kd = 0.1, Ki =

0.1), 6 Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.5. Systemantwort P13 auf Einheitsprung ITF . . . . . . . . . . . . . . . . . 41

5.6. Matlab Optimization Toolbox . . . . . . . . . . . . . . . . . . . . . . . . 42

5.7. Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.8. System response on stimulus . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.9. System response with coupling delay . . . . . . . . . . . . . . . . . . . . 44

5.10. Trajectory with old parameters (Position 50,50,pi) . . . . . . . . . . . . 45

5.11. Trajectory with new parameters (Position 50,50,pi) . . . . . . . . . . . . 45

6.1. Principle System Configuration . . . . . . . . . . . . . . . . . . . . . . . 47

6.2. Process-Time-Diagram Low-Level Serial Communication . . . . . . . . . 50

6.3. Statemachine of the High-Level Serial Communication . . . . . . . . . . . 51

6.4. TWI Bus Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B.1. Membership function Input xdiff . . . . . . . . . . . . . . . . . . . . . . 66

B.2. Membership function Input xdiff . . . . . . . . . . . . . . . . . . . . . . 66

B.3. Membership function zur Bewertung der Ausgangsgroße Fx . . . . . . . . 67

B.4. Matlab Fuzzy Ruleviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

83

Bibliography

[1] HEIMANN/GERTH/POPP, Mechatronik, Komponenten - Methoden - Beispiele,

Fachbuchverlag Leipzig, 2000

[2] J.M.J. JOURNEE / W.W. MASSIE, Offshore Hydromechanics, Delft University of

Technology, 2001

[3] M.S. TRIANTAFYLLOU F.S. HOVER, Maneuvering and Control of Marine Ve-

hicles, Department of Ocean Engineering, MIT, 2002

[4] H.HAASE, Messtechnik II, Messeigenschaften dynamischer Systeme, Skript zur

Vorlesung, GEML, Universitat Hannover, 2002

[5] W.GERTH, Regelungstechnik I, Ubungsumdruck, IRT, Universitat Hannover, 2001

[6] W.GERTH, Regelungstechnik II, Vorlesungsumdruck, IRT, Universitat Hannover,

2000

[7] THE MATHWORKS INC., Fuzzy Logic Toolbox User’s Guide, 2002

[8] MARIN, Maritime Research Institute Netherlands, Report No. 14493-1-GT.

[9] S.MOTTA, Posicionamento Dinamico de Plataformas Semi-submersıveis em Ambi-

ente Multi-direcional. Tese de Mestrado. Programa de Engenharia Naval, COPPE,

UFRJ, 2003, Rio de Janeiro, RJ - Brasil.

[10] G.STRANG, Introduction to Applied Mathematics, Wellesley-Cambridge Press

Cambridge, MA 02139 USA, ISBN 0-9614088-0-4

[11] G. ARFKEN, ”Lagrange Multipliers.” §17.6 in Mathematical Methods for Physi-

cists, 3rd ed. Orlando, FL: Academic Press, pp. 945-950, 1985

84

Bibliography

[12] Z-World and Rabbit Semiconductors, Rabbit Board User Manual , 2004

[13] H.HJALMARSSON, M.GERVERS and O.LEQUIN, Iterative Feedback Tuning:

Theory and Applications, IEEE Control Systems Magazine, August 1998

[14] H.HJALMARSSON, T. BIRKELAND, Iterative Feedback Tuning of Linear Time-

Invariant MIMO Systems, CDC 98, 1998

[15] ATMEL Corporation, ATMEL Mega64 Documentation, doc2503.pdf, 2004

85

Relatorio Ingles

Documents

Transcript of Relatorio Ingles