This document provides a final report on an embedded systems project to build an autonomous line-following buggy. It summarizes the key components of the buggy, including the mechanical design, electronic circuits for line and speed sensing, use of an ultrasonic sensor and RF link, and software programming. It describes the group's organization, budget, testing process, and performance at races, where the buggy placed fifth. Detailed diagrams and the pseudo code used are included in appendices.

1. I
Embedded
Systems
Project
FINAL
REPORT
Group
Number:
6
GROUP
MEMBERS:
Manyu
Dang
9566467
Eric
Mesquita
9568669
Hani
Qadiri
9066907
Vishisht
Tiwari
9109605
Cai
Willis
8473412
Tutor:
Dr
Judith
Apsley
Date:
08/05/2014
School
of
Electrical
and
Electronic
Engineering

2. II
Table of Contents
Embedded
Systems
Project
................................................................................................................
I
1.0
Introduction
....................................................................................................................................
1
1.1
Executive
Summary
.............................................................................................................................
1
1.2
Introduction
.........................................................................................................................................
1
1.3
Aims
and
Objectives
............................................................................................................................
2
2.0
Final
System
Components
Summary
................................................................................................
3
2.1
Mechanical
..........................................................................................................................................
3
2.1.1
Restructured
Components/Features
...........................................................................................
3
2.1.2
Non-­‐Restructured
Components/Features
(Successfully
Working
Components/Features)
..........
3
2.2
Electronic
.............................................................................................................................................
4
2.2.1
Line
Sensing
Circuit
......................................................................................................................
4
2.2.2
Speed
Sensing
Circuit
..................................................................................................................
5
2.2.3
Ultrasound
Sensor
.......................................................................................................................
5
2.2.4
RF
link(Radio-­‐Frequency
Link)
.....................................................................................................
5
2.3
Navigation
and
Control
.......................................................................................................................
6
2.4
Software
..............................................................................................................................................
7
2.2.4
Programming
features
................................................................................................................
7
2.2.4
Challenges
of
programming
........................................................................................................
8
3.0
Team
Organisation
and
Planning
.....................................................................................................
9
4.0
Budget
vs.
Outturn
........................................................................................................................
10
4.1
Proposed
Budget
v/s
Final
Cost
.........................................................................................................
10
4.2
Total
costt
of
Buggy
..........................................................................................................................
11
5.0
Race
Analysis
................................................................................................................................
12
5.1
Testing
...............................................................................................................................................
12
5.1.1
Challenges
during
testing
..........................................................................................................
12
5.2
Preparation
for
first
heat
..................................................................................................................
12
5.3
First
Heat
...........................................................................................................................................
13
5.4
Preparation
for
second
heat
..............................................................................................................
13
5.5
Second
Heat
......................................................................................................................................
13
6.0
Critical
Analysis
.............................................................................................................................
14
7.0
Successful
Innovative
Feature
........................................................................................................
14
8.0
Conclusion
.....................................................................................................................................
15
9.0
References
....................................................................................................................................
15
10.0
Appendix
.....................................................................................................................................
16
10.1
Updated
Engineering
drawing
for
Acetal
chassis
............................................................................
16
10.2
Updated
Engineering
drawing
for
Upper
Plate
of
the
chassis
.........................................................
17
10.3
Updated
Line
Sensor
Board
Diagram
..............................................................................................
18
10.4
Updated
Line
Sensing
Circuit
Board
Diagram
.................................................................................
18
10.5
UpdatedSpeed
Sensing
Board
Diagram
..........................................................................................
19
10.6
UpdatedSpeed
Sensing
Layout
Diagram
.........................................................................................
19
10.7
Updated
Line
Sensing
Circuit
Layout
Diagram
................................................................................
20
10.8
Updated
Line
Sensor
Layout
Diagram
.............................................................................................
20
10.9
Updated
Wiring
Diagram
................................................................................................................
21
10.10
Pseudo
code
..................................................................................................................................
21

3. 1
1.0
Introduction
1.1 Executive Summary
Using
innovative
techniques
such
as
the
inclusion
of
an
ultrasonic
sensor,
an
RF-­‐link
and
by
creating
an
overall
efficiently
compact
design,
Group
6
has
accomplished
the
given
task
of
building
a
line
following
autonomous
buggy.
This
documentation
is
an
in
depth
evaluation
of
the
methods
used
to
complete
this
given
primary
task.
Included
are
detailed
sections
of
how
this
was
accomplished
from
the
mechanical,
electrical,
navigational
strategy
and
software
aspects
of
the
buggy.
The
successes
and
the
failures
of
the
chosen
strategies
faced
during
the
design
and
assembling
processes
are
discussed
and
the
solutions
conceived
to
solve
them.
By
comparing
the
group’s
project
plan
as
proposed
in
the
proposal
and
the
final
outcome
of
the
buggy,
the
effectiveness
of
the
overall
group
work
is
demonstrated.
Furthermore,
a
detailed
report
is
given
on
the
budget,
how
much
the
buggy
was
proposed
to
cost,
the
difference
in
the
outcome
price
and
the
reasons
for
the
increase
in
price.
Finally,
there
is
a
detailed
analysis
on
how
the
buggy
was
prepared
for
the
race
and
exploring
the
possible
reasons
for
its
performance.
Overall,
the
buggy
was
ranked
at
fifth
place
with
two
times
at
8.3
and
7.1
seconds,
when
a
faster
time
was
expected.
During
the
first
semester,
the
group
worked
towards
the
completion
of
the
overall
mechanical
design
and
planning
for
the
manufacture
of
the
buggy.
The
main
obstacles
were
extracted
from
the
handbook
and
the
group
used
these
to
determine
the
design
of
the
buggy.
An
example
of
this
would
be
the
vital
information
of
the
allocated
distance
at
the
end
of
the
track
within
which
the
buggy
had
to
come
to
a
stop.
An
ultrasonic
sensor
was
used
to
give
the
buggy
sufficient
means
of
stopping
within
the
desired
space.
The
properties
of
the
gearbox
were
determined
to
obtain
the
desired
torque.
Research
was
undertaken
to
determine
the
sensors
required
for
the
optimum
race
performance
from
the
buggy.
The
first
half
of
the
second
semester
was
used
to
fully
manufacture
the
buggy.
Separately
assembling
the
different
aspects
of
the
buggy
–
mechanical,
electronic
and
even
software
–
and
then
combing
together
to
create
a
fully
functioning
system,
that
meet
the
requirements
of
the
project
deliverables.
From
week
7,
full
concentration
was
given
to
the
completion
of
the
buggy’s
software
to
implement
an
effective
PID
control
that
would
navigate
the
buggy
around
the
course
in
the
quickest
possible
time.
Overall,
the
group
was
able
to
achieve
all
aims;
except
reaching
the
finals.
1.2 Introduction
During
semester
2,
group
6
has
been
working
towards
fully
completing
the
manufacturing
and
software
for
the
buggy,
so
that
it
is
sufficiently
ready
to
give
an
excellent
performance
on
the
day
of
the
heats.
Unfortunately,
despite
the
hard
work
and
dedication
shown
by
the
group
members,
group
6’s
buggy
–
The
Flying
Duchess
–
did
not
qualify
for
the
final
race.
The
buggy
was
designed
to
be
compact,
with
a
slick,
neat
design
that
distributes
the
weight
sufficiently
to
keep
the
buggy
well
balanced
with
a
low
centre
of
gravity.
PID
control
was
used
to
navigate
the
buggy
around
the
track,
which
will
be
discussed
in
further
detail
in
the
software
aspect
of
the
Final
Components
Summary.
Having
efficiently
used
the
allocated
time
in
the
lab
per
week,
personal
time
and
the
supervisors’
help
to
overcome
certain
problems
with
the
RF-­‐Link,
a
buggy
was
built
that
met
the
criteria
set
by
the
group
and
the
project’s
demands.
Fig. 1. Overview photo of the buggy

