Departments of ECE and CS - Home



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

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

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

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

1. Introduction

The 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.

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 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.

1. 3 Budget

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

|Project Task |Labor |Labor |Material |Travel |Other |Total per |

| |Hour |Cost |Cost |Cost |Cost |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 |10 |$0. 00 |$0. 00 |$0. 00 |$0. 00 |$0. 00 |

| |Specification | | | | | | |

|5. |Develop Detailed Design |10 |$0. 00 |$0. 00 |$0. 00 |$0. 00 |$0. 00 |

| |Specifications | | | | | | |

|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 |

|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 |0 |$0. 00 |$0. 00 |$0. 00 |$0. 00 |$0. 00 |

| |Agencies | | | | | | |

|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 |

| |

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 |

|Senior Design 2 (Spring 2010) |

| |

|Brush up on C++ Coding |Over Winter Break |Pending |

|Meet to Create Meeting times throughout the |First week of Jan |Pending |

|semester | | |

|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 |

2. Specifications & Requirements

The 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 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 feet

o 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

❖ Cost:

o Module - under $25 per module

o Development Kit – under $300

o 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 :

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

3. Research

The 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.

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.

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

[pic]

[pic]

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, 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)

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:

[pic]

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

[pic]

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

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.

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 data |

|emitter / receiver |receiver |

|sensing range sd |0 . . .  1000 mm |

|scanning range far limit Sde |0 . . .  1000 mm |

|object size (at Sd = 50 mm) |> 2 cm² |

|hysteresis typ. |5 mm |

|repeat accuracy | ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download