/public/

Subsystems Design

Table of Contents 1 Phase Planning 1.1 Shared Phase Vision 1.2 Prioritized Tasks 1.3 Week 15 Plan 1.4 Updated Documentation 2 Testing Tracking 3 Electrical Testing 3.1 Schematic 3.2 Top Level Pseudocode 3.3 Data Flow Graph 3.4 Heelstrike Sensor 3.5 Distance Sensor 3.6 Store Gait Data 3.7 Low Battery through Arduino 3.8 Low Battery through Zener Diodes 3.9 Solenoid Control 4 Mechanical Testing 4.1 Muscle Deflection 4.2 Muscle Optimization Stage I 4.3 Upper Muscle Attachment 4.4 Lower Muscle Attachment 4.5 CAIR Capacity Test 5 CAD Models 6 Long Term Plan MSDII 7 Build, Assembly, and Debug Plan 8 Bill of Materials 9 Risk Assessment 10 References 10.1 Regulator Resources 10.2 Past Projects 11 Subsystems Review

Phase Planning

Shared Phase Vision

Our vision for this phase is to demonstrate Critical Subsystems feasibility. Our current critical subsystems are defined as:

1. Distance and heel strike sensor
2. Electrical control of air muscles
3. Secure foot – Lower
4. Secure foot – Upper (Air muscle attachment)
5. Air muscle lift / operating pressure
6. Air Tank for a full day

Key related technical questions include:

1. What is the best location to place the sensors? Can we control the distance of object detection? Is the new pressure sensor an improvement from the foam used on past projects?
2. Can we control the air using electrical components? Can we do that using just an Arduino? Will we need level shifters?
3. How and where to apply torque? What possible materials to use? Ergonomics?
4. How and where to attach muscle? How much force can it support? Is it safe?
5. How much force can we produce? What is the operating pressure range?
6. How much air do we actually need? Can we meet the operating pressure?

Some additional plans for this phase for our group are as follows:

• Review of functional decomposition and system architecture by adding up key subsystems to critical system requirements (verify flow-down to subsystems).
• Create subsystems’ functional decomposition. Show feasibility for these subsystems.
• Update postprototype test plan, make sure that requirements can be tested.
• Update and iterate the Risk table
• Update Actions items from last review

_{Return To Top}

Prioritized Tasks

_{Return To Top}

Week 15 Plan

_{Return To Top}

Updated Documentation

_{Return To Top}

Testing Tracking

_{Return To Top}

Electrical Testing

Schematic

_{Return To Top}

Top Level Pseudocode

_{Return To Top}

Data Flow Graph

_{Return To Top}

Heelstrike Sensor

Motivation - This test was to set up a prototype of the type of sensor that will be used to measure Heelstrike. The difference between this sensor and the final sensor that will be use is only the pressure level that can be applied to the sensor.
Procedure - The first part of this testing was to connect the Arduino. The pressure sensor ranges between infinite to ~300k and is connected to ground and in series with a resistor that is then connected to the power supply.
Code - The rest of the test was to create a function that will test the value of the ADC input and compare it to a tolerance and decide if there has been a Heelstrike.

• Initialization - The code will set the ADC that is monitoring the sensor. The tolerance level that will decide if there has been a Heelstrike or not. In addition to this, serial prints enable was set.
• Strike - This function looks at the value of the ADC and returns a true or false of if there has been a Heelstrike. The function has no inputs and will return a Boolean.

Results - The timing of this function is important. This was found using the Arduino’s on board timer. This was also done without serial writes in order to make sure that the speed is representative. The timing is recorded below.

• Strike Function and a conditional statement: <1ms

The output was also monitored to see if filtering is needed. The output is seen below.

Conclusions - First and foremost, it is clear that this method of monitoring Heelstrike does work. Secondly, it is clear that this will not be not be a timing issue. However, some timing will have to be done from Heelstrike to detection. The solution might be to raise the threshold. Finally, it is also clear that there are not large spikes that will effect detection, as long as the threshold is low enough.
Next Steps - The next step would be to order then new, higher pressure limit sensor, and to test that.

