KGCOE MSD Page 1 of 62 Technical Review Agenda
KGCOE MSD Technical Review Agenda
Meeting Purpose: Detailed design review for Smart Walker II (P14041.) The purpose of this meeting is to
present the final design of the system for entering into MSD II and receive feedback on the
proposed design.
Meeting Date: May 13, 2014.
Meeting Location: James E. Gleason Hall (09) - Rm. 4435
Meeting Time: 14:00 (2:00 PM)
Meeting Timeline
Time Topic of Review Required Attendees
Introduction Project Overview
Project Background
Problem Statement
Customer Needs / Engineering Requirements Matrix
Intended Deliverables
Risk Assessment
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez,
Mechanical Engineering Complete Walker Design
Mechanical Analysis
Strain Gage Placement Handle
Strain Gage Placement Seat
Motor Shafts
New Design Concepts
Backrest w/Integrated Camera
Xtion Mount
Micro-Controller Housing
Basket w/Micro Housing
Wheel Shroud
Clutch Design
Motor/Clutch Integration
Motor/Clutch/Wheel Assembly
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez,
Electrical Engineering High-level wiring diagram
Schematics and Component Information
Power Distribution
Strain Gage Measurement / ADC
Motor Driver / Motor Interconnections
Main Control Unit Components and Interconnections
Inertial Measurement Unit
TI ez430 Chronos
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez,
Computer Engineering Software Design
Interprocess Communication for Fall Detection
Library Selection
Software Verification
Data Formates and XML Report
Concerns about SLAM
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez,
KGCOE MSD Page 2 of 62 Technical Review Agenda
Appendix Bill of materials
MSD I to II schedule
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez, Prof. Indovina
Introduction
Project Background The “smart walker” is a mobile robotic system aimed at assisting the elderly who use a regular walker during their daily
lives, capable of collecting information about an individual’s health and functionalities. This will enable the patient’s
caretakers to carefully monitor their health from a remote location and even make preemptive healthcare decisions. There
have been other “smart walkers” researched, but the struggle has been to develop one which is unobtrusive and appealing
to a user. Previous attempts at designing a “smart walker” have been deemed too “robot-like” to be accepted by users.
Problem Statement The current Smart Walker prototype has been deemed too bulky and obtrusive for use in assisted living facilities. The goal
of Smart Walker II is to design a walker with the capabilities to collect information about the user’s health and
functionalities (heart rate, temperature, etc.) without appearing robotic. The walker will be designed to be mobile, semi-
autonomous, and able to prevent and detect falls, and be capable of locating patients in its immediate environment.
KGCOE MSD Page 3 of 62 Technical Review Agenda
Customer Needs / Engineering Requirements Matrix
Eng Reqs / Cust
Reqs
CR01:
Sys must
be quiet
CR02: Utilize
previous team's
resources
CR03: Sys
must be
robust
CR04:
Must look
"stock"
CR05: No
resistance to
user's
movements
CR06:
Able to
detect
falls
CR07: Able
to detect
when in use
CR08: Seamless
software
integration
CR09: Must
have robust
mtr/cltch sys
CR10: MDs
should get
concise
reports
CR11: Able to
localize and
map environ
CR12: Able to
predict
pressure sores
CR13: Able
to manually
brake
CR14:
Rechargeable
pwr sys
CR15:
Must be
light
weight
CR16:
Minimize
pwr losses
CR17:
Minimize
odometry
errors
CR18: Readily
reprogrammable
ER01: Minimize
motor noise
ER02:
Maximize mic
sensitivity
ER03:
Maximize mic
direc accuracy
ER04: Minimize
wheel resistance
ER05:
Maximize
Battery life
ER06: Minimize
Emrgcy
response time
ER07: Minimize
sys mass
ER08:
Maximize
braking force
ER09: Handle
sensitivity
ER10: Conceal
elec/mech sys
ER11: Unify
software
ER12: Design
mtr/cltch
housing
ER13: Exrt data
in hmn-
readable fmt
ER14: Ensure
SLAM
capability
ER15: Detect
pressure on seat
ER16: Use
redundant
odometry sys
ER17:
Accessible for
future research
Figure I.1 - Customer needs / engineering requirements fulfillment matrix
KGCOE MSD Page 4 of 62 Technical Review Agenda
Customer
Requirements
Priority Values ( 1-Low, 2 - Medium, 3 - High)
Customer
Req #
Priority Description Comments/Status
CR01 3 Reduce/ Eliminate noise from motors while walker
is in "manual mode"
This was added per Sub-System design review. Clutch system was initially thought to be for the
purpose of disengagement of the motors to reduce wear and extend motor life. Customer
clarified they were more concerned with the noise from the motors.
CR02 1 Set up External Microphone Array to connect to
PC and IR Thermal Camera for External Fall
Detection/ User Location
This was initially thought to not be a requirement, but instead a "would be nice" customer
request. Still need further clarification of exact deliverables associated with this.
CR03 3 System must be robust and able to withstand
everyday use
ALL components need to be able to withstand further testing, use, and demonstrations
CR04 3 Conceal systems within the frame of the walker. Walker must look "Off the shelf." Components should not be obtrusive to the user
CR05 3 Motors must not resist the manual movement of
the wheels.
CR06 3 System must be capable of detecting a user's fall
and executing a recovery routine.
Multiple redundant detection/alert systems working in tandem.
CR07 3 System should be capable of determining presence
of a user based on handle interaction.
Include sensor/strain gages on handles
CR08 3 Unify software subsystems and bring them to an
acceptable operational level.
CR09 2 Redesign motor and powertrain system.
CR10 3 Software should compile necessary info into a
readable file to be sent to customers
XML formatted and sent once-a-day regularly, and immediately in the event of a fall or medical
emergency
CR11 3 SLAM Capable Handled by ASUS Xtion Pro Live and previously developed algorithms
CR12 2 System must be capable of predicting pressure
sores.
CR13 2 System should be able to brake the wheels on user
input.
Manual cable breaks included in walker frame.
CR14 2 Make power system rechargeable and user
friendly.
CR15 1 System should be light weight.
CR16 1 System should have minimal power loss when
idling.
Converter selected for high efficiency, redundancy will be required to make sure that there is no
excess current draw during normal operation
CR17 3 Odometry handled via a combination of IMU and
encoder feedback
Encoders coupled to wheel motors, IMU pre-packaged and readily interfaceable
CR18 3 System must be readily reprogrammable System must be capable of being accessible on both the hardware and software side
KGCOE MSD Page 5 of 62 Technical Review Agenda
Engineering Requirements
Eng
Req #
Cust.
Req #
Description Unit of Measure Marginal Target Comments/Status Owners
ER01 CR01,
CR05
Reduce Motor Noise While in Manual
Mode
dB Clutch Design / New gearing; Currently being
designed and prototyped
Anthony, Noah
ER02 CR02 Microphone sensitivity dB 40 15 To be tested Kelsey, Trevor
ER03 CR02 Microphone directional accuracy m 1 0.1 To be tested Kelsey, Trevor
ER04 CR01,
CR03,
CR05,
CR09
Motor resistance on wheels Nm 0.25 0.01 Clutch Design/ New Gearing Noah, Anthony
ER05 CR14,
CR16
Battery life Hours 4 12 Power subsystem design mostly complete Kelsey, Trevor
ER06 CR06 Response time to fall s 60 30 Handled primarily via ez430 Chronos and other
redundant systems
Alex, Dan,
Kelsey, Trevor
ER07 CR03,
CR15
System mass kg 20 5 Noah, Anthony
ER08 CR13 Braking force N 10 20 Manual brakes already installed on system Noah, Anthony
ER09 CR07 Handle sensitivity kg 2 0.25 Handled via frame strain gauges Noah, Anthony,
Kelsey
ER10 CR04 Conceal Walker Components cm Rubber Grommets on frame to protect wires; New
seat back to allow more room to hide components;
New housing for motors
Anthony, Noah
ER11 CR08 Unify software systems Packet loss Communication between various controllers and
lower level systems
Alex, Dan
ER12 CR09 Motor housing/ mount; Clutch cm Design to be less obtrusive; measurement based on
protrusion into walkway
Anthony, Noah
ER13 CR10 Human-readable XML report Reports generated 1/week 1/day Special report generated on medical emergency Alex, Dan
ER14 CR11 SLAM-capable camera system Camera resolution Handled by ASUS Xtion Live Pro Alex, Dan,
Kelsey, Trevor
ER15 CR12 Strain Measurement in seat length/length Handled by strain gages in seat. Measures
displacement
Kelsey, Noah,
Anthony
ER16 CR17 Odometry error measurement m 0.1 0.05 Handled through Arduino+Encoders+IMU Kelsey, Trevor
ER17 CR18 Accessibility to control systems # of
reprogrammable
hubs
1 3 Microcontroller housing and design Anthony, Noah,
Alex, Dan,
Trevor, Kelsey
KGCOE MSD Page 6 of 62 Technical Review Agenda
Risk Assessments
Description Effect Cause L S I = L*S Owner(s) Response
RISK01 Patient unable to call
for help
Walker is not aware patient is
in danger
Heart attack, stroke, seizure, etc. 2 3 6 Trevor Build in redundancies to user
detection
RISK02 Walker falls over Patient is immobile Unstable walker design /
implementation
1 3 3 Noah,
Anthony,
Kelsey,
Trevor
Mechanical robustness and
walker fall-detection subroutine
RISK03 Loss of walker power "Smart" elements of walker are
disabled
Poor battery life, lack of reminders for
user to recharge
3 2 6 Kelsey,
Trevor
User feedback on battery levels
RISK04 Loss of watch power Watch is disabled, user unable
to call for help
Remote functions and fall detection
disabled
1 3 3 Kelsey,
Trevor
Alerts once watch battery drops
below certain level
RISK05 Breakdown between
mechanical and
electrical components
Mechanical components
damaged
Control system crashes 1 3 3 All Build in total system redundancy
and failsafes
RISK06 Delay on target MCU
development
Might not have the target
MCU on time and have to
reevaluate for a different MCU
Pandaboard ES out of stock
everywhere
3 2 6 Alex, Dan Worst case is to switch to a
regular pandaboard that is not as
powerful
RISK07 Clutch not able to be
implemented
Motors stay engaged and are
not able to freewheel. Noise
from motors continues even in
manual mode.
Size constraints, inability to find
available clutch in the marketplace,
Custom designed clutch does not
function as designed.
2 2 4 Noah,
Anthony
Create working prototype before
MSD II for testing purposes. If
clutch system fails, move to noise
reduction.
RISK08 algorithm that doesn't
meet our design specs
the software will not run as it
would be expected
Us not developing the algorithm 2 3 6 Alex, Dan Communicate with the person
developing the algorithms. RISK09 Wheel shroud impede
in walking path
The coverings for the motors
extend to far into the walking
path causing a tripping hazard
Size constraints to cover the
motor/clutch housing.
2 2 4 Noah,
Anthony
Design shroud with tight
tolerances around the wheels.
Redesign motor mount if
necessary.
KGCOE MSD Page 7 of 62 Technical Review Agenda
Current Walker Design: As seen below in Figure ME.01, the current walker is a Hugo Model 700-957. Off the shelf it comes with manual cable
hand brakes, a flip up seat, and a “basket” underneath the seat to store personal belongings. The goals of the Mechanical
Engineers is to meet the customer requirements while maintaining as much of the stock walker appearance and
functionality as possible.
Figures ME.01-03
KGCOE MSD Page 8 of 62 Technical Review Agenda
High-Level System Interconnect Diagram
Figure E.1a - High-level system interconnect drawing
KGCOE MSD Page 9 of 62 Technical Review Agenda
Figure E.1b – Electrical system interconnect drawing
KGCOE MSD Page 10 of 62 Technical Review Agenda
Strain gages:
Pressure Sore Measurement (CR12, ER15)
One of the customer requirements to detect pressure sores in a patient. We found the best means of accomplishing this
task is to determine the likelihood of a patient developing pressure sores. Pressure sores typically develop on patients who
have become stagnant and remain motionless for long periods of time. By observing how often the user moves over time,
a caregiver can determine the risk to the patient developing pressure sores. We will integrate a measurement system into
the walker to determine how often the patient moves when seated by measuring their center of mass using strain gages
hidden in the seat.
Strain gages function by measuring the strain on an object, the mechanical strain is converted to an electrical resistance
which changes linearly with strain. When used with a wheatstone bridge, greater strain will result in a greater voltage
difference so an equation can be determined. This equation will be determined later through calibration when the
components are available and constructed. The following figure shows the stress-strain distribution on the beams which
the strain gages will be attached to.
Figure ME.08 – Beam von-Mises Stress/Strain
KGCOE MSD Page 11 of 62 Technical Review Agenda
A plate will be added beneath the seat which will connect to the cushion by four load sensors mounted at each corner.
These load cells are made up of a beam sandwiched between two strain gages. When a load is applied to the seat, the
beams will bend linearly and sensory information from the four pairs of strain gages will determine the weight applied at
all four corners. Using the algorithm in figure ME.06, the position of the user’s center of gravity will be polled and any
change in its location will be noted. Applying this data, a caregiver can observe potential early warning signs that a
person is more likely to be stationary which will allow them to take precautions against pressure sores.
Figure ME.05 – Seat Placement
[
1 1 1 10 0 𝐿 𝐿0 −𝑊 −𝑊 0
−𝐿 −𝐿 0 0𝑊 0 0 𝑊]
∗ [
𝑅𝐴
𝑅𝐵
𝑅𝐶
𝑅𝐷
] = 𝐹
[
1𝑦
−𝑥𝑦 − 𝐿𝑊 − 𝑥]
Figure ME.06 – C.O.G. Measurement
KGCOE MSD Page 12 of 62 Technical Review Agenda
Seat Instrumentation System:
As the user sits in the seat, the strain will be transferred to the cantilevers where the strain gages are attached. The strain
gages will convert that strain into a voltage. There are four cantilevers so four voltages will be collected. These voltages
will be for each corner of the seat. Those four areas can be used to determine were the patient is sitting and/or leaning.
The data can be sampled at a rate of 30 samples per second, but will be down sampled every 1 second. The data will be
processed in such a way so as to tell how often the user moves over time. The four corners will also be used to determine
the weight of the user via a future algorithm, created when the components are received, tested, and calibrated. It should
be noted that the weight of the user will not be exact since the user is sitting but the weight would be useful to use to
determine changes in weight over time.
The following figure is the circuit that will be used to retrieve the voltage for the strain gages.
Figure E.1 - Single strain gage pair circuit with instrumentation amplifier
Figure E.1 shows the desired wheatstone bridge. The wheatstone bridge is used to determine the values of the strain gages
which act as variable resistors. The resistors R3 and R4 are the representations of the strain gages on each side of the
cantilever. The placing will be such that as the cantilever has stress applied to it, the resistance in R3 will decrease while
the resistance in R4 will increase. The linearity and temperature compensation is thus proven by analysis.
𝑉𝑜𝑢𝑡 = 𝑉𝑖𝑛(𝑅2
𝑅2 + 𝑅1−
𝑅4
𝑅3 + 𝑅4)
Say that the wheatstone bridge was perfectly balanced so there is no strain and 𝑉𝑜𝑢𝑡 = 0, that means that all of the
resistors will have the same values which can be denoted as 𝑅𝑜. 𝑅3 and 𝑅4 will still have unknown variables based on the
strain as represented with x.
𝑉𝑜𝑢𝑡 = 𝑉𝑖𝑛(𝑅𝑜
𝑅𝑜 + 𝑅𝑜−
𝑅𝑜(1 − 𝑥)
𝑅𝑜(1 + 𝑥) + 𝑅𝑜(1 − 𝑥))
𝑉𝑜𝑢𝑡 = 𝑉𝑖𝑛(𝑅𝑜
𝑅𝑜 + 𝑅𝑜−
𝑅𝑜 − 𝑅𝑜𝑥
𝑅𝑜 + 𝑅𝑜𝑥 + 𝑅𝑜 − 𝑅𝑜𝑥)
It should be noted that 𝑉𝑜𝑢𝑡 = 𝑉𝑖𝑛𝑥
2 & 𝑉𝑜𝑢𝑡 = 𝐼𝑁+ − 𝐼𝑁−
KGCOE MSD Page 13 of 62 Technical Review Agenda
The strain gages are used in the wheatstone bridge to create linearity, improve output sensitivity (because there are two
strain gages), and reduce temperature sensitivity (because there are two strain gages). The two outputs from the
wheatstone bridge are sent to an instrumentation amplifier to amplify the signal so the data can range evenly from 0 to 5
volts. The data is then sent to an ADC for analog to digital conversion before going to a microcontroller for
characterization.
Table E.1 - Strain Gage Characteristics
The EA-06-240LZ-120 strains gages are the chosen strain gages to be used. These were chosen due to its cheap cost since
it is a student version, as well as the strain gages’ self-temperature compensation. The self-temperature compensation
minimizes thermal output, allowing an increase in accurate data results. It should also be noted change in resistance in
ohm of .3%. This change means that the max strain on the strain gages will result in a max change of around 1Ω from
120Ω range. This small change meant that a gain of approximately 200 is necessary to ensure a range from 0 to 5 Volts.
Table E.2 - AD8237 electrical characteristics
KGCOE MSD Page 14 of 62 Technical Review Agenda
The AD8237 instrumentation amplifier is chosen to amplify the wheatstone bridge results. This instrumentation amplifier
was chosen due to its ability to change the gain using external resistances, its micropower, zero drift, and rail-to-rail input
and output. The instrumentation amplifier is typically used for bridge amplification which was also a deciding factor
along with its benefit in portable systems. Table E.2 shows the results from those advantages as well as its ability to have
a gain of up to 1000. In general, the characteristics shown are possible concerns that could had been an issue. But the
characteristics instead show there is no need for concern. Since the data should only be specific to the nearest millivolt
concerns like the noise, offset, and output swing will not be an issue. The power supply can only handle up to 5.5V which
works with a desired supply voltage of 5V. The inputs show a temperature range, well within the expected range since
there is no expectation of having a temperature even 100 °C.
Table E.3- Recommended Gain Resistances for the AD8237
Table E.3 shows the recommended resistances that could be used to determine the gain. Typically, as long as the
resistances fit the equation below, the results will have the best output swing and linearity.
(R1 + R2) || RL ≥ 10 kΩ
Figure E.2- Single strain gage pair schematic with instrumentation amplifier
Figure E.2 shows the circuit in its schematic form with its likely connections when attached to a board. The connections
are set up so that the strain gages can be easily disconnected from the board if so desired. The same circuit configuration
will be used for the handle mounted strain gages as well.
KGCOE MSD Page 15 of 62 Technical Review Agenda
Handle Placement: (CR07, ER09)
An additional customer request was using the walker to determine how much the user is leaning when walking. This was
done by adding two more sets of strain gages to the handles to determine how much force on the left and right handles the
user is applying.
Figures ME.04-05
As seen above in Figures ME.04, the handles of the walker were modeled using ANSYS to determine the maximum point
of stress on the walker frame itself. The von-Mises stresses are shown by color, with blue being the minimum stress and
red being the max stress location on the frame. Ideal placement of the strain gages will be on the top and bottom of the
walker frame 2.3in from the bend. This will allow the handle’s to be height adjusted without damaging the sensors.
Strain Gage Locations
KGCOE MSD Page 16 of 62 Technical Review Agenda
Motor Analysis:
Existing motors on the walker have proven to be functional and operate properly allowing the walker to move and
navigate autonomously without motor failures. The motors are Pololu 50:1 Metal Gearmotor 37Dx54L mm with 64 CPR
Encoder. Analysis has been run on these motor to determine their capabilities and has proven to be accurate and able to fit
our needs. Analysis on the motors, and motor bearing, with the designed drive shaft can be found in Appendix A.
Conclusions from the analysis determined that the drive shaft was not capable of handling the load of the walker with
user. This would prove to be an issue even when the motors were not engaged, as it would be the drive shaft that would
see the load from the walker. P13041, issued corrections to these issues by changing the materials of the washer from
nylon to 1018 CD steel, and changing the shaft material from 1018 steel to a 4140 steel alloy. These corrections have
proven to work as the existing smart walker is able to support load without failing.
Proposed Walker Design:
Figure ME.11
KGCOE MSD Page 17 of 62 Technical Review Agenda
Proposed Walker Design Cont.
The proposed design brings an addition of a larger more ergonomic backrest, as seen in image ME.01. The backrest serves
multiple purposes:
1. Provides a more comfortable seat back for the user, thereby encouraging the user to sit more. This would allow
more information about the user’s weight from the seat, as well as provide more information about the users
sitting habits enabling the early detection of potential pressure sores.
2. The larger design allows for better implementation of electrical components to be hidden. The wider back allows
for wiring as well as the web camera to be integrated into the seat back, keeping the wiring hidden giving the
walker a more “stock” appearance. Wires will be run into the walker frame through rubber grommets and then run
through the frame back to the controller housing located in the basket.
Figure ME.12
KGCOE MSD Page 18 of 62 Technical Review Agenda
Xtion Mount:
The ASUS Xtion will be used to replace the Microsoft Kinect currently on the walker. Mounting of the ASUS Xtion will
be in the same location as the Kinect and mounted similarly but attaching it to the frame facing the user as seen below in
Figure ME.13. Wires will be routed through the frame of the walker into the micro controller housing.
Figure ME.13
Micro-controller/Power Distribution Housing
The design for the micro-controller housing will be a completely self-contained unit with access points for power inputs,
USB inputs, Ethernet inputs, and HDMI inputs. These inputs will allow the micro controllers to be accessed from a
computer system for analysis, reprogramming, or troubleshooting without need to remove or open the housing itself.
There are a series of vents in the sides of the housing to allow for ventilation and room inside the housing to allow for a
fan, if need be, to aid in heat transfer out of the housing.
A second benefit to this housing is that, with it being self-contained, access to everything inside can be done by simply
unplugging the inputs and lifting the entire housing out. Once out, it can easily be opened up allowing access to all the
internal components for wiring, replacing, or addition of anything new to the housing.
The housing can be 3-D printed in high resolution, using Polycarbonate plastic material. Polycarbonate was chosen for its
strength as well as its impact resistance to cracking. Polycarbonate is also an easy material to machine. This will be
important when machining the openings for micro controller ports. We have the ability to print this for free, but for
outside vendor purposes, the cost for this would run approximately $4.10/in3.
KGCOE MSD Page 19 of 62 Technical Review Agenda
The housing will consist of two halves, hinged together (not shown), that will latch on the opposite side (latch not shown).
This will allow for the proto board and power board (shown in Figure ME.14) to be housed on one side, and the micro
controllers and battery packs on the other side. Figure ME.16 shows the housing inside the basket under the seat. The size
of the housing will still allow for use of the basket.
Figure ME.14 Figure ME.15
Figure ME.16
KGCOE MSD Page 20 of 62 Technical Review Agenda
Tech Drawing ME.01 Micro/Power Housing
KGCOE MSD Page 21 of 62 Technical Review Agenda
Proposed Wheel Shroud Design:
The wheel shroud design was based around the concept of allowing the walker to maintain its “stock” appearance while
concealing the drive assembly. It will be made out of black ABS plastic, to match the other components on the walker,
and 3-D printed in high resolution. Following the profile of the wheels, it is designed to be unobtrusive to user and reduce
the risk of snagging their shoes, or cutting their feet on the motor housing.
Another purpose of the wheel shroud is to help reduce motor noise that occurs while the walker is autonomous mode. It
also serves as a contingency plan for the clutch system.
Figure ME.17 Figure ME.18
Figure ME.19
KGCOE MSD Page 22 of 62 Technical Review Agenda
Tech Drawing ME.02 Wheel Housing/ Motor Shroud
KGCOE MSD Page 23 of 62 Technical Review Agenda
Clutch Design:
To reduce unnecessary wear on the motors, as well as to reduce noise from the motors, (CR01, CR03, CR05, CR09,
ER01, ER04) a clutch system needs to be integrated into the drivetrain assembly. Due to cost constraints, the purchase of
a clutch, that fit the size, torque, and power constraints, was not an option. Several design concepts for the clutch were
made, and will be prototyped and tested for feasibility of use.
Test would be to 3-D print designs and test the prototypes within design constraints. Factors to test for functionality are:
Free spinning of disengaged side
Proper function of actuator/magnet/springs to engage/disengage the clutch
Once engaged, clutch has enough torque to handle the loads applied to it by the wheels and the motors.
The final design will be chosen based on ease of implementation, cost, ease of manufacturing, and integration into the
powertrain system.
KGCOE MSD Page 24 of 62 Technical Review Agenda
Power Distribution System:
Figure E.2 - +12 V to +5 V Buck Converter
The output of the switching regulator is determined by the following equation:
The only systems that utilize the +12 V connections are the motors and clutches, which are placed under the direct control
of the Arduino microcontroller. All microcontrollers are powered from the +5 V rail.
Table E.11 - MC34063A step-down configuration test conditions
The MC34063A has a maximum output current rating of 1.5 A. The two differing walker modes of operation will have
significantly different power requirements: while in manual mode (user has complete control of the walker) the MCU and
motor driver microcontrollers will be focused on data collection and interpretation, drawing at most 500 mA of current
1 Texas Instruments. MC33063A, MC34063A Datasheet.
KGCOE MSD Page 25 of 62 Technical Review Agenda
from the +5 V rail; while in autonomous mode (walker seeks out user) the MCU and motor driver microcontrollers will be
actively engaged in navigational and processing tasks. During this time, the MCU (Pandaboard ES) will draw a maximum
800 mA, while the motor driver (Arduino Uno with Pololu dual-channel motor shield) will draw a maximum of 200 mA.
Since the motors are driven directly from the +12 V battery, their peak and running current will not contribute to the stress
on the MC34063A IC.
Figure E.3 - Simulated switching regulator response to +12 V input
Figure E.4 - Simulated switching regulator power in and power out for transient and steady states
KGCOE MSD Page 26 of 62 Technical Review Agenda
Efficiency is calculated as the ratio of power out to power in, where the efficiency of the Buck Converter shown in Figure
E.2 approaches 99%, as shown in Figure E.4. The original Smart Walker prototype utilized a single linear regulator to
step down the battery voltage, at the cost of efficiency. Linear regulators often have power efficiency around 30%. The
Buck Converter design utilizing the MC34063A integrated circuit triples this efficiency at only a small cost to complexity
and required discrete elements.
KGCOE MSD Page 27 of 62 Technical Review Agenda
Motor and Motor Driver System:
Motor control will be handled via an Arduino Uno utilizing an Atmel Atmega16 microcontroller with a third-party, dual-
channel “shield” that attaches inline to the Arduino. The dual-channel motor controller attachment uses two
STMicroelectronics VNH5019A-E H-bridge integrated circuits. The truth table defining the logic functions for the H-
bridge IC is shown in Table E.5, where a logic high (1) is defined by a voltage greater than 2.1 V and a logic low (0) is
defined by a voltage less than 0.9 V. The schematics for the Arduino Uno and Pololu dual channel motor driver are shown
in Figure E.7 and Figure E.8, respectively.
INA INB OUTA OUTB Operating Mode
1 1 H H Brake to VCC
1 0 H L Clockwise (CW)
0 1 L H Counter-clockwise (CCW)
0 0 L L Brake to GND
Table E.52 - H-bridge truth table for normal operating conditions
The general software flowchart for the motor controller operating in autonomous mode is shown in Figure E.9. Note that
the Walker will only engage in autonomous mode when attempting to localize the user. When the Arduino receives
navigational data from the main control board via I2C, it will jump out of the idle loop and begin processing motor
driving commands.
The general motor, encoder, and motor controller interconnection schematic is shown in Figure E.10. The Pololu 50:1
metal gearmotor selected for use on Smart Walker II comes with a 64 counts-per-revolution quadrature encoder, which
allows for the motor controller to utilize dead-reckoning odometry strategies when attempting to localize itself in an
unknown environment.
Table E.6 highlights the electromechanical characteristics and maximum ratings of the motors and associated components.
Stall Torque (at 12 V) 1.2 Nm
Stall Current (at 12 V) 5 A
Gear Ratio 50:1
Unloaded Freerun Speed 200 RPM
Maximum PWM Frequency 24 kHz
Table E.6 - Electromechanical characteristics of motors and associated components
2 STMicroelectronics. VNH5019A-E Datasheet.
KGCOE MSD Page 28 of 62 Technical Review Agenda
Figure E.9 - Motor control software flowchart
The general motor, encoder, and motor controller interconnection schematic is shown in Figure E.10. The Pololu 50:1
metal gearmotor selected for use on Smart Walker II comes with a 64 counts-per-revolution quadrature encoder, which
allows for the motor controller to utilize dead-reckoning odometry strategies when attempting to localize itself in an
unknown environment.
KGCOE MSD Page 29 of 62 Technical Review Agenda
Figure E.10 - Motor, encoder, and motor controller interconnection
KGCOE MSD Page 30 of 62 Technical Review Agenda
Main Control Unit Components and Interconnections:
Figure E.11 shows the overall schematic for connecting various sensors and peripherals to the main control unit (MCU), the PandaBoard ES.
Figure E.11 - MCU interconnection schematic
J3 in Figure E.11 comes from an array of ADS7229 analog-to-digital converters (ADC.) Figure E.12 shows a typical configuration for a single ADC, where the analog input is the output of the instrumentation amplifier shown in Figure E.5.
Figure E.123 - Typical configuration circuit for ADS7229
3 Texas Instruments. ADS7229, ADS7230 Datasheet.
KGCOE MSD Page 31 of 62 Technical Review Agenda
Figure E.13 shows the timing diagram for the ADS7229 during conversion and acquisition cycles for auto-triggering
mode.
Figure E.134 - ADC timing diagram for read-while-converting during auto-triggering events
The MCU acts as the host processor for the ADS7229 array, where the 24 MHz OMAP processor system clock acts as the
input system clock for the ADCs.
Table E.6 shows the ideal input voltages and output codes for the ADS7229.
Table E.6 - ADS7229 ideal voltages and output codes
The ADS7229 also features an automatic power-down and nap mode when not in use.
4 See 8
KGCOE MSD Page 32 of 62 Technical Review Agenda
Inertial Measurement Unit:
In order to provide a degree of redundancy and error correction in the odometry readings for the navigation system, an external, 9 degree-of-freedom (DOF) inertial measurement unit (IMU) will communicate real-time acceleration, velocity, and
orientation information to the MCU via an I2C connection. The IMU to be used on Smart Walker II comes custom-built from RIT’s own Robotics Option; it relies on the STMicroelectronics L3GD20 3-axis gyroscope integrated circuit and the
LSM303DLH 3-axis accelerometer/magnetometer integrated circuit. Figure E.14 shows the slave I2C timing diagram for both ICs. The schematic for the RIT-RO IMU is shown in Figure E.15.
Figure E.145 - IMU I2C slave timing diagram
Figure E.156 - IMU Schematic
5 STMicroelectronics. LSM303DLH Datasheet. 6 Rochester Institute of Technology. 9 DOF Inertial Measurement Unit Datasheet.
KGCOE MSD Page 33 of 62 Technical Review Agenda
Texas Instruments ez430 Chronos:
The Texas Instruments ez430 Chronos is a wireless, integrated development platform based on the popular CC430
microcontroller. The Chronos, shown in Figure E.16 with USB programming and RF modules, offers sub-GHz wireless
communication capabilities along with a varied collection of biometric sensors, including: a 3-axis accelerometer, a
temperature sensor, a pressure sensor, and a battery voltage meter. Additionally the Chronos has the ability to control and
communicate with other wireless biometric sensors, such as: heart-rate monitors, pedometers, etc.
Figure E.167 - Texas Instruments ez430 Chronos with USB programming and RF communications module
For the Smart Walker II, the Chronos will be used as a way to monitor the patient, both for passive information (body
temperature) and for event-based information (an emergency.) The onboard 3-axis accelerometer will be able to detect
sudden changes in a user’s motion, indicating an emergency event, such as a fall. Figure E.17 shows the accelerometer
output under sudden-impact conditions. In the event of a fall, or similar perceived emergency, a buzzer on the watch will
sound for 15-30 seconds, where the user is given the option to cancel the alert in the situation that the alarm was false. If
the user does not cancel the alarm, a general alert would be sent out to the user’s caregivers and the Walker would receive
a command to engage in autonomous mode and seek out the user. Additionally, the user will have the ability to call an
emergency manually by pressing a button on the watch. Figure E.18 shows the Chronos’ software flowchart.
Figure E.17 - Sample accelerometer output under sudden fall conditions
7 Texas Instruments. ez430 Chronos Users’ Guide.
KGCOE MSD Page 34 of 62 Technical Review Agenda
Figure E.18 - Software flowchart for the ez430 Chronos in use with Smart Walker II
KGCOE MSD Page 35 of 62 Technical Review Agenda
In the occasion that an emergency occurred and an alert was sent out, there is an option to turn off the alert on the walker
itself in the form of a button in case the patient was taken away with the watch.
Computer Engineering
Software Design
The first iteration of the SmartWalker’s central system was a single-thread program that heavily relied on the powerful i7
processor in the SBC for consistent operation. The goal of this redesign was to create a more optimal system that would
lower the hardware requirements and cost, reduce bloat, and simplify development for future iterations.
There are many problems with having a single-thread program handling a large quantity of tasks. Data acquisition,
navigation, and vital functionality were all packaged in the same thread. The immediate concern with this was the
navigation algorithm. A SLAM algorithm, such as the one to be implemented on this walker, generally would be given a
dedicated core on the processor due to the intensive processing requirements and need for precise timing. To circumvent
this issue, our system was designed as a multi-process system. Data acquisition is divided amongst four different
processes; one for Chronos data, one for the heart rate algorithm and webcam, one for strain gage data, and the main
process which takes encoder data during navigation in “Autonomous mode” for use within the SLAM algorithm. Initially
it was planned that the navigation algorithm would be forked off of the main process when needed, but after later designs
moved a majority of the data acquisition to separate processes within the OS, it was decided that navigation would simply
remain within the main program. By increasing code parallelism in this way, the hardware requirements of the system
were cut down significantly, allowing the use of the Pandaboard ES, which utilizes an ARM 9 dual core chip. This board,
chosen from a group of 4 candidate boards in a Pugh matrix for its powerful CPU and wide array of I/O options, delivers
the necessary computing power at a fraction of the cost and physical profile of the previous system’s main computational
device.
Raspberry Pi
(Model B rev.
2)
BeagleBone
Black PandaBoard ES
DuoVero
COMS
Robovero Kit
(Overo COM)
Specs.
Processor 0 1 1 1 1
Clock Freq. 0 1 1 1 1
RAM 0 0 1 1 0
Storage 0 0 0 0 0
Connectivity
USB Ports 0 -1 0 -1 0
Wifi 0 0 1 0 1
Ethernet 0 0 0 1 -1
GPIO 0 1 1 1 1
OS 0 0 0 0 0
Cost
Price 0 -1 -1 -1 -1
Total
0 1 4 3 2
Figure C.1: Pugh matrix for selection of MCU
KGCOE MSD Page 36 of 62 Technical Review Agenda
PandaBoard ES
BeagleBone Black
Raspberry Pi (Model B rev. 2)
DuoVero COMS
Robovero Kit (use of Overo COM)
Beagleboard-xM
Specs. Processor 0 -1 -1 0 -1 -1
Clock Freq. 0 -1 -1 -1 -1 -1 RAM 0 -1 -1 0 -1 -1
Storage 0 -1 0 0 0 0 Connectivity
USB Ports 0 -1 0 -1 0 1 Wifi 0 -1 -1 0 0 -1
Ethernet 0 0 0 1 -1 0 GPIO 0 1 -1 -1 1 -1
OS 0 0 0 0 0 0 Cost
Price 0 1 1 -1 -1 1 Total
0 -3 -4 -3 -4 -3 Figure C.2: Pugh matrix for MCU selection.
Benchmarked against PandaBoard ES.
The main program was designed using an object-oriented approach. The first step of this process was to create a state
diagram (Figure C.2 on next page) to convert the abstract, high-level program behavior into logical, programmable steps.
The state diagram details every step of the main program’s operation. This diagram allowed the system to be viewed as a
behavioral plot, making the next step - determining what functional subsystems would be needed - much easier.
The software subsystems were determined to be the “Vitals”, which handled reading and presenting collected vital data on
the user in an XML format; “Communications”, which dealt with sending and receiving commands and data to the
Arduino and IMU as well as taking strain and watch data for basic operation; and “Navigation”, which handles
autonomous navigation using SLAM. These subsystems were each allocated a class in the main program to create a
logical modularity that would simplify future maintenance and code development without bloating the system. Once these
classes were determined, the necessary attributes and functions they would need to complete their tasks was determined
and used to create a UML block diagram of the main program. The UML block diagram will be the main template for
writing the Smart Walker II’s central control program, as it details exactly what needs to be written once coding begins.
KGCOE MSD Page 37 of 62 Technical Review Agenda
Figure C.2: State diagram of main program
KGCOE MSD Page 38 of 62 Technical Review Agenda
Once this block diagram was completed, it was used in conjunction with the state diagram to create two UML sequence charts. UML sequence charts are used for
specific use cases to identify unexpected complications within a system. They were chosen in this case to address concerns over timing issues within the cases of a
user fall being detected and a user leaving the walker. Timing issues were discovered and corrected, and there were no other scenarios in which timing concerns
arose.
KGCOE MSD Page 39 of 62 Technical Review Agenda
Figure C.3: UML sequence chart of “User Fall” scenario Figure C.4: UML sequence chart of “User Leaves” scenario
KGCOE MSD Page 40 of 62 Technical Review Agenda
Once the main program design was resolved, focus was shifted to peripheral communications. The first step in this stage
of the design was figuring out how data collection processes would communicate with the main program. Sockets were
initially considered as they were simple to implement and much faster than file storage. However, using sockets would
require storing all collected data locally within the main process and consume valuable processing power that could be
allocated to navigation instead. It was determined that it would be much better to store collected data in a non-volatile
format through files. If a system failure was to occur data would not be lost and all data storage would instead offload to
the file system. Additionally, because creation of reports will only occur during emergency events or at a specified hourly
rate (Defaulting to every 24 hours), the files containing that data would be accessed very rarely, eliminating concerns
about slow access times.
Because the drivers will all be running as separate processes, there was a degree of freedom allowed in determining which
languages would be used to write them. Generally the language choice was limited by what libraries were available to
provide necessary functionality. Were there enough time, all drivers would be written in C++ and any needed libraries
would be ported, but the time constraints on such a task are well beyond the scope of this project. Because the
development environment will be a Debian Linux build, we were mostly limited to open-source libraries. For the heart
rate algorithm, only a single effective Python library was found, and thus the webcam driver was decided to be written in
Python. The output of the strain gages’ ADC interface is connected through GPIO; C++ operates at a low level and
therefore was the best choice for the strain gage driver language. Finally, C++ will be used for the Chronos watch drivers
as the watch interfaces with USB and thus does not have any client-side restrictions on language.
Figure C.5: Data flow diagram showing how data is transmitted through the system
KGCOE MSD Page 41 of 62 Technical Review Agenda
Inter-process Communication for Fall Detection
The multitude of separate processes present in the Smart Walker II’s code design makes communication between
peripherals and subsystems more complex as none of the processes exist in the same allocated space and thus do not share
memory. This becomes an issue when dealing with user fall detection as the data acquisition is placed in a different
process than the fall detection handling. Files in non-volatile storage are too slow for a time-sensitive event such as a fall.
To resolve this issue, Linux’s signal variables SIG_USR1 and SIG_USR2 will be used to set flags indicating a fall has
occurred. These flags exist within the operating system, meaning that all processes are able to access them, and they are
specifically for developers to use.
Library Selection
Library selection was an important aspect of designing this system. As part of the objectives of this redesign was to reduce
code bloat, determining what libraries to use was important to ensure that the system would not expand during
implementation due to unexpected library dependencies.
For the main program, it was decided that five external libraries will be used. The first, Mutex, which allows mutually
exclusive threading, will be used to spawn a separate navigation thread from the main program as well as allow the parent
thread to wait upon the SIG_USR1 signal for the fall detection flag. Were Mutexes not used for this and a process was
instead forked, the parent process would waste valuable clock cycles polling SIG_USR1 for an update. The second
library is PugiXML, which will be used in the Vitals class’s parseToXML() function to take data from all of the data files
and write it to an XML. PugiXML was chosen over another C++ library, TinyXML, because benchmarking showed that it
ran approximately 3 times faster and was much more compact. The final libraries that will be necessary are the OpenNI,
sensor-bin-linux-arm, and nite-bin-linux-arm libraries that are necessary for the Xtion to function. The Navigation
algorithm may also require libraries, but as it will not be completed until the Smart Walker’s development has begun, no
speculation can be made.
The heart rate algorithm will use the open-source library “webcam-pulse-detector”. This was the only webcam-based
pulse detection library found, and has dependencies on the OpenMDAO, OpenCV, and numPy libraries. All other drivers
were not determined to require any other outside libraries.
Software Verification
To verify that all of the devices worked with a Linux system, a simple driver was written for each. Unfortunately, because
no Pandaboard ES was available, all testing had to be performed on a Beaglebone. The Beaglebone was chosen because it
is the closest MCU to the Panda having been developed by the same company.
KGCOE MSD Page 42 of 62 Technical Review Agenda
Figure C.6: Demo of heart rate algorithm and library
Figure C.7: Code and demo of TI Chronos watch accelerometer
KGCOE MSD Page 43 of 62 Technical Review Agenda
Data Formats and XML Report
Data types were decided based on the output format of the device the data is being received from.
IMU and accelerometer data will each be stored in a vector of three doubles, each representing rotations around the X, Y,
and Z axes. The range of values for this data is 0 – 360. These values represent coordinate values which can be used to
interpret falls when there is great change at a given time interval.
Strain gage data will be stored in a vector of six doubles. There are two different strain gage data; a set for the seats (four
data values) and a set for the handles (two data values).
- The range seen from the seat strain data would be 0V – 5V (equivalent range of 0-294lb) and a lookup table
can be used to find the corresponding weight (mass in kg) being applied to the strain (See Appendix). This
can then be used to determine where pressure sores are most likely to develop.
o The number of bits required to meet the specifications is 7 bits.
The calculation is as follows:
Max value determined to be 294lb equivalent to 80kg.
Log2(80kg/0.25kg) = 7 bits
- The range seen from the handle strain data would be 0V – 5V (equivalent range of 0-80lb) and a lookup table
can be used to find the corresponding weight (mass in kg) being applied to the strain (See Appendix). This
information can be used to see how the person leans (how much weight is biased to one side) and then use to
correct the persons posture.
o The number of bits required to meet the specifications is 5 bits.
The calculation is as follows:
Max value determined to be 80lb equivalent to approximately 8.16kg.
Log2(8.16kg/0.25kg) = 5 bits
The heart rate will stored as a float as the heart rate algorithm being used returns values ranging from roughly 40 to 120
with a tenth decimal precision. The units are in Beats Per Minute (BPM).
The temperature will be stored as a double. The typical values seen are 0, 95 – 110. A value of 0 would mean that the user
does not have the watch on. A range of 95-110 are possible ranges of a human body whether the person is sick or healthy.
The units are in Fahrenheit.
A fall event is also added to the xml data as it indicates a user fall. The values for this data is just yes or no.
The velocity of the walker will be represented as a float, while the encoder count will be represented as an integer.
Finally, the walker’s position in its environment will be stored as a vector of three floats, each representing X, Y, and Z
position.
This data will be stored in files with the “.data” extension as plaintext. Each of these files will store all readings of a single
data type for 24 hours, after which the program will overwrite all existing data and begin anew. Data readings will be
stored with a value and a corresponding time at which the reading was taken and will be parsed out of the file by the
program using regular expressions during XML creation.
The XML report format was chosen keeping the designer of XSLT report transforms in mind. It was decided that, because
data will be time sensitive, it would be most logical to separate readings, represented as <reading/> nodes, into groups
KGCOE MSD Page 44 of 62 Technical Review Agenda
based upon which type of data the reading represents (Heart rate, strain data, etc.). These groups have an attribute in the
parent node representing the sample rates at which the data was recorded. Heart rate, temperature, and IMU data are all
represented by a single value, while strain gage values are broken up into 6 sub categories, each representing one of the 6
strain gages. Each reading node has a value and a start time associated with it, along with a value called
“numoccurrences”. This value is a form of preprocessing that allows compression of sequential readings with redundant
values into a single node. For every node compressed this way, the number of occurrences is incremented by one. In the
event of a fall, a FallEvent node is generated that records what triggered the fall as well as what time the fall occurred. It
was not deemed necessary to include more information in this node as all relevant data will already be present within the
XML. In the case of a fall, an emergency report will be sent immediately showing all data previous to the fall for that day.
The end of the day report following such an event will still contain the FallEvent node, but will also contain the rest of the
day’s data. (See Appendix)
Concerns About SLAM
There is a significant risk with using an algorithm that has not yet been implemented for SLAM. No benchmarks exist for
the algorithm resulting in a complete lack of information about the expected efficiency. This means that all decisions
about processing power with reference to the SLAM algorithm are based purely on previous knowledge and research on
the general properties of similar algorithms. There is no possible way to determine how to allocate space or even what
data types will be needed as inputs for SLAM to work properly. The most that can and will be done is to provide the
navigation a dedicated core on the Pandaboard’s ARM9 Dual Core processor. Beyond that, all performance improvements
must be achieved through the implementation itself in software. Additionally, because of a lack of SLAM, a basic stub
class will be implemented that mimics the anticipated outputs of SLAM with known values. This will allow consistent
behavior to test the system with.
KGCOE MSD Page 45 of 62 Technical Review Agenda
KGCOE MSD Page 46 of 62 Technical Review Agenda
KGCOE MSD Page 47 of 62 Technical Review Agenda
Data
Ports on Pandaboard Programs .data file XML file Comments
TI-watch
Temperature USB
Run separately from SWII
Celsius/Fah + time stamp
parsed into xml format using the data in .data file
3-axis data USB x,y,z data + time stamp
parsed into xml format using the data in .data file
Webcam
Heartrate USB
Run separately from SWII BMP + time stamp
parsed into xml format using the data in .data file
Strain gage system
Strain gages GPIO32-37
processed in the SWII application
Voltage value? maybe some processing?
parsed into xml format using the data in .data file
Consider using SPI over GPIO because bit banging is inefficient
Walker IMU system
Walker IMU I2C2_SDA
Data used in SWII to determine position of the walker
Arduino System
Encoder Count I2C4_SDA
Used in SWII for dead reckoning/navigation
Xtion Pro Live
video stream USB
video stream used/manipulates data to navigate
No category
Fall event generated in SWII boolean value
KGCOE MSD Page 48 of 62 Technical Review Agenda
TOTAL 1194.03
Bill of Materials
Item Quantity Cost per unit
($) Total cost ($) Vendor Part # URL Status Notes
Hugo Portable Rollater Walker with Seat and Back rest
1 $105.99 $105.99 Amazon http://www.amazon.com/Hugo-Portable-Rollator-Walker-
Backrest/dp/B000GHTHTM Arrived
50kg Load Sensor 1 $14.52 $14.52 Sparkfun https://www.sparkfun.com/products/10245 Disassembled
For Test Purposes. No
longer functional. Not on Walker
PandaBoard ES 1 $182.00 $182.00 Digikey http://pandaboard.org/content/pandaboard-es Backordered /
On order
Arduino Uno 1 $29.95 $29.95 Sparkfun https://www.sparkfun.com/products/11021 Arrived
ASUS Xtion Pro Live 1 $180.00 $180.00 eBay - 23port http://www.asus.com/Multimedia/Xtion_PRO_LIVE/ Arrived
50:1 Metal Gearmotors 2 $39.95 $79.90 Pololu http://www.pololu.com/product/1444 Arrived
Dual Channel Motor Driver
1 $49.95 $49.95 Pololu http://www.pololu.com/product/2507 Arrived
J-B Kwik Epoxy 1 $5.70 $5.70 Lowes N/A Arrived
Vishay Micro-Measurements Strain Gages
15 $0.00 $0.00 Vishay Micro-Measurements
http://www.vishaypg.com/micro-measurements/university/ Awaiting
correspondance
12 V, 5000 mAh NiMH Battery
1 $69.95 $69.95 AA Power
Corporation
http://www.batteryspace.com/nimh-battery-and-charger-combo-12v-5000-mah-nimh-battery-smart-fast-charge.aspx
Arrived
MC33063A 3 $0.63 $1.89 Digikey http://www.digikey.com/product-detail/en/MC33063ADR/296-17763-1-
ND/717455 Awaiting order
33008 SMD to SIP Breakout
10 $2.19 $21.90 Digikey http://www.digikey.com/product-detail/en/33008/33008CA-ND/272906 Awaiting Order
ADUC845BSZ62-5 1 $22.58 $22.58 Digikey http://www.digikey.com/product-detail/en/ADUC845BSZ62-5/ADUC845BSZ62-5-
ND/936524 Awaiting Order
8100-SMT6 Protoboard 1
$28.80 $28.80 Digikey http://www.digikey.com/product-detail/en/8100-SMT6/438-1015-ND/480482 Awaiting Order
AD8237 Instrumentation Amplifier
10 $2.31 $23.10 Digikey http://www.digikey.com/product-detail/en/AD8237ARMZ/AD8237ARMZ-
ND/3602811 Awaiting Order
8029 Perfboard 2 $6.26 $12.52 Digikey http://www.digikey.com/product-detail/en/8029/V2025-ND/1886431 Awaiting Order
TD-132-T-A Male Headers
1 $7.61 $7.61 Digikey http://www.digikey.com/product-detail/en/TD-132-T-A/SAM1114-32-ND/1105526 Awaiting Order
CES-150-01-T-D Female Headers
1 $7.24 $7.24 Digikey http://www.digikey.com/product-detail/en/CES-150-01-T-D/SAM1086-50-
ND/1104074 Awaiting Order
RP3502ARED Pushbutton
1 $2.09 $2.09 Digikey http://www.digikey.com/product-detail/en/RP3502ARED/EG1930-ND/280448 Awaiting Order
SRB22A2DBBNN Rocker Switch
1 $0.93 $0.93 Digikey http://www.digikey.com/product-detail/en/SRB22A2DBBNN/CH760-ND/446026 Awaiting Order
180-Piece Rubber Grommet Shop Assortment
1 $4.01 $4.01 Amazon http://www.amazon.com/180-Piece-Rubber-Grommet-Shop-
Assortment/dp/B003NRF052/ref=sr_1_5?s=hi&ie=UTF8&qid=1399912594&sr=1-5&keywords=grommet
Awaiting Order
Ethernet/USB/ Power Ports
TBD Radio Shack
These parts will be purchased in
MSD II after physical
verification of location
Gear Set w/ Set Screw(.1873d) 1:3
2 $61.57 $123.14 SDP-SI S1344Z-
64A32A096 Awaiting Order
6061 Al Bar - 1.25x2x12
1 $21.68 $21.68 McMaster 8975K412 Awaiting Order
6061 Al Bar - .5x3x12 1 $16.02 $16.02 McMaster 8975K415 Awaiting Order
KGCOE MSD Page 49 of 62 Technical Review Agenda
1566 Steel Rod 1OD - 12in
1 $22.21 $22.21 McMaster 1346K37 Awaiting Order
M3 Screws-12mm( Qty 100)
1 $5.68 $5.68 McMaster 91290A117 Awaiting Order
#8-32-1in Socket Head (Qty 50)
1 $7.51 $7.51 McMaster 91251A199 Awaiting Order
1/4-20 Socket Head 1in (Qty 50)
1 $7.58 $7.58 McMaster 91251A542 Awaiting Order
5/16-18 Socket Head 2in (qty 25)
1 $7.39 $7.39 McMaster 91251A591 Awaiting Order
Steel Ball Bearing - 1/4 ID
2 $8.38 $16.76 McMaster 6384K39 Awaiting Order
Taper Roller Bearing 1/2 ID
2 $36.00 $72.00 McMaster 23915T11 Awaiting Order
#10-24 .5in Button Head (qty 50)
1 $7.16 $7.16 McMaster 91255A252 Awaiting Order
1/16 Al sheet 6x48in 1 $28.51 $28.51 McMaster 89015K77 Awaiting Order
Al Key stock .5x.5 1 $7.76 $7.76 McMaster 99108A120 Awaiting Order
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
KGCOE MSD Page 50 of 62 Technical Review Agenda
Appedix: Lookup table for corresponding mass (kg)
KGCOE MSD Page 51 of 62 Technical Review Agenda
KGCOE MSD Page 52 of 62 Technical Review Agenda
KGCOE MSD Page 53 of 62 Technical Review Agenda
KGCOE MSD Page 54 of 62 Technical Review Agenda
Appendix: Demo Code for Heart Rate Detection
from lib.device import Camera
from lib.processors_noopenmdao import findFaceGetPulse
from lib.interface import plotXY, imshow, waitKey, destroyWindow
from cv2 import moveWindow
import argparse
import numpy as np
import datetime
from serial import Serial
import socket
import sys
class getPulseApp(object):
"""
Python application that finds a face in a webcam stream, then isolates the
forehead.
Then the average green-light intensity in the forehead region is gathered
over time, and the detected person's pulse is estimated.
"""
def __init__(self, args):
# Imaging device - must be a connected camera (not an ip camera or mjpeg
# stream)
serial = args.serial
baud = args.baud
self.send_serial = False
self.send_udp = False
if serial:
self.send_serial = True
if not baud:
baud = 9600
else:
baud = int(baud)
self.serial = Serial(port=serial, baudrate=baud)
udp = args.udp
if udp:
self.send_udp = True
if ":" not in udp:
ip = udp
port = 5005
else:
ip, port = udp.split(":")
KGCOE MSD Page 55 of 62 Technical Review Agenda
port = int(port)
self.udp = (ip, port)
self.sock = socket.socket(socket.AF_INET, # Internet
socket.SOCK_DGRAM) # UDP
self.cameras = []
self.selected_cam = 0
for i in xrange(3):
camera = Camera(camera=i) # first camera by default
if camera.valid or not len(self.cameras):
self.cameras.append(camera)
else:
break
self.w, self.h = 0, 0
self.pressed = 0
# Containerized analysis of recieved image frames (an openMDAO assembly)
# is defined next.
# This assembly is designed to handle all image & signal analysis,
# such as face detection, forehead isolation, time series collection,
# heart-beat detection, etc.
# Basically, everything that isn't communication
# to the camera device or part of the GUI
self.processor = findFaceGetPulse(bpm_limits=[50, 160],
data_spike_limit=2500.,
face_detector_smoothness=10.)
# Init parameters for the cardiac data plot
self.bpm_plot = False
self.plot_title = "Data display - raw signal (top) and PSD (bottom)"
# Maps keystrokes to specified methods
#(A GUI window must have focus for these to work)
self.key_controls = "s": self.toggle_search,
"d": self.toggle_display_plot,
"c": self.toggle_cam,
"f": self.write_csv
def toggle_cam(self):
if len(self.cameras) > 1:
self.processor.find_faces = True
self.bpm_plot = False
destroyWindow(self.plot_title)
self.selected_cam += 1
self.selected_cam = self.selected_cam % len(self.cameras)
KGCOE MSD Page 56 of 62 Technical Review Agenda
def write_csv(self):
"""
Writes current data to a csv file
"""
fn = "Webcam-pulse" + str(datetime.datetime.now())
fn = fn.replace(":", "_").replace(".", "_")
data = np.vstack((self.processor.times, self.processor.samples)).T
np.savetxt(fn + ".csv", data, delimiter=',')
print "Writing csv"
def toggle_search(self):
"""
Toggles a motion lock on the processor's face detection component.
Locking the forehead location in place significantly improves
data quality, once a forehead has been sucessfully isolated.
"""
#state = self.processor.find_faces.toggle()
state = self.processor.find_faces_toggle()
print "face detection lock =", not state
def toggle_display_plot(self):
"""
Toggles the data display.
"""
if self.bpm_plot:
print "bpm plot disabled"
self.bpm_plot = False
destroyWindow(self.plot_title)
else:
print "bpm plot enabled"
if self.processor.find_faces:
self.toggle_search()
self.bpm_plot = True
self.make_bpm_plot()
moveWindow(self.plot_title, self.w, 0)
def make_bpm_plot(self):
"""
Creates and/or updates the data display
"""
plotXY([[self.processor.times,
self.processor.samples],
[self.processor.freqs,
self.processor.fft]],
KGCOE MSD Page 57 of 62 Technical Review Agenda
labels=[False, True],
showmax=[False, "bpm"],
label_ndigits=[0, 0],
showmax_digits=[0, 1],
skip=[3, 3],
name=self.plot_title,
bg=self.processor.slices[0])
def key_handler(self):
"""
Handle keystrokes, as set at the bottom of __init__()
A plotting or camera frame window must have focus for keypresses to be
detected.
"""
self.pressed = waitKey(10) & 255 # wait for keypress for 10 ms
if self.pressed == 27: # exit program on 'esc'
print "Exiting"
for cam in self.cameras:
cam.cam.release()
if self.send_serial:
self.serial.close()
sys.exit()
for key in self.key_controls.keys():
if chr(self.pressed) == key:
self.key_controls[key]()
def main_loop(self):
"""
Single iteration of the application's main loop.
"""
# Get current image frame from the camera
frame = self.cameras[self.selected_cam].get_frame()
self.h, self.w, _c = frame.shape
# display unaltered frame
# imshow("Original",frame)
# set current image frame to the processor's input
self.processor.frame_in = frame
# process the image frame to perform all needed analysis
self.processor.run(self.selected_cam)
# collect the output frame for display
output_frame = self.processor.frame_out
KGCOE MSD Page 58 of 62 Technical Review Agenda
# show the processed/annotated output frame
imshow("Processed", output_frame)
# create and/or update the raw data display if needed
if self.bpm_plot:
self.make_bpm_plot()
if self.send_serial:
self.serial.write(str(self.processor.bpm) + "\r\n")
if self.send_udp:
self.sock.sendto(str(self.processor.bpm), self.udp)
# handle any key presses
self.key_handler()
if __name__ == "__main__":
parser = argparse.ArgumentParser(description='Webcam pulse detector.')
parser.add_argument('--serial', default=None,
help='serial port destination for bpm data')
parser.add_argument('--baud', default=None,
help='Baud rate for serial transmission')
parser.add_argument('--udp', default=None,
help='udp address:port destination for bpm data')
args = parser.parse_args()
App = getPulseApp(args)
while True:
App.main_loop()
KGCOE MSD Page 59 of 62 Technical Review Agenda
Appendix: Demo Code for Watch Accelerometer Data
import serial
import array
def startAccessPoint():
return array.array('B', [0xFF, 0x07, 0x03]).tostring()
def accDataRequest():
return array.array('B', [0xFF, 0x08, 0x07, 0x00, 0x00, 0x00,
0x00]).tostring()
#Open COM port 6 (check your system info to see which port
#yours is actually on.)
#argments are 5 (COM6), 115200 (bit rate), and timeout is set so
#the serial read function won't loop forever.
ser = serial.Serial("/dev/ttyACM0",115200,timeout=1)
#Start access point
ser.write(startAccessPoint())
while True:
#Send request for acceleration data
ser.write(accDataRequest())
accel = ser.read(7)
if ord(accel[0]) != 0 or ord(accel[1]) != 0 or ord(accel[2]) != 0:
print "x: " + str(ord(accel[0])) + " y: " + str(ord(accel[1])) + " z: " +
str(ord(accel[2]))
ser.close()
KGCOE MSD Page 60 of 62 Technical Review Agenda
Appendix: Shaft Analysis
KGCOE MSD Page 61 of 62 Technical Review Agenda
Appendix: Shaft Analysis Cont.
Corrections based on Analysis of Motor Shaft.
KGCOE MSD Page 62 of 62 Technical Review Agenda
MSD II: Beginning of Fall Semester Goals:
Majority of parts should have been ordered and will be waiting.
Schedule is built off the basis that consistent testing and redesign will be needed to achieve an optimal system. Based on
that platform, a 3 week incremental structure was established to ensure that after every 3 week block, the system is re-
evaluated, tested, and redesigned (and parts be reordered) as necessary to efficiently identify and work out any issues the
team may face.
Week 1: (Assembly)
- Finish building/machining/printing mechanical parts.
- Begin assembly of all mechanical, electrical, and computer components. (i.e. PandaBoard, Walker Assembly, etc…)
- Reassess electrical component needs so as to acquire any other electrical parts needed (i.e. resistors)
Week 2: (Test)
- Begin testing electrical systems
- Begin integrating newly built/machined/printed parts
- Begin programming
Week 3: (Redesign)
- Assess the functionality of components (i.e. Mechanical, electrical, computer) to determine if all
parts are working as designed, and as required.
- Assess and redesign any components that are not functioning as they should
- Order any necessary components to complete the “assembly” of the new design.