FRT090 Projects in Automatic Control

Control of a full scale Segway

Date: 7-6-2010

By:

Erik Torstensson, F06

Babak Rajabian, E06

Johan Andersson, E06

Kujtim Iljazi, E00

Advisor: Erik Johannesson

1

Acknowledgments We would like to thank our supervisor Mr. Erik Johannesson for the valuable advice and

support he has given us in this project.

We would also like to thank Mr. Johan Åkesson and Mr. Daria Madjidian for their

encouragement and guidance.

Special thanks to Mr. Anders Robertsson who always showed his interest for the project and

always in any time helped us through obstacles that made the project to stand still. He also

gave us valuable advice and support during the project.

2

Abstract This project was to investigate and implement different possible controllers for the Segway

(ElektorWheelie) to stabilize the process. In order to find the most efficient controller we

started with investigate LQR controller. The main findings were that the most effective

controller was an LQR-controller with Kalman-filtering.

3

Contents Acknowledgments .................................................................................................................................... 1

Abstract .................................................................................................................................................... 2

1. Introduction .......................................................................................................................................... 4

1.1 The hardware ................................................................................................................................. 4

1.1.1 Motors .................................................................................................................................... 4

1.1.2 Energy source ......................................................................................................................... 4

1.1.3 Sensors and CPU ..................................................................................................................... 4

1.1.4 Software .................................................................................................................................. 4

1.2 How does it work?.......................................................................................................................... 5

2. Objectives ............................................................................................................................................. 6

2.1 Analyze ........................................................................................................................................... 6

2.2 Research ......................................................................................................................................... 6

2.3 Computing ...................................................................................................................................... 6

2.4 Programming .................................................................................................................................. 6

3. Theory ................................................................................................................................................... 7

3.1 inverted pendulum ......................................................................................................................... 7

4. The model ............................................................................................................................................. 9

4.1 mat mod ......................................................................................................................................... 9

4.2 Matlab/Simulink model ................................................................................................................ 14

4.3 Motor identification ..................................................................................................................... 14

5. Methodology ...................................................................................................................................... 17

5.1 Safety during experiments ........................................................................................................... 17

5.2 State Estimation ........................................................................................................................... 17

5.3 LQR ............................................................................................................................................... 18

5.4 Filters ............................................................................................................................................ 19

6. Time plan ............................................................................................................................................ 20

7. Findings ............................................................................................................................................... 21

7 .1 State estimation .......................................................................................................................... 21

7.2 LQR results ................................................................................................................................... 21

7.3 Filters ............................................................................................................................................ 22

8. Discussion ........................................................................................................................................... 23

8.1 Future improvements .................................................................................................................. 23

8.2 Sidetracks ..................................................................................................................................... 23

Reference ............................................................................................................................................... 24

4

1. Introduction

A Segway is a modern two-wheeled, self-balancing electric transport vehicle. The architect

construction and the technical architecture make the usage for the Segway very simple. To

make it go forward the user leans forward and to go backwards the user leans back.

Furthermore there is a so-called “lean steer”-handlebar that makes it possible for the user to

turn left or right by leaning it. (Websource1)

The ElektorWheelie is a Segway developed and produced by the German company “Elektor”.

ElektorWheelie is an open source product and makes it possible to reprogram and fill in with

new features. (ElektorWheelie - Elektor’s DIY self-balancing vehicle)

1.1 The hardware The construction of the ElektorWheelie is a rigid metal chassis. Inside this metal chassis

there are rechargeable cells and compact control electronics. (ElektorWheelie - Elektor’s DIY

self-balancing vehicle)

1.1.1 Motors

Inside the ElektorWheelie we find two 24V DC electric motors with an effect of 1 kW that

gives a maximum speed of 12 km/h (7.5 mph). The manufacturer of the motors is “Zhejiang

Unite Motor Co., Ltd” 1. (ElektorWheelie - Elektor’s DIY self-balancing vehicle)

1.1.2 Energy source

The energy source is two 12V rechargeable lead-acid gel cells2. The capacity varies

depending on driving style and road gradient. With full charged battery you can expect 1

hour to 1.5 hours of usage before recharging the batteries again. The manufacturer of the

batteries is unknown. The only fact there is “CTM in China”. (ElektorWheelie - Elektor’s DIY

self-balancing vehicle)

1.1.3 Sensors and CPU

