Preliminary Report

Preliminary Report

November 18

2011 A balancing robot provides several benefits compared to standard three or more wheeled models, the main being a more closely holonomic robot. Throughout the report, an in depth analysis will be carried on the design, simulation to be able to arrive at a functional prototype.

Balancing Robot Design and Development

Author: Miguel Bernardo Student number: 41235 Unit co-ordinator: Dr Alan Hewitt Supervisor: Dr Djamel Azzi Unit: M586L

University of Portsmouth

School of Engineering

Meng Electronic and Electrical Engineering

Preliminary Report – Balancing Robot Design and Development CONTENTS

1

CONTENTS

CONTENTS ............................................................................................................................................ 1

1 INTRODUCTION .......................................................................................................................... 2

1.1 Statement of problem .............................................................................................................. 2

1.2 Objectives ............................................................................................................................... 3

1.2.1 Phase 1 - Research: ................................................................................................................ 3

1.2.2 Phase 2 – Analysis: ................................................................................................................. 3

1.2.3 Phase 3 – Modelling: .............................................................................................................. 4

1.2.4 Phase 4 – Implementation: .................................................................................................... 4

2 RESEARCH .................................................................................................................................... 5

2.1 Ballbot Literature Review........................................................................................................ 5

2.1.1 Drive ....................................................................................................................................... 6

2.1.2 Equations of motion and controllability ................................................................................ 7

2.1.3 Cost of components for a similar Ballbot model ................................................................... 9

2.2 Two-Wheeled Robot (TWR) Literature Review ..................................................................... 11

2.2.1 Drive ..................................................................................................................................... 12

2.2.2 Equations of motion and controllability .............................................................................. 13

2.2.3 Cost of components for a similar TWR model ..................................................................... 15

2.3 Research conclusions ............................................................................................................ 16

3 ELECTED DESIGN ANALAYSIS .............................................................................................. 16

3.1 Sensing Module ..................................................................................................................... 16

3.1.1 Introduction ......................................................................................................................... 16

3.1.2 Accelerometers and gyro analysis ....................................................................................... 18

3.1.3 Building and simulating the IMU.......................................................................................... 19

4 PROJECT BREAKDOWN ........................................................................................................... 21

4.1 Plan & Milestones ................................................................................................................. 21

5 CONCLUSION ............................................................................................................................. 22

6 REFERENCES ............................................................................................................................. 23

7 APPENDIX ................................................................................................................................... 24

7.1 Detailed Gantt chart ............................................................................................................. 24

7.2 Arduino code for the IMU ..................................................................................................... 32

Preliminary Report – Balancing Robot Design and Development INTRODUCTION

2

1 INTRODUCTION

Robots degree of freedom is one of the main constraints that restrict their application in

tight environments with objects constantly changing position. Conventional driven robots

lack the usability of a balancing robot, because they need the base to support the entire frame,

usually the taller and heavier the frame is, the wider the robot base will be to maintain

equilibrium. Because of these constraints on conventional models this project has the intent to

analyse existing pendulum based models and requirements as well as model a virtual robot

and build a prototype to demonstrate the benefits of such design.

1.1 Statement of problem

Throughout the course of the task at hand, several steps will have to be taken and analysed

to be able to feedback to a viable prototype. The main one will be the controllability feeding

to the drive of the robot. There are two out of three possible cases that will be analysed before

deciding on the final model to proceed.

The first one consists of a single spherical wheel; this will allow creating a holonomic

robot, where the available degrees of freedom are equal to the degrees of movement of the

robot. The second is a single wheeled robot, similar to a unicycle. However, due to the

inability to allow the robot to move sideways with the use of only the wheels drive this model

will be discarded. The last model is a two-wheeled robot similar to the Segway®, also a

similar model falling under the two wheeled would be a bicycle type robot. However, the

latter also requires additional drive to a sort of gyro to compensate lateral fall movement so it

will also be discarded for analysis. All models, because of their inability to stand upright if no

power is being driven to the motors are considered dynamic systems.

The robots design can be viewed as an inverted pendulum where control theory will need

to be applied to the dynamics of system. The applications of this type of robot are mainly in

human assistance and interaction where crowded and narrow environments will require an

agile reaction to the current scenario. Areas such as hospitality, by serving meals to

customers; care homes, assisting elderly people’s needs; mobility platforms, a replacement to

the current mobility chairs and even factories, assisting in manoeuvrability of heavy loads

would greatly benefit from their use.


3

The project will be basically a control theory application for the balancing robot stability

but because of its uniqueness and not very widespread information and resources regarding

the topic it will also cover the fields of mechanics, for the drive and frame; electronics, for

the sensing capability of the robot and computer modelling, for the testing, development and

simulation of the robot.

1.2 Objectives

The project is divided into phases and each phase has objectives as outcomes. Since the final

goal is to reach a balancing robot which can interact in a crowded dynamic environment, or

can be scaled to do so, by the completion of the project the following phases will be used to

guide me through the task.

The overall objective will be to be able to simulate and create a model which would balance,

and if time permits the creation of a remote control and further on an interface to be able to

detect/avoid/follow objects will be attempted.

1.2.1 Phase 1 - Research:

Research on available models of balancing robots and their viability, affordability (taking the

allocated budget) and benefits compared to other models.

