pin-Documentation

1
Fayoum University
Faculty of Engineering
Electrical Engineering Department
Electronics & Communications Section
Positioning Indoor Navigation
By:
Ahmed Mohamed Mokhtar
Eslam Mahmoud Raghib
Khaled AbdElNasser
Meena Bassem Nady
Supervised By:
Dr. Mohamed Hamdy

Positioning Indoor Navigation
Ahmed Mohamed Mokhtar
Eslam Mahmoud Raghib
Khaled AbdElNasser
Meena Bassem Nady
Jul, 2016
3

5
Dedication
To Dr. Maryem Fayed.

Preface
Acknowledgment
Dr. Mohamed Hamdy
As a supervisor, Dr. Mohamed Hamdy helped us at:
• Professional selection of the graduation project idea.
• Software and hardware components selection that best fits our particular use cases.
• Analytical and numerical solution to several problems we faced to be programatically efficient.
• Constructing a work plan for the project with the team leader, and helping us choose elements of
the work plan. After discussion, we have achieved the final form of our work plan and supervisors
have agreed upon. As it was:
– Introduction.
– Problem formulation.
– Description of the project.
– Feasible timetable over the research period.
– Arrangements: list of arrangements agreed on between the student and the supervisors.
• Holding team meetings. The aim of these meetings is to keep the supervisor sufficiently well in-
formed on the implementation of the project, that he can make an adequate judgment on whether
the project progresses according to the work plan.
• The supervisor (and us) discuss the work plan extensively and it is iteratively improved.
• A team leader writes a report of each meeting and sends it to all supervisors. To check the process
of the project.
Dr. Maryem Fayed
We cannot thank Dr. Maryem Fayed enough for early adoption of the idea, funding a big portion of the
project costs, giving technical advice and for believing in us.
7

8
Declaration
I hereby certify that this material, which I now submit for assessment on the programme of study lead-
ing to the award of Bachelor of Science in Electrical Engineering is entirely my own work, that I have
exercised reasonable care to ensure that the work is original, and does not to the best of my knowledge
breach any law of copyright, and has not been taken from the work of others save and to the extent that
such work has been cited and acknowledged within the text of my work.
Signed: _____________________________
Registration No.: ___________
Date: __________________

9
Abstract
This document introduces a novel idea to enable indoor localization of a vehicle that is both
cheap and accurate, and does not deviate over time like most of the alternatives, accompanying its
application as a vehicle that performs a go-to goal while avoiding obstacles and keeping an updated
map of the new obstacles and clearing the removed ones for faster and accurate navigation over time.

Contents
Contents 10
List of Figures 12
1 Hardware 15
2 Localization 17
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Localization marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Quiet margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2 Border . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3 Quiet padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.4 Alternating bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.5 Data bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.6 Parity bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Localizing the vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 Taking the picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.2 Removing noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3 Otsu Thresholding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.4 Contours Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.5 Perspective Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.6 Data extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.7 Calculating Mark/Vehicle Rotation . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.8 Calculating Accurate Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Path Planning 25
3.1 D* lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 RHS value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Inconsistency: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2.1 Underconsistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2.2 Overconsistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Server 29
4.1 WiringPi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 GPIO Utility: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Future Work 35
5.1 Alternative Localization Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10

List of Figures
2.2.1 Localization mark at (124,128) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2 Localization mark quiet margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3 Localization mark border . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.4 Localization mark quiet padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.5 Localization mark alternating bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.6 Localization mark data bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.7 Localization mark parity bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Comparison between different thresholding techniques[K.13] . . . . . . . . . . . . . . . . . 23
2.3.2 Localization mark x, y data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12

List of Acronyms/Abbreviations
AMR Autonomous Mobile Robot.
B&W Black and White
CPU Central Processing Unit.
CSS Cascading Style Sheet
GPS Global Positioning System.
HTML Hyper-Text Markup Language
IPS Indoor Positioning System.
JS JavaScript
LED Light Emitting Diode
LOS Line Of Sight.
PHP Hypertext PreProcessor
SI Units International System of Units.
USB Universal Serial Bus
w.r.t. with respect to.
w/o without.
Wi-Fi Wireless Fidelity
13

