1

VISUAL ODOMETER
A Project Report Submitted in the Partial fulfilment of
Bachelor of technology
In
ELECTRONICS AND COMMUNICATION
ENGINEERING
By
Aravinthan Ramaraj 091114038
Pratesh Kumar Reddy Rajupalem 091114076
Hithesh Reddivari 091114115
Lavudi Prudhvi 091114121
Annangarachari R 091114148
Korrapati Chandralohit 091114149

DEPARTMENT OF ELECTRONICS AND COMMUNICATION
ENGINEERING
MAULANA AZAD NATIONAL INSTITUTE OF TECHNOLOGY
BHOPAL
INDIA
April 2013
ii

DECLARATION BY THE CANDIDATES
We hereby declare that the project work entitled Visual Odometer is our own
work conducted under the guidance of DR.ARVIND RAJAWAT, Professor, Department
of Electronics and Communication Engineering, MANIT, Bhopal.
We further declare that to the best of our knowledge the thesis does not contain any
part of any work that has been submitted for the award of any degree either in this Institute
or in any other University without proper citation.
Student name Scholar number Signature
Aravinthan Ramaraj 091114038
Pratesh Kumar Reddy Rajupalem 091114076
Hithesh Reddivari 091114115
Lavudi Prudhvi 091114121
Annangarachari R 091114148
Korrapati Chandralohit 091114149
This is to certify that the declaration made above by the candidate is true to the best
of my knowledge.