Full Heelstrike Report

_{Return To Top}

Distance Sensor

Motivation - This test was an analysis of sensor positioning as well as filtration to help identify the terrain a client is walking on. This systems uses a distance sensor to help sense objects ahead as well as steps for sensing terrain changes.

Code - Initially, the code just contained stored data in an SD card for uploading. In order to reduce spikes, a smoothing function was added to the Arduino Code. This smoothing function takes every reading per delay in between reads and puts them in an array of 5 readings. Every new reading replaces the oldest reading on the array and the array is then averaged to give the output for a gait cycle.

Procedure and Results -The three wires of a GP2Y0A02YK0F distance sensor were connected to ground, power, and output. When there was a hardware filter attached, a capacitor was also connected to the same pin as output wire and the other pin of the capacitor was connected to ground.

Using the previous gait monitor, a series of trials were performed. These trials included walking on levelground to a wall, walking on levelground, upstairs, and downstairs.

Conclusions - When the sensor is positioned correctly, changes can be detected which can ultimately predict the terrain that a test subject is walking and going to be walking on. Applying a combination of software and hardware filtering can help reduce and eliminate spikes in the data output.

Next Steps -The next step would be to analyze timing for both the distance sensing and the compression sensing.

Full Step Detection Report

_{Return To Top}

Store Gait Data

Motivation - This test looked at the feasibility of storing the gate information on the Arduino. By sorting the information in the EEPROM, the data would be saved on power down. However, it will take more time to read and write to EEPROM and therefore the timing of this procedure was very important.
Procedure - The first part of this testing was to look at where the information is going to be stored in memory. Three different pieces of information were stored. The first was the date that the EEPROM was cleared. This was to record when the information was initialized. The next two pieces of information were the researched average and the running or stored average that is updated throughout the program run time. The locations in memory are stored below: Code - The next part of the test was to write code that would clear the EEPROM. This code was called P15001_EEPROMReadWrite. The variables that are written to memory are recorded at the top and called runtime variables. The date must be manually set here. To run the code, upload it to the Arduino board and open the serial monitor. The board will then output what is stored in memory at that point. If the user wants to change the value of the memory location, they must type ‘r’ and press enter at this point. The EEPROM is then rewritten with the runtime variables.
The last part of this test was to create a function that could write and read from the EEPROM during normal code execution. This was done in a class function that can be executed during normal Arduino Code.

• Initialization - The code will set the address that is used for the gait information that will be updated. In the example, memory address 5 was used. In addition to this, serial prints enable was set.
• Read - This function inside the EEPROM class will read the gait location starting at the initialized address. It will take the two bytes of this address and create the integer that represents the milliseconds of the gait cycle. The function has no inputs and will return an integer.
• Write - This function will write and integer value to the initialized address in the EEPROM. This will split the integer into the two bytes that can be stored in EEPROM. The function has an integer input and will not return anything.

Results - The timing of this function is important. This was found using the Arduino’s on board timer. This was also done without serial writes in order to make sure that the speed is representative. The timing is recorded below.

• Read Function: < 1ms
• Write Function: 4ms
• Read Function and arithmetic operation and Write Function: 4ms

Conclusions - It is clear from above that the write function timing is the limiting part of the functional of the EEPROM. However, because the current sampling time for the distance sensor is 50ms, this time would be not be so large a time that the EEPROM is not an appropriate solution. In fact, this test proves that the EEPROM is a good solution to storing gait data from run to run.
Next Steps - Continue to use this code in testing and create more functions as needed.

Full EEPROM Report

_{Return To Top}

Low Battery through Arduino

Motivation - This test was to set up a prototype of a system that would provide a low battery alert. This system will work through the Arduino. When completed, this system will poll the battery, sound an alert, and change the Arduino to low power mode.
Procedure - TThe first part of this testing was to connect the Arduino. This was done by connecting a resistor divider to the battery output (the voltage of the battery should be more than 5V which is max of what the ADCs could read). A capacitor was also attached to do some low pass filtering.
Code - The rest of the test was to create a function that will test the value of the ADC input and compare it to a tolerance.