14 List of Figures
Introduction
Over the last years, indoor localization and navigation is becoming a hot topic. With the increasing
number of buildings, indoor positioning and navigation has turned out to be more important than out-
doors.
In this paper, we evaluate an indoor image-based positioning system. We have a vehicle that can get
guidance information from a camera looking upwards to a matrix of printed 2d barcodes that provide
location and orientation information for the vehicle.We are going to learn from this project:
• Wireless communication with the Raspberry Pi.
• Image processing techniques to extract and read 2d barcodes out of an image, and use information
about its positioning, rotation, and included data to predict the location of the vehicle.
• Programming Raspberry Pi in Python language.
• Get information about some algorithms such as “D* lite” algorithm.
• Controlling motors by Raspberry Pi with H-bridge.
• PHP, HTML and android programming.
• Interfacing Raspberry Pi with other hardware component such as H- bride ,ultrasonic sensor and
camera.
• learn the Linux command-line to let us navigate through the folder and file system on the Rasp-
berry Pi.

Chapter 1
Hardware
The main hardware components used are:
• Raspberry Pi.
• Wi-Fi - USB Module.
• Ultrasonic HC-SR04 range finder module.
• USB Webcam.
• L298 H-Bridge Module.
• Car Chassis.
• Battery and power bank.
• Buzzer and indicator LED.
15

Chapter 2
Localization
2.1 Introduction
One of the biggest problems with indoor navigation is the urge to have a reliable way of determining
the location of the vehicle under operation at any point of time. There are alot of techniques already in
use, each optimizing for a particular use case.
Some of them optimize for price for economical devices, such as Wheel Encoders of two-wheeled
vehicles, which is notorious of being more erroneous the more the vehicle moves, as errors add up
because of slipping wheels and the likes.
Others optimize for correctness, as does Artificial GPS (Global Positioning System). While being too
expensive and most of the time used solely in labs, its main selling point is being correct with the same
small error every time a reading is fetched.
There are another techniques inbetween which make a trade off between expense and correctness,
as combination of Accelerometer, Gyroscope, and Compass can do. They are less prone to error that
Wheel Encoders but small errors can still accumulate on the long term if not regularly corrected.
We needed a localization method for our use case that can be cheap, correct over time, fast, and not
to only calculate the location of the vehicle, but also its orientation.
So, we developed a technique that exactly does this. It is pretty cheap, just costs printing some
papers and a camera, very accurate with an error in the millimeter scale, can operate with, theoretically,
an infinite number of devices at once, and can be used to calculate the orientation pretty easily and
accurately too without having error near magnetic fields as in the case of using Compass.
2.2 Localization marks
Our solution was to print marks, as one shown in Figure 2.2.1, on a flat surface above the vehicle looking
downwards, and a camera on the vehicle looking upwards at the marks.
In the expense of not tracking height, at least not directly, and having to always have an LOS (Line
of Sight) between the vehicle camera and the flat surface above, one can pretty easily determine the
location and orientation of the vehicle within a time window of milliseconds and with great accuracy.
Almost sufficient for our application under investigation.
The mark to be used should have some essential features to be used for location and rotation enquiry,
namely:
• Unique, so as for seemingly similar marks to be easily filtered away and avoid wrong readings.
• Orientation-wise, so as to be able to read the data correctly and calculate the rotation of the vehicle
with respect to it.
17

18 CHAPTER 2. LOCALIZATION
Figure 2.2.1: Localization mark at (124,128)
Figure 2.2.2: Localization mark quiet margin
• Mirror-wise, as it is easy to encounter a miror of an existing mark that can inject malicious reading
that mislead the vehicle.
• Easy to process. The easiest form to be processed would be binary data.
To suffice all these requirements, the mark is egineered to have the following:
2.2.1 Quiet margin
A white space around the mark, as shown in Figure 2.2.2, that makes extracting the mark by searching
for rectangular contours easy. Covering the quiet margin can confuse the image processor extracting
contours out of picture, leading to extracting non-rectangular contour instead of the rectangular mark,
thus it is automatically filtered away and the mark data is not read.
2.2.2 Border
A border around the mark, as shown in Figure 2.2.3, that is used to aid extracting the mark out of picture
using contour extraction, as mentioned above, and its line width is used to determine the density of the
mark. and determine how many bits are in the mark. In this application, we use 16 bit marks only.

