Table of Contents

1. Introduction......................................................................................................V

1. 1 Executive Summary....................................................................................V

1. 2 Motivation..................................................................................................VI

1. 3 Budget......................................................................................................VII

1. 4 Timetable for Completion for Senior Design 1 & 2......................................X

2. Specifications & Requirements.....................................................................XIII

2. 1 Requirements..........................................................................................XIII

2. 2 Specifications..........................................................................................XIV

2. 2. 1 Sensor.................................................................................................XIV

2. 2. 2 Transceiver..........................................................................................XIV

2. 2. 3 Power...................................................................................................XV

2. 2. 4 Display..................................................................................................XV

2. 2. 5 Server...................................................................................................XV

2.2.6 Microcontroller.......................................................................................XVI

3. Research.....................................................................................................XVII

3. 1 Sensor....................................................................................................XVII

3. 1. 1 Sonar.............................................................................................XVIII

3. 1. 2 Infrared..........................................................................................XXVI

3. 1. 3 Video Detection............................................................................XXXII

3. 1. 4 Light Sensor................................................................................XXXVI

3. 1. 5 Heat Sensor...............................................................................XXXVII

3. 1. 6 Fiber Optic Sensor.............................................................................XL

3. 1. 7 Loop Sensor.....................................................................................XLI

3. 1. 8 Strain Gauge Sensor........................................................................XLI

3. 2 Transceiver............................................................................................XLIII

3. 2. 1 Bluetooth........................................................................................XLIV

3. 2. 2 Wi-Fi................................................................................................XLV

3. 2. 3 ZigBee.............................................................................................XLV

3. 2. 4 6loWPAN......................................................................................XLVIII

1

3. 2. 5 Z-wave.........................................................................................XLVIII

3. 2. 6 DASH7...........................................................................................XLIX

3. 2. 6 Other Notable Options.........................................................................L

3. 3 Networking...............................................................................................LIV

3. 3. 1 Wired Networks................................................................................LIV

3. 3. 3 Mesh Networks..................................................................................LV

3. 3. 4 Compare and Contrast.....................................................................LVI

3. 3. 5 The “Park Sense” Network...............................................................LVI

3. 4 Power......................................................................................................LVII

3. 4. 1 Camera Based System....................................................................LVII

3. 4. 2 Sensor Based System....................................................................LVIII

3. 4. 3 Compare and Contrast.....................................................................LIX

3. 5 Image Processing.....................................................................................LX

3. 5. 1 Overview using Image Processing....................................................LX

3. 5. 2 Calibration File..................................................................................LXI

3. 5. 3 Indexed Array...................................................................................LXI

3. 5. 4 Image Histograms..........................................................................LXIII

3. 5. 5 OpenCV.........................................................................................LXIV

3. 5. 6 Computer Vision..............................................................................LXV

3. 5. 7 Image Noise....................................................................................LXV

3. 6 Display...................................................................................................LXVI

3. 6. 1 LCD Display...................................................................................LXVI

3. 7 Software packages..............................................................................LXVIII

3. 7. 1 Java...............................................................................................LXIX

3. 7. 2 Visual Basic.....................................................................................LXX

3. 7. 3 C#.................................................................................................LXXII

3. 8 Possible Features................................................................................LXXIII

3. 8. 1 Website........................................................................................LXXIII

3. 8. 2 Smartphone Application...............................................................LXXIV

3. 8. 3 Increased Nodes and Project Scaling..........................................LXXIV

3. 8. 4 Additional Displays.......................................................................LXXV

2

3. 8. 5 Summary of Features...................................................................LXXV

3.9 Microcontroller.....................................................................................LXXVI

3.9.1 Processor Speed...........................................................................LXXVI

3.9.2 Peripherals.....................................................................................LXXVI

3.9.3 Other Microprocessor Information................................................LXXVII

3.9.4 Part Selection...............................................................................LXXVII

3.9.4.1 RabbitCore.................................................................................LXXVII

4 Methods.....................................................................................................LXXXI

4. 1 Research Methods..............................................................................LXXXI

4. 2 Design Methods..................................................................................LXXXI

4. 3 Project Management...........................................................................LXXXI

4. 4 Implementation..................................................................................LXXXII

4. 5 Related Projects................................................................................LXXXIII

4. 5. 1 Innovative Technologies’ VDMs................................................LXXXIII

4. 5. 2 Smart Parking Garage...............................................................LXXXIII

4. 5. 3 eSPARC....................................................................................LXXXIII

5. Design....................................................................................................LXXXIV

5. 3 Transceiver.......................................................................................LXXXIV

5. 3. 1 Sensor Node Mounting..............................................................LXXXIV

5. 3. 2 XBee-Microcontroller Communication......................................LXXXVII

5. 3. 3 XBee Configuration.................................................................LXXXVIII

5. 3. 4 Communication between Transceivers.....................................LXXXIX

5. 3. 5 Transceiver Design Summary...........................................................XC

5. 4 Display...................................................................................................XCII

5. 5 Software................................................................................................XCVI

5. 5. 1 GUI................................................................................................XCVI

5. 5. 2 Website........................................................................................XCVII

5. 5. 3 Image processing..........................................................................XCIX

5. 6 Server.........................................................................................................C

5.7 Design Summary........................................................................................CI

6. Prototype......................................................................................................CIV

3

6. 2 Transceiver.............................................................................................CIV

6. 2. 1 Total Cost of Transceiver.................................................................CIV

6. 2. 2 Transceiver Prototype in the Sensor Node.......................................CV

6. 2. 3 Transceiver Prototype at the Server................................................CVI

6. 2. 4 Prototype Layout.............................................................................CVII

6. 3 Display..................................................................................................CVIII

7. Testing..........................................................................................................CXI

7. 1 System Integration..................................................................................CXI

7. 1. 1 The Setup........................................................................................CXI

7. 3 Transceiver...........................................................................................CXIII

7. 3. 1 Transceiver Software Testing........................................................CXIII

7. 3. 2 Sensor Node Transceiver Testing.................................................CXIII

7. 3. 3 Server / Access Point Transceiver Testing....................................CXIII

7. 3. 4 XBee to XBee Testing...................................................................CXIV

9. Conclusion..................................................................................................CXV

9. 1 Reflections.............................................................................................CXV

9. 1. 1 Features Left Out............................................................................CXV

9. 1. 2 Future Improvements....................................................................CXVI

I. Appendices..................................................................................................CXIX

I.I Bibliography.............................................................................................CXIX

I.II Permissions.............................................................................................CXX

4

1. IntroductionThe following introduction is an overview of the Park Sense project. This section provides an executive summary to outline the project, as well as a budget and motivation.

1. 1 Executive Summary

In today’s world business centers, universities, shopping malls etc. are busting with parking lots both open and multi-level garages. Finding an empty parking spot in this large maze like parking lots is an undertaken challenge itself. On an average a person spends 2-10 minutes looking for a parking spot in urban parking places, this in turn wastes time and gas. How people wish they would straightaway know where an empty parking spot when they enter the parking lot?

This is where our ‘Park Sense’ senior design project comes into play. When a car enters a parking lot it will be greeted by a display at the entrance showing them where in the parking lot there is an empty space. This in itself is a huge undertaking because this idea requires for there to be a sensor or a camera with image processing in each of the parking spot so that it can detect a car entering or leaving the spot. The major part of this project is to figure out and implement what technology to use to transmit the data from the sensor to the server and its display screen at the entrance of the parking lot. With the sheer size of the parking lot running wires to each of the sensor was an illogical approach. So now the only option remaining was to use a wireless technology and what wireless protocol to use. There are three wireless standards available today – Wi-Fi, Bluetooth, ZigBee. Our main characteristic for which wireless technology to use was durability and lost cost and low power. So ZigBee (IEEE802.15.4) wireless protocol fit our characteristics perfectly.

We would also like to add features like a website and a smartphone application for the user so that he/she can see the view of the parking lot before they enter the lot. This would greatly help in reducing the cluttering at the parking entrance as people would know beforehand itself where there is an empty parking spot and therefore would be ready to catch that spot.

We hope this project would also be energy efficient in a way that it would help people reduce their gas consumption that they waste on looking for a parking spot. With our senior design project ‘Park Sense’ we aim to reduce the time people spend finding parking spots and revolutionize the way people look for a parking space in parking lots.

5

Figure 1.1-1: Project Block Diagram

The above block diagram shows a basic pictorial reference to our project. On the frontend we have the display with a GUI interface showing the user a representation of the parking lot. Behind the display will be where the server will be housed. The server in turn will talk to the receiver and the receive information about the status of the parking spot through the sensor/camera and then it will process the received data and feed it to the GUI to be displayed on the front display. So therefore our project is an amalgamation of both software and hardware challenges. The hardware challenges being the one where expertise is needed to hoop up the camera to a suitable power and then transmits the data with a transceiver, whereas the software challenge being in making a suitable Graphical User Interface for the display screen. This in particular is important because this GUI is what the users basically see about our project because everything else works in the backend.

1. 2 Motivation

When we started on brainstorming ideas for our project, every one of us in our group had many different ideas for our senior design project. Our minds were just budding with ideas. Now the hard part came when we had to decide which idea we would implement to be our Senior Design Project. Therefore we started weighing down all the ideas and started deciding the pros and cons of each idea. So we decided that we would go with the idea that had more pros than cons. So

6

Display Server

Parking sensor or camera

camera

Power

(display)

Receiver Transmitter

Power

data

Signals

we came upon the idea of our project ‘Park Sense’. After discussing on the project for a while we all decided this would a perfect Senior design project for us.

Moreover this project dealt with an everyday common problem that is faced by the students of the University of Central Florida every day. UCF had a student population of about 55,000 students and there are just about 15,000 parking spots in UCF. So we can pretty much judge the challenge it would be to find an empty parking spot during regular school hours. After discussing our project each one of our group members was totally into the ides of ‘Park Sense’. First of all if we are successful in our project we would be helping the UCF parking services in implementing a system like ours at all the different parking garages and the open parking lots. Secondly we would be helping the students conserve their time looking for parking spaces. Thirdly all four of us in our group had personally experienced this big parking issue at UCF and because of that we had sometimes arrived late in class or late for an exam or a meeting etc.

This above mentioned points really got us going and interested in the project. We then started o thinking of various ways in which we could implement this project. Design ideas started flowing and after many trial and error decisions we came up with the idea of how we are going to implement it.

This project really dwelt into the excitement factor of all of us. We all were eager to take upon this challenge and see the outcome. This project also had a variety of different things to do in it, our group being a mixture of computer and electrical engineers we needed a project that would have a mixture of both. This project turned out to be a perfect blend of both software and hardware. After we started researching more on our idea we came to know that many people before us had implemented it. After hearing this many people would be discouraged but in turn we got even more encouraged to do this project as we now had benchmarks we could compare against and strive to be the best project pertaining to this idea.

So to sum it up there were many factors that motivated us towards this project. But the most important think that would help in succeeding in our goal was to be challenged and this would then bear fruits if were are successful in implementing our project to its core.

7

1. 3 Budget

Below is a series of tables outlining a very specific budget for the project.

Project Task Labor

Hour

Labor

Cost

Material

Cost

Travel

Cost

Other

Cost

Total per

Task

1. Project Design 100 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

2. Develop Functional Specifications

10 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

3. Develop System Architecture

5 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

4. Develop Preliminary Design Specification

10 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

5. Develop Detailed Design Specifications

10 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

6. Develop Acceptance Test Plan

0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

7. Project Development

50 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

8. Develop Components

20 $0. 00 $20 $0. 00 $5 $25

9. Procure Hardware 2 $0. 00 $500 $0. 00 $10 $510

10. Development Acceptance test Package

0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

11. Perform Unit/Integration Test

100 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

8

Project Task Labor

Hour

Labor

Cost

Material

Cost

Travel

Cost

Other

Cost

Total per

Task

12. Install System 1 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

13. Train Customers 0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

14. Perform Acceptance Test

5 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

15. Perform Post Project Review

2 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

16. Provide Warranty Support

0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

17. Archive Materials 0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

18. Project Management

20 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

19. Customer Progress Meetings/Reports

0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

20. Internal Status Meetings/Reports

45 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

21. Third-Party Vendor Interface

0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

22. Interface to Other Internal Agencies

0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

23. Configuration Management

0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

24. Quality Assurance 0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

0 $0. 00 $0. 00 $0. 00 $0. 00 $0. 00

TOTAL (scheduled) $0. 00 $0. 00 $520 $15 $0. 00 $535

9

1. 4 Timetable for Completion for Senior Design 1 & 2

The group was behind schedule for much of the first semester due to poor communication and lack of meetings. We have revised our approach to the project for next semester and are in the process of creating a structured weekly meeting plan, along with setting more frequent deadlines so everyone stays on top of things.

Event Estimated Completion Time Status

Senior Design 1 (Fall 2009)

Write up Specs and Requirements

Oct 7th Complete

Divide Responsibilities Oct 21st Complete

Begin Research ASAP On Going

Revise Specs Early Sept Complete

Begin Writing ASAP Complete

Discuss Design of Transciever and Sensor

Last week of Nov. Complete (late)

Complete Design of the System

First week of Dec On going revision

Pick Parts based on Design First week of Dec On going revision

First Draft of Final Documentation

Dec 5-6th Complete (late)

Final Draft of Final Documentation and print

Dec 10th Complete

Submit Documentation Dec 14th Complete

10

Senior Design 2 (Spring 2010)

Brush up on C++ Coding Over Winter Break Pending

Meet to Create Meeting times throughout the semester

First week of Jan Pending

Finalize Parts Decisions First week of Jan Pending

Start Coding End of January Pending

Basic Functionality of Software February Pending

Familiarize ourselves with the hardware

ASAP Pending

Determine and and setup Test environment

February Pending

Have Image Recognition Software Ready

Beginning of March

Pending

Test Using sample images March Pending

Debug and Revise Code March Pending

Conclude Testing April Pending

Finishing Touches April Pending

Revise SD1 Documentation April Pending

11

2. Specifications & RequirementsThe following sections outline the specifications and requirements for the Park Sense project. The main goal of the requirements is to set certain standards that are to be met with this project. The specifications are designed to establish certain specific characteristics for each component of the system. These specifications will make it easier to select parts and establish “rules” that can be followed to design the final system.

2. 1 Requirements

There are a number of requirements that we have set to be met by the Park Sense project. In the introduction and motivation sections of this documentation, many of the problems that this project is trying to address were identified. To solve these problems and ultimately have a successful project, we are placing the following requirements on our system. In meeting these requirements, we hope to have a successful outcome for this project.

One requirement of the project is low cost. We were incapable of acquiring sponsorship or any sort of financial aid for the Park Sense project. Therefore, it is critical to maintain as low of a cost as possible. While this is the primary reason for requiring a low cost, we also want to design this system to be capable of being used in real world applications or simply expandable onto a larger scale. For this to be possible, the system would have to be cost effective. For this requirement, a large portion of the research will be to find the least expensive part for each component of the project while still meeting the other requirements. Another requirement of Park Sense is energy efficiency. This somewhat goes hand in hand with being low cost. Generally if a system is energy efficient, it will be low cost. This is another requirement that is meant to contribute to the scalability of the project. A system that is energy efficient is more likely to be capable of being applied on larger scales. To achieve this requirement another large portion of the research will also be devoted to finding the most energy efficient and low power part of each component. There will also be an emphasis on researching and determining the most efficient power supply for each of the parts involved in the system.

There are a number of other basic requirements for the Park Sense project that are worth mentioning. Each sensor node of the project should be minimal in size. It is important to not have anything that is too intrusive in the parking lot or garage. There is a section of this documentation that discusses related projects. Another requirement for Park Sense is to improve upon these other similar projects that have been designed in the past. One way we will attempt to

12

accomplish this is by adding a number of features to our system. These features will also be discussed in a later portion of the documentation. To recap, the main requirements of the Park Sense project are summarized in the list below.

Low cost – The project should be as inexpensive as possible. High energy efficiency – The project should be as energy efficient as

possible and maximize battery life in each part. Small size – The components of the project should be as nonintrusive as

possible. Lots of features – The project should have as many additional features as

possible.

2. 2 Specifications

The following specifications are listed by individual component of the system. Each component needs to meet these specific guidelines. The idea of these specifications is to create a set of guidelines for part selection. Many of these specifications will be addressed further in the research sections of this documentation.

2. 2. 1 Sensor

The following is a list of some of the more important specifications we are looking for in determining the sensor for this project.

Range:o minimum 2 feeto maximum 12 feet (roughly the average length of a car)

Cost: under $10 per unit Power consumption: low Package size: minimal – less than 10 cm x 10 cm Supply voltage: less than 9V Accuracy: 95% or better

2. 2. 2 Transceiver

The following is a list of some of the more important specifications we are looking for in determining the transceiver technology that will be utilized in the Park Sense project.

Range: minimum of 25 meters Transmit Power: minimal – roughly no more than 100 mW

13

Cost:o Module - under $25 per moduleo Development Kit – under $300o Other development tools – under $50

Supply Voltage: minimal – less than 9V Package Size: minimal – less than 10 cm x 10 cm Weight: less than 1 oz RF Data Rate: at least 100 kbps Serial Data Rate: at least 100 kbps Peak Current: less than 100 mA Receive Current: less than 150 mA Idle Current: less than 50 µA Receiver Sensitivity: between -115 dBm and -80 dBm Supported Topology: Point-to-point, mesh Operating Temperature: -20 oC to 75oC Number of Channels: at least 12

2. 2. 3 Power

Below is a list of the specifications needed for the power of the system. This is currently based on the anticipated design and is subject to change.

Supply at least a constant 9V signal Able to handle at most a 20W load (use of a camera) Theoretical lifetime at least 2 years Signal may not degrade below 8. 5V near end of life Capable of a quick power on/power off cycles Little to no heat generation Fit within the package size

2. 2. 4 Display

The following list is a summary of what we are looking for in the display of the project that will be located outside of the parking lot.

Type: LCD Display area (diagonal) : 15’’ to 21’’ Resolution : 1280 * 1024 Pixel response time : 8 ms Brightness : 300 cd/m2 Contrast Ratio : 700:1 Viewing Angle ; 150/135 (H/V) Video : VGA (Analog), DVI-D (Digital) Input Connectors :

14

o 1 * VGA (15-pin HD D-sub)o 1 * DVI-D (24-pin Digital DVI) o 1 * Audio Line – In (Mini-Phone stereo 3. 5mm)

Unit : Approx. 17 * 16. 6 * 6. 9’’ Weight: Approx. 12 lbs. Environments : PC compatible Audio : Built in stereo speaker (2 * 1W)

2. 2. 5 Server

The following list outlines some of the key aspects that will be needed for the server. The more important of these are the RAM and the amount of storage on the drive.

Processor: Intel Core 2 Duo Processor E8400 (3GHz, 6M, 1333MHz front side bus)

Memory: 2GB, DDR2 Non-ECC SDRAM, 800MHz (2 DIMMS) Boot Hard Drive: 160GB SATA 3GB/s and 8MB Data Burst Cache Video Card: 256MB ATI RADEON HD 3450 (Dual DVI/VGA/1 TV-out) or

comparable card that has 256MB, dual monitor support, with dual DVI out and DMS-59

Optical Storage Device: DVD+/-RW Ethernet/modem

2.2.6 Microcontroller

One of the most important components of the project is the microcontroller. The following is a list of a few of the important aspects required in the microcontroller.

Microprocessor Speed: minimum 20 MHz Memory: minimum 256 K Serial Ports: minimum 2 – SPI and UART General Purpose I/O: minimum of 20 lines Serial Rate: Max baud rate = CLK/8 Timers: minimum of eight 8-bit timers Voltage Consumption: maximum 5 VDC Transmit Current Consumption: maximum 250 mA Sleep Current Consumption : maximum 50 µA Operating Temperature: -20oC to 50oC Board Size: less than 1 cm x 1 cm x 50 mm

15

3. ResearchThe following research sections are divided up by the individual components utilized to create our Park Sense system. Each component of the Park Sense system has a section of research dedicated to first selecting a technology, and then selecting a specific manufacturer and model within the chosen technology. While compatibility between components is considered in the research, for the most part, each section is researched individually as the best and most economical choice for the Park Sense project.

In the design section of this document there will be a greater focus on how the parts will be integrated toward the final design. There is also a later section expounding on the research methods used in this document that will discuss how the information included in this research was obtained.