4. 2
1.3 Aims and Objectives
The
group
was
given
the
initial
task
to
build
a
line
following
autonomous
buggy
able
to
manoeuvre
obstacles
of
a
constructed
course.
Following
are
the
projects
demands
for
the
specifications
of
the
desired
buggy:
• Driven
by
batteries
• Navigate
by
identification
of
a
white
line
• Capable
of
turning,
going
up
the
slope,
going
over
the
small
line
gap
• Successful
navigation
of
a
full
track
by
overcoming
obstacles
by
using
six
sensors
only
• Stopping
within
the
allocated
distance
• Remaining
within
a
budget
of
£50
With
the
project
demands
in
mind,
an
overall
of
four
primary
aims
were
set
by
the
group:
1. Build
a
line
following
buggy
2. Competitively
complete
a
given
course
in
order
to
reach
the
finals
3. Use
only
6
line
sensors
or
less,
abiding
to
the
given
constraint
4. Use
innovative
solutions
to
decrease
the
overall
buggy
size
and
number
of
line
sensors
used,
whilst
maintaining
a
highly
efficient
product
able
to
meet
the
specifications
of
the
given
task
The
following
deadlines
were
set
as
part
of
the
overall
embedded
systems
project:
1. Tech
demo
#1
-­‐
Demonstration
of
a
functional
speed
sensing
circuit
2. Design
report
#1
-­‐
a
technical
report
discussing
the
required
combination
of
gears,
based
on
test
results
and
calculations
from
the
motor
characterisation
lab
3. Design
report
#2
–
a
technical
report
discussing
the
given
choice
and
arrangement
of
sensors,
the
design
of
the
sensor
interface
circuits
and
the
chosen
strategy
track
navigation
4. Proposal
report
–
An
official
documentation
proposing
the
buggy
as
a
solution
to
meet
the
desired
specifications,
intending
to
receive
funding
for
the
project
5. Tech
demo
#2
–
Demonstration
of
functioning
motor
control
6. Tech
demo
#3
–
Demonstration
of
line
sensing,
by
visually
presenting
the
reactions
of
the
line
sensors
used
7. Tech
demo
#4
–
Demonstration
of
the
buggy
following
a
white
line
against
a
dark
surface,
not
as
demanding
as
the
heats
or
the
final
race,
however,
just
a
simple
demonstration
that
the
buggy
is
able
to
follow
a
line
8. Tech
demo
#5
–
The
Heats,
a
three
part
course
determining
the
buggies
sufficient
to
compete
in
the
final
race
on
the
harder
race
track
9. The
Final
Race
–
competing
for
the
fastest
time
of
completion
around
a
given
course
containing
several
obstacles
such
as
a
see-­‐saw
ramp
and
a
windy
slope
These
soft
deliverables
were
at
the
core
of
the
group’s
project
plan.
They
were
used
as
a
rough
guideline
to
set
goals,
objectives
and
helped
determine
deadlines
for
the
completion
of
different
aspects
of
the
buggy.
Using
the
list
of
aims,
the
project
demands
and
the
required
deliverables,
the
following
objectives
were
set:
-­‐ Designing
and
building
an
accurate
speed
sensing
circuit
to
be
implemented
in
the
buggy
-­‐ Designing
a
chassis
that
is
well
within
the
track
width
decreasing
the
risk
of
impact
with
the
boundaries
-­‐ Designing
a
battery
box
that
encloses
the
batteries
safely
ensuring
they
will
not
fall
out
during
either
the
heats
or
the
race
-­‐ Designing
the
necessary
PCBs
for
the
speed
sensing
and
line
sensing
circuit,
that
will
be
efficient
in
practical
use
and
space
-­‐ Assembling
the
buggy
–
putting
together
each
complete
aspect
of
the
buggy
(the
mechanical
and
the
electronic)

5. 3
-­‐ Writing
a
C
program
implementing
PID
control
that
will
sufficiently
navigate
the
buggy
around
the
course
following
the
white
line
-­‐ Using
the
allocated
time
in
labs
to
the
highest
degree
of
efficiency
to
meet
the
deadlines
set
both
personally
for
the
group,
and
the
overall
deadlines
set
for
the
project
(as
stated
above)
-­‐ Budgetary
planning
to
ensure
that
the
group
does
not
spend
over
the
give
budget
of
£50
2.0
Final
Systems
Components
Summary
2.1 Mechanical
The
mechanical
aspect
of
the
buggy
went
through
a
major
overhaul
during
the
second
semester
of
the
project.
The
buggy
now
consisted
of
two
levels
of
acetal
plates
carrying
different
components.
The
first
level(bottom
plate)
was
fitted
with
the
motor
drive
board
and
the
battery
box
while
the
second
level(upper
plate)
was
fitted
with
the
RF
link,
microcontroller
board
and
breakout
board.
Battery
Box
is
another
innovative
feature
that
was
introduced
in
the
second
semester
of
the
buggy
to
carry
and
replace
batteries
in
an
easy
yet
safe
way.
However,
few
features
of
the
buggy
such
as
placement
of
line
sensing
circuit
board
between
the
two
front
wheels
and
gear-­‐ratio
worked
well
for
the
purpose
of
line
following,
climbing
up
the
slope
and
descending
down
the
slope
and
hence
was
continued
to
be
used
in
the
buggy.
2.1.1 Restructured Components/Features
Components
that
did
not
work
as
planned
and
have
gone
through
restructuring
during
the
second
semester
have
been
discussed
below
in
detail:
Chassis:
The
chassis
width
size
was
decreased
in
order
to
improve
the
maneuverability
and
reduce
the
probability
of
the
buggy
crashing
into
pinch-­‐points.
Also,
the
modified
shape
of
the
chassis
is
symmetrical
which
provided
a
better
balance
to
the
buggy.
Front
Wheels
Initially,
the
group
planned
to
use
a
caster
wheel
for
the
front
wheel,
believing
it
to
easily
adapt
to
a
change
in
direction.
After
comparing
with
the
other
components
provided
in
the
workshop,
it
was
decided
instead
to
use
0.5”
ball
bearing
as
the
front
wheel.
This
was
due
to
two
main
reasons;
first,
the
weight
of
ball
bearing
is
lighter
than
the
caster
wheel,
reducing
the
overall
load
of
the
buggy.
Secondly,
after
testing,
it
was
found
that
the
ball
bearing
could
provide
smoother
turning
than
the
caster
wheel.
Battery
Box:
According
to
the
proposal
report,
the
battery
pack
was
supposed
to
be
on
the
upper
plate
of
the
buggy.
However,
having
decided
to
add
an
RF
link
board,
there
was
no
longer
enough
space
on
the
upper
plate.
The
group
sat
down
together
to
discuss
how
to
overcome
the
problem
at
hand,
which
was
where
to
place
the
batteries.
It
was
concluded
by
agreeing
to
place
the
batteries
inside
a
box
that
would
be
sturdy
enough
to
not
open
in
the
middle
of
a
race
and
that
could
be
easily
opened
when
needs
be
to
recharge
the
batteries.
The
battery
box
was
placed
at
the
bottom
of
the
chassis,
and
since
its
weight
was
quite
large,
this
change
also
lowered
the
centre
of
gravity
of
the
buggy,
making
it
more
stable
in
a
dynamic
system.
2.1.2 Non-­‐Restructured Components/Features (Successfully Working Components/Features)
Few
components
in
the
buggy
worked
the
way
they
were
expected.
These
provided
an
added
advantage
to
the
buggy
and
hence
were
continued
to
be
used
in
the
buggy:

6. 4
Gears:
In
the
proposal
report,
it
was
determined
that
the
gear
ratio
of
1:15.6
would
be
the
optimum
in
gear
ratio
for
providing
enough
torque
to
go
up
the
slope
and
enough
speed
on
the
straights.
Gears
to
be
used
for
the
construction
of
the
gearbox
were:
16
tooth
pinions
(motor
shaft
only);
50/10
free
running
gear
(grey);
50/10
press
fit
gear
(red).
This
gear
combination
provided
the
right
balance
between
torque
and
speed
and
hence
was
continued
to
be
used
in
the
buggy.
Sensor
Board
Placement:
Placement
for
the
sensor
board,
in
the
proposal
report,
was
decided
to
be
between
the
two
front
wheels.
This
feature
was
expected
to
provide
greater
accuracy
of
line
sensing,
as
the
sensors
would
be
able
to
detect
any
slope
changes
in
the
course
without
losing
the
track.
This
feature
also
worked
as
expected
and
was
continued
to
be
used
in
the
buggy.
The
board
however
was
divided
into
two
different
PCBs.
One
contained
the
sensors
while
the
other
contained
the
circuit
for
the
sensors.
2.2 Electronic
The
electronic
circuits
used
in
the
buggy
did
not
see
such
a
drastic
overhaul
like
the
mechanical
components
of
the
buggy
did.
However,
one
change
from
the
proposal
report
was
the
use
of
PCBs
instead
of
stripboard.
All
the
circuits
used
in
the
buggy
including
line
sensor
board,
speed
sensor
board
and
circuit
board
were
all
designed
on
Altium
software
and
then
constructed
on
PCBs.
This
decision
was
taken
after
analysing
the
reliability,
clean
and
easy
arrangement,
and
quality
of
the
PCBs.
Each
electronic
component
of
the
buggy
has
been
discussed
in
detail
as
follows:
2.2.1 Line Sensing Circuit
As
discussed
in
the
proposal
report,
the
TCRT5000L,
a
Reflective
Optical
Sensor
with
Transistor
Output,
remained
as
the
line
sensor
in
use
for
the
line
sensing
circuit.
This
choice
was
made
having
tested
all
other
potential
sensors.
This
sensor
proved
to
be
the
most
sensitive
to
reflective
differences
in
track
surfaces
i.e.
it
was
the
most
effective
at
detecting
the
white
line.
Furthermore,
it
was
self-­‐illuminating,
containing
an
IR
emitter
as
well
as
receiver,
in
a
compact
case
reducing
the
space
needed
for
the
circuit.
5
of
these
sensors
were
used
for
the
purpose
of
line
following
and
were
arranged
as
shown
in
figure
6.
The
circuit
for
all
the
sensors
was
unchanged
from
proposal
report.
A
100Ω
resistor
was
used
to
convert
the
maximum
amount
of
light
intensity
so
that
the
maximum
forward
current
is
60mA.
A
4.7kΩ-­‐resistor
was
used
in
series
with
the
phototransistor,
configured
as
a
potential
divider
to
work
out
the
maximum
difference
in
output
values
obtained
when
sensing
white
and
black
surfaces.
For
digital
sensors,
comparator
LM311
was
used
to
convert
the
output
from
sensors
to
logic
level
0
or
1
where
0
logic
level
means
black
surface
while
1
logic
level
means
white
surface.
The
circuit
diagram
for
Digital
sensors
has
been
shown
in
figure
3.
A
full
circuit
diagram
for
all
line
sensors
can
be
found
in
appendix10.3
and
10.4.
Fig. 3. Circuit Diagram for Digital Sensors
Fig. 2. Gearbox
R1
100Ω
R2
4.7kΩ
TCRT5000L
VSS
5V
LM311N-14
B/STBVS+
GND
BAL
VS-
3
4
6
11
9
2
7 839kΩ
100kΩ
Key=A
10 %
300kΩ
Output

7. 5
The
sensors
were
connected
to
the
breakout
interface
(PORTA
&PORTJ)
as
shown
in
the
wiring
diagram
in
appendix
10.9.
The
analogue
sensors
were
used
as
analogue
inputs(PORTA)
to
implement
the
PID
control
while
the
digital
sensors
were
used
as
digital
inputs(PORTJ).
When
designing
the
PCB
for
the
line
sensor
circuit,
it
was
separated
into
two
boards
where
one
contained
five
sensors
section
while
the
other
contained
the
rest
of
the
circuit.
This
change
increased
the
space
efficiency
on
the
buggy
and
also
meant
there
was
enough
space
for
the
ultrasonic
sensor.
The
two
PCBs
were
connected
using
Molex
connector.
An
image
of
the
line
sensing
circuit
has
been
shown
in
figure
4.
2.2.2 Speed Sensing Circuit
The
circuit
for
the
speed
sensing
from
the
proposal
report
has
been
unchanged.
For
the
speed
sensing
circuit,
the
IR
emitter
TEKT5400s
and
IR
receiver
TEKS5200s
was
used.
The
emitter
is
connected
100Ω
resistor
and
receiver
is
connected
to
4.7kΩ
resistor.
The
output
is
connected
to
PORTB
in
the
breakout
interface
board.
The
left
wheel
speed
sensor
circuit
and
right
wheel
speed
sensor
circuit
were
integrated
into
one
PCB
to
save
space.
The
circuit
diagram
for
speed
sensing
circuit
can
be
found
in
appendix
10.5.
2.2.3 Ultrasonic Sensor
The
new
electronic
innovation
that
has
been
introduced
in
the
buggy
in
second
semester
is
the
introduction
of
the
ultrasound
sensor.
This
was
a
new
idea
and
was
never
discussed
in
the
proposal
report.
The
high
mass
and
hence
high
momentum
at
high
speed
was
proving
it
to
be
difficult
for
the
buggy
to
stop
within
the
defined
range
of
20cms.
The
ultrasonic
sensor
was
used
to
allow
the
buggy
to
go
at
a
higher
duty
cycle
whilst
still
having
the
capability
to
stop
at
the
end
of
the
track.
It
works
by
transmitting
an
ultrasound
wave,
which
is
then
reflected
directly
back
from
the
barrier
at
the
end
of
the
track.
Since
the
speed
of
the
sonic
wave
is
known
it
can
be
used
to
calculate
the
distance
to
the
barrier,
assisting
the
line
and
speed
sensors
to
provide
a
higher
level
of
precisions
and
navigational
control.
2.2.4 RF-­‐Link (Radio-­‐frequency link)
An
RF-­‐link
(Radio-­‐frequency
Link)
was
also
implemented
allowing
for
wireless
control
under
a
specific
frequency.
The
RF-­‐link
contains
the
microchip
MRF24J40MB
module,
which
uses
the
microchip
MIWI
protocol.
The
SPI
port
is
used
to
transfer
data
between
the
PIC
and
the
MRF24J40MB;
as
a
result
the
position
information
can
be
identified
and
manipulated.
The
controller
for
the
buggy
was
made
using
the
I/O
board
used
in
the
microcontroller
project
in
1st
year.
The
potentiometer
in
the
I/O
board
was
used
for
varying
straight-­‐line
speed
while
two
push
buttons
were
used
for
turning
the
buggy.
Another
toggle
switch
was
used
to
change
the
buggy
from
line
following
mode
to
remote
control
mode
in
case
it
needed
to
be
used
for
the
final
race.
The
8
LEDs
and
7-­‐segment
display
on
the
I/O
board
were
used
as
a
debugging
tool.
Important
information
such
as
speed
of
both
the
motors,
the
sensitivity
of
the
sensors
etc.
was
obtained
easily
using
RF.
Values
of
integral
and
derivative
helped
to
get
the
PID
control
of
the
buggy
better
and
made
the
programming
process
much
easier.
Fig. 4. Two different PCBs for line sensors
5
Fig. 5. Ultrasonic Sensors HC-SR04

