Project Plan .edu
Self-Guided Wheelchair
MAY07-15
Final Report
Version 2.0
Client: Andrew Dove
[pic]
Faculty Advisor: Dr. Nicola Elia
Team Members: Brennen Beavers
Margaret Shangle
Vee Shinatrakool
Tara Spoden
John Volkens
Brian Yauk
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.
Submitted: Friday, May 4, 2007
Table of Contents
1 List of Figures iii
2 LIST OF TABLES IV
3 LIST OF DEFINITIONS VI
4 EXECUTIVE SUMMARY 7
5 INTRODUCTORY MATERIALS 8
5.1 ACKNOWLEDGEMENT 8
5.2 Problem Statement 8
5.2.1 General Problem Statement 8
5.2.2 General Solution Approach 8
5.3 Operating Environment 9
5.4 Intended Users and Uses 9
5.4.1 Users 9
5.4.2 Uses 10
5.5 Assumptions and Limitations 10
5.5.1 Assumptions 10
5.5.2 Limitations 11
5.6 Expected End Product and Other Deliverables 12
6 Proposed Approach 14
6.1 DESIGN OBJECTIVES 14
6.2 Functional Requirements 15
6.3 Constraint Considerations 15
6.4 Technology Considerations 15
6.4.1 Selection Criteria 17
6.4.2 Microprocessor Hardware 17
6.4.3 Microprocessor Software 18
6.4.4 Ranging Modules 18
6.4.5 Orientation Sensors 19
6.4.6 Distance Tracking Sensors 20
6.4.7 Localization 21
6.4.8 Motor Control 22
6.4.9 Power Management 23
6.4.10 User Interface 24
6.5 Detailed Design 25
6.5.1 General Overview 25
6.5.2 Microprocessor 26
6.5.3 Sensors 30
6.5.4 Localization 33
6.5.5 Motor Control 36
6.5.6 Power Management 42
6.5.7 User Interface 43
6.5.8 Design Summary 44
6.6 Implementation Process 44
6.6.1 Microprocessor 44
6.6.2 Sensors 45
6.6.3 Localization 46
6.6.4 Motor Control 46
6.6.5 Power Management 46
6.6.6 User Interface 46
6.7 End-Product Testing and Results 47
6.7.1 Microprocessor 47
6.7.2 Sensors 48
6.7.3 Localization 53
6.7.4 Motor Control 55
6.7.5 Power Management 56
6.7.6 User Interface 57
6.7.7 System Integration 57
7 Resource Requirements 58
7.1 PERSONNEL REQUIREMENTS 58
7.2 Other Resources 61
7.3 Financial Requirements 61
8 Schedules 63
9 CLOSURE MATERIALS 65
9.1 PROJECT EVALUATION 65
9.2 Commercialization 66
9.3 Recommendations for Additional Work 66
9.4 Lessons Learned 67
9.4.1 What Went Well 67
9.4.2 What Did Not Go Well 67
9.4.3 Knowledge Gained 68
9.4.4 What Would Be Done Differently 68
9.5 Risk and Risk Management 68
9.5.1 Anticipated Potential Risks 68
9.5.2 Anticipated Risks and Risk Management 68
9.5.3 Unanticipated Risks 69
9.5.4 Changes in Risk Management 69
10 Project Team Information 70
11 CLOSING SUMMARY 71
12 APPENDIX A 72
13 APPENDIX B 76
14 APPENDIX C 80
15 APPENDIX D 82
16 APPENDIX E 83
17 APPENDIX F 87
18 APPENDIX G 90
19 REFERENCES 93
LIST OF FIGURES
List of Figures
Figure 5.1 – Basic System Block Diagram 9
Figure 6.1 – Technology Selection Process 16
Figure 6.2 – PW-200-V, 12V DC/DC Power Supply Unit 24
Figure 6.3 – System Flow Diagram 26
Figure 6.4 – System Mounting Diagram 26
Figure 6.5 – Controller Connection Block Diagram 27
Figure 6.6 – General Program Flow 28
Figure 6.7 – Ranging Module Mounting Arrangement 31
Figure 6.8 – R117 Compass Timing Diagram [1] 33
Figure 6.9 – Tracker Sensor Diagram 34
Figure 6.10 – Track Configuration Diagram 34
Figure 6.11 – Photodetector Positions 35
Figure 6.12 – Invacare Arrow Joystick Schematic 36
Figure 6.13 – Motor Control Design Flow Diagram 37
Figure 6.14 – DAC Circuit Design Flow Diagram 38
Figure 6.15 – R-2R Thevenin Equivalent Circuit [] 39
Figure 6.16 – Complete DAC Circuit Schematic 40
Figure 6.17 – Summing Circuit Design Flow Diagram 41
Figure 6.18 – Complete Summing Circuit Schematic 41
Figure 6.19 – PSU Efficiency Ratings 43
Figure 6.20 – LCD Character Displays [] 43
Figure 6.21 – Sensor simulation controls 45
Figure 6.22 – Track sensor implmentation 46
Figure 6.23 – Sonar Detection Edges 48
Figure 6.24 – Sonar Average Error 50
Figure 6.25 – Sonar Standard Deviation 50
Figure 6.26 – Infrared Detection Edges 51
Figure 6.27 – Compass Average Error 53
Figure 6.28 – Compass Standard Deviation 53
Figure 6.29 – Simple Test Track 55
Figure 6.30 – DAC Output Measurements 56
Figure 8.1 – Full Task Schedule 63
Figure 8.2 – Reporting and Deliverables Schedule 64
List of Tables
List of Tables
Table 5.1 – Project Assumptions 10
Table 5.2 – Prototype Assumptions 11
Table 5.3 – Project Limitations 12
Table 6.1 – Controller Technology Comparison 18
Table 6.2 – Ranging Module Technology Comparison 19
Table 6.3 – Orientation Technology Comparison 20
Table 6.4 – Distance Tracking Technology Comparison 21
Table 6.5 – Localization Technology Comparison 22
Table 6.6 – Motor Control Technology Comparison 23
Table 6.7 – User Interface Technology Comparison 25
Table 6.8 – CMD565 Evaluation Board Features [4] 27
Table 6.9 – EZ1 Technical Specifications [9] 30
Table 6.10 – EZ1 Pin Connections [9] 31
Table 6.11 – R117 Compass Technical Specifications [16] 32
Table 6.12 – R117 Compass Pin Connections [] 32
Table 6.13 – Lynxmotion Tracker Sensor Features 33
Table 6.14 – Photodetector Identifiers 35
Table 6.15 – Microcontroller Output Offset Values 37
Table 6.16 – DAC Bit Order 38
Table 6.17 – Power Management Plan 42
Table 6.18 – Output Ratings for PW-200-V 42
Table 6.19 – Sonar Detection Boundary Measurements 48
Table 6.20 – Sonar Detection Accuracy Measurements 49
Table 6.21 – Infrared Accuracy Measurements 51
Table 6.22 – Compass Accuracy Measurements 52
Table 6.23 – Tape Descriptions 53
Table 6.24 – Initial Photodetector Testing 54
Table 7.1 – Estimated Person Hours (Original) 58
Table 7.2 – Estimated Person Hours (Revised) 59
Table 7.3 – Person Hours (Actual) 60
Table 7.4 – Other Resource Requirements 61
Table 7.5 – Material and Labor Costs 62
Table 9.1 – Evaluation of Design Functionality 65
Table 9.2 – Evaluation of Implementation Functionality 65
Table 12.1 – CMD565 Evaluation Board [ 72
Table 12.2 – Handy Board [] 73
Table 12.3 – EPIC AMD Gode GX2 [] 74
Table 12.4 – VIA EPIA-EN12000EG Mini-ITX [] 75
Table 13.1 – MaxSonar EZ1 Sonar Sensor [] 76
Table 13.2 – SRF04 Sonar Sensor [] 76
Table 13.3 – SRF235 Sonar Sensor [] 77
Table 13.4 – SensComp 6500 Sonar Sensor [] 77
Table 13.5 – Sharp GP2D05 IR Ranger [] 78
Table 13.6 – Sharp GP2Y0A02YK IR Sensor [] 78
Table 13.7 – R283-HOKUYO Laser Sensor [] 79
Table 14.1 – Devantech R117 Magnetic Compass [] 80
Table 14.2 – ADXRS150 Angular Rate Sensor [] 81
Table 15.1 – MA2 Miniature Absolute Magnetic Shaft Encoder [] 82
Table 16.1 – Off-board Track Localization 83
Table 16.2 – Dead Reckoning Localization 84
Table 16.3 – Tactile Detection Localization 84
Table 16.4 – RFID Localization 85
Table 16.5 – Sonar Imaging Localization 86
Table 17.1 – ADAC0808 8-Bit D/A Converter [] 87
Table 17.2 – Custom D/A Converters 88
Table 17.3 – Control Box Connection 88
Table 17.4 – Joystick Connection 89
Table 18.1 – Axiom HC-KP 4x4 Keypad [] 90
Table 18.2 – Targus USB Numeric 19-Key Mini Keypad [] 91
Table 18.3 – Axiom HC-LCD 4x20 Character LCD [] 91
Table 18.4 – Mini-Box picoLCD [] 92
Table 18.5 – Optrex TM1B5BW Touchscreen [] 92
List of Definitions
List of Definitions
DAC or D/A (digital-to-analog converter) electronic device that is used to convert digital signals into analog signals
DC (direct current) unlike alternating current (AC), the flow of current is constant in one direction
Infrared electromagnetic waves whose frequency range is above that of microwaves, but below that of the visible spectrum, from 760 nanometers to 1000 microns
LabVIEW Embedded graphical programming language developed by National Instruments for implementation on OEM hardware
LCD (liquid crystal display) display that consists of two polarizing transparent panels and a liquid crystal surface sandwiched in between
Microprocessor silicon chip with thousands of electronic components that serves as the central processing unit in microcomputers
Photodetector sensor which uses the photoelectric effect to convert radiant energy into an electrical signal.
PWM (pulse width modulator) type of circuit that holds the frequency constant while the width of power pulse is varied, and controls both line and load changes without major dissipation
RF (radio frequency) frequency that lies in the range within which radio waves may be transmitted, from about 10 kilohertz per second to about 300,000 megahertz.
Sonar (sound navigation and ranging) distances to objects are determined by bouncing sound waves off them and measuring the time it takes for the echo to return
USB (universal serial bus) external peripheral interface standard for communication between a computer and external peripherals over a cable using bi-serial transmission
VI (virtual instrument) file containing subroutines or sub-functions created in LabVIEW
Executive Summary
Executive Summary
The system designed in this project is a wheelchair that has the ability to navigate autonomously through a hospital environment while avoiding obstacles incurred along the desired route. Certain limitations, constraints outside of the control of the team, and assumptions, constraints defined by the team, have been identified in order to ensure a manageable project. These considerations include constraints on the operating environment such as floor surface, the physical and mental capabilities of the user, budget, physical dimensions, power requirements, and overall scope of the project. Functional requirements further define the autonomous navigation and obstacle detection in terms of navigation from and to predefined locations, detecting critical obstacles, and detecting floor drop-offs.
A floor plan map modeled after the actual environment has been programmed into the MPC565 microcontroller prior to operation. Within this map, several predetermined coordinates have been selected as the possible waypoints to be used as the start and destination points. Also included in this map are the locations of track intersections as the navigation is based on a track system. The operation includes the intelligence to distinguish between one intersection and the next as well as different waypoints. The MPC565 is programmed using LabVIEW Embedded 8.2 as requested by the client, National Instruments.
An algorithm for path calculation begins upon receipt of the starting and ending point of navigation. The path is generated from the initial floor plan, assuming an unobstructed track. The track is monitored with photodetector arrays mounted near the floor surface. Using multiple ultrasonic sensors positioned around the perimeter of the wheelchair, the distance from the wheelchair to physical objects in the environment is calculated from the sensor feedback. The distances are used in the microprocessor to decide whether or not the intended path is safe for travel and free of obstructions. In addition, an infrared sensor detects the distance to the floor and identifies drop-off hazards. In the event of a critical obstacle or drop-off, the navigation stops, and the user is alerted.
The motor control of the wheelchair is realized by converting the digital output of the controller into an analog signal which is sent into the existing joystick. This method allows for a high level control of the motors such that a forward/reverse and right/left parameter simultaneously affects both the speed and rotation left and right wheels.
The implementation process included mounting of the track sensors, and motor control. Since the microcontroller was deemed faulty and time was unavailable to replace the hardware, all controller interfacing was not implemented. Also, the ultrasonic obstacle sensors had to be returned to the manufacturer due to a firmware failure, and replacements were not received before the end of this project.
Testing was planned to be performed by team members, advisor and outside users to verify functionality. The team planned tests to evaluate both hardware and software modularly and as a complete system. Due to time constraints and microprocessor hardware issues, only a full system simulation was completed.
Due to the complexity and scale of this project, the tasks have been divided into smaller, manageable sections of planning, development, testing and documentation. A schedule is constructed with milestones signifying the conclusion of each section. The project has been completed somewhat successfully as the software development was a critical delay. This project was completed by utilizing 937 total man-hours and approximately $700 in hardware purchases.
The team encountered many risks throughout the project which lead to delays, and also encountered multiple instances were redefinition of the project was deemed necessary. The project team recommends that additional phases be appended this project to improve the design in areas of localization, obstacle avoidance, and commercialization.
Introduction
Introductory Materials
The following material gives an overall summary of current problematic situation, as well as an overview of the proposed system solution, complete with deliverables of the project.
1 Acknowledgement
The May07-15 Design Team would like to thank several resources for information and materials in relation to this project: National Instruments for their donation of LabVIEW Embedded 8.2 software, the CMD565 evaluation board and microprocessor, as well as, advanced technical support; Invacare for their donation of a joystick and wheelchair control box; and Iowa State University for the use of a motorized wheelchair for the duration of the project.
2 Problem Statement
The section addresses and outlines the general solution approach.
1 General Problem Statement
Many people encounter an instance in their life where a disability causes them to be confined to a wheelchair. When transport is required, the wheelchair is often physically manned, either by the person in the wheelchair or someone behind it. When someone is needed to push the wheelchair, the independence of the person confined to the wheelchair is limited to the schedule and convenience of an outside source.
Especially in hospital environments, these persons confined to wheelchairs need to move frequently, for appointments in multiple departments and general relocation from room to room. In the absence of family and friends, the assistance required for persons in wheelchairs creates a burden on the already confined schedules of the staff. As a result, patients are subject to waiting until aid is of convenience.
2 General Solution Approach
The system designed in this project is a wheelchair that has the ability to navigate autonomously through a hospital while detecting obstacles. Using a microprocessor programmed with LabVIEW Embedded 8.2 and interfaced with user input devices, the wheelchair user is able to select, from one of several locations, their starting and ending point.
Travel of a motorized wheelchair is initiated and controlled by the microprocessor. Navigation is based on a grayscale path which is adhered to the floor and tracked using photodetectors. During travel, additional sensors mounted on the wheelchair transmit environmental data such as distance to surround objects and distance to the floor to the microprocessor. Incurred obstacles prompt an emergency stop and alert the user.
The block diagram in Figure 5.1 demonstrates the basic system solution interface.
[pic]
Figure 5.1 – Basic System Block Diagram
3 Operating Environment
The system is designed for use in an indoor medical hospital setting. The prototype is designed only for operation on a single floor level, without requiring elevator transport. The floor surface must be a common hospital floor type, such as tile, hardwood, or short carpet, and be equipped with the path system designed in this project. The environment must be typical for motorized wheelchair operation and yield itself to a mobile wheelchair system.
4 Intended Users and Uses
The system is designed to accommodate the users and uses outlined in the following sections.
1 Users
There are two possible classes of users for this wheelchair: a primary user (operator), and a secondary user (passenger).
Primary User
The primary user must be able to interact with an LCD and keypad to provide the appropriate location information for the system input in the form of a numeric identifier. At a minimum, the primary user must have the mental and physical capability to provide the current location and desired destination of the wheelchair via a simple keypad, which requires shape recognition and basic literacy. In instances where the passenger lacks this mental or physical capacity, they become the secondary user, and the primary user is regarded as the medical staff or guardian providing the input.
Secondary User
The secondary user, as mentioned, is regarded as the passenger that is transported via the wheelchair to the specified destination. At a minimum, this user must be able to maintain a seated position within the confines of the chair dimensions, but no further physical or mental functions are specifically required. It is assumed that the secondary user will primarily be a patient who is unable to maintain proper control of a wheelchair due to mental of physical disabilities.
(Note: There may be one person who qualifies as both the primary and secondary user if the wheelchair passenger is capable of providing the location input.)
2 Uses
The system is designed for use in an indoor medical hospital or nursing home setting on one floor level. Other locations similar to an indoor medical hospital may provide an adequate for system operation, such as a residential home or office building, but are not explicitly covered by the system.
The system navigates from one of any number of pre-selected locations to one of any number of pre-selected destinations, as specified by the primary user, if an unobstructed path exists. The wheelchair attempts to traverse an initial path calculated by the system while detecting any obstacles (both moving and stationary). If the current path is deemed impassable due to obstacles, the system discontinues movement and signal that it is unable to proceed.
The system is able to traverse reasonably shallow ramps or other such gradual changes in plain elevation, in the absence of large drop-offs. In order to obtain operation on another floor level, an outside user is required manually relocate the system.
5 Assumptions and Limitations
The operation of the system is constrained by the assumptions and limitations described in the following sections.
1 Assumptions
Certain elements were defined by members of the design team which attempt to further quantify the scope of the project. The list contained in Table 5.1 summarizes the general assumptions used during the system conceptualization and the justification for each.
Table 5.1 – Project Assumptions
|Assumption |Justification |
|The floor shall be a common floor type, typical |Operational Requirement |
|to electronic wheelchair navigation. | |
|The navigation shall be applicable to hospital |Design Requirement |
|environments. | |
|The primary user shall have the physical and |Design Requirement |
|mental capabilities to interact with the input | |
|system. | |
|The team shall have administrative access to |Testing Requirement |
|load software/hardware on senior design | |
|workstations. | |
The complexity of this project warrants assumptions for the prototype as well as the overall design. In order to ensure a manageable prototype to be implemented within the timeframe of senior design, the additional assumptions in Table 5.2 have been specified by the team.
Table 5.2 – Prototype Assumptions
|Assumption |Justification |
|The environment shall consist of a single floor |Design Requirement |
|level without elevator transport. | |
|The navigation shall be applicable to hallway |Design Requirement |
|environments, such as those on third floor Town | |
|Engineering. | |
|The team shall be provided with a motorized |Design Requirement |
|wheelchair in working condition. | |
|The system shall travel and detect obstacles |Design Requirement |
|and/or drop-offs in the forward direction during| |
|autonomous navigation. | |
|The system shall travel only along a |Design Requirement |
|predetermined, marked path. | |
|The system shall travel to one and only one |Design Requirement |
|destination at a time without intermediate | |
|waypoints. | |
|The floor of operation will be equipped with a |Design Requirement |
|grayscale path coordinated with the | |
|preprogrammed map. | |
2 Limitations
Additional elements of the project were identified as design restrictions which are beyond the control of the team members. The list contained in Table 5.3 summarizes the limitations acknowledged during the system conceptualization and the justification for each.
Table 5.3 – Project Limitations
|Limitation |Justification |
|The placement of the components shall not |Operational Requirement |
|interfere with the mobility or passenger | |
|accommodation of the wheelchair. | |
|All hardware shall be secured to the existing |Design Requirement |
|wheelchair frame or remain stationary within the| |
|operational environment. | |
|The hardware shall interface to the |Client Requirement |
|microprocessor through the use of LabVIEW | |
|Embedded 8.2. | |
|The system shall only be required to navigate |Design Requirement |
|between predefined locations. | |
|The localization technology of the wheelchair |Design Requirement |
|shall be attainable within the existing project | |
|budget. | |
6 Expected End Product and Other Deliverables
There are two end products of this project. The first is a complete design report, and the second is a prototype of this design implementing the most pertinent components. In addition to the end products, there are two additionally required deliverables, the project plan and final report.
Prototype Design
The prototype is a full system implementation of an autonomous, track-guided wheelchair equipped with obstacle avoidance and drop-off detection.
Project Plan
The project plan is a document that defines that project and the plan for the completion of the project. It describes how design decisions were made for the project and defines the overall problem domain. This document was delivered in October of 2006.
Design Report
The design report is a document describing the full design of the system. As this is a non-proprietary project, it specifies the details of the complete system: the schematic designs, component layouts, software design, and hardware specifications. It is intended to provide all the details necessary for replication of the project by an independent team. This document was delivered in November of 2006.
Prototype
The prototype of the self-guided wheelchair system specified by the design documentation is assembled and presented to the client. Since a complete system would require extensive funding, the prototype is limited to the components of the design which demonstrate the basic, required navigational capabilities in a controlled environment and suggest further capabilities with the additional improvements and hardware. The team assembled and tested the equipment to verify proper autonomous navigation. This system will be delivered in May of 2007.
Final Report
The final report is a document that provides the most complete description of the project along with a detailed record of its development. All aspects of the project, including the background development, testing, and end product description, are covered in this document. This document also provides suggestions for future work on the project. This document will be delivered in May of 2007.
Proposed Approach
Proposed Approach
The following material reiterates the requirements of the project and discusses the considerations included in the design of the system. This will include the functional requirements, constraints, technical considerations, testing and overall objectives. The purpose of this material is to clearly describe the components which lead to a successful end product.
1 Design Objectives
The objective of this design is to solve transportation issues of a person confined to a wheelchair within a hospital environment. In order to successfully address the issues of concern with this problem, the project has been designed such that it meets the design objectives described in this section.
Autonomous navigation
The navigation of the wheelchair is independent of user input, other than the starting and destination point. Turning, forward navigation, intersection traversal, and waypoint identification are all controlled by the onboard processing unit with the aid of distance sensors, photodetectors, and a compass.
Obstacle avoidance
The navigation of the wheelchair attempts to avoid any obstacle incurred in the intended path. In situations where an obstacle is moving and clears the path in time, the wheelchair continues towards its destination upon removal of the obstacle. In situations where an obstacle or drop-off is stationary, the wheelchair terminates navigation and notifies the user that path is blocked.
User interface
The user interface is a visual, intuitive design which allows the selection of a starting point and destination point. The interface also offers options for commencing and terminating operation. Visual indicators for direction of travel and detected obstacles have also been implemented.
Reliable operation
The system is designed to operate reliably for a few hours of operation in order to insure project feasibility. The navigation is able to traverse a fairly smooth path free of sudden changes in direction or erratic movements. Smooth navigation ensures the safety and comfort of the passenger.
Ease of use
Simplicity of the system is an important factor in the marketability of the end product. The system is easy to use with a small learning curve to ensure that hospital staff is not overwhelmed by implementation of the system, especially as the solution is meant to reduce their workload.
Low cost
Comparable autonomous navigations systems can be implemented for thousands to hundreds of thousands of dollars. The system designed in this project is attainable with components whose total purchase price is less than $1150, the project budget.
2 Functional Requirements
The complete system has the following functional requirements:
Basic function
The system autonomously traverses from one of several predetermined locations to one of several predetermined destinations, indicated by the primary user, if an unobstructed path exists.
Navigation
The following list quantifies the requirements for the traversal of the system:
• The system calculates a path from the specified starting point to the specified ending point which is considered to be a direct route, although not constrained to be the absolute shortest route.
• The system attempts to travel on this predetermined path while detecting both moving and stationary obstacles presiding in the path.
• If the current path is deemed impassable, due to an obstacle or closed door, etc, the system discontinues movement.
• If an obstructed path remains impassible for an extended period of time, the system notifies the user that it is unable to continue navigation.
• The system does not attempt to traverse any stairwell, escalator, or other surface or area that is seemingly non-adjoining surface to the plain that the system is currently on.
• The system is able to traverse reasonably shallow ramps or other such gradual changes in plain elevation.
3 Constraint Considerations
The following list specifies the restrictions on the complete system as deemed appropriate by team consensus or the laws of physics:
• The floor shall be a common floor type, typical to electronic wheelchair navigation.
• The environment shall consist of a single floor level and no large drop-offs.
• The primary user shall have the physical and mental capabilities to interact with the input system.
• The secondary user shall be of physical dimensions accommodated by wheelchair and be capable of maintaining a seated position during travel.
• The team was provided with a motorized wheelchair in working condition.
• The system is only required to navigate between predefined locations.
• The system travel to one and only one destination at a time without intermediate waypoints.
• The placement of the components does not interfere with the mobility or passenger accommodation of the wheelchair.
• All hardware is secured to the existing wheelchair frame or remains stationary within the environment.
• The hardware is interfaced to the microprocessor through the use of LabVIEW Embedded 8.2.
• The prototype design is limited to that which is accomplishable based on budget and time.
4 Technology Considerations
This section contains a very detailed description of the methods used to identify, evaluate and select the technology used for the design of this system. The scope of this project demands that the technical details be divided into manageable parts; therefore, this section, as well as the remaining sections of this document, will describe details as they pertain to the following categories: processing, obstacle detection, localization, power management, and user interface. Using the process outlined in Figure 6.1, the solution alternatives addressed in this section were identified, evaluated and selected. While the testing phase has begun, final verification is still in progress.
[pic]
Figure 6.1 – Technology Selection Process
1 Selection Criteria
The selection of each component was based on the following criterion:
Capability
This takes into account how well the system can handle the tasks demanded of it according to its functional requirements. This also takes into account physical dimensions as space is limited for mounting on the wheelchair. This category has the most weight as the technology must be capable of handling the necessary tasks.
Ease of implementation
This takes into account how much effort would be needed to coordinate interfacing with the other components in the system and the ease of running all required tasks. This category has the second highest amount of weight as the technology must be able to be implemented in the given time frame, with readily available knowledge.
Cost
This takes into account how much the component actually costs to purchase, set up, and the associated labor. This category has the third highest amount of weight as the technology must be able to be implemented within the cost constraints of the project.
Durability
This takes into account how well the component withstands vibrations on the wheelchair or possible abuses from the operator.
Ease of use
This takes into account how feasibly the component can be implemented into a commercial product where a learning curve may be associated with the programming and/or maintenance.
2 Microprocessor Hardware
The functionality requirements for the microprocessor include the ability to:
• Receive data from the selected sensors and localization technology
• Interpret data from sensors into an area mapping
• Receive input from the user interface
• Transmit commands to the motor control
• Transmit status indicators to the user interface
• Perform path calculation and obstacle detection
• Operate on LabVIEW Embedded 8.2
Since a solitary microprocessor would not be sufficient, considerations of microprocessors were done in the form of a microcontroller starter kit. The client offered two alternatives for consideration, both of which were suitable for LabVIEW Embedded 8.2 environment:
1. Motorola MPC565 microprocessor with Axiom CMD565 evaluation board
2. Motorola 68HC11 microprocessor with Handy Board
However, in order to do the complex calculations and mapping required for an onboard map and obstacle avoidance, significant memory must be available. Neither of the microcontroller kit alternatives offers a large memory option, therefore the capability of the prototype is severely limited. The suggestion of this team for commercialization of this project is to design a custom board with sufficient external memory interfaced to the microprocessor, as well as, serial connection, digital, and ADC ports. Therefore, two further possibilities were considered for solving issues with the proposed microprocessors:
3. PC104 form factor EPIC AMD™ Geode GX2 Low Power Single Board Computer
4. VIA EPIA-EN12000EG Mini-ITX Motherboard
1 Technology Considerations
A full description of the technologies considered for the microprocessor can be found in Appendix A. Each option was researched and evaluated according to the pros and cons in relation to the functionality requirements.
2 Selected Approach
Based on the criterion described in the previous section, Table 6.1 summarizes the controller evaluation process as the technology options were rated on a scale of 1 to 5, 5 being the best..
Table 6.1 – Controller Technology Comparison
| |Capability |
| Microprocessor |32-bit MPC565 |
| Cable/Connection |(x2) |RS232 |
| Power Consumption |6 to 20VDC Input (300mA typical @ 12VDC) |
|Memory | |
|On Board | |
| EEPROM/FLASH |4 MByte (1M x 32) Burst |
| SRAM |2 MByte (512K x 32) Synchronous |
|Internal | |
| Flash |1024 KByte |
| RAM |36 KByte |
|Ports | |
| CAN |(x2) |1 x 4 headers |
| LCD |(x1) |contrast adjust |
| Keypad |(x1) |16 key or 20 key |
| BUS |(x1) |32 data, 24 address |
| Control |(x1) |44 pin |
| QSM |(x2) |16 pin |
| MIOS |(x1) |MDA, PWM, MGP, IO, 34 pin |
| TPU |(x2) |20 pin |
| QADC |(x2) |20 pin and 24 pin |
| INT |(x1) |10 pin |
|Dimensions |8 x 9.5 inch |
The evaluation board is equipped to handle a keypad and LCD through parallel ports, and the digital output to the joystick is routed through a DAC for conversion. The input received from the photodetector, compass, infrared, and ultrasonic sensors will be received through the analog-to-digital converter (ADC).
3 Software
The basic program flow of the software to be developed in LabVIEW for operation on the controller is summarized on the left side of Figure 6.6. The flow has been further modulated on the right side of this figure to indicate the main states of operation. These main states are idle, initialization, environment scan, obstacle detection, track and general navigation.
[pic]
Figure 6.6 – General Program Flow
Idle state
The idle state is the first state entered upon program execution. In this state the controller polls the keypad waiting for user input. No wheelchair movement is performed in this state.
checkKeypad – This VI will run continuously while the system is in an idle state. It will monitor the keypad to see if any input has been entered into it. Once it detects user input it will initiate the next step of the program.
Initialization
The initialization state is entered as soon as a key has been pressed on the keypad. The LCD display then presents the user will simple instructions for entering the starting and destination points. Once these inputs are received the controller calculates a path from the starting to destination point within the preprogrammed map. No wheelchair movement is performed in this state.
getInput – This VI will output instructions to the LCD display and prompt the user to input the starting and destination points via the keypad. It will then store the data for other VIs to use.
calcPath – This VI will use the starting and destination points received from the previous VI to calculate the next point that the wheelchair is going to come across. Once the wheelchair is at the next point it will then store this point as the current position and calculate the next point and direction. This process will repeat until the destination is reached.
Environment scan
The environment scan state is entered either directly after calibration of sensors or after a movement has been performed. In this state, the controller sends stimulus signals all of the sensors and RFID reader then stores the returned data. The data is recalled and used to determine if an obstacle is within critical distance and to determine the orientation of the wheelchair and position within the map. The wheelchair may be in motion during this state.
scanEnviro – This VI will be the general running state of the system. While it is running the chair will be moving and constantly checking all the sensors until something of interest is noted. Once input from the sensors is noticed then the system will determine what the changes must be made.
checkOrient – This VI will use the compass sensor and the user given starting point inputs to check and make sure that the chair is facing the proper direction to reach its next point. If the chair is not properly oriented then it will prompt the user of the problem.
checkObs – This VI will use the front sensors as inputs. Once these sensors return a value denoting that an obstacle is within critical range the wheelchair run the stopChair and alertUser VIs and wait for the situation to be resolved.
notifyUser – This VI will send a message to the LCD display to let the user know that their destination has been reached. After the user is prompted the program will return to the idle state.
Obstacle detection
The obstacle detection state is entered if an obstacle or drop-off is detected within a critical distance relative to the current operation. In this state, the controller issues a command to halt navigation and alerts the user.
stopChair – This VI will bring the chair to a complete stop when it is called. Once the chair is stopped it will not restart until the problem has been resolved.
alertUser – This VI will send a message to the LCD display to let the user know that there is a problem that must be resolved before the wheelchair will continue on its path.
Track navigation
The track navigation state is entered when the current path is free of obstacles. In this state, the controller reads the photodetector arrays and determines the appropriate action based on the position determined in the scan environment state.
scanTrack – This VI will read the arrays of photo reflectors on the bottom of the wheelchair to determine if the wheelchair is over the line that it must follow. If the line is detected the checkTrack VI will be run. If the line is not detected then the stopChair and alertUser Vis will be run.
checkTrack – This VI will determine if the wheelchair centered on the path line. If the chair is not centered, then the rotLeftRight VI will be called to correct the wheelchair so it will return to the center of the line.
General navigation
The general navigation state is entered when the current path is free of obstacles. In this state, the controller issues navigational commands to the wheelchair control box based on the position determined in the environment scan and track navigation state.
movFwdRvs – This VI will use its input to determine the speed the wheelchair will move in the forward and backward directions. It will output an 8-bit array to the microprocessor with 4 bits controlling the forward speed and 4 bits controlling the reverse speed.
rotLeftRight – This will use the check Track VI to make the wheelchair move in the left or right directions. It will output an 8-bit array to the microprocessor with 4 bits controlling the left direction and 4 bits controlling the right direction.
adjSpeed – This VI will output to the movFwdRvs VI to let it know if the speed of the wheelchair needs to be adjust so that it can successfully navigate the course.checkKeypad – this function/VI polls the keypad port in a continuous loop and exit when a response is received indicating that a key has been pressed.
3 Sensors
The following sensors were used in the design for the project. Included are the technical sepcifications for each sensor, how they are interfaced with the controller, and how they are used.
1 Ranging Module
Ranging Module
The technical specifications for the MaxSonar EZ1 ultrasonic sonar sensor are shown below. Also shown are the pin connections and how they are used.
Table 6.9 – EZ1 Technical Specifications [9]
|Power | |
| Voltage |5 Volts |
| Current |3 mA Typical |
|Frequency |20 kHz |
|Clock |625 kHz (1.6 µs) |
|Range | |
| Maximum |254 in |
| Minimum |0 in |
|Resolution |1 in |
|Weight |4.3 grams |
|Size |0.785” w x 0.870” h x 0.645” d |
Table 6.10 – EZ1 Pin Connections [9]
|GND |This pin is used for the connection to ground. |[pic] |
|+5 |This pin is used for the 5VDC to power the | |
| |device. | |
|TX |This pin is used for output to an RS232 serial | |
| |connection. | |
|RX |This pin turns the sensor off when brought low. | |
| |(high by default) | |
|AN |This pin is the analog voltage output with | |
| |scaling of Vcc/512 per inch. | |
|PW |This pin is a pulse width modulation output with | |
| |scaling of 147µs per inch. | |
|BW |This pin is not used. | |
Mounting
Three sonar sensors are used for the obstacle detection, with the primary sensor facing directly forward and two secondary sensors angled symmetrically at an angle of 32 degrees. The purpose of the secondary sensors is to increase the detection area since the beam width of the sensors is small, as well as to help prevent against false readings by the primary sensor. The biggest concern is when detecting wall corners; the sensors are prone to giving false readings because the signal is reflected twice. A mounting diagram is shown in Figure 6.7.
[pic]
Figure 6.7 – Ranging Module Mounting Arrangement
2 Orientation
Magnetic Compass
Shown below are the technical specifications for the R117 magnetic compass. Also shown are the pin connections and their uses.
Table 6.11 – R117 Compass Technical Specifications [16]
|Power | |
| Voltage |5 Volts |
| Current |20 mA |
|Resolution |0.1˚ |
|Accuracy |~3-4˚ after calibration |
|Outputs | |
| Primary |Timing Pulse 1-37 ms (0.1 ms increments) |
| Secondary |I2C Interface, 0-255 and 0-3599 |
|SCL Speed |Up to 1 MHz |
|Weight |0.03 oz |
|Size |32 mm x 35 mm |
Table 6.12 – R117 Compass Pin Connections [[i]]
|1 |Needs supply voltage of 5 volts to power the |[pic] |
| |device. | |
|2 |Used for I2C interface | |
|3 |Used for I2C interface. | |
|4 |Pulse width modulator. | |
|5 |No connect. | |
|6 |Used for initial calibration. The pin has a | |
| |pull-up resistor and can therefore be left | |
| |unconnected after the calibration. The | |
| |calibration only needs to be done once | |
| |because the data is stored to EEPROM. By | |
| |default, the calibration is set for use at | |
| |67˚ latitude. | |
|7 |Used to select 50Hz (low) or 60Hz (high) | |
| |operation. | |
|8 |No connect. | |
|9 |Connection to ground. | |
The heading of the compass can be given as a pulse width modulated signal that varies from 1ms to 36.99 ms, where each 100µs represents 1˚. The time between pulses is 65ms, where the signal has a negative voltage. In order to use the PMW mode of operation, the I2C pins (2 & 3) were connected to the 5V power supply using 47 kΩ resistors.
The timing diagram in Figure 6.8 shows how the alternative I2C interface can be used to obtain compass measurements. However, this method will not be used for the project since the PMW method will be better suited to the needs of the project.
[pic]
Figure 6.8 – R117 Compass Timing Diagram [1]
Mounting
The device must be mounted parallel to the ground to function properly and cannot be used near magnetic fields, such as the ones created by some motors. Proximity to metal can also interfere with the accuracy of the device. The best place to mount it will be behind the chair, out of sight and near the controller and batteries.
4 Localization
The following section contains the detailed plan for localization design, how the technology will operate and the research will be covered. This section will also describe the specifications of the chosen device as well as connections and other devices needed for this technology to be implemented.
Photodetectors
The team researched the use of two different types of infrared reflective sensors, a single-line detector and a tracker sensor composed of three parallel sensors. Both of these sensors were similar in design and both available from Lynxmotion.
After testing both sensors and comparing the results, the tracker sensor was decided to be the best device for this project. The differences between the sensors’ detection capabilities with different tape types and colors will be presented in the testing section. The results showed the tracker sensor to be more sensitive and more reliable than the single-line detector. The single-line detector requires a cover to block out extraneous light for better reading. Finally, the tracker sensor is less expensive; it provides three sensors for $20 where the single-line detector is $15 for a single sensor ($119.70 vs. $269.10 for 18 sensors). The only limitation to the tracker sensors is that they are a fixed distance apart and can not be adjusted. The main features of the tracker sensor are outline in Table 6.13.
Table 6.13 – Lynxmotion Tracker Sensor Features
|Sensor type |Reflective IR |
|IR sensor |Combined IR LED and detector |
|I/O required |Three digital lines (inputs) |
|Minimum range | ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- microsoft excel project plan template
- software development project plan template
- software project plan examples
- software development project plan example
- project plan for software development
- free project plan template word
- software project plan template
- basic project plan template excel
- free project plan template excel
- sample project plan template
- simple project plan template free
- product development project plan template