3. 1 Sensor

In choosing the appropriate sensor for this system, there are quite a few important factors that are vital in determining our decision. One of these contributing factors is the range and limitations of the area it can detect. This is basically tantamount to whether or not the sensor can work within the area and time we have allotted. If the sensor cannot meet these basic qualifications, then it must be immediately discarded as a choice for our design. A slightly less significant aspect in is the power efficiency of each sensor. Each system analyzed has similar power efficiency on a small scale; however, potentially extrapolating our design onto a larger scale would increase the significance of power efficiency. The details of power consumption are further explained in the Power Section in this report.

Another factor that is essential in determining the optimum sensor is the cost of each individual component. Without a sponsor, it is critical that we stay within a fixed budget and minimize any excess expenses. Thus, it necessary that each part is selected based on not only its optimum compatibility with our design, but also that it is the most economical choice for our design. By comparing the infra-red, ultra-sonic, induction coils, and video-detection systems, we concluded that video-detection was the most economical choice. Though the individual components of a video-detection system were comparatively more expensive (the cameras, transmitters, etc. ) than the other systems, the quantity of parts needed was substantially smaller than any other method of detection. This created a balance between quality and cost that was not present in any of the other systems researched, justifying our choice.

16

In this section, we will be primarily discussing the types of sensors that are being considered for use in this project. Details of implementation will not be discussed in this section, only the different sensor models and the functionality of each type of sensor-system. The technologies of the microcontroller and the wireless transceiver are also discussed in other sections.

3. 1. 1 Sonar

The main idea behind sonar sensing—also referred to as acoustic sensing or ultra-sonic sensing—is the emission of a frequency that is inaudible to human ears and then the subsequent detection of the time lapse between when the frequency was emitted and when the frequency is reflected back to the receiver. This time lapse is relevant for our project because it would determine whether or not a parking spot was occupied by a vehicle at the time the frequency was released. If the sensor outputs a signal, and receives no return then there was no object for the frequency to reflect off of, and therefore no vehicle within the spot. However, if the frequency returns to the receiver, then the parking spot is currently occupied and this would be registered by the system.

In respect to the Park Sense project, it is important to analyze the minimum and maximum ranges of the sensor, as well as the area the sensor detects. If any of these elements are incompatible with the theory of our design, it would be impossible to use ultra-sonic sensing as the method of detection for our project. The typical maximum range of a relatively economical sonar sensor is no greater than 6-25 feet. For the Park Sense project, with the average parking spot being within this range, the sonar sensor would be adequate to detect a parked car. However, utilizing one sensor per every two spots would maximize the capabilities of each sensor while also being more cost-efficient. This idea was not implemented due to the decision to utilize a video-detection system; one sensor per two parking spots was considered specifically for ultra-sonic sensors and infra-red sensors.

As previously discussed, cost is also a major factor in deciding which sensor to use in the Park Sense System. Due to our small budget, the least expensive option, while still maintaining an adequate range for detection purposes, is the best option. The least expensive ultra-sonic sensing system costs between $20 and $30. While this system option is preferable for monetary purposes, the ranges are not nearly adequate enough to cover the expected distances in the design for our project. The minimum distance for an inexpensive ultra-sonic sensor ranges from merely one to two inches. Even with the sensors placed at the very front of the parking spot, it is quite unlikely that the driver will pull their vehicle within the range of the sensor. With the limitations of an inexpensive sonar sensor considered, it is obvious that a more expensive ultra-sonic detection system would be necessary in order to choose this system for the Park Sense Project.

17

One general problem with ultra-sonic sensing is the delicate process of actually measuring the distance between the sensor and the object detected. Unless the object being detected—in this case an automobile—is directly in front of the sensor and perfectly flat, there will be a miscalculation in the distance to the object. The reflected wave is also not guaranteed to hit the receiver if the detected object is at a sharp angle. This problem is illustrated in Figure 3. 1. 1-1 parts a and b. For the Park Sense project, this would not be a problem as long as each vehicle is parked fully within the spot. Even considering the prevalence of people incapable of parking fully within their spot, in a packed garage, a sharp angle would still result in some frequency-retrieval. This problem was not further addressed due to the decision to use a video-detection system.

Figure 3. 1. 1-1(a): Ideal Reflection of a Sonar Transceiver

18

Figure 3. 1. 1-1(b): Nonideal Reflection of a Sonar Transceiver

Reprinted with permission of Scott Anderson, Frank Klassner, Pam Lawhead, and Myles McNally, www. mcs. alma. edu/LMICSE

One of the sensors that we were considering was the PING))) Ultrasonic Distance Sensor (#28015). The sensor accurately measures distances that range from about 2 centimeters (about 0. 8 inches) to 3 meters (about 3. 3 yards) through the use of ultrasonic frequencies. The pulse released from this sensor is 40 kHz in frequency, which is beyond the scope of normal human hearing. At 1130 feet per second, the pulse is released from the ultrasonic sensor until it comes in contact with an interfering object. When this occurs, the pulse reflects off the object, and returns to the receiver. The receiver then measures the width of the reflective pulse and then calculates the exact distance. One other advantage of using this sensor is the ease in which it connects to microcontrollers because it only needs one input/output pin.

A list of the features within the PING))) Ultrasonic Distance Sensor was taken from the product’s data sheet with permission from the manufacturer, Parallax. The list of features is provided below:

Supply Voltage – 5 VDC Supply Current – 30 mA typ; 35 mA max Range – 2 cm to 3 m (0. 8 in to 3. 3 yrds) Input Trigger – positive TTL pulse, 2 uS min, 5 μs typ. Echo Pulse – positive TTL pulse, 115 uS to 18. 5 ms Echo Hold-off – 750 μs from fall of Trigger pulse Burst Frequency – 40 kHz for 200 μs Burst Indicator LED shows sensor activity Delay before next measurement – 200 μs Size – 22 mm H x 46 mm W x 16 mm D (0. 84 in x 1. 8 in x 0. 6 in)

19

The dimensions of this sensor were also extremely compatible with our design for the Park Sense System. With the entire detection system being placed within the concrete block at the head of the parking spot, the small dimensions of the PING))) Ultrasonic Distance Sensor made for a perfect fit within our original design. Two diagrams, Figures 3.1.1-2 a and b, of the dimensions of the ultra-sonic sensor, taken from the product’s date sheet, are provided below for further detail:

Figure 3.1.1-2(a): Front view of PING))) sensor

Figure 3.1.1-2(b): Side view of PING))) sensor

20

This sensor would likely be implemented with a microcontroller. An example of the type of microcontroller that would be used is the MSP430, which is just one model that we were looking at.

3. 1. 1. 1 UEDK 20

The UEDK 20 is a special type of sonic transducer that is used as an ultrasonic proximity sensor, which allows for alternate transmission and reception of sound waves. The ultrasonic transducer emits a number of sonic waves which are reflected by an object, back to the ultrasonic transducer. After emission of the sound waves, the ultrasonic sensor will switch over to receive mode. The time elapsed between emitting and receiving is proportional to the distance of the object from the sensor.

Ultrasonic proximity sensors enable the detection of different objects irrespective of color and transparency. This is useful for the Park Sense project because of the variety of vehicles that could occupy parking spots. Therefore, the sensor would not have to be programmed separately for different types of vehicles.

The emitter and the receiver are in two separate housings. The emitter sends a continuous sonic signal which propagates until it hits an object and is returned until it is picked up by the receiver. When an object breaks this sonic beam, the receiver will react and give an output signal. Beam sensors are ideal for applications which require short response time or where the distance between successive objects is very small. This makes it a reasonable choice for the Park Sense project where the sensor would only need to reach a minimal distance from the end of the spot to the oncoming vehicle.

Sensing is only possible within the detection area, which is usually a conic region produced from the emitter. The required sensing range can be adjusted with the sensor's built-in potentiometer. If an object is detected within the set area, the output changes its state. There is also a built-in LED that indicates the change in state.

There are a number of options that are available to make the sensor customizable specifically to the Park Sense project. The operating ranges and SDE (Sensor data Elements) can be adjusted and the output function is selectable.

This sensor differs from other ultrasonic sensors in that it has a “Teach-in” function. Ultrasonic sensors with the "Teach-in" function are similar to the standard range of products but have the added versatility of a simple touch key set up. This makes the UEDK 20 more desirable.

21

One advantage to having a digital output is the simplicity of having a one button set up. Also, no tools are required and set up configuration is saved on an internal EEPROM. Saving the configuration ensures long term stability. This would also be useful if the Park Sense system were to be expanded. The configuration could be transferred between similar sensors without the need to reprogram each individual sensor. Below are a few tables detailing some of the features of this sensor followed by two figures showing the physical features.

General dataemitter / receiver receiversensing range sd 0 . . .  1000 mmscanning range far limit Sde 0 . . .  1000 mmobject size (at Sd = 50 mm) > 2 cm²hysteresis typ. 5 mmrepeat accuracy < 3 mmresponse time ton < 5 msrelease time toff < 5 msadjustment Teach-inalignment aid target display flashingoutput indicator LED green

Electrical datavoltage supply range +Vs 15 . . .  30 VDCcurrent consumption max. 30 mAoutput circuit PNP make function (NO)output current < 200 mAvoltage drop Vd < 2 VDCresidual ripple < 10 % Vsshort circuit protection yesreverse polarity protection yes

Mechanical dataType rectangularhousing material polyesterwidth / diameter 20 mmheight / length 42 mmDepth 15 mmconnection types connector M8

22

Ambient conditionsoperating temperature 0 . . .  +60 °Cprotection class IP 67

Remarksreceiver with teach-in & LED display  response time adjustable <= 5 . . . 320 ms  

Figure 3. 1. 1. 1-1: UEDK 20 Front and side view

Figure 3.1.1.1-2: UEDK 20 PIN set up

23

The UEDK20 also comes in a model that provides analog output. Both current and voltage outputs of the ultrasonic proximity sensors are proportional to the distance to the target. The UEDK20 allows the user to change the slope of the output curve using the built-in potentiometer or teach mode button. Doing this allows the user to define the required resolution.

Versions of this sensor, which come with a built-in analog to digital converter, generate output signals separated into discrete steps. Applications having long cable runs where there might be electromagnetic interference or radio frequency interference should use ultrasonic sensors with an analog current output option available.

The analog output can be set to either rise or fall proportional to the target distance. This may not seem significant but it allows another aspect of customizability, which is always a plus when it comes to adapting the parts to the Park Sense design.

The advantages of the analog output version of this sensor are that the optimum resolution for a particular installation is automatically set up. Also, the fact that the set up configuration is saved onto an internal EEPROM ensures the long term stability of the system. Lastly, multi functionality from one sensor means less expenses and a greater likeliness that the cost of the sensors will stay within the budget.

3. 1. 1. 2 RPS-400-6

The RPS-400-6 is a compact, high frequency sensor that is used for a wide array of application solutions that cannot be obtained from other proximity sensor technologies. The RPS-400-6 has an adjustable sensing range of two to six inches with background suppression. This means if any object is detected within the desired range, the sensor works. However, objects detected outside of the range are ignored by the sensor. It also cannot be affected by changes in the color or the material of the object detected. The RPS-400-6 is also capable of detecting vibrating and tilting objects. A response time of no more than 2 milliseconds and an operating frequency of 300 kHz make the RPS-400-6 a repeatable and accurate high-speed sensor. All of these characteristics make the RPS-400-6 a viable candidate for sensing technology in Park Sense.

Below is a list of some of the key features of the RPS-400-6. Background Suppression 20 to 30 VDC Power Input 2 to 6 inch Sensing Range Adjustable Sensing Range Detects translucent or opaque objects independent of color Compact Size LED Indicator

24

NPN Output Narrow Sensing Beam Quick Response Time

3. 1. 2 Infrared

The idea behind infrared sensing as it pertains to this project is either a) the detection of heat or b) the detection of infrared light. The better of these two options is the detection of infrared light. For Park Sense the ideal use of infrared would be in an IR proximity sensor. The IR proximity sensor uses LED’s to emit infrared light. The sensor then detects anything that reflects that light back to it. This information is then in turn used to determine proximity of the detected object to the sensor’s position.

One of the characteristics of the sensor that was discussed earlier is the range of the sensor. This is one of the problems with the infrared proximity sensor. The sensor at its highest range is no more than 25 to 35 centimeters. This range can be extended by increasing the amount of current into the LED. Obviously, there is a maximum current that can be generated into the IR sensor. This also requires more power and reduces the efficiency of the system. Therefore, the best range for this IR proximity range could potentially be around 80 cm depending on the brand and variation of sensor selected. This would give a little over two feet as the maximum range of the sensor. If the sensor is mounted on the wall facing the car, this would mean the car would have to get within two feet of the wall to be detected by the sensor. An automobile getting that close to a wall mount sensor is not guaranteed. This would reduce the reliability of the sensor detecting. This would obviously create the same problem if the sensor were mounted on the front of the car. Sensor mounting on the front of the car would also lead to detection of other objects that are not the wall at the end of the spot. However, a two-foot limit is not enough of a limitation to rule this out as a viable option to use as a sensor for the Park Sense system.

The range of the IR proximity sensor is also dependent on the amount of ambient light in the area where detection is to occur. When more ambient light is present, the sensor is less effective. This means that if the Park Sense system were set up in an open air parking lot, the IR proximity sensor would be a poor choice, especially for sensing during the day. However, the same problems with ambient light would occur inside a garage. Between the lighting of the garage and the headlights of the cars, there would be a significant amount of ambient light that could cause problems with the sensor. This problem can be fixed with an ambient light ignoring sensor which can work in conjunction with the proximity sensor. This still adds more complexity and cost to the system that would not be necessary with some of the other options that can be used for the sensor.

For the IR sensor to operate, the proximity design being discussed uses a pair of LEDs. One of the LEDs emits the light and the other detects the reflected light.

25

The problem with this design that the LED emitting light must be constantly emitting light and must, therefore, be constantly on and active. The constant activity will reduce the battery life of the sensor and severely hinder energy efficiency. There is a way to rectify this problem. The sensor can be designed to send IR pulses instead a constant emission. This requires more current to be sent into the LED as was discussed earlier. This design still requires more power and less efficiency.

In general, this type of sensor is relatively inexpensive. The typical price of a long range IR proximity sensor is around $15 dollars per sensor. The low cost is a benefit to using this type of sensor technology. The IR proximity sensor is also not particularly difficult to build. The circuit for the sensor can be built using just a few parts and put together on a printed circuit board, also for a very low cost. However, there are difficulties and negatives to building the sensor. Building the sensor would require a lot of time capital in terms of finding parts, as well as actually building the circuit. Building the circuit would also probably result in less reliability in the range of the circuit as well as the overall performance.

Another variation of an infrared sensor is a passive infrared sensor or a PIR. This type of IR sensor is basically a motion detector and is the same technology that is used in most industrial security motion detectors. The problem with detecting motion comes up when a car is in a spot for a long time. The sensor would have to be on constantly detecting for motion so that the state can change every time there is motion. Otherwise, if the sensor turned on periodically to see if there is a car present, the motion detector would deliver the same result when whether a car is present or not.

3.1.2.1 Determining which model to use

We were looking into using the GP2XX detectors, they come in different characteristics. The table below helps to characterize each type by minimum and maximum ranges, as well as whether the sensor returns a varying distance value:

26

Figure 3.1.2.1-1: GP2XX Distance Ranges

3.1.2.2 For a non-linear output

The output got these detectors are non-linear with respect to the displacement that is being measured. This is because of the crucial trigonometry within the triangle from the emitter to reflection spot to receiver.

27

Figure 3.1.2.2-1: GP2XX Typical output response

3.1.2.3 GP2D12 output voltage to distance curve

As you can see the graph above shows the usual output from these infra-red detectors. There are two things that we should find in this graph. First, is the output from the detector within the shown range (from 10 cm to 80 cm), this output should be logarithmic and not linear. The curve will vary slightly from model to model so it would be a good idea to normalize the output, this can be done with a lookup table or a parameterized function.

The second observation that we should look for in the graph is that once we fall inside of the stated distance range (this being less than 10 cm), the output should

28

fall really quickly and then slow down as it approaches a solid object (it gets below the minimum range), after we should get the wrong reading from the extended range reading meaning that the object is closing up to the sensor. To fix this error we should place the infra-red sensors across from each other. This is shown in the figure below.

Figure 3.1.2.3-1 Example of placing the infra-red sensors across from each other to avoid range errors.

3.1.2.4 The beam pattern

The beam pattern for these detectors is pretty consistent between the models. The range can fluctuate somewhere between 10-80 cm, the widest portion in the middle being about 16 cm wide. This is a reasonably narrow beam sample which will give us a large ranging data when coupled with a servo to sweep while the sensor takes readings.

To use the detectors as a solid-state bumper, you usually want the widest beam sample possible to make available a large area ex: the end of the parking spot. This can be achieved with no problems by using two detectors that cross over each other in front of the parking spot as shown in the figure below. The most widely used sensor for this set up is the GP2D15.

29

Figure 3.1.2.4-1: Example of wider beam angle using two crossing detectors.

Depending on the type of detector used, the output from these two detectors could actually be combined to help our microprocessor I/O budget.  

3.1.2.5 Interfacing the Sensors

For all the sensors except the GP2Y0A700 are in actual fact small and use a minute connector called the Japan Solderless Terminal connector. The Japan Solderless Terminal connectors have three wires, the ground, the VCC, and the output. Because the sensor is always on and does not require any clocking to initiate a reading, they are easier to interface but use more power and can potentially interfere with one another when numerous detectors are used. This interference can be avoided by following the theory of operations of the detectors.

There is a special case when dealing with the larger GP2Y0A700, it have a 5 pin Japan Solderless Terminal connector with two ground and two power lines. However, these lines can be soldered together provided the attached power supply is capable of delivering roughly 400 mA of peak current (roughly 30-50 mA continuous current). Like the other sensors, the GP2Y0A700 has to be continuously running.

30

Figure 3.1.2.5-1: Block Diagram Showing Diode Orientation

These detectors are a large addition to the collection of detectors available for The Park Sense. They are rather inexpensive, use very little power, they also fit in small spaces, and have a unique range that is ideally suited to detect the vehicle that enter and leave the parking spaces.  

3. 1. 3 Video Detection

The Park Sense system can be conceivably designed without a real sensor at all. One way to do this would be to use a camera in place of a sensor to obtain the information of what is happening in the parking lot or garage. This would likely require just one camera in a given area to monitor a number of spots.

To use video detection, there would likely be a webcam mounted above the parking lot or on the ceiling of the garage in a place where it can monitor as many parking spaces as possible. For the small scale design of Park Sense, there would only be need for a single webcam, which should be able to easily see the four spots in the design. The cost of a single webcam would be around $20. This means that this option would be relatively cost efficient compared to the other options of four sensor nodes where one monitors each spot. Financially speaking, this would be an ideal option.

The main problem with using video processing, is that the camera would have to be hard wired to the server. The video data would require too much bandwidth to be transmitted through a wireless transceiver as would be used with other sensor options. Hard wiring would cost more depending on how far the camera is from the server. If the camera is mounted very close to the server, this additional cost of wiring would be minimal.

The webcam would also require a lot more power to be running constantly. Another option would be to utilize cameras that already exist in parking garages for security purposes. These cameras are closed-circuit television (CCT) cameras. The images that are obtained from these security cameras can also be sent to the Park Sense server. This would save on the cost of the webcam and for most garages would not require any additional hardware to be installed. The cost of putting in an additional CCT camera would be significantly more than that

31

of a webcam. Most CCT cameras cost around $200 on the cheap end. However, in practical applications, the security cameras already installed would be used for this. It is only in the Park Sense test design that one of these closed-circuit television cameras would need to be purchased so that the system could be tested.

Using video image processing, the system would generally work in the following way. The software would be preset to the information corresponding to an empty spot by being loaded with an image of the background when no cars are there and all spots are empty. When an object comes into the background, the value of the background image pixel will change. There would need to be a certain threshold level set to where if the change in the background image pixel exceeds that threshold, the object can be recognized as a car and the status of the spot will change from vacant to being occupied. The bulk of the work for this type of sensing would come from writing the program and algorithms necessary for the system to come to these conclusions of vacancy or occupancy. There are, however, a good number of open source programs for image processing that could be modified or used to meet the needs of the project. This would make the use of a camera and image processing software a viable option, especially financially.

3.1.3.1 Programmable cameras

