Prototype

They keypad with LED indicators for (in)correct password

Pretend package full of marbles to be used in demonstration

Introduction

This documentation presents the prototype of the anti-package theft for Emily. We interviewed Emily which is detailed in an older post and have detailed a working prototype that both looks like and works like the final product below.

Prototype Explanation

The purpose of this prototype is to fix the issue that Emily has of her packages often being stolen from her porch. This prototype doubles as a stand for her to keep her groceries on when she has to unlock her door so she doesn’t have to drop them and bend down to pick them up afterwards. This box has a lid that is normally closed and unlocked and will be opened when a delivery person comes. Inside are force sensors that check if a package has been placed on the bottom surface. There is a set time to wait to make sure that the force is constant to prove that it is a package and not some animal that has weaseled its way inside. Afterwards Emily will enter a password that she has previously set into the keyboard in order to unlock the box to retrieve her package.

Process Pictures

Our initial device drawing, showcasing a rough outline of our initial idea of the device’s look.

The preliminary prototype. All components (aside from LEDs) are integrated rudimentarily and working as they should.

Transfer of pressure plates to prototype. We tried to maximize the distance between each to cover a large amount of surface area.

Our prototype’s main hardware housing. We wanted something simple that made the core wiring invisible to the user and large enough to fit everything in one place.

Our prototype’s roof hinge system. We initially tried to use k-nect components but changed to plastic string when k-nect components proved very finicky and unreliable.

Overhead shot of new hinge, pressure sensors moved, and new lock piece on servo

The completed prototype. It is approximately 1:3 scale of what the final will be.

The servo used with an L-shape lock from popsicles.

Discussion

Challenges:

Throughout our prototype creation we faced several challenges: obtaining a working device passcode check system, designing a functional and reliable lock, and identifying sources to behavior abnormalities in our device.

At its core, our project is an anti-theft device, and so the ability to distinguish between adversary and benign users is critical to a working produce. Though many solutions exist, we opted for a simple keypad passcode as the identifier due to the readily available soft and hard keypads in the class lab. Initially, we found implementing the keypad logic fairly straightforward as each each pad button was represented by an element in a two dimensional array. However, we encountered difficulties when trying to check if two combinations matched. To explain, our reference code we used suggested to encode both combinations into string format, and then use a string compare to determine whether the two matched. However, when doing this we consistently found that one string was equivalent to the concatenation of the two combinations, while the second was a single combination. To illustrate, if the two combinations desired to be compared were: ‘1234’ and ‘1234’, then under string compare one string would read ‘12341234’, while the other ‘1234’, thus returning ‘False’ when in fact it should return ‘True’. This result was exacerbated by the fact that nowhere in our code was there an operation which concatenated the two combinations. However, through further experimentation we realized that what was most probable was that the issue was caused by the strings being stored right next to each other in memory, and that this was causing one combination to be read as the concatenation of two. Thus, to counteract this problem reliably, we opted to do an iterative-wise character compare which worked significantly better.

Another big challenge we faced was designing a functional and reliable lock system for our prototype. Though as with user type identifiers, there were many possibilities, we thought the simplest lock would be an L-shaped lever which would turn into a hole to lock. This would allow us to use a hobby motor as it primarily creates rotation around an axis. However, integrating our locking contraption with our box created a few challenges. Firstly, we quickly found that not only was the motor’s rotation inaccurate (e.g. if we set the motor to turn 90 degrees, it would vary between turning between 90 and 120 degrees), but it also turned extremely fast which proved dangerous to the device’s structural components. Both these issues created challenges in the lock fitting. For instance, due to the unpredictability of the lever’s rotation, it could reach the hole just right and lock as expected, or push through the hole break the lock (with the help of the rotation speed). This latter problem actually became a reality in one instance when the lever overshot the lock hole, and tore the box top off its hinges. Thus, to mitigate this issue, we conducted several experiments to effectively gage the motor’s rotation error randomness before empirically finding a rotation value which would avoid breaking the device while still ensuring it would lock.

Our third big challenge, was identifying sources of behavioral abnormalities in our device. Our prototype can be thought of the integration of three hierarchical stages. The first is the physical stage which comprises of how a user physically interacts with the device. The second is the user input reading stage, which consists of reading and extracting information provided by the user. Lastly, the third stage entails understanding and performing instructions based on the information extracted from the second stage. Framing the prototype in this way elucidates the fact that when the device behaves abnormally, it can be challenging to find the root cause because any of these stages could be at fault. For example, if a user’s passcode input does not match the device’s stored passcode (to unlock the box the user must input the correct passcode), the root of the problem could be (in respective order of the stages): 1) the user has put in the wrong passcode, 2) the user has put in the correct passcode but the keypad was faulty and did not accurately record all button presses, or 3) the passcode was correct, the keypad is reliable, but there is issue in the software passcode comparison. Because of this, whenever an abnormality arose throughout our project prototyping we had to debug each stage separately before identifying the cause (in the case of our motivating example it was a faulty keypad), which resulted in substantial loss of time. Though we have not yet found a more ‘cost’ effective way of debugging, it is something we’re interested in exploring for the final product.

April 8th Critique:

During the critique with Emily on Monday, we went over our ideas and prototype for what we had so far. Emily appreciated the overall design, however she had some ideas and changes that we could work towards for the final. The prototype has issues with the keypad being too fidgety and difficult to control, it was also not water proof. For the final, Emily hopes the keypad to be made of metal and to be reliable and water proof. The sensors at the bottom of the box are not large enough to be accurate for such a large box, she hopes for the sensors to be larger and cover more surface area along the bottom so a small animal will also be able to trigger the sensors. Emily also wants the box to provide more feedback, perhaps a light indication when a password is successfully changed and a light to tell if there is a package in the box. We brought up a concern that she may receive more than one package delivery in one day, however she did not seem to consider that a problem, she said she rarely receives more than one package delivery a day. We are still planning to look into this issue however it is not critical.

Emily wanted to establish that the enclosure does not need to be a perfect box. In fact she said it might be better for the box to be longer rather than wider, that way the box won’t bulge out so far onto her porch. She gave us appropriate dimensions of 20″x18″x30″ high or alternatively 20″x20″x30″ high. Our team also discussed materials with Emily and we agreed that wood would probably be the best material to be water proof and inconspicuous.  She stressed the importance of different wood joints that will stay strong for long periods of time, we are considering mitered biscuit joints but are still thinking of different options.

One large problem that Emily brought up that we did not consider is power. The box needs power 24/7 in order to check for packages and react accordingly. One idea that Emily brought up is solar power. She drew a picture of the back deck and showed how sun hits the area, she explained different places where we could wire a solar panel to the box to receive power. We brought up the idea of opening a nearby light switch and adding a connection to the box, however this is something that she would need outside help to do and she seemed to prefer solar power. She offered to be in contact with us about wire lengths needed and different physical aspects of the solar panel condition.

Next Steps:

Our next steps will definitely start with ordering new, better, and waterproof parts that we can start working with. Having the final parts will give us the upper hand on designing the full size box. Secondly, we will refine the box hinge and locking mechanisms to ensure that each is resistant to Pittsburgh weather conditions and working reliably. Thirdly, we will completely redesign the user interaction portion of the device: keypad and LED feedback. We plan on using a metal keypad in place of the soft button keypad, and introducing LED displays to give direct and more granular feedback for users. Fourthly, we will redesign our device to fit within the dimensions Emily specified, and investigate using solar energy to power the box. For this end, we will also stay in contact with her to understand the specifics of wiring needed for connecting solar power to the device.