The only sensor necessary is a 2-axis acceleration sensor and a gyro give the controllers

input data. The CPU is an Atmel AVR-mega32 and supplies commands to the motors to

maintain the correct inclination of the ElektorWheelie. The manufacturer for the 2-axis

acceleration sensor is “Analog Devices” and for the gyro it is “Invensense”. Atmel AVR is the

manufacturer for the CPU.

1.1.4 Software

The microcontroller, Atmel AVR-mega32, is programmed in BASCOM-AVR.

1 http://unitemotor.ec51.com/

2 http://en.wikipedia.org/wiki/VRLA_battery

5

1.2 How does it work?

Figure 1 - Simplified overview of the controlsystem

The process is very simple and this section will describe the model the very simple way it is.

When the user stands on the ElektorWheelie the process, the sensors gyro and

accelerometer, starts to give output data into the controller. Although the output depends

on the users balance and lean-angel, make left, right, forward or backwards. When the

controller have received the output data from the process as an input. It starts to calculate

the changes that have occurred, the different states3, and gives an output to the process,

which will be the input, as seen Figure 1. The input signal will be the changed variables,

which furthermore will make it possible to balance and perform the usage of the

ElektorWheelie.

3 For more information see section 4.1

6

2. Objectives The main objective for this project was to find a feasible controller that stabilizes the

ElektorWheelie in the best possible way. To be able to find the best feasible controller the

project was divided into several main objectives.

2.1 Analyze To be able to gathering information about what to determine and perform is to analyze the

Segway. Without analysis there is no information to build up any conclusions. Without

conclusions it’s hard to be able to make any decisions.

2.2 Research The objective for the research area was to understand the different parts in the Segway. The

main objective for the research part was to understand the technical information that was

given and try to find out some more. What includes for the technical information is for

instance how the sensors works, how the motors works, programming, mathematical

models for the Segway and analyze valuable data. Furthermore the given information given

during the research helped us to compute new information by our own knowledge.

2.3 Computing The computing is the most important objective. The purpose is to compute the values that

matters and affect the Segway. This part shows how the Segway acts depending on how the

values differ. Furthermore a precision on the computing is very important to make the

process as accurate as possible.

2.4 Programming To be able to use the ElektorWheelie it’s necessary to express all the computed and

determined parts into, in our case, BASIC with the BASCOM AVR language. So basically if

there is none computed parts there will not be any code to program since the programming

is based on the computed parts.

7

3. Theory To understand how the Segway works in detail it’s important to introduce the inverted

pendulum.

3.1 inverted pendulum You may have seen different kinds of implemented inverted pendulums i.e. Johan Åkessons

Two wheeled robot, Design and Control of YAIP4, but all gets to the same theory. An

inverted pendulum is a pendulum with its mass above its pivot point, see figure 2

(Websource2).

Figure 2 - Inverted pendulum on a linear chart - http://www-

srt.upb.de/fileadmin/SRT_Images/Rundgang/Pendel/pendulum_inv.gif

Compared to a normal pendulum whereas it’s stable when hanging the inverted pendulum is

normally unstable, therefore it must be actively balanced in order to remain the mass above

its pivot point. To be able to balance it you can either apply a torque at the pivot point or

move the pivot point horizontally, for example on a chart as part of a feedback system.

Figure 3 - Inverted pendulum on chart with wheels - http://en.wikipedia.org/wiki/File:Cart-pendulum.png

4 http://www.control.lth.se/documents/2006/ake+06cca.pdf

8

The inverted pendulum is a classic problem in control theory. The problem maintains the

same interest, i.e. used as a benchmark for testing control algorithms and therefore as

described above there is many variations. Furthermore the experimentations are wide

because of the widely usage of this problem, but except the Segway there is other areas of

the daily usage. For example the lifting cranes on shipyards during the transportation of

containers. The cranes move the box in such a precision that the containers never swings,

they are even perfectly positioned under the operator when moving or stopping the

containers quickly5 (Websource2).

5 http://en.wikipedia.org/wiki/Inverted_pendulum

9

4. The model

4.1 mat mod

DCxy

BA

xx

The kinetic energy equals to:

Er v2

2dm

(rw)2

2dm

w2

2r2dm

w2

2 I

With dmrI 2 ,which is the body’s moment of inertia

Figure 4 - Simplified overview of the Segway-states

10