• Initialization - The code will set the ADC that is monitoring the sensor. The tolerance level will also be set that will decide if the battery is getting too low. In addition to this, serial prints enable was set.
• Low- This function looks at the value of the ADC and returns a true or false of if the battery is getting too low. The function has no inputs and will return a Boolean.

Results - The timing of this function is important. This was found using an oscilloscope and looking at the output. This will show the level that the battery is at and also the rise time that will happen at a transition of turning the battery off to on.

Conclusions - First and foremost, it is clear that this method of monitoring low battery does work. Secondly, it is clear that this will not be a timing issue and that filtering is not needed. It will be important to look at a sagging voltage and decide on the threshold then.
Next Steps - The next step would be to order or obtain an audio alert that will work with an Arduino. Also, the output should be monitored with the battery that the team plans on using.

Full Low Battery Through Arduino Report

_{Return To Top}

Low Battery through Zener Diodes

Motivation - This test was to set up a prototype of a system that would provide a low battery alert. This system will work with an all hardware circuit consisting of resistors and zener diodes. When this system is working, it will set off an LED or a buzzer representing a low battery. Procedure - After doing some research, the first part of this procedure is doing some software testing. A low battery schematic was designed, built and tested on Multisim circuit designer. A layout of the schematic is shown below consisting of two resistors, two zener diodes, and an LED. Zener Diode Layout - In order to decide how much voltage layout that the LED should light up, a zener diode layout would be used to set a threshold that would allow current to flow. When that threshold voltage is reached, current will flow through the zener diode. At D2, the voltage is rated at 3.3 V. D4 and D3 consist of a 5.1 and a 3.3 volt zener to set an 8.4 volt threshold for current.

Resistor Layout - Two .25 K ohm resistors were selected to allow enough current to flow through the LED so that it lights up whenever voltage is between 8.4 and 3.3 volts.

Results - For the schematic, the LED had lit up when it fell between the Zener diode voltage range. On the hardware test, the LED had lit up when power voltage had fallen to 5 volts which is still close to the actual level generated on the schematic.

Conclusions - It is very clear that using all hardware for detecting low battery works. Using this method of monitoring a low battery can save some Arduino coding and allow the battery to be constantly detected as opposed to detecting it on and off when using software.

Next Steps- The next step would be to design and test a desired threshold depending on what power source the team plans on using. Additionally, a buzzer going off can be much simpler to detect a low battery as opposed to watching for and LED to light up.

Testing Videos
Low Battery Test 1
Low Battery Test 2

Full Low Battery Through Zener Diodes Report

_{Return To Top}

Solenoid Control

Related System: CAIR, Actuate muscle
Can a solenoid be controlled by an Aurduino to actuate air flowing into and out of the muscle?
Testing Procedure and Results:
A double A battery pack consisting of four double air batteries was put in series with a 9V battery producing 12V in order to power a solenoid valve in the lab. A solenoid was actuated by touching the contact of the solenoid to that of the battery, powering the solenoid opened the valve and then disconnecting the contacts to un power the solenoid closed the valve. Pressurized air at a miscelanious pressure was applied to the solenoid. The solenoid that was tested was not a two port three wat solenoid like the one desired for the orthotic so one of the ports had to be plugged to produce our desired functionality. using simple circuit consisting of a transistor, diode and 1k resistor we were able to control the state of the solenoid by outputting a high or low out of the Aurduino, proofing functionality.
To control the solenoid with the Aurduino the robotic fish team was consulted with how they controlled their solenoids along with research completed of circuit diagrams to control the solenoid.
Conclusions:
A 3-way normally closed solenoid valve is needed to actuate air into the Mckibben muscle. A transistor controlled by the Aurduino can power the solenoid on and off along with diode to protect the diode form any kick back current.
Next Steps
-Look into desired hold state at low pressure
-CAll SMC to specify project specific diode
-Explore use of exhausted air with Tyler

Testing Video
Solenoid 5V Control

_{Return To Top}

Mechanical Testing

Muscle Deflection

Related System: Raise Foot, Hold Foot