We considered buying a programmable camera so that we could use image processing to obtain the data needed to determine whether a parking spot is currently occupied by a vehicle or vacant.  The C-Eye is the ideal board for adding low power stand-alone digital image acquisition and recording to any embedded application.  CMOS image sensors have become widely used on platforms such as cell phones, or PC/Web-based remote cameras.  Up to now, these cameras have generally relied on a connection to other central systems for data storage, image processing, or power.

3.1.3.2 Image Acquisition

The C-Eyeonboard CMOS image sensor has 640*480 active pixels. With a pixel clock of 20 MHz, the hardware frame capture period is approximately 40ms (allowing for about 25 fps acquirement), making it capable of tracking relatively high-speed motion. Real-time images captured are made available to the user-applications at a consistent rate of 10 fps, and indefinite storage to the compact flash card is possible at ~3-4 frames/second.

On the C-Eye platform, images are captured via two simple C function calls. Data is available to the application with full resolution, and full color and grayscale detail (about 1 or 3 bytes per pixel), this allows a very simple and

32

straight-forward machine vision applications. The user application can access any pixel directly from this memory buffer. The C-Eye can be programmed to capture images, analyze any zones of interested pixels, and make control decision based on that image processing result in real-time.

These images can also be saved in Windows bitmap (. bmp) format for simple storage and transfer to the computer for later analysis.  Tens of thousands of images can be stored with onboard removable compact flash memory cards, using the provided FAT16 file system support.

3.1.3.2 Stand-Alone Controller

What we liked about the C-Eye is that it is a complete controller including a 16-bit 40 MHz x86 CPU, onboard regulator, 512KB Flash, battery backed SRAM, 1 MB image FIFO, an image sensor, two RS232 ports and a compact flash interface.

The 10BaseT Ethernet port has TCP/IP support, including basic HTTP, SMTP code which makes it perfect for our project because we want to make a website where you can look at the spots available. Also contains two RS232 serial ports (SER0 and SER1) can handle 115,200 baud with high reliability. SER1 can also be hardware configured as RS485. There are a real time clock with battery backup, 10+ TTL I/O pins and 3 16-bit timer and counters. A high speed 16-bit parallel databus expansion header supports external USB interface for high speed data transfer to a PC.

The C-Eye is designed to be used in hard-to-access embedded environments. It accepts a wide range of power inputs (from 8 to 35V with the switching regulator), and can be driven directly by battery. The standard C-Eye consumes approximately 120mA at 12V. The optional switching regulator allows the C-Eye to sleep in VOFF mode, and to reduce power consumption to less than 30 uA. The onboard real-time clock can be used for scheduled alarm wakeups from VOFF

mode, allowing the C-Eye to run indefinitely in any battery-powered environment by controlling how often the camera is enabled for image acquisition.

3.1.3.3 Lorex LW1012

The Lorex LW1012 is a wireless color camera that is used for surveillance systems. This camera works for indoors and outdoors functions, it has night vision capabilities, and can transmit up to 300 feet in wireless transmission range, it is also very straightforward to set up – merely plug it into any electrical outlet.

The Lorex LW1012 is ideal for our project design; the packet comes with 2 wireless cameras, 1 wireless receiver, 3 9Volt DC power adaptors, 2 RCA video output cables and 2 camera battery adapter cables. This would be everything we

33

need to easily monitor the cars going into and leaving a spot, as well as provide security.

Some of the features these cameras are:

Imaging Sensor: 1/3” CMOS CMOS Total Pixels: 510 x 492 (NTSC) View Angle: 62° Diagonal Minimum Illumination: 3. 0 Lux F1. 5 (IR off) / 0 Lux (IR on) Transmission Frequency: 910 MHz - CH1, 920 MHz - CH2 (2CH) Transmission Power: 10 dBm Modulation Type: FM Bandwidth: 6. 0 MHz Power Source: + 9V (DC) Unobstructed Effective Range: 330 ft. Night Vision Range: Up to 26 ft. Dimensions: 1. 8x4. 6x6. 3” Weight: 0. 3lbs Operating Temperature Range: 14° F ~ 104° F -10° C ~ 40° C

Features of the receiver:

Receiving Frequency: 910-920 MHz - 2CH Intermediate Frequency: 32 MHz Demodulation Type: FM Receiving Sensitivity: -85 dBm Power Supply: 9V (DC) Consumption Current: 180 mA Unobstructed Effective Range: Up to 330 ft. / 100 m Dimensions: 2. 8x4. 7x3. 3” Weight: 0. 3lbs Operating Temperature: 14 F to 104 F /- 10 C to 40 C Operating Humidity: 85% RH

Here is a list of other characteristics that the Lorex provides:

‘EWT’ Eliminates Interference From Most Devices Receiver Connects to any TV/VCR/DVD Recorder Indoor / Outdoor Night Vision Camera Built-in Microphone for Listening Ability Camera Can be Battery Operated for True Portable Wireless Operation Up to 300ft Wireless Transmission Range Night Vision Allows for Low Light Viewing up to 23ft (7m) from Cameras Receiver Automatically Switches View Between Cameras Desktop, Wall and Ceiling Mountable

34

3. 1. 4 Light Sensor

We considered placing a light source on top of each individual parking spot and a light sensor on the ground of each spot in order to detect whether or not a vehicle was currently occupying it.  The light sensor is not actually a sensor, but rather a light-dependent resistor (otherwise known as a photo-conductor, a photo-cell, or a photo-resistor).  A light-dependent resistor is made of a high-resistance semiconductive material.  When the frequency of the light hitting the photo-conductor is high enough, the photons that are absorbed by the photo-conductor provides enough energy for bound electrons to jump into the conduction band.   The resistance is thus lowered by the resultant free electron (as well as its hole partner), which both conduct electricity.   A light sensor device can be either intrinsic or extrinsic.  In intrinsic devices, the only available electrons are in the valence band, and therefore the photon must have enough energy to excite the electron across the entire bandgap.  However, extrinsic devices have impurities added, which have a ground state energy closer to the conduction band. Since the electrons do not have as far to jump, lower energy photons (ex: longer wavelengths and lower frequencies) are enough to activate the device.   A light-dependent resister is a variable resistor whose value decreases when exposed to a higher light intensity.  This is pertinent to the Park Sense Project because these variable values would enable us to distinguish whether or not the parking spot was currently occupied.  If a vehicle is parked over the light sensor, then the light intensity will decrease, increasing the values of the resister.  These values would be registered by the system, and anyone remotely accessing the system would be able to see that the spot is indeed occupied, and direct their vehicle to a different area of the garage.  However, when a vehicle leaves a parking spot, the light sensor receives a higher light intensity, which subsequently decreases the values of the resistor.  This would then be registered by the system as an unoccupied parking spot.   In comparison to the other systems researched, this light-sensing system requires an exponentially larger amount of power, which would increase the cost of the Park Sense System substantially.  There would be no environmentally-friendly manner in which to decrease the consumption of energy due to the fact that the light sources would have to be on all day and all night, wasting enormous amounts of energy and creating a lot of unnecessary heat.  Also, the quantity of parts required to create this system would be much greater than all other systems considered.  Each parking spot would need its own system, which, on a large scale, would not be economical in the least.  Considering our limited budget and potential extrapolation on a larger scale, we decided against using a light-sensing system.

35

3. 1. 5 Heat Sensor

For the Park Sense System, there are 4 temperature-sensing devices that could be used to register whether a parking spot was occupied or vacant: thermocouples, resistance temperature detectors, thermistors, and temperature-transducing integrated circuits.  The heat from the parked car would be used as the heat source for these temperature-sensing devices.  The temperature generated from a car is converted into a reference voltage, resistance, or current which is then measured and stored.  A higher heat reading equates to an occupied parking space, while a lower heat reading equates to a vacant parking space.  These values would be accessed remotely through the Park Sense System, and direct drivers to any unoccupied parking spaces.   3.1.5.1 Thermocouples The mechanism behind thermocouples is theoretically complex, while the actual heat sensor is quite simplistic.  Provided below is a basic model of a thermocouple.  Two different alloys (wire A and wire B) are connected at T1.  This area is called the “hot junction”, or the sensing element, of the thermocouple.  The remaining ends of wire A and wire B are attached to an input device (usually a voltmeter) and the voltage across the space between wire A and wire B (T2) is measured.  This area is referred to as the “cold junction” and is maintained at a constant reference temperature. A diagram of a thermocouple is shown in Figure 3.1.5.1-1.

Figure 3.1.5.1-1: Visual description of a thermocouple

36

In the Park Sense Project, when the hot junction is heated-by the engine of the parked car, a voltage in the space between wire A and wire B is produced.  This voltage is directly proportional to the difference in temperature between T1 and T2, or between the hot junction and cold junction.  The principle behind this proportional voltage is referred to as the thermocouple effect.  Therefore, maintaining the junctions of the different alloys at two separate temperatures produces an electromotive force called the Seebeck electromotive force.  The different atomic structures of each individual alloy provide the foundation for the Seebeck electromotive force; however, there will be no elaboration on the chemical structures of these alloys.  It is substantial enough to state that standards have been agreed upon to ensure the replication of these thermocouple effects, due to the fact that different combinations of alloys generate unique voltages.   Thermocouples are regulated at a cold junction temperature of 0°C.  However, two problems arise when connecting thermocouples to their input device.  The first problem concerns the input terminals, which are built with a different type of metal. This different metal causes them to create their own Seebeck voltage, which changes the real thermocouple voltage.  The second problem is that the device has to be recalibrated often in order to sustain an operational cold junction temperature. Luckily, advancements in technology have resulted in the design of self-calibrating and self-compensating input modules. These input devices are also able to be configured for an assortment of thermocouple types.  3.1.5.2 Resistance temperature detectors Resistance temperature detectors are assembled by winding a fine metal wire around a glass (or ceramic) cylinder. Next, a coating of glass or ceramic is applied to insulate the coil.  Resistance temperature detectors function on the principle that as the sensing element is heated, the resistance of the metal wire increases proportionally.  Resistance temperature detectors are often made with copper, nickel, or nickel-iron, but platinum resistance temperature detectors are the most linear, repeatable, and stable.  The resistance is almost a linear function of temperature for very pure platinum.   3.1.5.3 Thermistors The thermistors vary in their resistance as the ambient temperature is changed.   Unlike resistance temperature detectors, the resistance of a thermistor decreases as the temperature rises—and not in a linear manner.  A thermistor consists of a metal oxide ceramic semiconductor sensing element. They are also known for their non-linearity, which engineers often dampen by implementing pairs of offsetting thermistors, providing a more linear output.  These temperature dependent resistors are highly sensitive to temperature change.  Thermistors vary in their resistance about -4.4% at 25°C when heated by one degree Celsius.  In operation, an electrical current is passed through the sensor because

37

thermistors are resistive devices.  Some of this electricity is converted into heat, which can cause temperatures slightly higher than ambient temperature readings.  With long lead wires, thermistors can operate without significant error because of their high base resistance.  Thus, they can be installed long distances, upwards of one hundred meters, from the input module.  3.1.5.4 Temperature-transducer integrated circuits These semiconductor temperature sensors are produced in the form of integrated circuits.  Their design results from the reality that semiconductor diodes have temperature-sensitive voltage versus current characteristics.  When two equal transistors are operated at a constant ratio of collector current densities, the difference in base-emitter voltages is directly proportional to the absolute temperature.   The use of temperature-transducer integrated circuits is limited to applications where the temperature is within a –55°C to 150°C range.  The measurement range of a temperature-transducer integrated circuit may be small compared to that of thermocouples and resistance temperature detectors, but that can be considered an advantage. Other advantages include that they are quite accurate and relatively inexpensive. When considering the necessity of staying within our limited budget without sacrificing the functionality of the system, these temperature-transducer integrated circuits could be extremely useful in the Park Sense System.

3. 1. 6 Fiber Optic Sensor

One idea we considered was to use fiber optic sensors as a counter. Essentially, a vehicle would roll over the fiber optic sensor, sending a signal confirming that the vehicle was currently occupying the parking spot. When the vehicle rolls over the fiber optic sensor a second time, the sensor would send another signal stating that the vehicle has left the parking spot.

In order to choose the best sensor for the Park Sense System, we researched further details on the fiber optic sensor. We discovered that the fiber optic structure would have to be inserted in a base that makes the sensor responsive to vertical pressure only. Also, we found that the fiber optic sensor is immune to electromagnetic interference, corrosion, and lightning because it does not contain any metal parts. This latter detail would be favorable for use in the Park Sense System.

The fiber optic sensor would be inserted into a small gap with Sensor Line SL-Cast 90 embedding material. It would also be connected to a Sensor Line MA-110 optical transmittance analyzer. This sensor would be embedded in the asphalt as shown in the figure below.

38

Figure 3.1.6-1: Example of the sensor being implanted in the asphalt

We decided against using the fiber optic sensors in the Park Sense System. Considering our limited budge, this idea proved to be rather expensive. The high cost resulted from the necessity of running fiber optic sensors across the entirety of the area we wanted to keep a counter on. With a multitude of other less expensive systems at our disposal, we therefore decided on a different sensor system.

3. 1. 7 Loop Sensor

The inductive loop sensor is a relatively simple sensor. When a vehicle reaches the loop, the metal of the vehicle disturbs the magnetic field over the loop, which causes a change in the loop's inductance. Inductance is an electrical property that is proportional to the magnetic field. This is how the loop sensor would detect a vehicle in a garage monitored by the Park Sense System.

Multiple features combine in order to form a specific circuit. Some of these features include: the size of the loop, the shape of the loop, the number of turns in the loop coil, and the length of the lead-in wire. The current passing through the loop generates an electromagnetic field. When a vehicle passes through the field, it acts as a conductor, changing the inductance of the loop. The sensor detects this change and notifies our micro-controller of its finding. Using this method, a loop sensor could be a distinct possibility for the Park Sense System.

Unfortunately, there are numerous failures that can occur when using inductive loop sensors. One such problem is damage to insulation during delivery.

39

However, the two most common causes of failure are poor pavements and poor installation techniques.

In considering the loop sensor for use in the Park Sense System, we ultimately decided not to use it. First of all, the many failures that could occur rendered the loop system unreliable. We need a system that will be both efficient and trustworthy, and the huge amount of work required to sustain this system would have been incredibly daunting. Also, due to our extremely limited budget, the high expenses necessary to create a system based on loop sensors cemented our decision to not consider these sensors any further.

3. 1. 8 Strain Gauge Sensor

A strain gauge is a resistance-based sensor used by mechanical engineers to measure strain in an object. The primary type of strain gauge is a metal foil gauge. A strain gauge consists of a long thin wire of metal foil that is wrapped back and forth across a grid, called a matrix. The matrix is attached to a thin flexible backing material with a bonding agent, often a cyanoacrylate. The strain gauge is bonded to the part that will be evaluated, and the matrix is oriented in the direction of the applied strain. The strain exerted on this part is also exerted on the strain gauges, causing the wire that makes up the matrix to stretch or compress.

3.1.8.1 Strain Gauge Configurations

Strain gauges are available in a vast assortment of sizes and configurations, depending on the material and geometry of the part to be tested and on the expected strain levels. Also, the matrix lengths can vary from a few millimeters to several inches.

The strain gauge is extremely useful because, while one strain gauge can measure strain along a single axis, multiple strain gauge matrices can be combined into a single sensor that measures stain along many axes. The most common multiple-matrix configuration is the bi-axial strain gauge. For the bi-axial strain gauge, two individual strain gauges are oriented at a right angle, with their axes passing through a common point. Other multiple matrix orientations include gauges for measuring shear strain, residual stresses, and hole stresses.

In considering the strain gauge sensor for use in the Park Sense System, we planned on using the strain gauge to collect data from the strain caused by the parked vehicles. Using this data, we could therefore determine whether there was a vehicle occupying a specific parking spot, as well as how long the vehicle had been occupying the parking spot. The ultimate reason why we decided not to choose the strain gauge sensor was cost. In order to fit within the confines of our limited budget, it was impossible to economically create this system.

40

Furthermore, with a multitude of less expensive systems at our disposal, it seemed unwise to choose this system over the other systems considered. A diagram of a strain gauge is show below.

Figure 3.1.8.1-1: Example of a strain gauge

3. 2 Transceiver

41

When it comes to transmitting and receiving data, there are a number of options. For the Park Sense system there are basically two options for data transfer. One is wireless and the other is hard wiring. It is important to note that hard wiring this system together is very expensive and relatively inconceivable. More importantly, there are a number of wireless options, which is what is likely needed for this project. For this project, the best option would be a system that could be described as a wireless sensor network. A wireless sensor network is the ideal system for connecting a number of autonomous sensors such as those that will be used in the Park Sense project. Some of the viable options for the Park Sense system include: Bluetooth, Wi-Fi or wireless LAN (WLAN) which operates on the 802. 11 wireless standard, ZigBee, WirelessHART, and 6LoWPAN, all of which operate on the 802. 15. 4 wireless standard.

The transceiver chip or module will likely also be part of what will be a sensor node, which will be located in each parking spot. The transceiver technology will likely be dependent on the choice of sensor.

3. 2. 1 Bluetooth

Bluetooth is one of the better known open wireless protocols. Bluetooth technology fits the basic needs of this project. Bluetooth uses transceiver microchips to communicate with one another within a certain range. Bluetooth is generally used for indoor applications for uses in offices and homes. However, Bluetooth can still be used in an outdoor or garage setting such as what would be required for Park Sense.

The range of Bluetooth varies with power input. Bluetooth is known for being used mainly in close range and short distance applications. However, Bluetooth can reach up to 100 meters or around 300 feet on a class 1 Bluetooth device which has a maximum power permission of 100 mW. Bluetooth also uses radio communications so devices do not have to be within line of sight of each other. Recently, Bluetooth has introduced a low energy platform that can sustain battery life up to one year.

Bluetooth has a couple of disadvantages that prevent it from being ideal for sensor networks. One of these disadvantages is that Bluetooth has a slow discovery time. It often can take a substantial amount of time for Bluetooth devices to find each other and connect. Not only is this exorbitant amount of time a problem for expediency of activation of nodes and joining the network, it is also a problem in that it requires more energy for the devices to find each other. The longer it takes; the more power is consumed by the devices. Hand in hand with this problem is the problem that Bluetooth also consumes more energy during the communication process. Communication makes up a bulk of the functionality of the Park Sense system. There will likely be data communicated many times within a small time interval to keep the information displayed as

42

accurate and up to date as possible. Both of these issues make Bluetooth a relatively poor choice for Park Sense.

One way that Bluetooth could be effectively used in a sensor node system like Park Sense would be to use IP as a communication source between nodes. This is similar to how a system using Wi-Fi or 6loWPAN would operate. While this would be one of the better ways to operate a Bluetooth communication sensor network, it is still not the preferred way of constructing the Park Sense project.

A final issue to mention with Bluetooth is minimal number of nodes that can be included in the system. For Park Sense, this is not that significant of a problem. This still presents a lack of scalability and makes it fairly pointless to base even a small scale system based on this technology.

Ultimately, Bluetooth does not seem like the best option for this project.

3. 2. 2 Wi-Fi

Probably the most well known wireless data transmission standard, the 802. 11 WLAN is always a viable option when it comes to wireless communication. In order to use Wi-Fi in a mesh networking application similar to what would likely be used; the Wi-Fi devices would probably have to be used in an ad hoc wireless network. This would add some complexity to the system that may be unnecessary. Wi-Fi has a number of disadvantages. It has a fairly limited range, not usually more than 95 m when in the open air. This limited range includes an inability to penetrate materials such as concrete.

Wi-Fi performance decreases rather significantly as the range of transmission increases. If the required transmission range gets to be significant, the power consumption of the Wi-Fi transmitter can get fairly high. In an expanded version of this project, transmission ranges could become reasonably large. The battery life of Wi-Fi enabled transmitters would be very low. The requirements of power efficiency would be far from met.

One last disadvantage is Wi-Fi’s questionable security. Wi-Fi networks can easily be broken into, even when proper encryption measures are taken. In a system with a potentially high number of access points, this security risk is even more of a problem. The Park Sense system could conceivably have a large number of access points, which would make this a potential problem for this project. Without needing to go into much more detail Wi-Fi is fairly clearly not the choice for this project, but should not be ruled out entirely.

3. 2. 3 ZigBee

43