The Lagrangian function will be L = Kinetic Energy – Potential Energy, following:

We have that:

v 2 d

dt(l cos())

2

d

dt(r lsin())

2

(l

sin())2 (r

l

cos())2

v 2 l2 2

(sin2() cos2()) r22

2r l

cos()

As we can see:

sin2()cos2(), equals to one:

sin2()cos2() 1

Therefore we get:

v2 l2 2

r2 2

2r l

cos()

We now get:

L 1

2Mr22

m

2l2 2

r22

2rl

cos()

mglcos()

L 1

2r22

(M m)ml2

2 2

mr l

cos() mglcos()

We now use Euler-Lagrange:

d

dt

L

L

d

dt

L

L

L Ek E p

L 1

2IM

2

mv 2

2mlgcos( )

With : IM M r2

11

We simplify the equations:

L

ml

2

mr l

cos()

L

mr l

sin() mlgsin()

L

r

2

(M m)mr l

cos()

L

0

d

dt

L

ml

2

mr l(

cos()

sin())

d

dt

L

r

2

(M m)mr l(

cos( ) 2

sin())

d

dt

L

m l2

mr l(

cos( )

sin( ))

d

dt

L

r2

(M m) mr l(

cos( ) 2

sin( ))

d

dt

L

L

ml2

mr l(

cos()

sin( )) mr l

sin( ) mlgsin()

d

dt

L

L

r2

(M m) mr l(

cos() 2

sin( )) 0

d

dt

L

L

m l2

mr l

cos( ) mlgsin()

d

dt

L

L

r2

(M m) mr l

cos() mr l 2

sin( )

We now have:

d

dt

L

L

ml2

mr l

cos() mlgsin()

d

dt

L

L

r2

(M m)mr l

cos() mr l 2

sin()

For small angles we have:

sin()

and

cos() 1

12

Therefore we can rewrite the equations as:

d

dt

L

L

ml2

mr l

mlg

d

dt

L

L

r2

(M m)mr l

mr l 2

Furthermore we have:

ml2

mr l

mlg

r2

(M m) mr l

mr l 2

When we linearize we have:

ml2

mr l

mlg (1)

r2

(M m) mr l

(2)

If we now solve

and put into (1) we get:

r2(M m)

mr l

r2(M m)

Now insertion in (1) will give us:

m l2

m lg mr l

r2(M m)

mr l

r2(M m)

m l2 m2 r2 l2

r2(M m)

m lg

mr l

r2(M m)1

m l2r2(M m) m2 r2 l2

r2(M m)

m lg

r2(M m) mr l

r2(M m)

(M m)g

M l

r(M m) m l

r l2Mm

13

Now, insertion of

into (2) will give us:

r2

(M m) mr l(M m)g

M l

r(M m)ml

r l2Mm

r2(M m)

mr l

r2(M m)

(M m)g

M l

r(M m)ml

r l2Mm

We can simplify this:

1

r2(M m)

mr l

r2(M m)

r(M m)

Mmrl2

mr l

r2(M m)

ml

Mmrl2

mg

M r

Mmr l2 mr2l(M m)m2 r l2

r2(M m)Mmr l2

mg

M r

M l2 M rlmr l ml2

r2(M m)M l2

mg

M r

l2(M m) (M m)r l

r2(M m)M l2

mg

M r

(l2 r l)(M m)

r2(M m)M l2

mg

M r

(l2 r l)

r2M l2

mg

M r

l r

r2M l

mg

M r

l r

r2l M

mg

M r

14

So, now we have:

(M m)g

M l

r(M m)ml

r l2Mm

l r

r2l M

mg

M r

If we introduce:

x1

x2

x3

x4

x1

x2

x2

x3

x4

x4

We can rewrite:

(M m)g

M l

r(M m)ml

r l2Mm

l r

r2l M

mg

M r

Into a state-space form:

x1

x2

x3

x4

0 1 0 0(M m)g

M l0 0 0

0 0 0 1

mg

M r0 0 0

x1

x2

x3

x4

0

(M r mr ml)

Mml2r

0r l

M l r2

Which is

x

Ax B

4.2 Matlab/Simulink model The statespace model and the motor model of the Elektor Wheelie where combined and

added to a Matlab script. This made it easy to develop and test the LQED estimater, LQRD

controller and the moving average filters on real data from the sensors and motors PWM

