1. Deliver button is pushed and delivery door locked.
2. Internal lift is raised to its maximum height, taking into account existing packages. This height is detected via an infrared sensor on the inside.
3. Trapdoor is unlocked, dropping the package a very short distance onto the lift platform.
4. Internal lift is lowered all the way down.
5. Trapdoor is closed, and the delivery door unlocks.

The Walls

For the walls of the mailbox, we can use stainless steel¹. This will prove to be both sturdy and weather resistant. It is corrosion and erosion resistant, and it will not be easy to cut through. We can also paint it, giving customers an option to customise their mailbox. The price related to this can be ascertained after meeting with our potential production partners.

Movable Platform

We can build the movable platform using stainless steel as well. We will probably have to use more powerful motors as compared to the ones we are using in the workshop. The price related to this can be ascertained after meeting with our potential production partners.

Handyperson for installation

We suggest 2 people for 2 hours for installing the smart mailbox according to the customers’ preference. The average hourly rate of a handyman is £11.71². So the total installation fee will be £46.84.

UV Sterilizer LED

We expect there to be 2 such LEDs (110 V, US) on 2 opposite walls (the ones adjacent to the access doors). The total comes to £24.02 (£12.01 each)^3.

Locks

All materials for the lock are expected to remain the same, although upon a future round of testing (hypothetically) if we find that the locks are not sturdy enough to withstand brute force, we might have to look at certain improvements, although the core mechanisms stay the same. The cost for building the current electromagnetic locks have been included in the budget.

Bascule trap door / collapsible platform

This platform separates the drop-off area and the secure compartment. We can use RSPro struts, which are £41 per metre and angle joints for RSPro struts, which are £5 each⁴.

Particle Photon

The IoT computer responsible for taking commands from our app and controlling the mailbox.

Power Supply

As apposed to the 8-way AA power supply we're currently using in our prototype, we would use a LIPO Battery 11.1V 1800mAh LB-012⁵. This would provide us with the long battery life we desired.

Over the course of development, changes were made to our original vision of the project which significantly impacted our budget. Some of the smaller changes included adding extra sensors, such as infrared, which was a decision made after the initial planning process. The updated budget also takes technical time into account, which was something we were unsure of our ability to use at the stage of Demo 1, as we were considering using solely Webots simulation and no physical hardware.

A more significant design change was going from our initial idea of a scissor lift to a forklift, to handle the inner platform of the mailbox. One of the huge deciding factors of this, other than the obvious hardware limitations, was the fact that even folded down all the way, the scissor lift would take up a significant portion of the height of the mailbox, reducing its ability to hold parcels. The forklift on the other hand is simply a moving platform, and takes up significantly less room. It is also a lot easier to use infrared sensors with a forklift, as there is only one moving component, and no supporting scaffolding.

Some of the potential security risks involved with our product came to our attention later in development, which led us to rethink our door locking mechanisms. Our initial plan was a magnetic lock, which is something we have stuck with, but we have now taken care to include a heavy-duty deadbolt lock as well, which would act in the event of power failure. This is to prevent an unpowered mailbox being left unlocked and at risk.

As you can see from the Gantt charts in this section, there were some time alterations necessary for our initial plan. In the first demo, we had initially planned to design the website UI, and start designing sections of the app UI. We ended up with a fully designed and partially implemented app UI, as well as a rough design of our website. In terms of our Webots simulation, we had a basic model, which is what we had planned.

In demo 2, since we were already ahead in terms of our app, we were able to get a fully functioning app front-end, and start testing out the UI. We had initially only planned to have some basic functionalities like navigation at this stage, so this was a huge success by the group. In our initial plan, there was no real mention of commissioning hardware, as we didn’t know if that was something we could do. We ended up commissioning our magnetic lock in this demo, and deciding against using a camera on the front of our device for security reasons. In terms of Webots, we had a simulation showing our device mainframe, which was what we had planned.

The third demo was more about hardware, and getting our app to communicate with our various components. In our initial plan we mentioned WiFi/Bluetooth module installation, and this ended up coming about in the form of the particle photon, which we installed in this demo. We also commissioned our forklift, and performed testing on the components we had at this stage. We started looking at app-device connectivity, and managed to get a button on our app to turn a LED on a particle photon on/off. This showed real-world interaction which we planned to develop in demo 4. We updated our Webots simulation to include infrared sensors, and updated our website according to plan. There were also revisions to our app UI in response to accessibility and usability workshops, which we could not have foreseen in our initial planning stages. We also created an advertisement video, which we were not initially planning to do.

The final demo was about getting everything ready to present. We completed our app, website and Webots simulation as planned, but with some minor deviations. We spent time completing QR code scanning for our app, stress testing both our app and simulation, and updating our app UI for further usability changes. These were things we thought to do later in the process, which is why they were not in the initial plan. We also completed our robot-app communication implementation and testing, and performed extensive tests on the hardware components we had commissioned.

