Project_Report_Masters

AS S E M B L Y A N D P R O G R A M M I N G O F A L I N E
F O L L O W I N G A N D O B S T A C L E A V O I D I N G
A U T O N O M O U S R O B O T
Department of Instrumentation & Embedded Systems

Project Report: Master of Science, Embedded Electronic Systems (2012/2013) Page 2 of 78

TABLE OF CONTENTS
Page
ACKNOWLEDGEMENTS -------------------------------------------------------- 3
ACRONYMS AND OTHER TERMS---------------------------------------------- 4
1.0 OBJECTIVE AND EXECUTIVE SUMMARY -------------------------------- 5
1.1 OBJECTIVE --------------------------------------------------------------------------- 6
1.1.1 Components Used------------------------------------------------------------ 6
1.1.2 Preliminary Analysis Done -------------------------------------------------- 6
1.1.3 Technologies Applied-------------------------------------------------------- 7
1.2 EXECUTIVE SUMMARY-------------------------------------------------------------- 7
2.0 PROJECT PLAN AND EXECUTION ---------------------------------------- 8
2.1 PROJECT PLAN OVERVIEW AND CRITICAL ASSUMPTIONS ------------------ 9
2.2 ROLE REQUIREMENTS ------------------------------------------------------------- 9
2.3 PROJECT ORGANIZATIONAL CHART--------------------------------------------- 10
2.4 PROJECT SCHEDULE---------------------------------------------------------------- 11
2.4.1 The Initially Planned Schedule--------------------------------------------- 11
2.4.2 The Actually Implemented Schedule-------------------------------------- 12
2.4.3 Slip between the Planned and the Actual -------------------------------- 13
3.0 HRDWARE DEVELOPMENT------------------------------------------------ 14
3.1 LIST OF TOOLS AND MATERIALS UTILIZED------------------------------------ 15
3.1.1 Tools --------------------------------------------------------------------------- 15
3.1.2 Materials----------------------------------------------------------------------- 15
3.2 MODIFICATIONS DONE TO THE MSP LAUNCHPAD --------------------------- 16
4.0 SOFTWARE DEVELOPMENT----------------------------------------------- 18
4.1 OVERVIEW --------------------------------------------------------------------------- 19
4.2 THE LFOAAR PERIODIC I/O TASKS ---------------------------------------------- 20
4.2.1 Task A-------------------------------------------------------------------------- 21
4.2.2 Task B-------------------------------------------------------------------------- 22
5.0 CONCLUSION -------------------------------------------------------------- 26
5.1 APPLICATIONS----------------------------------------------------------------------- 27
5.2 REFERENCES ------------------------------------------------------------------------- 27
Annexure-I: SAM-BOARD USER MANUAL ----------------------------------- 28
Annexure-II: ASSEMBLY MANUAL FOR THE ROBOT ----------------------- 31
Annexure-III: SOURCE CODE OF THE LFOAAR SYSTEM ------------------- 48
Annexure-IV: EXTRACTS OF SOME PROJECT CORRESPONDENCES------- 70



ACKNOWLEDGEMENTS
We would like to express our gratitude and appreciation to all those who made it
possible for us to complete the masters program and this project. Our project
supervisor, Dr. Vincent VAUCHEY deserves special mention for his constant guidance
and technical advices that helped us complete the project successfully.
Many thanks goes also to our Chef de Département (Département
Instrumentation & Systèmes Embarqués) at ESIGELEC*, Professor Jean Jacques
DELARUE for his tutelage and support, not only during the course of executing this
project; but throughout the masters program as well.
We also gratefully acknowledge the crucial role of the staff of IRSEEM
(Embedded Electronic Systems Research Institute) at ESIGELEC, who willingly made
available to us all required tools and materials necessary for actualizing the project.
Finally, yet importantly, we express our heartfelt thanks to our beloved parents
for their blessings, and our friends & classmates for their assistances and good
wishes throughout.
*ESIGELEC
Technopôle du Madrillet
Avenue Galilée, BP10024
76801 Saint Etienne du Rouvray
FRANCE
Tel. : +33 (0)2 32 91 58 58
Fax : +33 (0)2 32 91 58 59
Website : www.esigelec.fr
Contact : esigelec@esigelec.fr



ACRONYMS AND OTHER TERMS
1 ADC Analog-to-Digital-Converter
2 DC Direct Current
3 ESIGELEC École Supérieure d'Ingénieurs
4 IDE Integrated Development Environment
5 IR Infra Red
6 IRSEEM Embedded Electronic Systems Research Institute
7 Launchpad Electronic Board of the MSP430G2553 MCU
8 LFOAAR Line Following and Obstacle Avoiding Autonomous Robot
9 MSEE Master en Sciences, Systèmes Electroniques Embarqués
10 MSP Mixed Signal Processor
11 PWM Pulse Width Modulation
12 RTOS Real Time Operating System
13 SAM-Board Electronic Board of the Robot’s Motors
14 TA1CCR0 Timer A1 Capture/compare Register, Channel 0
15 TA1CTL Timer A1 Control Register, Channel 0
16 TAIFG Timer A Interrupt Flag
17 TI Texas Instruments®
18 UART Universal Asynchronous Receiver Transmitter
19 UML Unified Modeling Language



Section 1.0
OBJECTIVE AND EXECUTIVE SUMMARY



1.0 OBJECTIVE AND EXECUTIVE SUMMARY
1.1 OBJECTIVE
To assemble the given robotic kit and program the Texas Instruments (TI)
microcontroller unit (MCU) MSPG2553 to make the robot follow a path as well as
avoid any obstacles placed on its path.
1.1.1 Components Used
1.1.1.1 Hardware materials
Table 1.1
Material Quantity
SAM-Board (designed for the MSP430G2452 MCU) 1
MSP430G2553 MCU 1
DC Motors 2
MSP430G2553 Evaluation Board (Launchpad) 1
Base Board to mount the robot (Chassis) 1
Infra Red (IR) sensors 2
Reflectance sensors 4
Wheels for the motors 2
Robotic Kit 1
1.1.1.2 Software compiler
IAR®
Workbench IDE version 5.5.1 for Texas Instruments®
MSP Devices.
1.1.2 Preliminary Analysis Done
a) Detailed study of the given SAM board (which was designed for the
MSP430G2452 MCU) to integrate it with the MSP430G2553 MCU
b) Thorough study of the MSP430G2553 MCU and its differences with the
MSP430G2452 MCU in terms pin configurations and functionalities.
c) Study of characteristics and features of the given motors.
d) Analysis of the IR sensors and the reflectance sensors.



1.1.3 Technologies Applied
All knowledge and technologies acquired throughout the course of the masters
program were applied. Their utilization was significant in successfully completing the
project. Some of these were particularly in the areas of Embedded C programming,
Architecture of Microprocessors, Real Time Operating Systems, Electromagnetic
Compatibility, Instrumentation & Control etc.
1.2 EXECUTIVE SUMMARY
The entire project was broken down into three different modules and the testing of
each module was initially performed individually before integrating them to perform
the final test.
a) Testing for obstacle avoidance
The MCU was initially programmed to make the robot detect obstacle on its path
of movement; and this was tested by placing obstacles at distances: 30 cm and
closer. Additionally, it was also programmed to successfully take drastic decisions
when boxed up in a corner: this is the condition when it senses that it is
approaching obstacles at both sides and in front, and cannot afford to move
neither forward nor sideways any longer.
b) Testing for line (or path) following
The robot was programmed in such a way that it moved forward only along the
path marked out with a black line (note that it can easily be adapted to move
along the path of any other colour apart from black). During testing the robot
was able to manoeuvre through both a gentle curve and a sharp curve.
c) Final test
The final test was performed by integrating both the line following and the
obstacle avoidance modules. To see these tests, refer the videos in the CD
accompanying this report.



Section 2.0
PROJECT PLAN AND EXECUTION



2.0 PROJECT PLAN AND EXECUTON
2.1 PROJECT PLAN OVERVIEW AND CRITICAL ASSUMPTIONS
The project plan was developed based upon certain key assumptions. Changes in
these assumptions impacted the project schedule and projected costs. These
assumptions were:
a) We had worked with the MSP430G2452 MCU and did not envisage the extent of
the compatibility issues using the MSP430G2553 MCU.
b) We relied on easy availability of the various sensors, and did not make adequate
preparations for spares.
c) We believed the timeline was reasonable enough.
d) We did not have to worry about the budget as all the components were readily
available and provided to us.
e) We planned on maintaining effective, adequate, and appropriate levels of
communication between our mentors and the project team during all phases of
the project.
f) All the technical details were provided to ensure common understanding,
flexibility, and adaptation to the project.
2.2 ROLE REQUIREMENTS
The following (Table 2.1) is a detailed breakdown of the roles assumed during the
execution of the project. It included the individual project roles and the
responsibilities of each role.
Table 2.1
Name Role Skills Required
Emmanuel
CHIDINMA
Project leader / Software
Lead
Experience, sense of responsibility
and effective communication
Erick
COVARRUBIAS
Hardware Lead / Software
Developer
Good hardware background and
experience
Ravi Raj
NARAYANA
Hardware scoping /
Software compatibility
Good understanding of
requirements, sound judgment
Sagarika
MUKESH
Project Planner / Software
Developer
Good planning and communication
skills, understanding of the project
Tamilkavitha
VAITHIANATHAN
Software Developer /
Hardware Compatibility
Keen interest in programming and
knowledge of the hardware
Ishan CHUGH Hardware / Software
Development
Good knowledge and understanding
of the overall project

Project Re
2.3 P
The proj
under th

Depa
port: Master o
PROJECT O
ject team fo
he guidance
A
rtment of
of Science, Emb
ORGANIZA
ollowed a p
e of the two
AS S E M B L
F O L L O W
Instrumen
bedded Electro
ATIONAL C
parallel wor
o mentors.
L Y A N D P
W I N G A N D
A U T O N O
ntation & E
onic Systems (2
CHART
rk structure
This can be
R O G R A M
D O B S T A C
O M O U S R
Embedded
2012/2013)
e where eve
e seen in th
M I N G O F
C L E A V O I
O B O T
d Systems
eryone work
he chart of
A L I N E
I D I N G
Page 10 of 7
ked togethe
Figure 2.1.
78
er
.



2.4 PROJECT SCHEDULE
2.4.1 The Initially Planned Schedule



2.4.2 The Actually Implemented Schedule



2.4.3 Slip between the Planned and the Actual
The project was initially planned to end by 31/01/13. However, it ended on
15/02/13: a slip of about 2 weeks.
The final two weeks (17/01/13 to 31/01/13) took us unawares because we wrote
five examinations within this period; a period that was completely vacant when the
project commenced: consequently the project was completed later than the
scheduled time.
Secondly, while test running the robot, we discovered that reflective sensors had
become defective. It took another three days to procure new sensors: another delay.



Section 3.0
HARDWARE DEVELOPMENT

Project Re
3.0 H
3.1 L
3.1.1 T
a) 1 Mic
b) 1 Co
insta
c) 1 Dig
d) 1 Sol
e) 1 De
f) 1 kit
g) 1 Scr
screw
h) 1 Too
3.1.2 M
a) 1 SA
b) 1 MS
c) 1 Mic
d) 2 IR
e) 4 Ref
f) Sets
g) 1 Fix
h) 2 Me
i) 1 Ch
j) 2 DC
k) 2 Mo
l) 1 3.5
3.1.3 S
a) The
mode