from the Wheelie. Being able to get nice plots.

4.3 Motor identification A DC motor model relating the applied voltage to the motor and parameters in the state

space to the resulting torque of the motor

𝜏 = −𝛽1 𝜑 − 𝜃 + 𝛽2𝑢

15

To estimate 2 a voltage to the motor was applied and then measuring the torque required

stopping the wheel from spinning. This was done for different voltages. The resulting points

are interpolated with a first degree linear polynomial. The resulting figure for the Elektor

Wheelie motor is in Figure 5 for 2. With a 2 = 3.6136 Nm/Volts.

Figure 5 - Plot of the resulting torque versus applied voltage of the Elektor Wheelie DC motor

The parameter 1 in the DC motor model is estimated by measuring the revolutions of the

wheel in radianse after applying a voltage to the DC motor. Having a estimate of 2 and

letting the wheel spinn without applying a stopping torque the parameter 1 can be solved

for. The results after experiments are in Figure 6.

0 5 10 15 20 25-10

0

10

20

30

40

50

60

70

80

90Torque vs Voltage: Torque = 3.6136 * Volt - 1.4411

Voltage [Volt]

Torq

ue [

Nm

]

16

Figure 6 - ters

0 5 10 15 20 25-0.2

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6Scatterplot of Beta1: Mean value = 0.3626

Measurement

Beta

1

17

5. Methodology The methods were in general to derive controller offline using Matlab, and later test the

controller on the real process, with some safety measures.

5.1 Safety during experiments Because the Elektor Wheelie weighs 35kg and has two 450W DC motor it is a dangerouse

thing and can hurt people. This is why the power to the DC motors goes through a relay

controlled by the rider of the Wheelie with a handbrake switch. It is a mechanical solution

not affected by the firmware in the Wheelie. In parallel to the handbrake was also a

killswitch button serving as a dual killswitch for the power to the motors. This killswitch can

be removed manually. During motorparameter identification the Wheelie was raised from

the ground to make it safe and easy to measure the parameters. When developing the

controller the serialport data from the wheelie displaying the motor PWM is a must to be

safe.

5.2 State Estimation

To be able to control the segway it is crucial to know the angle and the angle velocity

for the segway body. The only two sensors that were used were a gyroscope and an

accelerometer. A number of different ways of estimating these states were

considered during the project. The first way was a complementary function where

the accelerometer is used for low frequencies and the gyroscope is used for high

frequencies. In that way each sensor is used in the area in which they have good

properties. The second way is to use a kalman filter on the mathematical model with

the gyroscope as an input for angle velocity and the accelerometer as an input for

the angle. The third and last way and the way that was chosen for this project is to

use the fact that the accelerometer and gyroscope can be described by the following

equations.

𝑦𝑔𝑦𝑟𝑜 = 𝛩 + 𝑑 + 𝑤1(1)

𝑦𝑎𝑐𝑐 = 𝛩 + 𝑣1(2)

𝛩

d =

0 −10 0

𝛩𝑑 +

10 𝑦𝑔𝑦𝑟𝑜 + 𝐺

𝑤1

𝑤2

𝑦𝑎𝑐𝑐 = 1 0 𝛩𝑑 + 𝑣1

This is a system with the gyroscope signal as input and accelerometer signal as

output and hence a kalman filter can be derived to estimate the states. Equation (1)

describes the signal from the gyroscope really good, the angle velocity but with a

drift is exactly what this signal is. Equation (2) is not that good as the accelerometer

is really measuring both the angle and the acceleration when the segway is going

backwards and forwards. The acceleration is because of this considered as noise.

18

The next thing to be done is to make a kalman filter for this system. As this system is

written in normal state space form this is not very hard to achieve. Below are the

system equations for a kalman filter.

𝑥 = 𝐴𝑥 + 𝐵𝑢 + 𝐾(𝑦 − 𝐶𝑥 )𝑦 = 𝐶𝑥

This can be written as

𝑥 = (𝐴 − 𝐾𝐶)𝑥 + 𝐵𝑢 + 𝐾𝑦𝑦 = 𝐶𝑥

The estimation of the states angle and drift from the kalman filter is then actually the

output from the following system.

𝛩

𝑑 = 𝐴𝑒 𝛩

𝑑 + 𝐵𝑒

𝑦𝑔𝑦𝑟𝑜𝑦𝑎𝑐𝑐