The best aspect of ZigBee is that it is generally low cost and low power, two of the key features that would optimize Park Sense. ZigBee also allows for mesh networking, which is a viable option to be considered for Park Sense. ZigBee has the ability to go from its sleep mode to being fully active in as little as 15 milliseconds. This response time is incredibly fast, especially in comparison to Bluetooth which can take as long as 3 seconds to awaken from its sleep mode. This quick activation time allows the ZigBee device to remain inactive for the bulk of the time. This helps conserve power and extend the life of the battery. Because of this, the standard battery life of a ZigBee device can be up to 1000 days, compared to a maximum of around 5 days for a Wi-Fi device. The supply voltage to a ZigBee device is usually somewhere around 2. 8 to 3. 5 VDC. This would meet the requirement for the system of being less than 9V. This is also a case where the lower the supply voltage, the better the choice.

Aside from its relatively low cost and power efficiency, ZigBee also has many other advantages that would also be useful for Park Sense. One of these advantages is the fact that like Wi-Fi, ZigBee also has a security ability that allows for the establishment of secure networks. One of the requirements that was discussed for the Park Sense system is the ability to interconnect multiple sensors. The small scale design of Park Sense for this project may only have a limited number of sensors, but the ability to extrapolate the design onto a larger scale is also something that was discussed. ZigBee helps to make this possible by having the capability of handling up to 65,000 sensor nodes on a single network. Therefore, should the design be expanded for larger projects, ZigBee would remain a favorable option. A diagram of a typical ZigBee network is shown in Figure 3. 2. 3-1. This diagram shows two sensor nodes along with a human interface and a data logger. The diagram also has a coordinator unit, which probably would not be included in the Park Sense design. Compared to the design of this project the two sensor nodes would be whatever sensors are chosen. The data logger would be the server along with the display showing the available parking spots. The human interface probably would not be included in Park Sense but could be considered a sort of remote control that would be used to remotely access the system without being on site.

44

Figure 3. 2. 3-1 Diagram of a Five Node ZigBee Network

A critical characteristic of the wireless transceiver component for Park Sense is the range of transmission. ZigBee offers a transmission range between 1-100 meters. This is similar to Wi-Fi. However, there are ZigBee modules, such as Digi’s XBee Pro Module, that allow double to triple the range of most ZigBee modules. A module such as this would provide a transmission component of up to 1200 meters. 1200 meters would be more than enough for the small scale of the Park Sense project. In fact, for this scale of project, 100 meters would likely be plenty. However, keeping in mind the idea of expanding the project, ZigBee would be a better source of wireless network in comparison to Wi-Fi.

ZigBee is available in a number of formats. The main decision amongst platforms comes down to chipsets or modules. Modules are generally easier to use and require less work. Because of this, modules are generally more expensive than less complex chipsets. However, with modules, what you save on time incorporating it into the system is worth the money. Depending on the desired range and the power of the antenna, ZigBee modules can cost anywhere

45

between $20 and $100. The best option for Park Sense would likely fall somewhere in the middle of this range. In fact, for the small scale of this project, even a lower end module with a limited range would suffice. The main cost associated with the ZigBee module is the price of the development kit, which can be anywhere from $250 to over $300 dollars. This is likely a cost that would be incurred with any transceiver build. The best option here would be to try to find the modules bundled with the development kit. This type of bundle can generally be bought for less than $300 itself from providers such as XBit.

Another benefit of the ZigBee module is its easy to use software interfacing. ZigBee has a number of stack configured software packages. These make the ZigBee module incredibly easy to incorporate into the system.

3. 2. 4 6loWPAN

6loWPAN is an acronym for the IPv6 over Low power Wireless Personal Area Networks. 6loWPAN offers the ability to wirelessly connect not only between individual nodes but also to the internet. This technology allows individual devices to be assigned their own IP addresses so that they can each be connected to via the internet. Basically 6loWPAN operates very similarly to ZigBee but enhances it by allowing each individual node to be connected to the internet where it can be accessed remotely at any time. Each device is assigned its own IP address for connectivity to the network. 6loWPAN makes this possible by compressing the size of the header used for IP communication.

6loWPAN is a much newer technology than ZigBee. Therefore, it is a little more untested and is still an up and coming standard. 6loWPAN does not have compatibility with very many devices. The selection of parts such as a microcontroller is limited to the few that can work with certain 6loWPAN compatible chips. 6loWPAN is still probably too new to be considered a viable option for use in this project.

3. 2. 5 Z-wave

Z-wave is yet another low power wireless technology. Z-wave operates below the 2. 4GHz frequency level that Wi-Fi and ZigBee operate on. Because of this it also has a lower bandwidth so less advanced information can be communicated. This should not be a problem for the Park Sense system because the data transmitted would be in the form of a yes/no or a 1/0 corresponding to if there is a car in the parking spot or if the spot is vacant.

Like ZigBee, Z-wave is a mesh networking technology. Z-wave, however, is a technology that usually has to come imbedded in a device. It is also a technology that is usually controlled with some sort of remote controller. This would not work well in the Park Sense system. The Z-wave devices, if used,

46

could be controlled by the microcontroller within the node that contains the Z-wave device. This would probably take a lot more work and be a lot more troublesome to integrate. Z-wave devices are typically integrated into a system through a remote with a series of button strokes, similarly to how a universal remote is integrated with a television. This is not a very desirable method for the proposed system.

The typical range for a Z-wave device is around 100 feet. This puts it in a class slightly above Bluetooth and slightly below Wi-Fi. Z-wave communication, however, is significantly reduced when it is not in open air. This would make it a terrible choice for and indoor garage, especially considering the density of the concrete walls in garages.

Another potential problem with Z-wave is that the standard is not open source. Therefore, there would be limited options in finding compatible software or even compatible devices for use in the Park Sense design.

Z-wave is also not as power efficient as some of the other options. The Z-wave device would need to be almost always on. The Z-wave topology is a unique mesh networking topology in that nodes can communicate even when they are out of range of each other. This is achieved because nodes can act as repeaters within the mesh. Therefore, signals can be sent between nodes that are not within range of each other as long as there is a node that is within range of both of them that is available to act as a repeater and relay the message between nodes. The power aspect becomes a factor in this situation because the Z-wave device cannot act as a repeater when it is in its sleep mode. If the Park Sense system is ultimately designed to with Z-wave, it would likely be because of its unique topology being an advantage. However, even with this advantage, there would be a disadvantage in the amount of power needed for the device to always be active. Keeping in mind that one of the goals of the design is to maximize power efficiency, Z-wave would likely not be the top choice to use for the wireless communication technology.

3. 2. 6 DASH7

Even with what has already been discussed, there are still another of transceiver options for wirelessly communicating amongst devices. One of these technologies is DASH7. DASH7 is primarily used in NATO military applications. DASH7 is known for being ultra low power and having a very large range.

DASH7 has a range of nearly 1 km. DASH7 has also been tested to achieve ranges up to 10km in some applications. This is incredible range. It far exceeds the range necessary for this project. However, this makes DASH7 an interesting option for a larger scale application of this project. Along with its long range, DASH7 also has the ability to penetrate water and concrete. While the ability to penetrate water does not do much for this project, penetrating concrete is an

47

excellent characteristic seeing as concrete is the predominant material used in parking garages. This range is mainly achieved because DASH7 operates on a much lower frequency than technologies such as Wi-Fi or ZigBee.

Like ZigBee, DASH7 is also low power and also has a low latency. The amount of time it takes for a DASH7 device to go from sleep mode to activity is between 2. 5 – 5 seconds, which generally is fairly fast. This is nowhere close to the speed that ZigBee offers and possible too slow for what is needed in this project. When considering low power, DASH7 offers multiyear battery life for its devices.

Something that most people fail to consider is licensing of spectrum use. DASH7 operates in the 433 MHz band which does not require licensing with the FCC in order to obtain an operating frequency. This may seem like a small benefit but it reduces the fees associated with licensing as well as the time it takes to get a license granted. This is a small advantage as it is also an advantage for Wi-Fi, Bluetooth, and ZigBee as well.

With ZigBee being so popular and DASH7 being more of an up and coming technology, there are a lot of comparisons to be made. Below is a table summing up some of the key similarities and differences between the ZigBee and DASH7 technologies.

Table 3. 2. 6-1: Comparison of ZigBee and DASH7

Concrete Penetration

Range (meters)

Power Draw

Latency Cost Sensor Support

Max Bit

Rate

ZigBee

No 100 300-600 mW

100 ms $10+ Yes 20-240 kbps

DASH7

Yes 1000 30-60 mW

2. 5-5 s $10+ Yes 28 kbps

3. 2. 6 Other Notable Options

Even with all of the options discussed up to this point, there are still many more options for wireless mesh networking that have not been discussed. Some of these other options include INSTEON, which is commonly used in “smart house” mesh networking applications, EnOcean, which is a battery-less technology, but has not yet been made a standard, and ONE-NET, which is an interesting open source option that can be used with many off the shelf transmitters and microcontrollers. These options are still interesting, but are both too new and not

48

reliable enough, or simply do not meet the required specifications that have been outlined for the Park Sense project.

3. 2. 7 Part SelectionObviously, not all of the technologies discussed thus far can be conceivably used for this project. However, there are still more than enough options to be considered for use in the final design of this project. The table 3. 2. 6-1 below shows some of the key components of each technology that have been used to make a decision on which one to use. The most important characteristics are shown in the table. The most important aspect considered was the price. After being narrowed down from price, the next most important aspect was the range. Most of these technologies have a range that is suitable for the Park Sense project. Having said that, it is still preferable to have the largest possible range of transmission possible. Not listed in the table is also the aspect of whether the range can penetrate certain materials. This aspect was also considered in selecting a transceiver technology. After cost and range, the most important characteristic of the transceiver module to be use was its batter life. This is also listed in the table. Finally, there are a series of less important aspects that were also considered in making this decision. One of these aspects is the possible number of nodes in the network, which is also listed in the table. This table is just a brief summary of the many contributing factors that went into making the decision of the best wireless technology to use in the project.

Table 3. 2. 7-1 Comparison of Best Wireless Transceiver Options

Bluetooth Wi-Fi ZigBee Z-wave

Range 1 – 10 m 1 – 100 m 1 – over 100 m

30 m

Cost ~$10 ~$10 ~$10 ~$10

Power Efficiency

1 – 7 days battery life

1 – 5 days battery life

100 – over 1000 days battery life

1 – 10 days battery life

Max. Number of Nodes

7 32 64,000 232

Based on the information from this research, the obvious choice for a transceiver would be to use a ZigBee module. ZigBee is basically the standard for wireless sensing networks. The ZigBee technology perfectly fits the design of this sensor system. Regardless of the type of sensor or microcontroller used, the ZigBee technology should work seamlessly. ZigBee can work perfectly with both a wireless sensor network as well as relaying the information from video imaging.

49

Since ZigBee has been settled upon, there are a few more details about the technology and how it relates to this project that should be briefly discussed. One thing to note is that ZigBee operates in the 2. 4 GHz band. This does not matter much to the project but it should be noted that devices operating in this band could be susceptible to interference from Wi-Fi networks and other popular devices operating in the same band that would likely be in or around the parking lot.

There is a wide selection of ZigBee module manufacturers to choose from. Unfortunately, one of the main contributing factors in making the decision of which module to select is cost. For most manufacturers, the ZigBee module is relatively inexpensive. It is the development kit that usually has a high price. As discussed in the sensor section, the likely choice of sensor is going to be video detection along with image processing. Needing only one camera for this, there will only be need for one ZigBee module at the site of the camera and one ZigBee module at the site of the server or display. Therefore, while the other requirements for the ZigBee are going to be considered, it will likely be the price of a single ZigBee module along with a development kit that will be selected for the project. The upcoming sections will discuss different ZigBee chipsets and modules, as well as manufacturers and ultimately which manufacturer and part will be selected.

3. 2. 7. 1 Digi XBee Module

The market in ZigBee modules has basically been cornered by one manufacturer. This one manufacturer to be considered is Digi, maker of the XBee module. Digi touts the XBee module as being ideal for low-power, low-cost applications. Digi also offers an XBee Pro module, a power-amplified version that can be used for longer range applications. This project would likely not need an XBee Pro module. The distance of transmission is not that far.

Getting right to the most important part, the price of an XBee module is $19 when bought directly from Digi For this price. There are four different XBee ZigBee modules. There is not much difference in these different modules. The main difference is the type of antenna used. The XBee can come with either a wire antenna or a chip antenna. The options on the other two XBee modules are simply different connector options on the module. The difference in antenna should not really matter for this project. It is always good to have options especially with things such as connector variations. Any of these options should work and they do all cost the same price of $19 each. However, the cost of a professional development kit from Digi is $399. This far exceeds the amount of money that had been budgeted for the transceiver. Digi also offers a package deal with two XBee modules as well as a starter development kit for only $129. This kit also includes adapters, cables and a development board. The development board, as well as the cables and connectors, is likely a part that

50

would need to be purchased anyway. Therefore, if the Digi XBee modules were selected, this would likely be the option to go with.

With price out of the way it is important to discuss some of the other important features that are offered by the Digi XBee module. Two of the more important aspects that were discussed during the initial research section were the power consumption and the range. The XBee module offers a range of 30 m indoors to around 100 m outdoors. This project would likely be in a semi-outdoor environment. More importantly in the Park Sense project, the two ZigBee devices will likely be in plain sight of each other meaning that the higher end of the range will likely be obtained. The XBee module also offers 1 mW transmit power. This is reasonably low and should be efficient enough. This module also has supply voltage limits of 2. 8 – 3. 4 VDC. This should help in trying to have the entire sensor node operate on a 9 V battery.

The XBee module has a number of operation modes. The device’s default mode is an idle mode in which it has the option to go into various different modes depending on certain scenarios. The idle mode reduces the amount of power consumed by the device. From this mode, the XBee device can go into either transmit mode, receive mode, sleep mode, or command mode. The availability of the idle mode helps to conserve power in the device. The sleep mode is only available in the end device, which in this case would be the sensor node, or more specifically, the ZigBee, camera, microcontroller unit.

Interoperability is another important issue to consider. The XBee module is interoperable with other devices that are EM-250 based. These devices include a wide selection of microcontrollers. Yet another important specification to consider is the sensitivity of the receiver. The sensitivity of the receiver contributes to the range of the device. The range of the device can be boosted by either increasing the power sent to the transmitter or by increasing the sensitivity of the receiver. The sensitivity of the XBee transceiver is about -95 dBm. This sensitivity is acceptable for the Park Sense design. It is important to keep in mind the benefits and disadvantages of both methods of increasing the range. The problem with increasing the power to the transmitter is obvious. It increases the power consumption and thus reduces the battery life. The problem with increasing the sensitivity of the receiver is that it makes the transceiver more susceptible to interference. For Park Sense, the system is in a busy garage or parking lot where it would be susceptible to interference from other networks such as Wi-Fi or cellular networks. The -95 dBm should be a good level for optimizing range without being too strong as to collect interference.

The Digi XBee transceiver also offers a boost mode. This mode would expand the range of transmission between transceivers. This is achieved by increasing the current sent into the transmitter and increasing the sensitivity on the receiver end. This mode would likely not need to be enabled in the Park Sense system, but it would be a useful tool should it unforeseeably be needed.

51

The XBee module also supports a number of topologies. Amongst others, these topologies include point-to-point and mesh. One of these is likely the topology that would be used for the Park Sense project. Mesh would be used if a normal sensor node is used. Point-to-point would likely be used for the design with a single sensor where a camera is used to detect the availability of a parking spot and the only communication is between that sensor and the server.

There are also physical properties to consider. The XBee module is about 2. 5 cm x 2. 5 cm and weighs about . 1 oz. Obviously, for any type of sensor node, the smaller, the better. The XBee module is also compatible with many microcontrollers and development boards. Many of these boards have built in pin connections designed specifically for attaching an XBee ZigBee module. All in all, the XBee ZigBee module is definitely the most likely option in part selection.

At this point, the part that will likely be used is an XBee DigiMesh 2. 4 RF module made by Digi International. This is the most readily available part, as well as the most easily integrated into the Park Sense design.

3. 3 Networking

A major part of the Park Sense project is how the system will be networked together. The following sections outline some of the networking options that have been considered for the project.

3. 3. 1 Wired Networks

In today’s day and age almost everyone is familiar with a wired network. This topology consists of a central node connected to all other nodes via Ethernet cable. As for the wiring, CAT-5, the most popular, which supports up to gigabit (1000Mbps, megabits per second) data transfers but does not perform as well at higher rates, CAT-5e which better handles a gigabit networks better than CAT-5, and finally CAT-6 which is ideal for a gigabit network or multi-gigabit networks but comes at a greater cost per meter. As for range, all 3 types have a maximum length of 100m before attenuation becomes a problem. The diagram below shows a traditional network topology.

52

Figure 3. 3. 1-1: Traditional Network Topology

3. 3. 2 802. 11 Wireless Networks

As far as topologies go, this is identical to the wired network minus the wires. Using the 802. 11 protocols, a, b, g, and n, although a and b are virtually phased out of the market now. 802. 11g operates in the 2. 4GHz band and has data transfer speeds of 54Mbps and a range of up to 150ft, and with super “g” routers can push up to 108Mbps. The problem with g is that the 2. 4GHz band is shared by many household electronics, cell phones, cordless phones, and microwaves to name a few. 802. 11n offers the use of the 2. 4GHz band or the 5GHz, and offers a theoretical max speed of 300Mbps. The difference between the 2 bandwidths are the fact that 2. 4GHz offers longer range (150ft) with more interference, while 5GHz will have a shorter range but better wall penetration and overall less interference from other electronics.

3. 3. 3 Mesh Networks

There are 2 main types of mesh networks, partial and full. A full mesh is where every device involved is connected to all other devices giving data transfer multiple paths and redundancy in case of failure. A partial mesh still allows for

53

multiple paths but without the need to interconnect every single node. Refer to the drawing below in Figure 3.3.3-1:

Figure 3. 3. 3-1: Mesh Topologies

It becomes exponentially more expensive to implement a full mesh as number of nodes increase, in the case of a wired network. When implementing a wireless mesh network, the cost of wires is alleviated, but now you have to worry about the range your transmitter is capable of. Because of this range issue a wireless partial mesh network where each device communicates with all other nodes within range would be very useful. Through the use of software, which determine how the nodes will interact with each other, in combination with existing wireless protocols, more specifically the 802. 11 family, a mesh network would easily be scaled up to cover an entire city.

3. 3. 4 Compare and Contrast

You can’t beat a large wired network when it comes to simplicity, quick and easy to setup on the software side, and no need to worry about security as with over the air transmissions. An 802. 11 wireless network with a central server, keeps the network fairly simple, the speeds offered would be more than enough to handle any type of traffic that would be used on this project, but without some security, WEP or WPA for example, the wireless signal would be picked up by anyone with a laptop in the area, and they’d have free reign over the server. The other issue with a plain wireless network falls in the parking garage section of this project, your range gets cut down a great deal by the concrete walls, ceilings,

54

and floors, meaning each floor would need multiple access points to keep the signal strength acceptable enough for fast data transfers. The mesh is by far the most complicated of the 3, but also the most reliable, with self healing capabilities loss of 1 line means little with multiple paths available for the signal to travel. You’re setup time may see a large jump, although you no longer have the cost of laying cable, or scattering access points all around, instead each node acts as an access point.

Cost will depend on the type of sensor we choose to use. For instance, the amount of networking equipment and the amount of cable needed if the technology we choose can only detect 1-2 spots each would be astronomical. However, if we choose the route of image detection, where 1 camera would be able to be responsible for a large amount of spaces a wired network answers the call with great data transfer rates, and fewer cables would need to be run. Also, wireless cameras could be used to prevent the need of running cables to every node, but instead just to select spots for access points.

3. 3. 5 The “Park Sense” Network

To network devices throughout something as large as a parking lot or garage, laying and hiding cables would be a huge obstacle. Also, distance and concrete walls pose a threat to traditional wireless network signal strength. The solution we chose to use is a wireless mesh network with a wired server which handles all the data collected from the sensors. The technology that will allow us to do this is Zigbee, a very low power device equipped with a transceiver. Each unit will contain a sensor as well as a Zigbee that will communicate with any neighboring unit, allowing the signal to travel quite a distance without the use of wires or multiple access points/routers.

3. 4 Power

