Meeting Purpose : Detailed Design Review

Materials to be Reviewed : Plans for MSD II

Meeting Date: 5/13/15

Meeting Location: TBD

Meeting time 9:00 AM

Timeline:

Meeting Timeline

Start

time Topic of Review Required Attendees

9:00 Agenda, Preliminary Comments on Pre-read Report all

Motor/clutch system all

Misc. Changes all

3D imaging and Printing all

ME plans for MSD II all

9:30 Wiring all Data Storage all

Data Sending all

10:00 Circuit Designs all

10:15 Controller Designs all

ROS & SLAM Updates all

10:35 Webcam Interfacing all

XTION Interfacing all

10:50 BMI Circuitry all

MSD II Plans all

Motor/Clutch Subsystem:

At the completion of Smart Walker II, the motor/clutch subsystem was incomplete. The customer

requirement that originally inspired the clutch system was the requirement to remove the noise and

resistance coming from the wheel area (motor specifically). Another issue not addressed was that the

wheels and motor must be separated to prevent the motor from continuously creating a voltage. This was

solved by making the motor and gear system two separate entities through the use of a solenoid activated

clutch. The implementation of the design did not fully separate the motor from the gears, nor was the

clutch able to be activated. Actions have already been taken in order to alleviate these issues, including

remodeling the housing (Figure 1) in order for the housing to be independent of the system, adding set

screws in order to translate the motion, and correcting the sizes of the bearing-plates (Figures 3-8). After

testing with only these changes, it has been concluded that the motion is now transferable from the motor

to the wheels. Do note, however, that these changes were made after much wear and tear on the gears

(due to the weight they were forced to bear from faulty bearing plates). This inspired a new gear set as

well. We are currently working on implementing a new design for translating the solenoid motion to the

clutch (Figure 10). A bushing is also being added to the plastic clutch piece in order to alleviate friction.

In the current state, the clutch does not consistently activate with the changes made.

The bearing plates, in their previous state (Figure 2), compromised the walker’s ability to

translate motion, thus, eating the gears and counteracting the implementation of a clutch. This

was a simple matter of poor machining accuracy. Two parallel plates which were supposed to be

the same size were found to be unequal in size, therefore, losing the much need 90° angle that

supports the weight of the walker. This forced the gears to bear the weight, which wrecked the

gear teeth as well as prevented the movement of the walker without great resistance to motion.

In order to fix this, new plates of a stronger material have been ordered and will be manufactured

with more accuracy (Figures 3-8). Ultimately, these plates will also be attached in a more robust

form.

The overall design of this system runs in two directions. When in autonomous mode, a motor is to

translate the motion down to the wheels. This is done via the clutch. The clutch is activated by a

solenoid. The clutch translates the motion through a set of bevel gears, 3:1 gear ratio, down to the

wheels. In order for the clutch to be able to be activated by the solenoid, a 3D printed piece has been

designed to connect to the bottom of the solenoid, and bushing are being added to line the clutch so that it

can move more freely along the shaft.

Misc. Changes:

Miscellaneous changes throughout the walker have been made in order to satisfy the customer

requirements and keep the integrity of the walker. One of the first changes made was to add

rivets to the bar supports in the walker. This was in order to keep the walker’s ability to move

easily, which was hindered due to the bars’ ability to deflect. This correction would not have

been necessary if it was not made worse by alterations made in Smart Walker II. It was deemed

necessary, however, as it was determined that the location of the wheels (moved in Smart Walker

II) significantly increased this deflection, causing the great resistance in motion. This same issue

of the wheels has also been determined to need changing. The plan is to move the wheels to be

closer to the line of action of the weight by decreasing the offset. This offset appears to

originally have been due to an overcompensation of the thickness of the housing.

3D Imaging: (note changes to systems vs. items to be 3D printed)

Figure 1-Motor/Clutch Housing (to be 3D printed)

Figure 1 shows the updated housing for the motor/clutch area. Do note a few changes in the housing.

The ultimate goal was to allow the housing to be strictly a housing mechanism. By removing ledges from

the housing, it removed the function of support, which has been determined to actually hinder the motion.

Also note the slots rather than thru holes. This allows the easy removal of the housing in order to expose

the are beneath for any testing or evaluation.

Figure 2-Motor/Clutch Subsystem

Figure 2 shows the motor/clutch system. The three plates, forming a “U” shape, are ready to be re-

manufactured. In its current state (altered by us), a shim is being used to create the necessary 90° angle.

Plates of 1018 steel are going to replace the current aluminum plates in order to make the system more

robust and to correct the plate sizing.

Figure 3-Top plate

Figure 4-Top plate

Figures 3 and 4 show the top plate of the bearing plate area. Holes have been added in order to more

robustly attach this top plate to the lower two, creating the “U” shape. In the previous design, this was

not attached, forcing the gear system that is encases to also be the structure.

Figure 5-Wheel side plate Figure 6-Inner plate

Figure 7-Wheel side

Figure 8-Inner

Figures 5-8 show the side plates. Note that the dimensions of the two plates are supposed to be mirror

images of each other, as mentioned before. Also note the addition of the screw holes at the top of each

piece in order to securely fasten these plates to the top plate.

These bearing plates are ready to be manufactured. We plan on submitting the drawings at the end of the

semester because the current system will have to be disassembled so the current bearings can be press fit

in. We want to hold off on this so that the EE’s can finish any testing they need to do this semester. They

will be ready to be assembled early next semester.

Xtion:

The case was designed to enclose the camera and set the angle required for the SLAM software. The

walls are 0.25” thick. The connecting piece was taken from the previous design, as this was modeled

correctly. It is incorporated directly into the case at a fixed angle preventing any rotational motion

accidentally caused by the user. The angle is yet to be determined, but will be chosen such that the wheels

are not in the cameras view. Once the angle is determined, one dimension will be fixed and the case will

be ready to be printed.

Figure 9a-Xtion Case Design front with Camera

Figure 9b-Xtion Case Design back with cap