Objectives:

• Research models;

• Study benefits/complexity and resources required for each model;

• Get components list price for each model;

• Decide on the model to create based on the findings above.

1.2.2 Phase 2 – Analysis:

With the model selected from “Phase 1” the development part of the project starts here.

Objectives:

• Breakdown model into modules for analysis;

o Frame module;

o Drive module;

o Sensing module;

o Control module;


4

o Ability to add extra modules:

� Remote control – wire/wireless and other custom modules.

1.2.3 Phase 3 – Modelling:

Subsequently the modules will try to be modelled/simulated either separately or together to

analyse and visualize the behaviour of the future prototype.

Objectives:

• Create simulation for modules where possible;

• Design frame/construction;

• Derive mathematical equations to model the system;

• Derive control equations for the balancing.

1.2.4 Phase 4 – Implementation:

This will be the final phase and some revisiting to previous phases might be done to

correct/expand prototype possibilities. Things like remote controlling and possibility for

modular expansion will be considered in this phase

Objectives:

• Coding:

o Drive;

o Control;

o Sensing;

o Remote controlling.

o Object avoidance

o Object tracking

• Assembly:

o Build frame;

o Assemble components.

• Simulation:

o Correct equations derived in previous phase if required.

Preliminary Report – Balancing Robot Design and Development RESEARCH

5

2 RESEARCH

2.1 Ballbot Literature Review

The Ballbot model is very similar to the robot named Serge which appears in sci-fi series

“Caprica”. Throughout the research of Ballbot models I discovered that there are mainly two

branches, depending on the type of drive they use. Thus, henceforth only those two will be

analysed as all others have been based on them.

The first robot was born in the labs of the Carnegie Mellon University (CMU) in 2006 by T.

B. Lauwers, G. A. Kantor, and R. L. Hollis. It weighted 43 kg and had the approximate size

of an average person, both in height and width (Watzman, 2006) and has a drive similar to an

inverse mouse-ball. The second robot was developed in 2008 at the Tohoku Gakuin

University (TGU) by Dr Masaaki Kumagai weighing 7.5 kg and with a height no bigger than

0.5 meters. The peculiar drive about the latter is that the wheels to drive the ball are placed

120 degrees apart making it harder to define the movement of the robot.

These types of robots are truly holonomic because of their ability to have the controllable

degrees of freedom equal to the total degrees of freedom the robot has. (The presented CMU

model does not have that capability. However, in the research undertaken an analysis was

being carried out to enable that feature to be available).

Figure 1 - Battlestar Galactica Comic Con Exclusives., 2009

Figure 2 - Ballbot balancing in the CMU motion capture lab, with Ralph Hollis looking on., 2006

Figure 3 - Masaaki Kumagai BallIP., 2008


6

2.1.1 Drive

The CMU ballbot depicted in Figure 4 consists of two orthogonal rollers in relation to the

sphere equator and perpendicular to each other. Both are linked to high torque DC

servomotors through timing belts. Opposite to each active roller there is an idle roller which

is spring loaded to add pressure to the ball insuring both drive rollers always have contact

with the sphere. Ball transfers are used to help alleviate weight of bogy and the feedback

control of the motors is provided by encoders.

The design method used in the TGU is based on three stepper motors forming 120 degrees

between each other connected to omni-wheels. This has several benefits compared to the

CMU model being the first the ability to yaw which is impossible in Lauwers et al model

without adding extra motors. Also the TGU model because it uses the motors directly

attached to omni-wheels it has the ability to support the robot weight without the ball transfer

which reduces the friction in the ball and allows a smother drive. The downside is that it

increases the computational requirements do calculate how to drive the ball.

Figure 5 – TGU Drive (Justin Fong, 2009)

Figure 4 – CMU Ballbot inverse mouse-ball drive mechanism (Lauwers, Kantor, & Hollis, 2006)


7

2.1.2 Equations of motion and controllability

Both models have similar equations of motions (only changing coefficient like mass, ball

radius, etc.). From a physics perspective they are considered as a wheel cart with two inverted

pendulums perpendicular/decoupled to each other. Also several assumptions, such as static

and non-linear friction, ball deformity and body flexibility, are made to simplify and allow a

more linear approach to the controllability of the model.

Also equations of motion are assumed equal in both planes allowing the design of a single

controller and the ability to apply it to the two planes. The dynamics of the system is thus

derived using Lagrange’s equation approach, where T is the sum of the kinetic energy of the

system and U the potential energy.

� = � − � (1)

In the CMU, they by defining the co-ordinates system as in Figure 5 and calculating the

kinetic energy of the ball,�� we end up with:

� =�� 22 +

�(�� )2 (2)

Where�, �� and ��being respectively the inertia, mass and radius of the ball. The ball

potential energy is and always will be equal to 0 as it is assumed that the ball will not bounce

or hop. The next step is to calculate the kinetic (Equation 3) and potential energy (Equation

4) of the Body.

�� =��2 ��2�� 2 + 2��(�� 2 + �� ) cos(� + �) + �2(�� + �� )2� + �

2 (�� + �� )2 (3)

�� = ��cos(� + �) (4)

Figure 5 – CMU Ballbot model for equations and controller (Lauwers, Kantor, & Hollis, 2006)


8

