Noise Requirement
written by: Fabian Suske
Approved and Edited by: Carolina Barrera
Table of Contents
Intro:
In order to fulfill the L2-13 subsystem requirement “Safety/Temperature sensor” a test has been carried out. This test followed the Verification and Validation Test Plan. The temperature sensor was implemented as a safety switch in the device. The feature is to prevent incidents when the components overheat, and the device could potentially become a hazard for the user’s safety.
Test Objective:
The test criteria that needs to be tested in this inspection is the following:
“Test Objective: To successfully verify the L2-13 (Safety) requirement, the Prosthetic Arm shall implement a temperature sensor such that upon reaching unsafe operating temperature (above 55°C), the system will shut-off “[1]
Test Method
The test was set up in the following way:
- Temperature sensor
- Maker1000
- C Algorithm to control the shutdown
Because of the incident while testing the kill switch, the Teensy MCU was not available for testing anymore. So, the temperature sensor was tested with the Arduino Maker1000 on a breadboard.
The breadboard was placed in a “temperature isolated” environment which was then heated up until the unsafe operating temperature of 55°C was reached. An indicator LED in the breadboard notified the system’s shutdown.
Test Conclusion:
Figure 1 shows that after the temperature reached the 55°C the Serial plotter stopped, and so we knew the shutdown had been initialized.
At the same time the LED indicating the shutdown went on in Figure 2.
The Serial Monitor also logged the temps and the shutdown. Figure 3 shows the analog serial values the temperature sensor was outputting.
[1] https://drive.google.com/drive/folders/0B3qlnfB-grPcVzJOTTZyemZ2R3c
Temperature Sensor / Safety
Written by: Fabian Suske
Approved and edited by: Carolina Barrera
Table of Contents
Intro:
In order to fulfill the L2-13 subsystem requirement “Safety/Temperature sensor” a test has been carried out. This test followed the Verification and Validation Test Plan. The temperature sensor was implemented as a safety switch in the device. The feature is to prevent incidents when the components overheat, and the device could potentially become a hazard for the user’s safety.
Test Objective:
The test criteria that needs to be tested in this inspection is the following:
“Test Objective: To successfully verify the L2-13 (Safety) requirement, the Prosthetic Arm shall implement a temperature sensor such that upon reaching unsafe operating temperature (above 55°C), the system will shut-off “[1]
Test Method
The test was set up in the following way:
- Temperature sensor
- Maker1000
- C Algorithm to control the shutdown
Because of the incident while testing the kill switch, the Teensy MCU was not available for testing anymore. So, the temperature sensor was tested with the Arduino Maker1000 on a breadboard.
The breadboard was placed in a “temperature isolated” environment which was then heated up until the unsafe operating temperature of 55°C was reached. An indicator LED in the breadboard notified the system’s shutdown.
Test Conclusion:
Figure 1 shows that after the temperature reached the 55°C the Serial plotter stopped, and so we knew the shutdown had been initialized.
At the same time the LED indicating the shutdown went on in Figure 2.
The Serial Monitor also logged the temps and the shutdown. Figure 3 shows the analog serial values the temperature sensor was outputting.
Resources
[1] https://drive.google.com/drive/folders/0B3qlnfB-grPcVzJOTTZyemZ2R3c
Kill Switch / Safety
Written by: Fabian Suske
Edited and Approved by: Carolina Barrera
Table of Contents
Intro:
In order to fulfill the L2-12 subsystem requirement “Safety/Kill switch” a test has been carried out. This test followed the Verification and Validation Test Plan.
Test Objective:
The test criteria that needs to be tested in this inspection is the following:
“Test Objective: To successfully verify the L2-12 (Safety) requirement, the Prosthetic Arm shall implement an electronic kill switch allowing the user to shut-off the system in case of an emergency “[1]
Before the MCU is integrated, a basic functionality test has to be carried out.
Test Method
The test was set up in the following way:
- Power supply
- PCB
- Teensy
- C Algorithm to control the enable pin
The PCB was hooked up to the power supply. The Enable jumper was shorted, and the system powered up. When the jumper is removed, the power in the PCB should shutdown.
Afterwards the MCU should be able to control the Enable pin.
The Teensy MCU was connected to the PCB. Once connected, the PCB was powered up. The MCU sends a high signal to the Enable Pin of the 14-12V LDO. Upon the successful reading of the high signal, the Enable Jumper was removed. Setting the Enable pin to low the power should cause the LDO to turn OFF.
Test Conclusion:
The first test was performed successfully. When the Enable Pin was shorted, the LDO provided power to all subsystems and Power was available on the 12V and 5V outputs. Once the jumper was removed, the power in the outputs dropped, and the system works as designed. An oscilloscope was hooked up to the PCB to measure the performance of the power off.
The following time was measured:
- Reaction time of the LDO
- Shutdown time
- Total time of shutdown
The time after the Enable signal drops (the reaction time- blue/Ch3) until the Voltage drops(green/CH2) obtained in the measurements was 4ms roughly.
The shutdown time -the time it takes the system to drop from 12 to 0V, was measured, and 5ms were obtained.
The total time of shutdown was calculated as the sum of the two previous times. Hence, it can be concluded that the system shuts down completely 9ms after the Enable was set to low.
After this, a second test was performed. In order to control the Enable pin through software, the MCU was connected to the PCB, but in this part of the testing we had the PCB behaving unusual.
When the MCU was connected to the board, and the Enable jumper was removed from the board, the system stayed ON. Another option to shut the system down was to force the output in the Enable pin to low, but that didn’t work either. After a couple of tries, the MCU was not programmable anymore. It’s unclear up to this point what could have occasioned the malfunction. Probably the Pin design to pull the Enable pin down was shorted to 12V by accident. As a result, the MCU fried, and was left inoperable.
In conclusion, the Hardware implementation of this power off works. When the MCU was introduced to control, the action of powering off the system didn’t do what it was supposed to, and a short might have left the MCU broken presumably. Therefore, the test failed but it was still completed around 50%.
Resources
[1] https://drive.google.com/drive/folders/0B3qlnfB-grPcVzJOTTZyemZ2R3c
Portability (L2-8)
written by: Fabian Suske
Approved and edited by: Carolina Barrera
Table of Contents
Intro:
In order to fulfill the L2-8 subsystem requirement “Portability” an inspection has been carried out. This test followed the Verification and Validation Test Plan. This requirement is basically to ensure the arm can be operation for 20 minutes – as agreed, and justified in previous stated requirements.
Test Objective:
The test criteria that needs to be tested in this inspection is the following:
“Test Objective: To successfully verify the L2-8 (Portability) requirement, the Prosthetic Arm battery system shall allow the user mobility, as to permit a 20 minute operation without constraining the user to a wired connection to the mains grid, or generation source.“[1]
This requirement goes along with duration, and both entail the success in the battery selection. If the team chose the right battery, then the arm will be able to operate for 20 minutes continuously, and ideally, it would not need to be recharged until the meal is finished. Therefore, the battery has been hooked up to the PCB and the both critical Voltages read.
Test Method
The test was set up in the following way:
- Battery
- PCB
- DMM
After the battery was hooked up, the DMM was used to measure the Voltage for 12V and 5V at the respective points. These readings are the power to the MCU and the motor. From the arm MCU there are wires that power the Hand’s MCU, and the motors in the wrist and fingers. This is the reason for having these two requirements for battery selection.
Figure 1 shows the mount of the battery inside the bicep, and Figure 2 and Figure 3 show the reading of the output voltages from the PCB.
Test Conclusion:
The first positive indication was that all status/power LED’s light up. This means the battery is able to provide at least 6 V to the Buck Converter. The following measurement ensured that the Voltage levels outputting the right values.
[1] https://drive.google.com/drive/folders/0B3qlnfB-grPcVzJOTTZyemZ2R3c
Blogpost Speed requirement (L2-6)
Written by: Fabian Suske
Edited and approved by: Carolina Barrera
Table of Contents
Intro:
In order to fulfill the L2-6 subsystem requirement “speed” a test has been carried out. This test followed the Verification and Validation Test Plan. The speed is mainly a requirement that was generated to make an effective system that would allow the user to bring the food elements to the mouth-level and back to the table to roughly complete the mission in the average time to eat a meal.
Test Objective:
The test criteria that needs to be tested in this test is the following:
“To successfully verify the L2-6 (Speed) requirement, the Prosthetic Arm shall be operable by the user at a pace of ten “lifts” (ie. movement from resting position on table, to flexion point required to reach mouth) within 8 minutes.” [1]
Therefore 10 movements of 120 degrees needs to be completed in under 8 minutes since 60 degrees is our range of motion.
Since the arm utilizes a stepper motor -which gives precise control over the movement (angle, steps), a test algorithm has been set up that moves the arm 10 times up and down in a specific period of time.
Test Method
The test was set up in the following way:
- C Program to control the movement
- The prosthetic arm with a mounted forearm
- Smartphone as stopwatch
- Camera to document the test
Process
Since the arm is going to be moving from the table to the mouth level to reach the food and feed it to the mouth, there were three demos performed in which the team measures 60,__ and __ degrees going down and up. The idea is that if the team is able to complete the moves under the time stated in the requirement then the requirement will be evaluated as aa pass.
- For this test, the forearm and the bicep needed to be assembled together. The initial angle is the angle closest to the bicep.
- A code was implemented so the motor run 60 degrees down and back.
- For the other two angles, the same procedure of steps 1 and 2 were implemented
Test Conclusion:
The arm needed 4:06 minutes [2]to complete the task. Since the allocated time for this requirement was 8 minutes, the prosthetic arm came in slightly over half of the time. Therefore the test is 100%completed.
Resources
[1] https://drive.google.com/drive/folders/0B3qlnfB-grPcVzJOTTZyemZ2R3c
[2] https://www.youtube.com/watch?v=VoRxWJ_K93U&feature=youtu.be