The Problem:

According to a study by August Home, Inc., a home lock manufacturer, eleven million American homeowners had packages stolen off their doorsteps in 2016 (August).
In the same August Home study, twenty six percent of American homeowners reported that they receive packages at least once a week.
This number is only set to rise every year with the dominance of online shopping and subscription services. Of the eleven million victims of package theft last year, seventy four percent of the victims’ packages were stolen during the day while they were not home.
Of the people polled for the study, sixty four percent of people said they would prefer to pick the exact time and day of delivery, so that they could guarantee they would be home to receive it (August).

Our Solution:

With the rising importance of secure parcel delivery, it is becoming more necessary for a parcel security solution that brings peace of mind to consumers. Our group has come up with such a solution: the SafeDrop Box.
The SafeDrop Box is a doorstep lockbox that senses when a package is placed inside, then sends a notification to the owner. Upon receiving the notification, the owner may then check the status of the box seeing the weight, lock the box remotely and securely, and at a later time unlock the box from anywhere via the SafeDrop web app.

Video Demonstration:


In summary, there is a rise in doorstep parcel theft victims among homeowners in the United States. With an even greater rise in online shopping, American homeowners deserve a secure, and convenient solution to this problem. The SafeDrop Box is precisely that solution.
The SafeDrop Box is a web-app controlled lockbox with sensors to relay information about the contents inside the box. Our group accomplished the production of the SafeDrop Box with servomotor locking mechanisms, a loadcell weighing mechanism, and a Raspberry Pi to tie it all together in an appealing, user-friendly web app.
Ideally, the SafeDrop Box will have a more secure locking mechanics and a more secure structure than a wooden shipping crate, but the current model is adequate for practical use with medium to low value packages. We believe that the demand for such a product will only rise in the future, and hope to help those individuals with the SafeDrop Box.
Currently the box is being redesigned from the ground up, allowing packages to be continously dropped, even if the access door is locked. This embedded device and locking/notification system will be applied in a wider array of uses.


The Web Application
The goal was to create a web app that would be simple, easy to use on any device, and would be potentially extendable. At the time, we did not yet know how the locking mechanism would work, how the weight sensor would function, or what would be going on behind the scenes.
This meant starting with the user interface. The goal to be mobile friendly and simple lead to the use of Bootstrap, an open-source front-end web framework. Originally, most of the site was using the Bootstrap framework to quickly and easily build a top and horizontal navigation, followed by a middle-centered control block of buttons. Most of the Bootstrap has been disregarded in the final build, but some of it remains in the buttons and spacing. Google Fonts/Icons were also used for style. JavaScript and Ajax (Asynchronous JavaScript And XML) allow the box to monitor the buttons.
When clicked, the buttons run the code to lock or unlock the box without having to reload the page. This is done by adding two event listeners on the two buttons, and code to handle each scenario which uses a small amount of Ajax to build and send the request. This method of implementation of the web app allowed us to adhere to the overall goal of simplicity and extendibility.
From the site’s perspective, the site needs to know when something is placed inside the box, and needs to be able to tell the box when to lock or unlock. Nothing should be stalling or waiting unnecessarily--especially not the site. The user should not be hindered in their use of the site as they wait for a package to be put in. The site and the user should come first with a seemingly direct control over the box. The first order of action was to get the web server up and running. Normally this would be easy, but doing so on a Raspberry Pi and dealing with moving the Raspberry Pi to any wi-fi network -- and being able to access it from any network around the world -- required a more advanced tool: Dataplicity.
The site needed the ability to do more than just front end HTML/CSS/JavaScript. The client (or web page the user accesses) needed to send off information to the server, and then the server should act and reply. A framework would help save a lot of time and handle a lot of the work. Because the locking and weight sensor scripts were in Python, the group used Flask, a Python framework.
Dataplicity acts like a middleman for managing wi-fi networks, and has support for hosting a website with relative ease. According to the Dataplicity website, “Dataplicity Wormhole allows you to host a website from your Raspberry Pi, regardless of where it is installed, at a specific address: Port forwarding, firewall exceptions and Dynamic DNS are no longer required” (Dataplicity). This was the solution needed to connect the Raspberry Pi to host the web app. All that was left was to install the Dataplicity client and its dependencies, and follow the steps to enable Dataplicity Wormhole.
The site needed the ability to do more than just front end HTML/CSS/JavaScript. The client (or web page the user accesses) needed to send off information to the server, and then the server should act and reply. A framework would help save a lot of time and handle a lot of the work. Because the locking and weight sensor scripts were in Python, the group used Flask, a Python framework.
Flask is a microframework for Python. It has a built-in development server and debugger, integrated unit testing support, is Unicode based, and is extensively documented. It has been used to create a diverse array of apps from twitter-like websites, to blogs, to many Raspberry Pi hosted websites. The most important feature of Flask is the RESTful request dispatching. This allows a client to make a request for a page, handle the request with ease and use any needed functions, and then return and render the view. Dataplicity is nicely compatible with Flask as well.
To summarize, this step enabled the user to set both the port the device would use and the script to listen to. Migrating the static website developed earlier into one using Flask was the next step. Flask works by having the Python .py script which stores the functionality and starts the webserver, and then in a folder within the same directory called “templates” we have our view files ending with .html. In the same directory, we have our static folder with CSS and JavaScript files, our weight sensor script to communicate with the server script, and more. For each view we have, we have a route mapping the view to a function. So, when a user clicks on the “status” button, they are routed to the status function in the .py script. The function reads the data the weight sensor has written, updates variables, and sends those variables off to the view by redirecting to the status.html view.
The following steps to connect everything came with relative ease thanks to Flask because all the source code was written in Python. Earlier on, the group had taken a moment to debate putting the source code in the web application’s Python script. Instead, the group decided to have all other code call the methods inside of the script. This allowed the other scripts to use the site. For instance, when the load cell script decides to send a notification to the user, it simply calls the notify function in the server’s script. The notify function uses the SMTP established by using the Flask-Mail interface to send an email to the user on record; however, the connection was not completely there for everything we wanted to do.
We could use a database, or even use additional frameworks and tools, but we decided to keep our simple methodology going and have the weight sensor and the server pass messages through a file. Anytime the box is locked or unlocked, that state change is written to the state file. Anytime the box senses a weight change, the weight is written to a state file for the weight as well. This allows both scripts to run in parallel and not be hindered by what the other is doing, and communicate by reading or writing messages. This approach was only further encouraged and reinforced by the implementation of the locking mechanisms, and how the group was writing to a file to change the locks to be either locked or unlocked.
At this point, the Raspberry Pi can start up the web server, start the weight sensor script, and now the box can do everything it needs to. Something can be set in the box, the user is notified, and they can then access the site and with a click of the button lock the box. They can see the weight of what is inside, see whether the box is currently unlocked or locked, and unlock it when they want to. The box does what it is intended to, however, the product idea did not include the user having to remotely log into the machine and start up the server every time the box was powered on. As a result, a bashrc script was written to run on startup, calling a Python script that cleans up the environment and starts the webserver.
From here the goal is to improve the site, fix some of the styling and add styled SweetAlert notifications for when the user locks or unlocks the box. SweetAlert is a CSS and JavaScript package that modifies the default JavaScript notification.