With, � distance from body centre of mass and ball, �� and � is the body mass and inertia

and � is the gravity acceleration. Ball and body angle are represented as � and � with their

angular velocity represented as the first derivative �� and�� , correspondingly. With the

summing of all kinetic and potential forces, Lauwers et al end up with the Euler-Lagrange

equation of the model expressed in the form and coordinates and velocity with controllable

variables ball and body angle and by re-arranging the outcome is Equation 5. Also in the

CMU a model of the viscous component based on the torque � is also added ending with

matrix of equations.

�( ) ! + "( , � ) + $( ) + %( � ) = &0�( (5)

This new re-arrangement organizes the problem into Mass matrix, Coriolis and centrifugal

matrix, Gravitational matrix and Damping matrix in respect to position and velocity � in

the two planar systems.

The controller used in the CMU model (figure 6) has the inner loop to provide the feedback

of the ball velocity to a Proportional Integrator controller and the outer loop for the linear

quadratic regulator for the full state feedback. The PI gains, )* and )+ are experimentally

chosen to make the real ball velocity track the desired ball velocity.

In the TGU model Dr Masaaki Kumagai opted for just a proportional derivative controller for

the balancing. Also the proportional and derivative gains were achieved through

experimentation. The desired output is after passed on to two virtual wheels which simulate

the drive of the ball allowing the simpler PI controller derivation. The model based, shown in

Figure 7 and 8, uses a similar derivation method but it relates to the wheel acceleration.

Figure 6 – CMU Ballbot model for equations and controller (T. B. Lauwers, 2006)


9

In the TGU, Masaaki et al, also calculate and simulate model under a load condition and

deduct that with a load on top of the ballbot the pendulum and inertia moment decrease which

raises the centre of mass. The conclusion was that the robot acceleration decreased nearly

inversely proportional to the inertia increase.

2.1.3 Cost of components for a similar Ballbot model

Merging the functionally of the two models and preventing the use of the complex drive from

the TGU, a ballbot with the design below was created. The benefits as shown in Figure 9, are

that it would be capable of yaw without the complexity of using the tri-omini-wheel design.

Thus, the positioning of the wheels would be 90° apart and use a set of four to support the

whole weight of the robot.

Figure 9 – Proposed drive model based on Wu and Hawg research 2008

Figure 7 – TGU Ballbot model for equations and controller (Kumagai & Ochiai, 2009)

Figure 8 – TGU Ballbot model for equations and controller (Kumagai & Ochiai, 2009)


10

Since the aim is to develop a robot which would be able to interact with a person, a scalable

model with the requirements presented below is based on created constraints from the

problem definition, thus this will reflect on the required components price and specifications

to acquire.

Motors:

• Enough torque to move the body and ball ( 3 – 10 kg );

• Power requirement must not exceed 12v because of price;

• Be scalable for future adaption to full scale model.

Omni-wheel:

• Radius size to be considered in regards to torque;

• Material of the wheel, from research plastic wears off to quickly;

Ball:

• Radius size to be considered in regards to torque as well;

• Physical properties are of high importance for controllability:

o As little as deformation as possible;

o High friction;

o Able to withstand frame mass.

Body:

• Frame dimensions and material (Frame cost will be disregarded and the Mechanics

Workshop provide a wide variety of components and until design is completed cost

cannot be factorized.)

Components List

Module Name Price Unit Quantity

Drive 2 x Pololu Universal Hub (6mm shaft) £6.60 2 Drive OmniWheel Black Small ** EUR ** £3.20 4 Drive Pololu 37D mm Metal Gearmotor Bracket Pair £6.36 2 Drive 50:1 Metal Gearmotor 37Dx52L mm with 64 CPR Encoder £31.68 4 Drive Bidirectional DC Motor Speed Controller (5-32V, 5A) £33.94 4 Drive Basketball £5.00 1 Microcontroller Arduino uno £20.03 1 Microcontroller Triple Axis Accelerometer Breakout - ADXL335 £15.53 1 Microcontroller Triple-Axis Digital-Output Gyro ITG-3200 Breakout £31.10 1 Power BT04065 - 4AA Extra-High Capacity Batteries £7.16 1 Power 12v Battery £16.00 1 Power 4 AA Battery case £0.70 1 Total: £396.72


11

2.2 Two-Wheeled Robot (TWR) Literature Review

Two-wheeled robots are more widely known and greater varieties of projects exist. The

research was inconclusive in relation to the first design origin and time but it is widely

accepted to consider these types of models to be a natural evolution of the inverted pendulum

control problem fixed on a moving cart.

The oldest found model was “Joel le pendule” in 1996 developed by LEI, Laboratoire

d'Électronique Industrielle at École Polytechnique Fédérale de Lausanne (EPFL) in

Switzerland (Figure 10). The project only had a successful balancing robot after four years of

the start of the project, on the 25th of January 2000. The aim of the project had no intended

specific application. However, what was interesting in the design for the authors was a

completely different structure and an unprecedented performance (EPFL, 2000).

Several other models followed, some built out of Lego® parts and others with solid and

robust frames such as the LegWay and nBot (Figure 11). The latter is very well documented

and due to its robustness it was aimed at rough terrain survey. The nBot created by David P.