The reason for this test is to find:
a.) How far does the muscle need to contract to raise the foot to the desired position?
b.) Does the moment arm length have a significant effect on the contraction length?
c.) Is the deflection needed feasible for our preliminary air muscle designs?

A summary of the theory behind the test is shown below:

Test Set up and Procedure:
Our main goal for this test was to simulate the function of the McKibben muscle that will be used on our final design and determine how much the muscle must deflect to ensure the foot is raised to the appropriate position. 4 straps were secured to the foot and lower leg to simulate the function of our AFO. A fishing line tether was attached to the strap that was on the middle of the foot, where we plan on tethering our muscle to raise the foot. The finishing line was then run underneath the other 3 straps to simulate the tether of our device. A reference mark was made on the tether to measure the distance the tether deflects.

The tether was pulled tight along the user's leg, with the user's foot hanging in the natural downward position. The user the manually raised his foot to the upward position, creating slack in the tether. The tether was then pulled tight again, and the distance the reference mark traveled was measured to determine the deflection needed from the air muscle.

A picture of our test setup is shown below:

Many more details can be found in the Report

Results & Conclusions:
Our test answered all the technical questions we wanted to answer through the test:
a.) The air muscle must contract 1 inch to raise the foot to the upright position.
b.) The level arm length does not have a significant impact on the distance the muscle must contract.
c.) The 1 inch deflection needed is feasible for our preliminary muscle design.

Next Steps
This test is completed, but will pair and feed directly into future testing:
-Results will be paired with results from the force it takes to raise the foot test from Phase 2
-Both test results will feed into our Muscle Optimization Design testing
-Results will drive our final McKibben Muscle Design.
Full Muscle Deflection Report

_{Return To Top}

Muscle Optimization Stage I

Related System: CAIR, Actuate muscle
The reason for this test is to find:
a.) What supplies are needed to make an air muscle?
b.) How can we regulate the pressure?
c.) What is the relationship between strain and pressure?
d.) What is the relationship between force and strain?
e.) What is the relationship between strain and size?
f.) What are the next steps for muscle optimization stage II?

Test Set up:
Two muscles were testing in this phase. The first (M1) was an orange muscle that was constructed in house with supplies on hand in the BAD Lab. The second (M2) was a longer Red muscle that was found pre-made in the Lab. A series of six tests were conducted using two muscles and three weight configurations. The image below depicts the test setup where the initial height from the floor (H_0psi) was measured separately for each test and used as a reference for corresponding displacements:
Testing Procedure and Results:
The tests were performed by varying the pressure and measuring the height. There is little deflection from 0-30psig so measurements began at 30psi and then increased by 5 or 10psi. The absolute deflections were calculated for each configuration and the results were plotted against the corresponding pressures.
Many more details including the BOM, visually friendly plots, and a descriptive analysis can be found in the Report
Conclusions:
a.) The team now has an understanding of the necessary supplies and components which ultimately affects the BOM.
b.) The team learned that there are functional pressure regulators in the BAD Lab that can be quickly connected to the shop air tank.
c.) After 30psig the strain increases dramatically with pressure as shown in the plot.
d.) Strain decreases with force as observed in the plot.
e.) Strain increases with size as observed in the plot.
Next Steps
-Identify Needs from Other Tests

• CAIR Tank Regulation and Capacity test
  
  • Need: Pressure ceiling
    
  • Need: Volume limitations & model confirmation
    
• Lower Foot Attachment Test
  
  • Need: Local fabric strain
    
  • Need: Actual lifting force required
    
• Upper Foot Attachment Test
  
  • Need: Local fabric strain
    
  • Need: Force ceiling
    

-Design Muscle:

• Iterate muscle design from constraints above and identify the following parameters:
  
  • Length
    
  • Width
    
  • Force
    
  • Strain Capacity
    
  • Operating Pressure
    
  • Plug and fitting specs
    

-Construct and Test Optimized Muscle

• Construct and test to identify further iteration opportunities.
  

Full Muscle Optimization Stage I Report

_{Return To Top}