8. 6
2.3 Navigation and Control
The
final
navigation
system
implemented
on
the
buggy
is
demonstrated
by
figure
6.
Navigation
is
executed
via
five
TCRT5000L
optical
sensors
used
to
determine
the
buggy’s
position
on
the
line
and
aid
in
tackling
obstacles
of
the
course.
The
sensor
bank
consists
of
a
central
digital
sensor,
two
analogue
sensors
and
two
outer
digital
sensors
positioned
less
than
a
line
width
away
from
each
analogue
sensor
to
aid
in
regaining
a
lost
line.
Requirements
for
the
navigation
system
were
determined
by
a
list
of
likely
and
worst
case
scenarios
that
the
buggy
might
encounter
such
as
sharp
turns,
line
breaks,
long
fast
straightways
and
the
end
of
the
track.
The
analogue
sensors
either
side
of
the
line
are
capable
of
providing
readings
sufficient
to
determine
relative
position
of
the
line
and
provide
a
basis
to
implement
some
variation
of
PID
control.
These
sensors
are
read
by
the
PIC18F8722’s
analog
to
digital
converter,
compared
and
used
in
calculations
to
maintain
a
steady
path
along
curves
and
increase
speed
along
straight
sections
of
the
track.
The
outputs
of
the
digital
sensors
are
fed
into
comparators
in
order
to
create
a
digital
signal
to
be
read
by
the
microcontroller.
The
sensitivity
of
the
comparators
can
be
adjusted
via
a
potentiometer.
The
central
digital
sensor
is
therefore
sensitive
enough
to
maintain
a
perception
of
the
line
across
the
maximum
line-­‐break
distance.
This
sensor
is
also
used
in
deducing
the
true
end
of
the
line.
The
outer
digital
sensors
are
intended
for
situations
in
which
the
buggy
has
strayed
too
far
either
side
of
the
line
or
even
left
the
line
completely.
In
the
case
of
either
of
the
outer
digital
sensors
being
the
last
sensor
to
give
a
reading,
the
buggy
will
continue
turning
until
the
line
has
been
found
again.
The
initial
design
for
the
layout
of
the
sensors
given
in
the
proposal
report
is
shown
in
figure
7.
Some
subtle
changes
have
been
made
to
the
layout
of
the
sensors
and
very
little
has
been
altered
in
terms
of
overall
navigation
strategy.
The
first
change
made
was
to
remove
the
second
digital
line
sensor
as
it
was
discovered
that
the
cone
of
light
emitted
by
a
single
TCRT5000L
sensor
was
sufficiently
large
to
maintain
a
signal
across
the
biggest
gap
when
the
sensitivity
of
the
comparator
circuit
was
adjusted.
The
second
central
digital
sensor
was
rendered
obsolete
and
could
thus
be
omitted,
simplifying
the
control
program
somewhat
with
no
effect
on
performance.
The
positioning
of
the
sensors
was
also
adjusted,
bringing
the
analogue
sensors
closer
towards
the
center
and
adjusting
the
outer
digital
sensors
accordingly
so
that
they
too
were
closer
to
the
center
and,
crucially,
less
than
the
line’s
width
away
from
the
analog
sensors.
The
analogue
sensors
are
now
12mm
from
the
center
and
the
outer
digital
sensors
are
18mm
from
the
respective
analogue
sensors.
The
original
design
had
a
sensing
dead
zone
physically
built
in
to
Fig. 6. Present Sensor arrangement
Fig. 7. Past Sensor
arrangement

9. 7
the
sensor
array,
and
the
adjustment
was
made
to
allow
a
dead
zone
to
be
implemented
or
adjusted
as
required
in
software.
The
outer
digital
sensors
were
originally
intended
only
to
provide
an
increased
response
in
the
case
of
the
analogue
sensors
using
the
line,
but
are
also
now
used
in
regaining
the
position
of
the
line
once
it
is
lost.
In
addition
to
the
sensor
bank,
the
buggy
uses
a
HC-­‐SR04
ultrasound
sensor
placed
at
the
front
of
the
chassis
which
is
intended
to
inform
the
microcontroller
that
a
barrier
is
close
in
front
and
that
the
buggy
should
slow
down.
This
ensures
that
the
buggy
is
able
to
stop
within
the
required
20cm,
and
is
potentially
also
useful
in
slowing
the
buggy
for
sharp
corners.
2.4 Software
Software
programming
was
one
of
the
most
integral
and
important
part
of
the
project.
Using
the
sensor
outputs
to
make
the
buggy
follow
the
line
was
accomplished
with
the
help
of
software
programming.
The
main
aim
of
the
buggy
was
to
follow
the
line
without
the
unnecessary
oscillations,
take
the
turn
smoothly
and
use
speed
sensing
to
be
able
to
go
up
a
slope.
As
an
extra
feature,
the
buggy
also
had
an
RF
link
board
fitted
to
it
and
could
be
controlled
using
a
remote
control.
2.4.1 Programming Features
The
main
features
of
programming
of
the
buggy
has
been
discussed
below:
Line
Following:
All
the
line
sensors
were
used
for
the
purpose
of
following
line.
As
seen
from
figure
6,
the
middle
digital
sensor
was
used
to
detection
of
the
end
of
the
line.
The
analogue
sensors
main
objective
was
to
reduce
the
oscillations
in
a
straight
line
and
provide
a
smooth
turning
at
curves.
The
last
digital
sensors
were
programmed
to
be
used
as
a
overshooting
sequence.
In
case
the
looses
the
line
at
a
corner,
the
buggy
was
programmed
to
come
back
to
the
line
but
middle
sensor
still
helped
it
to
stop
in
the
end
of
the
line.
For
reducing
the
oscillations
PD(Proportional-­‐Derivative)
controller
was
used.
The
PD
controller
obtained
error
from
the
middle
two
analogue
sensors
and
controlled
the
duty-­‐cycle
to
the
motor
to
obtain
oscillation
free
and
fast
movement
of
the
buggy.
The
proportional
was
used
for
turning
while
the
derivative
was
used
for
reducing
the
oscillations.
The
proportional
part
of
the
control
systems
worked
by
multiplying
the
error
by
a
certain
value
to
be
able
to
make
a
turn.
The
derivative
on
the
other
hand
finds
the
difference
between
last
error
and
present
error
and
tries
to
minimize
this
difference.
PD
control
instead
of
PID
control
was
decided
to
use
as
it
was
observed
that
I(integral)
control
did
not
contribute
towards
either
reducing
oscillations
or
improving
buggy
control
and
hence
was
not
used.
Speed
Sensing:
Maintaining
a
constant
speed
up
and
down
the
slope
was
an
important
requirement
for
the
buggy
to
be
able
to
complete
the
track.
Losing
or
gaining
speed
on
a
slope
could
result
in
increased
oscillations
of
the
buggy
and
hence
losing
the
line.
For
this
purpose
speed
sensing
was
an
important
part
of
the
buggy.
Speed
sensing
was
implemented
by
using
interrupts.
Every
rising
edge
caused
an
interrupt
and
incremented
the
counting.
After
every
half
a
second
this
value
was
obtained,
RPM
was
calculated
and
speed
was
changed
accordingly.
The
error
obtained
used
a
P(Proportional)
controller
to
control
the
speed.
RF
link:
Another
extra
feature
of
remote
control
was
added
in
the
buggy
in
case
it
was
not
able
to
complete
any
specific
part
of
the
final
track.
The
controller
for
the
buggy
was
made
using
the
I/O
board
used
in
the
microcontroller
project
in
1st
year.
The
potentiometer
in
the
I/O
board
was
used
for
varying
straight-­‐line
speed
while
two
push
buttons
were
used
for
turning
the
buggy.
Another
toggle
switch
was
used
to
change
the
buggy
from
line
following
mode
to
remote
control
mode
in
case
it
needed
to
be
used
for
the
final
race.

