Element H: Test Plan

Prototype I

Procedure Overview

Materials Needed

Raspberry Pi 3 (Bluetooth Support, OS)
Internet Router (Linksys)
Paper Lamp with light
Bluetooth speaker
PC (Runs Pi OS through Workspace)
Wemo Brick

Step-by-Step

Edison's testing of the 1st Prototype used a Linksys router which serves as a bridge between the user's computer and the Raspberry Pi. After connecting everything to Parker's MacBook, the Raspberry Pi OS ran through a virtual workspace to be able to run the Python script. Afterward, the Python script will run prompting the designated wakeup time the user will set for their program. At this stage, if any error occurs, the user can reboot the Raspberry Pi and set the Bluetooth speaker to pairing mode. After the troubleshooting as been done, it will be required to repeat the steps stated above. If working as intended, the alarm will go off after the time set and the alarm tone will play in VLC player and the prototype does it's job exactly as planned. Light based-stimuli may be set via the Wemo app, which is completely self-explanatory. Plug in the Wemo Mini and connect to the network it creates to star the pairing process.

Testing

In order to test the first prototype, Edison Co. ran some preliminary functionality tests. They ensured that the prototype worked functioned correctly. First, they tested every part individually. They made sure that the Wemo software worked as intended, and that Parker's code turned on the speaker at the right time. They then tested to see if the light and speaker would turn on at the same time, or at least near enough.

Safety

Safety hazards to appear in testing is highly unlikely as the materials don't have any potential hazard outright besides an electrical one, which is even is a rarity if it something ever happens. Due to the use of technology, potential heating hazards may occur if not complimented with any fan implementation which shouldn't be a worry. The only other noticeable hazard is any potential fire hazard that may occur to the paper lamp. No safety precautions were taken while testing the prototype.

Documentation of Testing

Image of Linksys Router and Raspberry Pi 3

Prototype II

Procedure Overview

Materials Needed

Raspberry Pi 3 (Bluetooth Support, OS)
Internet Router (Linksys)
Bread board with LED and resistor
Bluetooth speaker
PC (Runs Pi OS through Workspace)

Step-by-Step

In Edison Co's testing of the second prototype, much of the testing and process was the same. In order to activate the PI, the same steps were taken in the same order, and the same troubleshooting methods could be used if something went wrong with the process or with the Bluetooth speaker. However, in this prototype, the proprietary Wemo app was replaced with a small LED bulb for testing. As such, the user would plug in the PI and the router, and follow the same steps as with the previous prototype, and not have to go through the Wemo app or network, as the bulb was built in. This bulb was a precursor to Prototype III's full size lightbulb.

Testing

With the 2nd prototype, Edison Co. used incremental testing in order to confirm functionality. First, the team created a simple program to turn on the LED with a solid current. This worked well and was incredibly straight-forward, with the minor exception of the pin designation. Pins are given a GPIO "ID", and also have a pin number. The Python module references the pin number. After this, Edison Co. attempted to synchronize audio and visual output. Simply having two programs allowed for this functionality, and everything was synchronized with little effort. Then, the real challenge began. The group now had to dim the LED, so they took a step back from the speaker/LED synchronization to once again focus solely on the LED. The first program the group created provided no output to the LED, so they went back to cross-check with the guide they were using. As it turns out, a quick rewrite of the program gave output; chances are, there was simply an improperly assigned variable or something of the like. Parker wrote a quick script that allowed for a tester to choose any brightness and set the light as such. The LED functioned properly; low percentage of PWM (Pulse Wave Modulation) output was very hardly visible, as one would expect, and the higher PWM output turned out to be pretty bright. As a side note, the circuit the group set up could run off both the constant 5V and 3.3V from the Pi. Once again, the same two-program setup as before allowed the group to easily synchronize the speaker output and LED output, which worked as planned. This was also Edison Co.'s first time testing the speaker with a wired connection instead of Bluetooth; audio was inseparable from before.

Safety

There were very few safety hazards present in this prototype, as the Raspberry Pi was in a case which made touching any pins next to impossible, thereby reducing the odds of being shocked to next to nothing. In working with the breadboard, there was a slight risk of shock, though the voltages being supplied were low enough that no real threat was ever present. Since the risk was negligible, no specific safety precautions were taken.

Documentation of Testing