𝑦 = 𝐶𝑒 𝛩

𝑑

With 𝐴𝑒 = 𝐴 − 𝐾𝐶 𝐵𝑒 = 𝐵 𝐾

𝐶𝑒 = 1 00 1

The only thing that is needed know to get this system is the K which completes this

kalman filter. The Matlab command lqe was used to get a good K. After this the

continuous system has to be discretizised which was done with the Matlab command

c2d. Actually these two commands were used over and over again and the kalman

filter was then tested in Matlab with some data which was collected from the actual

process. This way the inputs to the lqe command was tuned to get a good kalman

filter.

5.3 LQR To control the process, state feedback was used where the gain on different states was

calculated with a discrete linear quadratic regulator in Matlab, based on the mathematical

model of the process and the motor. The feedback gains on different states are calculated

offline in Matlab with the command lqrd. This control gives feedback on all the three states

(body angle, body angle rate, and wheel angle rate).The lqrd needs some design parameters

on the weighting matrices for both the importance of states, and the cost of the control

signal. The feedback vector L is then used to close the loop with the feedback law

(1) 𝑢 = −𝐿𝑥

Where L minimizes the cost function

(2) 𝐽 = 𝑥𝑇Q 𝑥 + 𝑢𝑇𝑅 𝑢 𝑑𝑡∞

0

Q is the weighting of the states and R is the cost of control signal.

19

5.4 Filters

Sensors often have some kind of noise and sometimes it is needed to filter the

signals. On the process concerned in this project there are three sensors. The

gyroscope, the accelerometer and the rocker. All three of them needed some kind of

low pass filter because of some high frequency noise. Especially the accelerometer

had to be filtered as the signal also consists of the acceleration which is considered

as noise. The acceleration was seen as big spikes in the signal and these spikes

occurred because of some backlash in the motors making the segway to shake while

standing still. There is almost an infinite amount of low pass filters to choose from

but some sophisticated filter is not needed in this case. The reason for this is that a

perfect signal is not needed and it will be implemented in a microcontroller. The kind

of filter chosen was an easy moving average filter.

20

6. Time plan The project was lagging behind the original time plan quite early due to mathematical model

taking a bit longer then we thought. This made us abandon our plans on testing different

kind of controllers and we went straight for LQR. A lot of time was spent trying to derive and

implement a controller in Simulink. After a couple of weeks we were more and more lacking

behind our time plans, we realized that we were travelling down a sidetrack. In study week 7

we made a big breakthrough and the segway could stabilize. We had thus used up both of

our reserve weeks and still got a report to finish. Testing different controllers, as well as

improving steering and start up did not get the time that we had wished.

21

7. Findings

7 .1 State estimation

We tuned the kalman filter quite a bit to get a good estimation. To tune the filter

there is three weights that are changed to get a good explanation of how much noise

there is on each signal. We knew that we should trust the gyroscope more than the

accelerometer because the accelerometer has dynamics not described in the model.

The weight on the drift was known to be quite small as the drift is a slow change in

the gyroscope. After some tuning we got the following.

𝛩

𝑑 =

0 −10 0

𝛩𝑑 +

10 𝑦𝑔𝑦𝑟𝑜 + 𝐺

𝑤1

𝑤2

𝑦𝑎𝑐𝑐 = 1 0 𝛩𝑑 + 𝑣1

𝐸(𝑤𝑤𝑇) = 𝑄 = 1 00 4

𝐸(𝑣𝑣𝑇) = 𝑅 = 10

Here the first element in Q is saying how big the noise is on the gyroscope; the last

element in Q is how big the noise is on the drift, i.e. how fast the drift is changing. R

is saying how big the noise is on the accelerometer. As can be seen the parameters

we finally settled for is kind of expected with a large noise on the accelerometer, this

is basically saying that we trust more on the gyroscope. With these inputs to the lqe

command we get 𝐾 = (1.1683 − 0.6325)𝑇which get the following kalman filter.

𝛩

𝑑 =

−1.1683 −10.6325 0

𝛩𝑑 +

1 1.16830 −0.6325

𝑦𝑔𝑦𝑟𝑜𝑦𝑎𝑐𝑐

𝑦 = 1 00 1

𝛩𝑑

When this system is discretizised with the sample time of ten milliseconds we get the

following system.

𝛩

𝑑 =