Anderson has won NASA’s Cool Robot of the Week for 19th May 2003 and honoured the

NASA page as one of the top 10 engineering and technical web sites for 2003 (Anderson,

2002).

A commonly used application of the model is in the Segway Personal Transporter® (Figure

12). It was invented by Dean Kamen and the locomotion consists in combining the user plus

the frame to move the robot. When the user leans it destabilises the system dynamics forcing

the control algorithm to compensate with wheel rotation returning it to a stable position.

Figure 10 – Joe Pendulum (EPFL, 2000)

Figure 11 – nBot (Anderson, 2002) Figure 12 – Segway with rider


12

2.2.1 Drive

The drive component of the TWRs is nearly the same for all models, the use of a DC motor

with encoders either attached to the wheel, wheel shaft or the motor shaft depending on the

required resolution required, to feedback the wheel rotation. However, good wheel encoders

prove to be expensive and hard to find as it was recognized in the first component research

done for the Ballbot.

Further research provided an alternative to what will prove to be a less expensive option. The

use of servo motors set for continuous rotation or stepper motors provide a method of having

the feedback without actually having the feedback mechanism. Because these type of motors

work on degrees of rotation assuming an overcompensation on the motor torque

specifications it can be assumed that when the rotation movement is requested it will be

served, also the friction between the wheels are of contact with the floor is considered to be

very high. Other than having servos, steppers or dc motors controlling the drive of either one

or both wheels not much difference exists in the overall drive design of the TWR.

Figure 13 – Encoder patterns to be read by optical sensor providing different type of characteristics.


13

2.2.2 Equations of motion and controllability

The pseudo algorithm derived by Anderson (Figure 14) provides a very good idea of how the

system works and also how to derive the equations of motion. The differences compared to

the ballbot are nearly non-existent, the only difference being that this represents the whole

system as it will only need to balance in one axis because an assumption that the robot will

not topple on its sides.

To derive the equations of motion in the TWR model we divide the system into two parts for

analysis, the body and the wheels (Figure 15).

This ends up giving the following equations:

� ∗ -.�! = �

� ∗ /.�! = 0 −� ∗ �

1 ∗ �! = � ∗ (� ∗ cos(�) + 0 ∗ sin(�) + "

(6)

Figure 15 – TWR pendulum body and wheel geometry and coordinates (Vamfun, 2007)

Motor Shaft Encoder

Angle sensor

Motor PWM

Derivation

Derivation

K1

K2

K3

K4

SUM

Angle

Velocity

Angle

Position

Wheel

Position

Angle

Velocity

Figure 14 – nBot balancing pseudo algorithm (Anderson, 2002)


14

�4 ∗ -4! = 5-� − �

�4 ∗ /4! = 5/� − 0 −�4 ∗ �

14 ∗ �4! = � ∗ 5-� − "

(7)

Where set of equations 6 represent the body equations applying Newton’s Second law with x

axis being parallel to Fxg, y axis parallel to Fyg and z axis perpendicular to both x and y axis.

And equations set 7 are the wheel equations. When combined with the assumptions that the

wheels will always stay in contact with the floor and no slippage will occur between the

wheels and the floor Vamfum is able to achieve the following state equations.

��! = 6(−721 − 722) ∗ 91 + (711 + 712) ∗ 92):

79;

�! = 6−721 ∗ 91 + 711 ∗ 92):79;

(8)

With:

711 = 14 + (�4 +�) ∗ �<

712 = � ∗ � ∗ � ∗ .=>�

721 = � ∗ � ∗ � ∗ .=>�

721 = � ∗ � ∗ � ∗ .=>�

722 = 1 + � ∗ �<

79; = 711 ∗ 722 − 712 ∗ 721

91 = � ∗ � ∗ � ∗ >?@� ∗ ��< − "

92 = � ∗ � ∗ � ∗ >?@� ∗ +"

(9)

The controllability options for the two wheeled balancing robot are immense, they vary from

LQR to simple matching the position of the wheel with the position of the centre of the body

by the use of nothing more than the difference operation. Since the controllability of this

model is easier to achieve, similar to the ballbot equations but with less complexity and

various methods exist a more in-depth analysis will be undertaken if the path chosen is based

on the TWR.


15

2.2.3 Cost of components for a similar TWR model

The two wheeled inverted pendulum robot appears to have a very consistent approach in

design and drive throughout all the research done. The model proposed consists of creating a

very basic yet durable frame of a material still to be confirmed, can be wood like MBF or

acrylic sheets. And will consist of a tall parallelepipeds shaped body with the

microcontrollers inside and the wheels on the side. This way in a later date a modular

approach can be taken if extra functions are required to be added to the robot. The proposed

model will be similar to the one with Figure 16 and the location of the components has been

placed in the rear view.

Components

Module Name Price

Unit

Quantity

Drive Servo - Medium Full Rotation £9.06 2 Drive Tamiya 70193 Slim Tire Set (4 tires) £6.80 1 Microcontroller Arduino uno £19.98 1 Microcontroller Xbee Wireless Bluetooth Transceiver Module RS232 / TTL £9.39 0 Microcontroller Triple Axis Accelerometer Breakout - ADXL335 £15.53 1 Microcontroller Triple-Axis Digital-Output Gyro ITG-3200 Breakout £31.10 1 Power BT04065 - 4AA Extra-High Capacity Batteries £7.16 1 Power 4 AA Battery case £0.00 1 Total: £98.69