Dr.Arvind Rajawat
Professor,
Department of Electronics and Communication Engineering,
Maulana Azad National Institute of Technology, Bhopal (MP



iii

DEDICATION

We would like to dedicate our work to four years of college life that MANIT has
given us. We would like to dedicate this work to the entire department of Electronics and
Communication Engineering; that is, the faculty and the students of the 2009-2013 batch.


iv

ACKNOWLEDGEMENT

We would like to express our gratitude to Dr. Arvind Rajawat for his valuable
guidance. His valuable and admonishing feedbacks are responsible for the inclusion of
innovative developments in the project and its early completion. We are indebted to the
professor because we have observed and learnt many qualities like perseverance and
passion for the subject from him.

v


ABSTRACT
The objective of the project is to demonstrate the working along with complete
implementation of a new odometer technology. Unlike the conventional odometric
techniques this project uses and demonstrates Visual Odometry. This objective has
been accomplished by using an optical flow sensor ADNS3080 which is basically a mouse
sensor used in present day optical-mouse. The optical-flow sensor uses optical flow
techniques to calculate the relative motion vectors in terms of relative displacement values
delta_x and delta_y. The outputs from the optical-flow sensor are given to an Arduino (a
microcontroller based processing unit) which wirelessly transmits the data to a computer.
Computer plots and logs the data. MATLAB was used to write the plotting code, develop
it, make a GUI and finally to deploy a Windows executable (.exe) file. The .exe will
generate a figure comprising velocity vs time plot, distance vs time plot and X vs Y plot in
real-time. The plot can be saved and used for future reference.













vi

Table of contents
1. INTRODUCTION ........................................................................................ 1
1.1. Odometry .................................................................................................................... 2
1.2. Techniques Used in Odometry ................................................................................... 2
1.2.1. Mechanical Method (Using Rotational Encoders) ............................................... 2
1.2.2. Visual Methods: (Using Camera Sensors) ........................................................... 3
1.2.3. Electronic Method (Using Inertial Sensors): ....................................................... 4
1.3. Visual Odometry (VO) ............................................................................................... 4
1.3.1 Algorithm .............................................................................................................. 4
1.3.2. Optical Flow Methods ......................................................................................... 5
1.3.3. Requirements ....................................................................................................... 6
1.3.4. Advantages ........................................................................................................... 6
2. PROJECT DEVICES DESCRIPTION ........................................................ 7
2.1. Optical Flow Sensor: .................................................................................................. 7
2.1.1. Description: .......................................................................................................... 7
2.1.2. Theory of Operation: ........................................................................................... 8
2.1.2 Pin-out ................................................................................................................... 9
2.1.3. Synchronous Serial Port ....................................................................................... 9
2.1.4. Important Terms and Definitions ....................................................................... 10
2.2. Arduino ..................................................................................................................... 10
2.2.1. Programming ..................................................................................................... 12
2.3. Wireless Transmitter-Receiver ................................................................................. 12
2.3.1. Features .............................................................................................................. 13
2.3.2. Pin-out ................................................................................................................ 13
2.4. Serial to USB Converter ........................................................................................... 14
2.5. Application Software Description ............................................................................ 14
vii

3. PROJECT EXPLANATION ....................................................................... 15
3.1. Block diagram ........................................................................................................... 15
3.1.1 Explanation of Block Diagram: .......................................................................... 16
3.2. Arrangement and Interconnections of Components ................................................. 17
3.2.1. Vehicle Side ....................................................................................................... 17
3.2.2. User Terminal Side: ........................................................................................... 20
3.3. Working .................................................................................................................... 21
3.3.1. Vehicles Portion ............................................................................................... 21
3.3.2. Flow chart for Arduino operations ..................................................................... 22
3.3.3. Description of Vehicle Side flow chart .............................................................. 23
3.3.4. User Terminals Portion ..................................................................................... 23
3.3.5. Description of User Terminal Side Flow Chart ................................................. 25
4. CALIBRATION AND TESTING .............................................................. 27
4.1. Calibration Tables ..................................................................................................... 27
4.2. Conclusions after calibration: ................................................................................... 28
5. RESULTS................................................................................................... 29
5.1. Plots and Their Description ...................................................................................... 29
5.1.1. Surface Quality Plot: .......................................................................................... 29
5.1.2. Distance vs Time Plot: ....................................................................................... 30
5.1.3. Velocity vs Time Plot: ....................................................................................... 31
5.1.4. X vs Y Plot: ........................................................................................................ 31
5.2. Errors results in distance measurement .................................................................... 32
6. APPLICATIONS ........................................................................................ 33
6.1. In Space Rovers ........................................................................................................ 33
6.2. Other Important Applications ................................................................................... 35
References ....................................................................................................... 36
viii

APPENDIX-1 .................................................................................................. 37
MATLAB code for calibration and testing: ..................................................................... 37
APPENDIX-2 .................................................................................................. 39
Arduino code and explanation: ........................................................................................ 39
APPENDIX-3 .................................................................................................. 41
MATLAB main code and explanation ............................................................................. 41
APPENDIX-4 .................................................................................................. 43
Step by step instruction manual for operating the project: .............................................. 43
APPENDIX-5 .................................................................................................. 44
UART (Universal Asynchronous Receiver Transmitter) ................................................ 44
APPENDIX-6 .................................................................................................. 48
SPI (Serial Peripheral Interface) communication protocol: ............................................. 48

ix


List of Figures

Figure 1: Rotational Encoders ............................................................................................... 2
Figure 2: Illustration showing wheel slip .............................................................................. 3
Figure 3: Cameras as odometric sensors ................................................................................ 3
Figure 4: Monocular, stereo and omnidirectional camera examples ..................................... 4
Figure 5: Omni directional Camera on a car for measuring optical flow .............................. 5
Figure 6: Optical flow between two consecutive images ...................................................... 5
Figure 7: Optical flow sensor ................................................................................................. 7
Figure 8: Block Diagram of ADNS-3080 .............................................................................. 8
Figure 9: Optical Flow Sensor Pin-out .................................................................................. 9
Figure 10: Arduino UNO ..................................................................................................... 11
Figure 11: Arduino software snapshot ................................................................................. 12
Figure 12: RxTx module ...................................................................................................... 12
Figure 13: Transmitter ......................................................................................................... 13
Figure 14: Receiver .............................................................................................................. 13
Figure 15: Block Diagram of entire project ......................................................................... 15
Figure 16: Vehicle ............................................................................................................... 17
Figure 17: Illustration of Sensor and Vehicle Relative Alignment ..................................... 18
Figure 18: Circuit diagram at vehicle side ........................................................................... 19
Figure 19: Wireless receiver circuit ..................................................................................... 20
Figure 20: Serial to USB converter...................................................................................... 20
Figure 21: Circuit Diagram for the Receiving Circuit ......................................................... 21
Figure 22: Graphical User Interface .................................................................................... 26
Figure 23: Final result figure ............................................................................................... 29
Figure 24: Surface quality plot ............................................................................................ 30
Figure 25: Distance vs time plot .......................................................................................... 30
Figure 26: Velocity vs time plot .......................................................................................... 31
Figure 27: X vs Y plot ......................................................................................................... 31
Figure 28: Image of Mars Curiosity Rover .......................................................................... 33
x

Figure 29: Illustration Showing Possible Wheel Slip .......................................................... 34
Figure 30: US Army Spy bot with camera .......................................................................... 35
Figure 31: SPI Block Diagram ............................................................................................. 48
Figure 32: SPI Master-Slave Interconnection ...................................................................... 50


xi

List of Tables
Table 1: Pin-out of optical flow sensor .................................................................................. 9
Table 2: Transmitter Pinout ................................................................................................. 13
Table 3: Receiver Pin-out .................................................................................................... 14
Table 4: Connections between Arduino and Optical flow sensor ....................................... 19
Table 5: Experiment values for tar road under sunlight ...................................................... 27
Table 6: Experiment values for tar road under the shade of a tree ...................................... 27
Table 7: Experiment values for tiles in sunlight .................................................................. 27
Table 8: Experiment values for tiles under shade of a tree .................................................. 28
Table 9: Experiment values for cement slab in sunlight ...................................................... 28
Table 10: Experiment values for cement slab in shade ....................................................... 28
Table 11: Results in sunlight ............................................................................................... 32
Table 12: Results in shade ................................................................................................... 32

xii

List of Codes
Code 1: Pre-processor code ................................................................................................. 39
Code 2: Variable declaration ............................................................................................... 39
Code 3: Initial setup ............................................................................................................. 39
Code 4: Main loop ............................................................................................................... 40
Code 5: Function for sending motion data ........................................................................... 40
Code 6: MATLAB Variable declaration ............................................................................. 41
Code 7: Figure Creation ....................................................................................................... 41
Code 8: Serial Port Access ................................................................................................... 41
Code 9: MATLAB Main loop ............................................................................................. 42
Code 10: Clear Serial port ................................................................................................... 42















1

1. INTRODUCTION


Out of many factors that played remarkable role in development and flourishing of
human race, exploration finds a prominent position. We, the mankind would not have
stood long without our strong desire to explore the world. Its this curiosity to explore new
horizons made us understand the universe. This is what made us take our first step in our
childhood and that made us different from the frogs in a well. We started with a step and
now we are crossing planets. The newly sent mars rover aptly named CURIOSITY has
exemplified this interest in us.
Along with the passion we need a means, a tool that can make these explorations
successful. It is important that we are not lost during our explorations. This can be possible
with the aid of methods, the methods by which we can trace back our path to our initial
location while exploring new territories, and which are called navigational systems. From
the times of mariners compass we have now ascended to high precision GPS, INS
technologies. And these technologies have kept us in track without disappointment. But as
the situations take their shape, necessity for more precision is required. There is a lot more
we will be capable of achieving with the improved algorithms and mechanisms. So it is a
part of our continuous evolution that we aspire for new robust, reliable, precise
navigational systems.
Tracing the travelled path and locating the position starts with the most basic step
of measuring the distance travelled. This process of measuring distance is called
ODOMETRY
2

1.1. Odometry
Odometry is the use of data from moving sensors to estimate change in position
over time, so as to estimate their position relative to a starting location. The word
Odometry is composed from the Greek words hodos (meaning "travel", "journey") and
metron (meaning "measure"). It requires rapid and accurate data collection, equipment
calibration, and processing for optimum results. The system requires operating in real-time
with low delay. The motion estimates when aided with information of initial position and
velocity can be used for navigational purposes also.

1.2. Techniques Used in Odometry

1.2.1. Mechanical Method (Using Rotational Encoders)
This method uses mechanical/electronic encoders which convert the number of
rotations made by the wheels of the moving platform (viz. wheeled robot, car) into either
analog/digital signals which in turn drive the meter displays.

Figure 1: Rotational Encoders
This method is largely used at present in ground vehicles due its simplicity and cost
effectiveness. It lacks the precision and is prone to errors due to slippage and sliding of
wheels which can happen when the terrain is sandy or smooth as shown in the figure
below. It cannot be applied to mobile robots with non-standard locomotion methods, such
as legged robots.
3


Figure 2: Illustration showing wheel slip

1.2.2. Visual Methods: (Using Camera Sensors)
This system estimates the motion of a platform carrying stereo head or a single
moving camera based on video input. As motion is estimated from visual input alone it is
termed as Visual Odometry (VO). The term VO was coined in 2004 by Nister in his
landmark paper [2]

Figure 3: Cameras as odometric sensors
A good amount of precision can be achieved. Even though the robustness of the
system depends on the type of the surfaces and illumination, it is immune to errors of
slips/slides. It can be used for even non-conventional locomotion methods. Because of
moderate cost, they are generally used in robotic applications, such as on the Mars
Exploration Rovers.

4

1.2.3. Electronic Method (Using Inertial Sensors):
The motion is estimated using a computer, motion sensors (accelerometers) and
rotation sensors (gyroscopes) to continuously calculate via dead reckoning. The position,
orientation, and velocity (direction and speed of movement) of a moving object are
determined without the need for external references. It is also called Inertial Navigational
System (INS) when used for navigational purposes.
The application lies in ships, aircraft, submarines, guided missiles, and spacecraft guidance
systems. As they dont require external references they are immune to jamming or
deception (which is possible in GPS). But their cost and complexity place constraints on
the environments in which they are practical for use.

1.3. Visual Odometry (VO)

Visual odometry is the process of estimating the ego-motion of an agent (e.g.,
vehicle, human and robot) using sequential camera images. This can be achieved using
either monocular or stereo type or omnidirectional camera [3].

Figure 4: Monocular, stereo and omnidirectional camera examples

1.3.1 Algorithm
A camera attached to (mostly front end of) the moving agent detects the robust
features in the images captured.
5


Figure 5: Omni directional Camera on a car for measuring optical flow
The tracked features are matched between pair of images to construct optical flow
field.
This involves
Using correlation to establish correspondence of two images, and no long
term feature tracking.
Feature extraction and correlation (LucasKanade or Horn-Schunk method).
Construct optical flow field.

Figure 6: Optical flow between two consecutive images
Check flow field vectors for potential tracking errors and remove outliers.
Estimation of the camera motion from the optical flow

1.3.2. Optical Flow Methods
The optical flow methods usually preferred for extracting and matching the features in
image sequences are
6

Lukas-Kanade Algorithm:
It is a widely used differential method for optical flow estimation. It assumes
that the flow is essentially constant in a local neighbourhood of the pixel under
consideration, and solves the basic optical flow equations for all the pixels in that
neighbourhood, by the least squares criterion [5].
Horn-Schunk Algorithm:
The HornSchunck method of estimating optical flow is a global method which
introduces a global constraint of smoothness in the flow over the entire image [6].

1.3.3. Requirements
VO operates by incrementally estimating the pose of the vehicle through
examination of the changes that motion induces on the images of its on-board cameras.

For VO to work effectively there should be
Sufficient illumination in the environment,
Static scene with enough texture to allow apparent motion to be extracted,
Consecutive frames should be captured by ensuring that they have sufficient scene
overlap.

1.3.4. Advantages
The advantage of VO with respect to wheel odometry is that VO is not affected by
wheel slip in uneven terrain or other adverse conditions. It has been demonstrated that
compared to wheel odometry, VO provides more accurate trajectory estimates, with
relative position error ranging from 0.1 to 2%. This capability makes VO an interesting
supplement to wheel odometry and, additionally, to other navigation systems such as
global positioning system (GPS), inertial measurement units (IMUs), and laser odometry
(similar to VO, laser odometry estimates the ego-motion of a vehicle by scan-matching of
consecutive laser scans). In GPS-denied environments, such as underwater, aerial and
extra-terrestrial, VO has utmost importance.
7

2. PROJECT DEVICES DESCRIPTION

In this section a detailed report of all the components used in this project and their
respective function in this project.

2.1. Optical Flow Sensor:

Figure 7: Optical flow sensor
2.1.1. Description:
This sensor is based on ADNS3080 Mouse sensor which is used in present day
optical mouse. It has a camera along with lens which takes the images on which optical
flow algorithms are implemented. The sensor is programmed via registers through a four-
wire serial port. The features of this sensor are summarised below.

Features:
ADNS3080 mouse sensor
8mm lens with 11degree FOV
Standard M12x0.5 lens mount
High speed motion detection up to 40 ips and 15g
New architecture for greatly improved optical navigation technology
Programmable frame rate over 6400 frames per second
Smart Speed self-adjusting frame rate for optimum performance
Serial port burst mode for fast data transfer
400 or 1600 cpi
1
selectable resolution

1
CPI (Counts per Inch) resolution is indicative of how many times per inch of optical mouse
movement that the optical mouse sensor sends an image sensing report signal to an optical mouse
controller.
8

Single 3.3 volt power supply
Four-wire serial port along with Chip Select, Power Down, and Reset pins
The ADNS-3080 is based on a new, faster architecture with improved navigation.
The sensor is capable of sensing high speed mouse motion - up to 40 inches per second and
acceleration up to 15g for increased user precision and smoothness [1]. The sensor is
programmed via registers through a four-wire serial port. It is packaged in a 20-pin
staggered dual inline package (DIP).

2.1.2. Theory of Operation:
The ADNS-3080 is based on Optical Navigation Technology which measures
changes in position by optically acquiring sequential surface images (frames) and
mathematically determining the direction and magnitude of movement. It contains an
Image Acquisition System (IAS), a Digital Signal Processor (DSP), and a four-wire serial
port. The IAS acquires microscopic surface images via the lens and illumination system.
These images are processed by the DSP to determine the direction and distance of motion.
The DSP calculates the x and y relative displacement values. These relative
displacement values returned by the sensor are proportional to real world distances
provided sensors altitude is kept constant [1]. So in order to get the real world distances
(in meters) one has to find the multiplying factor.

Figure 8: Block Diagram of ADNS-3080
9


2.1.2 Pin-out
Table 1: Pin-out of optical flow sensor


Figure 9: Optical Flow Sensor Pin-out

2.1.3. Synchronous Serial Port
The synchronous serial port is used to set and read parameters in the ADNS-3080,
and to read out the motion information. The serial port is also used to load SROM data into
the ADNS-3080. The port is a four-wire, serial port. The host micro-controller always
initiates communication; the ADNS-3080 never initiates data transfers. The serial port
cannot be activated while the chip is in power down mode (NPD low) or reset (RESET
high). SCLK, MOSI, and NCS may be driven directly by a 3.3V output from a micro-
Pin Name Description
1 GND Ground
2 5V 5V Supply voltage
3 3V 3VSupply voltage
4 NCS Chip select pin
5 MISO Serial Data Output (Master In/ Slave Out)
6 MOSI Serial Data Input (Master Out/ Slave In)
7 SCLK Serial clock
8 RST Reset
9 NPD Power Down (Active low input)
10 LED Can be connected to an external LED
10

controller, or they may be placed in an open drain configuration by enabling on-chip pull-
up current sources. The open drain drive allows the use of a 5V micro-controller without
any level shifting components. The port pins may be shared with other SPI slave devices.
When the NCS pin is high, the inputs are ignored and the output is tri-stated.
The lines which comprise the SPI port are:
SCLK: Clock input. It is always generated by the master (the micro- controller).
MOSI: Input data (Master Out/Slave In).
MISO: Output data (Master In/Slave Out).
NCS: Chip select input (active low).

2.1.4. Important Terms and Definitions
Delta_X: X movement is counted since last report. Absolute value is determined by
resolution.
Delta_Y: Y movement is counted since last report. Absolute value is determined by
resolution.
Surface_Quality: SQUAL (Surface Quality) is a measure of of the number of valid
features visible by the sensor in the current frame. Use the following formula to find the
total number of valid features.



The maximum SQUAL register value is 169. Since small changes in the current
frame can result in changes in SQUAL, variations in SQUAL when looking at a surface are
expected.

2.2. Arduino

Arduino is a single-board microcontroller designed to make the process of using
electronics in multidisciplinary projects more accessible. The hardware consists of a simple
open source hardware board designed around an 8-bit Atmel AVR microcontroller. The
software consists of a standard programming language compiler and a boot loader that
executes on the microcontroller. The board which we are using in our project is Arduino
11

UNO. The Arduino UNO is a microcontroller board based on the ATmega328. It has 14
digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, a 16
MHz ceramic resonator, a USB connection, a power jack, an ICSP header, and a reset
button. It contains everything needed to support the microcontroller [4].



Figure 10: Arduino UNO

Summary:
Microcontroller ATmega328
Operating Voltage 5V
Input Voltage (recommended) 7-12V
Input Voltage (limits) 6-20V
Digital I/O Pins 14 (of which 6 provide PWM output)
Analog Input Pins 6
DC Current per I/O Pin 40 mA
DC Current for 3.3V Pin 50 mA
Flash Memory 32 KB of which 0.5 KB used by boot-loader
SRAM 2 KB
EEPROM 1 KB
Clock Speed 16 MHz


12

2.2.1. Programming
The Arduino Uno can be programmed with the Arduino software. The ATmega328
on the Arduino Uno comes preburned with a bootloader that allows you to upload new
code to it without the use of an external hardware programmer. A screenshot of the
computer interface used to write and upload programs is shown below [4].

Figure 11: Arduino software snapshot
2.3. Wireless Transmitter-Receiver
Pair of transmitter receiver module is used wirelessly transmit data serially. This
module operates at 2400 baud rate.

Figure 12: RxTx module
13

2.3.1. Features
Operating Frequency 433Mhz
Data Rate 2400 bps
Operating voltage
Transmitter 2 - 12 V
Receiver 4.5-5.5 V

2.3.2. Pin-out
Transmitter:

Figure 13: Transmitter
Table 2: Transmitter Pinout
Pin Name Description
1 GND Ground
2 DATAIN Serial input
3 VCC Transmitter Power supply
4 ANT Antenna

Receiver:

Figure 14: Receiver
14

Table 3: Receiver Pin-out
Pin Name Description
1 GND Ground
2 DATAOUT Serial data output
3 NC No connect
4 VCC Receiver Power supply
5 VCC Receiver Power supply
6 GND Ground
7 GND Ground
8 ANT Antenna


2.4. Serial to USB Converter
This device converts Serial RS232 protocol data into USB protocol data so that it
can be used by present day laptops which doesnt come with a RS232 port.

2.5. Application Software Description
The serial data received by the computer is processed to produce required plots. A
windows .exe file does all these operations after we provide the current COM port and
number of iterations the code has to run. The code for the program is written in MATLAB
and then it is compiled into an executable file using Deploy Tool in MATLAB.
15

3. PROJECT EXPLANATION


This chapter explains the entire working of the project developed both structurally
and functionally. We start by describing the block diagram of the project which illustrates
the basic blocks in the project along with their role in the project.

3.1. Block diagram


Figure 15: Block Diagram of entire project
PROCESSING
BLOCK
16

3.1.1 Explanation of Block Diagram:

Optical Flow Sensor:
The optical flow sensor senses the motion and outputs the relative displacement
values delta_x, delta_y and that data is sent to the processing block
Processing Block:
The processing block handles the communication protocol and communicates with
the Optical Flow Sensor. This is then relayed to the computer using a wireless medium.
433 MHz Tx
This is the wireless transmission block which transmits the data wirelessly at 433
MHz to the computer side.
433 Mhz Rx
This block is a wireless receiving block which receives the wireless data sent by
wireless transmission block and then sends to Serial to USB converter for further
processing
Serial to USB Converter:
This block handles the protocol conversion from UART (Universal Asynchronous
Transmitter Receiver) protocol to USB (Universal Serial Bus) protocol. This block is
necessary to connect with the present day computers where no RS232 port is present.
Computer/GUI:
The Serial to USB converter appears in computer as a serial COM port which is
used to give data to MATLAB GUI which then plots and logs the data.
Power system
Not shown In the block diagram is the power system which gives power required
for proper functioning of the hardware components used.

17

3.2. Arrangement and Interconnections of Components
In order to describe the working of the project we have started by explaining the
arrangement of the components followed by their interconnections and after that their
actual working is described.
3.2.1. Vehicle Side
The diagram below shows the arrangement of the components at the vehicle side.


Figure 16: Vehicle

The optical flow sensor is placed at the front side of the vehicle facing down as
shown in the figure. A plastic scale was used to support the placement of optical flow
sensor. Care is taken that the alignment of the sensors Y-axis is parallel to the vehicles
forward axes and lying on the central line as shown in Figure-17. At the central part of the
vehicle Arduino board is fixed with the help of screws. The sensor is connected to
Arduino using four wires which comprise MISO, MOSI, SCLK and NCS wires as shown
in circuit diagram (Figure-18). The wireless transmitter module is directly mounted on the
Arduino board and the Arduinos serial Tx pin (Digital pin-1) is connected to the DataIn
pin of the transmitter as show in circuit diagram. Different power supplies are provided to
Wireless Transmitter
Arduino
Optical Flow Sensor
18

Arduino and Transmitter module. As shown in figure-16 the batteries are placed at the rear
part of the vehicle. The Optical flow sensor is supplemented with an LED light (Not shown
in figure) in order to illuminate the surface in case of low lightning conditions.

Figure 17: Illustration of Sensor and Vehicle Relative Alignment
19

Circuit Diagram at Vehicle Side:

Figure 18: Circuit diagram at vehicle side

The pins from Arduino to Optical Flow sensor is connected as shown in the table below

Table 4: Connections between Arduino and Optical flow sensor

Description Arduino Pin Optical Flow sensor pin
SCK 13 7
MISO 12 5
MOSI 11 6
NCS 10 4
20


3.2.2. User Terminal Side:

Figure 19: Wireless receiver circuit


Figure 20: Serial to USB converter
To receive signals sent by the transmitter a receiver circuit is built at the user
terminal side. The circuit for the wireless receiver is built as shown in the circuit diagram
(Figure-21). A MAX232 chip is provided to convert the TTL levels (0V and 5V) given by
the DataOut pin of the receiver into RS232 levels (+10V and -10V). A 5V regulator
(LM7805) is used to power the receiver module. A serial to USB converter is used as an
interface between the receiving circuit and computer.
Wireless Receiver
MAX232
21

Circuit diagram at user terminal side (Receiving Circuit):

Figure 21: Circuit Diagram for the Receiving Circuit
3.3. Working
The working of the project is described by dividing it into vehicle side and user
terminal side. Since the arrangement and interconnections are understood, now we describe
the functional description of the project along with role played by each component.
3.3.1. Vehicles Portion
At the vehicle side Arduino is used as the control and processing unit. The Arduino
sends commands to the optical flow sensor requesting data from the sensor. The optical
flow sensor returns the relative displacement values which are transferred to the
microcontroller on the Arduino board using an SPI communication protocol (Appendix-6).
The specific addresses of the registers are given in the sensors datasheet. The arduino is
22

programmed to take these data and transfer them serially at 2400bps to wireless transmitter
module which relays the data with 433MHz carrier. Arduino code is given in appendix-2
and a flow chart is presented in section below.
3.3.2. Flow chart for Arduino operations


















Initialise the pre-processor code (Include headers and
define constants)
Variable Declaration
Initial setup (Initialise serial port and Optical flow sensor)
Get Relative displacement
values from optical flow
sensor
Send the frames serially
using UART
Framing
23

3.3.3. Description of Vehicle Side flow chart
The first block starts when the power is turned on i.e when the batteries are
connected to the Arduino board. It is a process of including the header files required for the
functioning of the Arduino code.
The second block is a variable declaration block where the memory registers are
allocated for the further processes to take place.
In the third block the initialization of serial port and Optical-flow sensor take place.
The serial port is set to 2400 baud rate.
The fourth one is an input block where sensors values are input into the Arduino.
The Arduino communicates with the sensor using SPI protocol. The details of the protocol
are described in Appendix-6.
Framing:
The data to be sent to the user terminal is first formed into frames in order to avoid
confusions at the receiver side. De-limiters are inserted in between the data in order to
distinguish from each other as shown in the frame structure below
Frame structure:
Delta_x ; Delta_y ; SQAL ; Delta_t
Here Delta_x is the relative displacement value of x, delta_y is the relative
displacement value of y, SQAL is the surface quality, Delta_t is the time taken to measure
relative displacement values.
The de-limiter ; is used to separate the values from each other. After the frame a
carriage return is sent to inform the end of the frame.
In the last block the frames generated are sent serially to the wireless transmission
module which relays the data to the user terminal.
3.3.4. User Terminals Portion
The wireless receiver module receives the data and relays it to Serial to USB
converter via a MAX232 level converter. Then the data is relayed to computer COM port
from which the MATLAB program grabs it. The communication protocol used is UART
24

which is described in Appendix-5. The flow chart describing MATLAB code operation is
given in the section below.
3.3.5. Flow Chart Describing MATLAB Code Operation

Variable Declaration
Creating Figure and initialising
Subplots
Initialising Serial Port
Acquire Data from
Serial Port
Process the Data by multiplying them
with their respective multiplying
factors
Plot and log the data
Close Serial port
25

3.3.6. Description of User Terminal Side Flow Chart

In the first block the matrices are created as variables which have their use in
further processes of the code
In the second block the Figure is created along with plots and their handles are
stored in separate variables. This plots the initial values of the plots as (0,0).
In the third block Serial port object is created and thus a buffer space is created to
accommodate the incoming data from the COM port. The baud rate is set to 2400 equal to
the transmitter baudrate. After the object is created, the port is opened.
In the fourth block the serial data which is automatically queued in the buffer is
taken into a matrix variable as a character string. Then using a specific MATLAB function
the data is separated into their respective values using the delimiter and stored in respective
variable matrices.
In the fifth block the calibration results are used to get the values of actual distance
velocity and angle turned by the vehicle from initial position. The delta_y value returned
by the sensor which is now stored in a new variable dy is used to calculate the real
distance i.e distance in centi-meters. The delta_x value returned by the sensor which is now
stored in a new variable dx is used to calculate the angle turned by the vehicle from its
initial position (Refer Figure-17)
In the last block the values found above are plotted in the plots. Surface quality is
plotted with respect to iteration count. Distance is plotted with respect to time. Velocity is
plotted with respect to time. The last plot which plots the path traversed by the vehicle
assumes vehicles initial position to be (0,0), vehicles initial forward direction as x-axis,
and perpendicular to it as y-axis. As the Axes of the sensor changes from time to time with
respect to our present axis, vehicles rotation angle and distance moved are taken as
reference to plot the path plot. The equations can be easily understood from the MATLAB
code given in Appendix-3. The plots and their explanation is given in Chapter-5.
26

After the code was written, it was compiled into a Graphical User Interface (GUI)
and deployed into a Windows executable file whose screen shot is shown below. The step
by step instruction manual to run the program is given in Appendix-4.

Figure 22: Graphical User Interface
27

4. CALIBRATION AND TESTING

We have created a separate MATLAB program to calibrate the sensor by which we
get the multiplying factors for converting sensor values to real world distances and angles.
The code is similar to the main code and is given in the Appendix-1. The values are
tabulated and the final multiplying factor is found out.

4.1. Calibration Tables
Table 5: Experiment values for tar road under sunlight
AVERAGE
SURFACE
QUALITY
ACTUAL LENGTH
(in cm)
SENSOR
VALUE
CALIBRATION
FACTOR
(cm/pixel)
105 100 2377 0.04207
99 75 1799 0.04169
100 50 1184 0.04223
110 25 596 0.04195
Average calibration factor=0.041985
Table 6: Experiment values for tar road under the shade of a tree
AVERAGE
SURFACE
QUALITY
ACTUAL LENGTH
(in cm)
SENSOR
VALUE
CALIBRATION
FACTOR
(cm/pixel)
90 100 2354 0.04248
100 75 1751 0.04283
120 50 1194 0.04188
102 25 578 0.04325
Average calibration factor=0.04261
Table 7: Experiment values for tiles in sunlight
AVERAGE
SURFACE
QUALITY
ACTUAL LENGTH
(in cm)
SENSOR
VALUE
CALIBRATION
FACTOR
(cm/pixel)
65 100 2442 0.04095
50 75 1817 0.04128
55 50 1186 0.04216
50 25 583 0.04288
Average calibration factor=0.04182

28

Table 8: Experiment values for tiles under shade of a tree
AVERAGE
SURFACE
QUALITY
ACTUAL LENGTH
(in cm)
SENSOR
VALUE
CALIBRATION
FACTOR
(cm/pixel)
53 100 2426 0.04122
55 75 1794 0.04181
40 50 1140 0.04386
52 25 596 0.04195
Average calibration factor=0.04221

Table 9: Experiment values for cement slab in sunlight
AVERAGE
SURFACE
QUALITY
ACTUAL LENGTH
(in cm)
SENSOR
VALUE
CALIBRATION
FACTOR
(cm/pixel)
90 100 2442 0.04095
85 75 1839 0.04078
95 50 1211 0.04129
75 25 589 0.04245
Average calibration factor=0.0414

Table 10: Experiment values for cement slab in shade
AVERAGE
SURFACE
QUALITY
ACTUAL LENGTH
(in cm)
SENSOR
VALUE
CALIBRATION
FACTOR
(cm/pixel)
60 100 2384 0.04195
60 75 1775 0.04225
75 50 1198 0.04174
80 25 596 0.04195
Average calibration factor=0.0420
4.2. Conclusions after calibration:
Average Calibration factor for conditions under sunlight=0.04173
Average Calibration factor for conditions under the shade of a tree= 0.04227
Average Calibration factor in any condition =0.042
29

5. RESULTS


After all the above components are connected properly, when one executes the .exe
file, it gives out a figure similar to the figure shown below. The application continuously
plots the data in real time as the vehicle is running.

Figure 23: Final result figure
As shown in the above figure, the application returns four plots which is described
below in detail.

5.1. Plots and Their Description
1. Surface Quality Plot
2. Distance vs Time Plot
3. Velocity vs Time Plot
4. X vs Y Plot
5.1.1. Surface Quality Plot:
This plot plots in real time the variations in the surface quality on which the vehicle
is moving. As described before in equation-1, the value of surface quality denotes one-
30

fourth of the number of features on the surface the sensor is tracking. This graph is
included in order to find if the surface is bright enough for visual odometry.

Figure 24: Surface quality plot
5.1.2. Distance vs Time Plot:
This plot plots in real time the distance moved by the vehicle along with time taken
from starting of the vehicle. Negative distance implies that the vehicle has moved in
backward direction. If the bot makes a 180 degree turn and moves backward, that distance
will be included in the positive plot.

Figure 25: Distance vs time plot
31

5.1.3. Velocity vs Time Plot:
This plot plots in real time the velocity of the vehicle vs the time taken from start.
The positive values in the plot convey that the bot is moving forward with velocity given
by y co-ordinate at that point. The negative values in the plot convey that the bot is moving
backward with velocity given by y co-ordinate at that point.

Figure 26: Velocity vs time plot
5.1.4. X vs Y Plot:
This plot plots the Path of the vehicle from the starting point so that we can track
the vehicle on a computer. The plot always strarts at co-ordinate (0,0).

Figure 27: X vs Y plot
32

5.2. Errors results in distance measurement

Table 11: Results in sunlight
AVERAGE
SURFACE
QUALITY
SENSOR
VALUE
CALUCULATED
DISTANCE
( in cm)
ACTUAL
DISTANCE
(in cm)
ABSOLUTE
ERROR
(in cm)
ERROR
(%)
50 500 20.85 20 0.85 4.25
60 970 40.4781 40 0.4781 1.2
55 1489 62.13 60 2.13 3.55

Table 12: Results in shade
AVERAGE
SURFACE
QUALITY
SENSOR
VALUE
CALUCULATED
DISTANCE
( in cm)
ACTUAL
DISTANCE
(in cm)
ABSOLUTE
ERROR
(in cm)
ERROR
(%)
55 440 18.9 20 1.1 5.5
55 902 38.1278 40 1.8722 4.6
100 1413 59.7278 60 0.2722 0.5



33

6. APPLICATIONS


The technology demonstrated by this project (Visual Odometry) finds its
applications in various fields. Application domains include robotics, augmented reality,
and automotive. In GPS-denied environments, such as underwater and aerial, VO has
utmost importance. A detailed description of applications with emphasis of rover
application is given below.
6.1. In Space Rovers
The autonomous space exploration represents a new frontier in space missions,
since it allows exploring unknown planets through the eyes of unmanned robotic systems.
Following this direction, in the past years many projects were realised, in order to design
autonomous vehicles able to autonomously explore planet surfaces [7].

Figure 28: Image of Mars Curiosity Rover
Due to the distance between Mars and Earth, real time tele-operation is not a
feasible solution for controlling a planetary exploration vehicle. Consequently, planetary
rovers must be provided with a certain level of autonomy, which allows them to
autonomously move in an unknown environment while avoiding obstacles, for reaching the
targets identified by the scientists working at the ground station. The problem of reaching a
34

required target can be split in three different subproblems: the guidance, the control and the
navigation problems. The guidance and control problems are related to the definition and
control of the path followed by the rover, while the navigation problem is related to the
reconstruction of the state of the rover with respect to the external environment. One of the
fundamental aspects of the rover navigation is the localisation problem, which consists in
reconstructing the position and the orientation of the vehicle with respect to a global
reference frame usually defined by the initial conditions of the exploration. The
localisation problem is typically solved by integrating the measurements of an inertial
measurement unit or by using odometry on wheels. For the first solution, the slow motion
of the rover forces the inertial measurement units to be very accurate to correctly
reconstruct position and velocity. In addition, the drift inherent with the integration of the
measurements requires a redefinition of the global reference frame after a certain amount
of time or to reset the actual position of the rover using known landmarks position
measurements. On the contrary, odometry is a direct measure of displacement; therefore it
is not affected by drift errors. However, the reconstruction of the global motion from the
measures coming from different wheels can bring to errors in case of uneven terrain or
wheels slippage.

Figure 29: Illustration Showing Possible Wheel Slip
The decision of developing a visual odometry system for detecting the rover
movements has been taken considering the need of having a sensorial system not affected
by the classical problems of drift and slide. In fact, since the proposed system is only based
on the analysis of sequences of images acquired by the rover cameras, it only depends on
their quality. Moreover, since the movement is directly related to the acquired images, it
35

can be reconstructed in every situation, and independently from any sliding problem, as
opposed to other systems (for example, if odometry is used, the wheels slippage could
bring to a wrong movement estimation) [7].
6.2. Other Important Applications
Visual Odometry (VO) is also applied on-board of unmanned aerial vehicles of all
kinds of sizes, e.g., within the Autonomous Vehicle Aerial Tracking and Reconnaissance
[8] and Swarm of Micro Flying Robots (SFLY) [9] projects. Within the SFLY project, VO
was used to perform autonomous take-off, point-to-point navigation, and landing of small-
scale quadrocopters.
Autonomous underwater vehicle is also a domain where VO plays a big role.
Underwater vehicles cannot rely on GPS for position estimation; thus, on-board sensors
need to be used. Cameras provide a cost-effective solution; in addition, the ocean floor
often provides a texture-rich environment [10], which is ideal for computer vision
methods. Applications range from coral-reef inspection (e.g., the Starbug system [10] to
archaeological surveys [11]. VO also plays a big role in the automotive industry. Driver
assistance systems (e.g., assisted braking) already rely on computer vision and digital
cameras. VO for automotive market is in development, and its first demonstrations have
been successfully shown, e.g., within the Daimler 6-D-Vision system [12] or as part of the
VisLab autonomous vehicle [13]. Driving the development of this technology is the low
cost of vision sensors as compared to Lidar sensors, which is an important factor for the
automotive industry. VO dont require the assistance of any outside element (like satellite
in GPS) to trace the travelled path. So there is no chance of hacking or jamming the
systems. This feature of VO is very useful in Military and Spying Applications.

Figure 30: US Army Spy bot with camera
36

References
1. ADNS-3080 Datasheet, Link : http://www.avagotech.com/docs/AV02-0366EN
2. D. Nister, O. Naroditsky, and J. Bergen, Visual odometry for ground vehicle
applications, J. Field Robot., vol. 23, no. 1, pp. 320, 2006.
3. Visual Odometry: Part I: The First 30 Years and Fundamentals by Davide
Scaramuzza and Friedrich Fraundorfer. IEEE ROBOTICS & AUTOMATION
MAGAZINE, DECEMBER 2011 pp. 80-92
4. www.arduino.cc
5. en.wikipedia.org/wiki/LucasKanade_method
6. en.wikipedia.org/wiki/HornSchunck_method.
7. Fast Visual Odometry System for Planetary Exploration Rover based on Discrete
Stereo Optical Flow, M. Massari and G. Giardini, Aerotecnica Missili & Spazio,
The Journal of Aerospace Science, Technology and Systems, pp 131-142
8. J. Kelly and G. S. Sukhatme. (2007. Sept.). An experimental study of aerial stereo
visual odometry. In Proc. IFAC Int. Federation of Automatic Control Symp.
Intelligent Autonomous Vehicles, Toulouse, France.
9. S. Weiss, D. Scaramuzza, and R. Siegwart, Monocular-SLAM-based navigation
for autonomous micro helicopters in GPS-denied environments, J. Field Robot.,
vol. 28, no. 6, pp. 854874, 2011.
10. M. Dunbabin, J. Roberts, K. Usher, G. Winstanley, and P. Corke, A hybrid AUV
design for shallow water reef navigation, in Proc. IEEE Int. Conf. Robotics and
Automation, ICRA, Apr. 2005, pp. 21052110.
11. B. P. Foley, K. DellaPorta, D. Sakellariou, B. S. Bingham, R. Camilli, R. M.
Eustice, D. Evagelistis, V. L. Ferrini, K. Katsaros, D. Kourkoumelis, A. Mallios, P.
Micha, D. A. Mindell, C. Roman, H. Singh, D. S. Switzer, and T. Theodoulou,
The 2005 chios ancient shipwreck survey: New methods for underwater
archaeology, Hesperia, vol. 78, no. 2, pp. 269 305, 2009.
12. A. G. Daimler. (2011). 6d vision. [Online]. Available: http://www.6d-vision.com/
13. M. Bertozzi, A. Broggi, E. Cardarelli, R. Fedriga, L. Mazzei, and P. Porta, Viac
expedition toward autonomous mobility [from the field], IEEE Robot. Automat.
Mag., vol. 18, no. 3, pp. 120124, Sept. 2011.

37

APPENDIX-1
MATLAB code for calibration and testing:
clc
clear all

%% variable declaration
com_port='COM3';
surfacequality=0;
x_disp=0;
y_disp=0;
t_diff=0;
loop=100;
x=0;
y=0;
prev_x=0;
prev_y=0;
prev_dx=0;
prev_dy=0;
mock_dx=0;
mock_dy=0;
slope=0;
tmf=835;
prev_t=0;
t=0;
prev_XY_x=0;
prev_XY_y=0;
XY_x=0;
XY_y=0;

%% figure creation
f1=figure('NumberTitle','off','Visible','off','Name','Visual odometry');
hold on;
subplot(231);
h1=plot(0);
title('Surface Quality');
subplot(232);
h2=plot(0);
title('x displacement');
subplot(233);
h3=plot(0);
title('y displacement');
subplot(234);
h4=plot(0,0);
title('x vs y');
subplot(235);
h5=plot(0);
title('Real x');
subplot(236);
h6=plot(0);
title('Real y');

%% serial port access
s=serial(com_port,'BaudRate',2400);
fopen(s);
data=fscanf(s);
% Main loop
for n=1:loop
38


try
data=fscanf(s);

C = textscan(data, '%d%d%d%d','delimiter',';');
[dx dy sq dt]=deal(C{:});
if (isempty(dx)||isempty(dy)||isempty(sq)||isempty(dt))
continue
end
mock_dx=double(-dy);
mock_dy=double(dx);
teta=double(mock_dy*pi/(2*tmf));
t=prev_t+teta;
prev_t=t;
XY_x=prev_XY_x+mock_dx*cos(t);
prev_XY_x=XY_x;
XY_y=prev_XY_y+mock_dx*sin(t);
prev_XY_y=XY_y;

x=prev_x+dx;
prev_x=x;
y=prev_y-dy;
prev_y=y;
surfacequality=get(h1,'YData');
x_disp=get(h2,'YData');
y_disp=get(h3,'YData');
%t_diff=get(h4,'Ydata');
XY_X=get(h4,'XData');
XY_Y=get(h4,'YData');
X=get(h5,'YData');
Y=get(h6,'YData');

set(h1,'YData',[surfacequality sq]);
set(h2,'YData',[x_disp dx]);
set(h3,'YData',[y_disp dy]);
set(h4,'YData',[XY_Y XY_y],'XData',[XY_X XY_x]);
set(h5,'YData',[X x]);
set(h6,'YData',[Y y]);
set(f1,'Visible','on');
prev_dx=dx;
prev_dy=dy;
catch err
continue
end
end
%% clear serial port
fclose(s);
delete(s);
clear('s');



39

APPENDIX-2

Arduino code and explanation:
Initialise the pre-processor code (include header files and define constants)










Variable declaration






Initial setup










#include "SPI.h"
#include "ADNS3080.h"

#define AP_SPI_DATAIN 12 //MISO
#define AP_SPI_DATAOUT 11 //MOSI
#define AP_SPI_CLOCK 13 //SCK
#define ADNS3080_CHIP_SELECT 10 //SS
#define ADNS3080_RESET 9 //RESET
int _cs_pin=ADNS3080_CHIP_SELECT;
int _reset_pin=1; // set to 1 if you have reset connected
int raw_dx;
int raw_dy;
unsigned int surface_quality;
unsigned long us_prev=0, us_pres=0, us_dif=0
void setup()
{
Serial.begin(2400); // initialise the serial port to 2400 baud rate
delay(100);

// flowSensor initialization
if( initOF() == false )
Serial.println("Failed to initialise ADNS3080");

delay(100);
}
Code 3: Initial setup
Code 2: Variable declaration
Code 1: Pre-processor code
40

Main loop







Function for sending motion data




















void loop()
{
us_pres=micros();
us_dif=(us_pres)-(us_prev);
send_motion(); //Function for sending data serially
us_prev=us_pres;
}
void send_motion()
{


updateOF(); // function to read data from OF Sensor

// check for errors
if( _overflow )
Serial.println("overflow!!");

// x,y,squal
Serial.print(raw_dx,DEC); //relative displacement in X
Serial.print(";"); //Add delimiters to separate data
Serial.print(raw_dy,DEC); //relative displacement in Y
Serial.print(";");
Serial.print(surface_quality,DEC); //surface quality
Serial.print(";");
Serial.println(us_dif,DEC); //time difference between every update in s

// short delay
delay(1);

}
Code 5: Function for sending motion data
Code 4: Main loop
41

APPENDIX-3
MATLAB main code and explanation
Variable Declaration





Figure Creation



















Serial Port Access



time=0;
prev_y=0;
prev_t=0;
prev_XY_x=0;
prev_XY_y=0;

f1=figure('NumberTitle','off','Visible','off','Name',
'Visual odometry');
hold on;

subplot(221);
h1=plot(0);
title('Surface Quality');
ylabel('Surface Quality');

subplot(222);
h2=plot(0,0);
title('distance vs time');
xlabel('time in s');
ylabel('distance in cm');

subplot(223);
h3=plot(0,0);
title('velocity vs time');
xlabel('time in s');
ylabel('velocity in cm/s');

subplot(224);
h4=plot(0,0);
set(gca,'DataAspectRatio',[1 1 1]);
title('x vs y');
xlabel('x');
ylabel('y');

s=serial(com_port,'BaudRate',2400);
fopen(s);

Code 6: MATLAB Variable declaration
Code 7: Figure Creation
Code 8: Serial Port Access
42

Main Loop




























Clear Serial Port



for n=1:loop
try
data=fscanf(s);

C = textscan(data, '%d%d%d%d','delimiter',';');
[dx dy sq dt]=deal(C{:});
if (isempty(dx)||isempty(dy)||isempty(sq)||isempty(dt))
continue
end
DY=(ymf*double(dy));
DT=((1/1000000)*double(dt));

%plotting x vs y
mock_dx=double(-DY);
mock_dy=(dx);
teta=(double(mock_dy)*pi/(2*tmf));
t=prev_t+teta;
prev_t=t;
XY_x=prev_XY_x+mock_dx*cos(t);
prev_XY_x=XY_x;
XY_y=prev_XY_y+mock_dx*sin(t);
prev_XY_y=XY_y;

%plotting distance
y=prev_y-DY;
prev_y=y;
time=time+DT;

surfacequality=get(h1,'YData');
Time=get(h2,'XData');
Y=get(h2,'YData');
velocity=get(h3,'YData');
XY_X=get(h4,'XData');
XY_Y=get(h4,'YData');


set(h1,'YData',[surfacequality sq]);
set(h2,'YData',[Y y],'XData',[Time time]);
set(h3,'YData',[velocity (-DY/DT)],'XData',[Time time]);
set(h4,'YData',[XY_Y XY_y],'XData',[XY_X XY_x]);


set(f1,'Visible','on');
catch
continue
end
end

fclose(s);
delete(s);
clear('s');

Code 9: MATLAB Main loop
Code 10: Clear Serial port
43

APPENDIX-4
Step by step instruction manual for operating the project:
1. Check all connections are perfect (Do not connect batteries yet)
2. Connect the batteries.
3. Switch on the light at the optical flow sensor.
4. Double click major_project.exe file and wait until the GUI appears.
5. Set the loop count to desired value and click run which starts plotting the data.
6. Now run the bot.
7. After all the iterations are complete save the figure to the hard disk by going to
File>Save.

44

APPENDIX-5

UART (Universal Asynchronous Receiver Transmitter)
The Universal Asynchronous Receiver/Transmitter (UART) controller is the key
component of the serial communications subsystem of a computer. The UART takes bytes
of data and transmits the individual bits in a sequential fashion. At the destination, a
second UART re-assembles the bits into complete bytes.
Asynchronous transmission allows data to be transmitted without the sender having
to send a clock signal to the receiver. Instead, the sender and receiver must agree on timing
parameters in advance and special bits are added to each word which are used to
synchronize the sending and receiving units.
When a word is given to the UART for Asynchronous transmissions, a bit called
the "Start Bit" is added to the beginning of each word that is to be transmitted. The Start
Bit is used to alert the receiver that a word of data is about to be sent, and to force the clock
in the receiver into synchronization with the clock in the transmitter. These two clocks
must be accurate enough to not have the frequency drift by more than 10% during the
transmission of the remaining bits in the word.
After the Start Bit, the individual bits of the word of data are sent, with the Least
Significant Bit (LSB) being sent first. Each bit in the transmission is transmitted for
exactly the same amount of time as all of the other bits, and the receiver looks at the wire
at approximately halfway through the period assigned to each bit to determine if the bit is a
1 or a 0. For example, if it takes two seconds to send each bit, the receiver will examine the
signal to determine if it is a 1 or a 0 after one second has passed, then it will wait two
seconds and then examine the value of the next bit, and so on.
The sender does not know when the receiver has looked at the value of the bit.
The sender only knows when the clock says to begin transmitting the next bit of the word.
When the entire data word has been sent, the transmitter may add a Parity Bit that
the transmitter generates. The Parity Bit may be used by the receiver to perform simple
error checking. Then at least one Stop Bit is sent by the transmitter.
45

When the receiver has received all of the bits in the data word, it may check for the
Parity Bits (both sender and receiver must agree on whether a Parity Bit is to be used), and
then the receiver looks for a Stop Bit. If the Stop Bit does not appear when it is supposed
to, the UART considers the entire word to be garbled and will report a Framing Error to the
host processor when the data word is read. The usual cause of a Framing Error is that the
sender and receiver clocks were not running at the same speed, or that the signal was
interrupted.
Regardless of whether the data was received correctly or not, the UART
automatically discards the Start, Parity and Stop bits. If the sender and receiver are
configured identically, these bits are not passed to the host.
If another word is ready for transmission, the Start Bit for the new word can be sent
as soon as the Stop Bit for the previous word has been sent.
Because asynchronous data is self-synchronizing, if there is no data to transmit,
the transmission line can be idle.

Bits, Baud and Symbols:
Baud is a measurement of transmission speed in asynchronous communication.
Because of advances in modem communication technology, this term is frequently misused
when describing the data rates in newer devices.
Traditionally, a Baud Rate represents the number of bits that are actually being sent
over the media, not the amount of data that is actually moved from one DTE device to the
other. The Baud count includes the overhead bits Start, Stop and Parity that are generated
by the sending UART and removed by the receiving UART. This means that seven-bit
words of data actually take 10 bits to be completely transmitted. Therefore, a modem
capable of moving 300 bits per second from one place to another can normally only move
30 7-bit words if Parity is used and one Start and Stop bit are present.
If 8-bit data words are used and Parity bits are also used, the data rate falls to 27.27
words per second, because it now takes 11 bits to send the eight-bit words, and the modem
still only sends 300 bits per second.
46

The formula for converting bytes per second into a baud rate and vice versa was
simple until error-correcting modems came along. These modems receive the serial stream
of bits from the UART in the host computer (even when internal modems are used the data
is still frequently serialized) and converts the bits back into bytes. These bytes are then
combined into packets and sent over the phone line using a Synchronous transmission
method. This means that the Stop, Start, and Parity bits added by the UART in the DTE
(the computer) were removed by the modem before transmission by the sending modem.
When these bytes are received by the remote modem, the remote modem adds Start, Stop
and Parity bits to the words, converts them to a serial format and then sends them to the
receiving UART in the remote computer, who then strips the Start, Stop and Parity bits.
The reason all these extra conversions are done is so that the two modems can
perform error correction, which means that the receiving modem is able to ask the sending
modem to resend a block of data that was not received with the correct checksum. This
checking is handled by the modems, and the DTE devices are usually unaware that the
process is occurring.
By striping the Start, Stop and Parity bits, the additional bits of data that the two
modems must share between themselves to perform error-correction are mostly concealed
from the effective transmission rate seen by the sending and receiving DTE equipment. For
example, if a modem sends ten 7-bit words to another modem without including the Start,
Stop and Parity bits, the sending modem will be able to add 30 bits of its own information
that the receiving modem can use to do error-correction without impacting the transmission
speed of the real data.
The use of the term Baud is further confused by modems that perform compression.
A single 8-bit word passed over the telephone line might represent a dozen words that were
transmitted to the sending modem. The receiving modem will expand the data back to its
original content and pass that data to the receiving DTE.
Modern modems also include buffers that allow the rate that bits move across the
phone line (DCE to DCE) to be a different speed than the speed that the bits move between
the DTE and DCE on both ends of the conversation. Normally the speed between the DTE
and DCE is higher than the DCE to DCE speed because of the use of compression by the
modems.
47

Because the number of bits needed to describe a byte varied during the trip between
the two machines plus the differing bits-per-seconds speeds that are used present on the
DTE-DCE and DCE-DCE links, the usage of the term Baud to describe the overall
communication speed causes problems and can misrepresent the true transmission speed.
So Bits Per Second (bps) is the correct term to use to describe the transmission rate seen at
the DCE to DCE interface and Baud or Bits Per Second are acceptable terms to use when a
connection is made between two systems with a wired connection, or if a modem is in use
that is not performing error-correction or compression.
Modern high speed modems (2400, 9600, 14,400, and 19,200bps) in reality still
operate at or below 2400 baud, or more accurately, 2400 Symbols per second. High speed
modem are able to encode more bits of data into each Symbol using a technique called
Constellation Stuffing, which is why the effective bits per second rate of the modem is
higher, but the modem continues to operate within the limited audio bandwidth that the
telephone system provides. Modems operating at 28,800 and higher speeds have variable
Symbol rates, but the technique is the same.

48

APPENDIX-6
SPI (Serial Peripheral Interface) communication protocol:
The Serial Peripheral Interface (SPI) allows high-speed synchronous data transfer
between the ATmega368 and peripheral devices or between several AVR devices. The
ATmega8 SPI includes the following features:
Full-duplex, Three-wire Synchronous Data Transfer
Master or Slave Operation
LSB First or MSB First Data Transfer
Seven Programmable Bit Rates
End of Transmission Interrupt Flag
Write Collision Flag Protection
Wake-up from Idle Mode
Double Speed (CK/2) Master SPI Mode

Figure 31: SPI Block Diagram
49

The interconnection between Master and Slave CPUs with SPI is shown in Figure
19. The system consists of two Shift Registers, and a Master clock generator. The SPI
Master initiates the communication cycle when pulling low the Slave Select SS pin of the
desired Slave. Master and Slave prepare the data to be sent in their respective Shift
Registers, and the Master generates the required clock pulses on the SCK line to
interchange data. Data is always shifted from Master to Slave on the Master Out Slave
In, MOSI, line, and from Slave to Master on the Master In Slave Out, MISO, line. After
each data packet, the Master will synchronize the Slave by pulling high the Slave Select,
SS, line.
When configured as a Master, the SPI interface has no automatic control of the SS
line. This must be handled by user software before communication can start. When this is
done, writing a byte to the SPI Data Register starts the SPI clock generator, and the
hardware shifts the eight bits into the Slave. After shifting one byte, the SPI clock
generator stops, setting the end of Transmission Flag (SPIF). If the SPI interrupt enable bit
(SPIE) in the SPCR Register is set, an interrupt is requested. The Master may continue to
shift the next byte by writing it into SPDR, or signal the end of packet by pulling high the
Slave Select, SS line. The last incoming byte will be kept in the Buffer Register for later
use.
When configured as a Slave, the SPI interface will remain sleeping with MISO tri-
stated as long as the SS pin is driven high. In this state, software may update the contents
of the SPI Data Register, SPDR, but the data will not be shifted out by incoming clock
pulses on the SCK pin until the SS pin is driven low. As one byte has been completely
shifted, the end of Transmission Flag, SPIF is set. If the SPI interrupt enable bit, SPIE, in
the SPCR Register is set, an interrupt is requested. The Slave may continue to place new
data to be sent into SPDR before reading the incoming data. The last incoming byte will be
kept in the Buffer Register for later use.
The system is single buffered in the transmit direction and double buffered in the
receive direction. This means that bytes to be transmitted cannot be written to the SPI Data
Register before the entire shift cycle is completed. When receiving data, however, a
received character must be read from the SPI Data Register before the next character has
been completely shifted in. Otherwise, the first byte is lost.
50


Figure 32: SPI Master-Slave Interconnection