Ideally, if a system like this was being installed in a parking lot or garage, the power lines run for the lights would be used. Since these devices are very low power consumers in comparison to the lights themselves, it would have very little impact. This would eliminate the need to run additional power lines, or replace batteries whenever a unit dies. All that would need to be changed is adding a circuit that ramps the input voltage supplied to the lights, down to what the units use.

Our first choice for a power supply was solar. This would eliminate the need to replace batteries, and be eco-friendly. This was quickly shot down by the fact that in a parking lot, depending on the location of the units, it would be very difficult to protect the solar panels from bad parking jobs and the curious passerby. Also, running lengths of wire to keep the panels away from people would dramatically increase the cost of the system.

55

3. 4. 1 Camera Based System

For a system based on cameras we would have to hardwire the power. The cameras would not be able to run long term on battery power. Instead additional power cabling would need to be run. The fact that through image processing the number of units needed to cover an entire lot/garage would be dramatically reduced, so the extra cost of laying cable would be a very feasible and affordable solution.

For an outside parking lot, solar power would also be an alternative, the cameras would need to be mounted fairly high off the ground as it is, and protecting a unit from every day foot traffic is no longer an issue. For night time use, a battery could be installed and charged during the day. Individual solar cells output . 5 volts regardless of size, to obtain a greater voltage, much like with batteries, you connect cells in series. To increase the amount of current the solar system can handle you increase the size of each cell. Adding a battery to a solar system is necessary for this application, and will also increase the price and maintainability. For a parking lot that isn’t in the shadow of taller buildings most of the day this would be a great idea. The batteries will need to be housed to protect from weather as well as maintained as per the batteries specifications, usually around every 5 years. The benefit of course being not having to pay for the operating cost of the system.

3. 4. 2 Sensor Based System

On the other hand a system that was reliant on units at every or every other parking space, we determined the use of batteries to be the best course of action due to the sheer number of sensors that would be needed for a parking lot or garage, running wires to each is out of the question. With the use of batteries we have to use a system that is able to come in and out of a very low power consumption state, i. e. standby or timing circuit to control when and how long the device turns on and off, to extend the battery life. A system that needs new batteries every week wouldn’t be very useful. A summary of typical battery statistics is shown in the table below.

56

Table 3. 4. 2-1: Comparison of Typical Alkaline Batteries

Type Mass (g) Nominal Voltage (V) Capacity (mAh)

AAA 11. 5 1. 5 1250

AA 23 1. 5 2890

D 148 1. 5 20500

C 66. 2 1. 5 8350

9V 45. 6 9 625

Information from http://en. wikipedia. org/wiki/Battery_%28electricity%29

Given the fact that most sensors we are considering, whether they are infrared, induction coils, or ultrasonic, accept voltage in the range from 3V-10V. To keep the cost per unit down and still get good power output and battery life, alkaline batteries are the best option. With the voltage and cost restriction, we are limited to either using multiple AA or AAA (1. 5V) batteries in series until the desired voltage is obtained, or use 9V batteries and scale the voltage as needed with circuitry.

Next we have to consider battery life. The operating life has to outweigh the cost of changing the batteries when the time comes. Battery capacities are rated in milliampere hours (mAh), the average AA alkaline battery holds about 2850 mAh and the average 9V alkaline battery is 595 mAh. In series the voltages add while the capacity remains roughly the same in practice, so if we compare the 2 types based on voltage…6 AA batteries would out live the single 9V but would require more space and weight. Comparing by capacity wouldn’t bode well, 5 9V batteries would be needed to match the AA.

3. 4. 3 Compare and Contrast

With the power options being defined, the following sections will serve as a summary of the comparison in the options in a number of important factors. These factors are what were considered in choosing the power options.

3. 4. 3. 1 Cost

57

The main difference between the implementation of either hard wiring or batteries is the cost. With power already being run to the area for lighting and other electronic devices, the cost of tapping into the main line and routing power to individual units will have a substantial initial cost but very little cost after the install. The average price for romex cabling is roughly $0. 50 a foot according to Home Depot, of course this isn’t including the cost of the labor to do the actual install which will range on the actual area of installation.

With solar power, we need to know the input voltage of the device being used to know how big of an array we would need to implement. If we estimate the device use 12V and 15W, the current pull will be a little less than 1 amp. West Florida Components sells a 12V, 20W solar panel for $169. 50 with dimensions to be about 2ft by 1ft, and so the camera can operate at night, a battery will cost at the cheapest $100. If we estimate a camera with an enclosure to be about another $100, that brings the cost of 1 system to be about $370 for a parking lot install. This may sound like a large figure but this will be able to detect over 20 spaces if positioned correctly, making the cost per space less than 20 dollars. This system would be most “green” solution and wouldn’t need much maintenance, aside from the battery every 5 years. If the install was for a parking garage solar wouldn’t be an option anymore.

On the other hand we have batteries, on average a 9V battery will cost somewhere between $1. 00-$1. 50 or AAs will cost about $0. 15-$0. 25 per battery, and if each unit uses more than 1, the price you’ll be spending on batteries alone will seem outrageous but would still beat the price of wiring install, as far as initial costs go. Plus, with the use of batteries comes the replacing of the batteries. From looking at similar projects (see references in Similar Projects section) with sensors designed to run off batteries, they calculated the theoretical battery life to be 4 years, with a more practical estimate to be about 2 years. Meaning that every 2 years you’ll have to pay that initial cost again, and this time have to pay someone to go around and install the batteries in each unit, not including each time a battery just randomly dies. Basically the maintainability of using batteries will easily overshadow the cost of laying wire.

3. 4. 3. 2 Sustainability

The second issue to debate is the sustained power output. Batteries and solar panels tend to degrade over time and no longer give the nominal output in their specifications. This is definitely something to look at, if you designed to work at the peak output of the battery or panel, the device might give out before the battery actually dies, due to a poor input, reducing battery life and increasing maintainability costs. Also with solar, power output is dependant upon the amount of sun that is available. During cloudy conditions and storms, the system would be dependant upon the battery in the system, which may not be a bad thing if the capacity of the battery is large enough to last a few days. The only

58

winner in this department is a hardwired line; it will always have the same output as long as the site has power supplied to it.

3. 5 Image Processing

Image processing is a very vast field that spans from detecting a face on your digital camera to allowing a robot to act on its own. This will be the key component to the project should we choose to use a camera.

3. 5. 1 Overview using Image Processing

The basic idea of what the group wants to do is, first mount the cameras in an area where they can clearly view the largest amount of parking spaces and have that camera take a control image, no cars can be present in the control image. Control images will be grayscale and need to be taken for the times of day with the biggest lighting differences, to prevent false positives due to lighting in the comparison that comes later. Each camera will have to have its own calibration file and control images, the calibration files will be addressed in greater detail later in this section. Then, once the system is setup each camera will take a grayscale image on a set interval not to exceed 1 minute between each picture. This image will be sent to a specific directory on the main server for that camera. When the server detects a new image in that folder it will load that cameras calibration file, check the system clock to know which control image to compare it to, and finally, do the actual comparison.

The data retrieved from the comparison will be sent to another program or database that will contain entries for each specific parking space in the given lot or garage. Through this system a graphical layout displayed on a monitor at the entrance of said parking lot or garage will be updated at about the same interval that the images are taken.

3. 5. 2 Calibration File

There are many ways in which we can approach how to make this calibration file. A few of the possibilities the group is exploring are: Reading in an image as an indexed array of each pixel and comparing to the control image indexed the same way, comparing the histogram of each image, or using an open source library like OpenCV to implement machine learning with object recognition.

3. 5. 3 Indexed Array

The way an image is stored digitally is in a vast indexed 2-D array of numbers. The numbers are the intensities of the color channels present in the given image

59

for each pixel. In a grayscale image there is only 1 value, the gray value, in a color image there will be 3 values, the red, green, and blue. It is much easier to work with a grayscale image given the fact that you have one third the amount of data per pixel. The indexes of the control image and the new image will be almost identical since they are framed the same. Knowing this, the programmer can set up the program to only compare these arrays in desired locations, in this case in between the white lines of parking spaces. What is being compared are the values of gray, because the camera isn’t perfect noise will be introduced as well as small lighting differences, a built in tolerance will be needed per pixel. On top of that, a question that needs to be answered is “How many pixels need to be different to clearly say a vehicle is present?” These are both parameters that will be determined during the testing phase of this project. Of course, because each camera isn’t oriented exactly the same, nor is it monitoring the same number of parking spaces, each camera will need its own calibration of which areas we are actually interested in comparing.

This method doesn’t require additional libraries, although it is possible that some exist to simplify the programming needed. The pros of this method are that the programming involved doesn’t take a veteran programmer to understand, and it can get the job done fairly quickly on basic hardware. The main con to this method is the setup time, for each camera added to the total system the greater the setup time becomes. The following figure shows an example of what one of these arrays look like.

Figure 3. 5. 3-1: Image Pixel Array

60

“OpenCV book” page 3

Reprinted with permission granted in book “OpenCV is free for commercial or research use, and we have the same policy on the code examples and images in

the book. Use them at will for homework, for research, or for commercial products. We would very much appreciate referencing this book when you do,

but it is not required. Other than how it helped with your homework projects (which is best kept a secret), we would like to hear how you are using computer

vision for academic re-search, teaching courses, and in commercial products when you do use OpenCV to help you. Again, not required, but you are always

invited to drop us a line”

3. 5. 4 Image Histograms

This is a type of histogram that displays the number of images for a given tone, for each pixel color present, i. e. red, green, blue. Once again the simplest image histogram would be a of a grayscale image. Similar to the method above, a histogram of the area in question would have to be generated and compared to the control image histogram of the same area. Functionally you’re doing the same thing as in the indexed array example just from a different approach; counting pixels of the same shade and if enough pixels are different enough, determined by a preprogrammed tolerance, an object is present. An example of what an image histogram looks like:

Figure 3.5.4-1 An image and its associated histogram

61

GNU license

In the same field of histograms would be the use of color histograms with background subtraction. Background subtraction is a method in which the control image with no cars in the parking spaces would be considered the background. First, the color histogram is generated for each area of interest in the control image and the real image. Then the Euclidean distance between the two histograms is found, and if the distance is above a certain level the space can be considered occupied.

62

3. 5. 5 OpenCV

OpenCV is an open source library written in C and C++ for aiding in computer vision. “Computer vision is the transformation of the data form a still or video camera into either a decision or new representation. ” The main focus of OpenCV is object classification and recognition on static images and real time feeds. Currently this library is widely used for many commercial uses such as; factory product inspection, medical imaging, security, and many more. Taking advantage of the five hundred plus functions in this library one can develop their own image processing tool.

As stated the main purpose of OpenCV is use in real time environments but can be adapted for use on static images. For this project, OpenCV may be considered for future systems. We do not anticipate having the processing power to update our parking space occupancy on a real time basis, nor do we want to over complicate the stated problem. Some tools available in the library may be utilized, but the bulk of the programming will be done in using the standard C++ libraries.

3. 5. 6 Computer Vision

A relatively new field of study, computer vision (CV) involves the combination of still or real time images and machine learning. The system takes in the visual input from a camera and uses computer software to make a decision. The amount of processing and programming involved with trying to make an electronic system see and react to the world how a human does, is immense. Currently in the world there are specialized systems that exist that have some sort of artificial intelligence, but this does not mean it thinks like a human. Through the use of such things like genetic algorithms and neural networks, among other AI programming techniques machine learning is possible. For instance, with object or facial recognition, a system may be trained on a large sample set of images of various faces the system will be programmed to calculate various parameters relating to placement and size of features that compose of a face. Once trained, when the system is presented with a new photo, not one from the sample set, it will be able to identify where a face is. Modern digital cameras use this very “basic” adaptation of computer vision. With Park Sense, we will be trying to adapt this kind of image processing to detect a vehicle.

3. 5. 7 Image Noise

One issue we will face no matter what method we choose to use is image noise. Just as with any electronic signal, noise can drastically alter the original data.

63

Image noise is attributed to the fluctuation of brightness and color data that can be produced by circuitry and/or the sensor used on a camera. Everyone has seen an image that appears grainy or when colors close to the same tone blend, these are both examples of noise. The better the camera and the more ideal the lighting conditions are of the specific settings of the camera will effect how much noise will be present. There are 3 main types of noise a digital camera will see; Fixed pattern, random, and banding noise. As depicted in Figure 3. 5. 7-1, fixed pattern noise is when some pixels brightness exceeds the levels of random noise which are always present. Random noise is just that, random, you will always have some level of random noise present, whether you can see it or not. Banding noise is often the fault of the camera’s components; it is introduced when the digital sensor passes its data on.

Figure 3. 5. 7-1: Comparison of Noise

Permission granted from Cambridge in Colour

3. 6 Display

A very important component in this project is the selection of the proper kind of display. We have to choose a display component that is compatible to our specifications and requirements. The display is of paramount importance as that they way the user will be able to see which parking spots are empty and where at

64

the front end. Basically at the front end we have two kinds of displays that we can use – LCD and LED displays. So we have to figure out the pros and cons of each display and use the best fit and the one that is most compatible with our project.

3. 6. 1 LCD Display

One of the LCD displays we looked at is a GLT240128. This 240 x 128 graphic LCD can display text in multiple fonts/styles/justification and graphics. ASCII serial commands are sent from the LCD display for switch closures and openings when switches are debounced. When the touchscreen is pressed, you can have the X and Y location sent, or have the on-screen keyboard displayed and touched keys are sent through the serial port. This had an interface builder which is easily customizable.

It has the ability to communicate via serial RS-232 protocol at regular and TTL levels as well as USB and I2C, the versatile GLT240128 can be used with virtually any controller. The GLT240128 comes in three backlight options, grey text on a white backlight, white text with a blue backlight, and standard grey text on a yellow-green backlight. Extended voltage options are also available to allow you to select the display which will best fit your project needs. One big advantage that this LCD display has over others is that it is touchscreen and so it works with our project idea well as the users can also interact and have different menu options when they pull up their car at the display. An example of an LCD display is shown in figure 3.6.1-1.

Figure 3. 6. 1-1: LCD Display

GNU License

65

But going by the requirements of our project our best option for an LCD display would be a regular LCF flat screen monitor that is used in most of the computers today. This would make our project simpler as we would have to just program a GUI to sit on top of the LCD. LCD monitors would be better than its CRT counterparts as an LCD monitor is brighter than a CRT, giving us a nice view even in fully bright sunlight situations. Brightness is measured in nits, or one candela per square meter. A standard measurement of brightness is between 250-300 nits. The brightness of the screen directly depends on nits as such that if the value of nits is bigger than we would have to adjust the brightness to a lower value.

When choosing the right kind of monitor for our project the big factor in our decision making was the fact that the LCD monitor is going to be out in the open as well as indoors. And moreover the angle as which people are going to view the screen should be a wide angle. In particular an LCD monitor has different specifications for the viewing angle which can be either vertical or horizontal, the specification states the degree of view ability while we slowly try to move away from the center of the screen and the screen view slowly diminishes. There is one way to solve this issue is to keep the level of contrast always high in these LCD monitors. Viewing angles of horizontal-140 degrees and vertical-120 degrees are the most efficient. LCD screens are far more energy efficient than the CRT monitors. It is also beautiful to look at and can be crammed in the smallest of spaces due to the fact that they are very thin. The radiation emmitance is always at a record low with LCD’s. Therefore an LCD screen is a perfect choice for any kind of project.

An LCD monitor comes in standard sizes from 15-inches to 21-inches, and larger. The viewing screen is the same size as the rated display, unlike CRT. Therefore a 15-inch LCD will have a 15-inch viewing screen. Therefore an LCD monitor with a computer running in its backend for the GUI would be a perfect solution to our display issue. An example of this is shown below.

Figure 3. 6. 1-2: Park Sense displayed on LCD Monitor

66

Recreated demo model

3. 7 Software packages

The software package would be open OpenCv for the backend image processing that will be handled by the computer behind the LCD. But the frontend that the user is going to see will be the GUI that shows them what parking spots are full and what parking spots are empty.

The graphical user interface will help us give a beautiful interface for the user with buttons and added functionality so that it will be easily available for to interact with the display. There are various programming languages that handle GUI programming to its core and also help us customize our GUI as tailored to our needs as possible. We will look at some of these tools below.

Figure 3. 7-1: GUI tools

67

Permission from Java. doc

3. 7. 1 Java

The first programming language we will look into is JAVA. In today’s world many computer applications are Java based as Java has excellent GUI tools which help us through the process of building an effective GUI. Swing is the "built-in" GUI component technology of the Java platform. Swing is the successor to the AWT technology that was provided with the early releases of the Java platform. So in other words, Swing replaces AWT. For example, in a Swing program you would use javax. swing. JTextField instead of java. awt. TextField. In another context, Swing builds on AWT: JTextField is a descendant of java. awt. Container, and many non-component AWT classes (such as layout managers) are used in swing programming.

NetBeans IDE 5. 5 is an excellent Integrated Development Environment that makes it easy to build GUI. Integrated inside the NetBeans package is the GUI builder which can be used to build great looking GUI with a simple user interface. The NetBeans GUI builder also has a feature called as ‘Matisse’ which gives us the tools and facilities to program and design the user interface f our application instead of worrying about different kinds of layout manages and stuff. One awesome feature about the NetBeans GUI builder is the tool to give us on the spot visual updates about the user interface we are building so this helps us in pointing out our errors right there instead of running the program then figuring out the bugs. This NetBeans GUI builder is included freely in the NetBeans package

68

and is independent of any platform and also supports the JAVA platform and the JAVA Standard Edition 6 code layout.

One big advantage that JAVA to its other GUI builder counterparts is the ability to be platform independent i. e it can run on any server or computer which has JAVA runtime environment installed. Figure 3.7.1-1 shows the JAVA building platform.

Figure 3. 7. 1-1: JAVA development tool

GNU licence

3. 7. 2 Visual Basic

The next programming language we are going to look at is Visual Basic. Visual Basic is an event-driven programming language from Microsoft. It is relatively easy to use than other GUI programming languages. Visual Basic is derived from BASIC and therefore facilitates in Rapid Application Development of a Graphical User Interface.

The GUI builder in visual Basic also has a very simple user interface. To build any kind of a user interface we just have to drag and drop an object anywhere on the form and then we can change different properties of the interface from the properties window. As we know a regular user interface we tend to click

69

anywhere on the screen so we have to program the GUI in such a way that the interface registers to our mouse clicks using events. These events should always be programmed independently. Because of this whenever we see a Visual Basic program we notice that it is made up of many subprograms and everyone of this subprogram can be initiated independently and also be linked together by more than one way. To build a GUI in Visual Basic is relatively easier to code but the one important thing its lacks is different kinds of functionalities that other GUI building languages give us.

We can using Microsoft Visual Studio (IDE) to build our GUI in Visual Basic. Visual Studio includes a code editor supporting IntelliSense as well as code refactoring. The visual basic debugger is a machine as well as a source bugger. The Visual basic GUI builder also includes forms designer for programming GUI user interfaces and applications, a web designer to build website and also a class and a database designer. Visual Basic also allows us to add different plugins and tools that suit our needs and also aids us in adding different kinds of functionality to our applications. This is shown below.

Figure 3. 7. 2-1: Visual Basic development tool

GNU licence

3. 7. 3 C#

The last programming language we are going to look at is C#. C sharp as it is widely known is a general-purpose, simple object-oriented programming language. C Sharp in such is a multi-paradigm programming language that

70

includes various disciplines of programming like functional, object-oriented etc. Many people today use C Sharp as their choice of programming languages as its content oriented and also it also helps in rapidly developing software applications regardless of the size of the software project be it small or big.

GUI programming in C Sharp is done using windows forms. Windows desktop applications in C Sharp are created using the System. Windows. Forms namespace. Making a GUI in C Sharp is a little more intense than the other programming languages but the outcome of the GUI is very commendable.

To build a GUI in C sharp we use the same Microsoft Visual Studio (IDE) but its component is called Visual C#. The Microsoft Visual Studio using C# is shown in figure 3.7.3-1.

Figure 3. 7. 3-1: Microsoft Visual Studio

3. 8 Possible Features

One of the keys to a successful senior design project is ensuring that the project is thorough. On the surface, the Park Sense system can appear to be relatively simple. The basic design of creating the sensor network is in itself a difficult

71

project. However, for the Park Sense project, there are a number of things that can make the project very complex.