0.9884 −0.0099420.006288 1

𝛩𝑑 +

0.009942 0.011653.15e − 005 −0.006288

𝑦𝑔𝑦𝑟𝑜𝑦𝑎𝑐𝑐

𝑦 = 1 00 1

𝛩𝑑

This system was then implemented in the microcontroller.

7.2 LQR results In the end, feedback was only used on two of the three states. The reason for not using

feedback on the wheel angle rate is both that a sensor for good measurement was lacking to

22

do so. Estimation of the wheel velocity was made based on the mathematical model and the

estimation of 𝛩 and 𝛩 that was made in the LQE kalman filter, these estimation seemed

however to be a bit unreliable and was disregarded in the feedback loop after some testing.

Another reason to not use the third state in the feedback is that the controller would then

like to force the segway to stand still, which apparently is not optimal for a transportation

vehicle.

The weightings were made so that the body angle 𝛩 was most important to control to the

reference value (upright position), and the weighting on the third state was put to zero.

The Q matrix was chosen as

𝑄 = 700 0 0

0 0.01 00 0 0

and R = 0.05 which resulted in the gain matrix

𝐿 = −155.9850 −28.5053 −0.7061

(only first two states used).

7.3 Filters

As said before we chose a moving average filter for our sensors. A moving average

filter can be implemented in a number of different ways but as this is done online we

can only use old data for filtering. There is also different ways to implement an online

moving average filter with for example different weights for older data and so on. We

chose the easiest one with the weight one for every old data. To save memory in the

microcontroller we did not save all the old data but instead we had a sum which we

updated in the following way.

𝑆 𝑘 =𝑛 − 1

𝑛𝑆 𝑘 − 1 + 𝑦 𝑘

Where n is the number of data points we take the average over.

𝑦𝑎𝑣𝑔 (𝑘) =𝑆(𝑘)

𝑛

We averaged the gyroscope and the accelerometer over twenty data points and the

rocker over ten data points. As a moving average filter like this actually delays the

real signal, we had to find a number where we had a good low pass filtering and at

the same time not a too long delay. We found out that as we had a delay on the

signals with this filter we really had to have the same length both on the gyroscope

and the accelerometer. If we did not have this the signals was not working together

and we did not get a good estimation.

23

8. Discussion The segway ended up with a state feedback controller where two out of three states was

used. The final code did succeed with both the balancing problem, and even removed a big

part of the “backlashing”-like effect that occur. The segway now demands more tilt to get to

same speeds as the original code did. We spent a lot of time on the mathematical model

aswell as the simulink models. However our simulink models were build with two Kalman

filters, a method we later threw away. After that sidetrack was corrected, it went quite fast

and only fine tuning remained.

The things that have made the biggest improvements in comparison to prior code are the

filtering that we applied to the steering, and the ramping of the control signal during the

start up.

8.1 Future improvements There are still elements in our controller that can be improved. For example how aggressive

the steering should be at different speeds and how much the speed changes when you lean

forward and backwards. The startup could also be improved further to make it easy when

stepping on the Wheelie. Hardware to simplify adding these features would be an encoder

giving a voltage proportional to the wheel. An extra step-on button for detecting when both

feet are on the segway. That would be nice. A means to measure the voltage and current to

the motors would be a nice added feature. Right now you can only receive RS232 data from

the Wheelie. A nice feature would be to also send data to the Wheelie.

8.2 Sidetracks For quite some time in the middle of the project we tried to use two different Kalman filters,

one that was based on the Kalman filter in YAIP by Johan Åkesson, and one that calculated

all three states based on the mathematical model we had derived. The original reason for

these attempts where that we wanted to estimate the wheel angular velocity as well as the

two other states. Our simulink models used this method. When we finally removed this filter

and only used the feedback that was calculated from the mathematical model we

implemented it on the real process due to time limit.

Another sidetrack we explored was how the different states were declared. More specifically

we initially used 𝛳 ,𝛳 , x and 𝑥 where x and 𝑥 is the forward position and velocity.

It is of course closely related to wheel angle, and wheel angle rate, and the reason we chose

wheel angle was mainly to make the comparison of our mathematical model with known

models easier.

24

Reference

Websource1: (2010-06-08) - http://en.wikipedia.org/wiki/Segway_PT

Websource2: (2010-06-08) - http://en.wikipedia.org/wiki/Inverted_pendulum