Vous êtes sur la page 1sur 76

SELF BALANCING ROBOT

A Project Report
Submitted by

RAJAN GUPTA

In partial fulfillment of the requirements
for the award of the degree of

MASTER OF TECHNOLOGY
in Communication Systems &
BACHELOR OF TECHNOLOGY
in Electrical Engineering


DEPARTMENT OF ELECTRICAL ENGINEERING
INDIAN INSTITUTE OF TECHNOLOGY MADRAS
MAY 2012


THESIS CERTIFICATE


This is to certify that the thesis titled SELF BALANCING ROBOT, submitted by
Rajan Gupta, to the Indian Institute of Technology Madras, Chennai for the award of the
degree of Bachelor of Technology in Electrical Engineering and Master of
Technology in Communication Systems, is a bonafide record of the research work done
by him under our supervision. The contents of this thesis, in full or in parts, have not been
submitted to any other Institute or University for the award of any degree or diploma.






Dr. Nitin Chandrachoodan
-------------------------------------
Research Guide
Assistant Professor
Dept. of Electrical Engineering Place: Chennai
IIT-Madras, 600 036


Date: 10
th
May 2012


!
ACKNOWLEDGEMENTS


Foremost, I would like to express my deep and sincere gratitude to my advisor,
supervisor and guide Dr. Nitin Chandrachoodan, Department of Electrical Engineering,
for the continuous support during research. His guidance helped me in all the time of
research. I am greatly indebted to him for providing me definite direction, professional
and personal guidance, constant encouragement and moral support in many ways during
the study period.
I would use this opportunity to thank all my professors, especially Dr. Devendra
Jalihal (faculty advisor), Dr. Arun D. Mahindrakar, Dr. Bharath Bhikkaji and Mr.
Prabhakar Rao for taking their time out of the busy schedule and providing support
during the course of this project.
I am grateful to the organization, Centre For Innovation (CFI), a student-run
laboratory, which has been of immense help and provided with all the facilities required
for implementation of this project. It has, since my stay at IIT Madras, also provided me a
platform to enhance my skills and bring out an overall personality development.
My friends, to say the least, have provided with moral support and stood by me
during all walks of my stay in this institute. I would like to thank my hostel wingmates
Harshad, Gaurav, Sagar, Vaibhav, Dipanjan, Joseph, Abhiram, Abhishek, Adhokshaj,
Arjun, Iqbal, Bhanu and Nikhil. Of all friends, I would also particularly like to thank
Sandeep, Prateek, Abhishek, Srishti, Ashwin R., Ashwin S., Santosh, Saubhagya,
Srujana, Subhashree, Shweta, Koustuv, Swostik, Sohan and Tanuj who have contributed
considerably in shaping my life.
I owe my most sincere gratitude to my grandparents who were the true source of
inspiration and constantly directed me towards honesty, dignity and integrity. I would
like to thank my parents who stood by me all the time, kept me motivated, taught me to
dream and realize it. I owe my loving thanks to my sisters, Neena and Suchita, with
whom I could share anything freely.

!!
ABSTRACT


KEYWORDS: Inverted Pendulum, Balance, Mobile, Tilt, Control System, PID, Vehicle,
Controller

The transportation industry has been progressing at a very fast pace and is striving
towards providing an easy and comfortable ride at an affordable price. Moreover, there is
a demand for innovative solutions for physically challenged and enable them to travel
independently. The aim of this project is to build a mobile platform primarily for physical
disabled person, keeping in mind their constraints. It is being achieved by building a two-
wheeled balancing vehicle, which can intuitively be driven by tilting the body in the
desired directions of travel.
There are similar commercial products existing but they have not been able to
penetrate Indian market due to various reasons. One such example, Segway, the two-
wheeled personal mobile vehicle, was not successful in India due to its high cost.
The concept of balancing platforms has been studied thoroughly in the past and is
commonly known as Inverted Pendulum. During the course of this project, we are
going to implement one such design of balancing platform, analyze with above stated
focus and bring out some conclusions through various experiments.

!!!
TABLE OF CONTENTS


ACKNOWLEDGEMENTS
ABSTRACT
LIST OF TABLES
LIST OF FIGURES
ABBREVIATIONS
NOTATIONS

1. INTRODUCTION.
1.1. Motivation
1.2. Scope
1.3. Objective
1.4. Limitation

2. LITERATURE REVIEW
2.1. Segway
2.2. Honda U3-X
2.3. Toyota Winglet
2.4. NXT Segway with Rider
2.5. JOE A Mobile Inverted Pendulum


!#
3. MATERIALS AND METHODOLOGY
3.1. Study Area
3.2. Equilibrium
3.3. Assumptions
3.4. Experimental Model - Uncompensated
3.5. Experimental Model - Compensated
3.6. Determination of Tilt Angle

4. EXPERIMENTS
4.1. Inertial Measurement Unit
4.2. Android Orientation Sensor
4.3. Analog Signal Filter
4.4. Motor Driver
4.5. Matlab Data Acquisition
4.6. Maximum Angle of Tilt
4.7. Position Drift
4.8. Payload

5. FINAL IMPLEMENTATION
5.1. Materials Used
5.2. Hardware Design
5.3. Schematic and PCB Design
5.4. 5V Switching Regulator
5.5. PID Controller Tuning
5.6. Translational Motion Control

6. CONCLUSION

A. REFERENCES
B. APPENDIX

#
LIST OF TABLES


Table 1 IMU-Arduino connections
Table 2 Maximum angle of tilt measured in various experiments
Table 3 Position drift measured in various experiments
Table 4 Range of payload measured in various experiments
Table 5 Effects of increasing each of the controller parameters k
p
, k
i
and k
d


#!
LIST OF FIGURES


Figure 1 NXT Segway with Rider
Figure 2 Stable and Unstable Equilibrium of the free pendulum pivot about
a frictionless point
Figure 3 A Cart and A Pendulum
Figure 4 Free Body Diagram of A Cart and A Pendulum
Figure 5 Control System diagram
Figure 6 Side View of the experimental setup showing lengths and angles
Figure 7 Analog output voltage (V) v/s Distance to reflective object (cm)
Figure 8 9 Degrees of Freedom Razor IMU
Figure 9 Android Application for the purpose of this experiment
Figure 10 Sharp Sensor
Figure 11 Sensor Noisy Output
Figure 12 10 Sample Average Filter
Figure 13 20 Sample Average Filter
Figure 14 10 Sample Median Filter
Figure 15 20 Sample Median Filter
Figure 16 Smooth Filter with smoothness factor of 0.9
Figure 17 Smooth Filter with smoothness factor of 0.7
Figure 18 Variation in tilt angle while balancing with
k
p
= 0.85, k
i
= 3.2, k
d
= 0.1
Figure 19 Variation in tilt angle while balancing with
k
p
= 0.85, k
i
= 3.2, k
d
= 0.1 as measured by IMU
Figure 20 Maximum angle of tilt beyond which the system will not be able to
come back to stable position
Figure 21 RPM output from PID controller while balancing


#!!
Figure 22 Position drift (in cm) as in one of the experiments
Figure 23 Infrared Proximity Sensor Short Range Sharp GP2D120XJ00F
Figure 24 Arduino Mega2560
Figure 25 Experimental setup AutoCAD diagram
Figure 26 2mm Aluminum bracket sheet
Figure 27 Wheel AutoCAD Diagram
Figure 28 PCB Schematic
Figure 29 PCB Board Design
Figure 30 Circuit - 5V Switching Regulator



#!!!
ABBREVIATIONS


IITM Indian Institute of Technology Madras
IP Inverted Pendulum
PID Proportional Integral Differential
HOT Honda Omni Traction
IMU Inertial Measurement Unit
UART Universal Asynchronous Receiver Transmitter
IR Infrared
EAGLE Easily Applicable Graphical Layout Editor
COM Centre Of Mass
RPM Rotations Per Minute
PWM Pulse Width Modulation
MCU Micro-controller Unit
FBD Free Body Diagram
I/O Input Output







!$
NOTATIONS


