ABSTRACT
This paper overviews the Smart Structure project. We found a desire from the City of San Luis Obispo for a way to tell the availability of parking spaces in local parking garages. In addition to meeting this need the project aims to provide functionality and adaptability based on future “smart” devices and making the device fit into an Internet of Things (IoT) system. Currently drivers must manually navigate the parking garage to determine which floor has a parking spot.
With our proposed solution drivers would be able to tell at a glance which floors had the most spots, as well as the relative fullness of each floor. Initial testing included a magnetic sensor, but it showed a lack of promise. The final solution is accomplished using a network of ultrasonic sensors. These sensors communicate to a database that is able to be accessed via a GUI. It is hoped that this project will provide the information needed for a real-world implementation of the network. This implementation could be done cheaply and with future device expansion
TECHNICAL BACKGROUND
figure 2 how data travels over the net.
TCP/IP is the basic communication protocol of the internet. Just about every computer comes loaded with the programs needed to access the internet. This collection of programs is often referred to as the communications “stack”. TCP/IP has two parts. The first layer is Transmission Control Protocol (TCP). TCP assembles the messages your device sends into smaller packets of data that are transmitted over the internet and received by the TCP layer of the receiving device. The lower layer, Internet Protocol (IP) handles the address part of each packet so that it gets to the right destination.
MQTT and the publish-subscribe model MQTT or Message Queue Telemetry Transport, is a standardized publish-subscribe “lightweight” protocol used for messaging on top of the TCP/IP stack. In the context of software, publish-subscribe is a messaging pattern where the senders of messages, called publishers, do not specify their messages to be sent to specific receivers, called subscribers.
An ultrasonic sensor is a device that measures the distance to an object using sound waves. It measures distance by sending out a sound wave and listening for that same sound wave to come back. Using the time it took for the sound wave to come back it is easy to determine the distance of the object the sound wave reflected from using the following formula: distance = (time taken * speed of sound ) /2.
DESIGN
The Smart Structure project was designed very modular in nature. This was very helpful when we had to switch sensors in the project. Switching meant acquiring a new device for the embedded Device and writing a new GPIO Module, but the rest of the architecture was able to be reused. This is a good example of how are system is able to be used as a framework with future IoT devices. The modules represented by clouds are where systems that do not yet exist would fit into our system.
TESTING
Testing the Magnetic Sensor
Our initial design did not use an ultrasonic sensor at all. Instead it used a Triple-Axis Magnetometer. The reason for this is we wanted to avoid as many false reading as possible, especially false positives. Since it is possible for a person, bike, or other non-space using object to move by a distance sensor and trigger a response we went with the Magnetometer. Initial tests looked promising, the sensor had a quick update speed and was able to accurately detect things such as the magnet inside our computer.
CONCLUSION
By situating an ultrasonic sensor at every ramp in the parking structure we are able to tell when a car leaves or exits each floor. Each sensor sends its data via a lightweight MQTT protocol to a central database, which aggregates all of the data. Using the database we can then say how many cars are on each floor. This data can be accessed via our Python GUI or through a custom python implementation, or directly from our MQTT broker.
The system is reasonably accurate, with built in error detection (for example when a person instead of a car) walks in front of the sensor, as well as a variety of error correction models that can be applied, including bounded database, manual calibration. Over a long period of time our system is able to improve its accuracy through skew analysis. This means theoretically the system gets more accurate the longer it runs.
The requirements for an implementation of our system is a WiFi network for the sensors to connect to, so that they can communicate. A WiFi or other network is vital to any IoT implementation. In regards to future development of this project there are several ways to progress. One promising method that unfortunately we did not have time to test is program a false reading drift. For our system to work with errors the number of false positives and negatives need to be roughly the same, that way they will balance each other out. This is fairly unlikely to happen naturally. Over a long period of time there will be more false positives than negatives, or vice versa, depending on the conditions.
Source: California Polytechnic State University
Authors: Erik Olsen | Justin Distaso
>> 200+ IoT Led Engineering Projects for Final Year Students
>> IoT Software Projects for Final Year Students