Upper Muscle Attachment

Related System: Raise Foot, Secure Foot

The reason for this test is to find:
a.) Where is the best place to tether up upper end of the McKibbon muscle?
b.) How much force can each attachment method support>
c.) How much force does it take to make the brace slip for each attachment method?
d.) How much force does each attachment method provide?
e.) What attachment method will be needed to counteract the reaction force from the McKibbon muscle while it is raising the foot?
f.) What are the next steps for upper muscle attachment design?

A free-body diagram of the forces associated with the upper muscle attachment is provided below:

Test Set up:
Four different iterations of this test were performed to determine the amount of force each attachment provided.

First, an existing brace was used to determine the amount of force it could withstand. This brace has been previously used on the lower leg for Jared's terrain sensing project. This brace provides compression force by Velcro straps in the back of the brace. The brace was tested with 3 different attachment methods:

1) with the attachment at the top of the brace;

2) with the attachment 2 inches below the top of the brace;

3) with the attachment 2 inches below the top of the brace, along with an additional securing strap at the top of the brace.

Also, an athletic neoprene compression sleeve was tested for its performance, as well as a walking test for the current brace supplied.

Testing Procedure and Results:
Different tests were performed for each testing setup. First, the maximum force it took to create separation between the brace and the leg when pulling directly outward was found, testing the compression force of the brace. The maximum force the brace could withstand when pulling directly down without slipping was found for each attachment position as well, simulating the performance of the McKibbon muscle. After this force was found, it was applied 100 additional times to determine the slippage the occurs from this force. The maximum force to create slippage in the athletic compression sleeve was found as well.

For the walking test, 100 steps were taken, and the slippage after these 100 steps was measured.

A summary of the maximum force results for the four different setups is shown below:

Many more details including the BOM, visually friendly plots, and a descriptive analysis can be found in the Report

Conclusions:
a.) The team now has an understanding of the necessary supplies and components which ultimately affects the BOM.
b.) The team learned that pure compression from a neoprene sleeve will not be sufficient to support the function of the air muscle.
c.) The team learned that the muscle will need to be tethered at least 2 inches below the top of the brace, as the top of the brace did not withdstand strong pressures.
d.) The team learned that adding an additional secure strap at the top of the brace increased the maximum amount of force it took to create slippage at the top of the brace significantly.
e.) The team learned that the existing brace does not slip significantly during a normal walking routine.

Next Steps
-Iterate test when final air muscle size and performance determined
-Begin to look at ways to secure the brace to the leg with an additional, non elastic strap at the top.
-Begin to consider the comfort of the system designed for the upper muscle attachment, as well as securing the brace to the leg.
Full Upper Muscle Attachment Report

_{Return To Top}

Lower Muscle Attachment

Related System: Raise Foot, Secure Foot

The reason for this test is to find:

a) Where on the lower base should the McKibben muscle be attached?

b) How much force does it take to lift the foot with an ankle brace?

c) How should the Mckibben muscle extender be attached to the lower base?

d) Does the brace remain comfortable when a force is applied? Are there any specific ways that the force is applied that causes the brace to be uncomfortable or constrict blood flow?

A free-body diagram of the forces associated with the lower muscle attachment is provided below:

Test Set up
During this test, 2 different test setups were used (Figure 1 and Figure 2).
Setup 1: In this setup, the volunteer is wearing an ankle brace with a piece of fishing line sewed into the end of the brace. The volunteer’s leg is held to the base of a table using 2 Velcro straps, one placed right above the volunteer’s ankle and another placed around the mid calf region. This ensures that the volunteer’s leg remains still during the test in order to obtain the most accurate force values.

Setup 2: In this setup, the volunteer is also wearing an ankle brace with a piece of fishing line sewed into the end of the brace; however, the force is not applied on the brace directly. The fishing line on the brace is tied to a rigid Velcro strap that is wrap around the volunteer’s foot, near the toes. Another piece of fishing line is tied to the Velcro strap and will be used to apply a force. Similar to setup 1, the volunteer’s leg is tied to the base of a table using 2 Velcro straps, one placed above the volunteer’s ankle and another placed around the mid calf region. This ensures that the volunteer’s leg will remain still during the test in order to obtain the most accurate force values.

