development of omnidirectional mobile robot for robocon 2012 tey ...

DEVELOPMENT OF OMNIDIRECTIONAL MOBILE ROBOT
FOR ROBOCON 2012
TEY WEI KANG
UNIVERSITI TEKNOLOGI MALAYSIA

UNIVERSITI TEKNOLOGI MATAYSIA
PSZ I ?:16 {Pind. I IATI
DECLARATION OF THESIS / UNDERGRADUATE PROJECT PAPER AND COPYRIGHT
Author's full nsme :
Date of birrh :
-irv LIET Mwa
g8lp lb -23 - F t /*
Title : YEVfrLaVn f fuT, aF- ,pflry_f ,t?tRF e Trg.N,frL
Acodemic Session :
I declore thot this thesis is clossified os :
tl
tl m
CONFIDENTIAL {Contoins confidentiol informotion under the Officiol Secret
AcI 19721*
RESIRICIED (Contoins restricted informotion os specified by the
orgonizotion where reseorch wos done)*
OPEN ACCESS logree thot mythesis to be published os online open occess
(fulltext)
I ocknowledged thot UniversitiTeknologi Moloysio reseryes the right os follows:
l. The thesis is the property of UniversitiTeknologi Moloyaio.
2- The Librory of UniversitiTeknologi Mololaio hos the dght to moke copies for the purpose
of reseorch only.
3. The Librory hos the right to moke copies of the thesis for qcodemic exchonge.
,/M
SIGNATURE
pg loJ,$""zJ - s//F
(NEW lC NO. IPASSPORT NO.)
Dote: t"/V/fg
Cerfified by :
SIGNATURE OF SUPERVISOR
D,r" Y*:Kg\ CJ^t W
Dote : 9* P/tl b IX lL
NOIES : * lf the thesis is CONFIDENTAL or RESTRICTFD, pleose ottoch with the letter from
the orgonizotion with pedod ond reosons for confidentiolity or restriction.

'T hereby declare that I have read this report and in my opinion this report is zufficient
in terms of scope and quality for the award of the degree of Bachelor of Engineering
Signature :
(Elecfrical - Mechatronics)"
W
Name : Dr. YEONG CHE FAI
Date : June 26,2012

DEVELOPMENT OF OMNIDIRECTIONAL MOBILE ROBOT
FOR ROBOCON 2012
TEY WEI KANG
A report submitted in partial fulfilment of the
requirements for the award of the degree of
Bachelor of Engineering (Electrical - Mechatronics)
Faculty of Electrical Engineering
Universiti Teknologi Malaysia
JUNE 2012

I declare that this report entitled “DEVELOPMENT OF OMNIDIRECTIONAL
MOBILE ROBOT FOR ROBOCON 2012” is the result of my own research except
as cited in the references. The report has not been accepted for any degree and is not
concurrently submitted in candidature of any other degree.
Signature :
Name : TEY WEI KANG
Date : June 30, 2012
ii

To my dearest family and friends, especially to my parent for supporting every
decision I had made. Thanks for trusting me all the while and sorry for not being by
your side always.
iii

ACKNOWLEDGEMENT
This project would not have been possible without the support of various
individuals. I can hardly deliver my appreciation to each of them. Nevertheless, I
would like to take this opportunity to express my gratitude to them here.
First of all, I would like to thank to my project supervisor, Dr. Yeong Che Fai
who was abundantly helpful and offered invaluable assistance, support and guidance.
He had spent many times in guiding and helping me especially during the participation
of this project in Dream Catcher Competition. His encouragement to me is the greatest
motivation for me to continue this project.
Deepest gratitude are also due to the UTM Robocon Team members, seniors
and lecturers. Without the support of UTM Robocon Team in terms of materials and
knowledges sharing, I will never had completed this project. And also not to forget
about the Lab technician, Mr. Khalid bin Lipot who guiding me a lot in mechanical
structure construction.
Special thanks also to all my graduate friends, especially Fong Jiunn Shean for
sharing the knowledge and providing invaluable assistance.
Last but not least, I wish to express my love and gratitude to my beloved
families. Their understanding and endless love throughout the duration of my studies
is invaluable. Without their support and encouragement, its impossible for me to
complete this project. And also to those whom I failed to mention here, your help
is much appreciated.
iv

ABSTRACT
Nowadays, autonomous mobile robot had been developed in order to reduce
human work load in moving heavy load. However, most of the robots are designed
to use differential drive method. Its generally takes more steps and more complicated
movement in order to navigate to certain position as compared to Omnidirectional
mobile robot. In this project, an omnidirectional mobile robot is developed for 2D
planar motion and capable of moving in translation (x, y) and rotation around their
centre of gravity (φ). It consists of three actuators which each attached to an omniwheel
alighting 120 degree apart and used gyroscope and distance sensors as feedback for the
navigation system. By using NIsbRIO9632XT by National Instrument as the main
controller, the navigation algorithm formula and PID block can be processed with
high speed to ensure fast response. Functional blocks such as PWM generator and
Quadrature Encoder Interface(QEI) block is designed inside the onboard FPGA to
interface with the encoders and motor drivers. By controlling the speed of each motor,
navigation of this robot can be done and optimized.
v

ABSTRAK
Pada masa kini, robot mudah alih automatik telah direkakan untuk
mengurangkan beban kerja manusia ketika menggerakkan beban yang berat.
Walau bagaimanapun, kebanyakan robot yang direka adalah menggunakan kaedah
bergerakan berbeza. Secara amnya, robot jenis ini mengambil lebih banyak langkah
dan pergerakan yang lebih rumit untuk menavigasi ke kedudukan tertentu berbanding
robot bergerakan Omnidirectional. Dalam projek ini, robot bergerakan omnidirectional
direkakan untuk pergerakan satah 2D dan ia mampu bergerak dalam satah (x, y) dan
putaran di sekitar pusat graviti (φ) ia. Ia terdiri daripada tiga penggerak yang setiap
satunya dipasang kepada omniwheel dan disusun dalam 120 darjah sesama sendiri
dan pengesan-pengesan yang digunakan ialah giroskop dan pengesan jarak sebagai
maklum balas kepada sistem navigasi. Dengan menggunakan NIsbRIO9632XT dari
National Instrument sebagai pengawal utama, formula navigasi algoritma dan blok-
blok PID boleh diproses dengan kelajuan yang tinggi untuk memastikan tindak balas
yang cepat. Blok fungsi seperti penjana PWM dan blok kuadratur Pengekod Antara
Muka (QEI) direka dalam FPGA atas papan litar untuk berantara muka dengan
pengesan jarak dan litar pemandu motor. Dengan mengawal kelajuan setiap motor,
navigasi robot ini boleh dilakukan dan dioptimumkan.
vi

TABLE OF CONTENTS
CHAPTER TITLE PAGE
DECLARATION ii
DEDICATION iii
ACKNOWLEDGEMENT iv
ABSTRACT v
ABSTRAK vi
TABLE OF CONTENTS vii
LIST OF TABLES ix
LIST OF FIGURES x
LIST OF ABBREVIATIONS xii
LIST OF SYMBOLS xiii
1 INTRODUCTION 1
1.1 Project Background 1
1.2 Problem Statement 4
1.3 Objectives 5
1.4 Scopes of Project 5
2 LITERATURE REVIEW 6
2.1 Implementation of Obstacle Avoidance and ZigBee
Control Functions for Omni Directional Mobile
Robot 6
2.2 Omnidirectional Mobile Home Care Robot 7
2.3 Design and Control of an Omnidirectional Mobile
Robot with Steerable Omnidirectional Wheels 8
2.4 Motion Control of an Omnidirectional Mobile
Robot 9
2.5 The Omni-directional Wheelchair for The Elderly 11
2.6 Motion Control of An Omnidirectional Mobile
vii
robot 11

3 METHODOLOGY 12
viii
3.1 Project Flow 12
3.2 System Overview 13
3.2.1 Hardware 15
3.2.2 Software 20
3.3 Gantt Chart 25
4 RESULTS AND DISCUSSION 26
4.1 Results 26
4.2 Discussion 29
5 CONCLUSION 31
REFERENCES 32
Appendix A 33

LIST OF TABLES
TABLE NO. TITLE PAGE
ix

LIST OF FIGURES
FIGURE NO. TITLE PAGE
1.1 ABU Robocon 2006 Game Field Layout 2
1.2 ABU Robocon 2007 Game Field Layout 2
1.3 ABU Robocon 2009 Game Field Layout 3
1.4 ABU Robocon 2012 Game Field Layout 3
1.5 Basic function of line following sensor: (a) Both motors
moving in same speed (b) Left motor moves faster (c)
Right motor moves faster 4
1.6 Comparison between CDDMR and ODMR 4
2.1 Omnidirectional Chassis and FPGA Development Board 6
2.2 Experimental Omnidirectional Mobile Service Robot 7
2.3 Omnidirectional Mobile Robot with Steerable Omnidi-
rectional Wheels 8
2.4 Photo of robot inside working station 9
2.5 Data flow of the system 9
2.6 Kinematics Equation of the robot 10
2.7 Omnidirectional Wheelchair 11
3.1 Project Flow 12
3.2 Mechanical hardware top and bottom view 13
3.3 System OverView 14
3.4 Solidworks Design 15
3.5 Top View of the Robot 16
3.6 Coupling between Motor and Omniwheel 16
3.7 Bottom View of the Robot 17
3.8 Encoder Attachment 17
3.9 Snapshot of NIsbRIO9632xt 18
3.10 Connector Board 19
3.11 MD10C H-bridge Motor Driver 19
3.12 Clock Generator 20
3.13 QEI Functional Block Diagram 21
3.14 QEI pattern 21
x

3.15 PWM Functional Block Diagram 22
3.16 APM2.0 Ardupilot 23
3.17 MAX232 Schematics 23
3.18 Navigation Equation [1] 24
3.19 Gantt Chart for FYP1 25
3.20 Gantt Chart for FYP2 25
4.1 QEI Graphical User Interface 26
4.2 PWM Output 27
4.3 Navigate in X-direction 28
4.4 Navigate in Y-direction 28
4.5 Navigate in XY-direction 29
A.1 Gantt Chart for FYP1 33
A.2 Gantt Chart for FYP2 33
xi

LIST OF ABBREVIATIONS
ABU Robocon – Asia-Pacific Broadcasting Union Robot Contest
UTM – Universiti Teknologi Malaysia
CDDMR – Conventional Differential Driven Mobile Robot
ODMR – Omnidirectional Mobile Robot
FPGA – Field Programmable Gate Array
DC – Direct current
DOF – Degree of freedom
PC – Personal computer
PWM – Pulse width modulation
3D – Three Dimensional
NI – National Instrument
GUI – Graphical User Interface
I/O – Input and output
VI – Virtual Instrument
QEI – Quadrature Encoder Interface
DFF – D Flip Flop
UART – Universal Asynchronous Receiver and Transmitter
PID – Proportional Integral Derivative
PCI – Peripheral Component Interconnection
WIFI – Wireless Fidelity
–
xii

LIST OF SYMBOLS
˙Θ – Angular Velocity of wheel
R – Radius of wheel
δ – Angle of the wheel from references axis
φ – Difference of desired angle to current angle
L – Robot radius
˙
Xm – Derivative of coordinate X in Cartesian axis
˙
Ym – Derivative of coordinate Y in Cartesian axis
˙φ – Derivative of approach angle of the robot
–
xiii

1.1 Project Background
CHAPTER 1
INTRODUCTION
ABU ROBOCON (Asia Broadcasting Union Robot-contest) is a robot
competition which is held by countries in Pacific Asia for undergraduate to participate
in yearly. The main objective of the contest is to exploit undergraduate’s talents and
to build up friendship among the undergraduates who are interested in robotic field.
In the year 2002, Malaysia had been invited to participate in ABU ROBOCON 2002
contest which is held in Japan for the first time. In the year 2003, Thailand had become
the host for ABU ROBOCON 2003, whereas Korea and China had been host for the
game in the year 2004 and year 2005 respectively. Malaysia had been host for ABU
ROBOCON 2006. In the year 2007, the game is held in Vietnam and after that the
game is held in India in the year 2008 before the year 2009 where Japan has once
again become host of the game. Egypt and Thailand had become the host of ABU
ROBOCON 2010 and 2011 respectively. In the year 2012, Hong Kong will be the host
of ABU ROBOCON 2012. Year after year, the game field design is becoming more
complicated in terms of line alignment and the intersections. This has made the game
becoming more challenging.

Figure 1.1: ABU Robocon 2006 Game Field Layout
In year 2006 as illustrated in Figure 1.1, the lines are alighted in a 90 degrees
cross with each other. The line following robot can easily detect the lines and the
intersection which we called it junction.
Figure 1.2: ABU Robocon 2007 Game Field Layout
2

As in year 2007 as shown in Figure 1.2, the game field design was changed.
The junction is not only 90 degrees; instead there are also some junctions which have
the junction with 120 degrees. This made the robot hard to differentiate whether it is a
junction or it is a noise.
Figure 1.3: ABU Robocon 2009 Game Field Layout
In year 2009 as shown in Figure 1.3, there are some sudden 90 degrees turning
lines made the line following robot even harder to implement in the game.
Figure 1.4: ABU Robocon 2012 Game Field Layout
Figure1.4 shows the game field layout of ROBOCON 2012. The game field is
designed with the combination of the properties from the previous year game field.
There are 90 degrees and 135 degrees lines intersection makes the line following
becoming more challenging.
3

1.2 Problem Statement
Figure 1.5: Basic function of line following sensor: (a) Both motors moving in same
speed (b) Left motor moves faster (c) Right motor moves faster
Previously in Universiti Teknologi Malaysia (UTM) Robocon Team, we use
Conventional Differential Driven Mobile Robot (CDDMR) to compete in the game.
The main sensor we use to do navigation for the mobile robot is line following sensor.
The basic function of a line following robot is as described in Figure1.5.
As shown in the Figure 1.5, line following robot’s performance is greatly
depends on line alignment and the cross section. If there is a task which requires a
robot to move in a place such that there is no line alight on it, a line following robot is
definitely inapplicable. In the sense that to optimize the navigation of a mobile robot,
the lines follow method has its limitation across the other navigation method such as
dead reckoning and odometry navigation due to it dependencies to the lines.
Figure 1.6: Comparison between CDDMR and ODMR
4

In terms of movement method, a CDDMR has its limitation. Firstly, a CDDMR
has an inflexible mobility. In the other words, it might require combination of few
movements in order to move from a specific location to another specific location.
As shown in Figure 1.6, in order to navigate to the desired position (1.0m, 1.5m), a
CDDMR need to make a straight movement for 1.5 meters, followed by a 90 degrees
turning and finally a straight line movement for 1 meter to reach the desired position.
As compared to an Omni Directional Mobile Robot (ODMR) which performs three
degree-of-freedom (DOF), a CDDMR move relatively longer distance than an ODMR
to reach the same destination. An ODMR can acheive both translation and rotation
movement simultaneously [2]. Lets say both robot can move with the same velocity,
the CDDMR will generally takes more times to navigate to a same location than an
ODMR.
Another disadvantage of CDDMR across ODMR is we cannot determine the
direction of heading of the robot after a specific movement. For a CDDMR, in order to
navigate to certain position, the direction from the robot itself towards the desired
destination must be aligning parallel with the robot tires. In the other words, the
direction of heading of the robot is also pointing to the direction of the destination.
This has caused some limitations to the robot as the movement of the robot might
not be able to perform with the other mechanism in the same time. In this context,
an ODMR offered a more flexible movement and user definable direction of heading;
both can be performed in the same time.
1.3 Objectives
(a) To develop an omnidirectional mobile robot for Robocon 2012.
(b) To develop navigation of an Omni-directional mobile robot using the feedback
of gyroscope and distance sensors.
1.4 Scopes of Project
(a) A multi purpose Omni-directional mobile robot base will be built.
(b) A platform which can be adapted to any kind of mechanism on it.
(c) Automatically navigate to a desired position on a pre-defined map with an end
desired direction of heading.
5

CHAPTER 2
LITERATURE REVIEW
In this chapter, some relevant works on omnidirectional mobile robot will be
discussed.
2.1 Implementation of Obstacle Avoidance and ZigBee Control Functions for
Omni Directional Mobile Robot
Figure 2.1: Omnidirectional Chassis and FPGA Development Board
The robot shown in Figure 2.1 is an omnidirectional mobile robot which can
perform obstacle avoiding. For the mechanical structure, the robot is basically built by
three DC motors with aligning 120 degree with each other. Besides, it has a ZigBee
wireless control function which built on a FPGA development board. The usage of the
FPGA is to achieve a real-time control and provide high speed with an acceptable error.
By using ultrasonic transducers which installed in front of the robot, the embedded
controller receives the obstacle distance signals and calculates the control signals to
drive the three omnidirectional wheels DC motors. [3]

2.2 Omnidirectional Mobile Home Care Robot
Figure 2.2: Experimental Omnidirectional Mobile Service Robot
Figure 2.2 shows Omnidirectional Mobile Home Care Robot designed by
National Chung-Hsing University. This project is to develop a robot which provides
home care for the disabled and improves their quality of life. The robot is basically
consists of a platform which can move in any direction, a robot arm which installed on
the top of the platform and a network camera which is installed on the front of the arm.
In the controller part, FPGA with Altera Nios II embedded processor is used to control
the system, motor position and speed of the robot. The reason why FPGA is used is to
ensure a better performance to control the motors. [4] [5]
7

2.3 Design and Control of an Omnidirectional Mobile Robot with Steerable
Omnidirectional Wheels
Figure 2.3: Omnidirectional Mobile Robot with Steerable Omnidirectional Wheels
This robot is developed by Mokpo National University, Korea as shown in
Figure 2.3. This robot can achieve 3 DOF motion on a 2-dimensional plane. As
compared to the other mobile robots which are equipped with two independent driving
wheels, the advantage of this robot is it can perform holonomic motion including
sideways motion. Besides, it can move in an arbitrary direction without changing
the direction of the wheels. [6]
8

2.4 Motion Control of an Omnidirectional Mobile Robot
Figure 2.4: Photo of robot inside working station
This is a robot which built as experimental purpose. In order to develop,
implement and test new algorithm and sensing technique, this robot is built as the
test bed which is designed to be very flexible and easy to program. This robot used
three omniwheels which are mounted at 120 degrees interval along the robots center
of gravity as shown in Figure 2.4. This arrangement ensures the wheels are always
contacted with the floor regardless of its roughness. [7]
Figure 2.5: Data flow of the system
9

Figure 2.6: Kinematics Equation of the robot
Figure 2.5 shows the data flow from the distance sensor (encoders) to the main
controller PC-104. After the signal been processed by the formulae programmed inside
the PC-104, a PWM output will pass to the PWM generator board to drive the motors.
Figure 2.6 is the kinematics equation of the robot. By using this formula, we can
calculate the speed required in order to move the robot to a desired location in x-y
coordinate plane.
10

2.5 The Omni-directional Wheelchair for The Elderly
Figure 2.7: Omnidirectional Wheelchair
The robot has three omnidirectional wheels which driven by a DC servomotor
respectively. The purpose of the project is to enable the disable person to move freely
in a small area. A joystick is used to control the movement of the robot provided ease
controlled by the user as illustrated in Figure 2.7. The robot is manually controlled by
the user and didn’t provide a closed loop control in the robot navigation. [8]
2.6 Motion Control of An Omnidirectional Mobile robot
In this article, the author has point out the advantages of omnidirectional mobile
robot. The robot has full mobility in the plane, which mean it can move in any direction
without changing of orientation. [9]
11

3.1 Project Flow
CHAPTER 3
METHODOLOGY
Figure 3.1: Project Flow
First of all, the project is starting with the idea inspiration. The idea is to
create a robot that solves the problem of navigation and to achieve faster yet simple
movement as compared to the Conventional Differential Driven Mobile Robot. After
some findings and research, the concept of project which is to do an Omnidirectional
Mobile Robot which can navigate to a desired location by using the feedback of
gyroscope and distance sensors was figured out. The project flow is developed as
shown in Figure 3.1 and the completion time for each stage is estimated by using
Gantt chart. Basically, development of the robot is divided into two parts, hardware
and software.

3.2 System Overview
Figure 3.2: Mechanical hardware top and bottom view
13

Figure 3.3: System OverView
As shown in Figure 3.2, the mechanical hardware is constructed. There are
three PD4266 DC motor aligning 120 degrees apart. [10] The APM gyroscope is placed
at the centre of the robot. At the bottom of the robot, the are two encoders aligning in
X and Y axis of the robot. Figure 3.3 shows the overall system.
14

3.2.1 Hardware
Figure 3.4: Solidworks Design
In the hardware part, there are two major components which are mechanical
structure and electrical controller circuit. The development is first started with the
design of mechanical structure. The software used is Solidworks. The purpose of
using this software is to roughly estimate the size of the robot and the materials to
build the robot. The 3D drawing view is shown in Figure 3.4. After getting the
right measurement about the size of the robot, the structure is built based on the
measurement.
15

Figure 3.5: Top View of the Robot
The mechanical structure is built as shown in Figure 3.5. The mechanical
structure is special designed to withstand a load up to 30kg on it. The material used to
build the structure is aluminium. There is a firm aluminium frame which designed to
hold the wheels. This allowed the weight of the robot to be acting on the frame.
Figure 3.6: Coupling between Motor and Omniwheel
The wheel is attached to the motor by a mechanical coupling in Figure 3.6.
The mechanical coupling acts as shock protection to the motor’s shaft. When there
16

is vibration on the wheel, the coupling will absorb the vibration before affecting the
motor’s shaft.
Figure 3.7: Bottom View of the Robot
Figure 3.8: Encoder Attachment
The next step is to attach the gyroscope and the distance sensors. For better
orientation sensing, the gyroscope is best placed at the center of the robot. The two
distance sensors are aligning in X and Y direction respectively as shown in Figure 3.7.
17

The attachment of the distance sensors is designed with a spring on the structure to
make sure the wheels of the distance sensors is always touching the ground as shown
in Figure 3.8.
Figure 3.9: Snapshot of NIsbRIO9632xt
For the electrical controller circuit design, NIsbRIO9632xt by National
Instrument (NI) is used as the main controller as shown in Figure 3.9. There are
few advantages upon using this board. Firstly, the board is built-in by an onboard
processor and a Field Programmable Gate Array (FPGA). The usage of the FPGA
provided high speed signal processing and fast computation time. This allowed the
real-time control and well navigation of the robot. Secondly, the board is programmed
using NI LabVIEW. The NI LabVIEW provides graphical programming which is
more simple and easy to learn. Besides, it also provided user friendly Graphical User
Interface (GUI) to the user for easy understanding and easy implementation. Thirdly,
the graphical programming is based on Data Flow Programming which allowed few
loops to be executed simultaneously. This allowed the parallel computation of the
formulae in navigation to be performed with more efficient.
18

Figure 3.10: Connector Board
Figure 3.11: MD10C H-bridge Motor Driver
The I/O pins from the main controller is connected to a pulled up circuit which
is also the power supply for the sensors. The pulled up circuit is shown in Figure 3.10
and it is also connected to the signal pins of MD10C H-bridge motor driver shown in
Figure 3.11.
19

3.2.2 Software
In the software part, software been used to program the NIsbRIO9632xt main
controller is NI LabVIEW. It is very powerful system design software built specifically
for tasks performed by engineers and scientists. The processor on NIsbRIO9632xt
board is a Freescale 32bits microprocessor. It is connected to the onboard FPGA via
Peripheral Component Interconnection (PCI). The FPGA provides free I/O for user to
customize it. In NI LabVIEW, the programming file is called Virtual Instrument (VI).
Figure 3.12: Clock Generator
In this project, there are two major VIs which are processor VI and FPGA VI.
The FPGA VI is design to interface the controller I/O with the environment change
which detected by sensors. In this VI, there are three components named clock pulses
generator, Quadrature Encoder Interface (QEI) and Pulse Width Modulation (PWM).
Inside the FPGA, a clock pulse generator is programmed to generate a 50 MHz clock
pulses which trigger the other peripherals such as QEI and PWM as shown in Figure
3.12.
20

Figure 3.13: QEI Functional Block Diagram
The QEI block is designed to interface with rotary encoders with are attached
on the robot. Figure 3.13 shown the design of the VI. In the design, there are six D
Flip-flop been used which are represented by the blocks labelled DFF in the figure.
The first four D Flip-flop is to avoid introducing of metastability into the QEI blocks.
Metastability is a condition where the output hovers in between logic ’0’ and logic
’1’. It happens due to the input changes too close to the clock edge which trigger the
flip-flop. Normally this happen in a fast system where the input is asynchronous with
the system clock or the system clock is too fast. The four DFF in the first column are
act as synchronizer. A synchronizer samples an asynchronous input and produces an
output that meets the setup and hold times required in a synchronous system. But yet,
the probability of failure can never be reduced to zero.
Figure 3.14: QEI pattern
21

By checking the input patterns from the inputs named QEA and QEB as shown
in Figure 3.14, we can know the direction of rotation of the encoder. Since it is in
grey code, some logics are applied to check the direction of rotation. If the sequences
of QEA and QEB inputs follow 00, 01, 11 and 10, we can conclude the encoder is
turning in clockwise direction and vice versa. If it is turning in clockwise direction,
the counter named POSCOUNT will increase and vice versa. There are total of five
QEI functional blocks been used, three for shaft encoders on the motors and another
two for external rotary encoders which aligned in X and Y direction of the robot.
Figure 3.15: PWM Functional Block Diagram
In order to drive the motors, PWM blocks is design to interface the main
controller with the H-bridge motor drivers. The design of the PWM block is shown in
Figure 3.15. Upon receiving the triggered clock pulses from the clock pulses generator,
the PWMCounter is increased by 1. The counter is then compared to a constant
value of 10000. If it is greater than 10000, it will reset to zero. By doing this, a
constant period of 0.2 millisecond which is equivalent of 5 kHz frequency is already
been created. Also, the counter is compared to a variable named PWM1. This is to
determine the duty cycle of the generated PWM pulses. For example, if 50 percents of
duty cycle is required, the user needs to set the value of 5000 into PWM1. Thus, when
22

the counter is less than PWM1, the PWM output pin is triggered ON while in the case
when the counter is greater than PWM1, the pin will triggered OFF. Hence, a simple
PWM blocks is created. In this project, three PWM blocks are used to control the three
actuators.
Figure 3.16: APM2.0 Ardupilot
Figure 3.17: MAX232 Schematics
In the processor VI, there few important steps need to be done. First step is
to interface the APM 2.0 Ardupilot to get the orientation of the robot by using serial
communication port. APM 2.0 Ardupilot as shown in Figure 3.16, is a complete set
of gyroscope, accelerometer and an ATMEGA microcontroller which acquires and
processes data from the sensors. The onboard microcontroller is programmed to
send out the digital yaw value after Kalman Filter with the accelerometer’s data via
Universal Asynchronous Receiver and Transmitter (UART). The connection circuit
from APM 2.0 Ardupilot to NIsbRIO9632xt serial communication port is shown in
Figure 3.17. The signal from APM is first been passed through a MAX232 to convert
23

the voltage level which is acceptable by the serial communication port.
Second step is to get the X and Y coordinate of the robot. By referring to the
QEI block’s counter value, the distance travelled by the robot can easily calculated by
the following equation.
Distance travelled in X = accumulatedpulsesofencoderinX
x(smallwheelradius)
pulsesperrevolution
2
The small wheel radius is referred to the small omniwheel which attached on
the rotary encoder.
3.18.
The third step is the navigation part based on the equation shown in Figure
Figure 3.18: Navigation Equation [1]
Θ1, ˙ Θ2
˙ and ˙ Θ3 are the angular speed of the three motors. R is the radius of the
Omni wheels. Ym, ˙ Xmand ˙ ˙ φ are the coordinate and the approach angle of the robot.
δ and L are angle of the tires from references axis and the distance from centre of the
robot to the centre of the wheel respectively.
In this case, user can define the desired X and Y coordinate and the approach
angle, φ of the robot. By comparing the actual coordinate and orientation with
the desired coordinate and orientation, the differences is then fed to the equation to
calculate the desired speed of the three motors respectively.
The next step is to calculate the actual speed feedback from the shaft encoders
by using the formula below:
Motor Spped1 = pulsesonshaftencoderin1milisec
x(motorwheelradius)
pulsesperrevolution
2
24

Finally, both the calculated actual speed and desired speed is fed into a PID
controller. The PID controller will output the PWM value which will later on been
feed to the PWM generator. The response of the PID controller can be adjusted by
tuning the PID gains. Hence, a closed loop speed controller is completed.
3.3 Gantt Chart
Figure 3.19: Gantt Chart for FYP1
Figure 3.20: Gantt Chart for FYP2
25

4.1 Results
CHAPTER 4
RESULTS AND DISCUSSION
Figure 4.1: QEI Graphical User Interface
This chapter will discuss on the results and functionality of the developed
omnidirectional mobile robot. In the previous chapter, the QEI and PWM block’s
designs are discussed. Figure 4.1 showed the Graphical User Interface (GUI) of the
QEI block. There are six QEI blocks been used and each has an indicator which
displays accumulated pulses. The system clock is indicated as Sys clk. The Ex-QEA,
Ex-QEB, QEA and QEB are representing the pin’s voltage level. The results were
obtained by testing the QEI to interface with an rotary encoder. Since the input pattern
is following grey code, there must be not any loses of pulse in order to accumulate the
pulses. The result shown 500 pulses times 4 which is equal to 2000 pulse per revolution
is obtained. Hence, we can conclude the reading is correct without any loses of pulse.

Figure 4.2: PWM Output
As for PWM block, the results are as showed in Figure 4.2. The first window
is the output of 10 percent duty cycle, followed by 50 percent duty cycle and lastly is
the output of 90 percent duty cycle. The graphs showed that, within a fixed period, the
PWM ON time is directly proportional to desired duty cycle sat.
27

Figure 4.3: Navigate in X-direction
Figure 4.4: Navigate in Y-direction
28

Figure 4.5: Navigate in XY-direction
For the navigation, the robot can travel to the correct desired coordinate
with correct desired orientation. There is error 10 percent of error due to the
mechanical structure is not perfectly made. Some input parameters such as robot
radius, omniwheels radius and distance from encoder’s wheel to centre of the robot
might differ from the actual mechanical structure. The result of the movement navigate
to X-direction, to Y-direction and to XY-direction is shown in Figure 4.3, 4.4 and 4.5
respectively.
4.2 Discussion
The robot can navigate in any direction and the movement is smooth as
compared to differential driven mobile robot. Hence, in the navigation to a same
desired location, the path and the time taken by this robot is generally shorter as
compared to differential driven mobile robot.
However, there are some disadvantages of this omnidirectional mobile robot.
Firstly, there are some offset of actual navigated location as compared to the desired
location. It is due to the mechanical structure is not made precisely. The motor speed
calculation is done based on the user defined parameters such as the robot radius, the
29

Omniwheel radius and etc. Since there are some offset of the real mechanical structure
and the keyed in parameters, the calculation has some small error causing the offset of
the navigated location and the actual desired location. Secondly, the PID parameters
are not been tuned to the prefect value for this robot. The response of the motor is still
not in a fine-tuned response. There are some overshoots of actual speed as compared
to desired speed.
30

CHAPTER 5
CONCLUSION
As conclusion, an omnidirectional mobile robot with navigation system is
developed. It use three motors with three internal encoders, two external encoders
and a gyroscope. NIsbRIO9632xt is used as the main controller of this robot. The
basic peripherals such as, QEI block is developed to interface with the rotary encoders.
By accumulating the pulses from the encoders, the distance travelled by the robot
and speed of the motor can be calculated. Besides, PWM block is also developed
to interface with the H-bridge motor driver (MC10C). The generated PWM pulses will
determine the amount of current which pass through the motor and hence control the
motor speed. The navigation formula is used to calculate the desired motor speed in a
particular location which is different from the desired location. It has been tested on
several routes which are to X-direction, Y-direction and XY-direction. It shows that
the robot can move smoothly to the desired location with desired orientation which its
error is less than ten percent. This robot can be used in Robocon 2012 competition
as either an autonomous robot or a manual controlled robot in order to achieve the
specific tasks in the game.
As for future improvement, the PID motor speed controller’s parameters should
be fine-tuned. The controller must have a fast response and less steady state error
so that the navigation of the robot can be done more smoothly. Since, the main
controller NIsbRIO9632xt required a connection to a PC or laptop via LAN cable,
there is limitation which is the robot cannot move too far away from the PC or laptop.
Hence, a router can be used to replace the LAN cable. The PC or laptop can connect
to the robot via WIFI and the robot can move as far as the coverage of the wireless
network. Also, the power supply can be replaced by DC battery. This allowed the
robot to move in any place without other power supply or plug.

REFERENCES
1. Ching-Chang Wong, Y.-H. L. S.-A. L. and Tsai, C.-H. GA-based Fuzzy
System Design in FPGA for an Omni-directional Mobile Robot. Journal of
Intelligient and Robotic Systems. 2005, vol. 44. 327–347.
2. Chuntao Leng, Q. C. and Huang, Y. A Motion Planning Method for
Omni-directional Mobile Robot Based on the Anisotropic Characteristic.
International Journal of Advanced Robotic System. 2008, vol. 5.
3. Kuo-Huang Lin, H.-S. L. and Chen, W.-T. Implementation of obstacle
avoidance and ZigBee control functions for omni directional mobile robot.
2008. 1–5.
4. Ching-Chih Tsai, H.-C. H. and Wang, T.-S. Omnidirectional Mobile Home
Care Robot. 2006.
5. Huang, H.-C. and Tsai, C.-C. FPGA Implementation of an Embedded Robust
Adaptive Controller for Autonomous Omnidirectional Mobile Platform. IEEE
Transactions On Industrial Electronics. IEEE. 2009, vol. 56.
6. Song, J.-B. and Byun, K.-S. Design and Control of an Omnidirectional Mobile
Robot with Steerable Omnidirectional Wheels. 2006, ISBN: 3-86611-284-X.
576.
7. Baede, T. A. Motion control of an omnidirectional mobile robot. Review
Literature And Arts Of The Americas. 2006. 21–23.
8. Han-Tai Fan, T.-L. L. and Chien, C.-H. The Omni-directional Wheelchair for
The Elderly.
9. Li, X. and Zell, A. Motion Control of An Omnidirectional Mobile Robot.
10. Yong Liu, R. L. W. I., J.Jim Zhu and Wu, J. Omni-directional mobile robot
controller based on trajectory linearization. Robotics and Autonomous Systems
56. 2008. 461–479.

A.1 Gantt Chart
APPENDIX A
APPENDIX A TITLE
Figure A.1: Gantt Chart for FYP1
Figure A.2: Gantt Chart for FYP2