2.2. LOCALIZATION MARKS 19
Figure 2.2.3: Localization mark border
Figure 2.2.4: Localization mark quiet padding
2.2.3 Quiet padding
Shown in Figure 2.2.4, quiet padding is a white border inside the border of the mark, passing through
just three sides, so as to make it possible to determine the orientation of the mark for data reading
correctness and enabling the mark to be used to determine the rotation of the vehicle relative to it. It is
also viable at checking that the data density of the mark is right, sort of.
2.2.4 Alternating bits
Where the fourth side of the quiet padding is a set of alternating bits, as shown in Figure 2.2.5. These
bits are arranged that the alternating bits start with a black bit in the leftmost. The last one is always
white irrespective of what should it have been in the alternating sequence. Obviously it is apparent
when there is an odd number of alternating bits, thus the rightmost one should have been black. These
bits have two rules by essence. First of them is ensuring that data density is well-chosen, as they are
highly probable to fail if read with different density. Second is to check whether the mark is mirrored
or not, as a mirrored mark is not far from possible in typical locations, especially next to a mirror, thus
filtering it out and not reading erroneous data nor waste precious CPU (Central Processing Unit) time.
They also play an important rule at detecting the orientation of the mark with the quiet padding.

Figure 2.2.5: Localization mark alternating bits
Figure 2.2.6: Localization mark data bits
2.2.5 Data bits
The portion of the mark containing the real data, shown in Figure 2.2.6. Data here is the (x,y) location
this marker is supposed to present. This is the only portion of the mark that can have any combination
of bits in it. Data is encoded from left to right, with the most significant bit in the top left of the area,
and the least significant bit in the bottom right of it.
2.2.6 Parity bits
As shown in Figure 2.2.7, odd double parity is used to check the consistency of data bits of the mark,
especially when printed on reflective materials. Odd parity is chosen so as to be at least one black block
per row/column, which is harder to be erroneous than an all-white data-parity bits state. Parity bits add
an additional correctness insurance check on the mark plus data consistency check. Erroneous marks
are better filtered away than being used thus injecting false data that, can times, can cause catastrophic
results.
2.3 Localizing the vehicle
To localize the vehicle using an picture of the marks above it, one should pass through several steps to
get the actual position and rotation precisely:

2.3. LOCALIZING THE VEHICLE 21
Figure 2.2.7: Localization mark parity bits
2.3.1 Taking the picture
This is the easy part. Unfortunately, taking a picture while the vehicle is moving is not always a good
idea, especially for cameras with long exposure time. This may limit when and how the vehicle can
detect its location and orientation of it. Luckily, this problem can be solved by investing in a faster
camera to be able to detect its location at any time even if it is in the middle of a movement.
2.3.2 Removing noise
First of all, we only expect white and black bits, thus converting the picture to B&W (Black and White)
can weaken other color components and clearing some of the noise rather than depending on one com-
ponent only.
There may be still some point noises that are seemingly subtle, but can greatly degrade reading
accuracy, thus comes the urge to blur the picture. Blurring the picture averages each pixel with its
surroundings, thus greatly immuning the picture against single-pixel noises, but overly blurring can
remove important details from it. 5 × 5 kernel size for blurring seems to be good enough.
2.3.3 Otsu Thresholding
To digitize the data in the picture, thresholding is important to decide what is the limit between black
and white. Choosing the right threshold is vital for accurate readings. Unfortunately, there is no single
thresholding value that can be good at all environments/times, thus dynamic thresholding techniques
emerged. One of the most famous ones is Otsu’s method.
Otsu’s method assumes there are two and only two peaks in the graph of color brightnesses’ fre-
quencies, or else, the thresholding value may be suboptimal. Some times, this is tolerable, but at others,
the effect is too strong to be neglected. This may happen when there is light headed at the camera or
any reflective materials shining, or at dark places where white bits are hardly recognisable from black
ones, thus biasing the threshold value and making reading the sign harder.
To implement Otsu’s thresholding, the first step is to make an array of number of pixels per bright-
ness value in the greyscaled version of the taken picture[Gre10], coded from 0 to 255. Then, the trick is
to minimize the “Within Class Variance” for different values of threshold. But before we calculate it for
some threshold, we should at first define Weight (W ), Mean (µ), and Variance (σ2).
Wx =
x
Ni
number of pixels
(2.3.1)