! Angle from vertical in degree ( %
" Small angle from vertical after linearization in degree ( %
M Mass of the cart in kg
m Mass of the pendulum in kg
b Friction coefficient
l Length of the pendulum center of mass in m
I Inertia of the pendulum in kgm
2

u Force applied to the cart in N
x Position of the cart in x-direction in m
k
p
Proportional constant
k
i
Integral constant
k
d
Differential constant
d Distance of the sensor from the obstacle in cm
v Analog voltage in v
r Radius of the wheel in cm
t Time
1. CHAPTER

INTRODUCTION

We, since childhood, have inherently and unknowingly been practicing to balance
various objects. It may be balancing stick on palm, moving with a glass of water filled up
to the brim, walking on a narrow wall, cycling, etc. All of it requires a balancing
algorithm for which we have trained our brain to do so. Similar examples can be quoted
from industrial applications like Segway, loading machines at shipyard, robotic
applications, etc.
We, in this project, were working on a similar concept with a focus on
transportation industry and affordability. Over the years, this industry has been evolving,
rolling out various innovative products in the market. There has also been a constant
focus on customers needs and demands.
This thesis of ours will focus on small spectrum of personalized mobile platform,
primarily for physically challenged people for the Indian market. During the course of
this project, we will be making a scaled down version of the same to prove the concept,
incurring minimum cost. To be more precise, it is a two-wheeled platform with a dummy
weight at the top symbolizing a person, required to balance vertically and be able to move
in desired direction.
A similar concept being studied since long is an experimental setup known as
Inverted Pendulum. It is a common control system implementation. It is a system with
mass above its pivot point. While a normal pendulum is stable hanging downwards, an
inverted pendulum is inherently unstable. For an inverted pendulum to balance, it is
required to continuously take the feedback of its tilt from its unstable equilibrium
position and correct it by applying external force, which, in our case, is done by actuating
a motor.
In our case, we need to balance the pendulum about its unstable equilibrium.
Hence, any disturbance needs to be quantifiably detected and instantly corrected by an

&
external force. There is a limited disturbance angle beyond which it may be
mathematically impossible to get it back to its equilibrium position with any amount of
external force.
Its quite difficult to hold a pen in your hand and balance it. But to do the same thing
with a broom in your hand, its relatively simple. The reason is that there is more time to
compensate. For that reason its actually easier the higher we are off the ground. There
are various control algorithms widely used for such applications. We have used a PID
controller in our case.

1.1. Motivation
Over past few years, we have seen the transportation industry grow and providing its
customers with innovative solutions in personalized mobile platforms. But, less was
focus on physically challenged people. Our focus in this thesis will be towards trying to
engineer a personalized mobile vehicle for physically challenged people and design it in a
way keeping in mind their inherent constraints. At the same time, the vehicle will be
designed with affordability as one of the deciding factors in coming up with the design
and manufacturing process.

1.2. Scope
As it is not possible for us to come up with a full scale, robust and aesthetic product in the
given time frame, we will be concentrating on making a scaled down version of the
experimental setup to prove the concept and affordability.
During the process, we will be taking a standard literature of inverted pendulum on
an experimental basis and make a two-wheeled personalized mobile platform, which
could travel in the desired direction by sensing either the external control signals or the
tilt of the rider, which will be a dummy weight in our experiment. This inverted
pendulum, being free to move in any translational direction and rotate about its own
vertical axis, has 7 state spaces that determine it completely. For the theoretical analysis,

'
we will consider cart and a pendulum problem and try to simulate our problem with
stated assumptions. For balancing this system, there are various controllers that can be
used. We, in our case, will be using PID controllers, which is a common and basic of all.
We will be stating a standard protocol to manually tune the PID controller as per our
needs with varying physical parameters. Because of limited resources available, the setup
will be limited to balance and traverse only on flat surfaces, not even on inclined planes.
Scaling it up to commercially launch it in the market will require scaling up of
hardware as well as electronics. Power requirements for the battery and current ratings of
the motor driver will go up proportionally. Motors will require to have higher torque and
speed. Sensor should be able to detect tilt independent of the ground in order for the setup
to work in all-terrain. Hardware will need to be stronger for it to be able to support an
average human beings weight. Aesthetics and ergonomics will play an important role
when placing the same in the consumer market.

1.3. Objective
Objective of this project to demonstrate a working prototype (scaled down version) of a
personalized mobile platform which can move in desired direction of travel inclusive of
translation and rotation while at the same time balancing itself vertically in a smooth
fashion.

1.4. Limitation
Resources available limit us, in this project. Sensors used in this project are not suited for
wide rage of applications, as we would explain later in detail. Motors do not have inbuilt
encoders and hence cannot be used for dead reckoning. Or in other words, out of 7 state
spaces, we will be considering only two state spaces due to this limitation. Motors not
being a standard one, its gains could not be determined and hence computer simulation of
the same could not be carried out with accuracy. Due to limited time availability, battery
voltage could not be regulated for the motors, which plays an important role in the

(
response of the system. Acquisition of data on to the computer for the purpose of further
analysis of data is again limited due to less powerful microprocessor onboard.

)
2. CHAPTER

LITERATURE REVIEW


There has been a continuous and focused research towards personalized mobile vehicles.
Though they are commercially available in the market, they have their own
disadvantages. There are many experimental setups across the world with similar concept
targeting at varied range of application.

2.1. Segway
Segway Inc. of New Hampshire, USA is the manufacturer of a two-wheeled, self-
balancing electric vehicle, the Segway PT, invented by Dean Kamen. The name Segway
is a homophone of segue (a smooth transition, literally Italian for follows).
Segway, as the company claims, are worlds leading provider of personal electric
transportation. Segway markets a full line of zero-emissions personal transporters for
indoor, sidewalk, cross-terrain and patrol use, which deliver impressive energy efficiency
equivalent to 450 miles per gallon.
Segway claims for inbuilt technologies in its product like dynamic stabilization
(providing incredible maneuverability, zero turning radius, a small footprint), electric
propulsion (precise software-based approach to traction control and braking), smart
battery management (regenerative braking capability), advanced inertial sensing, intuitive
user interfaces and digital dashboard.
Its working principle remains the same. To move forward or backward on the
Segway PT, the rider just leans slightly forward or backward. To turn left or right, the
rider simply moves the LeanSteer frame left or right. Segways balance-control system
works in tandem with a pair or electric motors, one powering the each wheel. That

*
motion-control algorithm, which requires input from four sensors under the riders feet
and five solid state gyroscopes, is the soul of the Segway.
Specifications:
Motion control algorithms are run on a DSP designed by Texas Instruments
using a variety of embedded control and data buses like I2C, SPI and SCI
Segway onboard charger uses a standard 110V/220V AC cord
It applies a maximum torque of 2-hp to keep the rider upright
It can climb a 30-degree grade
It comes equipped with a 64-bit encrypted magnetic key to prevent theft.
It can travel as far as 24 miles on a single battery charge, depending on
terrain, payload and riding style.
The industrial model weighs 80 pounds, while the smaller, personal Segway
is 65 pounds.
At idle, the Segway can stand upright by itself, balancing on its internal
gyros, and will do so for up to 34 hours

In 2003, the company sold 6000 units, by September 2006 approximately 23,500 and
by May 2009 50,000 had been sold. Currently, the Segways will cost between $8000 and
$10,000.
For safety sake, the Segways control mechanisms were designed to be redundant.
The Segway contains two motors, each with a set of windings, but with a common shaft.
Since the motors can apply opposite torque, the machine can turn in place with no
additional turning radius. Segways also ship with kickstands.
Segways have had success in niche markets such as transportation for police
departments, military bases, warehouses, corporate campuses and industrial sites. The

+
legal roadworthiness of the Segway varies with different jurisdictions classifications of
the device as a motor vehicle.

2.2. Honda U3-X
The Honda U3-X is a self-balancing one-wheeled electric vehicle similar to Segway PT.
Honda developed the U3-X with technology originally developed for ASIMO, the
bipedal human project. Honda states that the U stands for unicycle and for universal.
Honda U3-X is a compact experimental device that fits comfortably between the
riders legs, to provide free movement in all directions just as in human walking forward,
backward, side to side and diagonally. It uses Honda Omni-Traction (HOT) drive system
to permit it to move in any lateral direction.
Specifications:
Dimension: Length - 313 mm, Width - 160 mm, Height - 647 mm
Weight: ~10 Kg (22lbs)
Top Speed: 6 km/h
Drive System: Honda Omni Traction (HOT) Drive System
Battery Type: Lithium-Ion battery
Operation Time: ~1 hour

2.3. Toyota Winglet
Toyota Motor Corporation announced the development of Winglet, a personal transport
assistance robot ridden in a standing position, self-balancing through gyroscopic sensors
detecting the gentle directional tilts of a rider. Designed to contribute to society by
helping people enjoy a safe and fully mobile life, the Winglet is a compact next-

,
generation everyday transport tool that offers advanced ease of use and expands the
users range of mobility.
The Winglet consists of a body (with a projected area the size of an A3 sheet of
paper) that houses an electric motor, two wheels, and internal sensors that constantly
monitor the users position and make adjustments in power to ensure stability.
Meanwhile, a unique parallel link mechanism allows the rider to go forward, backward
and turn simply by shifting body weight, making the vehicle save and useful even in tight
spaces or crowded environments.
Toyota Winglet enters production priced at $3,500.
Specifications (L Model)
Dimension: Length - 265 mm, Width - 464 mm, Height - 1130 mm
Weight: 12.3 kg
Maximum Cruising Speed: 6 km/ h
Turning Radius: 0
Cruising Range: 10 km
Charging Time: 1 h (full charge)

2.4. NXT Segway with Rider
This robot simulates a Segway, which is a two-wheeled self-balancing vehicle that a rider
stands on. By using the NXT color sensor as a simple proximity sensor to the ground,
measuring the reflected light, which will change slightly depending on how close the
sensor is to the ground, detecting the approximate tilt angle of the robot, the robot can
actually balance itself.


-

Figure 1: NXT Segway with Rider

Its underlying issues are as follows:
Lighting: External lights can confuse the color sensor, especially if the amount of
lighting or shadow varies as the robot moves around. Also, florescent lights will
interfere less than incandescent lights.
Surface: The robot requires a surface that has very uniform brightness. Blank
white paper will work well, or any surface that is a uniform solid color with no
pattern. A wood floor with a wood grain pattern, or a title floor with texture will
not work well, because the light reflection will vary as the robot moves.
Initial Balance: Since the color sensor cannot tell which way is up, the robot
must start perfectly balanced to begin with, and then program will try to maintain
that balance by trying to seek out the same reflected light reading that the color
sensor had at the beginning of the program. Specifically, the robot must be
physically balance, which is not the same as holding it visually straight up.

Programs that balance this robot is a basic PID controller that uses the color sensors
reading to determine an error in its position and then tries to correct for it. If the robot
starts not quite balanced, it will drive steadily in one direction, or perhaps even accelerate
in that direction and then fall.


./
2.5. JOE A Mobile Inverted Pendulum
The Industrial Electronics laboratory at the Swiss Federal Institute of Technology (EPFL)
in Lausanne has built a prototype of a revolutionary two-wheeled vehicle. Due to its
configuration with two coaxial wheels, each of which is coupled to a DC motor, the
vehicle is able to do stationary U-turns. A control system, made up of two decoupled
state space controllers, pilots the motors so as to keep the system in equilibrium.
This vehicle has 3 degrees of freedom. It can rotate about the wheel axis (pitch),
linearly translate and rotate about the vertical axis (yaw). Six state spaces variables fully
describe the dynamics of the system.

3. CHAPTER

MATERIALS AND METHODOLOGY

We will carry out a theoretical analysis of our project and try to mathematically calculate
the results with given assumptions and constraints. We hereby state that these results may
not closely match the experimental results due to underlying assumptions and
unavailability of few parameters that determine the response of the setup.

3.1. Study Area
Our area of study will be primarily Control Theory. It is an interdisciplinary branch of
engineering and mathematics that deals with the behavior of dynamical systems. The
external input of a system is called reference. When one or more output variables of a
system need to follow a certain reference over time, a controller manipulates the inputs to
a system to obtain the desired effect on the output of the system.
Our system is a practical application of a common control system experimental
setup, known as Inverted Pendulum. While a pendulum is normally stable handing
downwards, a pendulum upside-down is inherently unstable and needs a continuous
external force to keep it in an upright position. Every pendulum setup has two
equilibrium points Stable and Unstable Equilibrium. As the setup demands, we are
required to continuously take the tilt feedback and provide an external force to keep the
system balanced about its unstable equilibrium. There are various control algorithms that
can be implemented in order to achieve the same. However, we will be using most
commonly used algorithm, PID (Proportional Integral Differential).
We will also be looking at methods to manually tune the controller, looking at its
response to any given parameter.


.&
3.2. Equilibrium
Equilibrium is a state of a system in which the variables that describe the system are not
changing. Every pendulum pivot about a frictionless point has two equilibrium positions,
stable and unstable in its complete possible rotation. In a Stable equilibrium, if a small
perturbation away from equilibrium is applied, the system will return itself to the
equilibrium state. In an Unstable equilibrium, if a small perturbation away from
equilibrium is applied, the system will move farther away from its equilibrium state.
Strictly speaking, mathematically we determine whether a mechanical equilibrium is
stable or unstable by looking at the second derivative of the energy with respect to the
coordinate of interest.
As an example, assume we have a pendulum weighing 1kg and is pivot about a
point with the help of massless rod of length 50cm. Following will be its energy curve
(assuming the velocity to be zero at equilibrium) as a function of angle from vertical.

Figure 2: Stable and Unstable Equilibrium of the free pendulum pivot about a frictionless
point


.'
3.3. Assumptions
In order to make our study simple, we have made underlying assumptions, which may
result in slightly erroneous theoretical results and not closely matching our experimental
output.
A Cart and a Pendulum: A Cart is a base body, which consists of wheels,
motors and its housing, electronics, sensors and battery. Pendulum, on the other
hand, consists of a mass connected to the Cart through a rod. We will not consider
the moment of inertia of the cart and take it as a linearly translating body. The
assumption holds for small pitch (tilt) angles.
Motor Control: As it is difficult to control the torque of the motor, we wish to
control the same by varying the input voltage, though we do not know the relation
between torque and voltage. We will assume it to be linear in our case.

3.4. Experimental Model - Uncompensated
We present the theory of Inverted Pendulum. As previously stated, it was decided to build
a scaled down prototype carrying a weight instead of driver, in order to reduce the cost
and danger of test pilots. We will determine the dynamic equations of A Cart and a
Pendulum with the help of a free body diagram (FBD), linearize the system about its
unstable equilibrium, which is vertically upright position.

Figure 3: A Cart and A Pendulum


.(


Figure 4: Free Body Diagram of A Cart and A Pendulum

Equation of motion of the cart in the horizontal direction:
M x
..
+b x
.
+ N = u (1)
Writing an equation of motion in the vertical direction will not reveal any
information. Forces in the vertical direction will be balanced with the normal reaction
from the ground.
Equation of motion of the cart in the horizontal direction:
N = mx
..
+ml!
..
cos! !ml!
.
2
sin! (2)
Eliminating N from (1) and (2), we get our first dynamic equation
(M +m) x
..
+b x
.
+ml!
..
cos! !ml!
.
2
sin! = u (3)
Summing the forces in the perpendicular direction of the pendulum, we get
Psin! + Ncos! !mgsin! = ml!
..
+mx
..
cos! (4)
!Pl sin! ! Nl cos! = I !
..
(5)
Combining (4) and (5), we get our second dynamic equation,

.)
(I +ml
2
)!
..
+mgl sin! = !ml x
..
cos! (6)
We will now linearize the equations about ! = " , assume
! = " +#
Where ! represents a small angle from vertical. Hence,
cos! = !1
sin! = !"
(
d!
dt
)
2
= 0

After linearization, the equations of motion are
(I +ml
2
)!
..
!mgl! = ml x
..
(7)
(M +m) x
..
+b x
.
!ml !
..
= u (8)

Transfer Function:
(I +ml
2
)!(s)s
2
"mgl!(s) = mlX(s)s
2
(M +m)X(s)s
2
+bX(s)s "ml!(s)s
2
=U(s)
(9)
After rearranging the above two equations and cancelling a pole and a zero at the origin,
we get,
!(s)
U(s)
=
ml
q
s
s
3
+
b(I +ml
2
)
q
s
2
"
(M +m)mgl
q
s "
bmgl
q
(10)
Where q =[(M +m)(I +ml
2
) !(ml)
2
]


.*
3.5. Experimental Model - Compensated
We will now try to design a controller, which can make the system stable with the
continuous feedback and actuation mechanism. We will be using PID controller in our
case.
We will need to stabilize inverted pendulum about its vertical point and hence
angle from vertical will be a control parameter. We need to monitor theta continuously
and ensure its stability by giving required actuation to the motors. In order to simulate the
external disturbance, we have carried out impulse response model.




Figure 5: Control System diagram


Closed Loop Representation
!(s)
U(s)
=
G(s)
1+G(s)C(s)
(11)
where C(s) is a PID Controller with k
p
0 k
i
and k
d
as proportional, Integral and Differential
constants.
C(s) = k
d
s
2
+k
p
s +k
i
(12)
and G(s) is the open loop representation,
Controller
C(s)

Plant
G(s)

U(s)
! !
!(s) E(s)

R(s) = 0

.+
G(s) =
ml
q
s
s
3
+
b(I +ml
2
)
q
s
2
!
(M +m)mgl
q
s !
bmgl
q


3.6. Determination of Tilt Angle
Determining angle of tilt accurately is one of the critical factor in our implementation.
We will be using a sensor for this purpose, which will measure distance from the ground
at a specified angle. We will then proceed with mathematically calculating the angle of
tilt. This sensor has been chosen for the reasons mentioned later in this thesis.

Figure 6: Side View of the experimental setup showing lengths and angles


.,
cos! =
a
2
+b
2
!c
2
2ab
(13)
c
sin!
=
b
sin(90 +")
(14)
cos! =
a
2
+b
2
!(
bsin!
sin(90 +")
)
2
2ab
bsin!
cos"
= a
2
+b
2
!2abcos!
cos" =
bsin!
a
2
+b
2
!2abcos!

! = cos
!1
(
bsin"
a
2
+b
2
!2abcos"
) (15)

! is the angle of tilt from the vertical. Hence, once calculated, it will be fed into
the system to ensure it remains at zero all the time without much variation.
Further, though not accurate, there is an approximate relation between the output
voltage of the sensor and its distance from the obstacle. The sensor used in our
implementation detects distance from 3cm-40cm with voltage varying from 3.1V 0.3V
respectively. The relation can be quantified as follows:
d = 29.4! v
"1.1
"2.647
where d (in cms ) is distance of the sensor from obstacle and v (in volts ) is the analog
voltage measured.

.-

Figure 7: Analog output voltage (V) v/s Distance to reflective object (cm)

It is an analog sensor. Hence, it is required to filter the data before it can be used for
processing. We will come to this in the later part of this thesis.

&/
4. CHAPTER

EXPERIMENTS

Many experiments were carried out before coming up with a working prototype which
suits our purpose. Depending on feasibility and success, some of them are implemented
on the final prototype, while others are not.

4.1. Inertial Measurement Unit
An Inertial Measurement Unit, or IMU, is an electronic device to measure the relative
states of a static or mobile unit with respect to the inertial reference frame. It measures
and reports on a crafts velocity, acceleration, and gravitational forces, using a
combination of accelerometers, gyroscopes and magnetometers. IMUs are typically used
to maneuver aircraft, including unmanned aerial vehicles (UAVs), among many others,
and spacecraft, including shuttles, satellites and landers.

Figure 8: 9 Degrees of Freedom Razor IMU

Specifications:
9 Degrees of Freedom on a single, flat board
o ITG-3200 triple-axis digital output gyroscope
o ADXL345 13-bit resolution, 16g, triple-axis accelerometer

&.
o HMC5883L triple-axis digital magnetometer
Outputs of all sensors processed by on-board Atmega328 and sent out via a serial
stream
Autorun feature and help menu integrated into the example firmware
Output pins match up with FTDI basic breakout
3.5-16VDC input
ON-OFF control switch and reset switch
Dimensions: 1.1 x 1.6 (28 x 41mm)

Procedure:
As this IMU has an onboard processor, Atmega328, the output can be modified as desired
by changing its firmware. Procedure to modify its firmware is exactly same as that of
Arduino, an electronic open source prototypic platform. Hence, it was modified to
calculate and give euler angles i.e., pitch, roll and yaw as its output in a standard format,
taking input from accelerometer, gyroscope and magnetometer present onboard. A
special hardware called UART, piece of hardware that translates data between parallel
and serial forms, present on both sides of the communications enables the transfer of data
from IMU to Arduino. The continuous feedback of tilt angles is used to run a PID
algorithm in Arduino, which in turn actuates the motor.
Table 1: IMU-Arduino connections
IMU Arduino Purpose
RX0 TX1 (Pin 20) Transmit to IMU
TXI RX1 (Pin 19) Receive from IMU
3.3V 3.3V Supply Voltage

&&
GND GND Ground

It is not required to connect Pin RX0 of IMU as we are not going to send anything
to IMU, but just receive. Arduino was programmed to interpret the incoming data and use
it in PID algorithm. We can also independently generate 3.3V using appropriate
regulators.

Discussion:
The earths gravity is a constant acceleration where the force is always pointing down to
the center of the earth. When the accelerometer is parallel with the gravity, the measured
acceleration will be 1G, when the accelerometer is perpendicular with the gravity, it will
measure 0G. Unfortunately, this theory can be applied when the robot is completely
static. When robot is moving, there will be other components of acceleration acting on
the robot and causing the calculated tilt angle to be inaccurate.
It is challenging to design, test and integrate low-cost inertial sensors into a
powerful IMU for navigation uses. More considerations for system design and sensor
fusion algorithms need to be addressed to achieve autonomous navigations missions. The
sensor fusion problem is defined as making an optimal estimation of the required vehicle
states with the direct measurement from multiple sensors. There are possible solutions to
this problem such as Kalman filters or complimentary filters. The orientation is not
directly measurable and has to be estimated from a set of correlated states. Therefore, the
estimation accuracy of IMUs heavily relies on the sensor fusion algorithm. These
algorithms may have high demands for computational power, which is not possible for
low-cost IMUs.
Accelerometer lets us measure the forces caused by turning, accelerating or
braking, but the measurements wont be accurate unless the vehicle is level relative to the
earth during these maneuvers. If the vehicle tilts forward, we will get gravity components
measured by the accelerometer we use to measure the braking force. Most tilt sensors

&'
sense the direction of gravity as a reference direction. Braking, accelerating and turning a
vehicle produce accelerations on the vehicle. In a tilt measurement, we want to measure
gravitational acceleration only. In a measurement of a vehicles dynamics, we want to
measure motional acceleration only.
A tilt sensor (uncompensated) will give inaccurate angle measurements when
subjected to motion acceleration. An accelerometer will give inaccurate acceleration
measurements when the vehicle tilts.
Angular rate sensors can help correct for the effect of the forward tilt by
measuring rotations around the center of gravity of the vehicle. Unfortunately, angular
rate measure rotation rate, not rotation angle; the rotation angle is found by integrating
the measured rotation rate over time. Error in rotation rate will integrate in larger error
value. In addition, the random noise in the rate sensors will produce a random walk effect
in the calculated angle. These effects will limit the usefulness of all but the most
expensive angular rate sensors for measurements longer than a few minutes.
Fortunately, use the rate sensor to measure angle changes on short time scales.
Use the accelerometer like a tilt sensor to calculate the tilt angles, and force the rate
sensor derived angles to slowly match the accelerometer angles over a long time scale.
To perform these measurements, we need sensors, data-acquisition equipment and
computational power.

Results:
This IMU could not be used as the data was not reliable in case of dynamic environment.
Its acceleration compensation for the dynamic movements of the setup was not proper
due to limited computing power. Also, its delayed response makes it unsuitable for our
purpose. Further, one of the problems noticed was the continuous shift of reference angle
even during its operation.


&(
4.2. Android Orientation Sensor
All mobiles, now a days, are equipped with various sensors to give user an experience.
Android mobile operating systems are quite common and provide easy tools to exploit its
sensors for external use as desired by the user. Hence, the plan was to mount such mobile
on the system, build an android application which can acquire orientation data from the
sensors present onboard and use it for our purpose. This has an added advantage of
having a huge computing resource along with, as such smart phone comes with high end
processors. Please go through appendix to know more about writing an android
application and the code.


Figure 9: Android Application for the purpose of this experiment

In order to provide an interface between I/O devices and Android mobile, a device
called IOIO was used. All the computing inclusive if acquiring the orientation data
happens on mobile and the results are sent to IOIO for it to send signals to motors
accordingly.
This concept, if used, can then further be extended to exploit other features
available with smart phones like camera to send the image signals back to base station,
surveillance, remotely controlled over TCP/IP protocol via data connection.

&)

Results:
There was a considerable delay between the actual orientation and the sensor output.
Hence, it could not be used for our purpose.

4.3. Analog Sensor Filter
In order to detect tilt of our setup, we have installed a sensor, offset from the center,
which measures the distance from the ground. Tilt in either direction results in the change
in its distance from the ground. The magnitude of change provides the information
equivalent to tilt angle.
Sensor that we have used works on a principle of infrared intensity detection of
reflected waves. Onboard IR transmitter sends waves. IR receiver detects the intensity of
the reflected IR radiation and correspondingly varies the output voltage. The voltage data
is then fed to an analog to digital converter and is used as tilt information.
One of the drawbacks of infrared technology is its varying nature as a result of
ambient lighting conditions. As the ambient light in the surrounding might as well
contain infrared radiations, it affects the output of the sensor and hence needs to be
calibrated for different environments.

Figure 10: Sharp Sensor

As the output of this sensor is in the form of analog voltage, the data is noisy.
There are various filters that were tried out. Before we begin to implement these filters,
we should be aware of limited computing resources that we have. Any additional

&*
processing will have to be paid in terms of delayed results, which could be quite crucial
in our case.
50 100 150 200 250 300 350 400 450 500
200
220
240
260
280
300
320
340
360
380
400
Samples
D
i
s
t
a
n
c
e

S
e
n
s
o
r

O
u
t
p
u
t

(
S
t
e
a
d
y
)

Figure 11: Sensor Noisy Output

Also, there is a provision to implement those filters as digital or analog. We went
ahead with digital, as it provides flexibility to experiment with various kinds of filters
without any change in the hardware design.
It is recommended to put bypass capacitors at the supply voltage of the sensors for
surpassing power noise.

Averaging Filter:
This is the most common digital filter. In this filter, we take few samples and take an
average. However, we need to be cautionary here as there is a trade off between
smoothness of the data and delay. More the averaging samples, more the smoothness but
will have to compromise with delayed output.

&+
50 100 150 200 250 300 350 400 450 500
300
310
320
330
340
350
360
370
380
390
400
Samples
A
v
e
r
a
g
e

F
i
l
t
e
r

(
1
0

S
a
m
p
l
e
s
)


Raw Sensor Data
Average Filter Data (10 Samples)

Figure 12: 10 Sample Average Filter

50 100 150 200 250 300 350 400 450 500
300
310
320
330
340
350
360
370
380
390
400
Samples
A
v
e
r
a
g
i
n
g

F
i
l
t
e
r

(
2
0

S
a
m
p
l
e
s
)


Raw Sensor Data
Average Filter Data (20 Samples)

Figure 13: 20 Sample Average Filter

Please go through the appendix for its code implementation.

&,

Median Filter:
In this filter, we take few samples to find their median. Here again, number of samples
we choose calls for a trade off between the delay and smoothness.
50 100 150 200 250 300 350 400 450 500
300
310
320
330
340
350
360
370
380
390
400
Samples
M
e
d
i
a
n

F
i
l
t
e
r

D
a
t
a

(
1
0

S
a
m
p
l
e
s
)


Raw Sensor Data
Median Filter Data (10 Samples)

Figure 14: 10 Sample Median Filter


&-
50 100 150 200 250 300 350 400 450 500
300
310
320
330
340
350
360
370
380
390
400
Samples
M
e
d
i
a
n

F
i
l
t
e
r

D
a
t
a

(
2
0

S
a
m
p
l
e
s
)


Raw Sensor Data
Median Filter Data (20 Samples)

Figure 15: 20 Sample Median Filter

Smooth Filter:
In this filter, we take a weighted average of past and present data. Weight factor decides
the smoothness of the data. Higher the factor, smoother the filtered data.
sensorFiltered = sensorRaw! (1" filterVal) +sensorFiltered ! filterVal
where sensorFiltered is the filtered data, sensorRaw is the real-time acquired data and
filterVal is the weight factor to decide the smoothness.

'/
50 100 150 200 250 300 350 400 450 500
300
310
320
330
340
350
360
370
380
390
400
Samples
S
m
o
o
t
h

F
i
l
t
e
r

(
F
i
l
t
e
r

F
a
c
t
o
r
:

0
.
9
)


Raw Sensor Data
Smooth Filter Data (Filter Factor: 0.9)

Figure 16: Smooth Filter with smoothness factor of 0.9

50 100 150 200 250 300 350 400 450 500
300
310
320
330
340
350
360
370
380
390
400
Samples
S
m
o
o
t
h

F
i
l
t
e
r

(
F
i
l
t
e
r

f
a
c
t
o
r
:

0
.
7
)


Raw Sensor Data
Smooth Filter Data (Filter Factor: 0.7)

Figure 17: Smooth Filter with smoothness factor of 0.7

'.

Conclusion:
As seen from the above plots, median filter is better off as compared to other filters in
terms of smoothness, delay and computing resources required. We hence went ahead with
10 Sample Median Filter.

4.4. Motor Driver
We were initially using a standard motor driver used very commonly in all the basic
robotics applications. It was L298.
L298 Specifications:
Dual Full Bridge Driver
Operating supply voltage upto 46V
Total DC current upto 4A
Low Saturation voltage
Over-temperature protection
Logical 0 input voltage upto 1.5V (high noise immunity)
Current sensing capability
But motor was demanding more inrush current at the start than L298 could handle. Also,
due to sudden demand of power at the start, battery voltage goes down. As a result, it
shuts down the whole control circuit and resets it. Hence we had to go with a higher
capacity motor driver as mentioned later in this thesis under implementation chapter.


'&
4.5. Matlab Data Acquisition
In order to further analyze the response of the experimental setup, real time data of
distance sensor was imported to Matlab in various conditions. One of the major problem
that we faced while doing this was an added delay in onboard processing because of
sending an extra byte to the computer in every iteration through serial communication.
This had a considerable effect on the response of the setup and hence had to be removed.
Solution was to have a single PID computation for both the motors rather than having
separate computations for 2 motors. This implementation however doesnt enable any
rotational move along vertical axis to be taken but to balance in only one translational
direction.
2000 4000 6000 8000 10000 12000 14000 16000 18000
20
15
10
5
0
5
10
15
20
Samples
A
n
g
l
e

o
f

T
i
l
t



Figure 18: Variation in tilt angle while balancing with k
p
= 0.85, k
i
= 3.2, k
d
= 0.1 as
calculated from distance sensor

As we can see form above figure, there is a variation of 5 while it tries to balance about
equilibrium position for k
p
= 0.85, k
i
= 3.2, k
d
= 0.1.

''

Figure 19: Variation in tilt angle while balancing with k
p
= 0.85, k
i
= 3.2, k
d
= 0.1 as
measured by IMU

4.6. Maximum Angle of Tilt
There were many experiments conducted in order to determine the maximum angle of tilt
beyond which the system will not be able to come back to stable position. Impulsive
external forces were given various times and were plotted. As a result of these
experiments, it balances many a times, but sometimes not. The maximum angle in any of
the plots would determine the desired threshold angle.

'(
2000 4000 6000 8000 10000 12000 14000 16000 18000
15
10
5
0
5
10
15


X: 3629
Y: 11.64
Samples
A
n
g
l
e

o
f

T
i
l
t

(
i
n

d
e
g
r
e
e
s
)

Figure 20: Maximum angle of tilt beyond which the system will not be able to come back
to stable position

Above plot is one of the many experiments and shows the maximum angle of tilt
while the system balances back. The maximum angle is approximately 12 degrees.

Table 2: Maximum angle of tilt measured in various experiments

')
Experiment
No.
Maximum Angle of Tilt
while Balancing (in
degrees)
1 10.55
2 8.599
3 10.53
4 11.32
5 11.64
6 7.767
7 12.25
8 8.7
9 12.07
10 9.725
11 12.3
12 8.371
13 8.539
14 9.422
15 10.89

4.7. Position Drift
In order to quantify the position drift while the setup tries to balance, RPM (Rotations Per
Minute) that is sent to motors in the form of PWM (Pulse Width Modulation) was
acquired onto the computer software and integrated. However, there is an inherent
assumption here that PWM signals sent to motors are directly proportional to the RPM of
the motor. Position drift varies every time the experiment is repeated.

'*
2000 4000 6000 8000 10000 12000 14000 16000 18000
80
60
40
20
0
20
40
60
80
Samples
R
P
M

Figure 21: RPM output from PID controller while balancing

drift = rpm! (2! ! ! r)! t
where r is the radius of the wheel and t is the time for a sample.

'+
2000 4000 6000 8000 10000 12000 14000 16000 18000
50
40
30
20
10
0
10
20
30
40
50
Samples
D
r
i
f
t

(
c
m
)

Figure 22: Position drift (in cm) as in one of the experiments

Various experiments were conducted for the determination of drift. Drift was calculated
in the span of 25 seconds with the readings as tabulated below.

Table 3: Position drift measured in various experiments
Experiment No. Initial Position (cm) Final Position (cm) Drift (cm)
1 0.46 18.81 18.35
2 0 52.4 52.4
3 0 46.95 46.95
4 0 28.95 28.95
5 0 2.902 2.902
6 0 7.463 7.463
7 0 -11.69 -11.69

',
8 0 18.19 18.19
9 0 29.65 29.65
10 0 -27.21 -27.21
11 0 -23.06 -23.06


4.8. Payload
We conducted a set of experiments to find out the range of payload with which our setup
can safely balance, keeping the PID parameters constant. This would determine the
stability of the system with different physical parameters. Weights were varied for
various PID parameters with different length of pendulum. Its interesting to see the setup
balancing with a wide range of weights.
Following table demonstrates the readings. In order to carry out this experiment, we
multiplied a set of PID parameters with various multiplying factors (multiplier) and noted
the range of weights it can balance with different heights. Also, height is the distance of
the COM of weights from the line joining the motor shafts.

Table 4: Range of payload measured in various experiments
Multiplier Kp Ki Kd
Weight (gms)
Height
(cms)
Min Max
0.8 0.68 2.56 0.08 250 2450 50
0.9 0.765 2.88 0.09 300 2450 50
1 0.85 3.2 0.1 500 >2450 50
1.1 0.935 3.52 0.11 700 >2450 50

0.8 0.68 2.56 0.08 1000 >2450 25
0.9 0.765 2.88 0.09 1700 >2450 25
1 0.85 3.2 0.1 >2450 25
1.1 0.935 3.52 0.11 >2450 25

0.8 0.68 2.56 0.08 500 2450 38
0.9 0.765 2.88 0.09 750 >2450 38

'-
1 0.85 3.2 0.1 1200 >2450 38
1.1 0.935 3.52 0.11 1450 >2450 38

Weights used for testing weigh 200grams, 250grams, 300 grams and 500 grams, each in
different quantities, making up a total of 2450grams.

(/
5. CHAPTER

FINAL IMPLEMENTATION


After carrying out these experiments, prototype was finally implemented taking into
consideration their conclusions. This chapter describes all the specifics of our
implementation.

5.1. Materials Used
Motor:
Motor with necessary requirements like torque and speed was chosen. Motor best suiting
our purpose including affordability was High Torque DC Geared Motor 200RPM.
Specifications:
Speed: 200 RPM
Rated Operating Voltage: 12V DC
18000 RPM base motor
6mm Diameter shaft with M3 thread hole
Gearbox Diameter 37mm
Motor Diameter 28.5mm
Length without shaft: 63mm
Shaft Length: 15mm
Weight: 180gm

(.
Torque: 32kgcm
No-load current: 800mA
Load Current (Max): 7.5A
Metal Gearbox with off centered shaft.
There exists a small backlash in the motors, a free movement in the shaft without
powering it because of gear reduction.

Sensor:
It is an Infrared Proximity Sensor Short Range Sharp GP2D120XJ00F.

Figure 23: Infrared Proximity Sensor Short Range Sharp GP2D120XJ00F

Specifications:
Analog Output: 3.1V at 3cm 0.3V at 40cm
Supply Voltage: 4.5V 5.5V
Sensor has a Japanese Solderless Terminal (JST) Connector


(&
Microcontroller:

Figure 24: Arduino Mega2560

As a central processing unit, Arduino was used. It is an open-source electronics
prototyping platform based on flexible, easy-to-use hardware and software. It is intended
for artists, designers, hobbyists and anyone interested in creating interactive objects or
environments. Arduino can sense the environment by receiving input from a variety of
sensors and can affect its surroundings by controlling lights, motors and other actuators.
The microcontroller on the board is programmed using the Arduino Programming
Language (based on wiring) and the Arduino Development Environment.

Motor Driver:
In order to drive a motor, it was required to install a device or group of devices that could
amplify the control signals given by processor. Current allowance during normal
operation and at the start are the major deciding factors in choosing them.
Specifications:
Simple connectivity to IO pins of any MCU
Compatible with motors rated 6V-18V
Can easily deliver 20A of current during normal operation

('
Braking feature included without affecting the performance of an MCU

Battery:
Lithium Ion Rechargeable Battery Pack 12.6V 4000mAh (2C) was chosen over Lead
Acid because of weight constraints. Also, lithium ion battery can provide more current
without any major drop in voltage. In other words, it is a light-weight and small size
battery compared to any other battery of such capacity.
Specifications:
Weight: 176gm
Small in size and weight compared to Ni-Cd, Ni-MH and Lead Acid Batteries
Discharge capacity upto 8A
Charge in 90 to 180 minutes depending upon charger
Long life with full capacity for upto 1000 charge cycles
6X Li-ion 4.2V 2000mAh cells (3S2P)
Low maintenance
Maximum safe discharge current: 4000mA (2C)
Maximum charging current: 4000mA
Li-Ion batteries are very sensitive and can get damaged easily and permanently if not
used properly. Charging batteries with non-standard chargers will ensure reduction in
battery life and efficiency. If the batteries are drained beyond their discharge capacity,
they will get heated and will get damaged permanently. These batteries are rated for
discharge current. If the battery is rated at 2000mAh, 2C it means that it can discharge
4Ampere (2000mAx2) current at the maximum.


((
5.2. Hardware Design
In order to minimize the weight of the experimental setup, be stronger and affordable, we
decided to make the structure out of Aluminum. Before manufacturing, prototype was
designed in AutoCAD, a software application for computer-aided design and drafting in
2D format.


Figure 25: Experimental setup AutoCAD diagram

An aluminum sheet of thickness 2mm was cut, drilled and bent according the
AutoCAD design, to form a bracket to house motors, battery and electronics.

()

Figure 26: 2mm Aluminum bracket sheet

Araldite, an adhesive, was applied on the corners of the final bracket to ensure
strength. Battery, Sensor, and other electronics were installed shown in a photograph in
appendix. Wheels were also made out of aluminum, turned by a lathe machine, over
which a rubber O-ring was installed at the circumference to ensure proper traction with
the ground. An aluminum rod coming out from the center of the base bracket, high
enough to test the experimental setup with different physical parameters, was fixed.

Figure 27: Wheel AutoCAD Diagram


(*
Special care was taken to ensure that the systems weight is balanced and its center
of mass (COM) lies exactly above the center of the line along motor shafts. Hence,
payload like battery, electronics and a dummy weight were placed in parallel to the same
line.

5.3. Schematic and PCB Design
Apart from a standard central processor board, Arduino, there was a requirement to make
a customized PCB, Arduino Shield, to be able to connect sensors, motors and battery
having different types of connectors. PCB was designed in Eagle, a flexible and
expandable PCB layout, autorouter and CAM program. Schematic was made, PCB was
laid out and Gerber files were generated for the purpose of manufacturing.


Figure 28: PCB Schematic


(+

Figure 29: PCB Board Design


PCB Components
5V Switching Regulator
Motor Driver Output Port
Analog Sensor Input Port
Power Supply Port
Arduino Port

5.4. 5V Switching Regulator
As we have a single 12V battery to power motors, it was needed to step down 12V to
logic voltage i.e., 5V. Switching regulator was chosen over a linear voltage regulator to
save on power. Various capacitors at various levels as shown in the diagram were put to
ensure a smooth power supply.

(,

Figure 30: Circuit - 5V Switching Regulator

Specifications
Output: 5V Regulated
Input: 7V 40V Unregulated (LM2576-5V)
Input: 7V 70V Unregulated (LM2576HVT-5V)
Maximum Output Current: 3A

5.5. PID Controller Tuning
PID parameters affect the system dynamics. We are most interested in four major
characteristics of the closed loop step response. They are
Rise Time: The time it takes for the plant output to rise beyond 90% of the
desired level for the first time
Overshoot: It the difference between the peak level and the steady state
Settling Time: The time it takes for the system to converge to its steady state
Steady State Error: The difference between the steady-state output and desired
output

(-

Table 5: Effects of increasing each of the controller parameters k
p
, k
i
and k
d

Response Rise Time Overshoot Settling Time S-S Error
k
p
Decrease Increase NT Decrease
k
i
Decrease Increase Increase Eliminate
k
d
NT Decrease Decrease NT

Where NT means No definite Tread or Minor change.
Steps for designing a PID controller are:
Determine what characteristics of the system needs to be improved
Use k
p
to decrease the rise time
Use k
d
to reduce the overshoot and settling time
Use k
i
to eliminate the steady-state error

5.6. Translational Motion Control
Changing the setpoint for the PID controller individually for two motors can control the
translational motion of the robot. If we change one while keeping the other constant, the
robot will go into rotational motion as well. Higher the difference between the setpoint
for it to vertically balance and actual setpoint, faster will the translational motion be.

)/
6. CHAPTER

CONCLUSION

A self balancing robot was designed and manufactured as desired with limited resources
possible. It was able to balance smoothly with a maximum tilt error of 5 degrees. Range
of payload and its height for which it balances was quantified. Maximum angle of tilt for
balancing was also determined through various experiments. However there are some
limitations. Such technology is suitable only for flat ground. In order to make it work on
slant surface, the angle of slant needs to be fed into the system, either manually or using
some intelligence.
Project can further be extended to make a full scale personalized mobile vehicle
for common people, especially physically challenged. Further, such robots in higher
quantity can be made to work in coordination and realize a collective effort. This can also
be developed as a surveillance body and made to send back informative signals back to
base station from remote areas which are partially or completely inaccessible.
This report studies the balancing of a system in only one direction i.e., pitch. Such
theory can also be extended to balance in multiple axis i.e., pitch and roll and is under
research. They are generally called BallBots or Ball Balancing Robot.
Any practical implementation may not be easy and requires continuous effort and
improvement. In order to get a prototype working of similar nature, one is required to
have a good knowledge in manufacturing, product design, basic electronics, PCB design,
basic programming language like C, C++ or Java, and debugging skills. Latest
manufacturing technologies may not be available which may pose some problems and
may lead to a compromise on designs. Many concepts are generally not included in
theory and come into picture only when it comes to implementation stage. Something
working may not work in all conditions and will have constraints, similar to sensor
sensitivity, which keeps changing in accordance to ambient lighting conditions. Also, its

).
a good practice to perform any activity or experiment in best manner possible and not
implement any temporary solution which might end up taking more time in debugging
the unknown errors.
In this implementation, because we have non-zero integral constant in PID
controller, system does not start balancing the moment it is switched on, but takes some
time before the integral error goes to zero.

)&
REFERENCES

[1] Grasser F., DArrigo A., Colombi S. & Rufer A., JOE: A Mobile, Inverted
Pendulum, IEEE Transactions On Industrial Electronics, Vol.49, NO. 1, 107-114.
[2] Anderson, D. P. (2007, July 1). nBot, a two wheel balancing robot. Retrieved
from nBot Balancing Robot: http://www.geology.smu.edu/~dpa-www/robo/nbot/, June
18, 2009
[3] Victor Vicente Abreu, Balance-Bot, Presented to Universidade da Madeira,
Funchal, November 2009.
[4] CJC. (1997, August 8) CTM Example: State-space design for the inverted
pendulum. Retrieved from Control Tutorials for Matlab:
http://www.engin.umich.edu/group/ctm/examples/pend/invSS.html, April 15, 2009
[5] Segway - Simple Moving, Provider of Personal Electric Transportation,
Retrieved from Segway: http://www.segway.com/
[6] Honda U3-X, Self Balancing One-Wheeled Electric Vehicle, Retrieved from
http://en.wikipedia.org/wiki/Honda_U3-X
[7] Electronics S., Sparkfun Electronics 9 Degrees of Freedom Razor IMU,
Retrieved (May 2012) From Sparkfun Electronics:
http://www.sparkfun.com/products/10736
[8] Robotics, Robokits High Torque DC Geared Motor 200 RPM, Retrieved (May
2012) From Robokits:
http://robokits.co.in/shop/index.php?main_page=product_info&cPath=2_3&products_id=
275
[9] Robotics, Robokits DC Motor Driver 20A, Retreived (May 2012) From
Robokits:
http://robokits.co.in/shop/index.php?main_page=product_info&cPath=73&products_id=3
34
[10] Robotics, Robokits Lithium-Ion Rechargeable Battery Pack 12.6V 4000mAh
(2C), Retrieved (May 2012) From Robokits:
http://robokits.co.in/shop/index.php?main_page=product_info&cPath=13&products_id=2
25

)'
[11] Robotics, Rhydo Technologies (P) Ltd., Infrared Proximity Sensor Short Range
Sharp GP2D120XJ00F, Retrieved (May 2012) From Rhydolabz:
http://www.rhydolabz.com/index.php?main_page=product_info&cPath=137_144&produ
cts_id=833
[12] Hurbain P., Get up, NXTway!, Retreived from Get up, NXTway!:
http://www.philohome.com/nxtway/nxtway.htm, June 18, 2009
[13] Maria Landry, Sue Ann Campbell, Kirsten Morris and Cesar O. Aguilar,
Dynamics of an Inverted Pendulum with Delayed Feedback Control, Society of Industrial
and Applied Mathematics, 2005.
[14] Ahmed Nor Kasruddin Bin Nasir, Modelling and Controller Design for an
Inverted Pendulum System, A Thesis submitted for the award of degree of Master of
Electrical Engineering, Universiti Tecnologi Malaysia, April 2007.
[15] Wikipedia, The Free Encyclopedia, Segway, Retrieved from Wikipedia:
http://en.wikipedia.org/wiki/Segway_Inc.,
[16] Wikipedia, The Free Encyclopedia, Honda U3-X, Retrieved from Wikipedia:
http://en.wikipedia.org/wiki/Honda_U3-X,

)(
APPENDIX A
ARDUINO

This is very commonly used electronic platform for quick results without investing much
time and effort. Loads of tutorials are available online for getting started with this board,
including tutorials on coding language, hardware setup and procedure to burn the code
onto the Arduino. We can find all this information online from Arduino.cc which is quite
easy to understand and extensive. Hence, we will not be explaining them here.

Main Arduino Code
Changing the setpoint for the PID controller individually for two motors can control the
translational motion of the robot. If we change one while keeping the other constant, the
robot will go into rotational motion as well. Higher the difference between the setpoint
for it to vertically balance and actual setpoint, faster will the translational motion be.

-----------------------------------------------------------------------------------------
#include <PID_v1.h> //Adding PID library

//Defining pins for PWM output, rotational direction and brakes
const int pwm_L = 8, pwm_R = 9 ;
const int dir_L = 10, dir_R = 11;
const int brk_L = 12, brk_R = 13;

//Setpoint and PID Ouput variables
double setpoint_L, PID_out_L = 0;
double setpoint_R, PID_out_R = 0;

double sensorRaw = 0, sensorFiltered = 0;
int i=0, j=0, temp=0, samples = 10;
int rawData[10], frame[10], start=0;

//PID functions for two motors
PID PID_L(&sensorFiltered, &PID_out_L, &setpoint_L, 0.85, 3.2, 0.1, DIRECT);
PID PID_R(&sensorFiltered, &PID_out_R, &setpoint_R, 0.85, 3.2, 0.1, REVERSE);

//Analog input pin to which sensor is connected
const int analogInPin = A2;


void setup() {
//Serial Communication Initialization
Serial.begin(9600);

//Setting the direction control pins as output

))
pinMode(dir_L, OUTPUT);
pinMode(dir_R, OUTPUT);

//Setting the PWM output at the start as 0
analogWrite(pwm_L, 0);
analogWrite(pwm_R, 0);

//Setpoint about which our experimental setup balances
setpoint_L = 396;
setpoint_R = 396;

//Initialize the filter array with setpoint
for(i=0;i<samples;i++) {rawData[i] = setpoint_L;}
for(i=0;i<samples;i++) {frame[i] = setpoint_L;}

//To limit the output of the PID controller from -255 to 255
PID_L.SetOutputLimits(-255, 255);
PID_R.SetOutputLimits(-255, 255);

//Setting the PID computation to automatic mode
PID_L.SetMode(AUTOMATIC);
PID_R.SetMode(AUTOMATIC);
}

void loop() {
// read the analog in value:
sensorRaw = analogRead(analogInPin);

//This is a running sensor array
for(i=0;i<samples-1;i++) {rawData[i] = rawData[i+1];}
rawData[samples-1] = sensorRaw;

//Sensor array is copied in another array for filtering
for(i=0;i<samples;i++) {frame[i] = rawData[i];}

//Median Filter
for(i=0;i<samples;i++) {
for(j=i+1;j<samples;j++) {
if(frame[i] > frame[j]){
temp = frame[i];
frame[i] = frame[j];
frame[j] = temp;
}
}
}
sensorFiltered = frame[samples/2];

//Compute PID
PID_L.Compute();
PID_R.Compute();

//Send signals to the left motors as per PID Controller output
if(PID_out_L >= 0) {analogWrite(pwm_L, (PID_out_L)); digitalWrite(dir_L, LOW);}
else {analogWrite(pwm_L, -1 * (PID_out_L)); digitalWrite(dir_L, HIGH);}

//Send signals to the right motors as per PID Controller output
if(PID_out_R >= 0) {analogWrite(pwm_R, (PID_out_R)); digitalWrite(dir_R, LOW);}
else {analogWrite(pwm_R, -1 * (PID_out_R)); digitalWrite(dir_R, HIGH);}
}
-----------------------------------------------------------------------------------------

Averaging Filter Code
-----------------------------------------------------------------------------------------
//Analog input pin to which sensor is connected
const int analogInPin=A2;

double sensorRaw=0, sensorFiltered = 0;

//10 samples the sensor array
int i=0, samples=10;

)*
int frame[10];

void setup() {
//Serial Communication Initialization
Serial.begin(115200);

//Initialize the filter array with 0
for(i=0;i<samples;i++) {frame[i] = 0;}
}

void loop() {
// Read the analog in value:
sensorRaw = analogRead(analogInPin);

//This is a running sensor array
for(i=0;i<samples-1;i++) {frame[i] = frame[i+1];}
frame[samples-1] = sensorRaw;

sensorFiltered = 0;

//Taking an average
for(i=0;i<samples;i++) {
sensorFiltered += (double)(((double)frame[i])/((double)samples));
}

//Sending the data to the computer via Serial Communication
Serial.print(sensorRaw);
Serial.print(',');
Serial.print(sensorFiltered);
Serial.println(',');
}
-----------------------------------------------------------------------------------------

Median Filter Code
-----------------------------------------------------------------------------------------
//Analog input pin to which sensor is connected
const int analogInPin = A2;

double sensorRaw = 0, sensorFiltered = 0;

//10 samples the sensor array
int offset = 0, i=0, j=0, temp=0, samples = 10;
int rawData[10], frame[10];

void setup() {
//Serial Communication Initialization
Serial.begin(9600);

//Initialize the filter array with 0
for(i=0;i<samples;i++) {rawData[i] = 0;}
for(i=0;i<samples;i++) {frame[i] = 0;}
}

void loop() {
// Read the analog in value:
sensorRaw = analogRead(analogInPin);

//This is a running sensor array
for(i=0;i<samples-1;i++) {rawData[i] = rawData[i+1];}
rawData[samples-1] = sensorRaw;

//Sensor array is copied in another array for filtering
for(i=0;i<samples;i++) {frame[i] = rawData[i];}

//Median Filter
for(i=0;i<samples;i++) {
for(j=i+1;j<samples;j++) {
if(frame[i] > frame[j]){
temp = frame[i];
frame[i] = frame[j];

)+
frame[j] = temp;
}
}
}
sensorFiltered = frame[samples/2];

//Sending the data to the computer via Serial Communication
Serial.print(sensorRaw);
Serial.print(',');
Serial.print(sensorFiltered);
Serial.println(',');

//Delay for analog to digital conversion to stabilize
delay(1);
}
-----------------------------------------------------------------------------------------

Smooth Filter Code
-----------------------------------------------------------------------------------------
//Analog input pin to which sensor is connected
const int analogInPin = A2;

//Smoothness factor
double filterVal=0.9;

//10 samples the sensor array
double sensorRaw = 0, sensorFiltered = 0;
int i=0, samples = 10;
int frame[10];

void setup() {
//Serial Communication Initialization
Serial.begin(115200);

//Initialize the filter array with 0
for(i=0;i<samples;i++) {frame[i] = 0;}
}

void loop() {
// Read the analog in value:
sensorRaw = analogRead(analogInPin);

//Smooth Filter
sensorFiltered = (sensorRaw * (1 - filterVal)) + (sensorFiltered * filterVal);

//Sending the data to the computer via Serial Communication
Serial.print(sensorRaw);
Serial.print(',');
Serial.print(sensorFiltered);
Serial.println(',');
}
-----------------------------------------------------------------------------------------

Programming IMU
Programming an IMU is similar to that of Arduino and uses the same development
environment. Complete information regarding it can be found as in the reference [7].

),
APPENDIX B
ANDROID

Android application was programmed in JAVA language in an open source editor called
Eclipse which has a provision for adding Android plugin and its libraries. Learning
resources are extensively available on Android developer website, starting from
installation, adding the required plugins, programming language, and getting an
application working on standalone android mobile.
Application needs to communicate with IOIO in order to exchange the information and
control signals. IOIO also has tutorials available on web along with sample programs to
get started. Once we know how to access each of the ports and control them, we can
modify as desired. IOIO library needs to be added before compiling the code containing
IOIO commands.


)-
APPENDIX C
MATLAB

Data acquired was plotted for further analysis and quantifying our results. We tried to
incorporate computations in the Matlab code as much as possible and not do it onboard in
Arduino. Hence, raw data was acquired and further processing was done on computer.
Matlab codes below acquire 20000 samples and plot the same. It can be changed as
desired.
Plotting Tilt Angle
-----------------------------------------------------------------------------------------
%To close and delete all the open ports
clear all; close all; clc;
delete(instrfindall);

%Creating a serial handler
s = serial('/dev/cu.usbmodemfd121', 'BaudRate', 115200);
s.InputBufferSize = 50000;

%Opening the port
fopen(s);

%Number of iterations and Stored samples
iteration = 20000;
samples = 20000;

%Intitializing data
angleArray = zeros(1, samples);

%Figure for plotting data
figure;
hold on;

%Starting iterations
for i=1:iteration
%Read a line and convert it into voltage reading
voltage= str2double(fgets(s))*5/1024;

%Find out distance of the sensor from the ground
distance = 29.4*voltage^(-1.1)-2.647;

%Find out angle
angle=180*acos(distance*sin(45*pi/180)/sqrt(distance^2+6.3^2-
2*distance*6.3*cos(45*pi/180)))/pi;

if(distance<8)
angle = -angle;
end


%Modifying the data according to the new value
angleArray = [angleArray(2:samples) angle];
end

%Closing the port
fread(s,s.BytesAvailable);

*/
fclose(s);

%Plotting the data
i=1:iteration;
plot(i,angleArray,'r');
grid on;

%Labelling
xlabel('Samples');
ylabel('Angle of Tilt');
delete(s);
delete(instrfindall);

-----------------------------------------------------------------------------------------

Plotting RPM
-----------------------------------------------------------------------------------------
%To close and delete all the open ports
clear all; close all; clc;
delete(instrfindall);

%Creating a serial handler
s = serial('/dev/cu.usbmodemfd121', 'BaudRate', 115200);
s.InputBufferSize = 50000;

%Opening the port
fopen(s);

%Number of iterations and Stored samples
iteration = 20000;
samples = 20000;

%Intitializing data
rpmArray = zeros(1, samples);

%Figure for plotting data
figure;
hold on;
drift=0;

%Starting iterations
for i=1:iteration
%Read a line and proportionally convert it into rpm
rpm = str2double(fgets(s))*200/256;

%Modifying the data according to the new value
rpmArray = [rpmArray(2:samples) rpm];
end

%Closing the port
fread(s,s.BytesAvailable);
fclose(s);

%Plotting the data
i=1:iteration;
plot(i,rpmArray,'r');
axis([1500 18000 -50 50]);
grid on;

xlabel('Samples');
ylabel('PWM');
delete(s);
delete(instrfindall);

-----------------------------------------------------------------------------------------

*.

Plotting Drift
-----------------------------------------------------------------------------------------
%To close and delete all the open ports
clear all; close all; clc;
delete(instrfindall);

%Creating a serial handler
s = serial('/dev/cu.usbmodemfd121', 'BaudRate', 115200);
s.InputBufferSize = 50000;

%Opening the port
fopen(s);

%Number of iterations and Stored samples
iteration = 20000;
samples = 20000;

%Intitializing data
driftArray = zeros(1, samples);

%Figure for plotting data
figure;
hold on;
drift=0;

%Starting iterations
for i=1:iteration
%Read a line
rawData= str2double(fgets(s))*200*2*pi*5*25/(256*(iteration-3500)*60);
if(i>1500 && i<18000)
drift=drift+rawData;
end

%Modifying the data according to the new value
driftArray = [driftArray(2:samples) drift];
end

%Closing the port
fread(s,s.BytesAvailable);
fclose(s);

%Plotting the data
i=1:iteration;
plot(i,sensorData,'r');
axis([1500 18000 -50 50]);
grid on;

%Labeling
xlabel('Samples');
ylabel('Drift (cm)');
delete(s);
delete(instrfindall);
-----------------------------------------------------------------------------------------


*&
APPENDIX D
PHOTOGRAPHS


This was the first prototype made for this project. It was very simple, light weight setup
with plastic geared motors and Arduino. It was tried with IMU but had considerable
delay in serial communication. Moreover, it was physically unstable according to theory.
Motors again did not have enough torque to respond instantly for the tilt.



*'

This was the second prototype with an implementation of android mobile and IOIO. Data
from Mobiles orientation sensors were acquired and processed in the application and
output signals were sent to IOIO for communicating it to motors. This was failure again
because of delayed sensor output and insufficient torque of motors.



This was the third prototype with servomotors with enough torque required for it to
balance theoretically. Again, Arduino was used for processing along with PID library.
Distance sensor was used to detect the tilt of the system. There was no requirement of
motor drivers because they were inbuilt in the servo. Also, instead of including PID

*(
control in arduinos code, inbuilt servo controller was used to ensure that motors come
back to setpoint, which is defined by control signals. Also, system was demanding motors
to have more speed to respond instantly.
As a result, it was balancing but with a drawback of we having no control over PID
parameters as it was all inbuilt in the servo. Hence, such system would not be suitable if
we need to modify it for different range of weights.



The third prototype did not have enough speed to catch up and respond instantly to tilts.
It was required to increase the speed of the system. Hence, wheels with higher diameter,
which to some extent solved the problem, but not completely, replaced existing wheels.
We were still not in a position to modify the system for balancing different weights.




*)

This is the fourth and final prototype which is working as we desired, satisfying all our
conditions. Motors are with good speed and torque. It has an Arduino onboard running
with PID algorithm and the parameters can be changed as per our requirements. Sensor
was again analog distance with voltage varying in accordance with its distance with the
ground.

Vous aimerez peut-être aussi