Table of Contents
|
Phase Planning
Shared Phase Vision
Our vision for this phase is to demonstrate Critical Subsystems feasibility. Our current critical subsystems are defined as:- Distance and heel strike sensor
- Electrical control of air muscles
- Secure foot – Lower
- Secure foot – Upper (Air muscle attachment)
- Air muscle lift / operating pressure
- Air Tank for a full day
Key related technical questions include:
- 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?
- Can we control the air using electrical components? Can we do that using just an Arduino? Will we need level shifters?
- How and where to apply torque? What possible materials to use? Ergonomics?
- How and where to attach muscle? How much force can it support? Is it safe?
- How much force can we produce? What is the operating pressure range?
- 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
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 muscleCan 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
Mechanical Testing
Muscle Deflection
Related System: Raise Foot, Hold FootThe 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
Muscle Optimization Stage I
Related System: CAIR, Actuate muscleThe 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
- Need: Pressure ceiling
- Lower Foot Attachment Test
- Need: Local fabric strain
- Need: Actual lifting force required
- Need: Local fabric strain
- Upper Foot Attachment Test
- Need: Local fabric strain
- Need: Force ceiling
- Need: Local fabric strain
-Design Muscle:
- Iterate muscle design from constraints above and
identify the following parameters:
- Length
- Width
- Force
- Strain Capacity
- Operating Pressure
- Plug and fitting specs
- Length
-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 FootThe 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 FootThe 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 muscleThe 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
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.
Bill of Materials
Risk Assessment
References
- Average American's Steps - NY Times
- ATmega328 Microcontroller Datasheet
- GP2Y0A0YK IR Long Distance Measuring Sensor
-
Aurduino
solenoid control
Regulator Resources
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
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.