Where:
• Ni : Number of pixels with brightness i,
• x: A set of the brightnesses under test.
µx =
x
i · Ni
x
Ni
(2.3.2)
σ2
x =
x
(i − µx )2
· Ni
x
Ni
(2.3.3)
To find the optimal value, we calculate for all possible values of threshold the Weight, Mean and Vari-
ance for both the set of brightnesses above (foreground) and below (background) the chosen threshold
value. Then, it is time to calculate the Within Class Variance (σ2
W ) of the two sets using the following
equation:
σ2
W = Wbσ2
b +Wf σ2
f (2.3.4)
Where:
• Wb : Weight of the background set of brightnesses,
• σ2
b
: Variance of the background set of brightnesses,
• Wf : Weight of the foreground set of brightnesses,
• σ2
f
: Variance of the foreground set of brightnesses.
• b = {0,1,2,. . . ,threshold value}
• f = {threshold value + 1,. . . ,254,255}
We then choose the value of threshold that gives the minimum value of σ2
W , and use this value to
threshold the picture thus getting a pretty sharp picture that can be analyzed to check whether some
pixel denotes one or zero.
As shown in Figure 2.3.1, Gaussian filterring (blurring) the image, then Otsu thresholding it gives
the clearest output given that, as shown in the histogram, two and only two peaks are there in the image.
Otherwise, threshold value may deviate and non-accurate threshold value will be chosen.
2.3.4 Contours Extraction
The next step to do is to extract the markers from thresholded picture. This is mainly done by extracting
all the closed contours of the picture, and further filtering them. A contour here is a line surrounding
a white/black shape which in turn is surrounded by another shape(s) of the complementary color. This
whole process is to help determine where the borders of markers in the picture are. We then exclude
all shapes with extremely small areas. Next, we filter out all contours that does not have exactly four
vertices. Sides are approximated with a tolerance of small percentage of the periscope of the shape (e.g.
2%).

2.3. LOCALIZING THE VEHICLE 23
Figure 2.3.1: Comparison between different thresholding techniques[K.13]
Figure 2.3.2: Localization mark x, y data
2.3.5 Perspective Transformation
As we extracted all four-sided shapes from the picture, it is time to do the real data extraction, but
before we can really do so, we should first transform this irregular shape into a square. There comes the
importance of perspective transformation. It maps the vertices of the shape to another four points of a
regular square, and stretches the contents of the inside of the old shape into the new square. Thus, if
the shape was really a mark, what we will have is a flat mark that can be easily processed by computer
without any further image processing.
2.3.6 Data extraction
After we get a picture of the mark, we can easily extract data from it and verify its correctness as a mark
and that the data is not tampered with for any reason. In our application, we use 16 bit marker to store
its location, and, as shown in Figure 2.3.2, we use the most significant 8 bits for storing x location, and
the least significant 8 bits for storing the y location.

2.3.7 Calculating Mark/Vehicle Rotation
In the last step, we must have known which side of the mark is heading up, thus we can know the
orientation of the mark, which is the negative of the vehicle orientation. A simple solution to this
problem is to find the center point of the left and right sides of the mark, which, when connected
together, form a line whose angle with the x-axis equals the angle of the mark to the same axis.
2.3.8 Calculating Accurate Location
The last step at this procedure is to calculate the real location based on all the information given above.
Known the center of the mark in the picture (the average of its original vertices), the center of the picture,
one can easily calculate the length and orientation of the line connecting these two points. Given these
information, accurate location can be easily calculated using this equation:
Actual Location = Marker Reading −
Line Distance
√
Marker Area
· sin (Marker Rotation + Line Rotation) (2.3.5)
This location is in units of mark side length, thus knowing the real physical side lengths of marks it
can be converted to physical length units.