10. 8
2.4.2 Challenges of Programming
Achieving
the
right
values
for
Kp(proportional
constant),
Ki(Integral
Constant)
and
Kd(derivative
constant)
in
PID(Proportional-­‐Integral-­‐Derivative)
control
for
line
following:
Achieving
right
values
of
Kp,
Ki
and
Kd
in
PID
control
was
important
in
implementation
of
oscillation
less
and
fast
movement
of
the
buggy.
Calculating
Kp,
Ki
and
Kd
using
trial
and
error
was
one
of
the
most
difficult
part
of
the
programming
and
needed
many
iterations
before
achieving
the
right
values.
It
is
important
to
note
that
the
values
in
table
has
been
deduced
for
70%
straight-­‐line
duty-­‐cycle
of
the
buggy.
The
values
have
to
be
tweaked
for
changing
duty-­‐cycle.
During
the
initial
tests,
very
high
oscillations
and
large
turning
radius
were
observed.
The
oscillations
were
reduced
by
increasing
the
values
of
Kd.
It
was
observed
that
increasing
Ki
or
Kd
to
a
very
high
value
increased
oscillations
as
well.
Increasing
Kp
values
reduced
the
turning
radius
and
helped
the
buggy
take
sharper
turns
with
ease
and
speed.
It
was
also
observed
that
Ki
did
not
contribute
towards
reducing
turning
radius
and
in
some
cases,
worsened
the
oscillations.
Hence
it
was
decided
to
not
use
integral
control
and
manoeuvre
the
buggy
using
just
PD
control
with
Kp
value
as
21
and
Kd
value
as
132.
It
is
important
to
note
the
values
of
Kd
was
tweaked
according
to
changing
duty-­‐cycle.
Increasing
duty-­‐
cycle
led
to
increased
Kd
value
to
maintain
the
low
oscillations
Implementing
RF
link
and
speed
sensing
simultaneously:
Both,
RF
link
and
speed-­‐sensing
used
interrupts
and
implementing
both
the
features
without
interfering
with
the
movement
of
buggy
was
proving
difficult
to
achieve.
The
buggy
seemed
to
get
stuck
in
a
loop
of
RF
and
would
not
come
out
of
the
loop
unless
the
programme
is
reset.
It
was
found
that
the
loop
involved
transmitting
data
from
the
buggy.
It
was
deduced
that
‘if
speed-­‐sensing
is
used
then
the
buggy
would
not
be
able
to
send
data
to
remote
control
and
hence
the
remote
control
would
not
be
able
to
used
as
a
debugging
tool’.
This
problem
could
not
be
solved
and
a
decision
was
taken
to
use
remote-­‐
control
as
a
debugging
tool
only
when
needed.
At
all
other
times
the
speed
sensing
would
work
in
which
the
remote
control
will
still
be
able
to
control
the
buggy
but
would
not
be
able
to
receive
any
data
from
the
buggy.
Implementing
overshooting
sequence:
Another
challenge
for
the
buggy
was
to
take
very
sharp
turns
at
high
speeds.
This
was
normally
the
case
of
an
s-­‐bend
after
a
long
straight.
To
be
able
to
overcome
this
problem,
an
overshooting
tool
was
used
in
the
buggy.
According
to
this
feature,
if
the
buggy
left
the
white
line
at
a
corner
then
the
end
digital
Kp
Ki
Kd
Oscillation
Turning
Radius
2
0.4
0.1
Very
High
Oscillations
Large
Radius
5
0.4
0.5
Very
High
Oscillations
Large
Radius
10
0.8
2
Very
High
Oscillations
Medium
Radius
15
0.8
10
High
Oscillations
Medium
Radius
18
0.8
30
Medium
Oscillations
Small
Radius
20
0.8
50
Medium
Oscillations
Small
Radius
20
2
50
High
Oscillations
Small
Radius
20
0.8
90
Medium-­‐Low
Oscillations
Small
Radius
20
0.8
120
Low
oscillations
Small
Radius
20
0.8
130
Very
Low
Oscillations
Small
Radius
20
0.8
140
Medium
Oscillations
Small
Radius
20
0.8
132
Almost
No
Oscillations
Small
Radius
21
0
132
Almost
No
Oscillations
Small
Radius
Table. 1. Different values of PID constants and their effects
5

11. 9
sensors
would
be
the
last
sensor
to
have
sensed
the
line.
In
this
case,
the
buggy
would
try
to
re-­‐join
the
line.
However,
if
any
of
the
middle
3
sensors
were
the
last
sensors
to
sense
the
white
line,
then
the
buggy
would
consider
that
as
the
end
of
the
line
and
would
stop.
3.0
Team
Organisation
and
Planning
In
terms
of
requirements,
it
was
quickly
determined
that
the
project
could
be
divided
into
mechanical,
hardware
and
software
components.
Each
component
could
be
further
subdivided
into
specific
tasks
such
as
assembly
of
the
battery
box
and
gearbox
for
the
mechanical
aspect,
design
and
soldering
of
PCBs
as
hardware
tasks,
and
so
on.
Collective
decision
of
dividing
the
work
among
the
group
members
was
taken.
Each
group
member
discussed
the
aspect
they
were
interested
in
and
accordingly
work
was
divided
among
the
members.
During
all
times,
2
group
members
were
focused
on
the
software
programming
of
the
buggy
while
other
3
members
worked
on
mechanical
and
electronic
aspects
if
the
buggy.
The
group
had
set
different
goals
for
completing
all
the
mechanical,
electronic
and
software
requirements.
The
mechanical
aspect
of
the
buggy
such
as
the
gearbox,
the
chassis
etc.
was
aimed
to
be
finished
by
the
3rd
week
while
the
electronic
parts
such
as
the
sensor
PCB,
speed
sensing
PCB
etc.
was
aimed
to
be
finished
by
6th
week
of
the
second
semester.
Software,
on
the
other
hand,
was
worked
on
during
the
whole
semester.
Fig. 8. Gantt Chart
5

12. 10
Each
member
was
shared
into
sub-­‐groups
to
tackle
each
component
while
interacting
regularly
and
reporting
to
the
others.
Communication
was
conducted
via
WhatsApp,
thus
quick
meetings
could
be
called
at
short
notice,
which
proved
to
be
a
very
efficient
process.
All
the
data
including
PCB
files,
software
codes,
solidworks
file
were
at
all
times
uploaded
to
the
common
Dropbox
account
and
was
updated
as
soon
as
any
changes
were
made.
The
available
laboratory
sessions
were
used
to
full
affect
with
the
group
split
between
each
of
the
three
laboratories
depending
on
their
specific
tasks.
Meetings
were
often
held
outside
laboratory
sessions
to
consolidate
the
work
done
in
each
component
and
for
each
group
member
to
gain
and
provide
insight
in
every
aspect
of
the
buggy.
Due
to
regular
communication
and
the
enthusiasm
of
the
group
in
general,
it
was
possible
for
every
group
member
to
be
involved
in
design
decisions
such
as
PCB
placement
and
chassis
construction.
Towards
the
end
of
the
semester,
when
the
buggy’s
construction
was
complete
and
only
software
testing
remained,
very
few
construction
and
design
modifications
were
required,
which
meant
that
some
group
members
were
left
with
little
to
do
during
laboratory
sessions.
This
was
resolved
by
the
decision
to
start
the
writing
of
the
final
report
early
so
that
all
group
members
could
contribute
to
the
project
when
the
hardware
and
design
aspects
of
the
project
were
completed.
Regular
meetings
were
still
held
to
discuss
the
buggy’s
progress
and
make
alterations
as
required.
The
Gantt
chart
constructed
in
semester
1
shown
in
figure
8
remained
largely
accurate
in
terms
of
its
overall
scope.
Work
in
the
laboratory
sessions
was
always
geared
towards
completing
the
next
technical
demonstration
and
each
of
the
deadlines
was
successfully
achieved
on
or
before
the
specific
date.
The
group’s
achievement
of
consistently
high
marks
in
all
technical
demonstrations
supports
this.
The
only
major
difference
in
the
proposed
organisation
shown
in
the
Gantt
chart
and
its
realisation
is
the
number
of
hours
spent
on
each
task.
The
group
consistently
went
above
and
beyond
what
was
merely
“required”
by
the
task
in
order
to
perfect
everything
from
the
construction
of
a
battery
box
to
drilling
holes
and
using
cable
ties
to
keep
the
wiring
looking
neat.
Another
difference
was
that
the
buggy’s
control
software
was
started
from
the
very
beginning
of
the
project
and
was
developed
alongside
the
software
required
for
technical
demonstrations.
4.0
Budget
vs.
Outturn
4.1 Proposed Budget v/s Final Cost
Comparing
changing
item
price
table
Proposal
report
Final
report
Item
Quantity
Individual
price
(£)
Total
cost
(£)
Item
Quantity
Individual
price
(£)
Total
cost
(3)
Acetal
board
3
(total
200mm*2
00mm)
0.575
(per
m!
)
2.3
Acetal
board
11
(total
350mm*3
00mm)
0.575
(per
m!
)
6.1
Strip
board
2
2
4
PCB
board
4
3
12
Caster
wheel
2
2
4
Ball
bearing
2
1
2
Line
sensor
TCRT500
0
6
0.5
3
Line
sensor
TCRT5000
5
0.6
3
RF-­‐link
board
1
4
4
Ultrasonic
sensor
1
2.5
2.5
Total
£13.3
Total
£29.6
Table.2. Comparing changing item price table
5