(XTION Specifications: http://www.asus.com/us/Multimedia/Xtion_PRO_LIVE/specifications/ )

Figure 10-Clutch Redesign Version 2:

The piece in Figure 10 was printed, however it might not be necessary if the bushings correct the original

problem of too much friction. We are currently waiting on those to be installed by the machine shop.

Figure 11 shows the calculation of the center of mass via the load cells. The matrix shows a calculation

using moments. What the equation is doing is taking a point as an origin to form an x-y coordinate

location. in the equation, a moment is being taken about each of the points in order to determine a

location of the total moment. This can be proven by units as well to show accuracy. The point of center

of mass is located by diving the total moment by the sum of all forces, yielding a distance calculation

from the point being used as a reference.

Future Work:

Future work for MSD II begins at the load cells (Figure 11). The load cells are connected to a plate under

the seat. They are a set of four individual load cells, one in each corner of the seat. The goal with these

load cells is to collect four individual readings from the cells and use these to determine the center of

mass. The method of analysis of the points had already been determined in Smart Walker II. The

analysis can be seen in Figure 11.

Future work for the wheel area includes moving the wheels closer to the bar. This is to be done using a

lathe tool in order to adjust the axil length and where the wheel sits along it.

Future work will also need to be done for the BMI system. The metal electrodes will be incorporated into

the handles and will be supported by a 3D printed slot. Work for this is currently on hold until a final

BMI design is completed so that no unnecessary alterations are performed to the walker.

MSD II Preliminary Schedule:

Figure 11-MSD Preliminary ME Schedule

EE Section:

Wiring:

At the completion of Smart Walker II, system wiring was either incomplete or a complete mess. The

original micro controller and Pandaboard enclosure was impossible to open without disconnecting one or

multiple wires due to components previously being mounted opposite of how the enclosure opened. The

customer requirement that would make the system more robust, allowing for wiring to stand up against

customer falls, testing, and benchmarking.

While Smart Walker II did provide a full system level diagram of how components were expected to

connect, there was no overall wiring diagram. When investigating the current state of wiring residing

within Smart Walker II it was noticed that multiple runs of CAT5 Ethernet cable were fished through the

frame to strain gauges and to motor controls, which seemed to allow for reuse of the previously

implemented cabling. Upon closer inspection there were multiple pairs of the CAT5 cable missing from

each run, as well as the strain gauge runs that were damaged in both the external jacket and internal

twisted pairs. Due to these reasons, two sets of twisted pair 24 gauge cable needed to be ran to the strain

gauges. While taking from the high level design document, a new and complete wiring overhaul needed

to happen, and this overhauled wiring diagram is depicted in Figure 12.

Figure 12-Complete System Level Wiring Diagram

As Smart Walker II soldered every connection to their PCBs, it was difficult to quickly test and swap

connections. Based on this reason, the connections between the Strain Gauges (Figure 13) and Load

Cells (Figure 14) were made with a 4 pin snap in connector from Digikey at the following address.

http://www.digikey.com/product-detail/en/640441-4/A1902-ND/108947. Due to each of these cables

being 24 gauge, it was imperative that the wires do not become detached from the connectors, requiring a

strain relief connector. The strain relief used on all strain gauge and load cell wiring is also from Digikey

at the following address. http://www.digikey.com/product-detail/en/0/A19232-ND.

Figure 13-Strain Gauge Connections to Strain Gauge PCB

In the case of the Strain Gauge connections, the data plus (red wire) is soldered to the single colored wire

in the twisted pair while the data minus (grey wire) is soldered to the white/color wire. In the case of the

left handle, the two twisted pairs consist of orange and green, and in the right handle, blue and brown. For

the left handle, the connections from 1-4 on the 4 pin connector are as follows: Upper Strain Gauge data

plus (orange), Upper Strain Gauge data minus (white orange), Lower Strain Gauge data plus (green), and

Lower Strain Gauge data minus (white green). This four pin connector plugs into the strain gauge one

circuit on the strain gauge PCB.

For the right handle, the connections from 1-4 on the 4 pin connector are as follows: Upper Strain Gauge

data plus (blue), Upper Strain Gauge data minus (white blue), Lower Strain Gauge data plus (brown), and

Lower Strain Gauge data minus (white brown). This four pin connector plugs into the strain gauge two

circuit on the strain gauge PCB.

Figure 14-Load Cell Connections to Strain Gauge PCB

In the case of all four load cells, the connections from 1-4 on the 4 pin connector are as follows: +5V

(red), data plus (green), data minus (green), data minus (white), and ground (black). The connection

locations on the strain gauge PCB depend on the load cell location under the seat. The back left, front

left, back right, and front right load cells correspond to circuits load cell 1 - load cell 4 respectively. The

output of the strain gauge PCB ties into the ADC 8 board via plugging into the main board, therefore

there are no wire connections, but the image is still included in the drawing.

The only CAT5 connections run by Smart Walker II are the cables connecting the solenoids and motors to

the Arduino Due and Pololu VNH5019 Motor Driver shield. This circuit is depicted in Figure 15.

Figure 15-Motor and Solenoid Connections to Arduino Due and Motor Shield

Smart Walker II ran two lines of CAT5 cable for the motors through the front half of the frame, and they

are being reused as the cables do not seem to be damaged. As the separate solenoid control PCB was

created, it will not require wires to the motor shield as the Arduino will be plugged into PCB revision 1.1

to be created this summer / next fall. Since the voltage required to run the solenoids is +12V, CAT5 will

not work effectively for the solenoid power. 12 gauge (red) cable is what connects the +12V PCB line to

the motor. The encoders of the motors run off of +5V and ground, and the encoder outputs of the left

solenoid will plug into pins 22 and 23 of the motor driver shield for encoders A and B, while the right

solenoid will plug into pins 24 and 25 for encoders C and D.

On the right side of the motor shield, motor control 1 and motor control 2 from the left motor will run into

M1A and M1B respectively. Motor control 3 and motor control 4 from the right motor will run into M2A

and M2B respectively. The +12V and GND lines from the right solenoid will plug into VIN and GND

respectively. Pins 18 and 19 of the motor shield connected to the solenoid transmit and the solenoid

receiver that will connect to the Main PCB along with the strain gauge ADC circuit via means of two

separate level shifters.

Figure 16-Motor, Solenoid, and Strain Gauge Connections to Main PCB and Pandaboard

This is shown in Figure 16 as the connections between the Main PCB and the Pandaboard are made over

twp 28 conductor, dual row ribbon cables that encase a +1V line, a motor transmit and receive, and a

ground for one ribbon cable while connecting +1.8V, SDA, SCL, and GND to the other. These two

ribbon cables are connected to the Pandaboard through the two 28 pin general expansion ports.

Last but not least, the heartrate webcam and XTION are both powered via USB running through the

frame to the Pandaboard. The heart rate camera also has a microphone built in, so the ⅛” audio input will

plug into a female audio jack on the Pandaboard.

For future work, the soldering of female sockets onto the Pandaboard by Smart Walker II is to be

removed and replaced with a 28 pin male header, and the IDC connection needs to be pressed onto the 30

conductor ribbon cable to connect the Pandaboard to the Main PCB.

Data Storage:

One of the first and foremost customer requirements about the Smart Walker is the necessity for data

collection and the ability to wirelessly transmit said data via server to a care provider or doctor. In

beginning this task it became clear that each individual vital correlated to a value of raw input (voltage,

resistance, etc.) which would require an additional calculation to display each data capture in user

readable formatting.

When calculating the applicable storage space required for all the data measured by Smart Walker’s

sensors, it was decided that the storage values for raw input and calculated values would all have to be

accounted for. For the raw voltage measurements of the strain gauges, the load cells, the BMI sensor, and

the heart rate sensor, 2 bytes of data would be stored for each sensor. In the case of creating a time stamp

for each update to the vitals output file, or in the case the patient falls, 4 bytes of storage needed to be

allocated for each fall and timestamp.

For the calculation of strain gauge and load cell data, 2 bytes of data also needed to be allocated to

convert from voltage to center of mass. In the much more diverse case concerning the conversion of

resistance to BMI, 6 bytes of data have been allocated for the calculation. If the total sampling time of the

sensors in one continuous run is 60 minutes, and the walker samples once every 15 seconds, with no user

falls, the total storage size is 10.336 kilobytes of data, which will be stored in a file called “vitals.txt” in

the directory /data on the Pandaboard. To approximate storage space, I have created an excel spreadsheet

(Data Storage.xls on Edge under Detailed Design Documents) that takes in how long the total sampling

time is (in minutes), the sampling rate (in seconds), and the amount of falls a patient may encounter, and

the spreadsheet will output the approximate size of the “vitals.txt” document.

For future work: The actual formatting in which the vitals file is to be written will be of large importance.

While the approximation of data storage values does give a reasonable estimate of necessary file sizes, the

data algorithms can be improved to find more accurate storage values.

Data Sending:

The first step to setting up wireless transmission of data was to create an SSH server on the Pandaboard.

In order to accomplish this task, sshd and ssh install packages were downloaded onto the Pandaboard via

sudo get-apk and similar commands. The ssh and sshd downloads were unable to start an ssh server from

the beginning due to a correlation error forwarding port 25 to the ssh rather than port 22, this error took

multiple reinstallations of the apks to almost entirely fix the error. After debugging the ssh code for

errors it was discovered that the sshd files were hardcoded to port 25 and no external attempts to modify

the file would change this port. After three attempts using sudo nano, the sshd config code was correctly

set to port 22, allowing SSH.

The second step to setting up transmission of data is securing a static IP address, allowing remote access

to the server at any time. Although the Pandaboard does have wireless capabilities based on the WL1271

wifi chip, when attempting to procure a wireless address for broadcasting on RIT’s network, we were

advised to not set up wirelessly due to: the shut down of the wireless access point by ITS, and for security

concerns relating to the information to be stored on the walker. Due to these concerns, the Pandaboard is

wired directly to a networking card on the senior design lab computer which is passed a host address

down from the live ethernet port on the computer. As of right now the static IP address set for the

Pandaboard is 10.1.1.101. After setting the static IP, there was contact between puTTy and the

Pandaboard if there was a direct link.

The third step in setting up the transmission of data is a means to actually retrieve files from the

Pandaboard from a remote destination. The software route we took in this task was to use WinSCP,

which allows for file transfer between linux based devices and windows based devices using the same log

in methods as ssh. WinSCP also provides an efficient means of automating the file transfer process via

usage of scripts and batch files (the batch files work primarily on windows devices). The applicable use

of the batch file is that it can be added to the event planner on any windows based machines, automating

the retrieval of data at the same computer time every 24 hours. The batch file calls the script which will

open WinSCP and pull the “vitals.txt” file from the Smart Walker and transfer it as “myData.txt” onto the

client computer. The code for the batch and script file is as follows:

Batch file (SW3.bat)

"C:\Program Files\WinSCP\WinSCP.exe" /script="c:\Users\User\Documents\script.txt" ^

/log="c:\Users\User\Documents\example.log"

---------------------------------------------------------------------------------------------

Script file (script.txt)

# Automatically abort script on errors

option batch abort

# Disable overwrite confirmations that conflict with the previous

option confirm off

# Connect

open sftp://smartwalker:smartwalker@10.1.1.101/ -hostkey="ssh-rsa 2048

87:eb:01:d3:f0:39:c3:57:23:67:99:a2:ef:b1:62:4f"

# Change remote directory

cd data

# Force binary mode transfer

option transfer binary

# Puts ASCII characters in the document such as New Line and Carriage Return

ascii

# Download file to the local directory C:\Users\User\Documents

get vitals.txt C:\Users\User\Documents\myData.txt

# Disconnect

close

Future work: The wired connection for the Pandaboard will need to be updated to a wireless Static IP

address. Other than updating the static IP of the Pandaboard, the batch and script files will just need the

new static IP to continue their current functionality.

Circuit Design:

A master file containing both high and low level schematics has been created and will be

maintained with Microsoft Visio. The file is interactive, and clicking on each box/part links to

another drawing or part datasheet. The high level block diagram of the Smart Walker 3 electronic

layout is seen in Figure 17.

PCB – Power Conversion & Distribution

+ 12 V

+ 5 V

+ 3.3 V

PCB - Strain Gauge Amplification

Left Handle Strain Gauges

Right Handle Strain Gauges

Top Left Load Cell

Top Right Load Cell

Bottom Left Load Cell

Bottom Right Load Cel

GND

+ 5 V

PCB – 8 Channel

ADC

SDA – To Level Shifter

SCL – To Level Shifter

+ 3.3 V

GND

Mo

tor

Motor CTL 1Motor CTL 2

+ 5 VEncoder AEncoder B

Solenoid Solenoid

Arduino Due w/ Pololu Dual H-Bridge Motor Shield Pandaboard

Level Shifting

Level Shifting

i2c-04

tty

03

+ 3.3 V

SDA

SCL

GN

D

PCB – Solenoid Control

+ 1.8 V

TXM

RXM

GND

+ 3.3 V

RXS

TXS

GND

Left Solenoid Control Pin

Right Solenoid Control Pin

+ 1

.8 V

SDA

SCL

GN

D

Battery: + 12 V

USB - Webcam

USB - XTION

+ 5 V

GND

+ 12 V

+ 12 V

FET Collector

FET Collector

IMU

+ 5 V

GND

usb

0

usb

1

Mo

tor

Motor CTL 1Motor CTL 2

+ 5 VEncoder AEncoder BLevel Shifting

Level Shifting

Figure 17 - Top Level Block Diagram

Circuit Design 1: Strain Gauge Amplifier

3.3 kW

200 W

+5 V

RSTRAIN

RSTRAIN

+5 V

1 kW

1 MW

Vo = (1+1000)(V+ - V-) + VREF

V+

V-

FB

REF

TRIM+

- AD8237

1.2 kW

2 kW

200 W

TRIM

0.01 uF

Bypass Caps omitted for simplicity. 1uF and 0.1uF are connected

between Vin & GND

Figure 18 - Handlebar Strain Gauge Amplification

The first trimmer (in the 3.3 kohm resistor divider), provides adjustment on the initial voltage

output (Vo when there is no load). This is to allow for wiggle room in case V+ and V- are not

completely matched. The second trimmer is for a small adjustment on the gain ratio. A similar circuit is used for load cells, only the resistor divider is unnecessary. The load cells

have an internal wheatstone bridge, and the V+ and V- terminals are completely matched. Figure 19

shows the PCB portion of the circuit.

+5 V 1 kW

1 MW

Vo = (1+1000)(V+ - V-) + VREF

V+

V-

FB

REF

+

- AD8237

200 W

TRIM

0.01 uF

Bypass Caps omittedf for simplicity. 1uF and 0.1uF are connected

between Vin & GND

To Load Cell - RED

To Load Cell - GREEN

To Load Cell - WHITE

To Load Cell - BLACK

Figure 19 - Seat Load Cell Amplification

Circuit 2 Design: Power Conversion & Distribution

The battery currently used in the Smart Walker (leftover from Smart Walker 2) is 12 V, 6000

mA*Hr.

The DC motors draw ~200 mA during a free run. This will change significantly, however,

when the motors are under a full load (since motor assemblies are taken apart, testing cannot be done

at this time). Solenoids draw ~430 mA each when engaged, and essentially nothing when

disengaged. The Pandaboard runs on 5 V, and draws 700-800 mA. The Arduino Due draws 50-100

mA when fully on. Since the Due is only needed when the walker is in “robot” mode, it can be put

into a sleep mode to save power, until it is woken up with an external interrupt.

To step the 12 V down, a buck converter circuit was designed. The AOZ1280CI by Alpha &

Omega Semiconductors was chosen as the IC to use in the circuit due to its small size, high switching

frequency, and adjustable output voltage. Two voltage levels were set in the first PCB: 5 V and 3.3

V. Figure 20 shows the circuit design.

AOZ1280CI

Adjustable Buck Converter

10 nF

10 uF

22 uF

59 k

11.2 k

1 k

4.7 uH

+12 V

Resistor Ratio determines Vo:

Vo = 0.8(1+R1/R2)

AOZ1280CI

Adjustable Buck Converter

10 nF

10 uF

22 uF

56 k

17.8 k

1 k

4.7 uH

+12 V

Vo = 0.8(1+56/17.8) = 3.32 V

Vo = 0.8(1+59/11.2) = 5.01 V

R1

R2

R1

R2

Figure 20 - Voltage Step Down Design

(Link to buck converter datasheet: http://www.aosmd.com/res/data_sheets/AOZ1280CI.pdf )

Circuit 3 Design: A/D Conversion The Tigerbot V team had previously designed a PCB with an 8 channel ADC and I2C

interface. To save time, this PCB will be used in the Smart Walker. Figure 21 shows the circuit,

designed by Ben Haag, as it is used in the Smart Walker.

ADC128AD818

8 Channel A/D Converter1 uF

Left

Han

dle

Stra

in G

auge

s

Righ

t H

andl

e St

rain

Gau

ges

Top

Left

Loa

d Ce

ll

To

p R

igh

t Lo

ad

Ce

ll

Bott

om L

eft

Load

Cel

l

Bott

om R

ight

Lo

ad C

ell

To

He

ad

er

Pin

s

To

He

ad

er

Pin

sSDA

Line

– T

o Le

vel

Shi

fter

SCL

Lin

e –

To L

evel

Shi

fter

IN0

IN1

IN2

VREF

IN4

IN5

IN6

IN7

SDA

SCL

GND

VIN

INT

A1

A0

+ 3.3 V

IN3

Figure 21 - A/D Conversion Circuit

(Link to ADC datasheet: http://www.ti.com/lit/ds/symlink/adc128d818.pdf )

Circuit Design 4: Solenoid Control The solenoids used in the clutch system must be driven, as they draw relatively high current.

In order to control the solenoids with the Arduino, the circuit in Figure 22 is used.

IRF640

+ 12 V + 12 V

Solenoid Solenoid

To Arduino, PIN 3

To Arduino, PIN 5

ADUM1200

2-Channel Digital Isolator

+3.3 V +5 V

VDD1

VIN A

VIN B

GND

VDD2

VOUT A

VOUT B

GND

Bypass Capacitors omitted for simplicity. 2 1uF caps connecting each VDD to

ground.

IRF640

Figure 22 - Solenoid Driving Design

(Link to isolator datasheet: http://www.analog.com/media/en/technical-documentation/data-sheets/ADuM1200_1201.pdf )

Circuit Design 5: Various Level Shifting To account for differing voltage levels on the I2C and UART lines, bi-directional level

shifting is needed. The circuitry will be built-in on the PCB’s in the appropriate places, and will be

able to be completely bypassed via jumpers. Figure 23 shows the circuitry used for level shifting.

BSS13810 kW 10 kW

Lower Voltage Level (3.3 V, 1.8 V) Higher Voltage Level (5 V, 3.3 V)

Lower Voltage Line Higher Voltage Line

Figure 23 - Level Shifting Circuitry.

The design and operation of the circuit is discussed in detail by Philips Semiconductor.

(link: http://www.nxp.com/documents/application_note/AN10441.pdf )

PCB:

Rev. 1 was designed, laid out, and populated by Dave Malanga. The circuitry is in working

condition, although a few errors were found in the board. The following lists the plans for rev. 2 for

the PCB:

1. Spacing for the strain gauge board connectors does not match. It is offset by 2 pins.

2. Anode of the diode in both buck converter circuits was connected to wrong node (should be

connected to GND), causing higher than anticipated voltages. A board mod was made on rev.

1 and the voltage levels are correct.

3. Adding a third, fully adjustable voltage converter. Will be adjustable via two trim pots.

4. Level shifters should be integrated onto the board. Have the option to bypass the shifting

circuitry via jumpers.

5. ADC board will plug into main board. Minimizes wiring.

6. Adding connections for connecting Pandaboard GPIO expansions with ribbon cable.

Motor Control:

Section 1 – Design Theory:

𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒

𝑟𝑒𝑣𝑜𝑙𝑢𝑡𝑖𝑜𝑛= 20.32𝜋 = 63.84 𝑐𝑚

(3200 𝑡𝑖𝑐𝑘𝑠

𝑟𝑒𝑣) (

3 𝑟𝑒𝑣

1 𝑟𝑒𝑣) (

1 𝑟𝑒𝑣

63.84 𝑐𝑚) = 150.38 𝑡𝑖𝑐𝑘𝑠/𝑐𝑚

Figure 24 - Smart Walker 3 wheel dimensions.

8 i

n (

20

.32

cm

)

24 in (60.96 cm)

Originally, in Smart Walker 2, motor control was handled by an Arduino Uno connected to the

Pandaboard via a UART line. In addition, the motor encoders were read using a Teensy 3.1 connected to

the Pandaboard via an I2C line. In Smart Walker 3, the Uno was replaced with an Arduino Due because it

has more processing power, more I/O pins, and better interrupt capability. This eliminated the need for

the Teensy, making motor control much simpler.

The motor is controlled with an Arduino Due, with a Dual H-Bridge Motor Shield made by

Pololu. The motors on the Smart Walker have quadrature encoders. Each motor has 2 encoder channels,

out of phase by 90 degrees. They produce a set of square waves, with 64 rising or falling edges (or ticks)

per revolution of the motor shaft. Since there is a 50:1 gear ratio internal to the motor, this means there

are 64*50 = 3200 ticks per revolution on the output motor shaft. Additionally, there is another set of gears

connecting the output motor shaft and the wheel, which has a gear ratio of 3:1. Therefore the motor

encoders produce 9600 ticks per revolution of the Smart Walker’s wheel.

Since the circumference of the wheel is known, a desired distance or velocity can be translated

into a number of ticks, or a number of ticks per second, respectively. This makes it possible to have a

closed loop system.

Each motor uses a P/I controller for position, with an additional semi-active P controller for

velocity. The velocity control will keep the motors spinning at a constant velocity over longer distances.

Once the walker gets close enough to its target (< 0.5 meter), the velocity controller shuts off, allowing

the motors to slow down as they approach the target position. Figure 25 shows the block diagram of this

control system.

Figure 25 - Motor Control System Design.

Section 2 – Programming:

The Arduino program is coded using the Arduino IDE. There is one controller for each motor

(left & right). The bulk of a controller consists of two functions: a setup function, and the main control

1

s+1

Transfer Fcn

Step1

Step Scope

1

s

Integrator

Kp_v

Gain2

Ki_x

Gain1

Kp_x

Gain

du/dt

Derivative

loop function. The setup function simply initializes all of the variables used in the controller. Interrupts

are attached to each encoder pin, and they trigger on every change-of-state (falling edge or rising edge)

that occurs. This is how the number of ticks is counted for the control loop.

Using the equations in Figure 24 and the inputted distance & velocity values, a target distance

and a target velocity (in terms of ticks, and ticks per cm) are calculated. The motors are then driven with

the motor shield (using their library), with the level of gain changing every time through the controller

loop. Since the motors have started turning, the encoders start triggering interrupts, increasing the tick

counter. As the tick counter approaches the target distance value, the P/I controller slows the motors

down, and eventually the motors come to a stop.

The controllers must be calibrated for it to work properly. This is done by simply adjusting the

gain values in Figure 25 (Kp_x, Ki_x, Kp_v), which totally depend on the mechanics of the system being

used. Figure 26 displays the flow chart for the Arduino program functionality.

Figure 26 - Arduino Program Flow Chart.

Sleep

Exit Sleep Mode

UART

Data Sent?

Get Control Data

Calculate Distance,

Velocity, and Arc

Lengths for Target Angle

Move to Angle

Run Controller

Set Brakes,

Initialize Motors

New Data

Sent?

Reached Target

Distance?

Wait for Data for

30 seconds

no

yes

no

yes

yes no

Send Position

Estimation

Send Position

Estimation

Section 3 – Serial Communication:

Incoming Data Format (5 bytes total):

FR – Forward/Reverse Control:

1 – Forward

0 – Reverse

BRAKE – Stops the motors:

0 – Enable motors

1 – Disable motors

SOLCTL – Solenoid control bit:

0 – Disengage Solenoids

1 – Engage Solenoids

VH – MSB of Velocity

0xFFFF → Max velocity = xxxx

VL – LSB of Velocity

0xFFFF → Max velocity = xxxx

AH – MSB of Angle

0xFFFF → Max angle = 360 deg

AL – LSB of Angle

0xFFFF → Max angle = 360 deg

X X X X X FR BRAKE SOLCT

L VH

VH VL

AH AL

AL

Transmitting Data Format (4 bytes total):

DH – MSB of Displacement Estimate

DL – LSB of Displacement Estimate

AH – MSB of Current Angle Estimate

AL – LSB of Current Angle Estimate

Section 4 – Testing & Calibration:

The following video shows the reaction of the motor when the program is run. As a test, a program was

written to have the motor drive forward 10 cm, drive backward 20 cm, drive forward again 30 cm, and then pause

for 3 seconds before looping back and doing it again. The Serial terminal on the PC displays the tick counter that is

being used in the controller. The tick counter will never reach its target exactly; rather, the motor is set to stop once

the counter comes within ~100 ticks of its target (therefore, the error is less than 1 cm), in order to prevent the slow

approach to the exact target value.

WP_20150508_002.mp4

Implementation of ROS:

We were able to acquire an ODROID from Chris Crippen on 05/11/15 and have just begun the testing of

ROS. From what we have gathered in our brief encounters with the code, there seems to be a large

learning curve in setting up the ODROID for our required algorithms and implementation of cameras and

sensors. The bulk of Wednesday 05/13/15 will be spent delving further into ROS.

Future work will entail adapting ROS code to make the current C++, python, and XML code located on

the Pandaboard function on the more powerful ODROID unit. This summer will be spent debugging

ROS and attempting to create working source code for the Smart Walker.

DH

AH

DL

DL

AL

SLAM Subsystems:

As of 05/12/15, the emphasis on SLAM has been reduced until full internal functionality of the Walker

has been established. The strain gauge/ load cell, BMI, and heart rate testing has been the primary

concern of weeks 14 and 15 of MSD I. We have looked into multiple open source C++ SLAM

algorithms, but feel that if ROS is to be implemented for Smart Walker, that SLAM will be implemented

after ROS is functional.

Webcam:

Shown below is the link to the website for the webcam pulse sensor code:

https://github.com/thearn/webcam-pulse-detector

The code is developed by Tristan Hearn and his email contact information is here:

tristanhearn@gmail.com. The source code is written in python and there is an executable file for

windows 7 and 8, Mac OSX 10.6 (and later). There is no executable file for and Linux platform,

but the source code can be run using the command get_pulse.py.

In the website the source code is under the file name get_pulse.py. The raw code is shown at the

end of this section.

My understanding of the code is that it will only start to read the RGB color code of the person’s

forehead only when it has a captured forehead of the person’s face. To do this the user of the code

has to press the button S to start the capture. This will be a hassle for the Smart Walker because

there will be no keyboard to press the button and it would seem too robotic for our customer needs.

To counter act this problem a code can be written to start the @bin sequence when the panda gets

a reading from the strain gauges. This means that the S key is now being replaced with a true and

false statement that will only be true if the panda gets a reading from the strain gauges. This is

optimal because this will happen once the elderly uses the smart walker.

To stop the pulse sensor, a code can be written to press the S button again at the end of the day

where all the data that is collected on that day is “dumped” to a hard drive and sent to a facility.

And then the next cycle will begin once the smart walker is used again.

One thing to worry about is that the pulse code collects a fix forehead point and measures the RGB

bits from that point, I do not know how well it will measure the RGB bits if the person moves out

and then back into the fix position because it takes roughly 30 seconds to get a good bpm reading

from the code.

The heart rate outputs should contain 1 file output with time stamp and bpm data in the xml file.

e.g.: XX XX:XX:XX

XX XX:XX:XX

XX XX:XX:XX

XX XX:XX:XX

XX XX:XX:XX

XX XX:XX:XX

Figure 27 shown below is the flow chart that he has made for the code to follow. But what we need

for the Smart Walker is only the measure heart rate portion of the code. There is no need to display

any graphs or display any captured face from the Pandaboard. The next figure following Figure 27

will be the revised flow chart that will include when the data is collected and where the data needs

to flow to.

Figure 27 – Raw Flow Chart by Tristan Hearn.

Figure 28 is the revised flow chart. As stated above the webcam will only start its @bin command

when there is a reading from the strain gauges. After the code starts to run, the heart rate data will

be extracted and will keep updating until the system stops using a time stamp. The time stamp

should be at least 10 minutes before all the data is “dumped” into the hard drive. This will give the

panda enough time to extract the xml file that contains all the bpm data of the user from that day.

Figure 28 – Revised Flow Chart.

Strain gauge reading from

pandaboard

RGBsplitter

Grab_foreheads

fft

measure_heart

input

grayscale

Contrast_eq

find_faces

output to xml file

Figure 29 is a demo of the code on Windows 7. Figure 29a is the file before pressing the lock

button, S button. Here it is constantly scanning for the face and the forehead where it will collect

data. Figure 29b is the code after locking onto the forehead. After a 30 second wait the estimated

heart rate is shown in bpm above the locked forehead.

Figure 29 – (a) Left before Lock (b) Right after Lock and Count Down

Figure 30 is the graphed bpm after the locking. The top waveform is a graph of raw optical density.

By measuring the average of the optical density in the forehead location (green wavelengths), a

physiological data can be estimated. The bottom waveform is the power spectral density graph.

The average of these two waveforms gives the bpm measurements which are shown as the number

below the greyscale picture.

Figure 30 – Waveforms Generation after Forehead Lock In

The code itself is very well documented. The first section checks to see if the webcam is connected

and also it contains the line of code that will handle all image & signal analysis. The bulk of the

code to run the analysis is shown below the “def plot” section of the code.

Future Works:

To modify the code so that it will automatically start once it reads a data coming from the

pandaboard. Ultimately it needs to be tied into the strain gauge data input. It also needs a stopping

code that will match up with the timestamp of the pandaboard. I will be working of modifying the

code this summer so that it can be up and running for testing in the fall.

Raw Heart Rate Code:

By: Tristan Hearn

from lib.device import Camera

from lib.processors import findFaceGetPulse

from lib.interface import plotXY, imshow, waitKey,destroyWindow, moveWindow

import numpy as np

import datetime

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

#Imaging device - must be a connected camera (not an ip camera or

mjpeg

#stream)

self.camera = Camera(camera=0) #first camera by default

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 = "Cardiac info - raw signal, filtered signal, and

PSD"

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

"f" : self.write_csv

def write_csv(self):

"""

Writes current data to a csv file

"""

bpm = " " + str(int(self.processor.measure_heart.bpm))

fn = str(datetime.datetime.now()).split(".")[0] + bpm + " BPM.csv"

data = np.array([self.processor.fft.times,

self.processor.fft.samples]).T

np.savetxt(fn, data, delimiter=',')

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

if not state:

self.processor.fft.reset()

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"

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.fft.times,

self.processor.fft.samples],

[self.processor.fft.even_times[4:-4],

self.processor.measure_heart.filtered[4:-4]],

[self.processor.measure_heart.freqs,

self.processor.measure_heart.fft]],

labels = [False, False, True],

showmax = [False,False, "bpm"],

label_ndigits = [0,0,0],

showmax_digits = [0,0,1],

skip = [3,3,4],

name = self.plot_title,

bg = self.processor.grab_faces.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..."

self.camera.cam.release()

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

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

#handle any key presses

self.key_handler()

if __name__ == "__main__":

App = getPulseApp()

while True:

App.main_loop()

Xtion

The flowchart shown below is the mapping of the xtion camera. It starts the mapping from the

distress signal it receives from either a fit-bit or a chronos watch. Then it will look into SLAM to

see if there were any previous mappings and if there is then it will load that previous map and then

move towards the distress person using that map. If not then it will make the Xtion scan in front

of it and capture its depth values for each frame. The pixels from each frame will be analyzed into

a 2x2 matrix block. There will be three frames and these frames will be used to create the mapping

for SLAM.

yes

no

no

no

yes

yes

yes

no

SW has

fallen

Program

Start

Initialize

variables

do I know

location?

Previous

map?

Load map

Scan in front

no

no

yes

yes

Capture Depth

Frame from

Xtion

Look at pixel

depth values

Is pixel too

close?

Is next pixel

too close?

Previous columns

marked?

Was same 2x2

block marked

for last 3 frames

Mark current

columns as a block

in the current frame

no

Last pixel

row?

no

Last row

of frame?

yes

Go to next

row

Update Map

There is code from Smart Walker II that was said to compute the 2x2 matrix that contains the information need

to be implemented in SLAM. The code is written by Dan Mei and certain portions of the code was said to have

been demonstrated and working, but I have no dived too deep into the code since it did not contain good

documentations in the code itself.

Future Works:

To verify the section of the code that works and have that portion complied and results in an xml file. The code

will then be compiled as a header so that it can be ready for SLAM interfacing. Ultimately I want to this code to

be compatible with a simple SLAM algorithm and show a mapping using the SLAM algorithm. I will be diving

in this code over the summer and have a working Xtion depth extraction code for the fall.

Smart Walker II – Xtion Navigation Code

By: Dan Mei

#include <boost/thread/thread.hpp>

#include <string>

#include <sys/types.h>

#include <signal.h>

#include <iostream>

#include "SmartWalker.h"

#include "Navigation.h"

#include "Vitals.h"

#include "SharedMutex.h"

#include "Communication.h"

// Initialize static member flag

int SmartWalker::fallDetected;

// Scoped declaration of extern

boost::mutex mutexCOM;

using namespace std;

SmartWalker::SmartWalker()

this->pid = 0;

string afn = "data/accel_data.txt";

string hrfn = "data/hr_data.txt";

string tfn = "data/temp_data.txt";

string altfn = "data/alt_data.txt";

string strfn = "data/strain_data.txt";

this->nav = new Navigation();

this->vitals = new Vitals(afn, hrfn, tfn, altfn, strfn, 0, 0, 0);

void SmartWalker::run()

cout << "Starting ... " << endl;

//Check strain ages

// while(Communication::ReadFromDevice("Strains") < thresholding)

// Start collection threads

//int watchPID = this->runWatch();

//int hrPID = this->runHR();

// int strainPID = ....

float curData[3] = 0, 0, 0;

//this->runNav();

// Associate SIGUSR2 events with a fall detection

signal(SIGUSR2, fallHandler);

while(1)

char msg[5] = 0xD6, 0x09, 0x00, 0x00, 0x00;

char stopmsg[5] = 0xD5, 0x19, 0x00, 0x00, 0x00;

Communication::SendToSerialDevice("Arduino", msg);

sleep(1.5);

char msg1[5] = 0xD6, 0x19, 0x00, 0x00, 0x00;

Communication::SendToSerialDevice("Arduino", msg1);

sleep(1.5);

char msg2[5] = 0xD6, 0x29, 0x00, 0x00, 0x00;

Communication::SendToSerialDevice("Arduino", msg2);

sleep(1.5);

char msg3[5] = 0xD6, 0x39, 0x00, 0x00, 0x00;

Communication::SendToSerialDevice("Arduino", msg3);

sleep(1.5);

char msg4[5] = 0xD6, 0x49, 0x00, 0x00, 0x00;

Communication::SendToSerialDevice("Arduino", msg4);

sleep(1.5);

Communication::SendToSerialDevice("Arduino", stopmsg);

Communication::ReadFromI2CDevice("IMU", curData);

cout << to_string(curData[0]) << " " << to_string(curData[1])

<< " " << to_string(curData[2]) << endl;

sleep(1.5);

//if(SmartWalker::fallDetected)

//

// TODO: If IMU indicates fall, send report

// if(1)

//

// this->vitals->parseToXML("data/data.xml");

// SmartWalker::fallDetected = 0;

//

//

/*

double hrsr = 1.0; // Sample rate for the hr algorithm.

bool user_present = false;

bool walker_upright = false;

bool hr_running = false;

bool watch_running = false;

float threshhold = 0.0; // Thresh hold value for user presence.

float* strainData = new float[2]; // Strain data from handles. Remember to

delete!

float* imuData;

int camPID; // Process id for the webcam algorithm thread.

int watchPID; // Process id for watch thread.

// Check initial state and if user is present

Communication::ReadFromI2CDevice( "Strains", sdata );

if( strainData[0] >= threshhold && strainData[1] >= threshhold )

user_present = true;

else

user_present = false;

Communication::ReadFromI2CDevice( "IMU", imuData );

// TODO: How to tell if walker is upright?

if( 0 )

walker_upright = true;

else

walker_upright = false;

while(true)

while( !user_present )

// Check Strain gauges for data. If there is data

// above the thresholds then user is present.

Communication::ReadFromI2CDevice( "Strains", sdata );

if( strainData[0] >= threshhold && strainData[1] >= threshhold )

user_present = true;

else

user_present = false;

if( !hr_running )

// Start heart rate algorithm.

camPID = this->runHR(hrSampleRate);

hr_running = true;

if( !watch_running )

// Run the watch driver.

watchPID = this->runWatch();

watch_running = true;

if( SmartWalker::fallDetected )

user_present = false;

// Check Strain gauges for data. If there is data

// then user is present.

Communication::ReadFromI2CDevice( "Strains", sdata );

if( strainData[0] >= threshhold && strainData[1] >= threshhold )

user_present = true;

else

user_present = false;

if( user_present )

// Check IMU for data. If there is data

// then walker is upright.

Communication::ReadFromI2CDevice( "IMU", imudata );

// TODO: How to tell if walker is upright?

if( 0 )

walker_upright = true;

else

walker_upright = false;

if( hr_running )

// Generate report.

this->vitals->parseToXML("data.txt");

this->killHR(camPID);

hr_running = false;

while( !walker_upright )

Communication::ReadFromI2CDevice( "IMU", imudata );

// TODO: How to tell if walker is upright?

if( 0 )

walker_upright = true;

fallDetected = false;

else

walker_upright = false;

else

sleep(5);

// Check IMU for data. If there is data

// then walker is upright.

Communication::ReadFromI2CDevice( "Strains", sdata );

if( sdata[0] >= threshhold && sdata[1] >= threshhold )

user_present = true;

else

user_present = false;

if( !user_present )

// Generate report.

this->vitals->parseToXML("data.txt");

if( hr_running )

this->killHR(camid);

hr_running = false;

//start navigation

this->runNav();

else

//start navigation

this->runNav();

*/

// Clean up threads

cout << "Killing ... " << endl;

//this->killNav();

//this->killHR(hrPID);

void SmartWalker::fallHandler(int param)

// Set internal fall flag

SmartWalker::fallDetected = 1;

void SmartWalker::runNav()

this->navThread = boost::thread(boost::bind(&Navigation::begin,

*(this->nav)));

int SmartWalker::runHR(double sampleRate)

int pid = fork();

if(pid != 0)

return pid;

// Child process: run heartrate script and then exit

else

// Need to add handler here to raise SIGINT to python process

string cmd = "python drivers/simHR.py ";

cmd += this->vitals->getHRFName();

cmd += to_string(sampleRate);

int result = system(cmd.c_str());

// If something goes wrong with running the heartrate

// script, notify the main thread on SIGUSR1

if(result == -1)

kill(getppid(), SIGUSR1);

exit(0);

int SmartWalker::runWatch()

int pid = fork();

this->pid = getppid();

// Parent process: set parent PID and return child PID

if(pid != 0)

return pid;

// Child process: run heartrate script and then exit

else

sleep(.2);

string cmd = "python drivers/ChronosDriver.py ";

cmd += this->vitals->getAccelFName();

cmd += " " + this->vitals->getAltFName();

cmd += " " + to_string(this->pid);

cout << cmd << endl << endl << this->pid << endl;

// Fall detection flag

static int fallDetected;

int result = system(cmd.c_str());

// If something goes wrong with running the heartrate

// script, notify the main thread on SIGUSR1

if(result == -1)

kill(getppid(), SIGUSR1);

exit(0);

void SmartWalker::killHR(int pid)

cout << pid << endl;

int res = kill((pid_t)pid, SIGINT);

cout << res << endl;

void SmartWalker::killNav()

this->navThread.interrupt();

int main(int argc, char* argv[])

SmartWalker* walker = new SmartWalker();

walker->run();

delete(walker);

return 0;

BMI:

The link shown below is a website that contains a circuit schematic that is said to measure the bioimpedance of a

person. The researchers for this publication are Aroom KR, Hatring MT, Cox CS Jr, Radharkrishnan RS, Smith

C, Gill BS.

http://www.ncbi.nlm.nih.gov/pubmed/18805550

Figure C.5 shown below is the schematic that is provided in the websites publication of this project. It says that

you need to request permission in order to reuse it. I have no contacted the person that handles this matter for the

NCBI. I hope to get this circuit simulated and given reasonable results and then I’ll make a PCB layout if the

simulation results are within the correct ranges.

The circuit was run using low input current of around 500 uA. The usual single frequency applied with this current

is around 50 kHz, but the publishers tested the circuit around frequencies between 1 and 100 kHz. This should

mean that it should run at 50 kHz since it falls within the range that it was tested at.

If the bioimpedance of the circuit can be accurately calculated the next step is to store this data in the pandaboard

and do some plug and chug into equations so that the BMI can be calculated. The equations are shown below.

Equation C.1 shown below will calculate the total body water (TBW) in the user. This TBW can be used to

estimate the fat-free mass (FFM).

𝑇𝐵𝑊 = 0.372 (𝑆2

𝑅) + 3.05(𝑆𝑒𝑥) + 0.142(𝑊) − 0.069(𝐴𝑔𝑒) (𝐶. 1)

S = height of the person (cm)

R = bioimpedance (Ω)

W = weight (kg)

Age = in years (yr)

Sex = 1 for males and 0 for females

TBW will be in units of kg

Equation C.2 is used to calculate the FFM of the person.

𝐹𝐹𝑀 =𝑇𝐵𝑊

0.73 (𝐶. 2)

The next step is to calculate the fat mass of the user using Equation C.3

𝐹𝑀 = 𝑊𝑒𝑖𝑔ℎ𝑡 − 𝐹𝐹𝑀 (𝐶. 3)

Lastly arriving to the final step is to calculate the percent body fat using the FM shown in Equation C.4.

% 𝐵𝑜𝑑𝑦 𝐹𝑎𝑡 =𝐹𝑀

𝐵𝑜𝑑𝑦 𝑊𝑒𝑖𝑔ℎ𝑡∗ 100% (𝐶. 4)

These equations will be used to create a code that will take the bioimpedance and give a body fat percentage. The

body fat percentage will be complied in an xml file and be “dumped” in the hard drive along with all the other

data that was collect at the end of the day.

The reference link for these equations is shown below from an online tutorial:

http://nutrition.uvm.edu/bodycomp/bia/lesson4.html

Future Works

I hope to get the simulations completed by the end of this week so that after my Wednesday final I will have time

to create a PCB layout of the circuit and then get it ordered from MSD office. That would be an ideal situation to

end MSD I with because once the board comes in I can work populate the board in MSD II and test the PCB to

make sure that it was layout correctly.

Figure C.5 – Bioimpedance Circuit