This section of research is devoted to determining the features that can be added to the Park Sense project to make it more thorough and add aspects that improve user interface, efficiency and overall completeness. Much of the research in this section is based on related projects that were studied, as well as brainstorming of other ideas that can further improve the project.

3. 8. 1 Website

One of the obvious features that can be added to the project is the addition of a website. The website would basically be used as a way of remotely accessing the display. The display at the entrance of the parking lot is there to show where the open parking spaces are located. The website would be a way to see this same information from anywhere with internet access.

There are a number of benefits to adding this feature to the project. It adds an aspect of completeness in the fact that it utilizes another technology. It also adds an aspect of increased user interface. Having a website would provide an increased ease of access and also help a user who has not yet arrived at the parking lot. An example of this would be at UCF. Someone who has internet access and is arriving on campus can see the available spots before entering the lot. If the spots are full, the user can elect to bypass the lot altogether.

The website can also offer a number of other features in itself. In addition to showing the data that is displayed at the lot, other information can be presented as well. There is a plethora of other information that is vital to the parking process that can be accessible via the website. One thing that can be offered on the website is the weather of the area of the lot. This will help inform the user of the weather for not just parking and walking out of the lot, but also for the drive to the lot. The website could also potentially offer traffic conditions around the lot. This is another aspect that would be extremely helpful in a setting such as UCF where the traffic in different lots varies throughout the day.

There are also a number of statistics that could be added to the site. Some of these statistics that could be added to the site include things such as average wait time for a spot in the given parking area. There is also data on parking lot capacity that could be made available. Some of this data could be things such as graphs showing parking lot capacity vs. time of day. This information can also be displayed per level of garage and not just the parking lot as a whole.

The website is itself a feature that adds complexity and also provides a number of other opportunities to add features within itself. The only real drawback of the website is the time that it will take to create. There are a few monetary aspects of a website as well. These are just minimal costs that include the software used

72

to create the website as well as the domain name and hosting fees. While none of the decisions have been made on which features will be used and which will not, it is likely that a website will be added to the project.

3. 8. 2 Smartphone Application

Going hand in hand with a website, another feature that is popular today is the addition of a Smartphone application. However, there are complexities to adding a Smartphone application that make it slightly less realistic for this project than a website.

The benefits of adding a Smartphone application for this project are very similar to those of a website. The application would probably not offer as much of the information that the website would. The Smartphone application would likely be a simpler version of the website. The best design for a Smartphone application would be to make it exactly the same as the display. This would make for the most simple and feasible design. Another benefit of the Smartphone application would be potential revenue. If the application were sold, revenues from the purchase would help differ some of the costs of the project. However, the application would likely be offered for free.

As an extension of the website feature, the Smartphone application would be an even further extension of getting up to date parking information on the go. It would be a way of accessing the parking information where there is no internet access and the user is not yet to the display.

Smartphone applications can be projects within themselves. There are a number of complexities to Smartphone applications that make them much more complicated than a simple website. Considering the amount of time that the rest of the project will take and the lack of experience in creating programs such as what would be required make developing a Smartphone application an unlikely feature.

3. 8. 3 Increased Nodes and Project Scaling

Ideally the Park Sense project would monitor every spot within a parking lot or a parking garage. One possible feature for this project is scalability. Unfortunately, for this project, the scale will be limited to just 3 or 4 parking spots. The idea of creating enough sensor nodes to cover an entire parking lot has been discussed. There are a number of reasons that make this unfeasible. The main reason against covering an entire parking lot is that is not cost effective. It is simply too expensive to be pursued in the Park Sense project.

Covering an entire parking lot would certainly add an aspect of completeness to this project. However, because of the lack of financial resources, the Park Sense project will be limited to covering only a handful of spots. In this way, the Park

73

Sense project is more of a prototype of what could be developed into a larger system. Because of this, many of the other sections of research address the idea of expanding the system into a full parking lot.

3. 8. 4 Additional Displays

A feature that has been added in a number of similar projects is the addition of additional displays. Additional displays are typically used in parking garage applications of parking systems such as the one that is being developed for this project. There are basically two applications of adding in more displays. One would be to have a display on each floor. This would not be necessary for the Park Sense design because, as was just discussed, the system will not be spanning multiple floors. There will not be need for more than one display. The other use of additional displays is to provide displays throughout the garage that lead the way to the available parking spaces.

Again this is a feature that is unlikely to be used in the Park Sense project. As was stated, there is no need for a display on every floor because there are only a few spots being monitored. There is also not a need for signs leading the way to the open spots. Both of these uses of additional displays would also create a higher cost for the project that and is not really affordable.

3. 8. 5 Summary of Features

In doing research and reviewing similar projects, the aforementioned features were discussed as possible parts that could be added to the Park Sense project. The final conclusions that have been reached from this research are subject to change as the project is further developed and implemented next semester.

Ultimately, it has been decided that many of the features discussed will likely not be included in the final design for this project. There is no real need to include multiple displays in the project so this feature will not be included. It is also unfeasible to include more than one node in the system. Park Sense will just be one just one node monitoring up to four spots.

The one feature that likely will be implemented is the website. The website is not as complicated as some of the other possible features, but does add a significant amount of information and user accessibility to the design. However, along with the website, there will likely not be a Smartphone feature added to the project.

3.9 Microcontroller

The microcontroller will be another component of the sensor node. The microcontroller will process the information received by the camera and relay that

74

information to the transceiver to be sent to the display. Just like the other components of the sensor node, there are a number of things to look for in a microcontroller. Primarily, the microcontroller needs to be inexpensive, and compatible with the other parts that are being used in the sensor node.The primary function of the microcontroller depends on the type of sensor used. For most of the sensors discussed earlier the main roll of the microprocessor would be to analyze the information that is detected by the sensor and relay it to the transceiver. The detection method that will likely be used, however, is video detection. In this case the main roll of the microcontroller will be to analyze the image and relay that information to the transceiver. Therefore, the microcontroller that will be used needs to be capable of executing image processing software to accurately analyze the image captured by the CCTV camera.

Microcontrollers can vary fairly significantly in price. The amount of money that is allotted for the microcontroller will likely depend on what type of sensor is used. The type of sensor used will determine the importance of the microcontroller. Obviously, for a system design requiring a more powerful microcontroller, more money will be allotted for the microcontroller.

3.9.1 Processor Speed

One of the main specifications of any microcontroller is the processor speed. The most important aspect of the processor inside of the microcontroller is the clock speed. Image processing can take a high number of clock cycles to complete. Ideally, for Park Sense, a relatively fast microcontroller would be used. It is hard to put a set limit on the speed of the microprocessor but anything above 10 MHz in speed would likely make a good option for this project.

3.9.2 Peripherals

One of the key peripheral features that is important to choosing a microcontroller is what type of data can be inputted and outputted of the chip. Ideally the microcontroller used would have a universal asynchronous receiver and transmitter or a UART interface for data transfer. This is the type of technology that would allow for the transfer of serial data which would be compatible with most transceivers, specifically ZigBee. Another possible serial interface that would be useful to have is a serial peripheral interface (SPI). This interface is more suitable to data transfer between AVR devices. This would be able to be utilizes for data transfer between the camera and the microcontroller.

There are a number of other peripheral features that can be included in the microcontroller. Almost anything can be included on a microcontroller. Some of these options include comparators, timers, analog to digital converters and even on-board Ethernet. However, the most important thing for the Park Sense project remains the need to be able to process images.

75

3.9.3 Other Microprocessor Information

One very important aspect of the microcontroller is the ease of use. None of the members in the Park Sense group have very much experience in working with microcontrollers. Because of this there are a few aspects of the microcontroller that would be help in configuring and incorporating the microcontroller into the final project design.

The main thing in looking for a microcontroller that would make the project easier is finding a part with very easy to use development tools. For this project, it would be helpful to find a microcontroller that has not only an inexpensive development kit, but also one that is very easy to use.

3.9.4 Part Selection

Basically the research component of choosing a microcontroller is all about looking at a variety of different parts and choosing the one that best fits the design of the project. Based on what has been discussed, the only real requirements that are needed are low cost and compatibility with ZigBee as well as with the sensor chosen, which will likely be a closed circuit camera. The following sections discuss just the main option of microcontroller that will be considered for use in the Park Sense Project.

3.9.4.1 RabbitCore

RabbitCore offers a wide range of microcontrollers. Specifically the ones that should be considered are the line of RCM4510W microcontrollers. This module offers ZigBee mesh networking connectivity, as well as in point to point topologies which would likely be used in the Park Sense design. The RCM4510W has an on board ZigBee modem to make it even more suited for connectivity. The RCM4510W can operate as any of the ZigBee devices, including the coordinator, router, or end device. In the Park Sense system the microcontroller would be used as part of the ZigBee device that is in the end device.

The price of this microcontroller can vary. The RCM4510W(ZB) costs $89. There is an option to purchase the microcontroller with an XBee module and USB adapter included on the package. This option costs much more at $299. This option also includes the development kit. This could be a reasonable option as it would get rid of the cost associated with buying the ZigBee module.

The RCM4510W also has a number of other key features. It has 512K flash memory as well as 512K data SRAM. This is more than enough flash memory for

76

the microprocessor. The processor also runs at 29.49 MHz. This should be fast enough to meet the demands of the Park Sense system. This microcontroller is designed for data acquisition, which is the prime function it will be needed for in the Park Sense project. Another key aspect is that it is a very small package. The board size is 47 mm x 72 mm x 14 mm.

Another nice feature of this Rabbit processor is that it utilizes programs based in C. Most of the members of this team are most comfortable in programming in this language. Rabbit also offers a field utility that allows the user to download pre compiled C files to be used in the microcontroller. The large memory space of the Rabbit microcontroller also makes it possible to store very large programs, containing tens of thousands of lines of code, within the microcontroller.

The Rabbit RCM4510W also meets the requirements of being low power. One way that it does this is by offering a sleep mode. The sleep mode of the Rabbit microcontroller is largely controlled by the ZigBee device. The entire node can only go into sleep mode when the sleep mode is activated in the XBee device. The microcontroller just has to be in the run mode. When the XBee awakes from its sleep mode to contact the coordinator and see if there is information that needs to be transferred, it will also be able to awaken the microcontroller when there is information that needs to be transmitted.

Finally, the RabbitCore RCM4510W microcontroller comes with a few quintessential development tools that make it easily programmable. This also makes it easy to interface with the system. This microcontroller comes with software that can be utilized to develop programs for the microcontroller. The RCM4510W uses the Dynamic C program for developing its code. Dynamic C utilizes a COM port in the microcontroller to communicate with the device. Dynamic C has a very friendly user interface. A screenshot of it is shown below in Figure 3.9.4.1-1.

77

Figure 3.9.4.1-1: Dynamic C

Reprinted with permission of Digi International

This screenshot shows one of the advantages to using a microcontroller that uses Dynamic C. The programming language is very similar to C which is what most of the members of the Park Sense group are most comfortable with using. The user interface of the program is also very similar to DevC++ which is also what most of the group members are familiar with using.

The development kit for the RabbitCore RCM4510W comes with three main parts that enable it to be connected with the Dynamic C software on the PC. These parts are the prototyping board, the connecting cable and the power supply. The prototyping board allows for easy mounting of the microcontroller board. This prototyping board can be connected to the PC through the connecting cable. The power supply easily connects to the prototyping board as well. Below in figure 3.9.4.1-2, the setup for programming the RabbitCore processor is shown.

78

Figure 3.9.4.1-2: RabbitCore Setup

Overall, the RabbitCore RCM4510W offers a lot of features that make it the number one choice for the Park Sense project. This model of RabbitCore microcontroller is the best fit for the design of this project.

79

4 MethodsThe methods section of this documentation is designed to describe what steps were taken by the Park Sense team in developing the system design and producing this report.

4. 1 Research Methods

A large amount of time and effort went into the researching of all the aspects of this project. Before research was started a meeting was held where topics/sections were picked and/or delegated to each group member based on interest and experience with the give topic. We made it a point to not over burden a single individual, for the most part everyone ended up being responsible for about the same amount of material. As for the actual research, most of it was done through the use of internet searches of various published journals, parts manufacturers and vendors, as well as websites that assisted in the general understanding of components of the project. Friends and co-workers were also valuable pools of knowledge when it came to certain topics, such as experience with certain parts and programming know-how.

The majority of our research focused on the options we had as to what kind of sensor/device we were going to use for the detection of a vehicle, as well as the programming required on the server end. As a whole, the group was relatively new to the technology behind these sensing devices but now feel much more confident about their knowledge because of the research done.

4. 2 Design Methods

Designing the project is what the group has been waiting their whole tenure as an engineering student, finally putting to practice the theory and application studied over the past few years. While designing the Park Sense system the group worked as a whole, everyone giving their input on each section, with whoever did the research on a given topic deemed as the lead for that feature. The group also consulted with peers and professionals that have worked on similar features to get a better grasp on what needed to be dealt with. The design proposed at this stage of the project is likely to be revised during out testing, as with most designs, what works on paper does not always work the same in practice.

4. 3 Project Management

80

The key to success in large endeavors such as this is time management. The group did not assign anyone the title of “project leader,” instead we left everyone to be responsible to set their own deadlines with group meetings along the way to check progress and to work on the design. Time conflicts from class and work schedules made meeting on a weekly basis difficult to keep up with. For the first half of the semester the group had little to show as far as written documentation, but everyone was perusing their assigned research topics. Towards the end of the semester more meetings were held to discuss findings and to toss around ideas, to ensure the document would be completed.

In Figure 4. 3-1 we have labeled who is in charge of the main features associated with the system. This does not mean they are the only ones who worked on these, but instead are the ones in charge of what needs to be done and they have the final say in that department.

Figure 4. 3-1 Responsibility Breakdown

4. 4 Implementation

The group decided, as with design, that whoever was charged with the research of a given topic, would become the lead when it came to the design and implementation of that component or section. Everyone will stay up to date with any changes that are made, as well as have a working knowledge of, not only their own sections, but of the whole project. The biggest obstacle we foresee is

81

implementing the software side of the project as most of the group has minimal understanding in that area. Everyone in the groups hopes to have a hand in the building and testing of each component of the system, to take away as much experience as possible from this project.

4. 5 Related Projects

The idea of having an automated system that monitors parking lots and relays the information to a display for the end user is not a new idea. Here are a few case studies that chose to implement parking space detection:

4. 5. 1 Innovative Technologies’ VDMs

(Meshnetics Case study)

Innovative Technologies partnered with a Zigbee provider, setup up a large scale automated parking system in a large urban parking garage. They used vehicle detection modules, or VDMs, which consisted of a Zigbit device which allowed low power wireless mesh networking, and a sensor, of undisclosed type, to detect a vehicle as the name implies, all to run off a 9V battery. For this implementation to be cost effective, a single VDM had to monitor more than 1 space, in this case study they were able to efficiently monitor 4 spaces with 1 VDM. The displays used were one at the entrance to the garage to show how many open spots each level had, and multiple smaller displays throughout the garage that gave the number and direction of the closest available space.

4. 5. 2 Smart Parking Garage

(Senior Design at UIUC, Spring 03)

This project took smart parking garages to the next level. Not only did they keep track of open and occupied spaces, but they assigned a unique ID to a car which corresponded to an open space. Then through use of floor sensors, tracked the vehicle to the parking space, and used LEDs to guide the car. Then once that car departs the ID is put back into the pool to be used for another vehicle. This project was not implemented on a large scale.

4. 5. 3 eSPARC

(Senior Design at San Diego State Univ. , Spring 08)

This group added authentication to the process and setup a system to automatically notify the proper individuals whenever a parking space was

82

occupied legally and illegally. This was implemented for a secure parking lot, authorized vehicles were equipped with RFID tags to automatically let them in, while guests interacted with a LCD display at the entrance which they input an access code. If the guest does not park in the designated spot, personnel associated with eSPARC are alerted.

83

5. DesignThe design section provides a detailed explanation of how each component of the project will be designed and how these components will come together in forming the final product.

5. 3 Transceiver

The XBee ZigBee transceiver is designed to be integrated into the sensor node as well as the server on the display end. The other parts of the sensor node are the video camera and the microcontroller. In the sensor node, the transceiver only really needs to be designed to work with the microcontroller. The microcontroller will serve as the bridge between the data obtained from camera and the data transmitted to the display where a second transceiver will need to be designed to work with the server. The overall design of the transceiver is relatively simple. The main aspects of the design that will be discussed in the following sections, include the mounting of the XBee ZigBee module, the interconnections of the XBee and the microcontroller, the interconnections of the XBee and the server/display unit, and the software design for managing the module, as well as a number of other factors involved in designing this part of the system.

5. 3. 1 Sensor Node Mounting

The XBee module that is being used for this project comes packaged with an RS-232 Development Board. The XBee module will be mounted directly onto this board. The mounting is solderless. The XBee module has been designed to mount directly onto the board through pin sockets. Not having to solder the module to the board offers a number of advantages. There is less room for error because there will be no soldering mistakes. This also allows the module to be reusable for other applications because it is easily removable from the board. Below, figure 5. 3. 1-1 shows how the module is mounted into the two 20 pin sockets on the board.

84

Figure 5. 3. 1-1 Mounting Diagram

Reprinted with permission of Digi International

Figure 5. 3. 1-1 also shows some of the other components that are included on the RS-232 development board. The board also has a serial connection as well as a power adapter. Using this board is primarily for programming the ZigBee module. This is just one option for designing the system. Another option for integrating the ZigBee module with the microcontroller is to use the microcontroller itself. The Rabbit RCM4510W microcontroller is designed for use with the XBee ZigBee module. The XBee module can be mounted directly onto the board of the RCM4510W microcontroller. Figure 5. 3. 1-2 below shows the board with and without the XBee module attached.

Figure 5. 3. 1-2 RCM4510W Microcontroller Board Shown With and Without XBee Module Attached

85

Reprinted with permission of Digi International

86

This would probably be the most straight forward way of integrating the microcontroller and the XBee device. This only covers the physical integration of the XBee transceiver and the microcontroller.

5. 3. 2 XBee-Microcontroller Communication

More important than the mounting is the communication between the XBee module and the Rabbit microcontroller. The parts that were chosen were already known to be compatible. The primary responsibility of designing the software integration of the two parts is mainly to make sure that the data can be transferred between the two devices accurately. Figure 5. 3. 2- 1 shows a diagram a ZigBee device communicating with a microcontroller on one end and another ZigBee device communicating with the server on the other end.

Figure 5. 3. 2- 1 Data Flow Between XBee and Microcontroller

Reprinted with permission of Digi International

This diagram shows the flow of data into the XBee module from the microcontroller and into the microcontroller from the XBee module. That data is then transferred between XBee modules. On the other end the data received will be transferred to the server to be stored and shown on the display. The diagram also shows two other lines between the devices. Both the RTS and the CTS lines are control lines. The CTS line controls overflow of data received by the microcontroller. The RTS line allows the microcontroller to signal the XBee module to not send any more data. This is another way to prevent data overflow between the two devices. These four lines are possibly the most important in getting the data from the microcontroller to the ZigBee to be transmitted back to the server.

There are two possibilities for data transfer. The first possibility would be for the XBee to transmit the telemetry data of either yes, the spot is occupied or no, the spot is vacant. Utilizing this option would mean that the image processing needs

87

to occur in the microcontroller so that the resulting information could be transmitted to the server. The second possibility would be for the image captured by the camera to be transmitted to the server and have the image processing occur at the central computer instead of the microprocessor. This would mean the transceiver has to be designed to transfer an image file. Ideally for Park Sense the transceiver and microcontroller would be designed to where either of these options would be possible.

5. 3. 3 XBee Configuration

The first step in designing the Digi XBee ZigBee transceiver is the initial configuration. The system will consist of just two XBee modules. These two modules, however, will be configured differently from each other. The XBee module at the server will be configured as a coordinator. ZigBee operates as a personal area network (PAN). For the PAN to be established there must be a ZigBee module that is designated as the coordinator. For the Park Sense system, the coordinator will be the transceiver at the server. The coordinator is not designed to be battery powered. This is not a problem for the system. The unit with the server, display, and transceiver will not be battery powered. The need to be able to accept other devices into the PAN is the main responsibility of the coordinator. The XBee device at the server end of the system will be responsible for creating the PAN, which includes selecting the channel that will be used for transmission. This device will also be responsible for allowing the XBee transceiver at the sensor node to be added into the PAN so that the system can be established. The coordinator is capable of sending and receiving data. The coordinator is also capable of routing data through a mesh. This will not be needed in the Park Sense design but is still important to consider. It is also worth noting that each coordinator can only be associated with 8 routers or end devices.