13. 11
The
reason
for
the
difference
between
the
outturn
and
proposal
cost
is
mainly
due
to
the
increase
in
the
mechanical
cost.
This
is
because
a
lot
of
acetal
was
used
for
creative
designs
to
solve
some
of
the
design
problems
faced.
One
example
being
the
battery
box;
an
enclosure
that
could
withstand
stress
and
protect
the
batteries
during
the
course
of
the
track
effectively
whilst
still
being
easily
accessible
was
needed,
and
so
a
boxed
compartment
was
made
for
them
out
of
acetal.
Replacing
strip
board
with
PCB
also
increased
the
overall
cost.
The
addition
of
the
RF
link
and
the
ultrasonic
sensor
was
decided
later
in
the
design
process,
and
so
increased
the
outturn
cost.
Despite
these
changes
resulting
in
a
higher
overall
cost,
it
resulted
in
a
buggy
that
is
believed
to
be
more
effective
and
efficient
at
meeting
the
aims
set
at
the
beginning
of
the
project.
4.2 Total cost of the buggy
Outturn
final
report
Item
Quantity
Individual
price
(£)
Total
cost
(£)
Acetal
board
11
(totally
350mm*300mm)
57.5
(per m!
)
6.1
PCB
board
4
3
12
Ball
bearing
2
1
2
Line
sensor
TCRT5000
5
0.6
3
IR
emitter
sensor
TSKT5400S
2
0.5
1
RF-­‐link
board
1
4
4
Ultrasonic
sensor
1
2.5
2.5
Resisters
&
Capacitors
(various
value)
50
0.03
1.5
Comparator
6
0.02
1.2
Molex
pin
header
5
0.02
0.1
Screw
30
0.02
0.6
Nut
30
0.02
0.6
Washer
10
0.03
0.3
Gear
2
sets
Workshop
item
Drive
board,
breakout
interface,
micro-­‐control
board
1
Workshop
item
Batteries
and
battery
pack
1
Workshop
item
Motor
2
Workshop
item
Total
£34.9
£32
Because
the
budget
is
strictly
limited
£50,
other
methods
were
found
to
make
sure
the
budget
does
not
exceed.
This
included
using
recycled
items
available
in
the
labs
such
as
nuts,
screws,
washers
etc.
Assuming
the
items
mentioned
above
are
recyclable,
the
overall
final
outturn
is
approximately
£32
and
not
£34.9
For
manufacturing
100
buggies,
it
will
be
assumed
that
no
recyclable
items
will
be
used.
Hence
cost
of
100
buggies
would
be
100
x
£34.9
=
£3490
Table.3. Total Budget table
5

14. 12
5.0
Race
Analysis
5.1 Testing
Testing
of
the
buggy
mainly
involved
achieving
the
right
values
of
Kp
and
Kd
for
achieving
minimum
oscillations
and
fast
movement.
As
discussed
in
table
1,
many
iterations
of
trial
and
errors
were
done
to
achieve
the
Kp
value
of
21
and
Kd
value
of
132.
With
these
values,
the
buggy
was
able
to
achieve
smooth
turns
and
high
speed
in
straight
lines
in
different
rooms
with
different
ambient
light.
Another
important
testing
criteria
was
to
decide
the
use
of
speed-­‐sensing
circuit
and
achieve
the
right
speed
that
would
be
followed
through
out
the
track.
This
was
done
using
the
innovative
debugging
tool
that
the
team
had
developed-­‐RF
link.
After
achieving
the
right
values
and
testing
on
small
tracks,
the
buggy
was
tested
on
longer
tracks(track
in
C34).
On
its
first
few
trials,
the
buggy
achieved
good
speed
and
was
able
to
take
all
turns
smoothly.
However,
few
challenges
surfaced
during
this
test.
The
problems
have
been
discussed
below
in
detail
5.1.1 Challenges during testing
S-­‐bends:
During
testing
on
tracks
in
C34
workshop,
it
was
observed
that
the
buggy
was
not
able
to
complete
the
s-­‐bends.
The
buggy
was
programmed
with
overshooting
sequence
for
such
turns
but
the
turning
radius
was
not
small
enough
for
the
buggy
to
take
the
turn.
After
decreasing
the
turning
radius
by
changing
the
duty-­‐cycle
of
the
motors,
the
buggy
was
successfully
able
to
take
s-­‐bend
turns
and
all
other
turns.
Stopping
in
20cms:
Another
challenge
that
was
uncovered
during
testing
was
the
buggy’s
incapability
to
stop
within
20cms
at
high
speeds.
At
its
highest
possible
straight-­‐line
speed
the
buggy
was
not
able
to
stop
within
20cms.
Many
different
programming
ways
were
tried
to
tackle
the
problem
such
as
turning
the
buggy
or
reversing
the
buggy
at
the
end.
All
these
ways
were
either
not
reliable
or
started
disturbing
buggy’s
movement
in
the
middle
of
the
course.
To
tackle
this
problem
the
team
came
up
with
the
idea
of
using
an
ultrasonic
sensor.
The
ultrasonic
sensor
slowed
the
buggy
down
if
any
wall
was
sensed
within
30cms
of
the
front
of
the
buggy.
It
is
important
to
note
that
the
ultrasonic
sensor
did
not
stop
the
buggy
but
only
slowed
the
buggy
down;
the
stopping
sequence
was
still
achieved
using
the
line
sensors.
This
feature
successfully
worked
as
the
ultrasound
sensor
slowed
the
buggy
down
before
the
end
of
the
track
and
line
sensors
were
able
to
stop
the
within
the
defined
space
of
20cms.
5.2 Preparation for first heat
As
a
group,
it
was
decided
to
use
the
first
heat
to
complete
the
track
and
not
concentrate
on
setting
a
fast
time.
The
following
changes
were
made
to
the
programme
of
the
buggy
to
make
sure
the
buggy
completes
the
track:
• The
straight-­‐line
duty-­‐cycle
was
reduced
to
50%
and
turning
duty-­‐cycle
was
also
reduced
accordingly
to
ensure
smooth
moving
buggy.
• The
value
of
constant
Kd
was
also
decreased
to
ensure
oscillation
free
movement
of
the
buggy.
Fig. 9. Buggy taking the S-bends
Fig. 10. Buggy going up the slope