The Hardware
The box is comprised of many physical components. The box itself is made of a wooden shipping crate padded with foam and wrapped with duct tape for shape and protection. There are wood blocks on the bottom platform with a thin board resting on top of the blocks to provide a space for the Raspberry Pi and the connected components, as well as provide a platform for packages to rest on.
A loadcell sits under the thin board as the weighing mechanism. Two servomotors are attached to opposite corners of the box near the opening. The servomotors are the primary locking mechanisms. The loadcell used is a bending bar strain gauge. This type of loadcell measures changes in the electrical resistance in response to force acting on the devise using a wheatstone bridge. These analog strain readings must be converted to digital signals for the Raspberry Pi to make use of the data.
A HX711 amplifier is used for this analog to digital conversion. The loadcell was needed to be soldered to the amplifier, but the pins on the amplifier allowed for easy connection to the breadboard. Voltage and ground are drawn from the Raspberry Pi, and clock and data pins are used for reading data. To coordinate and read the signals received through the GPIO pins, a library written by Philip Whitfield was used. This library reads the GPIO pins and gives the data as an integer value.
To make use of the data, a Python script is used. The script loops and grabs the loadcell data every 2 seconds. The data is compared to the previously seen value. If it is different the server script is called to send a notification and the new value is stored. The value is stored in both a script variable as well as overwrites a file that the server reads from to give the weight for the user. The weight file only stores the data integer value and the web app does the conversion to pounds. The data is divided by what was found to be 1 pound into a double and then is rounded to the nearest quarter of a pound for the user to view.
The loadcell is very sensitive, even changes in temperature or humidity will give a slight variation in data. Because of these slight variations, steps had to be taken in the script to compensate. The client should not be notified every time the value changes slightly; therefore, the integer value is integer divided by 100 to avoid sending unnecessary notifications. Of course, the precision of the weight should not be impacted, so the weight is written to the weight file using the raw data first.
In addition, the loadcell data will sometimes have a large, brief spike in data. To compensate for this, the first time the data value has changed does not matter. There must be two consecutive equal values that are different from the old data before weight values are changed and notifications sent. The Hitec HS-55 9g Micro Servo servomotors are the locking mechanisms used for the project. Because servo motors do not require constant power to either stay open or closed they were chosen over solenoids and steppers. They are wired to a dedicated power source so the Raspberry Pi is protected from surges. There are only 3 wires required: power, ground, and control.
Servos require a specific pulse length through the command wire to instruct it on when and how far to rotate. Timing issues with the software control of pins necessitate a background process to take control of sending the pulse signals with hardware support. If a software program that controls the servo command pulses, the motors suffer from bad jittering and vibrations. For the project a library ServoBlaster from Richard Hirst is used. This background process uses a file to control the servo motors.
To control the servo position from the command line all one would need to type is: echo P-= > /dev/servoblaster. The library takes care of the rest and the servo instantly moves to the correct position without jittering. To control the servos from the server, a Python script was used. When the web app receives the command from the user to either lock or unlock the box the script is called. It opens /dev/servoblaster/ for writing, writes either the lock or unlock position for both servo locks and then closes the file. The servo motors are then instantly placed into lock or unlock positions. The script also writes to a file that the web app uses to keep track of the lock status even if the server is powered down. When a servo is moved into position its head is rotated with a bar attached. To lock, the bars slide under latches on the lid to hold the lid shut.
The implementation of the servomotors for locking, along with the loadcell for weighing proved to be the best strategies to accomplish the intended purpose of the box. Although these approaches could be improved in a later model, these specifications worked within the time and financial limitations set for the project.