We tested the open/closed state of our solenoid by both operating it with our microcontroller and manipulating it manually, then checking the sensor readings for whether they reflect it being pulled in or pushed out. On average, the readings were accurate 4/5 times. We suspect that the sensor readings are not entirely accurate due to some noise present in them. We ran a similar test after manipulating our latch and the latch sensor returned expected values between 3/5 and 4/5 times, with some noise accounting for 1 or 2 unexpected readings. For each case, we changed states (i.e., between 0 and 1) 5 times[1]. When returning the state of the above components to the app, we look at readings in groups of 5. If 3 or more readings are the same, we report the state that corresponds to the majority reading.

Our remote technition was present at the lab to confirm that our solenoid was working as expected at all points, which means that it was pulled in at our "on" command and pushed out at our "off" command (as was implemented using the microcontroller).

We also tested our secure compartment mechanisms which included a forklift driven by a motor and two infrared sensors. One sensor (s1) is at the top of the compartment (at 33 cm), pointing across it and mounted onto a wall adjacent to the doors. The other sensor (s2) is at the bottom of the compartment, pointing upwards. If s1 returns less than 19 cm (width of the compartment),then we know a parcel has entered the secure compartment. Readings from s2 let us know the distance of the moving platform from the floor.

We ran 30 iterations of the movable platform’s upward and downward movement to decide on thresholds of when it should stop. The forklift is about 48 cm high. To allow for the parcel some space to enter the secure compartment and drop into the platform, we stop it at 31-32 cm when going up. We want to stop the platform at a 4-5 cm distance from the floor to avoid it ramming into the sensor s2 when going down.

We ran 5 iterations of dropping a single parcel into the movable platform. It stopped after moving down far enough to clear s1’s ’line of vision’ 100% of the time. We ran another 5 iterations with multiple boxes (3), placed one after the other. The forklift moved down as expected 100% of the time. Upon placing a parcel such that s1 returned a reading of less than 19 cm while the moving platform was at 4 cm from the ground, it did not move down any further, which is the desired behaviour. In this state, we are able to raise a flag of "Mailbox is full".

We also had to allow for a little noise in our infrared sensors. Sensor s1 gives a reading which sometimes varies between 19 and 20 cm while there is no parcel. We take the lower threshold, i.e., 19 cm, to check against. This worked well for our above test cases. Sensor s2 gives a similar varying reading, which is why we allowed a 1 cm interval when deciding the thresholds as discussed previously.

We ran multiple test for the Webots simulation in order to ensure its robustness and investigate its capacity. Even though its simulation testing, in order to present a real-life scenario, the parcel size and process are strictly following the maximum standard of Royal Mail UK Parcels Size and Weight. The length of UV sanitation differs based on parcel size after research (Hiroki Kitagawa, et al.).

From the experiments we could tell that for the current size of the mailbox (75cm*75cm*100cm), it could take 12 max-size letters, or 5 max-size small parcels, or 1 max-size medium parcel. Blueprints and actual simulations are provided as screenshots. Though the large size parcel cannot be put into our mailbox, according to Royal Mail standard, large parcel has a length of 1.5 meters, such large parcels (e.g. television, furniture, etc.) are better to be handled in person, which is not considered as our product initiative.

We used Monkey to test the robustness and stability of our Android application. Memory usage and coherence between different classes was considered. The table on the right contains testing of all the functionalities of the application and their testing results.

In the test, we found that some functions are highly dependent on the quality of the network. When the network delay is high or the connection is unstable, the functions trying to send HTTP Post will be blocked. At the beginning of the design, if the function corresponding to a button cannot be finished due to network reasons, it will cause the button to be temporarily inaccessible. This is to prevent excessive touches from causing the entire application to become unresponsive. In specific use, although the user cannot touch the functions that are being used, he can touch functions that have not yet been used, such as the navigation bar. The results of the stress test show that the application performs well when it does not involve frequent page switching, but if frequent page switching is performed, some functions will occupy a considerable amount of memory. This is because the App uses a polling method to update the data, and the data on the entire page will re-send the HTTP command to Particle Photon every time it is re-entered. When the data is obtained, the page will not be refreshed immediately, but will be automatically refreshed after the user leaves the page or the page is static for a period of time. Before entering the new interface, the application will also try to obtain updated data.

For our usability testing, we had 5 participants, 2 of whom were native English speakers while 3 were non-native English speakers. While 3 of them were from within the Systems Design Project course, 2 of them were from outside of the School of Informatics. All of them were students at the University of Edinburgh. Maintaining a balanced mix of both native and non-native English speakers as well as students with and without a technical background helped us shed some light onto how different people would interact with our app.

The testing was conducted as a recorded video call with each of the participants, where they were given access to our app’s user interface through a rendering on Figma. We described our project to them and how the app ties with the hardware. They were then asked to perform certain tasks using the app and rate how difficult it was for them to complete the tasks. We also noted some useful comments while analysing the participant’s interaction with our app. At the end we asked them some general questions and documented their feedback.

The tasks were:

1. Login and view your account
2. Determine the status of Jane’s mailbox delivery door, battery life and storage capacity
3. Add a new device via the QR code on the mailbox
4. Unlock and lock your new device
5. Edit your device name and remove Jane from the device then save those settings
6. Remove your device
7. View all your notifications, then just John's mailbox notifications
8. Find help for errors
9. Log out