Figure 16 – Proposed TWR

Preliminary Report – Balancing Robot Design and Development ELECTED DESIGN ANALAYSIS

16

2.3 Research conclusions

Being the ballbot an evolution from the two wheeled robot and due to the lack of knowledge

in inverted pendulum mechanics and although the ballbot presents a more challengeable and

exciting project due to the budget constraints the decision of which project to follow is clear.

Also both ballbot models were built by a team of electronic and mechanical engineers which

allowed them to create a better prototype using each members field of expertise.

The decision to build a two wheeled inverted pendulum robot is not the preferred but it is

however the better option to provide knowledge and understanding of the inverted pendulum

control problem. In the future the author would like to proceed with the creation of a

prototype with dimensions similar to a person because the benefits presented are not only

crucial to a robot that can easily interact in human environments but also presents a very

economically profitable business aimed at several industries.

3 ELECTED DESIGN ANALAYSIS

This topic will try to divide the project into smaller blocks allowing better time management

and easier overall design. Since the robot proposed for simulation and building is the two

wheeled inverted pendulum robot the initial division into modules will be the following.

The Drive, this will include motors (and motor drivers if required) as well as the required

analysis and measuring of the components properties. Frame, which will consist in design

and material analysis for the robot, also, the equations of motion and control will fall under

this category. Microcontroller, being the brain of the robot this module will possibly overlap

with other modules but will be considered individual because a final composition of all the

sketched codes for each module will be required. Finally, the sensing module, which will

consist in creating an accurate measuring unit to be easily interfaced with the microcontroller.

3.1 Sensing Module

3.1.1 Introduction

Most systems which are dynamically unstable require a method to determine their orientation

before they are able to be controlled. A good example is UAVs (Unmanned Air Vehicles) due

to the fact that they do not have a pilot who would be able to percept/acquire data, say from

looking out of the cockpit window to be able to then take the required action to compensate


17

the direction or altitude to bring the aeroplane to the required position they will require a set

of sensors to be able to do that inferring automatically in a lack of a person.

Applied to the project the required measurements will be the ability to detect the direction of

the movement, the speed of the vehicle and how fast it is rotating or falling, depending on the

plane. With this in mind a set of basic movements will be analysed in order to determine the

problem and required sensing module. Based on the proposed model at the end of the

research the demonstration and analysis of three conceivable situations the robot will

encounter will be set forth to better understand the sensing requirements.

In scenario 1 the robot is still. However, due to the fact that it is on top of two wheels it will

be impossible to keep upright position. Thus, it will be required to detect how many degrees

per time frame it is falling to be able to feed that value to the control algorithm. Because, of

the two wheels we can assume the robot will always fall in the same plane. The direction of

the fall will need to be identified to compensate the motors in the right direction.

For the second scenario the robot will require to turn on its own z axis. However, if we can

always maintain the position in scenario 1 we can neglect having to detect motion in another

plane saving the requirements of having to measure an extra acceleration.

Centre

of mass

Centre

of mass

Centre

of mass

Figure 17 - Possible scenarios the robot will face

Scenario 1 - balancing position Scenario 2 - rotate on z axis Scenario 3 – move


18

In the last scenario, when the robot moves we will need to detect the fall while preventing it

from going to the upright position, so that is always in a permanent fall state allowing for the

movement to occur. For this we will need to detect the displacement of the wheel, thus an

accelerometer that detects movement in a plane perpendicular to plane z and the wheels will

be required. Henceforth, that plane will be regarded as x plane and we can consider it as

parallel to the surface the robot will be on. All scenarios assume that the wheels will never

lose contact with the floor.

3.1.2 Accelerometers and gyro analysis

To be able to have the required measurements an accelerometer would suffice. However,

research in building robots that need to know their position in space indicates that it alone

does not provide accurate readings; this is due to motor oscillation that introduces noise into

the readings.

An Inertial Motion Unit (IMU) compensates those inaccuracies introduced by the false

readings. It consists in combining a gyroscope with and accelerometer (and sometimes a

magnetometer to detect magnetic orientation) to provide a reliable reading. In addition the

values read are passed through a Kalman filter, it basically consists of inferring present

values based on previous readings and estimations of future values, this allows us to have a

smoother output of values with less discrepancies.

The accelerometer for the IMU (Figure 18) will read the inertial and gravitational force, so if

we have a three axis accelerometer like the one chosen in the components and it is still, we

will measure one g-force in the z axis according to the datasheet, as this will be the earth

gravitational pull. The output of data is analogue and the resolution will value depending on

the reference voltage which is equal to the supplied voltage and can swing from 1.8 to 3.6

volts. The sensing capability is from +3g to -3g.

Figure 18 - Accelerometer


19

The gyro (Figure 19) will measure the disturbances in the current axis, measuring the rotation

in that axis. For the selected component the interface uses the I2C protocol which simplifies

communication. For example, to read a certain rotation axis value, we only need to specify

the address of the register we would like to get (it needs to be read twice because the values

are 16bit 2s complement). The sensing capability goes from -2000°/s to +2000°/s and it has

separate input voltage and reference voltage, able to go from 2.1 to 3.6v.

