kgcoe msd technical review...

KGCOE MSD 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


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


Becker-Gomez,

Computer Engineering Software Design

Interprocess Communication for Fall Detection

Library Selection

Software Verification

Data Formates and XML Report

Concerns about SLAM


Becker-Gomez,


Appendix Bill of materials

MSD I to II schedule


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.


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


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


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


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.


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


High-Level System Interconnect Diagram

Figure E.1a - High-level system interconnect drawing


Figure E.1b – Electrical system interconnect drawing


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


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


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 & 𝑉𝑜𝑢𝑡 = 𝐼𝑁+ − 𝐼𝑁−


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


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.


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


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


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


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.


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


Tech Drawing ME.01 Micro/Power Housing


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


Tech Drawing ME.02 Wheel Housing/ Motor Shroud


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.


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.


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


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.


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.


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.


Figure E.10 - Motor, encoder, and motor controller interconnection


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.


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


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.


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.


Figure E.18 - Software flowchart for the ez430 Chronos in use with Smart Walker II


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


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.


Figure C.2: State diagram of main program


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.


Figure C.3: UML sequence chart of “User Fall” scenario Figure C.4: UML sequence chart of “User Leaves” scenario


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


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.


Figure C.6: Demo of heart rate algorithm and library

Figure C.7: Code and demo of TI Chronos watch accelerometer


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


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.


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


Webcam

Heartrate USB

Run separately from SWII BMP + time stamp


Strain gage system

Strain gages GPIO32-37

processed in the SWII application

Voltage value? maybe some processing?


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


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-


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-


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


1566 Steel Rod 1OD - 12in


M3 Screws-12mm( Qty 100)

1 $5.68 $5.68 McMaster 91290A117 Awaiting Order

#8-32-1in Socket Head (Qty 50)


1/4-20 Socket Head 1in (Qty 50)


5/16-18 Socket Head 2in (qty 25)


Steel Ball Bearing - 1/4 ID


Taper Roller Bearing 1/2 ID

2 $36.00 $72.00 McMaster 23915T11 Awaiting Order

#10-24 .5in Button Head (qty 50)


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


Appedix: Lookup table for corresponding mass (kg)


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(":")


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


destroyWindow(self.plot_title)

self.selected_cam += 1

self.selected_cam = self.selected_cam % len(self.cameras)


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"


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]],


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


# 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()


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()


Appendix: Shaft Analysis


Appendix: Shaft Analysis Cont.

Corrections based on Analysis of Motor Shaft.


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.

kgcoe msd technical review...

Documents