KGCOE MSD Page 1 of 62 Technical Review Agenda KGCOE MSD Technical Review Agenda Meeting Purpose: Detailed design review for Smart Walker II (P14041.) The purpose of this meeting is to present the final design of the system for entering into MSD II and receive feedback on the proposed design. Meeting Date: May 13, 2014. Meeting Location: James E. Gleason Hall (09) - Rm. 4435 Meeting Time: 14:00 (2:00 PM) Meeting Timeline Time Topic of Review Required Attendees Introduction ● Project Overview ○ Project Background ○ Problem Statement ● Customer Needs / Engineering Requirements Matrix ● Intended Deliverables ● Risk Assessment Prof. Slack, Dr. Sahin, Dr. Becker-Gomez, Mechanical Engineering ● Complete Walker Design ● Mechanical Analysis ○ Strain Gage Placement Handle ○ Strain Gage Placement Seat ○ Motor Shafts ● New Design Concepts ○ Backrest w/Integrated Camera ○ Xtion Mount ○ Micro-Controller Housing ○ Basket w/Micro Housing ○ Wheel Shroud ○ Clutch Design ○ Motor/Clutch Integration ○ Motor/Clutch/Wheel Assembly Prof. Slack, Dr. Sahin, Dr. Becker-Gomez, Electrical Engineering ● High-level wiring diagram ● Schematics and Component Information ○ Power Distribution ○ Strain Gage Measurement / ADC ○ Motor Driver / Motor Interconnections ○ Main Control Unit Components and Interconnections ○ Inertial Measurement Unit ○ TI ez430 Chronos Prof. Slack, Dr. Sahin, Dr. Becker-Gomez, Computer Engineering ● Software Design ● Interprocess Communication for Fall Detection ● Library Selection ● Software Verification ● Data Formates and XML Report ● Concerns about SLAM Prof. Slack, Dr. Sahin, Dr. Becker-Gomez,
62
Embed
KGCOE MSD Technical Review Agendaedge.rit.edu/content/P14041/public/Documentation/Design_Meetings/... · KGCOE MSD Page 7 of 62 Technical Review Agenda Current Walker Design: As seen
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
KGCOE MSD Page 1 of 62 Technical Review Agenda
KGCOE MSD Technical Review Agenda
Meeting Purpose: Detailed design review for Smart Walker II (P14041.) The purpose of this meeting is to
present the final design of the system for entering into MSD II and receive feedback on the
proposed design.
Meeting Date: May 13, 2014.
Meeting Location: James E. Gleason Hall (09) - Rm. 4435
Meeting Time: 14:00 (2:00 PM)
Meeting Timeline
Time Topic of Review Required Attendees
Introduction Project Overview
Project Background
Problem Statement
Customer Needs / Engineering Requirements Matrix
Intended Deliverables
Risk Assessment
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez,
Mechanical Engineering Complete Walker Design
Mechanical Analysis
Strain Gage Placement Handle
Strain Gage Placement Seat
Motor Shafts
New Design Concepts
Backrest w/Integrated Camera
Xtion Mount
Micro-Controller Housing
Basket w/Micro Housing
Wheel Shroud
Clutch Design
Motor/Clutch Integration
Motor/Clutch/Wheel Assembly
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez,
Electrical Engineering High-level wiring diagram
Schematics and Component Information
Power Distribution
Strain Gage Measurement / ADC
Motor Driver / Motor Interconnections
Main Control Unit Components and Interconnections
Inertial Measurement Unit
TI ez430 Chronos
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez,
Computer Engineering Software Design
Interprocess Communication for Fall Detection
Library Selection
Software Verification
Data Formates and XML Report
Concerns about SLAM
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez,
KGCOE MSD Page 2 of 62 Technical Review Agenda
Appendix Bill of materials
MSD I to II schedule
Prof. Slack, Dr. Sahin, Dr.
Becker-Gomez, Prof. Indovina
Introduction
Project Background The “smart walker” is a mobile robotic system aimed at assisting the elderly who use a regular walker during their daily
lives, capable of collecting information about an individual’s health and functionalities. This will enable the patient’s
caretakers to carefully monitor their health from a remote location and even make preemptive healthcare decisions. There
have been other “smart walkers” researched, but the struggle has been to develop one which is unobtrusive and appealing
to a user. Previous attempts at designing a “smart walker” have been deemed too “robot-like” to be accepted by users.
Problem Statement The current Smart Walker prototype has been deemed too bulky and obtrusive for use in assisted living facilities. The goal
of Smart Walker II is to design a walker with the capabilities to collect information about the user’s health and
functionalities (heart rate, temperature, etc.) without appearing robotic. The walker will be designed to be mobile, semi-
autonomous, and able to prevent and detect falls, and be capable of locating patients in its immediate environment.
from the +5 V rail; while in autonomous mode (walker seeks out user) the MCU and motor driver microcontrollers will be
actively engaged in navigational and processing tasks. During this time, the MCU (Pandaboard ES) will draw a maximum
800 mA, while the motor driver (Arduino Uno with Pololu dual-channel motor shield) will draw a maximum of 200 mA.
Since the motors are driven directly from the +12 V battery, their peak and running current will not contribute to the stress
on the MC34063A IC.
Figure E.3 - Simulated switching regulator response to +12 V input
Figure E.4 - Simulated switching regulator power in and power out for transient and steady states
KGCOE MSD Page 26 of 62 Technical Review Agenda
Efficiency is calculated as the ratio of power out to power in, where the efficiency of the Buck Converter shown in Figure
E.2 approaches 99%, as shown in Figure E.4. The original Smart Walker prototype utilized a single linear regulator to
step down the battery voltage, at the cost of efficiency. Linear regulators often have power efficiency around 30%. The
Buck Converter design utilizing the MC34063A integrated circuit triples this efficiency at only a small cost to complexity
and required discrete elements.
KGCOE MSD Page 27 of 62 Technical Review Agenda
Motor and Motor Driver System:
Motor control will be handled via an Arduino Uno utilizing an Atmel Atmega16 microcontroller with a third-party, dual-
channel “shield” that attaches inline to the Arduino. The dual-channel motor controller attachment uses two
STMicroelectronics VNH5019A-E H-bridge integrated circuits. The truth table defining the logic functions for the H-
bridge IC is shown in Table E.5, where a logic high (1) is defined by a voltage greater than 2.1 V and a logic low (0) is
defined by a voltage less than 0.9 V. The schematics for the Arduino Uno and Pololu dual channel motor driver are shown
in Figure E.7 and Figure E.8, respectively.
INA INB OUTA OUTB Operating Mode
1 1 H H Brake to VCC
1 0 H L Clockwise (CW)
0 1 L H Counter-clockwise (CCW)
0 0 L L Brake to GND
Table E.52 - H-bridge truth table for normal operating conditions
The general software flowchart for the motor controller operating in autonomous mode is shown in Figure E.9. Note that
the Walker will only engage in autonomous mode when attempting to localize the user. When the Arduino receives
navigational data from the main control board via I2C, it will jump out of the idle loop and begin processing motor
driving commands.
The general motor, encoder, and motor controller interconnection schematic is shown in Figure E.10. The Pololu 50:1
metal gearmotor selected for use on Smart Walker II comes with a 64 counts-per-revolution quadrature encoder, which
allows for the motor controller to utilize dead-reckoning odometry strategies when attempting to localize itself in an
unknown environment.
Table E.6 highlights the electromechanical characteristics and maximum ratings of the motors and associated components.
Stall Torque (at 12 V) 1.2 Nm
Stall Current (at 12 V) 5 A
Gear Ratio 50:1
Unloaded Freerun Speed 200 RPM
Maximum PWM Frequency 24 kHz
Table E.6 - Electromechanical characteristics of motors and associated components
2 STMicroelectronics. VNH5019A-E Datasheet.
KGCOE MSD Page 28 of 62 Technical Review Agenda
Figure E.9 - Motor control software flowchart
The general motor, encoder, and motor controller interconnection schematic is shown in Figure E.10. The Pololu 50:1
metal gearmotor selected for use on Smart Walker II comes with a 64 counts-per-revolution quadrature encoder, which
allows for the motor controller to utilize dead-reckoning odometry strategies when attempting to localize itself in an
unknown environment.
KGCOE MSD Page 29 of 62 Technical Review Agenda
Figure E.10 - Motor, encoder, and motor controller interconnection
KGCOE MSD Page 30 of 62 Technical Review Agenda
Main Control Unit Components and Interconnections:
Figure E.11 shows the overall schematic for connecting various sensors and peripherals to the main control unit (MCU), the PandaBoard ES.
Figure E.11 - MCU interconnection schematic
J3 in Figure E.11 comes from an array of ADS7229 analog-to-digital converters (ADC.) Figure E.12 shows a typical configuration for a single ADC, where the analog input is the output of the instrumentation amplifier shown in Figure E.5.
Figure E.123 - Typical configuration circuit for ADS7229
3 Texas Instruments. ADS7229, ADS7230 Datasheet.
KGCOE MSD Page 31 of 62 Technical Review Agenda
Figure E.13 shows the timing diagram for the ADS7229 during conversion and acquisition cycles for auto-triggering
mode.
Figure E.134 - ADC timing diagram for read-while-converting during auto-triggering events
The MCU acts as the host processor for the ADS7229 array, where the 24 MHz OMAP processor system clock acts as the
input system clock for the ADCs.
Table E.6 shows the ideal input voltages and output codes for the ADS7229.
Table E.6 - ADS7229 ideal voltages and output codes
The ADS7229 also features an automatic power-down and nap mode when not in use.
4 See 8
KGCOE MSD Page 32 of 62 Technical Review Agenda
Inertial Measurement Unit:
In order to provide a degree of redundancy and error correction in the odometry readings for the navigation system, an external, 9 degree-of-freedom (DOF) inertial measurement unit (IMU) will communicate real-time acceleration, velocity, and
orientation information to the MCU via an I2C connection. The IMU to be used on Smart Walker II comes custom-built from RIT’s own Robotics Option; it relies on the STMicroelectronics L3GD20 3-axis gyroscope integrated circuit and the
LSM303DLH 3-axis accelerometer/magnetometer integrated circuit. Figure E.14 shows the slave I2C timing diagram for both ICs. The schematic for the RIT-RO IMU is shown in Figure E.15.
Figure E.145 - IMU I2C slave timing diagram
Figure E.156 - IMU Schematic
5 STMicroelectronics. LSM303DLH Datasheet. 6 Rochester Institute of Technology. 9 DOF Inertial Measurement Unit Datasheet.
KGCOE MSD Page 33 of 62 Technical Review Agenda
Texas Instruments ez430 Chronos:
The Texas Instruments ez430 Chronos is a wireless, integrated development platform based on the popular CC430
microcontroller. The Chronos, shown in Figure E.16 with USB programming and RF modules, offers sub-GHz wireless
communication capabilities along with a varied collection of biometric sensors, including: a 3-axis accelerometer, a
temperature sensor, a pressure sensor, and a battery voltage meter. Additionally the Chronos has the ability to control and
communicate with other wireless biometric sensors, such as: heart-rate monitors, pedometers, etc.
Figure E.167 - Texas Instruments ez430 Chronos with USB programming and RF communications module
For the Smart Walker II, the Chronos will be used as a way to monitor the patient, both for passive information (body
temperature) and for event-based information (an emergency.) The onboard 3-axis accelerometer will be able to detect
sudden changes in a user’s motion, indicating an emergency event, such as a fall. Figure E.17 shows the accelerometer
output under sudden-impact conditions. In the event of a fall, or similar perceived emergency, a buzzer on the watch will
sound for 15-30 seconds, where the user is given the option to cancel the alert in the situation that the alarm was false. If
the user does not cancel the alarm, a general alert would be sent out to the user’s caregivers and the Walker would receive
a command to engage in autonomous mode and seek out the user. Additionally, the user will have the ability to call an
emergency manually by pressing a button on the watch. Figure E.18 shows the Chronos’ software flowchart.
Figure E.17 - Sample accelerometer output under sudden fall conditions
7 Texas Instruments. ez430 Chronos Users’ Guide.
KGCOE MSD Page 34 of 62 Technical Review Agenda
Figure E.18 - Software flowchart for the ez430 Chronos in use with Smart Walker II
KGCOE MSD Page 35 of 62 Technical Review Agenda
In the occasion that an emergency occurred and an alert was sent out, there is an option to turn off the alert on the walker
itself in the form of a button in case the patient was taken away with the watch.
Computer Engineering
Software Design
The first iteration of the SmartWalker’s central system was a single-thread program that heavily relied on the powerful i7
processor in the SBC for consistent operation. The goal of this redesign was to create a more optimal system that would
lower the hardware requirements and cost, reduce bloat, and simplify development for future iterations.
There are many problems with having a single-thread program handling a large quantity of tasks. Data acquisition,
navigation, and vital functionality were all packaged in the same thread. The immediate concern with this was the
navigation algorithm. A SLAM algorithm, such as the one to be implemented on this walker, generally would be given a
dedicated core on the processor due to the intensive processing requirements and need for precise timing. To circumvent
this issue, our system was designed as a multi-process system. Data acquisition is divided amongst four different
processes; one for Chronos data, one for the heart rate algorithm and webcam, one for strain gage data, and the main
process which takes encoder data during navigation in “Autonomous mode” for use within the SLAM algorithm. Initially
it was planned that the navigation algorithm would be forked off of the main process when needed, but after later designs
moved a majority of the data acquisition to separate processes within the OS, it was decided that navigation would simply
remain within the main program. By increasing code parallelism in this way, the hardware requirements of the system
were cut down significantly, allowing the use of the Pandaboard ES, which utilizes an ARM 9 dual core chip. This board,
chosen from a group of 4 candidate boards in a Pugh matrix for its powerful CPU and wide array of I/O options, delivers
the necessary computing power at a fraction of the cost and physical profile of the previous system’s main computational
The main program was designed using an object-oriented approach. The first step of this process was to create a state
diagram (Figure C.2 on next page) to convert the abstract, high-level program behavior into logical, programmable steps.
The state diagram details every step of the main program’s operation. This diagram allowed the system to be viewed as a
behavioral plot, making the next step - determining what functional subsystems would be needed - much easier.
The software subsystems were determined to be the “Vitals”, which handled reading and presenting collected vital data on
the user in an XML format; “Communications”, which dealt with sending and receiving commands and data to the
Arduino and IMU as well as taking strain and watch data for basic operation; and “Navigation”, which handles
autonomous navigation using SLAM. These subsystems were each allocated a class in the main program to create a
logical modularity that would simplify future maintenance and code development without bloating the system. Once these
classes were determined, the necessary attributes and functions they would need to complete their tasks was determined
and used to create a UML block diagram of the main program. The UML block diagram will be the main template for
writing the Smart Walker II’s central control program, as it details exactly what needs to be written once coding begins.
KGCOE MSD Page 37 of 62 Technical Review Agenda
Figure C.2: State diagram of main program
KGCOE MSD Page 38 of 62 Technical Review Agenda
Once this block diagram was completed, it was used in conjunction with the state diagram to create two UML sequence charts. UML sequence charts are used for
specific use cases to identify unexpected complications within a system. They were chosen in this case to address concerns over timing issues within the cases of a
user fall being detected and a user leaving the walker. Timing issues were discovered and corrected, and there were no other scenarios in which timing concerns
arose.
KGCOE MSD Page 39 of 62 Technical Review Agenda
Figure C.3: UML sequence chart of “User Fall” scenario Figure C.4: UML sequence chart of “User Leaves” scenario
KGCOE MSD Page 40 of 62 Technical Review Agenda
Once the main program design was resolved, focus was shifted to peripheral communications. The first step in this stage
of the design was figuring out how data collection processes would communicate with the main program. Sockets were
initially considered as they were simple to implement and much faster than file storage. However, using sockets would
require storing all collected data locally within the main process and consume valuable processing power that could be
allocated to navigation instead. It was determined that it would be much better to store collected data in a non-volatile
format through files. If a system failure was to occur data would not be lost and all data storage would instead offload to
the file system. Additionally, because creation of reports will only occur during emergency events or at a specified hourly
rate (Defaulting to every 24 hours), the files containing that data would be accessed very rarely, eliminating concerns
about slow access times.
Because the drivers will all be running as separate processes, there was a degree of freedom allowed in determining which
languages would be used to write them. Generally the language choice was limited by what libraries were available to
provide necessary functionality. Were there enough time, all drivers would be written in C++ and any needed libraries
would be ported, but the time constraints on such a task are well beyond the scope of this project. Because the
development environment will be a Debian Linux build, we were mostly limited to open-source libraries. For the heart
rate algorithm, only a single effective Python library was found, and thus the webcam driver was decided to be written in
Python. The output of the strain gages’ ADC interface is connected through GPIO; C++ operates at a low level and
therefore was the best choice for the strain gage driver language. Finally, C++ will be used for the Chronos watch drivers
as the watch interfaces with USB and thus does not have any client-side restrictions on language.
Figure C.5: Data flow diagram showing how data is transmitted through the system
KGCOE MSD Page 41 of 62 Technical Review Agenda
Inter-process Communication for Fall Detection
The multitude of separate processes present in the Smart Walker II’s code design makes communication between
peripherals and subsystems more complex as none of the processes exist in the same allocated space and thus do not share
memory. This becomes an issue when dealing with user fall detection as the data acquisition is placed in a different
process than the fall detection handling. Files in non-volatile storage are too slow for a time-sensitive event such as a fall.
To resolve this issue, Linux’s signal variables SIG_USR1 and SIG_USR2 will be used to set flags indicating a fall has
occurred. These flags exist within the operating system, meaning that all processes are able to access them, and they are
specifically for developers to use.
Library Selection
Library selection was an important aspect of designing this system. As part of the objectives of this redesign was to reduce
code bloat, determining what libraries to use was important to ensure that the system would not expand during
implementation due to unexpected library dependencies.
For the main program, it was decided that five external libraries will be used. The first, Mutex, which allows mutually
exclusive threading, will be used to spawn a separate navigation thread from the main program as well as allow the parent
thread to wait upon the SIG_USR1 signal for the fall detection flag. Were Mutexes not used for this and a process was
instead forked, the parent process would waste valuable clock cycles polling SIG_USR1 for an update. The second
library is PugiXML, which will be used in the Vitals class’s parseToXML() function to take data from all of the data files
and write it to an XML. PugiXML was chosen over another C++ library, TinyXML, because benchmarking showed that it
ran approximately 3 times faster and was much more compact. The final libraries that will be necessary are the OpenNI,
sensor-bin-linux-arm, and nite-bin-linux-arm libraries that are necessary for the Xtion to function. The Navigation
algorithm may also require libraries, but as it will not be completed until the Smart Walker’s development has begun, no
speculation can be made.
The heart rate algorithm will use the open-source library “webcam-pulse-detector”. This was the only webcam-based
pulse detection library found, and has dependencies on the OpenMDAO, OpenCV, and numPy libraries. All other drivers
were not determined to require any other outside libraries.
Software Verification
To verify that all of the devices worked with a Linux system, a simple driver was written for each. Unfortunately, because
no Pandaboard ES was available, all testing had to be performed on a Beaglebone. The Beaglebone was chosen because it
is the closest MCU to the Panda having been developed by the same company.
KGCOE MSD Page 42 of 62 Technical Review Agenda
Figure C.6: Demo of heart rate algorithm and library
Figure C.7: Code and demo of TI Chronos watch accelerometer
KGCOE MSD Page 43 of 62 Technical Review Agenda
Data Formats and XML Report
Data types were decided based on the output format of the device the data is being received from.
IMU and accelerometer data will each be stored in a vector of three doubles, each representing rotations around the X, Y,
and Z axes. The range of values for this data is 0 – 360. These values represent coordinate values which can be used to
interpret falls when there is great change at a given time interval.
Strain gage data will be stored in a vector of six doubles. There are two different strain gage data; a set for the seats (four
data values) and a set for the handles (two data values).
- The range seen from the seat strain data would be 0V – 5V (equivalent range of 0-294lb) and a lookup table
can be used to find the corresponding weight (mass in kg) being applied to the strain (See Appendix). This
can then be used to determine where pressure sores are most likely to develop.
o The number of bits required to meet the specifications is 7 bits.
The calculation is as follows:
Max value determined to be 294lb equivalent to 80kg.
Log2(80kg/0.25kg) = 7 bits
- The range seen from the handle strain data would be 0V – 5V (equivalent range of 0-80lb) and a lookup table
can be used to find the corresponding weight (mass in kg) being applied to the strain (See Appendix). This
information can be used to see how the person leans (how much weight is biased to one side) and then use to
correct the persons posture.
o The number of bits required to meet the specifications is 5 bits.
The calculation is as follows:
Max value determined to be 80lb equivalent to approximately 8.16kg.
Log2(8.16kg/0.25kg) = 5 bits
The heart rate will stored as a float as the heart rate algorithm being used returns values ranging from roughly 40 to 120
with a tenth decimal precision. The units are in Beats Per Minute (BPM).
The temperature will be stored as a double. The typical values seen are 0, 95 – 110. A value of 0 would mean that the user
does not have the watch on. A range of 95-110 are possible ranges of a human body whether the person is sick or healthy.
The units are in Fahrenheit.
A fall event is also added to the xml data as it indicates a user fall. The values for this data is just yes or no.
The velocity of the walker will be represented as a float, while the encoder count will be represented as an integer.
Finally, the walker’s position in its environment will be stored as a vector of three floats, each representing X, Y, and Z
position.
This data will be stored in files with the “.data” extension as plaintext. Each of these files will store all readings of a single
data type for 24 hours, after which the program will overwrite all existing data and begin anew. Data readings will be
stored with a value and a corresponding time at which the reading was taken and will be parsed out of the file by the
program using regular expressions during XML creation.
The XML report format was chosen keeping the designer of XSLT report transforms in mind. It was decided that, because
data will be time sensitive, it would be most logical to separate readings, represented as <reading/> nodes, into groups
KGCOE MSD Page 44 of 62 Technical Review Agenda
based upon which type of data the reading represents (Heart rate, strain data, etc.). These groups have an attribute in the
parent node representing the sample rates at which the data was recorded. Heart rate, temperature, and IMU data are all
represented by a single value, while strain gage values are broken up into 6 sub categories, each representing one of the 6
strain gages. Each reading node has a value and a start time associated with it, along with a value called
“numoccurrences”. This value is a form of preprocessing that allows compression of sequential readings with redundant
values into a single node. For every node compressed this way, the number of occurrences is incremented by one. In the
event of a fall, a FallEvent node is generated that records what triggered the fall as well as what time the fall occurred. It
was not deemed necessary to include more information in this node as all relevant data will already be present within the
XML. In the case of a fall, an emergency report will be sent immediately showing all data previous to the fall for that day.
The end of the day report following such an event will still contain the FallEvent node, but will also contain the rest of the
day’s data. (See Appendix)
Concerns About SLAM
There is a significant risk with using an algorithm that has not yet been implemented for SLAM. No benchmarks exist for
the algorithm resulting in a complete lack of information about the expected efficiency. This means that all decisions
about processing power with reference to the SLAM algorithm are based purely on previous knowledge and research on
the general properties of similar algorithms. There is no possible way to determine how to allocate space or even what
data types will be needed as inputs for SLAM to work properly. The most that can and will be done is to provide the
navigation a dedicated core on the Pandaboard’s ARM9 Dual Core processor. Beyond that, all performance improvements
must be achieved through the implementation itself in software. Additionally, because of a lack of SLAM, a basic stub
class will be implemented that mimics the anticipated outputs of SLAM with known values. This will allow consistent
behavior to test the system with.
KGCOE MSD Page 45 of 62 Technical Review Agenda
KGCOE MSD Page 46 of 62 Technical Review Agenda
KGCOE MSD Page 47 of 62 Technical Review Agenda
Data
Ports on Pandaboard Programs .data file XML file Comments
TI-watch
Temperature USB
Run separately from SWII
Celsius/Fah + time stamp
parsed into xml format using the data in .data file
3-axis data USB x,y,z data + time stamp
parsed into xml format using the data in .data file
Webcam
Heartrate USB
Run separately from SWII BMP + time stamp
parsed into xml format using the data in .data file
Strain gage system
Strain gages GPIO32-37
processed in the SWII application
Voltage value? maybe some processing?
parsed into xml format using the data in .data file
Consider using SPI over GPIO because bit banging is inefficient
Walker IMU system
Walker IMU I2C2_SDA
Data used in SWII to determine position of the walker
Arduino System
Encoder Count I2C4_SDA
Used in SWII for dead reckoning/navigation
Xtion Pro Live
video stream USB
video stream used/manipulates data to navigate
No category
Fall event generated in SWII boolean value
KGCOE MSD Page 48 of 62 Technical Review Agenda
TOTAL 1194.03
Bill of Materials
Item Quantity Cost per unit
($) Total cost ($) Vendor Part # URL Status Notes
Hugo Portable Rollater Walker with Seat and Back rest