3.1.3 Building and simulating the IMU

The IMU will be the gyroscope and the accelerometer attached to the microcontroller,

Arduino board. Following the datasheet the diagram in Figure 20 shows how they have been

connected to the microcontroller.

Figure 19 - Gyro

Figure 20- Sensor Diagram


20

A small sample code was also created to test interfacing with the sensors (see Appendix 7.2),

following this a Matlab® model was designed to be able to analyse the readings from the

sensors and help towards creating a model for developing the control algorithm.

The Simulink® model in Figure 21 connects to the serial port of the connected Arduino

board with the attached sensors, which transmits a vector of the three rotations, as in Figure

20 and displays the values in the three boxes, one for each of the axis. It is also being

attempted to get a visualisation of the actual rotation in the 3D model feeding of the parsed

vector read from the serial link (Figure 22).

Figure 21- Matlab® Simulink® designed model

Figure 21- Matlab® Simulink® designed model

Preliminary Report – Balancing Robot Design and Development PROJECT BREAKDOWN

21

4 PROJECT BREAKDOWN

4.1 Plan & Milestones

The project will span over two semesters with the final goal of achieving a balanced and

controlled two wheeled robot. A Gantt was created to depict in detail the tasks taken and yet

to be done as well as the project milestones assigned by the lecturers and self-assigned

milestones such as decisions and estimated prototype readiness (See Appendix 7.1 for more

detail).

Preliminary Report – Balancing Robot Design and Development CONCLUSION

22

5 CONCLUSION

At this stage with the research done the selected type of design to follow is the two wheeled

inverted pendulum. Some initial design analysis and the assembly of the sensing unit is

complete. For the next step I will work on perfecting the sensing to give accurate readings by

simulating real value readings and displaying them on the modelled 3D Matlab® Simulink

model.

After, the frame design with the drive module will be assembled so the equations of motions

and afterwards the control can be designed, as they mass of body and some other values of

the final prototype.

Preliminary Report – Balancing Robot Design and Development REFERENCES

23

6 REFERENCES

Ballbot balancing in the CMU motion capture lab, with Ralph Hollis looking on. (2006). Retrieved November 7, 2011, from http://www.msl.ri.cmu.edu/projects/ballbot/images/Ballbot_Goldfein_small.jpg

Masaaki Kumagai BallIP. (2008). Retrieved November 7, 2011, from http://a1.twimg.com/profile_images/688323178/ballip_rev20.jpg

Battlestar Galactica Comic Con Exclusives. (2009). Retrieved November 7, 2011, from http://everyjoe.com/files/2009/07/serge-usb-keychain.jpg

Anderson, D. P. (2002, December 12). nBot Balancing Robot. Retrieved November 6, 2011, from Geology SMU: http://www.geology.smu.edu/~dpa-www/robo/nbot/

EPFL. (2000, January 25). EPFL - Joe the pendulum. Retrieved November 3, 2011, from EPFL: http://lei.epfl.ch/page-36905-fr.html

Hollis, R. (2011, January 4). Microdynamic Systems Laboratory. Retrieved October 11, 2011, from Dynamically-Stable Mobile Robots in Human Environments: http://www.msl.ri.cmu.edu/projects/ballbot/

Justin Fong, S. U. (2009, May 22). TGU Drive. Adelaide.

Kumagai, M., & Ochiai, T. (2009, September 29). Development of a Robot Balanced on a Ball. Tohoku, Japan.

Lauwers, T. B., Kantor, G. A., & Hollis, R. L. (2006). A Dynamically Stable Single-Wheeled. Proc. IEEE Int’l. Conf. on Robotics and Automation,, 3.

Steve. (2004, April 6). Steve's LegWay. Retrieved November 6, 2011, from Team Hassen Plug: http://www.teamhassenplug.org/robots/legway/

Vamfun. (2007, August 20). Modeling a Two Wheeled Inverted Pendulum Robot.

Watzman, A. (2006, August 9). Carnegie Mellon Researchers Develop New Type of Mobile

Robot That Balances and Moves on a Ball Instead of Legs or Wheels. Retrieved October 15, 2011, from http://www.msl.ri.cmu.edu/projects/ballbot/text/BallbotAugustFinal.pdf

Preliminary Report – Balancing Robot Design and Development APPENDIX

24

7 APPENDIX

7.1 Detailed Gantt chart


25


26


27


28


29


30


31


32

7.2 Arduino code for the IMU

8 //The Wire library is used for I2C communication

9 #include <Wire.h>

