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 IIT-Madras, 600 036
Date: 10th May 2012
Place: Chennai
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.
i"
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 twowheeled 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 twowheeled 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.
ii"
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 "
iii"
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 iv"
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 , ki and kd
v"
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, ki = 3.2, kd = 0.1 Figure 19
Variation in tilt angle while balancing with
k p = 0.85, ki = 3.2, kd = 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
"
vi"
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
"
vii"
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
viii"
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 "
kp
Proportional constant
ki
Integral constant
kd
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
ix"
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 customer’s 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. It’s quite difficult to hold a pen in your hand and balance it. But to do the same thing with a broom in your hand, it’s relatively simple. The reason is that there is more time to compensate. For that reason it’s 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, 2"
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 being’s 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 3"
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.
4"
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, selfbalancing 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 world’s 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. Segway’s balance-control system works in tandem with a pair or electric motors, one powering the each wheel. That 5"
motion-control algorithm, which requires input from four sensors under the rider’s 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 Segway’s 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 6"
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 rider’s 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-
7"
generation everyday transport tool that offers advanced ease of use and expands the user’s 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 user’s 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.
8"
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 sensor’s 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.
9"
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.
10"
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
12"
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 13"
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: ..
. 2
..
N = m x+ ml ! cos! ! ml ! sin ! …(2)" Eliminating N from (1) and (2), we get our first dynamic equation" ..
.
. 2
..
(M + m) x + b x + ml ! cos! ! ml ! sin ! = u …(3)
Summing the forces in the perpendicular direction of the pendulum, we get ..
..
P sin ! + N cos! ! mgsin ! = ml ! + m x cos! …(4) ..
!Pl sin ! ! Nl cos! = I ! …(5) "Combining (4) and (5), we get our second dynamic equation, 14"
..
..
(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! ( )2 = 0 dt 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,
ml s !(s) q = "…(10)" b(I + ml 2 ) 2 (M + m)mgl bmgl U(s) 3 s + s " s" q q q Where" q = [(M + m)(I + ml 2 ) ! (ml)2 ] "
15"
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.
U(s)
R(s) = 0
!"
E(s)
Controller
!"
C(s)
Plant
!(s)
G(s)
Figure 5: Control System diagram
Closed Loop Representation
!(s) G(s) = …(11) U(s) 1+ G(s)C(s) where C(s) is a PID Controller with k p ," ki and" kd as proportional, Integral and Differential constants.
C(s) = kd s 2 + k p s + ki …(12)
and G(s) is the open loop representation,
16"
ml s q G(s) = " b(I + ml 2 ) 2 (M + m)mgl bmgl 3 s + s ! s! q q 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
17"
cos ! =
a2 + b2 ! c2 …(13) 2ab
c b …(14) = sin ! sin(90 + " ) bsin ! 2 ) sin(90 + " ) 2ab
a2 + b2 ! ( cos ! =
bsin ! = ± a 2 + b 2 ! 2ab cos ! cos "
cos " = ±
! = cos!1 (
bsin ! 2
a + b 2 ! 2ab cos !
bsin " a 2 + b 2 ! 2ab cos "
) …(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.
18"
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.
19"
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 craft’s 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 20"
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
21"
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 earth’s 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 won’t 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 22"
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 vehicle’s 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.
23"
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. 24"
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 25"
processing will have to be paid in terms of delayed results, which could be quite crucial in our case.
400 380
Distance Sensor Output (Steady)
360 340 320 300 280 260 240 220 200
50
100
150
200
250 Samples
300
350
400
450
500
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. 26"
400 Raw Sensor Data Average Filter Data (10 Samples)
390
Average Filter (10 Samples)
380 370 360 350 340 330 320 310 300
50
100
150
200
250 Samples
300
350
400
450
500
Figure 12: 10 Sample Average Filter
400 Raw Sensor Data Average Filter Data (20 Samples)
390
Averaging Filter (20 Samples)
380 370 360 350 340 330 320 310 300
50
100
150
200
250 Samples
300
350
Figure 13: 20 Sample Average Filter
Please go through the appendix for its code implementation. 27"
400
450
500
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.
400 Raw Sensor Data Median Filter Data (10 Samples)
390
Median Filter Data (10 Samples)
380 370 360 350 340 330 320 310 300
50
100
150
200
250 Samples
300
350
Figure 14: 10 Sample Median Filter
28"
400
450
500
400 Raw Sensor Data Median Filter Data (20 Samples)
390
Median Filter Data (20 Samples)
380 370 360 350 340 330 320 310 300
50
100
150
200
250 Samples
300
350
400
450
500
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.
29"
400 Raw Sensor Data Smooth Filter Data (Filter Factor: 0.9)
390
Smooth Filter (Filter Factor: 0.9)
380 370 360 350 340 330 320 310 300
50
100
150
200
250 Samples
300
350
400
450
500
Figure 16: Smooth Filter with smoothness factor of 0.9
400 Raw Sensor Data Smooth Filter Data (Filter Factor: 0.7)
390
Smooth Filter (Filter factor: 0.7)
380 370 360 350 340 330 320 310 300
50
100
150
200
250 Samples
300
350
400
Figure 17: Smooth Filter with smoothness factor of 0.7 30"
450
500
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.
31"
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 doesn’t enable any rotational move along vertical axis to be taken but to balance in only one translational direction.
20
15
10
Angle of Tilt
5
0
−5
−10
−15
−20
2000
4000
6000
8000
10000 Samples
12000
14000
16000
18000
Figure 18: Variation in tilt angle while balancing with k p = 0.85, ki = 3.2, kd = 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, ki = 3.2, kd = 0.1 .
32"
Figure 19: Variation in tilt angle while balancing with k p = 0.85, ki = 3.2, kd = 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.
33"
15
X: 3629 Y: 11.64
Angle of Tilt (in degrees)
10
5
0
−5
−10
−15
2000
4000
6000
8000
10000 Samples
12000
14000
16000
18000
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
34"
Experiment
Maximum Angle of Tilt
No.
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.
35"
80
60
40
RPM
20
0
−20
−40
−60
−80
2000
4000
6000
8000
10000 Samples
12000
14000
16000
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.
36"
18000
50 40 30 20
Drift (cm)
10 0 −10 −20 −30 −40 −50
2000
4000
6000
8000
10000 Samples
12000
14000
16000
18000
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
37"
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. It’s 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
Kd
Weight (gms) Min Max
Height (cms) 50 50 50 50
Kp
Ki
0.8 0.9 1 1.1
0.68 0.765 0.85 0.935
2.56 2.88 3.2 3.52
0.08 0.09 0.1 0.11
250 300 500 700
2450 2450 >2450 >2450
0.8 0.9 1 1.1
0.68 0.765 0.85 0.935
2.56 2.88 3.2 3.52
0.08 0.09 0.1 0.11
1000 1700 >2450 >2450
>2450 >2450
25 25 25 25
0.8 0.9
0.68 0.765
2.56 2.88
0.08 0.09
500 750
2450 >2450
38 38
38"
1 1.1
0.85 0.935
3.2 3.52
0.1 0.11
1200 1450
>2450 >2450
38 38
Weights used for testing weigh 200grams, 250grams, 300 grams and 500 grams, each in different quantities, making up a total of 2450grams.
39"
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 40"
•
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
41"
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 42"
•
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.
43"
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.
44"
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
45"
Special care was taken to ensure that the system’s 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
46"
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.
47"
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 48"
Table 5: Effects of increasing each of the controller parameters k p , ki and kd Response
Rise Time
Overshoot
Settling Time
S-S Error
kp
Decrease
Increase
NT
Decrease
ki
Decrease
Increase
Increase
Eliminate
kd
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 kd to reduce the overshoot and settling time
•
Use ki 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.
49"
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, it’s 50"
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.
51"
REFERENCES
[1] Grasser F., D’Arrigo 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 52"
[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,
53"
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
//Adding PID library //Defining pins const int pwm_L const int dir_L const int brk_L
for PWM output, rotational direction and brakes = 8, pwm_R = 9 ; = 10, dir_R = 11; = 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
54"
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 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;
55"
int frame[10]; void setup() { //Serial Communication Initialization Serial.begin(115200); //Initialize the filter array with 0 for(i=0;i
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 frame[j]){ temp = frame[i]; frame[i] = frame[j];
56"
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
*
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].
57"
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.
58"
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^22*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);
59"
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); -----------------------------------------------------------------------------------------
60"
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); -----------------------------------------------------------------------------------------
61"
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.
62"
This was the second prototype with an implementation of android mobile and IOIO. Data from Mobile’s 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 63"
control in arduino’s 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.
64"
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.
65"