15. 13
• For
the
first
heat,
the
function
of
ultrasound
sensor
of
slowing
down
the
buggy
was
not
used.
Because
it
was
decided
that
the
buggy
would
not
be
running
at
high
speed,
there
was
no
need
for
the
ultrasound
sensor
to
unnecessarily
slow
the
buggy
down.
The
line
sensors
would
be
able
to
stop
the
buggy
without
any
help.
5.3 First Heat
The
buggy
was
able
to
overcome
every
obstacle
and
stop
in
the
end
without
any
difficulty.
Buggy’s
performance
through
each
obstacle
has
been
discussed
below:
• Straight
section
of
the
track:
The
buggy
showed
decent
speed
and
very
little
oscillations
on
the
straight
section
of
the
track.
• Pinch-­‐Points:
The
sleek
body
shape
of
the
buggy
and
its
dexterity
in
following
line
proved
the
pinch-­‐points
to
be
of
no
danger
and
the
buggy
was
successfully
able
to
manoeuvre
its
way
through
the
pinch-­‐points.
• Turns:
The
turns
on
the
track
also
proved
to
be
of
no
problem
for
the
buggy.
All
the
turns
were
easily
taken
by
the
PD
controller
of
the
buggy.
• Slope:
The
speed
sensing
worked
well
during
the
up-­‐slope
section
of
the
track
and
increased
the
speed
of
the
buggy
accordingly.
The
change
in
the
speed
of
the
motor
was
almost
instantaneous
showing
the
working
of
P(proportional)
controller
in
speed
control.
This
helped
the
buggy
in
maintaining
the
speed
without
oscillating
and
hence
was
able
to
complete
the
track.
• Stop:
The
buggy
stopped
well
before
the
20cms
mark.
This
was
due
to
the
slow
speed
of
the
buggy
on
straight
line.
The
buggy
was
successfully
able
to
complete
the
track
in
a
respectable
time
of
8.3
seconds.
With
this
time
the
buggy
was
5th
fastest
among
all
the
buggies
in
stream
A.
The
next
step
was
to
make
the
buggy
faster.
5.4 Preparation for second heat
For
the
second
stream,
the
group
decided
to
make
the
buggy
faster
to
confirm
a
place
in
the
final
race.
The
following
changes
were
made
to
the
programme
of
the
buggy
to
make
the
buggy
faster
and
still
able
to
complete
the
track:
• The
straight-­‐line
duty-­‐cycle
was
increased
to
90%
and
turning
duty-­‐cycle
was
also
increased
accordingly
to
ensure
smooth
moving
buggy.
• The
value
of
constant
Kd
was
also
increased
to
ensure
oscillation
free
movement
of
the
buggy.
• For
the
second
heat,
the
function
of
the
ultrasound
sensor
was
decided
to
be
used
and
hence
was
included
in
the
program.
5.5 Second Heat
In
the
second
heat,
the
buggy
was
able
to
complete
the
track
and
stop
in
the
end
with
a
faster
lap-­‐time.
The
buggy
over-­‐all
looked
faster
in
the
turns
and
slope
but
took
greater
time
to
achieve
top
speed
on
straight
line.
Buggy’s
performance
through
each
obstacle
has
been
discussed
below:
• Straight
section
of
the
track:
The
main
problem
for
the
buggy
during
the
whole
course
was
the
oscillation
on
straight
line.
Buggy’s
settling
time,
compared
to
heat
1,
was
more
this
time
and
hence
made
the
buggy
slower
on
the
straight
line.
• Pinch-­‐Points
and
Turns:
Pinch-­‐points
and
turns
again
did
not
prove
to
be
any
problem
for
the
buggy
and
was
able
to
manoeuvre
its
way
through
with
much
more
speed
this
time.
• Slope:
Comparatively
much
less
oscillations
were
observed
on
straight
line
of
the
slope
than
the
straight
line
on
the
flat
surface.
On
the
slope
the
buggy
was
much
faster
than
in
first
heat
and
made
up
for
the
time
lost
on
straight
line.

16. 14
• Stop:
Ultrasound
sensor
worked
well
for
the
stopping,
as
the
buggy
was
able
to
stop
almost
5cms
before
the
end
of
the
wall.
The
stop
was
almost
perfected
and
proved
that
the
decision
of
using
ultrasound
sensor
was
the
right
one.
The
buggy
was
successfully
able
to
complete
the
track
in
a
fast
time
of
7.1
seconds.
Unfortunately
the
time
was
again
5th
fastest
in
stream
A
and
hence
was
not
fast
enough
to
be
qualified
for
the
final
race.
6.0
Critical
Analysis
The
buggy
was
able
to
complete
the
track
with
ease;
however,
not
reaching
the
final
race
was
a
disappointment.
Thorough
analysis
of
the
heats
has
been
done
below:
The
buggy
was
fast
everywhere
on
the
track,
except
on
the
straights
paths.
The
buggy
oscillated
more
than
expected
costing
time
and
place
in
the
finals.
The
possible
reasons
for
this
behaviour
might
be
the
reflected
infra-­‐red
from
the
sunlight.
The
race
was
the
first
time
the
buggy
was
tested
in
a
room
with
sunlight.
Because
the
two
analogue
sensors
were
used
for
keeping
the
buggy
on
a
straight
line,
additional
reflected
infrared
from
the
sunlight
might
have
affected
the
PD
control
systems.
An
alternative
that
could
have
led
to
a
faster
time
may
have
been
to
run
the
buggy
at
a
lower
duty-­‐cycle.
The
buggy
would
have
lost
time
at
the
turns
and
slope
but
would
have
made
up
for
it
on
the
straights
and
might
have
posted
a
faster
time.
The
buggy,
on
the
turns,
was
reasonable
fast
and
was
able
to
overcome
almost
any
kind
of
turns
using
the
overshooting
sequence
as
discussed
before.
Buggy,
with
the
help
of
the
speed
sensing,
was
also
very
fast
on
the
up
slope
and
it
would
have
been
very
difficult
to
make
the
buggy
even
faster
on
the
turns
and
slopes.
Another
big
challenge
the
buggy
faced
was
the
stopping
of
the
buggy.
The
buggy
was
comparatively
a
little
bit
heavier
than
expected
and
this
greater
mass
resulted
in
difficulty
to
stop
the
buggy
down.
This
greater
mass
could
have
been
the
result
of
the
RF
link
board
and
the
battery
box.
The
buggy
could
have
been
made
lighter
but
group
6
found
another
innovative
feature
to
tackle
this
problem
using
the
ultrasound
sensor
as
discussed
above.
The
sensor
worked
perfectly
in
stopping
the
buggy
within
the
required
distance
and
was
one
of
the
best
feature
of
the
buggy.
7.0
Successful
Innovative
Feature
Group
6
introduced
many
innovative
features
in
the
buggy
that
helped
the
buggy
more
reliably
complete
the
track
at
a
faster
speed.
The
innovative
features
have
been
discussed
below:
RF
link
used
as
debugging
tool:
Group
6
has
been
able
to
ease
down
the
process
of
debugging
which
otherwise
is
very
difficult
with
MPLAB.
Group
6
has
used
the
RF
board
along
with
the
microcontroller
board
and
I/O
board
to
obtain
important
information
about
the
buggy
which
made
the
programming
process
very
easy.
Important
information
such
as
speed
of
both
the
motors,
the
sensitivity
of
the
sensors
etc.
can
be
obtained
easily.
Values
of
integral
and
derivative
have
helped
to
improve
the
PID
control
of
the
buggy.
Obtaining
timer
information
from
the
microcontroller
of
the
buggy
has
made
the
programming
process
much
easier.
After
all
this,
the
RF
link
can
simultaneously,
change
the
speed
of
the
buggy,
make
it
go
left
right
or
go
back
with
varying
speed.
The
line
following
mode
and
the
remote
control
mode
can
be
changed
with
just
1
switch.
Ultrasonic
Sensor
as
a
means
for
stopping
within
20cms:
Stopping
the
buggy
in
the
limited
amount
of
space
was
one
of
the
main
challenges
of
the
buggy.
Group
6
has
tackled
this
using
an
ultrasonic
sensor.
The
ultrasonic
sensor
is
able
to
measure
the
distance
between
the
buggy
and
the
front
wall
in
every
10𝜇𝑠.
The
sensor
slows
the
buggy
down
if
it
senses
a
wall
in
30cms
from
the
buggy.
It
is
important
to
note
that
the
sensor
does
not
stop
the
buggy
but
only
slows
it
down.
The
stopping
feature
is
still
done
by
the
line
sensors.