Chapter 3
Path Planning
Autonomous Mobile Robot (AMR) has been widely used in exploration and navigation especially where
static, dynamic and unknown environment is involved.
Consider a goal-directed robot-navigation task in unknown terrain, where the robot always observes
which of its eight adjacent cells are traversable and then moves with cost one to one of them. The robot
starts at the start cell and has to move to the goal cell. It always computes a shortest path from its current
cell to the goal cell under the assumption that cells with unknown blockage status are traversable. It
then follows this path until it reaches the goal cell, in which case it stops successfully.
Some definition that we have:
• g(x) is the cost so far from the start node to the current node
• h(x) is the heuristic being used to estimate distance to the goal
• Children[] is a list of children nodes or nodes connected to the current node
• LPA (lifelong planning A*)
• Open list : List of nodes that need to be examined
• Priority Queue sorted by f(x)
• f(x) = g(x) + h(x)
• closed list : List of nodes that have already been visited
What does we mean by LPA: is an incremental version of A*. It applies to finite graph search
problems on known graphs whose edge costs increase or decrease over time
• This will be the first algorithm we explore as it is the foundation of D* Lite
• The idea is that given a goal node you can find a path by backtracking to the start node by mini-
mizing the RHS value. RHS(right hand side)
• Because of this we do not need to manage a Closed List (theoretically)
So we have to get know about how A* is working quickly
• There is four kinds of data structure Graph ,node ,open list and closed list each on of them is used
to determine the kind of the check in path finding algorithms .
25

26 CHAPTER 3. PATH PLANNING
• The search requires 2 lists to store information about nodes 1) Open list (O) stores nodes for
expansions 2) Closed list (C) stores nodes which we have explored.
This flow chat describe the process of A*
For nodes :
Openlist . Clear ( ) ; C l o s e d L i s t . Clear ( ) ;
currentNode = n i l ;
startNode . g ( x ) = 0 ;
Openlist . Push ( startNode ) ;
While currentNode != goalNode
currentNode = OpenList . Pop ( ) ;
f o r each s in currentNode . Children [ ]
s . g ( x ) = currentNode . g ( x ) + c ( currentNode , s ) ;
OpenList . Push ( s ) ;
end f o r each
C l o s e d L i s t . Push ( currentNode ) ;
End while
In A* we know that
List must also track the source parent of the nodes it contains and When the goal node is placed on
the closed list the algorithm terminates
3.1 D* lite
Based on A* – Store pending nodes in a priority queue – Process nodes in order of increasing objective
function value
However, when the search space is altered and costs are changed they’ll handle these inconsistencies.
• Incrementally repair solution paths when changes occurs

3.1. D* LITE 27
• The idea is that given a goal node you can find a path by backtracking to the start node by mini-
mizing the rhs value
3.1.1 RHS value
This value is known as right hand side which equal to the cost of the parent of a node plus the cost to
travel to that node By comparing this value to the cost to the node we can detect inconsistencies
Consistent ⇒ g = rhs
Inconsistent ⇒ g rhs
g(x) = A+B
rhs(x) = g(x’) + c(x’,x) = A+B
Under normal circumstances g(x)==rhs(x)
This is known as locally consistent
Cost changed dynamically g(x) = A+B
rhs(x) = g(x’)+c(x’,x) =A+∞ = ∞
g(x) != rhs(x) This is called locally inconsistent
3.1.2 Inconsistency:
Inconsistency falls into two categories:
3.1.2.1 Underconsistency
• Under Consistent occurs when g(x) < rhs(x) is called underconsistency
• When a node is found to be underconsistent that means that the path to the that node was made
to be more expensive.
• Nodes found to be underconsistent will need to be reset and paths completely recalculated
• All nodes in the Open List are locally inconsistent
3.1.2.2 Overconsistency
• g(x) > rhs(x) is called overconsistency
• the idea of overconsistency is also used to manage the open list by exploiting the fact that an
overconsistant node implies that the shortest path has been found to that node.
We have some variables in D* LITE
• g(x) is the cost so far from the start to the node
• h(x) is the heuristic estimating the cost from x to the goal
• rhs(x) = min(g(x’)+c(x’,x)) where x’ are the parents of x
• key(x) is a value used to sort the open list
• Children[] is a list of node that can be advanced to from x
• Parents[] is a list of nodes from which you can advance to x
The key : the key of a node is a value that is going to be used to sort the open list by

