Edge.rit.edu



KGCOE MSD Technical Review AgendaMeeting 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. 4435Meeting Time:14:00 (2:00 PM)Meeting TimelineTimeTopic of ReviewRequired AttendeesIntroductionProject OverviewProject BackgroundProblem StatementCustomer Needs / Engineering Requirements MatrixIntended DeliverablesRisk AssessmentProf. Slack, Dr. Sahin, Dr. Becker-Gomez, Mechanical EngineeringComplete Walker DesignMechanical AnalysisStrain Gage Placement Handle Strain Gage Placement Seat Motor ShaftsNew Design ConceptsBackrest w/Integrated CameraXtion MountMicro-Controller Housing Basket w/Micro HousingWheel ShroudClutch DesignMotor/Clutch IntegrationMotor/Clutch/Wheel AssemblyProf. Slack, Dr. Sahin, Dr. Becker-Gomez, Electrical EngineeringHigh-level wiring diagramSchematics and Component InformationPower DistributionStrain Gage Measurement / ADCMotor Driver / Motor InterconnectionsMain Control Unit Components and InterconnectionsInertial Measurement UnitTI ez430 ChronosProf. Slack, Dr. Sahin, Dr. Becker-Gomez, Computer EngineeringSoftware DesignInterprocess Communication for Fall DetectionLibrary SelectionSoftware VerificationData Formates and XML ReportConcerns about SLAMProf. Slack, Dr. Sahin, Dr. Becker-Gomez, AppendixBill of materialsMSD I to II scheduleProf. Slack, Dr. Sahin, Dr. Becker-Gomez, Prof. IndovinaIntroductionProject BackgroundThe “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 StatementThe 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 MatrixEng Reqs / Cust ReqsCR01: Sys must be quietCR02: Utilize previous team's resourcesCR03: Sys must be robustCR04: Must look "stock"CR05: No resistance to user's movementsCR06: Able to detect fallsCR07: Able to detect when in useCR08: Seamless software integrationCR09: Must have robust mtr/cltch sysCR10: MDs should get concise reportsCR11: Able to localize and map environCR12: Able to predict pressure soresCR13: Able to manually brakeCR14: Rechargeable pwr sysCR15: Must be light weightCR16: Minimize pwr lossesCR17: Minimize odometry errorsCR18: Readily reprogrammableER01: Minimize motor noiseER02: Maximize mic sensitivityER03: Maximize mic direc accuracyER04: Minimize wheel resistanceER05: Maximize Battery lifeER06: Minimize Emrgcy response timeER07: Minimize sys massER08: Maximize braking forceER09: Handle sensitivityER10: Conceal elec/mech sysER11: Unify softwareER12: Design mtr/cltch housingER13: Exrt data in hmn-readable fmtER14: Ensure SLAM capabilityER15: Detect pressure on seatER16: Use redundant odometry sysER17: Accessible for future researchFigure I.1 - Customer needs / engineering requirements fulfillment matrixCustomer RequirementsPriority Values ( 1-Low, 2 - Medium, 3 - High)Customer Req #PriorityDescriptionComments/StatusCR013Reduce/ 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.CR021Set up External Microphone Array to connect to PC and IR Thermal Camera for External Fall Detection/ User LocationThis 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. CR033System must be robust and able to withstand everyday useALL components need to be able to withstand further testing, use, and demonstrationsCR043Conceal systems within the frame of the walker.Walker must look "Off the shelf." Components should not be obtrusive to the userCR053Motors must not resist the manual movement of the wheels.CR063System must be capable of detecting a user's fall and executing a recovery routine.Multiple redundant detection/alert systems working in tandem.CR073System should be capable of determining presence of a user based on handle interaction.Include sensor/strain gages on handlesCR083Unify software subsystems and bring them to an acceptable operational level.CR092Redesign motor and powertrain system.CR103Software should compile necessary info into a readable file to be sent to customersXML formatted and sent once-a-day regularly, and immediately in the event of a fall or medical emergencyCR113SLAM CapableHandled by ASUS Xtion Pro Live and previously developed algorithmsCR122System must be capable of predicting pressure sores.CR132System should be able to brake the wheels on user input.Manual cable breaks included in walker frame.CR142Make power system rechargeable and user friendly.CR151System should be light weight.CR161System 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 operationCR173Odometry handled via a combination of IMU and encoder feedbackEncoders coupled to wheel motors, IMU pre-packaged and readily interfaceableCR183System must be readily reprogrammableSystem must be capable of being accessible on both the hardware and software sideEngineering RequirementsEng Req #Cust. Req #DescriptionUnit of MeasureMarginalTargetComments/StatusOwnersER01CR01, CR05Reduce Motor Noise While in Manual ModedBClutch Design / New gearing; Currently being designed and prototypedAnthony, NoahER02CR02Microphone sensitivitydB4015To be testedKelsey, TrevorER03CR02Microphone directional accuracym10.1To be testedKelsey, TrevorER04CR01, CR03, CR05, CR09Motor resistance on wheelsNm0.250.01Clutch Design/ New GearingNoah, AnthonyER05CR14, CR16Battery lifeHours412Power subsystem design mostly completeKelsey, TrevorER06CR06Response time to falls6030Handled primarily via ez430 Chronos and other redundant systemsAlex, Dan, Kelsey, TrevorER07CR03, CR15System masskg205Noah, AnthonyER08CR13Braking forceN1020Manual brakes already installed on systemNoah, AnthonyER09CR07Handle sensitivitykg20.25Handled via frame strain gaugesNoah, Anthony, KelseyER10CR04Conceal Walker Components cmRubber Grommets on frame to protect wires; New seat back to allow more room to hide components; New housing for motorsAnthony, NoahER11CR08Unify software systemsPacket lossCommunication between various controllers and lower level systems Alex, DanER12CR09Motor housing/ mount; ClutchcmDesign to be less obtrusive; measurement based on protrusion into walkwayAnthony, NoahER13CR10Human-readable XML reportReports generated1/week1/daySpecial report generated on medical emergencyAlex, DanER14CR11SLAM-capable camera systemCamera resolutionHandled by ASUS Xtion Live ProAlex, Dan, Kelsey, TrevorER15CR12Strain Measurement in seatlength/lengthHandled by strain gages in seat. Measures displacementKelsey, Noah, AnthonyER16CR17Odometry error measurementm0.10.05Handled through Arduino+Encoders+IMUKelsey, TrevorER17CR18Accessibility to control systems# of reprogrammable hubs13Microcontroller housing and designAnthony, Noah, Alex, Dan, Trevor, KelseyRisk AssessmentsDescriptionEffectCauseLSI = L*SOwner(s)ResponseRISK01Patient unable to call for helpWalker is not aware patient is in dangerHeart attack, stroke, seizure, etc.236TrevorBuild in redundancies to user detectionRISK02Walker falls overPatient is immobileUnstable walker design / implementation133Noah, Anthony, Kelsey, TrevorMechanical robustness and walker fall-detection subroutineRISK03Loss of walker power"Smart" elements of walker are disabledPoor battery life, lack of reminders for user to recharge326Kelsey, TrevorUser feedback on battery levelsRISK04Loss of watch powerWatch is disabled, user unable to call for helpRemote functions and fall detection disabled133Kelsey, TrevorAlerts once watch battery drops below certain levelRISK05Breakdown between mechanical and electrical componentsMechanical components damagedControl system crashes133AllBuild in total system redundancy and failsafesRISK06Delay on target MCU developmentMight not have the target MCU on time and have to reevaluate for a different MCUPandaboard ES out of stock everywhere326Alex, DanWorst case is to switch to a regular pandaboard that is not as powerfulRISK07Clutch 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. 224Noah, Anthony Create working prototype before MSD II for testing purposes. If clutch system fails, move to noise reduction.RISK08algorithm that doesn't meet our design specsthe software will not run as it would be expectedUs not developing the algorithm236Alex, DanCommunicate with the person developing the algorithms.RISK09Wheel shroud impede in walking pathThe coverings for the motors extend to far into the walking path causing a tripping hazardSize constraints to cover the motor/clutch housing.224Noah, AnthonyDesign 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-03High-Level System Interconnect DiagramFigure E.1a - High-level system interconnect drawingFigure E.1b – Electrical system interconnect drawingStrain 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/StrainA 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 17640306159500111100LL0-W-W0-L-L00W00W*RARBRCRD=F1y-xy-LW-xFigure ME.06 – C.O.G. MeasurementSeat 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 amplifierFigure 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.Vout= Vin(R2R2+R1-R4R3+R4) Say that the wheatstone bridge was perfectly balanced so there is no strain and Vout=0, that means that all of the resistors will have the same values which can be denoted as Ro. R3 and R4 will still have unknown variables based on the strain as represented with x.Vout= Vin(RoRo+Ro-Ro(1-x)Ro(1+x)+Ro(1-x))Vout= Vin(RoRo+Ro-Ro-RoxRo+Rox+Ro-Rox)It should be noted that Vout= Vinx2 & Vout= IN+-IN-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 CharacteristicsThe 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 characteristicsThe 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 AD8237Table 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 amplifierFigure 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.Strain Gage LocationsFigures ME.04-05As 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. 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.11Proposed 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: 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. 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.12Xtion 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.13Micro-controller/Power Distribution HousingThe 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.14Figure ME.15Figure ME.16Tech Drawing ME.01 Micro/Power HousingProposed 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.17Figure ME.18Figure ME.19Tech Drawing ME.02 Wheel Housing/ Motor ShroudClutch 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 sideProper function of actuator/magnet/springs to engage/disengage the clutchOnce 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 ConverterThe 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.1 - MC34063A step-down configuration test conditionsThe 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 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 inputFigure E.4 - Simulated switching regulator power in and power out for transient and steady statesEfficiency 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.INAINBOUTAOUTBOperating Mode11HHBrake to VCC10HLClockwise (CW)01LHCounter-clockwise (CCW)00LLBrake to GNDTable E.5 - H-bridge truth table for normal operating conditionsThe 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 NmStall Current (at 12 V)5 AGear Ratio50:1Unloaded Freerun Speed200 RPMMaximum PWM Frequency24 kHzTable E.6 - Electromechanical characteristics of motors and associated componentsFigure E.9 - Motor control software flowchartThe 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 interconnectionMain 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 schematicJ3 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.12 - Typical configuration circuit for ADS7229Figure E.13 shows the timing diagram for the ADS7229 during conversion and acquisition cycles for auto-triggering mode.Figure E.13 - ADC timing diagram for read-while-converting during auto-triggering eventsThe 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 codesThe ADS7229 also features an automatic power-down and nap mode when not in use.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.14 - IMU I2C slave timing diagramFigure E.15 - IMU SchematicTexas 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.16 - Texas Instruments ez430 Chronos with USB programming and RF communications moduleFor 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 conditionsFigure E.18 - Software flowchart for the ez430 Chronos in use with Smart Walker IIIn 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 puter EngineeringSoftware DesignThe 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 BlackPandaBoard ESDuoVero COMSRobovero Kit (Overo COM)Specs.Processor01111Clock Freq.01111RAM00110Storage00000ConnectivityUSB Ports0-10-10Wifi00101Ethernet0001-1GPIO01111OS00000CostPrice0-1-1-1-1Total01432Figure C.1: Pugh matrix for selection of MCUPandaBoard ESBeagleBone BlackRaspberry Pi (Model B rev. 2)DuoVero COMSRobovero Kit (use of Overo COM)Beagleboard-xMSpecs.Processor0-1-10-1-1Clock Freq.0-1-1-1-1-1RAM0-1-10-1-1Storage0-10000ConnectivityUSB Ports0-10-101Wifi0-1-100-1Ethernet0001-10GPIO01-1-11-1OS000000CostPrice011-1-11Total0-3-4-3-4-3Figure 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 programOnce 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” scenarioOnce 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 systemInter-process Communication for Fall DetectionThe 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 SelectionLibrary 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 VerificationTo 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 libraryFigure C.7: Code and demo of TI Chronos watch accelerometerData Formats and XML ReportData 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. 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 bitsThe 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.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 bitsThe 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 SLAMThere 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.DataPorts on PandaboardPrograms.data fileXML fileCommentsTI-watch TemperatureUSBRun separately from SWIICelsius/Fah + time stampparsed into xml format using the data in .data file3-axis dataUSBx,y,z data + time stampparsed into xml format using the data in .data fileWebcamHeartrateUSBRun separately from SWIIBMP + time stampparsed into xml format using the data in .data fileStrain gage systemStrain gagesGPIO32-37processed in the SWII applicationVoltage value? maybe some processing?parsed into xml format using the data in .data fileConsider using SPI over GPIO because bit banging is inefficientWalker IMU systemWalker IMUI2C2_SDAData used in SWII to determine position of the walkerArduino SystemEncoder CountI2C4_SDAUsed in SWII for dead reckoning/navigationXtion Pro Livevideo streamUSBvideo stream used/manipulates data to navigateNo categoryFall eventgenerated in SWIIboolean valueTOTAL1194.03?Bill of Materials?????????ItemQuantityCost per unit ($)Total cost ($)VendorPart #URLStatusNotesHugo Portable Rollater Walker with Seat and Back rest1$105.99$105.99Amazon? Load Sensor1$14.52$14.52Sparkfun? Test Purposes. No longer functional. Not on WalkerPandaBoard ES1$182.00$182.00Digikey? / On order?Arduino Uno1$29.95$29.95Sparkfun? Xtion Pro Live1$180.00$180.00eBay - 23port? Metal Gearmotors2$39.95$79.90Pololu? Channel Motor Driver1$49.95$49.95Pololu? Kwik Epoxy1$5.70$5.70Lowes?N/AArrived?Vishay Micro-Measurements Strain Gages15$0.00$0.00Vishay Micro-Measurements? correspondance?12 V, 5000 mAh NiMH Battery1$69.95$69.95AA Power Corporation?$0.63$1.89Digikey? order?33008 SMD to SIP Breakout10$2.19$21.90Digikey? Order?ADUC845BSZ62-51$22.58$22.58Digikey? Order?8100-SMT6 Protoboard1$28.80$28.80Digikey? Order?AD8237 Instrumentation Amplifier10$2.31$23.10Digikey? Order?8029 Perfboard2$6.26$12.52Digikey? Order?TD-132-T-A Male Headers1$7.61$7.61Digikey? Order?CES-150-01-T-D Female Headers1$7.24$7.24Digikey? Order?RP3502ARED Pushbutton1$2.09$2.09Digikey? Order?SRB22A2DBBNN Rocker Switch1$0.93$0.93Digikey? Order?180-Piece Rubber Grommet Shop Assortment1$4.01$4.01Amazon? Order?Ethernet/USB/ Power PortsTBD??Radio Shack???These parts will be purchased in MSD II after physical verification of locationGear Set w/ Set Screw(.1873d) 1:32$61.57$123.14SDP-SIS1344Z-64A32A096?Awaiting Order?6061 Al Bar - 1.25x2x121$21.68$21.68McMaster8975K412?Awaiting Order?6061 Al Bar - .5x3x121$16.02$16.02McMaster8975K415?Awaiting Order?1566 Steel Rod 1OD - 12in1$22.21$22.21McMaster1346K37?Awaiting Order?M3 Screws-12mm( Qty 100)1$5.68$5.68McMaster91290A117?Awaiting Order?#8-32-1in Socket Head (Qty 50)1$7.51$7.51McMaster91251A199?Awaiting Order?1/4-20 Socket Head 1in (Qty 50)1$7.58$7.58McMaster91251A542?Awaiting Order?5/16-18 Socket Head 2in (qty 25)1$7.39$7.39McMaster91251A591?Awaiting Order?Steel Ball Bearing - 1/4 ID2$8.38$16.76McMaster6384K39?Awaiting Order?Taper Roller Bearing 1/2 ID2$36.00$72.00McMaster23915T11?Awaiting Order?#10-24 .5in Button Head (qty 50)1$7.16$7.16McMaster91255A252?Awaiting Order?1/16 Al sheet 6x48in1$28.51$28.51McMaster89015K77?Awaiting Order?Al Key stock .5x.51$7.76$7.76McMaster99108A120?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 Detectionfrom lib.device import Camerafrom lib.processors_noopenmdao import findFaceGetPulsefrom lib.interface import plotXY, imshow, waitKey, destroyWindowfrom cv2 import moveWindowimport argparseimport numpy as npimport datetimefrom serial import Serialimport socketimport sysclass getPulseApp(object):"""Python application that finds a face in a webcam stream, then isolates theforehead.Then the average green-light intensity in the forehead region is gatheredover 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 self.bpm_plot = False 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 statedef toggle_display_plot(self): """ Toggles the data display. """ if self.bpm_plot: print "bpm plot disabled" self.bpm_plot = False destroyWindow(self.plot_title) else: print "bpm plot enabled" if self.processor.find_faces: self.toggle_search() self.bpm_plot = True self.make_bpm_plot() moveWindow(self.plot_title, self.w, 0)def make_bpm_plot(self): """ Creates and/or updates the data display """ plotXY([[self.processor.times, self.processor.samples], [self.processor.freqs, self.processor.fft]], 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 Dataimport serialimport 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 pointser.write(startAccessPoint()) while True:#Send request for acceleration dataser.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 AnalysisAppendix: 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. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download