10 //ITG3200 sensitivity is 14.375 LSB/(degrees/sec) 11 #define GYROSCOPE_SENSITIVITY (1 / 14.375) 12 //Voltage reference for the ADC 13 #define V_REF 3.3 14 //Number of calibration samples 15 #define CALIBRATION_SAMPLES 128 16 //Number of samples per value returned 17 #define SAMPLES 4 18 //16bit 2s complement range 19 #define G_RESOLUTION 32767 20 //Accelerometer pins 21 #define PIN_X 0 22 #define PIN_Y 1 23 #define PIN_Z 2 24 25 //This is a list of registers in the ITG-3200 26 char WHO_AM_I = 0x00; 27 char SMPLRT_DIV= 0x15; 28 char DLPF_FS = 0x16; 29 char TEMP_OUT_H = 0x1B; 30 char TEMP_OUT_L = 0x1C; 31 char GYRO_XOUT_H = 0x1D; 32 char GYRO_XOUT_L = 0x1E; 33 char GYRO_YOUT_H = 0x1F; 34 char GYRO_YOUT_L = 0x20; 35 char GYRO_ZOUT_H = 0x21; 36 char GYRO_ZOUT_L = 0x22; 37 38 //Calibration variables for g_ == gyro and a_ == accelerometer 39 long g_xBias = 0, g_yBias = 0 , g_zBias = 0; 40 long a_xBias = 0, a_yBias = 0, a_zBias = 0; 41 float a_sensitivity=0; 42 int a_0g=0; 43 44 45 //This is a list of settings that can be loaded into the registers. 46 //DLPF, Full Scale Register Bits 47 //FS_SEL must be set to 3 for proper operation 48 //Set DLPF_CFG to 3 for 1kHz Fint and 42 Hz Low Pass Filter 49 char DLPF_CFG_0 = (1<<0); 50 char DLPF_CFG_1 = (1<<1); 51 char DLPF_CFG_2 = (1<<2); 52 char DLPF_FS_SEL_0 = (1<<3); 53 char DLPF_FS_SEL_1 = (1<<4); 54 55 //I2C devices each have an address. The address is defined in the datash

eet for the device. The ITG-

3200 breakout board can have different address depending on how

56 //the jumper on top of the board is configured. By default, the jumper is connected to the VDD pin. When the jumper is connected to the VDD pin

the I2C address

57 //is 0x69. 58 char itgAddress = 0x69; 59


33

60 //In the setup section of the sketch the serial port will be configured, the i2c communication will be initialized, and the itg-

3200 will be configured.

61 //Calibration for the itg3200 and adxl335 62 void setup() 63 { 64 //Create a serial connection using a 9600bps baud rate. 65 Serial.begin(9600); 66 67 //Initialize the I2C communication. This will set the Arduino up as

the 'Master' device.

68 Wire.begin(); 69 70 //Read the WHO_AM_I register and print the result 71 char id=0; 72 id = itgRead(itgAddress, 0x00); 73 Serial.print("ID: "); 74 Serial.println(id, HEX); 75 76 //Configure the gyroscope 77 //Set the gyroscope scale for the outputs to +/-2000 degrees per

second

78 itgWrite(itgAddress, DLPF_FS, (DLPF_FS_SEL_0|DLPF_FS_SEL_1|DLPF_CFG_0));

79 //Set the sample rate to 100 hz 80 itgWrite(itgAddress, SMPLRT_DIV, 9); 81 82 //calibrate gyro and calibrate accelerometer 83 for(int sample = 0; sample < CALIBRATION_SAMPLES; sample++) 84 { 85 g_zBias += (itgRead(itgAddress, GYRO_ZOUT_H)<<8) | (itgRead(itgAddre

ss, GYRO_ZOUT_L));

86 g_xBias += (itgRead(itgAddress, GYRO_XOUT_H)<<8) | (itgRead(itgAddress, GYRO_XOUT_L));

87 g_yBias += (itgRead(itgAddress, GYRO_YOUT_H)<<8) | (itgRead(itgAddress, GYRO_YOUT_L));

88 a_xBias += analogRead(PIN_X); 89 a_yBias += analogRead(PIN_Y); 90 a_zBias += analogRead(PIN_Z); 91 delay(10); 92 } 93 g_xBias = g_xBias / CALIBRATION_SAMPLES; 94 g_yBias = g_yBias / CALIBRATION_SAMPLES; 95 g_zBias = g_zBias / CALIBRATION_SAMPLES; 96 97 a_xBias = a_xBias / CALIBRATION_SAMPLES; 98 a_yBias = a_yBias / CALIBRATION_SAMPLES; 99 a_zBias = a_zBias / CALIBRATION_SAMPLES; 100 a_0g = (a_xBias + a_yBias)/2;

101 a_sensitivity = 1.000/( a_zBias - a_0g);

102 Serial.println(a_sensitivity);

103 Serial.println(a_0g);

104 Serial.println(a_sensitivity*(a_zBias - a_0g));

105 Serial.println(a_xBias);

106 Serial.println(a_yBias);

107 Serial.println(a_zBias);

108 }

109

110 //The loop section of the sketch will read the X,Y and Z output rat

es from the gyroscope and output them in the Serial Terminal

111 void loop()


34

112 {

113 //Create variables to hold the output rates.

114 double g_xRate, g_yRate, g_zRate, g_tSensor; //Gyro ITG-3200

Values

115 double r_vector[2];

116

117 //Read the x,y and z output rates from the gyroscope.

118 g_xRate = readX();

119 g_yRate = readY();

120 g_zRate = readZ();

121 g_tSensor= readT();

122 readAccel(&r_vector[0]);

123

124 //Print the output rates to the terminal, seperated by a TAB

character.

125 Serial.println("XXX,YYY,ZZZ");

126 Serial.print(g_xRate);

127 Serial.print(',');

128 Serial.print(g_yRate);

129 Serial.print(',');

130 Serial.println(g_zRate);

131 //printDouble(r_vector[PIN_X],10);

132 Serial.print(analogRead(PIN_X));

133 Serial.print(",");

134 // printDouble(r_vector[PIN_Y],10);

135 Serial.print(analogRead(PIN_Y));

136 Serial.print(",");

137 // printDouble(r_vector[PIN_Z],10);

138 Serial.print(analogRead(PIN_Z));

139 Serial.println();

140 //Wait 10ms before reading the values again. (Remember, the

output rate was set to 100hz and 1reading per 10ms = 100hz.)