Chapter 4
Server
The apache2 server is installed and running on the RaspberryPi, hosting the server that’s used to control
everything.
The server is built using:
• HTML5/CSS3 : For the site content and look, styles, colors,....
– Android fonts were used instead of icons for the manual controls.
– Fieldsets were used to make the group-box-like look.
– CSS was used to control the font colors, styles, border radius, hover effects,.....
• Bootstrap : was used to make the mobile friendly website style with the manual controls on the
top of the page, the logo is also hidden in the mobile view to give more space to the manual
controls to be on the top of the page and take most of the space.
• Javascript : Had a few small but effective tasks like
– showing the selected value for the range input of the speed/brightness control, and sending
the command immediately.
– Loading all the links for the commands in a hidden iframe 0x0 (width x height) so there will
be no need for refreshing the page/ redirecting to the same page for each command. That
was very useful for the mobile view.
• PHP : did most of the work. It was used to build the API. The API is quite simple and it contains
just the basic features required for our project.
The server files in the raspberry pi are located in /var/www/html/
Below is a description of what each file does
• /img/favicon.ico : The favicon for the server website
• /img/logo.png : The logo of PIN.
• /img/hw-connections.png: The hardware connections, includes the pinout of the raspberry pi
GPIO pins, and their connections with the other components, including the H-Bridge, Buzzer,
Ultrasonic sensor, Indicator led, Front Leds.
• /scripts/bootstrap.min.js : The javascript file used for the bootsraping (for the mobile friendly
website)
29

30 CHAPTER 4. SERVER
• /scripts/jquery.min.js : The javascript file for the JQuery, a little script was written in JQuery used
for loading the log on page refresh.
• /scripts/jscript.js: contains functions for loading all the commands in the iframe without reaload-
ing the whole page. These functions include
– function setSpeedValue(newValue); gets input from the range input and directly changes the
value in % written in front of it, and sends command to the GPIO to set the speed to given
input, all in the hid
– function setBrightnessValue(newValue); similar as above, but for brightness for the front
lights.
– function loadWithoutRefresh(url); Loads the given url in the iframe so the page won’t have
to be reloaded.
– function goto_x_y_js(); sends the required destination without reloading the page.
• /styles/bootstrap.min.css : minimum styles required for using the bootstrapping for the mobile
friendly website.
• /styles/MaterialIcons-Regular.ttf : fonts for the icons used in the server, including the directions,
stop, buzzer, ....
• /styles/MaterialIcons-Regular.woff : same as above
• /styles/MaterialIcons-Regular.woff2 : same as above
• /styles/styles.css : contains the styles for everything in the websites, and how it looks, the most
important styles include
– Body : color, background, font
– Iframe : no border,
– Fieldset : border color, border radius, padding, ...
– Tables : different radius for the controls, and other controls, log,....
– Hover effect for icons and URL, including changing background color with transition effect,
– Material design fonts settings (color, size, background color, ....)
• Available_options.php : A simple page that includes mini documentation on how to use the server
and how the URL should look like
• Check_connection.php : A page that does literally nothing, except for printing ‘ok’. That is useful
for the android app to make sure that the ip address used belongs to the Raspberry Pi. If the
response is correct, then the phone is connected to the raspberrypi successfully.
• Command.php : One of the core files of the API, and it is the main interface file. It takes the
commands form the url, and takes actions according to them, using functions from other files.It’s
used by index.php and the android app.For index.php, it’s loaded by the buttons in an invisible
iframe, so there will be no need to refresh the page after each click. For the android app, a similar
approach was used, it loads the url in an invisible webview on button clicks.
The url is usually something in the format command.php?var_1=val_1&var2=val_2 with $_GET[‘var_1’].
The number of variables in the url varies according to the number of parameters. The first pa-
rameter is usually mode, the next parameters depend on the mode, and the number of parameters
required for the functions. There are 5 modes:

31
– Setup:
∗ Used to define a pin mode as input, output, pwm or clock mode, and additionally can set
the internal pull-up/down resistors to pull-up, pull-down or none, requires parameters
(pin&dir).
∗ setup, write and pwm, were used in the early development stages while trying to make
sure that the basic command line interface with the server is working. They are not
actually used in the application anymore, but since they are kept and are accessible
from the URL in case they were needed for future development.
∗ Ex:
· command.php?mode=setup&pin=6&dir=output
· command.php?mode=setup&pin=12&dir=pwm
∗ Note : all the pins are using BCM numbering as in GPIO18 ,BCM stands for Broadcom
SOC Channel. BCM was used because gpio command line utitliy only supports BCM
and wiringPi pinouts (more details about wiring pi in the next section)
– Write:
∗ Write the state of the output pin as 1 or 0, requires parameters (pin&state)
∗ Ex:
· command.php?mode=write&pin=6&state=1
– PWM:
∗ Set the value for the pwm of the pin, requires parameters(pin&duty). The value for duty
is (0-1023), but it’s modified in the code to get value from 0 to 100, and multiply by 10.
∗ Ex:
· command.php?mode=pwm&pin=12&duty=60
– Func:
∗ Executes functions defined in functions.php, with parameters if required, the functions
are listed in available_options.php
∗ Ex:
· command.php?mode=func&func=car_stop
· command.php?mode=func&func=set_speed&duty=50
– Dest:
∗ Sets the destination for the car, given the new destination as x and y
∗ Ex:
· command.php?mode=dest&dest_x=130&dest_y=129
• Constants.php : contains some constants used by other files/functions the constants include pin
numbers for the motors control (the pins connected to the H-Bridge), leds and buzzer, location of
log file, car destination file
• Functions.php : Another core file of the API. it contains the functions executed by command.php.
Most of these functions just execute 1-line shell commands using wiring pi gpio utility.these func-
tions are only accessible via the command.php, and within the file by other functions. There is
no other interface for these functions.

32 CHAPTER 4. SERVER
– There are functions for directly interfacing the car, including forward, back,right,left, stop,
changing speed, changing front lights brightness, buzzer on/off, write to log, clear log,set
destination, ... and a few more that are just used to set pin high/low just to make other
functions shorter.
• Hw_connections.php: contains an image of the hardware connections to the Raspberry Pi. It
shows the whole 40 pins, and the connections, that can be helpful in case something with any of
the connections went wrong, it can be easily recovered.
• Ie_reject.html : if your browser is Internet Explorer, you’re redirected to this page telling you that
IE is not supported. The page styles are not displayed correctly (as expected),
• Index.php : The main interface for the server, and the home page for the server. It contains the
manual controls, speed and brightness control, destination control, and it shows the current map
with the car and the obstacles.
• Map.php : loads the map from it’s location, and displays a blank black page instead of error page
in case the map image is not found. That can happen if the program has not run yet and no image
for the map is created yet.
• Radar.py : is executed by a file to get readings from the ultrasonic sensor and display them in the
page, not very important any more in the manual mode, but still kept for possible uses in future
development.
• Terminal.php: connects directly to the raspberrypi interactive shell using shellinabox, you still
need to enter the username and password for the Raspberry Pi
– https://github.com/shellinabox/shellinabox
– http://www.tecmint.com/shell-in-a-box-a-web-based-ssh-terminal-to-access-remote-linux-servers/
4.1 WiringPi
Wiring Pi is a library. It simplifies a lot using the Raspberry Pi GPIOs (one command instead a long
process). It also means that you can use it in any of your C codes. However, we won’t build and use a
C program but the Gpio utility.
4.1.1 GPIO Utility:
WiringPi is a GPIO access library written in C for the BCM2835 used in the Raspberry Pi. It’s released
under the GNU LGPLv3 license and is usable from C and C++ and many other languages with suitable
wrappers (See below) It’s designed to be familiar to people who have used the Arduino “wiring” system1
WiringPi includes a command-line utility gpio which can be used to program and setup the GPIO
pins. You can use this to read and write the pins and even use it to control them from shell scripts.
gpio utility is used to interface the Raspberry Pi with the hardware, like the motors, buzzer, leds, ....
. it’s used by the php from the server and also from the python script to control the car. There are some
libraries other than Wiring Pi for interfacing the GPIO, like RPi.GPIO, and gpiozero, but Wiring Pi had
the advantage of the gpio command line utility, that doesn’t need root access, and can be easily used
from the php. gpiozero is the easiest to interface in python, but comflicts with gpio utility.
The command line interface for the gpio utility is quite easy, there’s a list of all available commands
at http://wiringpi.com/the-gpio-utility/, what we needed to know is only a little part of it like that
gpio -g ...