1ReferAn
2ReferAn

Depa
port: Master o
HARDWA
LIST OF TO
Tools
cro USB wir
mputer wit
lled
gital Multim
ldering iron
esoldering p
of wire cut
rewdriver a
wdriver
olbox for st
Materials
M Board1
SP 430 Laun
cro-controll
Sensors: S
flectance S
of connect
xation kit (s
eters of wire
assis const
C motors
otor covers
5 v Battery
Steps for A
idler whee
erately tigh

nnexure-Itose
nnexure-IItos
A
rtment of
of Science, Emb

Fi
in
pl
ARE DEVE
OOLS AND
re
th IAR Deve
meter
n
pump
tters and pl
and small Am
torage
nchpad
er MSP430
harp®
GP2
ensors: Pol
ors (for ext
crews, tape
e
ituting the
Assembling
el was ins
ht.

eetheSAM-B
seetheAssem
AS S E M B L
F O L L O W
Instrumen
bedded Electro
igure 3.3:
nstalled in t
latform
ELOPMEN
D MATERIA
elopment ki
liers
merican
G2553
D120
lolu®
Corpo
tensions to
es, etc)
robot
g the Robo
stalled und
oardUserMa
mblyManualfo
L Y A N D P
W I N G A N D
A U T O N O
ntation & E
onic Systems (2
Idler whee
he chassis
NT
ALS UTILIZ
it
oration QTR
the MSP La
ot 2
der the cha
anual
ortheRobot
R O G R A M
D O B S T A C
O M O U S R
Embedded
2012/2013)
el
ZED
R-8A
aunchpad)
assis with
M I N G O F
C L E A V O I
O B O T
d Systems
the screw
A L I N E
I D I N G
Page 15 of 7
ws and nut
78
ts

Project Re
b) The
c) The
to th
cons
d) The s
e) The c
3.2 M
When w
compati
with the
The pins
not mat
wires (F
of the L
shown in

Depa
port: Master o
two wheel
motors and
he chassis
erve the pa
sensors we
connections
MODIFICA
we tried usi
bility probl
e MSP430G2
s for the ti
tch: this wa
Figure 3.5),
Launchpad
n Table 3.1
A
rtment of
of Science, Emb
s were fixe
d wheels w
using the
arallelism of
ere attached
s to the MC
ATIONS DO
ing the SAM
ems becau
2452 MCU.
mer chann
as the main
we were a
to the SAM
1.
AS S E M B L
F O L L O W
Instrumen
bedded Electro
ed to their r
were attache
motors cov
f both whee
d to the pro
CU were do
ONE TO TH
M-board w
use the SA
els of the
n source o
able to ove
M-board as
L Y A N D P
W I N G A N D
A U T O N O
ntation & E
onic Systems (2
respective m
ed to the S
ver bolts an
els.
ovided supp
ne as show
HE MSP LA
ith the MSP
M-Board w
MSP430G25
f the probl
ercome this
s required.
R O G R A M
D O B S T A C
O M O U S R
Embedded
2012/2013)
motors.
SAM-board,
nd nuts pr
ports on the
wn in Table
AUNCHPAD
P430G2553
was designe
553 and M
lem. Howev
problem b
And the re
M I N G O F
C L E A V O I
O B O T
d Systems
Figure3.
madetot
and at the
ovided ma
e chassis.
4.1.
D
3 MCU, we
ed actually
SP430G245
ver, with s
by connecti
esult was t
A L I N E
I D I N G
Page 16 of 7
.5:Modification
theLaunchpad
e same time
king sure t
faced som
to be use
52 MCUs d
some jumpe
ng the port
tabulated a
78
ns
pins
e,
to
me
ed
id
er
ts
as



Table 3.1
LaunchPad
Pins
Function Type
P 1.0 ADC10 IR-sensor Left Input
P1.1 UART Rx Input
P1.2 UART Tx Output
P1.3 Line detection (reflectance) Back-Left Sensor Input
P1.4 Line detection (reflectance) Front-Left Sensor Input
P1.5 Line detection (reflectance) Front-Right Sensor Input
P1.6 Line detection (reflectance) Back-Right Sensor Input
P1.7 ADC10 IR-sensor Right Input
P 2.0 Timer A1 Channel 0 Unused
P 2.1
PWM motor A ( SAM-board marked as pin 1.2):
Timer A1 Channel 1 for the left wheel
Output
P 2.2
H Bridge Control Motor B: determines direction
of rotation of right wheel
Output
P 2.3 Optocoupler A Input
P 2.4 Optocoupler B Input
P 2.5
PWM motor B ( Sam-board marked as pin 1.4):
Timer A1 Channel 2 for the right wheel
Output
P 2.6
H Bridge Control Motor A ( Sam-board marked
as pin 2.1): determines direction of rotation of
left wheel
Output



Section 4.0
SOFTWARE DEVELOPMENT

Project Re
4.0 S
4.1 O
This sec
Avoiding
Modeling
The LFO
are ofte
input ev
rates th
constrain
The LFO
that mu
case wa

Depa
port: Master o
SOFTWAR
OVERVIEW
ction descr
g Autonom
g Language
OAAR is a r
n complex
vents and p
hat are of
nts specifie
OAAR was a
st be met
s the crash
A
rtment of
of Science, Emb
RE DEVE
W
ibes the so
mous Robot
e) notation
real-time sy
because th
produce mu
ften unpre
ed in the sy
a hard real-
to prevent
hing of the r
AS S E M B L
F O L L O W
Instrumen
bedded Electro
LOPMEN
oftware mo
t (LFOAAR)
is utilized.
ystem (Figu
hey have to
ultiple inde
dictable, a
stem requir
-time system
a catastro
robot.
L Y A N D P
W I N G A N D
A U T O N O
ntation & E
onic Systems (2
NT
odeling for
). Through
ure 4.1). A
o deal with
ependent ou
although th
rements.
m because
ophic system
R O G R A M
D O B S T A C
O M O U S R
Embedded
2012/2013)
the Line F
hout, the s
As an overv
h multiple in
utputs. The
hey must
there were
m failure. T
M I N G O F
C L E A V O I
O B O T
d Systems
Following a
software U
view, real-t
ndependen
ese events
be subjec
e time-critic
The catastr
A L I N E
I D I N G
Page 19 of 7
and Obstac
UML (Unifie
ime system
t streams o
have arriv
ct to timin
cal deadline
rophe in th
78
le
ed
ms
of
al
ng
es
is



The LFOAAR real-time system had just two tasks: One task measuring the distances,
and the other sensing line colour. As these two tasks were mutually exclusive, this
real-time system was not a concurrent system that employed multiple threads of
execution: it was purely a sequential system using just one thread of execution. It
was a foreground/background system with a super loop. As a result, the use of an
RTOS (Real Time Operating System) was not necessary. The textual pseudo code
modeling of the LFOAAR system is shown in Listing 4.1.
Listing 4.1: Pseudo Code for the LFOAAR System
while start with the periodic slow clock mode do
Take the IR sensor measurement to obtain distance
if distance at both sides of the robot are less than 30 cm // Task A for obstacle avoidance
if distance at the right is greater than that at the left // Ai)
Steer robot to the right // end Ai)
else if distance at the left is greater than that at the right // Aii)
Steer robot to the left // end Aii)
else // distances at both sides are equal and less than 30 cm: Aiii)
Move the robot backwards until it senses enough space to steer to any side // end Aiii)
end if; // end either Ai or Aii or Aiii)
else distance at both sides of the robot are more than 30 cm // Task B for line detection
Stop the slow clock mode and start the fast clock mode // B1
Take line sensor measurement to obtain colour value // B2
Check whether it is time to stop the fast clock and restart the slow clock mode // B3
if Consider the situations where all 4 sensors are necessary to regulate movement // B4i
Use all 4 line sensors to regulate movement such that robot moves along the line/
else if In the situation where all 4 sensors are not sensing the line // B4ii
Move robot forward at a slower speed to hit the nearest line // end B4ii
else if In the situations where just the 2 front sensors should regulate movement // B4iii
Use just the 2 front line sensors to regulate movement // end B4iii
else//situation when the back line sensors are on the line and the front ones are not: Biv)
Perform random movements to position robot on the path // end Biv)
end if; // end either Bi or Bii or Biii or Biv)
end if; // end either A or B)
end while;
4.2 THE LFOAAR PERIODIC I/O TASKS
The two LFOAAR system tasks – Task A and Task B – were not configured to be
event (or interrupt) driven I/O tasks because interrupts were not enabled in the
application. Instead, they were configured as periodic I/O tasks. Because these two
tasks were mutually exclusive, there was no need for an RTOS; thus, the two tasks
were handled in a single if-else statement.
As an overview, unlike an event driven I/O task, which deals with an event driven
I/O device, a periodic I/O task deals with a passive I/O device, where the device is

Project Re
polled o
its func
perform
the time
For the
(IR) and
MSPG25
TA1CTL
tasks sca
4.2.1 T
The rob
distance
The LFO
obstacle
voltages
GP2D12
(Analog-
transfer
dependi
actuator
distance
go.

Depa
port: Master o
on a regular
tion is I/O
s an I/O ac
e between s
LFOAAR sy
d four refle
553 MCU, a
register) e
anned the s
Task A
bot commen
e value is le
OAAR syste
e. Two IR
s as a func
0 Infra Red
-to-Digital-C
function.
ng on the
rs) controlli
es measured
A
rtment of
of Science, Emb
r basis. In
O-related. T
ction, and t
successive a
stem, the p
ctance (line
and the tim
each time t
sensors and
nced obsta
ess than 30
em task A
(left and r
ction of th
d Sensor. T
Converter)
Thereafter
e distances
ing the (lef
d: this was
AS S E M B L
F O L L O W
Instrumen
bedded Electro
this situatio
The period
then waits f
activations.
passive I/O
e) sensors.
mer event w
the timer c
d read their
acle avoidan
cm.
obtained t
right) sens
he distance
These volta
outputted v
r, task A
s measured
ft and right
how the ro
L Y A N D P
W I N G A N D
A U T O N O
ntation & E
onic Systems (2
on, the act
dic task is
for the nex
.
devices we
The timer
was the se
ounts up t
r values.
nce when
the distanc
sors placed
s measure
ages served
values wer
must ena
d. The d
t) wheels o
obot made
R O G R A M
D O B S T A C
O M O U S R
Embedded
2012/2013)
tivation of t
activated
xt timer eve
ere the six
r utilized wa
ettings of t
o the TA1C
it decipher
ces of the
in front o
d. Each IR
d as inputs
e mapped
ble the ro
direction of
of the robo
its decision
M I N G O F
C L E A V O I
O B O T
d Systems
the task is
by a time
ent. The tas
sensors – t
as the Tim
the TAIFG
CCR0 value
red that an
robot from
of the robo
R senor wa
to ADCs, a
to distance
obot make
f the DC
ot were affe
ns on which
A L I N E
I D I N G
Page 21 of 7
periodic bu
er event.
sk’s period
two infra-re
er A1 of th
flag (of th
e. These tw
ny measure
m its neares
ot outputte
as a Sharp
and the AD
e values by
a decisio
motors (th
ected by th
h direction t
78
ut
It
is
ed
he
he
wo
ed
st
ed
p®
DC
a
on
he
he
to



Immediately after the ADC outputs were ready, the Distance Sensor Interface
function was called. This function was the hardware/software boundary (refer Figure
4.2) for task A. The signature of the function is: float calculate_distance().
This function enabled the ADC outputs to be mapped to distance values. The
dist_left and dist_right were float variables representing the distances of left
and right IR sensors respectively from an obstacle.
What was it that determined the period of activation of task A?: the IR sensors’
reaction time placed the constraint and determined the threshold for this periodic
time. For a particular distance from an obstacle, It took approximately 55 ms for
each IR sensor to output a corresponding voltage value; and subsequently, a time of
308 µs (ADC sample and conversion time) for the ADCs to output their values. Thus,
with task A configured to scan each of the two IR sensors every other periodic time,
a period of 30 ms ensured that each of IR sensor was scanned every 60 ms. This
time also included the ADC sample and conversion time.
Task A was further subdivided in to three mutually exclusive scenarios:
a) Case Ai: distance at the right is greater than that at the left, in which case the
robot steers right.
b) Case Aii: distance at the left is greater than that at the right, in which case
the robot steers left.
c) Case Aiii: distance at both sides were equal (and less than 30 cm); in which
case the robot must move backwards until it sensed enough space to steer to
any side.
4.2.2 Task B
It should be noted that during obstacle avoidance, that line (or path) following ability
of the robot was suppressed. However, after successfully avoiding an obstacle, the
robot must then proceed to the nearest black line path to continue the “path
following.” Thus, program execution was passed to task B.
The LFOAAR system task B obtained the colour under the surface on which the robot
moved. This system was programmed to run on a black line (or path): therefore,
there were only two colours: black colour and “other colours.” There were four
reflectance sensors. Each reflectance sensor was a Pololu®
Corporation QTR-8A
reflectance Sensor. The reflectance sensors were also called line sensors in the
context of the application. There were four of them mounted underneath the robot:

Project Re
two (left
at the b
the sens
were ma
the robo
direction
affected
remain o
Immedia
was call
task B.
function
colour
colour
front rig
values w
‘seen.’
The refle
activatio
output a
sample a
configur
of 1 ms
included
clock tha

Depa
port: Master o
t and right)
back. These
sors. Thes
apped to co
ot make a d
n of the DC
by the co
on its (blac
ately after t
ed. This fu
The signa
enabled
r_front_r
r_back_le
ht, front le
were ‘0’ w
ectance sen
on of task
a correspon
and conver
red to scan
s ensured t
d the ADC s
an task A.
A
rtment of
of Science, Emb
) sensors p
e sensors ou
se voltages
olour values
decision de
C motors co
olour meas
k colour) pa
the ADC ou
nction was
ature of t
the ADC
right, c
eft were b
ft, back rig
when a black
nsors’ react
B. It took
nding volta
rsion time)
each of th
hat each o
sample and
A periodic
AS S E M B L
F O L L O W
Instrumen
bedded Electro
placed in fro
utputted vo
served as
s by a trans
epending on
ontrolling th
sured: this
ath.
utputs were
the hardw
he function
C outputs
colour_fr
bool varia
ht and bac
k colour wa
tion time e
k approxima
age value;
for the AD
e four refle
of line sens
d conversion
time of 1
L Y A N D P
W I N G A N D
A U T O N O
ntation & E
onic Systems (2
ont and the
oltages as a
inputs to A
sfer functio
n the colou
he (left and
was how
e ready, the
ware/softwa
n is: bool
to be m
ront_left
bles repres
k left reflec
as ‘seen’ an
nsured the
ately 10 µ
and subse
DCs to outp
ectance sen
sor was sca
n time. Thu
ms is obvio
R O G R A M
D O B S T A C
O M O U S R
Embedded
2012/2013)
e other two
a function o
ADCs, and
on. Thereaft
ur measured
d right) wh
the robot
e Colour Se
re boundar
l calcul
mapped to
t, colour
senting the
ctance sens
nd ‘1’ whe
threshold
s for each
equently, a
put their va
nsors every
anned every
us, task B o
ously so ma
M I N G O F
C L E A V O I
O B O T
d Systems
o (left and r
of the colou
the ADC o
ter, task B
d. Both th
heels of the
made its
ensor Interf
ry (refer Fig
late_colo
o colour v
r_back_r
e colours “s
sors respect
en any othe
for the per
reflectanc
time of 3
lues. Thus,
fourth peri
y 4 ms. Th
operated un
any times g
A L I N E
I D I N G
Page 23 of 7
right) place
ur “seen” b
utput value
must enab
e speed an
e robot wer
decisions t
face functio
gure 4.3) fo
our(). Th
values. Th
ight an
seen” by th
tively. Thes
er colour wa
iodic time o
ce sensor t
308 µs (AD
, with task
iod, a perio
his time als
nder a faste
greater tha
78
ed
by
es
le
nd
re
to
on
or
is
he
nd
he
se
as
of
to
DC
B
od
so
er
an



the sensor reaction time of 10 µs. However, the large disparity was necessary to
ensure there was enough time for the wheel speeds and direction to update to their
new values accordingly.
As soon as program control is passed to task B, each of the four reflectance sensors
are scanned seven times in succession – a total of 28 ms; after which the clock is
switched back to the slow mode and program control transferred back to task A.
Task B was further subdivided under four mutually exclusive scenarios:
a) Case B4i: situation in which all four reflectance sensors partook in regulating
the movement of the robot.
b) Case B4ii: situation in which none of the four sensors were sensing black
colour. In this scenario, the robot was completely off the line.
c) Case B4iii: situation in which only the two front reflectance sensors partook in
regulating the movement of the robot.
d) Case B4iv: situation in which the two back reflectance sensors were sensing
black colour and the two front reflectance sensors were sensing other colours.
In this case the robot makes some random movement to reposition itself on
the line.
These various scenarios are detailed in Table 4.1.
Labels:
colour_front_right = W
colour_front_left = X
colour_back_right = Y
colour_back_left = Z
Scenario = P
Table 4.1
W X Y Z
Action by robot, control techniques by line
sensors
P
01 0 0 0 0 Move forward, all 4 sensors participate in the control B4i
06 0 1 0 1
Move forward, only the 2 front sensors participate in the
control. It is not necessary to use all 4 because the front pair
and back pair values are just the same
B4iii



W X Y Z
Action by robot, control techniques by line
sensors
P
07 0 1 1 0
control. All 4 cannot be used because the front pair and back
pair values cancel out each other. Yet a change in position is
necessary to re-position the robot accordingly
B4iii
08 0 1 1 1
control. Here 3 sensors are offline. If all 4 participate, the
robot might be steered more than necessary.
B4iii
10 1 0 0 1
control. All 4 cannot be used because the front pair and back
pair values cancel out each other. Yet a change in position is
necessary to re-position the robot accordingly
B4iii
11 1 0 1 0
control. It is not necessary to use all 4 because the front pair
and back pair values are just the same
B4iii
12 1 0 1 1
control. Here 3 sensors are offline. If all 4 participate, the
robot might be steered more that necessary.
B4iii
13 1 1 0 0
The rear part of the robot is on the line but the robot is
facing a direction approximately perpendicular to the path.
Therefore, it must perform random movements to reposition
itself accordingly.
B4iv
16 1 1 1 1
The robot is completely offline; most probably it has just
completed an obstacle avoidance session. Here, it must move
forward slowly to the nearest black line in order to join back
the path.
B4ii
Annexure-III depicts the source code of the LFOAAR system.



Section 5.0
CONCLUSION



5.0 CONCLUSION
This project implemented the working of a robot, the objective of which was to
follow a colour path and avoid all the obstacles en route. We write this report after
the successful completion of the project. The project centered on the use of the
MSP430G2553 MCU with two kinds of sensors:
a) Infrared Sensor: This sensor was used to accomplish the goal of avoiding
obstacles on the route of the robot. Two IR sensors were used, which enabled
the robot take the necessary decisions to avoid obstacles.
b) Reflectance Sensor: This sensor was enabled the robot follow the path for which
it was programmed. The sensor had different output voltages for different
colours.
The Hardware of the project was developed on the SAM board, used for interfacing
motors and sensors with the MCU. The programming language used was Embedded
C and the debugging and compilation was done using IAR systems IDE.
5.1 APPLICATIONS
a) In Future this project can be slightly modified for the robot to be employed in
sewers for cleaning the tunnels where people cannot enter.
b) The project can be adapted to be used in factory automation.
c) The project can be adapted to be used in automated vehicles that carry heavy
loads.
d) The robot can be used in conveyor systems.
5.2 REFERENCES
• The Texas Instruments®
Datasheet for the MSP430G2553 MCU.
• The Pololu®
Corporation QTR-8A reflectance Sensor Datasheet.
• The Sharp®
GP2D120 Infra Red Sensor Datasheet.



Annexure-I
SAM-BOARD USER MANUAL

SAM Board – Manuel de l'utilisateur
Présentation
La carte « SAM Board » est prévue pour être montée sur le châssis Pololu rrc04a, elle accueille en mezzanine une carte
Launchpad permettant ainsi la réalisation d'un petit robot mobile. Elle permet la gestion d'alimentation (gestion de la
batterie, conversion des tensions) ; le contrôle de deux moteurs DC et comporte deux opto-coupleurs permettant
d'estimer la vitesse de rotation des roues.
Ce manuel décrit l'utilisation, la configuration et la mise en œuvre de cette carte.
Fonctionnalités
• Gestion (charge et supervision) d'une batterie Lithium-Polymère 3.7V
• Gestion de l'alimentation (production de deux tensions : 5V et 3.3V)
• Interface de puissance pour deux moteurs DC
• Deux codeurs incrémentaux optiques pour la détection de la vitesse de rotation des roues
• Connecteurs femelles permettant l’insertion d'une carte LaunchPad
• Connecteurs femelles permettant l'alimentation et la connexion de périphériques (capteurs, actionneurs)
Configuration
Jumper Description Configuration par défaut
JP1 Limitation du courant
consommé sur le port USB
Présent : 500 mA Absent: 100 mA
JP2 Mode de commande des
moteurs (cf datasheet)
1-2 : Phase / Enable 2-3 : IN / IN
JP3 Tension d'alimentation des
moteurs
1-2 : Vbat (env. 3.7V) 2-3 : 5V
JP4 Codeurs incrémentaux (opto-
coupleurs)
Présent: codeurs actifs ; D3 et
D4 indiquent l'état
Absent : codeurs inactifs ; D3 et D4
contrôlés par Launchpad
Illustration 1: SAM board - vue d'ensemble