The XBee transceiver at the sensor node will be configured as an end device. This transceiver actually has two options of how it will be configured. The transceiver in the sensor node could be configured either as a router or as an end device. If the device were to be configured as a router, it would be very similar to a coordinator. It would be capable of routing data through the mesh as well of transmitting and receiving data between nodes. The reason it cannot be configured as a router is that a device configured as a router must always be active and cannot enter into a sleep mode. Therefore, a device configured as a router also cannot run on battery power. The XBee device in the sensor node will, therefore, be configured as an end device. The end device must be joined into the PAN by the coordinator. That is why this is one of the main responsibilities of the coordinator device at the server. The end device has limited functionality. The end device is not capable of allowing devices to join the PAN or routing data throughout a network. End devices are basically limited to transmitting and receiving data. These restrictions allow the XBee transceiver in the sensor node to be able to go into a sleep mode. This way it can operate on

88

battery power and be all around low power. The coordinator will be responsible for waking up the end device when transmitting data to it as well as buffering the data so that the data is not transmitted prematurely. During the configuration process, security will be enabled on every device with the same encryption key so that the devices can operate on the same PAN.

5. 3. 4 Communication between Transceivers

There are two ways that data can be transmitted between the two ZigBee devices. The data can be shared through a broadcast transmission or a unicast transmission. Normally, in a ZigBee network a broadcast transmission would send the data to every node while a unicast transmission would send the data to a single specified node. Because there are only two ZigBee device in this system, there is really no difference between a broadcast and a unicast transmission. From a programming point of view it is generally easier to and faster to do a broadcast transmission. This is the method that will be used for Park Sense.

Because the end device will primarily be in sleep mode, it will rely on the coordinating transceiver to awaken it when transmission needs to occur. The way this will be designed is that when data needs to be collected from the sensor, the coordinator transceiver will send a signal to the end device to awaken it and poll it for data. The end device will then send the data that has been collected from the receiver. The whole system is based on polling to maintain sleep mode. The end device will also operate on a cyclical sleep pattern. Figure 5. 3. 4-1 shows how the cyclical sleep design works.

Figure 5. 3. 4-1 Sleep Time Cycle

Reprinted with permission of Digi International

89

The time ST is a preset amount of time that the device awakens to see if there is data to be transmitted or received. When this time expires the device goes back to sleep. This is how the XBee transceiver in the sensor node will operate.

5. 3. 5 Transceiver Design Summary

To complete and clarify the transceiver section of the design, a block diagram of each transceiver is shown below. The first block diagram shows the communication of the transceiver at the sensor node. The second block diagram shows the layout of the transceiver that is located at the server.

Figure 5. 3. 5-1 Block Diagram of Transceiver at Sensor Node

The block diagram above is not very complex, but it shows the most important information. The XBee transceiver that is located at the sensor node is really only comprised of a connection with the microcontroller in which the image data that is collected by the camera is sent to the XBee module through the microcontroller.

The XBee module then sends the data that has been obtained and processed in the microcontroller to the other XBee transceiver. These are the only two connections of this transceiver. It is also important to remember that the XBee module will be mounted directly onto the Rabbit RCM4510W microcontroller board after being programmed on a different board. More information about the design and the connection with the XBee module, as well as the communication between the two devices will be discussed in the microcontroller design section.

90

Figure 5. 3. 5-1 Block Diagram of Transceiver at Sensor Node

The block diagram above shows the transceiver on the server end of the system. The XBee receiver on the server end of the system receives the image data transmitted from the XBee transceiver located in the sensor node. The data received at this module is transferred to the server. The XBee module at the server will be mounted on the RS-232 development board. This is the same board that the device is programmed on and has a serial connection to the computer that will be used as a server. More information about the design of the server, as well as specifically what will be used as the server will be discussed in the server design section. This section will also go into further detail about the connection and communication between the XBee module and the computer display.

Both XBee modules only have one key hard wired connection: one to the microcontroller and one to the server. The other key connection is that between the two transceivers themselves. The bulk of the work in designing the transceiver devices lies in software and programming the devices. Each device will require specific programming to assign one as the end device and one as the coordinator. Other aspects of programming the two devices include specifying certain actions for the coordinator and the end device. The coordinator device needs to be programmed to start a PAN and enable security encryption. The coordinator also needs to be able to allow end devices access into the PAN it has established and then be responsible for awakening the end device from its sleep mode. The end device transceiver needs to be programmed to transmit and receive data as well as enable a sleep cycle to conserve power within the sensor node.

91

5. 4 Display

In our research methods we had laid out our ideas on the different kinds of displays. Designing the Display means first choosing the right display to work with. After weighing pros and cons of each display we come to a conclusion that selecting the LCD Display would be our best choice because of its maintainability, portability, Viewing angle and easier to look at. After we have decided on the display the next thing is to design the display in particular. Now that we have our proper choice of display in place, the next challenge we are going to tend to face is overcoming the sun rays which always tend to hamper the view ability of the user. A summary of these conditions is shown in Table 5.4-1.

Table 5. 4- 1: Light Conditions

Lighting

condition

Ambient

Brightness

Display Brightness

Application

Dark environment

0 nits 50 nits Marine bridge system

Indoor without lighting

< 500 nits Adjustable Conference room

Indoor lighting < 1000 nits 300 nits Desktop monitor

Indoor applications, overcast skies

1000 – 3000 nits 300-500 nits Industrial displays

Outdoor application, Indirect sunlight

3000-7000 nits 500-800 nits Outdoor LCD’s

Clear skies 7000-10,000 nits 800-1000 nits Outdoor kiosks like ATM

After looking at the above table we are faced with a task of picking out the right LCD display for our project.

92

To overcome our issue with bright sunlight we can use Transflective LCD technology to any LCD display so that it will enhance the reflective functionality to the screen and help in making it brighter and easier to look at. After we can add the Transflective characteristic to our LCD screen the newly modified LCD screen will be able to reflect the ambient light and then catch the light beams and make it its source of illumination. Figure 5.4-2 shows the reflection characteristics of a backlit LCD module.

Figure 5. 4-2: Backlit LCD

Recreated figure of an LCD monitor

The above figure shows the representation of a regular LCD. In a regular LCD the brightness is not sufficient at all to overcome the ambient light. In a regular LCS sunrays fall on the LCD module and get sucked in and therefore make the picture shady to see. This truly hampers the viewing angle and the perception of the user. Without a solution to this problem our project would be far from being a complete project. Figure 5.4-3 shows a poorly designed outdoor LCD.

SUN LCD Module

Backlight

93

Figure 5. 4- 3: Transflective LCD module

Recreated figure of a modified LCD monitor with transflective enhancement

In the above figure a transflective enhancer is placed between the LCD module and the backlight. This transflective enhancer has both transmissive and reflective properties. How an image is displayed on the screen totally depends on the ambient light of the environment. This new transflective enhancement pays way to better view ability, better color enhancement, more brightness and clear visibility. The net reflection rate of a transflective LCD is just about 0. 9% – 1. 3 %. One big adjustment we would have to make is to keep the contrast ratio at a proper range in accordance with the display brightness.

If we have more time we would even like to add the following feature (in Figure 5.4-4) in our display.

SUN LCD Module

Backlight

Transflective enhancement

94

Figure 5. 4-4: Light Sensor Brightness control

Recreated Model

The above block diagram represents a sensor activated control system. The light sensor detects the difference in the amount of light perceived and then it sends a signal to the MCU. Then the MCU will command the inverter to change the brightness if the amount of light was other than the default. At last the MCU will send a signal to the inverter and the inverter will get to work and change the brightness of the LCD monitor.

The light sensor will measure the outside brightness with varying conditions depending on the ambient light and then it will relay this information back to the display and depending on that the display will change the brightness of the LCD screen. So when there is more ambient light the brightness will increase and whereas there is little or less ambient light the brightness will decrease. This would be an added advantage to our project as such that it would give a variety to try new things in our developmental design.

System

Light sensor

Brightness ControlMCU

95

5. 5 Software

There is a major portion of the project that is devoted to the software behind the scenes that is running the project.

5. 5. 1 GUI

Figure 5.5.1-1 shows an example of a proposed GUI.

Figure 5. 5. 1-1: Sample GUI

Demo Model of the GUI

This is how the demo model of the GUI would look like. As we had discussed in the Research section about various different utilities we could use to build the GUI. After looking at the good points and the bad points we finally chose to go with JAVA and use the NetBeans IDE 5. 5. We chose this over the other programming languages because of its amazing GUI builder with lots of added functionality. Another important reason for us choosing this over other programming languages was that JAVA is platform independent. So we just have to install the JAVA runtime environment in the computer in which we want to run the JAVA program and then it would seamlessly run in that environment.

96

Therefore we chose JAVA as our main programming language choice for our GUI.

Building the GUI will entail creating a desktop application with a main class. Then the basic structure of the GUI will be handled using the GUI builder editor window. The GUI will be programmed using the JAVA Swing components as well as JAVE AWT components. Then after that it’s just a matter of dragging and dropping components in the GUI editor window. After the basic layout has been done then the major portion of the programming comes in the form of adding functionality to each and every component. We have to switch from the editor view to the code view where we code the functionality of every little component from the buttons to the text fields.

Our GUI will have seven major parts in it. They are layout commands, editing component properties, right click component, properties pane, listeners and handlers and the alternative properties pane. Let us go through the main ones step by step:

Layout components: This will be the part where we will use the GUI editor to make a basic layout of our user interface. This is not that big of a daunting task such that it’s just a matter of selecting the component and then dropping it in the editor window.

Edit component properties: After we have finished with the basic layout of the user interface then we would want to assign values and properties to each of the different components.

Listeners and handlers: After the properties and values of each component has been taken care of we would specify how each component would respond to an event like an action performed on a button or mouse listeners (what happens when u roll over or click on the component) etc. Then it’s just a matter of adding al the actions to each of the components to the performed on.

There 3 were the major parts we would focus on designing our GUI. The GUI is still in the initial stages of development by our group but we hope to get a handle on it as soon as possible. We all are trying to work with different programming situations to aid us with this design. All of this GUI building would be a big task in itself for all of us as one of us have good programming experience but with this NetBeans IDE 5. 5 we all think we could learn how to use it and design a great looking satisfactory user interface for our project. Designing the GUI would also help every one of us get used to some programming experience as it would always help us in our future endeavors.

5. 5. 2 Website

97

Another functionality that we plan to add in our project is to have a website with live update about the availability of the parking spots in the lots. So that people can look it up on their PDA’s, laptops or smartphones. This also reduces the need to have a standalone smartphone or an IPhone app as this interface can be accessed from any given internet capable device with a web browser functionality inside it.

Due to the other parts of our project that is going to take a major chunk of our time we decided to make the website in a way that is simple but still not removing any functionality from it and on top of it to give a nice basic simple look. Figure 5.5.2-1 shows an example screenshot of the website.

Figure 5. 5. 2-1: Proposed Website Layout

Demo model of the website

Above we have a basic demo model of how the website would more or less look like. Not a lot of emphasis will be put on the cosmetic side of the website but it will be a fully functional simple website with all the options needed by the user to find an open parking spot.

Park SensePark Sense

Park Sense

Park Sense

Home

Lots

Contact

About

Lot 1A

98

To design the website we would basically use ‘Joomla’. Joomla is a Content management system (CMS) that will keep track of every piece of content on our website. It will talk care of the database through MySQL which we will have to use in designing the website. Joomla basically runs in the backend with a login and username for designers to take fully control of the website they are designing. In other words ‘Joomla’ is like one stop place for all our web designing needs. The basic scripting of the webpage will be done in html which most of us are acquainted with and then come in part in typing our user interface with the website to receive live updates. We as a group did not want to completely redesign the parking lot user interface for the website. So we thought that we could just use the same user interface that greets people at the entrance of the parking lot. We had selected JAVA as our GUI programming language for our display screen user interface. So it would be an obvious choice to just convert that JAVA program application code into a JAVA applet and attach it to our website. Therefore our applet would work on any computer with a web browser running a JAVA runtime environment.

To convert a JAVA application to n applet needs a reference to an html page so that it can load all the classes it needs from the codebase. Also applets load very fast on a web browser so that the user won’t waste its time waiting or the applet to open up. The biggest advantage that an applet has over anything else is portability and ease of distribution. It can be run on a variety of devices ranging from desktops, laptops, PDA’s and even smartphones. There are various other alternative technologies like Flash, Microsoft Silverlight and JavaScript. But porting out JAVA user interface from a JAVA application to like Flash would be an ordeal in itself. And moreover there is no need for Flash or anything else as making a JAVA applet would be the best and the simplest solution to the problem.

We will be doing the basic HTML designing of the website using ‘Dreamweaver’ which is a web designing applications that is widely used to develop great looking websites. If we are have more time we would also like to add a functionality to show live images of the parking spots to our website. After the website is created we would have to host it on a server and the web hosting server will have to be in constant contact with our display server to give it live information about the empty parking spots.

5. 5. 3 Image processing

The last in the Software Design that’s left to be talked about is the part about image processing. Image processing as we all know is a fairly complicated process and takes time and expertise to get successful results. As we are using JAVA as our main programming language for our GUI and also the applet it

99

would we better if we tried to do the image processing in JAVA too so that everything is basically in one programming language.

JAVA has JAVA Advanced Imaging API that can be used for high-performance image processing to be included into JAVA applications and JAVA applets. It is basically a collection of classes that can be used to do some core image processing functions etc. This is a very good way to try to incorporate image processing into a JAVA application or applet.

The JAVA Advanced Imaging API will be run without any native code so due to this the JAVA Advanced Imaging API will only use JAVA code. As most of us group members are not familiar with image processing this image processing part of our project is going to prove to be a learning curve for all four of us. But we as a group are ready to take upon this challenge to try something different from the common norms and be successful in it.

OpenCv is used by many developers today for image processing but we would not want to have our updates in real time and OpenCv is best suited for that. So we would not have to use OpenCv for our image processing functionalities. But on the contrary we will just probably end up using some standard C++ libraries to achieve our needed results. Table 5.5.3-1 shows a comparison of the JAVA platform and OpenCV

Table 5. 5. 3-1: JAVA vs. OpenCV

JAVA Advanced Imaging API OpenCv

JAVA programming C , C++ programming

Still Developing with daily builds Complete libraries

Better for the future Good for the present

Not that active in updating libraries More active in updating libraries

Above is a table that shows a basic comparison between JAVA Advanced Imaging API and OpenCv.

100

5. 6 Server

We are going to use a desktop computer as a server for our project. In context with designing we don’t have to do anything in particular. Everything from all the image processing stuff to our JAVA application will be housed in this server. So if we go to see this server is like the mainframe heart of our project. So the proper functionality of the server is of utmost importance. If the server goes down then our whole project is down, that’s how important the server is.

5.7 Design Summary

The following section is a brief summary of the overall design of the Park Sense system. This overall design is shown in Figure 5.7-1.

Figure 5.7-1: Park Sense design

5.7.1 Server

To save money, we have decided to use one of our personal desktops as the server. The specifications are:

101

CPU – intel Core2 Duoo 2.8GHzo 1033MHz front side buso 3MB L2 cache

RAM - 4GB DDR3 1333MHz clock speed Hard drive – 750GB Sata-2 ASUS Maximus Extreme Motherboard Graphics Card - Nvidia 9800GT (1GB) PCI-e Windows Vista 64-bit Ultimate

This computer should be able to handle the load of at least 2 cameras as inputs, which is how we intend to prove the concept of the Park Sense system.

5.7.2 Software

The Park Sense software is going to consist of 4 main components. The first part of the package that will be needed is a monitor and fetch program. The camera will be saving images to a given directory this program will monitor that folder for new files and load them into memory, copy it to a new directory where all old photos are kept, and delete it from the original folder. The program will have to be able to tell what camera the image came from and sort it accordingly. The next part is the image processing, this is where the Park Sense system is realized. The images loaded into memory will be compared to the control images based on the time of day. Each camera will have its own control images as well as configuration parameters that will control where the program will compare pixel tones to the control image’s pixel tones. Once the processing is done we will need to pass the output to a database that controls the GUI. We will not know how the output of the image processing will be formatted until we actually write the program, so for the time being we’re treating this part of the software as a black box. Finally, GUI will need to be updated based off the current values in the database and actually be displayed on the LCD. The first 3 parts will be coded in C++, and we may be able to bypass the need for a database intermediary based on how we write the program.

5.7.3 Camera

The Lorex LW1012 came in a very convenient set with a receiver for $123. The cameras are Wi-Fi ready and equipped for outdoor use. The image resolution is suitable for our means. The cameras also come in a small and compact package. This means they will not be intrusive in the environment where the system will be implemented.

102

6. PrototypeThe goal of the prototype section is to go into even further detail than the design section. The section will also discuss some of the aspects that are going to go into making the prototype of each component of the system and how they connect. This section elaborates on the ideas that were discussed in the design section and goes into further detail about how the parts will be connected and the prototypes of the sensor node and the server unit. The section will also discuss aspects such as the total cost that is expected to be associated with each component and how that cost relates to the original budget.

6. 2 Transceiver

As previously discussed, there are two applications of the transceiver. The following sections will discuss the XBee component of the prototype for the sensor node and the XBee component of the server unit.

6. 2. 1 Total Cost of Transceiver

As discussed, there are two locations where the XBee transceivers are needed. In prototyping the transceiver locations, the first thing to do is confirm that the expense of these transceiver devices meet what was specified in the initial budget. The initial budget allowed for some room for unexpected costs as well as variation in the prices of the parts involved. The main cost involved is that of the XBee development kit package. This package costs $129 but includes 2 XBee modules, as well as a number of essential parts. Considering that the XBee transceivers sell individually for $19 apiece, we will consider the cost of the other parts as well as the development kit to be $91, which is the cost minus that of the two XBee modules. The items included in this general price that can be contributed to both transceiver locations are the serial cables, connectors, power adapter, and two development boards (one USB and one RS-232). The price of the individual XBee transceiver per node will just be $19. If the system were to add more nodes, the price per each additional node for more XBee transceivers would simply be $19.

The budget and the specifications suggested that the price for the transceiver component of each sensor module should be no more than $25. The physical price of the XBee transceiver in the one node that is used is just $19. The original budget was also assuming more than one node. The prototype that was designed and settled upon uses just one node. This allows even more room for extra costs considering the money that is saved with just one node. The budget

103

also allowed for a generous $300 for the development kit to create the prototype. Because of the package that is offered by Digi for the XBee devices, the actual cost for the prototype of any XBee device due to the development kit is under $90. The last aspect of the budget for the transceiver was a vague $50 dollars allotted to other miscellaneous development tools such as cables and development boards. Pretty much all of these tools are also included in the package from Digi. Therefore, in the prototyping of these parts, there is basically no cost for extra development tools needed for the transceiver. It should be noted that the cost of this prototype does not include the minimal costs of wiring and soldering that may be associated with creating these prototypes.

6. 2. 2 Transceiver Prototype in the Sensor Node

The main goal of this section is to show the connections of the transceiver and its neighboring devices within the sensor node. There are very few pins in the chip. Some of the important pins are described.

In the sensor node, pin 1 will be connected to the power supply, which in this case will likely be either a large battery power supply powering the entire node, or its own smaller battery that will be used to power just the XBee transceiver. There are not very many other important connections. Pin 2 will also be connected to the microcontroller. Pin 2 is the data out pin. In the sensor node there is not much need for data to be transferred from the transceiver to the microcontroller; however, this pin cannot be ignored because there still may be need for data to be sent in that direction. Pin 3 is the data in pin. This pin is very critical to ensure the data is transferred from microcontroller to the transceiver. Pin 9 will also be used. This is the sleep control line that will be used to control the power conserving function of the end device transceiver and enable its sleep mode. Pin 10 will also be utilized as it is the ground pin. Pin 12 and 16 will also be used. These two pins are clear to send and request to send flows. These pins will be needed for communication between the two transceivers. Most of the other pins are analog or digital I/O pins which are not as important to functionality of the prototype as the other pin connections.

These pin connections will likely not need to be soldered or hard wired in any way to the microcontroller module. As was discussed in the design section, the board of the Rabbit RCM4510W microcontroller module can come in a package that includes a 20 pin socket that is designed for the ZigBee transceiver made by XBee. This is show in the figure that was described in the transceiver design section.