Procedure
Two separate setups were utilized yielding a total of two tests. However, both setups followed the same test procedure, which is outlined below:

1. Using a spring force gage, a team member will lift the volunteer’s foot

2. Volunteer announces when their foot is at a 90 degree angle and team member will stop applying a force

3. The team member will read aloud the resulting force from the force gage

4. The test volunteer will record the results

Results:
Setup #1:

* Brace is crimping because most of the force absorbed by brace

* First 1.5lbs of force is transmitted to brace

* Moment arm at start of test: 4.75inches, Moment arm at end of test=2.9inches

Setup #2:

Refer to the Results section of the following for further results: Full Lower Muscle Attachment Report

Conclusions:
a.) Where on the lower base should the McKibben muscle be attached?

On top of foot, near the toes (approximately 1 inch away)

b.) How much force does it take to lift the foot with an ankle brace?

According to our results, it will take approximately 7lbs of force to lift the force. From previous tests, we believe that the necessary applied force can be lowered. Specifically, in the previous test it took 5.0lbs of force to lift a foot with a sock. Our follow-up test will be addressing this question.

c.) How should the Mckibben muscle extender be attached to the lower base?

The muscle extender should rest on the top of the base/brace and strung through inelastic loop holes in order to avoid contact with a user’s shoe.

d.) Does the brace remain comfortable when a force is applied? Are there any specific ways that the force is applied that causes the brace to be uncomfortable or constrict blood flow?

In this test, the brace was not comfortable because it was very tight. It needed to be wrapped tight in order to withstand the necessary applied forces. This issue will be addressed in a follow up test, outlined below.

Next Step

• Complete a follow up test
  
  • Test will address the issues identified by stage 1 test
  • Specifically, test will need to include a more rigid attachment point since it was determined that the brace is too elastic to withstand the necessary applied force.
    

Full Lower Muscle Attachment Report

_{Return To Top}

CAIR Capacity Test

Related System: CAIR, Actuate muscle
The reason for this test is to find:
a.) How accurate is the CAIR Capacity calculations model?
b.) How does the output pressure/strain behave during testing?
c.) Can we get a working refined model for POC?

Test Set up:
P15001 Muscle #2 (M2) was chosen for testing in this phase. M2 is larger than our expected optimal design but the size was ideal for this test since the large dimensions reduce the risk of measurement errors. The test rig was setup as shown in the figure below:

Testing Procedure and Results:
The outer diameter of the inflated muscle was found to be 2/32in. The test was performed by taking initial measurements and operating at a pressure of 60psig as controlled through an additional regulator. The muscle was flexed, held for 1-3seconds, and released via a push button on the breadboard connected to a solenoid. Length and pressure measurements were taken every 25 cycles to ensure consistency. The steady state pressure varied from 58psi to 61psi and the strain varied by + or - 1/16in. At approximately 690 cycles the pressure began to decrease quickly due to tank exhaustion. A small leak was occasionally heard coming from the regulator.

As shown in the table above, the initial conditions were inserted into the original, calculation model and produced reasonably similar results.

Conclusions:
a.) The model shows reasonable accuracy to the test results
b.) There is very little output pressure or strain variation during testing
c.) A refined estimation model can be produced using the correction factor for further POC and testing

Next Steps
-Use the model in muscle optimization stage II
-Use the model to determine the benefits of a 4500psig tank if necessary
-Confirm model in long term testing

Testing Videos
Tank Capacity Test Rig
Tank Capacity Test Rig Regulator

Report Sheets From Excel
Report sheet
Optimized Length sheet
Optimized Length 4500 psi sheet

_{Return To Top}

CAD Models

In the subsystems phase, previous CAD drawings completed on McKibbon muscle were looked into. The end plugs for the McKibbon muscles must be machined, and there are many drawings that we could alter to get these machined. A sample drawing, as well as a sample McKibbon muscle drawn in SolidWorks, are shown below.



_{Return To Top}