Connecteurs
K1 : Connecteur 3 points 2.54mm pour batterie Lithium-Polymère 3.7V équipée d'une NTC interne.
K2 : Connecteur 2 points 2mm pour batterie Lithium-Polymère 3.7V non équipée d'une NTC. Localisé sous K1 qu'il
est nécessaire de dessouder.
J1 : connecteur mini-USB type B. Alimentation du système (5V) et charge de la batterie
P1, P3 : connecteurs pour enficher une carte Launchpad. Le brochage des différentes fonctions connectées à la carte
Launchpad sont indiqués dans le tableau ci-dessous,
Launchpad Fonction (configuration par défaut)
P 1.2 (TA 0.1) PWM pour le moteur A, 250 KHz maximum
P 1.4 (TA 0.2) PWM pour le moteur B, 250 KHz maximum
P 2.1 Sens pour le moteur A
P 2.2 Sens pour le moteur B
P 2.3 Opto-coupleur roue A
P 2.4 Opto-coupleur roue B
P2 : Connecteur fournissant l'alimentation pour les périphériques (capteurs, actionneurs)
P2: Broche n° Fonction
1, 2, 3 5V
4, 5, 6, 7 GND
8, 9, 10 3.3V
P4 : Connecteur fournissant quelques signaux de la Launchpad, ainsi qu'une alimentation 3.3V.
Le brochage est compatible avec les afficheurs 4x7 segments sparkfun qui peuvent donc être enfichés
directement.
P4 : Broche n° Pin Launchpad Fonction afficheur Sparkfun
1 P 1.1 RX
2 P 2.0 CS
3 P 1.6 SI
4 P 1.3 RST
5 P 1.5 SCK
6 P 1.7 SO
7 / 3.3V
8 / GND
Indicateurs
D1 Vert : indique qu'une source d'alimentation adéquate est connectée sur J1 (port Mini-USB)
Orange : indique que la batterie est en charge
D2, D3 : indiquent le fonctionnement et le sens de rotation des moteurs
D4, D5 : indiquent l'état des opto-coupleurs. Si JP4 est retiré, peuvent être utilisés comme indicateurs par la carte
Launchpad
D6 : Indique la mise sous tension du système



Annexure-II
ASSEMBLY MANUAL FOR THE ROBOT

Notice de montage du robot aspirateur.
APP Systèmes Numériques à Microprocesseurs.
Département Instrumentation & Systèmes Embarqués. ESIGELEC 2012 (C). Page 1
Robot Aspirateur
(Notice de Montage)
R. ROSSI & R. KHEMMAR. ESIGELEC. 11/2012
Cette notice de montage a comme vocation de vous guider dans le montage de votre robot. Il
est commode de respecter la chronologie des étapes indiquées afin d’avoir un robot
opérationnel.

TABLE DES MATIERES
PAGE
1. INVENTAIRE DU MATERIEL A UTILISER.........................................................................................3
1.1. Caisse à outils........................................................................................................... 3
1.2. Composants et Eléments du robot....................................................................... 4
2. PROCEDURE D’ASSEMBLAGE DU ROBOT ASPIRATEUR ...................................................................6
2.1. Déballage du châssis.............................................................................................. 6
2.2. Assemblage de la roue folle.................................................................................. 6
2.3. Assemblage Roues-Moteurs .................................................................................. 8
2.4. Assemblage carte-moteurs sur le châssis ..........................................................10
2.5. Soudure des moteurs à la carte-moteurs ..........................................................13
2.6. Installation de la batterie .....................................................................................14
2.7. Installation de la carte launchpad & l’afficheur..............................................16

1. INVENTAIRE DU MATERIEL A UTILISER
1.1. CAISSE A OUTILS
Vous disposez d’une caisse à outils vous permettant d’assembler votre robot
et d’assurer les différentes modifications nécessaires.
Le tableau 1 comprend la liste des outils fournis :
N° Désignation
1 Multimètres
2 Fer à souder et Pompe à dessouder
3 Pince coupante et pince plate
4 Tournevis plat et petit tournevis américain
5 Caisse à outils pour le rangement
6 Sacoche
Tableau 1. Liste des outils.
La figure 1 illustre l’ensemble des outils fournis :
Figure 1. Vue d’ensemble des outils.

La figure 2 illustre la caisse avec les outils et la sacoche :
Figure 2. Vue d’ensemble sur la caisse à outils et la sacoche.
1.2. COMPOSANTS ET ELEMENTS DU ROBOT
Le tableau 2 comprend la liste des éléments et composants nécessaires à
l’assemblage du robot :
N° Désignation
1 Châssis
2 2 x Moteurs DC
3 2 x Caches moteurs
4 2 x Roues motrices et 1 x Roue folle
5 Carte Launchpad MSP430
6 Carte Moteur et afficheur
7 Batterie et pastille adhésive pour fixation
Tableau 2. Liste des éléments constituants le robot.

La figure 3 illustre l’ensemble de ces éléments :
(a) (b)
(c) (d)
Figure 3. Vue d’ensemble des éléments du robot.
Caches
moteurs (d)
Moteurs
(a)
Châssis
Carte
MSP430
2 roues
(b)
Roue folle
(c)
Carte
moteur
Batterie

2. PROCEDURE D’ASSEMBLAGE DU ROBOT ASPIRATEUR
Afin de bien assembler le robot, il est indispensable de respecter toutes les
étapes mentionnées ci-dessous.
2.1. DEBALLAGE DU CHASSIS
Retirer le papier de protection des deux faces du châssis. Aidez-vous du
tournevis plat pour décoller un bord comme le montre la figure 4 :
Figure 4. Retrait du film de protection du châssis.
2.2. ASSEMBLAGE DE LA ROUE FOLLE
Enlever le papier de protection de chaque côté de la petite entretoise
comme le montre la figure 5 :
Point de
retrait

Figure 5. Préparation de la roue folle.
Assembler la roue folle sous le châssis avec la vis et les écrous fournis en
serrant modérément comme le montre la figure 6 :
Figure 6. Assemblage de la roue folle sous le châssis.
Roue folle

Faire attention au sens : la bille est sous le châssis, à l’arrière du robot (comme
le montre la figure 7) :
Figure 7. Roue folle installée sur le châssis.
2.3. ASSEMBLAGE ROUES-MOTEURS
Emboiter les roues sur l’axe des motoréducteurs :
 Enlever le pneu de la roue
 Placer la roue sur une table, côté denté vers le haut
 Enfoncer l’axe du motoréducteur en appuyant bien droit
La figure 8 illustre ces différentes étapes :
Avant
du robot
Arrière
du robot

Figure 8. Roue montée sur l’axe du moteur.
L’extrémité de l’axe doit bien affleurer la surface de la roue (figure 9) :
 Vérifier que la roue tourne facilement en entrainant le moteur (si le
moteur semble bloqué, il faut appeler le tuteur)
 Replacer les pneus sur les roues
Figure 9. Les deux roues assemblées aux moteurs.
L’axe du
moteur

2.4. ASSEMBLAGE CARTE-MOTEURS SUR LE CHASSIS
Déballer les caches moteurs et la visserie associée (Figure 10) :
Figure 10. Caches moteurs et visserie associée.
Positionner les caches sur les moteurs-réducteurs (figure 11) :
 Vérifier le positionnement correct des caches
Figure 11. Positionnement des caches sur les moteurs.
Caches
moteurs
Moteur et réducteur
englobés dans le cache
Côté denté
vers l’intérieur

Positionner les moteurs et leurs caches sur la carte électronique (carte
moteur) comme le montre la figure 12 :
 Attention au sens des moteurs. Les pattes marquées par un plus (+) vont
vers l’avant du robot.
Figure 12. Montage moteurs + caches sur la carte moteurs.
Pate moteur
marquée d’un +
L’avant du robot

Positionner l’ensemble (carte + moteurs) sur le châssis (figure 13) :
 Placer les écrous dans les logements sur le dessus des caches moteurs
 Vissez par le dessous dans les trous appropriés
 Serrez modérément en vous aidant du tournevis
Figure 13. Fixation de l’ensemble (carte + moteurs) sur le châssis.

Vérifier le parallélisme des roues (afin d’assurer un déplacement rectiligne du
robot) comme le montre la figure 14 :
Figure 14. Vérification du parallélisme des roues.
2.5. SOUDURE DES MOTEURS A LA CARTE-MOTEURS
A ce stade de montage, vous devriez avoir les pattes des moteur marquées
par un plus (+) vers l’avant du robot.
Faites penchez les connecteurs (+) et (–) de la carte vers les connecteurs
des moteurs et soudez délicatement. La figure 15 illustre les étapes à suivre :

Figure 15. Soudure des moteurs à la carte-moteurs.
2.6. INSTALLATION DE LA BATTERIE
Coller la batterie sous le châssis (figure 16) :
 Coller l’adhésif (double-face) sous le châssis
 Faire passer le câble de la batterie par l’ouverture carrée avant
 Enlever le papier protecteur sur l’adhésif
 Coller la batterie en appuyant fermement. Les inscriptions de la batterie
doivent rester visibles.
Attention : La batterie doit être positionnée comme sur la photo (latéralement
centrée, l’arrière de la batterie alignée avec la grande ouverture
rectangulaire dans le châssis)
Vue de dessus
des connecteurs
Soudure des moteurs aux
connecteurs
Moteur soudé à
la carte

Figure 16. Installation de la batterie.
Connecter la batterie comme le montre la figure 17 :
Figure 17. Connexion de la batterie.
Fiche détrompeuse

2.7. INSTALLATION DE LA CARTE LAUNCHPAD & L’AFFICHEUR
Enfichez la carte Launchpad en dessus de la carte moteur (figure 18) :
Figure 18. Installation de la carte Launchpad et l’afficheur.
FIN DU DOCUMENT



Annexure-III
SOURCE CODE OF THE LFOAAR SYSTEM

Page: 1C:UsersEMMANUL CHINMADocumentsmain.cpp
Sunday, February 24, 2013 / 8:26 PM
1: /* 15 February 2013
2: *
3: * MSEE12 PROJECT
4: *
5: * Implementation of robotic obstacle avoidance and line/path ¬
follower using:
6: *
7: * i) MSP430G2553 MCU,
8: *
9: * ii) Two Sharp GP2D120 Infra Red (IR) Sensors mounted at the ¬
front of the robot (Robot Aspirateur),and
10: *
11: * iii) Four (Pololu Corporation) QTR-8A reflectance Sensor (2 ¬
mounted at the front and 2 at the back)
12: *
13: * 1V) Black tape used to construct the path (or line) for the ¬
robot.
14: *
15: *
16: * PROJECT TEAM:
17: *
18: * 1) CHIDINMA, Emmanuel; emmanuel.c.chidinma@gmail.com
19: *
20: * 2) COVARRUBIAS, Erick; e.covarrubias.fr@gmail.com
21: *
22: * 3) VAITHIANATHAN, Kavitha; thamizh.pec@gmail.com
23: *
24: * 4) NARAYANA, Ravi Raj; nrnraviraj@gmail.com
25: *
26: * 5) CHUGH, Ishan; ishanchugh89@gmail.com
27: *
28: * 6) MUKESH, Sagarika; sagarika.mukesh@gmail.com
29: *
30: *
31: */
32:
33:
34: #include "io430.h"
35:
36: #include "intrinsics.h"
37:
38: #include "stdint.h"
39:
40: #include <time.h>
41:
42: #include <stdlib.h>
43:
44:
45:
46: float dist_right; // distance of right IR sensor from obstacle
47:
48: float dist_left; // distance of left IR sensor from obstacle
49:
50: bool colour_front_right; // colour sensed by the front right line ¬
sensor (black or others)
51:
52: bool colour_back_right; // colour sensed by the back right line ¬
53:
54: bool colour_front_left; // colour sensed by the front left line ¬
55:
56: bool colour_back_left; // colour sensed by the back left line ¬
57:
58: //unsigned long OptocouplerLeftCountValue = 0; // the left ¬
optocoupler count variable
59:

60: //unsigned long OptocouplerRightCountValue = 0; // the right ¬
optocoupler count variable
61:
62: unsigned short int k = 0; // flag to enable choosing between the ¬
left or right IR sensor
63:
64: unsigned short int j = 0; // flag to hold the next k
65:
66: unsigned short int l = 0; // flag to enable choosing between the ¬
left or right line sensor
67:
68: unsigned short int p = 0; // flag to hold the previous l
69:
70: unsigned short int m = 0; // flag that accumulates the number of ¬
interrupts during the
71:
72: // left and right line sensor conversions
73:
74: unsigned short int RandNum; // holds 0, 1, 2 or 3 for the move ¬
backwards, turn left, turn right
75:
76: // and move forward respectively of the possible ¬
robot directions
77:
78: unsigned short int r = 0; // flag for tracking the number of ¬
executions when program is
79:
80: // executing in the section of the backwards movements
81:
82: unsigned short int n = 0; // flag for tracking the number of ¬
executions when program is
83:
84: // executing in the section of line finding
85:
86:
87:
88:
89:
90: void initGPIO ()
91:
92: { // | p6 p2
93:
94: // configure pins 2 and 6 of port2 as GPIO | 0 0 move ¬
backwards
95:
96: // outputs to send to the samboard the motor | 0 1 turn left
97:
98: // direction | 1 0 turn right
99:
100: P2SEL &= ~BIT6; // | 1 1 move ¬
forward
101: P2SEL2 &= ~BIT6;
102:
103: P2SEL &= ~BIT2;
104:
105:
106: //P2SEL2 &= ~BIT2;
107:
108: P2DIR |= BIT6; // GPIO output
109:
110: P2DIR |= BIT2; // GPIO output
111:
112:
113:
114: // configure pins 3 and 4 of port2 as GPIO
115:
116: // inputs to receive the optocoupler outputs
117:

118: P2SEL &= ~BIT3; // left wheel optocouplerA outputs to this pin
119:
120: P2SEL &= ~BIT4; // right wheel optocouplerB outputs to this pin
121:
122: //P2SEL2 &= ~BIT3;
123:
124: //P2SEL2 &= ~BIT4;
125:
126: P2DIR &= ~BIT3; // GPIO input
127:
128: P2DIR &= ~BIT4; // GPIO input
129:
130: }
131:
132:
133:
134: void init_Timer_ports ()
135:
136: {
137:
138: P2DIR |= (BIT1 | BIT5);
139:
140: P2SEL |= (BIT1 | BIT5);
141:
142: P2SEL2 &= ~BIT1;
143:
144: P2SEL2 &= ~BIT5;
145:
146: P2OUT |= BIT1; // Timer A1 channel 1 for the right motor
147:
148: P2OUT |= BIT5; // Timer A1 channel 2 for the left motor
149:
150: }
151:
152:
153:
154: void init_PWM_1 ()
155:
156: {
157:
158: TA1CTL |= (TASSEL_2 | MC_1 | ID_2 | TACLR); // up mode
159:
160: TA1CTL &= ~TAIFG;
161:
162: //TA1CCTL0 |= CCIE;
163:
164: TA1CCR0 = 7500; // period is 30ms. N/B: time of IR sensor voltage ¬
output
165:
166: // is 55ms approx. D/4 there is 60ms timing between each
167:
168: // IR sensor (2 of them) distance measurement and ADC ¬
conversion.
169:
170: // The ADC sample and conversion time is 308micro s. ¬
approx.
171:
172: TA1CCR1 = 3000; // initial arbitrary value to power right motor
173:
174: TA1CCR2 = 3000; // initial arbitrary value to power left motor
175:
176: TA1CCTL1 |= OUTMOD_7;
177:
179:
180: }
181:
182:

183:
184: void init_PWM_2 ()
185:
186: {
187:
188: TA1CTL |= (TASSEL_2 | MC_1 | ID_2 | TACLR); // up mode
189:
191:
192: //TA1CCTL0 |= CCIE;
193:
194: TA1CCR0 = 250; // period is 1ms. N/B: time of line sensor voltage ¬
output
195:
196: // is 10micro s approx. D/4 there is 4ms timing between ¬
each
197:
198: // line sensor (4 of them) colour measurement and ADC ¬
conversion.
199:
200: // The ADC sample and conversion time is 308micro s ¬
approx.
201:
202: TA1CCR1 = 150; // initial arbitrary value to power right motor
203:
204: TA1CCR2 = 150; // initial arbitrary value to power left motor
205:
207:
209:
210: }
211:
212:
213:
214: void init_ADC10 ()
215:
216: {
217:
218: ADC10CTL0 &= ~ADC10IFG;
219:
220: }
221:
222:
223:
224: float calculate_distance ()
225:
226: {
227:
228: float distance; // distance (d in cm) from obstacle, and voltage ¬
(V in volts) generated
229:
230:
231:
232: if ((1023 >= ADC10MEM) && (ADC10MEM >= 928)) {distance = (float)( ¬
(1308 - ADC10MEM)/95);} // 3.00 >= V >= 2.72 and 3 <= d <= 4
233:
234: else if ((928 > ADC10MEM) && (ADC10MEM >= 682)) {distance = (flo ¬
at)((1420 - ADC10MEM)/123);} // 2.72 > V >= 2.00 and 4 < d <= 6
235:
at)((1132 - ADC10MEM)/75);} // 2.00 > V >= 1.56 and 6 < d <= 8
237:
at)((1936 - 2*ADC10MEM)/109);} // 1.56 > V >= 1.24 and 8 < d <= 10
239:
at)((5154 - 8*ADC10MEM)/177);} // 1.24 > V >= 0.72 and 10 < d <= ¬

18
241:
at)((4806 - 12*ADC10MEM)/103);} // 0.72 > V >= 0.42 and 18 < d <= ¬
30
243:
244: else {distance = 35.0;} // 35.0 assigned arbitrarily for ((143 > ¬
ADC10MEM) && (ADC10MEM > 0)) since 0.42 > V >= 0 and d > 30
245:
246:
247:
248: return distance;
249:
250: }
251:
252:
253:
254: bool calculate_colour ()
255:
256: {
257:
258: bool colour_sensed; // colour sensed under the robot, and voltage ¬
(V in volts) generated
259:
260:
261:
262: if ((1023 >= ADC10MEM) && (ADC10MEM >= 853)) {colour_sensed = 0;} ¬
// 3.00 >= V >= 2.50, black colour
263:
264: else {colour_sensed = 1;} // ((853 > ADC10MEM) && (ADC10MEM >= ¬
0)) since 2.50 > V >= 0, for other colours
265:
266:
267:
268: return colour_sensed;
269:
270: }
271:
272:
273:
274: void move_backwards ()
275:
276: {
277:
278: P2OUT &= ~BIT6;
279:
280: P2OUT &= ~BIT2;
281:
282: }
283:
284:
285:
286: void move_left ()
287:
288: {
289:
290: P2OUT &= ~BIT6;
291:
292: P2OUT |= BIT2;
293:
294: }
295:
296:
297:
298: void move_right ()
299:
300: {
301:

302: P2OUT |= BIT6;
303:
304: P2OUT &= ~BIT2;
305:
306: }
307:
308:
309:
310: void move_forward ()
311:
312: {
313:
314: P2OUT |= BIT6;
315:
316: P2OUT |= BIT2;
317:
318: }
319:
320:
321:
322: void stop ()
323:
324: {
325:
326: TACCR1 = 0;
327:
328: TACCR2 = 0;
329:
330: }
331:
332:
333: /* void enableInterruptFlags_Optocouplers()
334:
335: {
336:
337: // enable interrupts on edge on pins 3 and 4 of Port2
338:
339: P2IE |= BIT3;
340:
341: P2IE |= BIT4;
342:
343: // sensitive to positve edge (0 to 1 transition)
344:
345: P2IES &= ~BIT3;
346:
347: P2IES &= ~BIT4;
348:
349: // clear any pending interrupts on these bits
350:
351: P2IFG &= ~BIT3;
352:
353: P2IFG &= ~BIT4;
354:
355: }
356: */
357:
358:
359: /*void disableInterruptFlags_Optocouplers()
360:
361: {
362:
363: // disable interrupts on edge on pins 3 and 4 of Port2
364:
365: P2IE &= ~BIT3;
366:
367: P2IE &= ~BIT4;
368:
369: }

370:
371: */
372:
373: void guess_direction()
374:
375: {
376:
377: // generate the random number between 0 and 3
378:
379: srand (time(NULL)); // ensure a random number is chosen ¬
inbetween programs
380:
381: RandNum = rand() % 4; // generate random number from 0 to 3
382:
383: }
384:
385:
386:
387: void set_speed_right (int speed)
388:
389: {
390:
391:
392: TA1CCR1 = speed;
393:
394: }
395:
396:
397:
398: void set_speed_left (int speed)
399:
400: {
401: TA1CCR2 = speed;
402:
403: }
404:
405:
406:
407: void turn_right (int angle)
408:
409: {
410:
411: int current_right_speed = angle + 60;
412:
413: set_speed_right (current_right_speed);
414:
415: }
416:
417:
418:
419: void turn_left (int angle)
420:
421: {
422:
423: int current_left_speed = angle + 60;
424:
425: set_speed_left (current_left_speed);
426:
427: }
428:
429:
430:
431: void right_line_sensor (bool colour)
432:
433: {
434:
435: int current_angle; // angle of turning left (determined by speed) ¬
and measured from the x-axis

436:
437:
438:
439: if (colour == 0) // 3.00 >= V >= 2.50 which is black (the colour ¬
of the line being followed)
440:
441: {
442:
443: current_angle = 40;
444:
445: }
446:
447: else // colour = 1: 2.50 > V >= 0 which represents other colours ¬
apart from black
448:
449: {
450:
452:
453: }
454:
455:
456:
457: turn_left (current_angle);
458:
459: }
460:
461:
462:
463: void left_line_sensor (bool colour)
464:
465: {
466:
467: int current_angle; // angle of turning right (determined by ¬
speed) and measured from the x-axis
468:
469:
470:
471: if (colour == 0) // 3.00 >= V >= 2.50 which is black (the colour ¬
of the line being followed)
472:
473: {
474:
476:
477: }
478:
479: else // colour = 1: 2.50 > V >= 0 which represents other colours ¬
apart from black
480:
481: {
482:
484:
485: }
486:
487:
488:
489: turn_right (current_angle);
490:
491: }
492:
493:
494:
495: void InitUART(void)
496:
497: {
498:

499: P1SEL |= (BIT1 + BIT2); // P1.1 = RXD, P1.2=TXD
500:
501: P1SEL2 |= (BIT1 + BIT2); // P1.1 = RXD, P1.2=TXD
502:
503: UCA0CTL1 |= UCSSEL_2; // SMCLK 1 MHz
504:
505:
506:
507: // UCOS16 = 1
508:
509: // 1,000,000Hz, 9600Baud, UCBRx=6, UCBRSx=0, UCBRFx=1
510:
511: UCA0BR0 = 6; // 1MHz, OSC16, 9600 B ¬
Baud Rate Control Register 0
512:
513: UCA0BR1 = 0; // 1MHz, OSC16, 9600 Baud ¬
Rate Control Register 1
514:
515:
516:
517: //UCA0MCTL |= ( UCBRFx | UCBRSx | UCOS16 ); // USCI_A0 modulation ¬
control
518:
519: UCA0MCTL = 0x10|UCOS16; // check the control bits using the ¬
tables in the documentation.
520:
521:
522:
523: // UCBRFx=1,UCBRSx=0, UCOS16=1
524:
525: UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine** ¬
526:
527: IE2 |= UCA0RXIE; // Enable USCI_A0 RX interrupt
528:
529: }
530:
531:
532: void TXdata( unsigned char c )
533:
534: {
535:
536: while (!(IFG2&UCA0TXIFG)); // USCI_A0 TX buffer ¬
ready?
537:
538: UCA0TXBUF = c; // TX -> RXed character
539:
540: }
541:
542:
543:
544: void right_IR_conversion () // called when k = 1
545:
546: {// conversion from the right (Sharp) GP2D120 Infra Red (IR) ¬
Sensor
547:
548: ADC10CTL0 |= (SREF_0 | ADC10SHT_3 | ADC10SR | ADC10ON);
549:
550: ADC10CTL1 |= (INCH_7 | SHS_0 | ADC10DIV_3 | ADC10SSEL_3 | ¬
CONSEQ_0);
551:
552: ADC10AE0 |= BIT7;
553:
554: ADC10CTL0 |= (ENC | ADC10SC);
555:
556: while (ADC10CTL1 & ADC10BUSY)
557:
558: { // (64+13) times the ADC10CLK clock cycles = 308micro

559:
560: } // seconds for the sample and conversion time
561:
562: dist_right = calculate_distance ();
563:
565:
566: ADC10CTL0 &= ~ENC;
567:
568: ADC10AE0 &= ~BIT7;
569:
570: k = 0; // next k, transfer control to left_IR_conversion ()
571:
572: }
573:
574:
575:
576: void left_IR_conversion () // called when k = 0
577:
578: {// conversion from the left (Sharp) GP2D120 Infra Red (IR) Sensor
579:
581:
582: ADC10CTL1 = (INCH_0 | SHS_0 | ADC10DIV_3 | ADC10SSEL_3 | ¬
CONSEQ_0);
583:
584: ADC10AE0 |= BIT0;
585:
587:
589:
591:
593:
594: dist_left = calculate_distance ();
595:
597:
598: ADC10CTL0 &= ~ENC;
599:
600: ADC10AE0 &= ~BIT0;
601:
602: k = 1; // next k, transfer control to right_IR_conversion ()
603:
604: }
605:
606:
607:
608: void front_right_line_conversion () // called when l = 1
609:
610: {// conversion from the front right (Pololu Corporation) QTR-8A ¬
reflectance Sensor
611:
613:
CONSEQ_0);
615:
616: ADC10AE0 |= BIT5;
617:
619:
621:
623:

625:
626: colour_front_right = calculate_colour ();
627:
629:
630: ADC10CTL0 &= ~ENC;
631:
632: ADC10AE0 &= ~BIT5;
633:
634: p = l; // save previous l before updating it
635:
636: l = 2; // next l, transfer control to back_left_line_conversion ( ¬
)
637:
638: }
639:
640:
641:
642: void front_left_line_conversion () // called when l = 0
643:
644: {// conversion from the front left (Pololu Corporation) QTR-8A ¬
reflectance Sensor
645:
647:
CONSEQ_0);
649:
650: ADC10AE0 |= BIT4;
651:
653:
655:
657:
659:
660: colour_front_left = calculate_colour ();
661:
663:
664: ADC10CTL0 &= ~ENC;
665:
666: ADC10AE0 &= ~BIT4;
667:
669:
670: l = 1; // next l, transfer control to front_right_line_conversion ¬
()
671:
672: }
673:
674:
675:
676: void back_right_line_conversion () // called when l = 3
677:
678: {// conversion from the back right (Pololu Corporation) QTR-8A ¬
reflectance Sensor
679:
681:
CONSEQ_0);
683:
684: ADC10AE0 |= BIT6;
685:

687:
689:
691:
693:
694: colour_back_right = calculate_colour ();
695:
697:
698: ADC10CTL0 &= ~ENC;
699:
700: ADC10AE0 &= ~BIT6;
701:
703:
704: l = 0; // next l, transfer control to front_left_line_conversion ¬
()
705:
706: }
707:
708:
709:
710: void back_left_line_conversion () // called when l = 2
711:
712: {// conversion from the back left (Pololu Corporation) QTR-8A ¬
reflectance Sensor
713:
715:
CONSEQ_0);
717:
718: ADC10AE0 |= BIT3;
719:
721:
723:
725:
727:
728: colour_back_left = calculate_colour ();
729:
731:
732: ADC10CTL0 &= ~ENC;
733:
734: ADC10AE0 &= ~BIT3;
735:
737:
738: l = 3; // next l, transfer control to back_right_line_conversion ¬
()
739:
740: }
741:
742:
743:
744: /*
745: //ISR_01===================================
746:
747: #pragma vector = TIMER0_A0_VECTOR
748:
749: interrupt void TIMER0 A0 ISR (void) // for TACCRO CCIFG, which ¬

resets
750:
751: { // automatically once ISR is serviced
752:
753: TACCR1 = DynTACCR1;
754:
755: TACCR2 = DynTACCR2;
756:
757: }
758:
759: //=========================================
760: */
761:
762: /*//ISR_02===================================
763:
764: #pragma vector = PORT2_VECTOR
765:
766: __interrupt void PORT2_ISR (void)
767:
768: {
769:
770: if(P2IFG & BIT3)
771:
772: {
773:
774: P2IFG &= ~BIT3;
775:
776: OptocouplerLeftCountValue++;
777:
778: }
779:
780: // Remember to initialize the static variable
781:
782: // OptocouplerLeftCountValue to zero at the
783:
784: // calling function after using the its counted value
785:
786:
787:
788: if(P2IFG & BIT4)
789:
790: {
791:
792: P2IFG &= ~BIT4;
793:
794: OptocouplerRightCountValue++;
795:
796: }
797:
798: // Remember to initialize the static variable
799:
800: // OptocouplerRightCountValue to zero at the
801:
802: // calling function after using the its counted value
803:
804: }
805:
806: //============================= */
807:
808:
809:
810: int main( void )
811:
812: {
813:
814: // Stop watchdog timer to prevent time out reset
815:
816: WDTCTL = WDTPW + WDTHOLD;

817:
818:
819: initGPIO ();
820:
821: //disableInterruptFlags_Optocouplers();
822:
823: init_Timer_ports ();
824:
825: init_PWM_1 ();
826:
827: move_forward ();
828:
829: init_ADC10 (); // start conversion first for k = 0 (left IR ¬
sensor)
830:
831: __enable_interrupt(); // enable global interrupts
832:
833:
834:
835: while (1)
836:
837: {
838:
839: while (TA1CTL & TAIFG)
840:
841: {
842:
844:
845: if ( k == 0)
846:
847: {
848:
849: left_IR_conversion ();
850:
851: j = k; // save the next value of k
852:
853: }
854:
855: else if (k == 1)
856:
857: {
858:
859: right_IR_conversion ();
860:
861: j = k; // save the next value of k
862:
863: }
864:
865:
866:
867: //DETERMINE WHETHER ROBOT SHOULD BE AVOIDING OBSTACLE OR FOLLOWING ¬
LINE. BOTH ARE MUTUALLY EXCLUSIVE: (i) WHEN ROBOT
868: // IS AVOIDING AVOIDING, THEN IT DOES NOT BOTHER ABOUT FOLLOWING ¬
THE LINE. (ii) WHEN THE ROBOT IS FOLLOWING THE LINE,
869: // IT CAN ONLY BE DERAILED WHEN IT ENCOUNTERS AN OBSTACLE AND ¬
ATTEMPTS TO AVOID IT. (iii) WHEN THE ROBOT HAS BEEN IN
870: // THE COURSE OF AVOIDING AN OBSTACLE, IT MUST ATTEMPT TO RETRACE ¬
THE LINE AFTER THE OBSTACLE AVOIDANCE.
871:
872: if ((dist_right <= 30) || (dist_left <= 30)) // Then there is ¬
an impending obstacle.
873:
874: // A) THIS IS THE PROGRAM SECTION FOR OBSTACLE AVOIDANCE
875:
876: // We program for avoidance: the robot will most certainly be ¬
derailed (miss the line following)
877:

878: // in the course of trying to avoid the obstacle. D/4 line ¬
following is not priority here.
879:
880: {
881:
882: n = 0; // once we are out of the section of line finding, ¬
n is initialized
883:
884:
885: // PROGRAM THE 3 POSSIBLE SITUATIONS
886:
887: if (dist_right > dist_left)
888:
889: {// Ai) THE ROBOT ATTEMPTS TO MOVE RIGHT BECAUSE THERE IS ¬
MORE SPACE AT THE RIGHT
890:
891: // then turn right slowly and progressively until ¬
dist_right and dist_left are both > 30cm.
892:
893: // When this happens, control will be transferred back to ¬
the line senors, which handles
894:
895: // this case with the robot having been derailed in the ¬
course of obstacle avoidance
896:
897:
898:
899: //enableInterruptFlags_Optocouplers();
900:
901: r = 0; // once we are out of the section of backwards ¬
movement (for obstacle avoidance), r is initialized
902:
903: move_right ();
904:
905: } // end if Ai
906:
907: else if (dist_left > dist_right)
908:
909: {// Aii) THE ROBOT ATTEMPTS TO MOVE LEFT BECAUSE THERE IS ¬
MORE SPACE AT THE LEFT
910:
911: // then turn left slowly and progressively until ¬
dist_right and dist_left are both > 30cm.
912:
914:
915: // this case with the robot having been derailed in the ¬
course of obstacle avoidance
916:
917:
918:
919: //enableInterruptFlags_Optocouplers();
920:
921: r = 0; // once we are out of the section of backwards ¬
movement (for obstacle avoidance), r is initialized
922:
923: move_left ();
924:
925: }// end else if Aii
926:
927: else // dist_right = dist_left (or both are < 30cm). Then ¬
the robot is fast approaching a target
928:
929: { // Aiii) THIS IS THE PROGRAM SECTION OF BACKWARD ¬
MOVEMENT OF THE ROBOT BECAUSE THE ROBOT
930:
931: // HAS BEEN BOXED IN A CORNER:

932:
933: // Here, implement move_backwards() of the robot ¬
direction, such that this movement
934:
935: // continues until it is sensed that dist_right and ¬
dist_left are both > 30cm.
936:
938:
939: // this case with the robot (most certainly) having been ¬
derailed in the course of obstacle avoidance
940:
941:
942:
943: // The idea below is to choose to implement the backwards ¬
movement
944:
945: // for about 6 seconds (200 X 30ms is about 6s) if the ¬
program flow keeps coming here. But, if
946:
947: // in the process of implementing this, and the program ¬
flow leaves
948:
949: // this section, then we know, at least that the robot is ¬
not approaching a targest on both sides.
950:
951: // Note that move_forward () is not an option when the ¬
robot is approaching an abstacle.
952:
953:
954:
955: if ((r == 0) || (r == 200)) // Aiiia
956:
957: {
958: if (r == 200) {r = 0;} // Aiiiai beginning and end
959:
960: move_backwards ();
961:
962: } // end Aiiia
963:
964: r++;
965:
966: }// end else Aiii
967:
968: }// end if A
969:
970: else // ((dist_right > 30) && (dist_left > 30)): then there is ¬
no impending obstacle.
971:
972: // B) THIS IS THE PROGRAM SECTION WHERE THE LINE SENSORS ARE ¬
SOLELY IN CONTROL SINCE THERE IS NO IMPENDING OBSTACLE.
973:
974: // We program the line sensors to ensure robot follows the ¬
black line and
975:
976: // is not derailed. This is the priority here and not obstacle ¬
avoidance.
977:
978: // Run this section for 28ms out of the possible 30ms period. ¬
7 measurements for each line sensor
979:
980: {// Start by switching to a faster clock (PWM_2) for the line ¬
sensors: 1ms TA1CCR0 PERIOD
981:
982: if (k != 2) // B1 if
983:
984: {

985:
986: TA1CCR0 = 0; //stop PWM_1
987:
988: k = 2; // control is tranferred to the line sensors
989:
990: r = 0; // once we are out of the section of backward ¬
movement (of obstacle avoidance), r is initialized
991:
992: init_PWM_2 (); // start PWM_2
993:
994: }// end B1 if
995:
996: if ( l == 0) // B2 if
997:
998: {
999:
1000: front_left_line_conversion ();
1001:
1002: m++; // increment the number of interrupts
1003:
1004: }
1005:
1006: else if (l == 1)
1007:
1008: {
1009:
1010: front_right_line_conversion ();
1011:
1013:
1014: }
1015:
1016: else if ( l == 2)
1017:
1018: {
1019:
1020: back_left_line_conversion ();
1021:
1023:
1024: }
1025:
1026: else if (l == 3)
1027:
1028: {
1029:
1030: back_right_line_conversion ();
1031:
1033:
1034: } // end B2 if
1035:
1036: // if m = 28, stop PWM2, start PWM1, and take conntrol
1037:
1038: // back to the IR sensors
1039:
1040: if (m == 28) // B3 if
1041:
1042: {
1043:
1044: TA1CCR0 = 0; //stop PWM_2
1045:
1046: k = j; // transfer control back to the next IR sensor
1047:
1048: init_PWM_1 (); // start PWM_1
1049:
1050: m = 0; // initialize m for the next session of line ¬
sensors measurements

1051:
1052: }// end B3 if
1053:
1054: //THEN CONSIDER THE FOLLOWING 4 SITUATIONS
1055:
1056: // a) Regulate the movement of the robot with all 4 line ¬
sensors as shown in B4i)
1057: if (/*01*/((colour_front_right == 0) && (colour_front_left ¬
== 0) && (colour_back_right == 0) && (colour_back_left == 0)) ||
1058: /*02*/((colour_front_right == 0) && (colour_front_left ¬
== 1) && (colour_back_right == 1) && (colour_back_left == 0))) // ¬
B4i condition
1065:
1066: // B4i) ALL 4 LINE SENSORS PARTAKE IN REGULATING THE ¬
MOVEMENT OF THE ROBOT TO ENSURE IT KEEPS FOLLOWING THE LINE BY
1067:
1068: // CALLING THE LINE SENSOR FUNCTIONS AND MOVING FORWARD
1069:
1070: {
1071:
1072: n = 0; // once we are out of the section of line ¬
finding, n is initialized
1073:
1075:
1076: if ( p == 0)
1077:
1078: {
1079:
1080: left_line_sensor (colour_front_left);
1081:
1082: }
1083:
1084: else if (p == 1)
1085:
1086: {
1087:
1088: right_line_sensor (colour_front_right);
1089:
1090: }
1091:
1092: else if (p == 2)
1093:
1094: {
1095:
1096: left_line_sensor (colour_back_left);
1097:
1098: }
1099:
1100: else if (p == 3)
1101:
1102: {
1103:
1104: right_line_sensor (colour_back_right);
1105:
1106: }

1107:
1108: }// end B4i
1109:
1110:
1111: // b) Just move the robot forward and attempt to find the ¬
line as shown in B4ii)
1112: else if (/*16*/((colour_front_right == 1) && ( ¬
colour_front_left == 1) && (colour_back_right == 1) && ( ¬
colour_back_left == 1))) // B4ii) condition
1113:
1114: // B4ii) THIS IS THE SITUATION IN WHICH THE ROBOT HAS JUST ¬
AVOIDED AN OBSTACLE AND HAS BEEN DERAILED: ALL 4 LINE SENSORS
1115:
1116: // LINE SENSORS SENSE COLOURS OTHER THAN THE BLACK COLOUR. ¬
HERE THE ROBOT MOVES FORWARD WITH A SLOW SPEED IN AN ATTEMPT
1117:
1118: // TO REACH THE NEAREST LINE
1119:
1120: {
1121:
1123:
1124: TA1CCR1 = 120;
1125:
1126: TA1CCR2 = 120;
1127:
1129:
1130: } // end B4ii
1131:
1132: // c) Regulate the movement of the robot with the 2 front ¬
line sensors only as shown in B4iii)
1133: else if (/*06*/((colour_front_right == 0) && ( ¬
colour_back_left == 1)) ||
1134: /*07*/((colour_front_right == 0) && ( ¬
colour_back_left == 1))) // B4iii condition
1139:
1140: // B4iii) HERE ONLY THE 2 FRONT LINE SENSORS PARTAKE IN ¬
REGULATING THE MOVEMENT OF THE ROBOT TO ENSURE IT KEEPS FOLLOWING ¬
THE LINE BY
1141:
1142: // CALLING THE LINE SENSOR FUNCTIONS AND MOVING FORWARD
1143:
1144: {
1145:
1147:
1149:
1150: if ( p == 0)
1151:
1152: {

1153:
1154: left_line_sensor (colour_front_left);
1155:
1156: }
1157:
1158: else if (p == 1)
1159:
1160: {
1161:
1162: right_line_sensor (colour_front_right);
1163:
1164: }
1165:
1166:
1167: }// end B4iii
1168:
1169: else // /*13*/((colour_front_right == 1) && ( ¬
colour_back_left == 0)) // B4iv condition
1170:
1171: // B4iv) THIS IS THE SECTION OF LINE FINDING. THIS IS THE ¬
SITUATION IN WHICH THE TWO BACK LINE SENSORS HAVE SENSED THE BLACK ¬
LINE, WHILE
1172:
1173: // THE TWO FRONT LINE SENSORS ARE NOT SENSING BLACK. HERE ¬
THE ROBOT MUST ATTEMPT TO REPOSITION ITSELF SUCH THAT 3 OR ALL 4 ¬
LINE SENSORS SENSE
1174:
1175: // THE BLACK COLOUR. THIS MUST BE DONE AT A SLOWER SPEED. ¬
THE ROBOT MUST STOP FIRST. IF THE PROGRAM FLOW KEEPS COMING HERE, ¬
THEN THE CHOSEN
1176:
1177: // DIRECTIONAL MOVEMENT SHOULD EXECUTE FOR 1 SECOND (1MS X ¬
1000) BEFORE ANOTHER IS CHOSEN.
1178:
1179: {
1180:
1181: stop ();
1182:
1183: TA1CCR1 = 110;
1184:
1185: TA1CCR2 = 110;
1186:
1187: do
1188:
1189: {
1190:
1191: if ((n == 0) || (n == 1000))
1192:
1193: {
1194:
1195: if (n == 1000) {n = 0;}
1196:
1197: guess_direction(); // obtain an arbitrary direction
1198:
1199: switch (RandNum)
1200:
1201: {
1202: case 0:
1203:
1204: move_backwards ();
1205:
1206: case 1:
1207:
1208: move_left ();
1209:
1210: case 2:
1211:

1212: move_right ();
1213:
1214: case 3:
1215:
1217:
1218: default:
1219:
1220: move_left ();
1221:
1222: }// end switch
1223:
1224: } // end if
1225:
1226: n++;
1227:
1228: } while ((colour_front_right == 0) && ( ¬
colour_back_left == 0));
1229:
1230: } // end B4iv
1231:
1232: }// end else B
1233:
1234: } // nested while ends
1235:
1236: }// while (1) ends
1237:
1238: }// main() ends
1239:
1240:



Annexure-IV
EXTRACTS OF SOME PROJECT CORRESPONDENCES

Emmanuel Chidinma< emmanuel.c.chidinma@gmail.com>
COVER PAGE
14 messages
kavitha nathan< thamizh.pec@gmail.com> Tue, Feb 19, 2013 at 6:22 PM
To: Emmanuel Chidinma <emmanuel.c.chidinma@gmail.com>, erick Covarrubias Franco
<e.covarrubias.fr@gmail.com>, Ravi Raj <nrnraviraj@gmail.com>, ishan chugh
<ishanchugh89@gmail.com>, Sagarika Mukesh <sagarika.mukesh@gmail.com>
Dear all,
I have attached the draft of cover page,objective and testing part of my work here. I left the conclusion
page open. I feel it is better to include it once all other works are done. Any improvements and
suggestions are welcome.
Regards,
kavitha
Master PROJECT REPORT.doc
63K
To: Emmanuel Chidinma <emmanuel.c.chidinma@gmail.com>, erick Covarrubias Franco
<e.covarrubias.fr@gmail.com>, Ravi Raj <nrnraviraj@gmail.com>, ishan chugh
A Bonafide certificate should also be included in the front mentioning our project Guide and
coordinator. I am looking for the format. I will send you once I complete it.
[Quoted text hidden]
Emmanuel Chidinma < emmanuel.c.chidinma@gmail.com> Tue, Feb 19, 2013 at 6:30 PM
To: kavitha nathan <thamizh.pec@gmail.com>
Cc: erick Covarrubias Franco <e.covarrubias.fr@gmail.com>, Ravi Raj <nrnraviraj@gmail.com>, ishan
chugh <ishanchugh89@gmail.com>, Sagarika Mukesh <sagarika.mukesh@gmail.com>
Yes I was thinking about adding an acnowledgement. This is where the project guide and coordinator
should be mention.
Therefore, please prepare it as well.
Emmanuel
To: Emmanuel Chidinma <emmanuel.c.chidinma@gmail.com>
Hi all,
Check out the draft of the acknowledgement.
ACKNOWLEDGEMENTS.doc
23K
Page 1 of 7Gmail - COVER PAGE
2/24/2013https://mail.google.com/mail/u/0/?ui=2&ik=b91492d98a&view=pt&cat=MSEE_Projec...