6. 2. 3 Transceiver Prototype at the Server

The transceiver used at the server will be exactly the same as the transceiver used in the sensor node. As it was discussed, the only real difference in this

104

transceiver prototype is the way that it is programmed. The same pin connections will be used with this transceiver. The power supply pin (pin 1) on this XBee will not be connected to battery power because this transceiver cannot utilize the sleep mode and therefore must have a stronger power supply. The prototype will likely be connected to whatever power supply is used for the server.

On this transceiver the connection on pin 2 is more important than in the sensor node. This is because this node is more reliant on receiving data and exporting it to the server through the data out pin, than transmitting it. In the same way, this node is less dependent on pin 3 because there is less data being sent into the XBee for transmission. This XBee device will also be less reliant on pin 9 because the device at the server will not be utilizing the sleep mode.

Unlike the XBee in the sensor node, this transceiver will have to be hard wired or soldered into a larger module. Depending on how the server is ultimately designed, it could be possible to just use the pin socket connection offered on the development board and connect the development board to the server through the USB connection. Even if this does not work it would still be useful in prototyping the XBee transceiver on the server end of the system.

Creating the overall module prototype of the transceiver at the server could require a number of additional parts. This is where it is fortunate that there is extra money left over from what was allotted in the initial budget. Some of the additional parts that could be needed for this module prototype would be either a breadboard or possibly a printed circuit board. This would also require wiring and the expense of additional wiring. All in all the costs of creating a prototype for this module should not exceed the $50 that had been designated for additional development tool costs.

6. 2. 4 Prototype Layout

To present a better understanding of how exactly the prototype of the sensor node will work, the following diagram is provided to show the overall layout of the sensor node component. The diagram below shows the complete sensor node. In this way, this layout is not just limited to the prototype of the transceiver. There are other sections of the documentation that are more focused on specifically prototyping the sensor. The figure below shows the sensor node prototype.

105

Figure 6. 2. 4-1 Sensor Node Prototype Diagram

There are four main components to the sensor node prototype shown in the figure above. The main component of the sensor node prototype is the camera. The block representing the camera in the figure is fairly bland because the camera that will be used has not yet been officially decided upon. Regardless of which of the cameras is selected, they would all likely be configured the same way. All of the choices for cameras will utilize some sort of board likely a UART which will be used to interface with the microcontroller. It should also be noted that the diagram is not drawn to scale. The camera is much larger than the other components on the board and in the node.

The part labeled as the camera interfacing board will be wired to the microcontroller. These actual wiring connections are not shown in the diagram but will be used to transfer the picture from the camera to the microcontroller. The actual microcontroller is the part on the RCM4510W board that has the rabbit on it. The picture will be processed in the microcontroller using the image processing software programmed into it as was previously discussed.

After the image processing is done inside of the microcontroller, the data of which spot is open is transferred to the XBee device which is shown attached to the RCM4510W board. The XBee is connected to the board through a pin socket connection as was discussed. Once the processed image data is transferred to from the microcontroller to the XBee transceiver, the information is

106

sent to the server where it is stored. The updated information is then uploaded onto the display which is located at the front of the parking lot.

6. 3 Display

As mentioned in our Design we are going to use transflective display. But the costs of these displays are very high so therefore are best option would be to try to make our own version of a transflective display for our project. We tried to design our own transflective display and after designing it we think theoretically it should work but we cannot be completely sure if it would work after prototyping it. Below is a diagram of our idea of how to go about prototyping this transflective display.

Figure 6. 3-1: Transflective Display Prototype

Prototype model when there is no sunlight

In the above figure we can see three major components – the LCD front, one sided mirror and the backlight. We put a one sided mirror between the LCD screen and the backlight so when there is no sunlight it would be dark and so the backlight would light up the LCD screen without any intervention from the mirror as its is one sided and the non-reflective side is facing the backlight.

Backlight

One sided mirror

LCD

No Sunlight

107

Figure 6. 3-2 Reflective Display prototype

Prototype model when there is sunlight

So from the above figure when there is sunlight and the sun rays hit the LCD screen , they reach the reflective side of the one sided mirror and reflect the sunlight back and in return illuminating the LCD by the light from the reflected sun rays.

This is prototype model of our LCD screen, theoretically we think this would work but practically we cannot ascertain anything unless we actually build this thing.

Backlight

One sided mirror

LCD

Sunlight

108

7. TestingTesting is a critical part of any design project. This is especially true for the Park Sense project. Basically, every component of the system needs to be tested both individually and connected with other parts of the system. The following sections will discuss how each component part will be tested individually and eventually how the system will be tested as a whole.

7. 1 System Integration

To give a better understanding on how the Park Sense system will operate we included this section outlining the layout and the interconnects involved. We will guide you through the system starting from the very beginning, an image being taken, to the end product, the GUI on the display.

7. 1. 1 The Setup

To begin with, a camera will be mounted in a position with a good vantage point of as many parking spots as possible. This step is vital; the angle of which the camera views the parking lot greatly determines how accurate our image processing will be. If the lateral angle is too extreme on given spots the area that unique to that parking space becomes smaller due to overlapping of vehicles. As for the vertical, ideally you’d like the camera to be pointing straight down on the lot, so the closer the vector which the lens draws with the ground is to 90 degrees the better.

The camera will be networked wirelessly to some form of wireless access point that will be hardwired to the server. The server is the center of all the data, the images from each camera will be saved in their own directory, or with unique file name structures, so the program knows what control image to compare it to. Once processed, the images with be moved to another folder so the program does not accidentally analyze old images and update the system with this data. The output of the image processing will be transferred to one of 2 options to be determined once some test has been performed. First option, a data base that will be created with ID codes for each parking space, and therefore the program will have to be made to correspond and output accordingly, then this data will be used to update the display. Second option, integrate the database, display, and image processing software so that everything is processed in the same place and doesn’t need to exchange hands.

Following an Image to the Output

109

1. Camera takes a snapshot2. Image wirelessly sent to nearest access point3. Server acquires Image and stores in correct directory4. Image fetch program detects a new image in the directory and stores it to

memory5. The image processing software determines what control image to use6. Compare the 2 images7. Output data sent to the database and GUI control software8. GUI software updates the display

a. Note: the display may not be directly connected to the server in real implementations.

Figure 7. 1. 1-1 Integration Block Diagram

During our testing phase we may choose to revise the details of our current system design, but the overall system shown in the block diagram in Figure 7. 1. 1-1 should remain true.

110

7. 3 TransceiverThere is a lot of testing that needs to be done to make sure that the transceiver devices will operate properly in the final design. Fortunately, the Digi XBee ZigBee transceiver package comes with a number of tools that make testing easier and successful testing more likely to occur.

7. 3. 1 Transceiver Software Testing

The first step in designing the XBee transceivers for use in the Park Sense system is to program the devices with the appropriate setup and programs for them to interact properly for the project. Each of the two XBee devices will have to be setup differently. The development kit package comes with the development board needed to program the devices. The initial setup is programming what device type the XBee transceiver will be programmed to be. One will be the coordinator and one will be the end device. The data sheet and operating manual for the Digi XBee device includes test programs that can be programmed into the devices. Each device will be loaded with these test programs to ensure that they are operating properly.

7. 3. 2 Sensor Node Transceiver Testing

Testing the connections between the transceiver and the microcontroller at the sensor node is probably the most important aspect of the transceiver testing. This testing will likely occur as early in the building process as possible.

One of the tests of the XBee device in the sensor node will be making sure that the sleep function is operating properly. The sleep function is a critical aspect of the energy efficiency requirement of the project. Once the connection has been established between the microcontroller and the XBee device, there will have to be a test to make sure that first the XBee device is sleeping as it should be, and then that the microcontroller can effectively awaken the XBee device for data transmission.

There will also have to be testing done to make sure that the information processed in the microcontroller can properly be transmitted to the XBee device. This should require minimal testing because the Rabbit microcontroller chosen is designed for interfacing with ZigBee transmissions.

7. 3. 3 Server / Access Point Transceiver Testing

On the other end of the system, there will have to be testing done to make sure that the XBee device can communicate with the server when it receives information. This should be relatively simple. If the data transmitted is an image,

111

there will just have to be testing done to make sure the image can be loaded from the XBee transceiver onto the server accurately.

This XBee device will also have to be tested to make sure that it can transmit data from the server. Should data need to be transmitted to the node, it is important that the information can properly be transmitted from the server to the ZigBee transmitter.

7. 3. 4 XBee to XBee Testing

The transmission of data from the sensor node to the server is completely dependent on the communication between the two ZigBee devices. There are a number of things that need to be tested to ensure that the data will be able to be transmitted from the node to the server.

The first thing that needs to be done is to make sure that, after programming, the two devices do indeed act as an end device at the node and a coordinator at the server. For this testing, there are really just a number of things that need to be checked. First, it needs to be confirmed that the coordinator XBee can successfully select an unused transmission channel and a PAN ID. If it can properly do this, the next thing to check is to make sure that the coordinator successfully allows the end device transceiver to join the network. Hopefully, this testing should not be very time consuming. Assuming the devices are successfully programmed and their roles are accurately assigned, the testing of the devices should be successful as well. Along with this, the coordinator should also have the ability to awaken the end device XBee. This is another aspect that will need to be tested in the system.

There are a couple of other things that will go into the testing of the communication between nodes. Once the system is operational, there will need to be testing done to make sure that the spacing of the two transceivers does not exceed the allowable range of the transceivers. There will also have to be other location tests to see if there is interference or better line of site options if there are obstructions.

A key to ensuring that testing is done successfully with the transceivers is to make sure that the parts are obtained as soon as possible. The sooner that the testing is able to start, the better the chances of success in the system.

112

9. ConclusionThe following section is a brief conclusion discussing some of the things that were learned during the project.

9. 1 Reflections

To accomplish the goals that have been set for this project there were many paths open to the group. This section will outline features we chose not to include or replaced with something better and various approaches we decided against. At the end of this section we will discuss future improvements that can be applied to a project such as this.

9. 1. 1 Features Left Out

Whether due to over complicating the problem, over stretching our capabilities, time constraints, or budget, various possible features for this project were chosen to not be implemented. We feel strongly that the project we are choosing to put together will be a success, and electing to not include some features will not negatively impact the end project. When we first thought of this idea at a group meeting, we were trying to come up with ideas that would make the project worthy of our senior design project.

9. 1. 1. 1 Low Power Sensors

Through our research, we found that this approach to be almost cliché at this point, and overall it gets the job done but somewhat ineffectively. Out of the large number of similar projects we looked through they were able to monitor up to a max of 4 spaces with 1 sensor, but still chose to use that sensor to monitor only 2 spaces because there were less glitches. After a passing comment made in the meeting with Dr. Richie about what the most efficient way to accomplish our goals was to use cameras. Already second guessing our original idea we chose to look into using image processing. People have approached the problem this way through a variety of image processing methods however, the oldest example we found was done in 2007, whereas people have been using low power sensors for almost 10 years for this application. This method of parking space detection has the capability to monitor large amounts of spaces if the cameras are placed correctly. This system could also piggy back on an existing security camera system already in place, if the cameras were compatible, otherwise, on a fresh install the system itself doubles as a security system.

113

9. 1. 1. 2 ZigBee Mesh-Network

One of the main things we wanted to use was a Zigbee mesh-network. Our original project proposal included a fairly large meshed network of low power sensors; infrared, ultrasonic, or induction. With using cameras however, we no longer would have 100’s of sensors in a parking lot, but instead a fraction of the amount, knocking out the need to use a mesh network to cut down on cost of wires and other networking hardware. Of course we could still implement such a system, but it over complicates something that can be solved relatively easy. Mesh networks require a large amount of manual setup on the software end, whereas a standard wireless network would just require precise placement of access points, and either a camera with a built in wireless network interface card, or design a transceiver to adapt to the design.

9. 1. 1. 3 Battery Power

For an ideal case, each of the sensors was going to be standalone; no wires and no maintenance. However, in a practical application such as this, even if we did choose to design using low power position detecting sensors, the best theoretical battery life of similar units was 4 years on a 9V battery. We all know theoretical values don’t usually hold true in practical uses, we estimate that a battery sweep would be needed after two to two and a half years, not including random batteries dying before then, which would be a very time consuming and expensive job. The cost of replacing the batteries, labor plus parts, would overshadow the cost of tapping into the power grid used for the lights in the parking area, which is a one-time cost with a much less chance of needing maintenance.

9. 1. 1. 4 Smart-Phone Application

With the rising number of people buying smart phones, we thought a good idea was to program an application that would allow drivers to check the current occupancy of parking lots equipped with our system. While there is plenty of material on the market aimed towards helping people learn how to program such applications, the group was already facing the hurdle of programming the image processing software with limited programming experience. Not being the only reason we dropped this idea, two other factors played a roll; the extra time that would be needed in order to learn and write the program followed by testing, along with none of the group members owned a phone capable of installing applications. Instead we opted to sticking to just making a website with the same features our display in from of the lots and garages. That way the idea of being able to remote check is still an option, not only for smart phone users, but everyone with an internet connection.

114

9. 1. 2 Future Improvements

As we’ve stated, this project is already something we can be proud of, but we are not arrogant enough to say it is perfect. Innovation is a part of human nature, it’s what we are doing with this project and it is something someone could possibly improve upon in the future. 9. 1. 2. 1 Computer Vision

Currently, the way we plan to detect a car in a parking space, could just as easily detect someone getting out of an adjoining spot that just happens to be standing in the region we are analyzing. With a system programmed to utilize computer vision, it would be able to classify the object in the region of interest. It would only flag a spot as occupied if the object in the spot was classified as “vehicle” and could reduce false positives that our system may generate. This would also help night time detection, our system will require different control images to account for times of the day where the light differs greatly, this system would be relatively unaffected by light. One main obstacle this kind of system would have is detecting a vehicle that is a very similar color tone to the pavement, if it doesn’t detect that a vehicle is there at all, no classification can happen.

9. 1. 2. 2 Video

Of course, using images taken on a given interval is great and can approach real time updating, but never actually achieve it. However, we’re already installing cameras, all of which have the capability of live feeds, so why not use this live feed and have a truly real-time system. Computer vision and machine learning would play a large roll in this kind of system. Training a system that knows where the parking spaces are, and “learns” what various types of vehicles look like in a variety of colors. This is quite feasible using the knowledge out there today, maybe not as efficiently as processing a still image, but still very possible.

One major facet that has to be taken into consideration here is the amount of processing power needed to process real-time video. A power computer is already needed to process all images coming in from the cameras, but if we were to use the same computer for the analysis of a live stream, I estimate it could handle up to 4 – 6 feeds, depending on the graphics card being used, to keep the system from lagging. So, no longer do you have a single server at the center of your network, but instead, a network of servers running behind the network of cameras, drastically increasing the cost the data from these computers would still have to be centralized to update a database that controls the displays. 9. 1. 2. 3 Nearest Open Spot

This feature would be very effective, especially if multiple displays are used. Being able to calculate where the nearest open spot to the display and giving

115

directions would be a fun feature to add. This would just be icing on the cake, if the display itself already shows all the open spaces, something like this is not necessary.

9. 1. 2. 4 Parking Space Reservation

This is a tricky topic, everyone has different destinations in mind when they drive into a parking lot. So, the system can’t just assign you spot automatically, almost no one would park in the designated spot, and although the vehicle would get detected in another spot, there’s still the fact that a spot is marked as “reserved. ” Then again, you can let the drivers reserve a spot from the display at the entrance, this way the driver knows where other cars are headed but not yet reached for the system to flag a spot as occupied, but instead it’s marked as reserved. It would be very hard to enforce these reservations, and if someone happened to be leaving as you are headed to your reserved spot and this one is better, there’s nothing stopping you from voiding your reservation. To compensate for this, the system can only mark a spot as reserved for 1 to 2 minutes and after that returns the spot to just being classified as “vacant. ”

9. 1. 2. 5 Adding an Application Programming Interface to the Website

Everyone has seen an application programming interface (API) in action but may not know what it is. This is what allows people to have access to certain information from the website, without having to write a program that scans the actual page. So by letting other people have access to key information such as, number of open spaces, number of cars in the lot not currently parked, and if the lot is full, average wait time for a free spot, other people would be able to write apps or embed this information on their websites, blogs, or social networking profiles.

116

I. AppendicesI.I Bibliography

1. RabbitCore RCM4500W User’s Manual. Digi International. 2007. Rabbit.com

2. Product Manual XBee™ ZNet 2.5/XBee-PRO™ ZNet 2.5 OEM RF Modules. Digi International. 2008. Digi.com

3. “ZigBee.” Wikipedia, The Free Encyclopedia. Wikipedia.org. 2009. <http://en.wikipedia.org/wiki/Zigbee>

4. “Wi-Fi.” Wikipedia, The Free Encyclopedia. Wikipedia.org. 2009. <http://en.wikipedia.org/wiki/Wi-Fi>

5. “DASH7.” Wikipedia, The Free Encyclopedia. Wikipedia.org. 2009. <http://en.wikipedia.org/wiki/DASH7>

6. “Z-Wave.” Wikipedia, The Free Encyclopedia. Wikipedia.org. 2009. <http://en.wikipedia.org/wiki/Z-wave>

7. “Bluetooth.” Wikipedia, The Free Encyclopedia. Wikipedia.org. 2009. <http://en.wikipedia.org/wiki/Bluetooth>

8. “6LoWPAN.” Wikipedia, The Free Encyclopedia. Wikipedia.org. 2009. <http://en.wikipedia.org/wiki/6lowpan>

9. “Smart Parking System using Image Processing Techniques in Wireless Sensor Network Environment.” M.Y.I. Idris, E.M. Tamil, Z. Razak, N.M. Noor and L.W. Kin. Information Technology Journal. Year: 2009. Volume: 8. Issue: 2. Page No.: 114-127.

10. Roos, Dave. "How Wireless Mesh Networks Work." 20 June 2007. HowStuffWorks.com. <http://communication.howstuffworks.com/how-wireless-mesh-networks-work.htm> 12 December 2009.

11. Digital Image (2009, August). In Wikipedia, the free encyclopedia. Retrieved November 10, 2009, from http://en.wikipedia.org/wiki/Digital_image

12. Bradski, G. & Kaehler, A (2008). Learning OpenCV: Computer Vision with the OpenCV Library. Cambridge: O’Reilly.

13. True,N.(2007),Vacant Parking Space Detection using static Images,

14. www-cse.ucsd.edu/classes/wi07/cse190-/reports/ntrue.pdf

117

15. McHugh, Sean. (2004). Digital Camera Noise. Retrieved September 3, 2009, from http://www.cambridgeincolour.com/tutorials/image-noise.htm

16. Battery (electricity) (No date provided). In Wikipedia, the free encyclopedia. Retrieved November 1, 2009, from http://en.wikipedia.org/wiki/Battery_%28electricity%29

17. Eddy Current (2009, June ). In Wikipedia, the free encyclopedia. Retrieved November 25, 2004, from http://en.wikipedia.org/wiki/Eddy_current

18. http://www.sensorwiki.org/doku.php/sensors/temperature

19. http://www.sensorwiki.org/doku.php/sensors/light-dependent_resistor

20. http://zuff.info/RangeFindersComp_E.html

21. http://www.acroname.com/robotics/info/articles/sharp/sharp.html

22. http://www.tfhrc.gov/pubrds/septoct98/loop.htm

23. http://www.fhwa.dot.gov/ohim/tvtw/natmec/00000.pdf

24. http://www.meas-spec.com/downloads/SPZ.pdf

25. http://www.bolideco.com/PDF/procamera/BB1032.pdf

26. http://www.bluerr.com/images/Overview_of_FOS2.pdf

27. http://www.bolideco.com/productinfo.aspx?ProductID=BB1032

28. http://www.testech-elect.com/tern/ceye.htm

29. http://www.sensorland.com/HowPage002.html

30. http://en.wikipedia.org/wiki/Strain_gauge

31. http://mechanical-engineering.suite101.com/article.cfm/ an_introduction_to_strain_gauges

I.II Permissions1. Permission from Digi International

118

2. Permission from www.mcs.alma.edu

3. Cambridge in Colour

119

4. Meshnetics

120

121

5. Nick True

6. Acroname Support

7. Migatron Corp.

122

8. Halvorsen, Don

9. Wikipedia GNU License

123

124