Long Term Plan MSDII

_{Return To Top}

Build, Assembly, and Debug Plan

Debug Plan
Electrical:The following section will outline how the different sections of the electrical side of the project, specifically the code, will be debugged during testing. Overall, the code has enabled serial prints. For most of the debug, this will be enough as long as the arduino can be connected to the computer.

• Gait Information Storage:The EEPROM can be read at any time by uploading the code that reads the EEPROM. This will read all the addresses that are being used in this system. If the EEPROM needs to be cleared, this can also be done here. During normal code operation, the serial prints will output what is being read from the EEPROM and what is being written to the EEPROM
• Heelstrike Sensing: The Heelstrike sensor is just a variable resister and can be monitored during operation. As for the code, when the serial writes are enabled, the output of the ADC can be monitored and also the output of the function of if there has been a Heelstrike. If the delay is too large from Heelstrike to when the output is seen by the arduino, then a resistor divider can be used. This will change the threshold in the code, but that is a simple change.
• Distance Sensing: The distance sensor also has a serial output function that will display what the Distance sensor sees. This is more difficult to use because the distance sensor should be monitored during movement. This is overcome by attaching the SD card which can save the output of the distance sensor. This can be examined after a run.
• Low Battery Alert: The low battery alert also has serial writes that will output the information from the ADC to the serial monitor. If they system is not detecting a low battery alert soon enough, the threshold in the code can be changed. If the alert is spiking, then more filtering can be used. If the input to the ADC is too high, a different resistor divided can be using.

_{Return To Top}

Bill of Materials

_{Return To Top}

Risk Assessment

_{Return To Top}

References

• Average American's Steps - NY Times
• ATmega328 Microcontroller Datasheet
• GP2Y0A0YK IR Long Distance Measuring Sensor
• Aurduino solenoid control
  

Regulator Resources

• Regulating Paintball Tank Pressure
• Air Myth Paintball Regulator

Past Projects

• P12029 - Robo-Ant: Untethered Air McKibben Muscles
• P13001 - Active Ankle-Foot Orthotic: Tethered Air Muscle
• P13002 - Ankle-Foot Orthotic Un-Tethered, Mechanical
• P14029 - Robotic Fish Powered by Hydraulic McKibben Muscles

_{Return To Top}

Subsystems Review

The following agenda was used during the technical review on October 23.

The following action items were taken into consideration during the technical review on October 23.

_{Return To Top}

Home	Planning & Execution	Problem Definition	Systems Design	Subsystems Design	Detailed Design	Gate Review
MSD I	Team Members & Roles Project Plan Meeting Minutes, Notes, & Actions Team Values and Norms	Project Summary Use Scenario Customer Requirements Engineering Requirements Concerns and Risks Problem Definition Review	Functional Decomposition Morphological Chart Pugh Chart System Design Performance Limits Risk Assessment System Design Review	Phase Planning Electrical Testing Mechanical Testing CAD Models Build, Assembly, and Debug Plan Bill of Materials Risk Assessment Subsystems Review	Phase Planning Mechanical System Concept Electrical System Concept Bill of Materials Risk Assessment Detailed Design Review	Phase Planning System Design Bill of Materials Build, Assembly, and Debug Plan Electrical System Concept Mechanical System Concept Risk Assessment Gate Review
	Build Preparation	Build & Test	Integrate & Assemble	System Validation	System Verification	Final Review
MSD II	Phase Planning Imagine RIT Shared Vision MSDII Test Plan Problem Tracking	Phase Planning Engineering Requirements Problem Tracking Mechanical Build Integrated Prototype Electrical Build	Phase Planning Engineering Requirements Problem Tracking Updated System Design Electrical Build Nazareth Clinic	Phase Planning Engineering Requirements Problem Tracking Updated Board Design Wearibility Testing Nazareth Clinic Imagine Deliverables	Phase Planning Engineering Requirements Problem Tracking New Muscle Testing RIT Subject Testing Imagine RIT	Performance vs. Requirements Budget Tracking Electrical Design Mechanical Design Assembly and Build Plan Next Steps