17. 15
Overshooting
sequence:
Group
6
had
developed
a
feature
to
make
the
buggy
complete
the
track
in
a
more
reliable
way.
Overshooting
sequece
is
a
programming
feature
that
helps
the
buggy
to
take
sharp
turns
at
high
speeds.
This
feature
relies
on
the
fact
that
if
a
buggy
overshoots
a
line
at
the
corner,
the
last
sensor
sensing
the
line
would
have
been
one
of
the
end
sensors.
If
such
is
the
case,
the
buggy
would
try
to
rejoing
the
track
by
taking
a
sharp
turn
in
the
direction
depending
in
the
sensor
that
sensed
the
line.
If
,however,
any
of
the
middle
3
sensors
were
the
last
sensors
to
detect
the
line,
the
buggy
would
understand
that
it
has
reached
the
end
of
the
line
and
hence
would
stop.
8.0
Conclusion
The
buggy
was
able
to
achieve
most
of
its
aim
except
reaching
the
final
race.
It
was
capable
of
taking
turns
in
a
smooth
and
fast
way,
go
up
or
down
the
slope
while
maintaining
the
speed
and
stop
on
reaching
the
end
of
the
course.
The
total
cost
of
the
buggy
was
calculted
to
be
£32
including
recycable
items
which
is
underr
the
allocated
budget.
All
aims
were
accompilshed
while
abiding
by
the
regulations
of
maximum
6
sensors
and
budget
of
£50.
Many
new
innovative
features
such
as
RF
link
debugging
tool
and
ultrasound
sensor
not
only
eased
the
process
of
programming
but
also
improved
the
manoeuvrability
of
the
buggy
through
the
track.
During
the
two
heats,
group
6
had
mixed
fortunes.
For
the
first
heat,
the
group
concentrated
on
completing
the
track
in
respectable
time.
The
buggy
was
able
to
complete
the
track
without
any
difficulty
in
8.3
seconds.
In
the
second
heat,
the
group
concentrated
on
posting
a
faster
time
to
qualify
for
the
final
race.
However
the
buggy
had
more
oscillations
than
before
which
resulted
in
more
time
to
settle
down
on
a
straight
line.
This
costed
time
and
place
in
the
final
race
as
the
best
time
posted
by
group
6
was
only
7.1
seconds,
5th
fastest
in
the
stream.
After
critical
analysis
of
the
race,
the
following
steps
were
noted
which,
if
implemented,
could
have
improved
the
fastest
time
for
the
buggy:
• The
buggy
was
heavier
than
expected
which
compromised
not
only
the
stopping
distance
but
also
the
manoeuvrability
of
the
buggy
• One
reason
for
increased
oscillation
was
pointed
towards
the
sunlight
in
the
room
of
race.
The
buggy
should
have
been
tested
in
sunlight
before
coming
to
race.
• Better
PID
control
should
have
been
implemented
to
improve
oscillations
that
were
observed
in
a
straight
line.
In
conclusion,
even
though
the
buggy
was
not
able
to
reach
the
finals,
it
was
able
to
complete
the
track
in
fast
time
and
hence
can
be
declared
as
a
success.
9.0
References
[1]
Apsley,
J,
Green
PN,
Embedded
Systems
Project:
Project
Handbook,
School
of
Electrical
and
Electronic
Engineering
(2014),
the
University
of
Manchester,
Sept
2014.
[2]
Microchip.
(2008)
PIC18F8722
Family
Data
Sheet.
Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/39646c.pdf.
[3]
Vishay.
(2009).
TCRT5000L
Datasheet.
Available:
http://www.vishay.com/docs/83760/tcrt5000.pdf.
[4]
Foster,
DA,
Breakout
Interface
Schematic,
School
of
Electrical
and
Electronic
Engineering
(2014),
the
University
of
Manchester,
Sept
2014.
[5]
Apsley,
J,
Drive
Board
Circuit
Diagram,
School
of
Electrical
and
Electronic
Engineering
(2014),
The
University
of
Manchester,
Sept
2014
[6]
Farnell.
electronic
components.
Available:
http://uk.farnell.com/
[7]
Chen,
CW,
Embedded
System
Project-­‐Wireless
Link
Documentation,
School
of
Electrical
and
Electronic
Engineering
(2014),
The
University
of
Manchester,
Sept
2014
[8]
ITead
Studio.
(2010).
Ultrasonic
ranging
module
:
HC-­‐SR04
(Data
Sheet).
Available:
http://www.electroschematics.com/wp-­‐content/uploads/2013/07/HC-­‐SR04-­‐datasheet-­‐version-­‐2.pdf

18. 16
10.0
Appendix
10.1 Updated Engineering drawing for Acetal chassis
Fig. A. Acetal Chassis Plate

19. 17
10.2 Updated Engineering drawing for Upper Plate of the chassis
Fig. B. Upper Acetal Plate

20. 18
10.3 Updated Line Sensor Board Diagram
10.4 Updated Line Sensing Circuit Board Diagram
Fig. C. Circuit Diagram for line sensor board
Fig. D. Circuit Diagram for line sensing circuit board

21. 19
10.5 Updated Speed Sensing Board Diagram
10.6 Updated Speed Sensing Layout Diagram
Fig. E. Circuit Diagram for speed sensing circuit board
Fig. F. Layout Diagram for speed sensing circuit board

22. 20
10.7 Updated Line sensing Circuit Layout Diagram
10.8 Updated Line sensor Layout Diagram
The
line
sensor
board
was
designed
for
six
sensors,
however,
only
5
bottom
sensors
are
being
fitted
and
used.
Fig. G. Layout Diagram for line sensing circuit board
Fig. H. Layout Diagram for line sensor board

23. 21
10.9 Updated Wiring Diagram
10.10 Pseudo code
ConfigureADC()
while(1){
if(Remote
control
mode
is
switched
on)
{
if(pushbutton
1
is
pressed)
{
Turn_right()
}
RF
board
Ultrasonic
Sensor
Line
Sensors
Speed
Sensors
Motors
Fig. I. Wiring Diagram

24. 22
else
if(pushbutton
2
is
pressed)
{
Turn_left()
}
else
{
go
straight
according
to
potentiometer
}
else
if(Line
following
mode
is
switched
on)
{
Read
Sensors()
if(no
sensor
senses
line)
{
stop
}
else
if(analogue
sensors
detect
error)
{
Send
the
error
to
PD
line
controller
Turn
buggy
accordingly
}
else
if(end
digital
sensors
detect
line)
{
Turn
buggy
accordingly
}
else
{
Go
straight
if(speed
is
less
than
it
is
suppose
to
be)
{
Send
the
error
to
P
speed
controller
Increase
speed
accordingly;
}
else
if(speed
is
more
than
it
is
suppose
to
be)
{
Send
the
error
to
P
speed
controller
Decrease
speed;
}
}
}
}