4.1. WIRINGPI 33
The optional -g flag causes pin numbers to be interpreted as BCM_GPIO pin numbers rather than
standard wiringPi pin numbers. We used this parameter to use the BCM instead of the wiring pi pinout,
because the wiring pi pinout is specific to only wiring pi library, and cannot be used for any other
interfaces.
gpio mode <pin> in/out/pwm/clock/up/down/tri
This sets the mode of a pin to be input, output, pwm or clock mode, and additionally can set the
internal pull-up/down resistors to pull-up, pull-down or none. We only used out and pwm.
gpio write <pin> 0/1
This sets an output pin to high (1) or low (0)
gpio pwm <pin> <value>
Set the pin to a PWM value (0-1023 is supported)
Examples :
• gpio -g mode 17 out
• gpio -g write 17 1
• gpio - g mode 12 pwm
• gpio -g pwm 12 750
Languages used:
1. Python - OpenCV (For the image processing)
2. HTML
3. CSS
4. PHP
5. Javascript
6. Java for Android

Chapter 5
Future Work
5.1 Alternative Localization Technique
Also we succeeded in determining the location and the angle of the vehicle using a super cheap com-
ponents, a camera and a punch of printed papers, it was not perfect. It can fail at locations with bad
lightning, and cannot work without a LOS between the camera and the flat surface, thus we created
a different technique that can be used in conjunction with the first one and to get the best of the two
worlds, and it is relatively cheap, too.
The idea is to have at least four ultrasonic beacons at predetermined locations. They are controlled
using a master processing unit that coordinates their timings, and connected together with wires, that
are way more faster at broadcasting information than sound does, thus almost error free timing can be
done out of the box.
Beacons radiate ultrasonic signals with a constant amount of time inbetween. But because not all
beacons are necessarily on the same distance from the vehicle, and because of the speed of sound, there
will be a shift between subsequent signals, thus enabling the vehicle to analyze these differences, and
the given information about the locations of beacons to estimates it current location.
A problem with this technique with respect to our original one:
• It may be not as accurate because speed of sound changes in different environments because of
different factors like temperature, humidity, ...etc.
• Because it requires perfect timing of the signals and readings, which can add errors over the line.
• For the ultrasonic to be able to run on a wide range of devices, we have an upper limit of 21 kHz,
which is, whilst not hearable by most people, adults, babies and dogs can hear it and it may be
annoying, especially if it was continuous.
• It takes time to wait to listen for at least four beacons, and identify them apart, which is slow
because we should wait sufficient amount of time between signals because they may arrive earlier
or later than subsequent signals, and it takes time to send identification information over sound
signals which adds to the sum.
• You can calculate your location only, not the rotation. At least not w/o hacks.
• Requires initial setup between the device and the beacons.
• A complex arrangement of the beacons is a necessity for a solution to exist every time. If their
locations 3d plot is symmetric somehow, there will be cases where solutions does not exist, thus
complicating setup.
35

36 CHAPTER 5. FUTURE WORK
• Measuring location while moving can alter result greatly, because of delays between signals.
• It is, maybe, a bit more expensive.
In contrast, this technique have over the original one:
• It does not require to maintain a LOS with any surface. You can determine your location anywhere
near the beacons.
• It can calculate altitude as well, not just (x,y) coordinates.
• Works with arbitrary devices as well, like mobile phones, laptops, or any device with a capable
microphone, not only our particular use-case.
• Have less interferences, as there is hardly any sound in this frequency. In contrast, not-good
lightening can cause the original technique to stall.
The advantages, maybe, not a lot compared to what you lose, but sometimes it is worth the price, and
some of these advantages are killer features for other applications that you must pay for, and they are
easily affordable, mostly because setup time is required only once.
The idea is fairly simple. In reality, it is based on the same principle upon which GPS stands, but
with some modifications to come over timing problem, and trading a little increase in the error for
consistency and ease of application.
After every beacon sends its signal in the predetermined time, the vehicle listens to all the signals
sent through a microphone, then it records the deviation of the time frame at which every beacon should
have sent its signal.

Bibliography
[Gre10] Dr. Andrew Greensted, Otsu Thresholding, http://www.labbookpages.co.uk/
software/imgProc/otsuThreshold.html, June 2010.
[K.13] Abidrahman K., Image Thresholding, http://docs.opencv.org/master/d7/
d4d/tutorial_py_thresholding.html, September 2013.
37

pin-Documentation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to pin-Documentation

Similar to pin-Documentation (20)

pin-Documentation