141 delay(1000);

142 }

143

144 void readAccel(double *a_xyz)

145 {

146 for(int sample=0 ; sample < SAMPLES; sample++){

147 a_xyz[0] +=analogRead(PIN_X);

148 a_xyz[1] +=analogRead(PIN_Y);

149 a_xyz[2] +=analogRead(PIN_Z);

150 }

151 a_xyz[0] = ((a_xyz[0] / SAMPLES) - a_0g) * a_sensitivity;



154 }

155 //This function will write a value to a register on the itg-3200.

156 //Parameters:

157 // char address: The I2C address of the sensor. For the ITG-

3200 breakout the address is 0x69.

158 // char registerAddress: The address of the register on the sensor

that should be written to.

159 // char data: The value to be written to the specified register.

160 void itgWrite(char address, char registerAddress, char data)

161 {

162 //Initiate a communication sequence with the desired i2c device

163 Wire.beginTransmission(address);

164 //Tell the I2C address which register we are writing to

165 Wire.send(registerAddress);

166 //Send the value to write to the specified register

167 Wire.send(data);


35

168 //End the communication sequence

169 Wire.endTransmission();

170 }

171

172 //This function will read the data from a specified register on the

ITG-3200 and return the value.

173 //Parameters:

174 // char address: The I2C address of the sensor. For the ITG-

3200 breakout the address is 0x69.

175 // char registerAddress: The address of the register on the sensor

that should be read

176 //Return:

177 // unsigned char: The value currently residing in the specified re

gister

178 unsigned char itgRead(char address, char registerAddress)

179 {

180 //This variable will hold the contents read from the i2c device.

181 unsigned char data=0;

182

183 //Send the register address to be read.


185 //Send the Register Address

186 Wire.send(registerAddress);

187 //End the communication sequence.


189

190 //Ask the I2C device for data


192 Wire.requestFrom(address, 1);

193

194 //Wait for a response from the I2C device

195 if(Wire.available()){

196 //Save the data sent from the I2C device

197 data = Wire.receive();

198 }

199

200 //End the communication sequence.


202

203 //Return the data read during the operation

204 return data;

205 }

206

207 //This function is used to read the X-Axis rate of the gyroscope.

208 //Usage: long g_xRate = readX();

209 double readX(void)

210 {

211 double data=0;

212 for (int sample = 0; sample < SAMPLES; sample++)

213 {

214 data += (itgRead(itgAddress, GYRO_XOUT_H)<<8) | (itgRead(itgAdd

ress, GYRO_XOUT_L));

215 }

216 data = data / SAMPLES;

217 data = (data - g_xBias) * GYROSCOPE_SENSITIVITY;

218 return data;

219 }

220

221 //This function is used to read the Y-Axis rate of the gyroscope.

222 //Usage: long g_yRate = readY();

223 double readY(void)


36

224 {

225 double data=0;


227 {

228 data += (itgRead(itgAddress, GYRO_YOUT_H)<<8) | (itgRead(itgAdd

ress, GYRO_YOUT_L));

229 }


231 data = (data - g_yBias) * GYROSCOPE_SENSITIVITY;

232 return data;

233 }

234

235 //This function is used to read the Z-Axis rate of the gyroscope.

236 //Usage: long g_zRate = readZ();

237 double readZ(void)

238 {

239 double data=0;


241 {

242 data += (itgRead(itgAddress, GYRO_ZOUT_H)<<8) | (itgRead(itgAdd

ress, GYRO_ZOUT_L));

243 }


245 data = (data - g_zBias) * GYROSCOPE_SENSITIVITY;

246

247 return data;

248 }

249 //This function is used to read the Temperature sensor.

250 //Usage: long g_zRate = readZ();

251 double readT(void)

252 {

253 double data=0;

254 data = (itgRead(itgAddress, TEMP_OUT_H)<<8) | (itgRead(itgAddress

, TEMP_OUT_L));

255 data = 35 + ((data + 13200)/280);

256 return data;

257 }

258

259 void printDouble( double val, unsigned int precision){

260 // prints val with number of decimal places determine by precision

261 // NOTE: precision is 1 followed by the number of zeros for the des

ired number of decimial places

262 // example: printDouble( 3.1415, 100); // prints 3.14 (two decimal

places)

263

264 Serial.print (int(val)); //prints the int part

265 Serial.print("."); // print the decimal point

266 unsigned int frac;

267 if(val >= 0)

268 frac = (val - int(val)) * precision;

269 else

270 frac = (int(val)- val ) * precision;

271 int frac1 = frac;

272 while( frac1 /= 10 )

273 precision /= 10;

274 precision /= 10;

275 while( precision /= 10)

276 Serial.print("0");

277

278 Serial.print(frac,DEC) ;

279 }

Documents

Preliminary Report