Image of breadboard and LED used in dimming

Prototype III

Procedure Overview

Materials Needed

Raspberry Pi 3 (Bluetooth Support, OS)
Dimmer Board
Lightbulb with paper lamp
Bluetooth speaker
PC (Runs Pi OS through Workspace)

Step-by-Step

The third prototype had the largest improvements from the previous two, as it entirely removed the need for an internet router and simplified the process. To access the Pi, the user goes through the same process as with previous prototypes and connects to the Pi. However, the user can connect directly to the Pi instead of connecting to the Pi through the router, which allows for a faster and more seamless user experience. Once connected, the user navigates through a basic Python program with prompts and error detection, and can set their alarm for whatever time they wish. With this prototype, the user no longer has to set the time on the Pi when they connect to it, nor do they need to deal with the more complicated aspects of the Pi in the back-end.

Testing

From messing with the lightbulb in combination with the Pi, there were a couple of key observations about the behavior of the dimmer and PWM. First, the LED the group was using had a sort of "threshold;" when the PWM was set below about 20% strength, there would be no observable output from the lightbulb. Within the 20-40% range, the LED faced pretty extreme flickering. Beyond this range, the light was incredibly bright, but from what limited observations the group could make without harming their eyes, only minimal flickering was present

Safety

The 3rd prototype had the highest risk to safety of the 3 prototypes assembled. In the 3rd prototype, the team had to deal with exposed wiring, high voltage, and soldering. As such, they took extra safety precautions at every step of the way. For example, they wore goggles during soldering, only soldered in rooms with proper ventilation, covered all exposed wiring, and ensured that there was no risk of electrocution on any part of the prototype. One notable example of this was when the team needed to convert the AC power supplied by the outlet into DC power used by the Pi. They wanted to have only one wire going into and out of the housing, so they had to split the input wire into 2 sets, one for the lightbulb, and one for the Pi. After soldering the wires, they needed a way to convert the power from AC to DC. As a test, they took the converter from a power base (like the one you charge your phone with), and removed it from its plastic housing. However, when plugged in, the small converter had small pins which ran current through them. If someone touched the pins while it was plugged in, they would receive 120 volts. The team recognized this before it became a risk, and covered the pins in copious amounts of hot glue and electrical tape to ensure that no one would touch the pins accidently. They did this again with the dimmer board, and with any other pieces of equipment which had risks of shock.

Documentation of Testing

David soldering the prototype

Prototype mid-construction

Final prototype, outside of casing

Scientific Concepts

Some scientific concepts to be explored by Edison Co. include computer science and hardware/software integration. The code for the prototype, while functional, is still not entirely user-friendly. While better than manually typing out bash scripts, the code used is not perfect, and could be improved. Similarly, choosing better hardware which has all the functionality the team would like is something that Edison Co. would explore if they had more time with the project. More specifically, finding a way to control an RGB bulb so that the team could experiment with light color and determine if warm or cool colors help to wake up the user more effectively.

Engineering Principles

Engineering Principles used is PLTW Engineering Notebooks allowing for "official" documentation and notetaking on the continuation of the project allowing to be a vital tool for project organization. No other Engineering Principals were used during the planning of the prototype.

The Engineering Principles used in this project included documentation and problem solving. For the former, each team member was tasked with keeping an Engineering Notebook which would include a daily log of what was done, concept sketches, ideas, and the like. These notebooks, while at first an inconvenience, turned out to be an invaluable tool for organization and recalling ideas. The other engineering principle used was problem solving. Edison Co. dealt with many, many problems throughout the project. From infuriating code and inexplicable hardware failure to redoing 3D prints, Edison Co. had to deal with many problems. However, they persevered, and were able to achieve all the goals they set for themselves in the course of the project.

Validation

Ways to validate our prototype is through Edison's cohort Ms. Mason, who has background in coding and computer science and has worked with industry professionals before. With her knowledge in the subject, it is possible for her to approve Edison's proof of concept and further prototypes. She would be great for confirmation of how the prototype does and can give ideas for further prototypes later down the line. Other ways of validating Edison's prototype is through the opinions of piers from a consumer/user perspective being people who would actually buy the final product. They can provide insight on user quality and the effectiveness on prototypes and can provide criticism and future prototypes.

Page updated

Report abuse