Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

- stripped out and rephrased some things for space

  • Loading branch information...
commit 8c56a5a14d434a0e1589d48798577add8c874ca4 1 parent ea87864
Michael Schultz authored
Showing with 73 additions and 96 deletions.
  1. BIN  doc/paper/report.pdf
  2. +73 −96 doc/paper/report.tex
View
BIN  doc/paper/report.pdf
Binary file not shown
View
169 doc/paper/report.tex
@@ -302,11 +302,10 @@ \subsection{Hardware}
\subsubsection{Parking Space Monitors}
-The Parking Space Monitors (PSMs) need to be able to do more than just determine
-if a vehicle is present in a parking space.
-They must be able to run on a set of batteries for an extended period of
-time, support multiple sensor types and interfaces, and wirelessly transmit
-the required data to a base station for further processing.
+A Parking Space Monitors (PSMs) must be able to do more than just determine
+if a vehicular presence.
+It must also run on batteries for an extended period of time, support
+multiple sensor types and interfaces, and transmit the required data.
For all these reasons we chose the Telos Revision B (TelosB) wireless
sensor module as the base for our PSMs.
@@ -318,20 +317,15 @@ \subsubsection{Parking Space Monitors}
\label{fig:telosb}
\end{figure}
-Shown in Figure~\ref{fig:telosb}, the TelosB provides many
-features and sensors while still managing to use little power and support
-fast wireless communications. We chose the TelosB because it includes a
-250 kbps IEEE 802.15.4 wireless transceiver; on-board temperature and light
-sensors; low power consumption; an on-board antenna; simple
-programming/collection interface; and a 10+6-pin expansion slot allowing
-analog, digital, or serial connections~\cite{moteiv:telosb}.
-
-The TelosB includes many different interfaces we could use to attach
-sensors too.
-These include analog to digital, UART, I2C, and digital connections, this
-selection gives us a very flexible platform.
-It's this flexibility that will make our system a viable option for parking
-structures.
+The TelosB (Figure~\ref{fig:telosb}) provides many features while still
+managing to use little power and support fast wireless communications.
+We chose the TelosB because it includes a 250 kbps IEEE 802.15.4 wireless
+transceiver; on-board temperature and light sensors; low power consumption;
+an on-board antenna; simple programming and collection interface; and a
+10+6-pin expansion slot allowing analog to digital, UART, I2C, and digital
+connections~\cite{moteiv:telosb}.
+This selection gives us a very flexible platform and this is what makes our
+system viable parking structures.
\begin{figure}
\begin{center}
@@ -342,71 +336,62 @@ \subsubsection{Parking Space Monitors}
\label{fig:range_finder}
\end{figure}
-There are many different types of sensors that could have been used to
-monitor if a parking space is occupied or vacant. These include infrared
-range finders, pressure sensors, and inductive sensors.
+Potential sensors to detect vehicle presence include infrared range
+finders, pressure sensors, and inductive sensors.
We chose to use the
LV-MaxSonar\textsuperscript{\textregistered}-EZ1\textsuperscript{\texttrademark}
by MaxBotix\textsuperscript{\textregistered} (hereafter ``EZ1'')
because of its price and feature set.
The EZ1 supports a wide range of standard supply voltage inputs.
-This allows us a great deal of flexibility in choosing how to power the
-EZ1.
-It can detect objects from 6 inches to 254 inches.
-This is enough range to cover the complete parking space.
+This allows a great deal of flexibility in choosing how to power the EZ1.
+It can detect objects from 6 inches to 254 inches; this is enough range to
+cover the complete parking space.
The EZ1 supports many output formats including pulse width, analog voltage,
-and serial digital.
-This gives us multiple ways to connect the same sensor depending on the
-environment~\cite{maxbotix:maxsonar-datasheet}.
+and serial digital giving us multiple ways to connect the same
+sensor~\cite{maxbotix:maxsonar-datasheet}.
\subsubsection{Base Station}
-A MacBook Pro was used as the base-station in this project.
-However, keeping with our theme of low-cost, we kept the
-requirements of the base station to a minimum by only using features found
-in any low-end Unix or Linux computer.
-The only requirements of the base station are that it be capable of
-connecting to the Internet and that it provides a USB connection.
-Because video is not a requirement, we would recommend a small, power
-efficient and cost effective plug
+Keeping with our theme of low-cost, the requirements of the base station
+are minimal.
+We only need the features found on any low-end Unix or Linux computer.
+The base station requirements are the capability to connect to the Internet
+and a USB connection.
+We recommend a small, power efficient and cost effective plug
computer~\footnote{\url{http://www.wikipedia.org/wiki/Plug_computer}}.
-The base station must be able to have IEEE 802.15.4 communications with the
-PSMs, this can be achieved by connecting a TeloB via USB and using a simple
-serial connection to allow the two devices to communicate.
+The base station must have IEEE 802.15.4 communications with the PSMs, this
+can be achieved by connecting a TeloB via USB completing the bridge between
+the sensor network and the Internet.
\subsection{Collection Software}
\subsubsection{Parking Space Monitors}
-The PSMs are powered by TinyOS.
-We chose TinyOS because it fully supports the TelosB and provides many
-features that rapidly speed-up development.
-These include mesh networking and communication protocols as well as native
-support built in for all the connection interfaces described earlier.
+Since we are using TinyOS on TelosB platforms, we are able to use the
+included mesh networking and communication protocols, as well as having
+native support for all the connection interfaces described earlier.
-The PSMs receive configuration data from the base-station and then begin
+The PSMs receive configuration data from the base station and then begin
monitoring sensor values.
-Every sample period the PSMs sample the sensors ten times and average the
-values.
-Those values are then wirelessly transmitted to the base-station every
-fifteen seconds.
+During a sampling period the PSMs reads the sensors ten times and average
+the values.
+Those values are then transmitted to the base station every 15 seconds.
One of our key design goals was wireless reliability.
-Packets containing sensor details must always make it back to the base station for processing.
-This can be very difficult in dynamic environment such as a parking
-structure, especially a multi-floored garage where line of site is
-impossible, and transmissions will attenuate through the industrial walls present in the structure.
-Therefore, alternative methods of packet forwarding must be introduced in
-order for the system to be able to operate with a single, centrally located
-base station.
-In this project, we attempted to use Collection Tree Protocol (CTP).
+Packets containing sensor details must always make it back to the base
+station for processing.
+This can be difficult in dynamic environment such as a parking structure,
+especially a multi-floored garage where line of site is impossible, and
+transmissions will attenuate through the walls.
+To overcome this, we attempted to use Collection Tree Protocol (CTP).
CTP is a dynamic point-to-sink routing protocol, which creates a tree
topology for the network through which all packets travel to the base
-station, known as the root node or sink. By creating this tree based
-topology, motes dynamically create an efficient routing method for
-collecting all data at a centralized point. CTP does not handle
-point-to-point communication, though it does provide support for
-broadcasting to all nodes~\cite{tep123:collection-tree-protocol}.
+station (the ``root node'' or ``sink'').
+By creating this topology, motes can build efficient routes for collecting
+data at a centralized point.
+CTP does not handle point-to-point communication, though it does provide
+support for broadcasting to all
+nodes~\cite{tep123:collection-tree-protocol}.
In our final implementation, due to a miscommunication about integrating
the various parts of the project, CTP was left out.
However, initial tests of a non-trivial CTP network gave indications that
@@ -414,52 +399,47 @@ \subsubsection{Parking Space Monitors}
\subsubsection{Base Station}
-The base station software has multiple functions. It was written in C so
-as to be compatible with most current versions of Unix or Linux.
-It is responsible for configuring the PSMs, monitoring their status, collecting data from them, and sending the collected data to the aggregation software over the Internet.
+The base station software has multiple functions.
+It configures the PSMs, monitors their status, collects data from them, and
+sends the data to the backend over the Internet.
Since the base station needs to communicate with the motes over IEEE
802.15.4, a TelosB is connected via USB as part of the base station.
-The TelosB is running the default BaseStation app (included with the TinyOS
-install) with only minor tweaks to support CTP.
+The TelosB runs the default BaseStation app (included with the TinyOS
+install) with only minor tweaks.
-The base-station has the ability to send configuration packets to the PSMs.
-It is through this configuration process that the PSMs are assigned their
-parking space IDs.
+The base station is able to send configuration packets to the PSMs.
+This configuration process allows the PSMs to be assigned parking space
+identifiers.
The configuration packet structure was designed to be easily extended to
support future needs.
For example, the base station could adjust sensor read rates or data
-transmission rates based on the time of day to increase PSM battery life.
+transmission rates based on the time of day to increase battery life.
The base station's primary purpose is to collect sensor readings from the
PSMs and relay it to the aggregation software.
-The data is encoded as a JSON packet (as seen in
+Once the data is collected, it is encoded as a JSON packet (as seen in
Figure~\ref{fig:clientserverjson}) and transfered via HTTP \texttt{PUT} to
the backend for processing.
\subsection{Aggregation Software}
-Data leaving the base station of a parking lot is directed over then
-Internet to our aggregation software hosted on Google's
-AppEngine~\cite{google:appengine}.
-We decided that AppEngine was an appropriate choice for several reasons:
-\begin{itemize}
- \item The service is free for light usage (testing and development).
- \item It provides a Python programming environment.
- \item It scales up easily with large datasets.
-\end{itemize}
+Data leaving the base station is directed over then Internet to our
+aggregation software hosted on Google's AppEngine~\cite{google:appengine}.
+Using AppEngine provides us with: free hosting service for light usage
+with the option to pay as usage increases, a Python programming environment
+for rapid development, and the ability to transparently scale up as usage
+increases.
-We need easy scalability if we are to have one sensor per parking space for
+Scalability is important if we are to have one sensor per parking space for
every parking lot.
Thus our backend must be able to accept, store, and recall large amounts of
current and historical data.
A traditional server model may have worked for this prototype, but if the
project starts scaling up we would quickly start running into barriers.
-AppEngine scales with demand due to their use of a data store built on top
-of Bigtable~\cite{google:bigtable}.
+
Though transparent to users of our system, this non-SQL based data store
forces some differences from a SQL based data store.
-
While queries look like SQL, they are actually ``GQL,'' a SQL-like
language.
In general this does not bring any problems, but because of the
@@ -478,7 +458,7 @@ \subsubsection{Frontend}
Our prototype frontend is an HTML interface that allows viewing information
about a parking lot.
-The user can select a lot and our frontend provides a map of the area and
+The user selects a lot and our frontend provides a map of the area and
marks lots within a two mile radius.
It also displays a ``health'' indicator giving an approximate empty-to-full
ratio, as well as a percentage and a list of full spaces and their usage
@@ -522,15 +502,12 @@ \subsection{Sensing and Sending}
\label{fig:parking_sensor}
\end{figure}
-A large amount of testing was performed on the sensing and sending portion
-of this project.
-Figure~\ref{fig:parking_sensor} shows a PSM mounted on a
-tripod.
-This set-up was used to test the system with an actual vehicle.
-This testing found issues with the sensing range of our PSMs.
-The EZ1 should support a distance up to 254-inches, however we
-were only able to detect a vehicle up to approximately 120-inches (10
-feet).
+Figure~\ref{fig:parking_sensor} shows a PSM mounted on a tripod; this
+set-up was used to test the system with an actual vehicle.
+Testing found issues with the sensing range of our PSMs.
+The EZ1 specification claims support for distances up to 254-inches,
+however we were only able to detect a vehicle up to approximately
+120-inches (10 feet).
Though this did not cause an issue detecting a vehicle, it could be an
issue with detecting smaller objects such as motorcycles.
More testing and analysis would need to be performed to determine if the
Please sign in to comment.
Something went wrong with that request. Please try again.