Ravi Raj < nrnraviraj@gmail.com> Tue, Feb 19, 2013 at 7:21 PM
Cc: Emmanuel Chidinma <emmanuel.c.chidinma@gmail.com>, erick Covarrubias Franco
<e.covarrubias.fr@gmail.com>, ishan chugh <ishanchugh89@gmail.com>, Sagarika Mukesh
<sagarika.mukesh@gmail.com>
i am attaching the sample of Conclusion i am still working on it and you guys can specify me if i need to
do some changes
cheers
ravi.
Conclusion.docx
14K
Erick Omar Covarrubias Franco< e.covarrubias.fr@gmail.com>
Tue, Feb 19, 2013 at 11:44
PM
To: Ravi Raj <nrnraviraj@gmail.com>
Cc: kavitha nathan <thamizh.pec@gmail.com>, Emmanuel Chidinma
<emmanuel.c.chidinma@gmail.com>, ishan chugh <ishanchugh89@gmail.com>, Sagarika Mukesh
<sagarika.mukesh@gmail.com>
Hello to everyone.
please check it out and make suggestions.
have a good night.
Best regards.
Erick Covarrubias.
2 Av Maryse Bastié Apt 60
CP 76800 St Étienne du Rouvray, France
T +33 63 117 2297
+33 65 272 3225
e.covarrubias.fr@gmail.com
Le 19/02/2013 à 19:21, Ravi Raj <nrnraviraj@gmail.com> a écrit :
i am attaching the sample of Conclusion i am still working on it and you guys can specify
me if i need to do some changes
cheers
ravi.
On Tue, Feb 19, 2013 at 7:07 PM, kavitha nathan >thamizh.pec@gmail.com< wrote:
Hi all,
Check out the draft of the acknowledgement.

On Tue, Feb 19, 2013 at 6:30 PM, Emmanuel Chidinma
>emmanuel.c.chidinma@gmail.com< wrote:
Yes I was thinking about adding an acnowledgement. This is where the project guide
and coordinator should be mention.
Therefore, please prepare it as well.
Emmanuel
On Tue, Feb 19, 2013 at 6:28 PM, kavitha nathan >thamizh.pec@gmail.com< wrote:
A Bonafide certificate should also be included in the front mentioning our project
Guide and coordinator. I am looking for the format. I will send you once I complete
it.
On Tue, Feb 19, 2013 at 6:22 PM, kavitha nathan >thamizh.pec@gmail.com<
wrote:
Dear all,
I have attached the draft of cover page,objective and testing part of my work
here. I left the conclusion page open. I feel it is better to include it once all other
works are done. Any improvements and suggestions are welcome.
Regards,
kavitha
<Conclusion.docx>
HW&M ROBOT.pdf
39K
Emmanuel Chidinma< emmanuel.c.chidinma@gmail.com> Wed, Feb 20, 2013 at 2:13 AM
To: Erick Omar Covarrubias Franco <e.covarrubias.fr@gmail.com>
Cc: Ravi Raj <nrnraviraj@gmail.com>, kavitha nathan <thamizh.pec@gmail.com>, ishan chugh
Erick
We need this report in MS WORD
Thats how it can easily be collated with others.
Please send it
Thanks
Le 19/02/2013 à 19:21, Ravi Raj <nrnraviraj@gmail.com> a écrit :
<Conclusion.docx>

Emmanuel Chidinma < emmanuel.c.chidinma@gmail.com> Wed, Feb 20, 2013 at 2:17 AM
Cc: Ravi Raj <nrnraviraj@gmail.com>, ishan chugh <ishanchugh89@gmail.com>, Sagarika Mukesh
<sagarika.mukesh@gmail.com>, erick Covarrubias Franco <e.covarrubias.fr@gmail.com>
Meanwhile
Kavitha please see my idea of a cover page attached
Here the names are depicted as members of a team:
Ishan is the arrow head
The 2 ladies are the wingers
Erick, Emmanuel and Ravi are the defence men
Master PROJECT REPORT_ECC2.docx
27K
Sagarika Mukesh< sagarika.mukesh@gmail.com> Wed, Feb 20, 2013 at 4:41 PM
Cc: Emmanuel Chidinma <emmanuel.c.chidinma@gmail.com>, Ravi Raj <nrnraviraj@gmail.com>, kavitha
nathan <thamizh.pec@gmail.com>, ishan chugh <ishanchugh89@gmail.com>
Hi guys,
Here is the edited version of acknowledgement, with minor grammatical corrections.
Thanks
Sagarika
ACKNOWLEDGEMENTS.doc
23K
Emmanuel Chidinma< emmanuel.c.chidinma@gmail.com> Wed, Feb 20, 2013 at 8:28 PM
For the Acknowlegements, please note that I built upon Sagarika's contribution
On Wed, Feb 20, 2013 at 8:26 PM, Emmanuel Chidinma >emmanuel.c.chidinma@gmail.com< wrote:
Hi Kavitha
I have made sunstantiall changes in your documents: technical, grammatical and spellings. You can
always see my changes shown in blue font.
Please check out the area I have highlightd with red font and complete it.
There seems to be an overlap between your work and that of Ravi. And we have not yet seen the
latest from Ravi.

Please liaise accordingly with him so that there is a complete separation of duties between you two.
There should not be duplicacy of works.
We have not heard a word from Ishan.
Folks, please note that I use both British and Americam English interchangeably. To me they are all
the same.
Regards.
Emmanuel
Sagarika Mukesh< sagarika.mukesh@gmail.com> Thu, Feb 21, 2013 at 6:38 AM
Cc: kavitha nathan <thamizh.pec@gmail.com>, erick Covarrubias Franco <e.covarrubias.fr@gmail.com>,
Ravi Raj <nrnraviraj@gmail.com>, ishan chugh <ishanchugh89@gmail.com>
Hi all,
Find attached my Project plan, it is free to be edited by everyone :)
Thanks
Sagarika
Project Plan -Final.docx
65K
Sagarika Mukesh< sagarika.mukesh@gmail.com> Thu, Feb 21, 2013 at 7:13 AM
Cc: kavitha nathan <thamizh.pec@gmail.com>, erick Covarrubias Franco <e.covarrubias.fr@gmail.com>,
Ravi Raj <nrnraviraj@gmail.com>, ishan chugh <ishanchugh89@gmail.com>
Hi all,
Find attached the MS Project file.
Regards,
Sagarika
Project1.mpp
155K
Emmanuel Chidinma< emmanuel.c.chidinma@gmail.com> Fri, Feb 22, 2013 at 8:29 AM
Cc: kavitha nathan <thamizh.pec@gmail.com>, Ravi Raj <nrnraviraj@gmail.com>, ishan chugh
Folks,
Please find attached the draft for my own contribution to the report. kindly make your comments about
it.
In this draft you will not find a flow chart because flow chat is "anticuado."
Erick can explain the meaning of that word.

I kinda concur with Erick to use his caption for the project. This is not neglecting Kavitha's caption
because:
Erick's caption = Kavitha's caption + Assembly of the Robot.
I will now proceed to merge all the individual contributions in to a draft report.
This draft shall be sent across later today.
Regards
Emmanuel
On Thu, Feb 21, 2013 at 1:16 PM, Erick Omar Covarrubias Franco >e.covarrubias.fr@gmail.com<
wrote:
Here is the word version for the adaptations. of harwarre, fore the title that i put , consider for
using at main title. ( suggest)
see you guys
Best regards.
Erick Covarrubias.
2 Av Maryse Bastié Apt 60
CP 76800 St Étienne du Rouvray, France
T +33 63 117 2297
+33 65 272 3225
e.covarrubias.fr@gmail.com
Le 21/02/2013 à 12:55, kavitha nathan <thamizh.pec@gmail.com> a écrit :
Hi Emmanuel,
I have gone through the document with the changes you have made. Now, it looks
perfect for me. Unfortunately i dont know the version number of the IAR.
Erick and Ravi please let me know the the IAR version used for the project.
Software.docx
33K
ishan chugh < ishanchugh89@gmail.com> Fri, Feb 22, 2013 at 6:40 PM
Cc: Ravi Raj <nrnraviraj@gmail.com>, Sagarika Mukesh <sagarika.mukesh@gmail.com>, kavitha nathan
<thamizh.pec@gmail.com>, erick Covarrubias Franco <e.covarrubias.fr@gmail.com>

Emmanuel Chinonye, CHIDINMA <e.chidinma.12@groupe-esigelec.fr>
MSEE12 Project Source Code and Three Videos
3 messages
Emmanuel Chidinma <emmanuel.c.chidinma@gmail.com> 16 février 2013 23:44
À : delarue@esigelec.fr, vauchey@esigelec.fr
Cc : erick Covarrubias Franco <e.covarrubias.fr@gmail.com>, kavitha nathan <thamizh.pec@gmail.com>,
Ravi Raj <nrnraviraj@gmail.com>, Sagarika Mukesh <sagarika.mukesh@gmail.com>,
ishanchugh89@gmail.com, e.chidinma.12@groupe-esigelec.fr
BATCH 01
Dear Sirs,
As instructed, please find attached the project source code and the videos (3 of them).
The emails will be coming in 3 chunks because the video files are heavy.
We also want to use this opportunity to specially thank you for all your support and assistance.
Emmanuel Chidinma
2 pièces jointes
MSEE12 Project Source Code.cpp
27K
Video_1_of_3_Robotic_Obstacle_ Avoidance.wmv
15782K
BATCH 02
[Texte des messages précédents masqué]
Video_2_of_3_Robotic_Line Follower_01.wmv
10742K
BATCH 03
[Texte des messages précédents masqué]
Video_3_of_3_Robotic_Line Follower_02 (un chemin plus difficile).wmv
14569K
Page 1 of 1Groupe ESIGELEC Mail - MSEE12 Project Source Code and Three Videos
2/24/2013https://mail.google.com/mail/u/1/?ui=2&ik=724474b739&view=pt&search=inbox&th...

Emmanuel Chinonye, CHIDINMA <e.chidinma.12@groupe-esigelec.fr>
The Translated Robot Assembly Manual and the MSEE 2012-2013 Project
Report
1 message
Dear Sirs
As part of the MSEE 2012-2013 Project deliverables, please find attached the translated version (from
French to English) of the Robot Aspirateur Assembly Manual. This is the second deliverable.
On Monday 18/02/13, three demonstration videos were handed over to Mr. Vauchey at his office. This
was the first deliverable.
The final deliverable for this project will be the MSEE 2012-2013 Project report, which shall be sent to
you later today.
Kind regards.
Emmanuel Chidinma
Notice_Montage_Robot_SAM_28_10_2012_RK_RR (Anglais).docx
8238K
Page 1 of 1Groupe ESIGELEC Mail - The Translated Robot Assembly Manual and the MSEE 20...
2/24/2013https://mail.google.com/mail/u/1/?ui=2&ik=724474b739&view=pt&search=inbox&th...

Project_Report_Masters

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to Project_Report_Masters

Similar to Project_Report_Masters (20)

More from Emmanuel Chidinma

More from Emmanuel Chidinma (10)

Project_Report_Masters