VA Research and Development LOGO

Logo for the Journal of Rehab R&D
Volume 41 Number 3B, May/June 2004
Pages 429 — 442

The Smart Wheelchair Component System

Richard Simpson, PhD, ATP; Edmund LoPresti, PhD; Steve Hayashi, PhD; Illah Nourbakhsh, PhD;
David Miller, PhD

University of Pittsburgh, Forbes Tower, Pittsburgh, PA; Assistive Technology Sciences, Pittsburgh, PA; Robotics Institute, Carnegie Mellon University, Pittsburgh, PA; University of Oklahoma and KISS Institute for Practical
Robotics, Norman, OK
Abstract — While the needs of many individuals with disabilities can be satisfied with power wheelchairs, some members of the disabled community find it difficult or impossible to operate a standard power wheelchair. To accommodate this population, several researchers have used technologies originally developed for mobile robots to create "smart wheelchairs" that reduce the physical, perceptual, and cognitive skills necessary to operate a power wheelchair. We are developing a Smart Wheelchair Component System (SWCS) that can be added to a variety of commercial power wheelchairs with minimal modification. This paper describes the design of a prototype of the SWCS, which has been evaluated on wheelchairs from four different manufacturers.
Key words: man-machine systems, rehabilitation, robotics, wheelchairs.

Abbreviations: CPWNS = Computer-Controlled Power Wheelchair Navigation System, EJSCI = Everest & Jennings Specialty Controls Interface, SWCS = Smart Wheelchair Component System.
This material was based on work supported by a Small Business Innovation Research (SBIR) grant from the National Center for Medical Rehabilitation Research (NCMRR) of the National Institute of Child Health and Human Development (NICHD) of the National Institutes of Health (NIH). Invacare and Everest & Jennings donated wheelchairs in support of this research.
Address all correspondence to Richard Simpson, PhD; Forbes Tower, Suite 5044, Sennott and Atwood Streets, University of Pittsburgh, Pittsburgh, PA 15260; 412-383-6593; fax: 412-383- 6597; email:


Independent mobility is critical to individuals of any age. Children without safe and independent self-ambulation are denied critical learning opportunities, which places them at a developmental disadvantage relative to their self-ambulating peers [1]. Adults who lack an independent means of locomotion are less self-sufficient, which can manifest itself in a negative self-image [2]. A lack of independent mobility at any age places additional obstacles in the pursuit of vocational and educational goals. While the needs of many individuals with disabilities can be satisfied with power wheelchairs, some members of the disabled community (up to 40% [3]) find operating a standard power wheelchair difficult or impossible. This population includes, but is not limited to, individuals with low vision, visual field neglect, spasticity, tremors, or cognitive deficits.

To accommodate this population, several researchers have used technologies originally developed for mobile robots to create "smart wheelchairs." A smart wheelchair typically consists of either a standard power wheelchair base to which a computer and a collection of sensors have been added or a mobile robot base to which a seat has been attached. Unfortunately, a smart wheelchair system that requires substantial modification to the wheelchair may be impractical for installation in many seating clinics, may interfere with normal service of the wheelchair, and may prevent clients from obtaining wheelchairs that provide navigation assistance features while also meeting their needs for specialty seating and other features.

We are therefore developing a modular Smart Wheelchair Component System (SWCS), shown in Figure 1, which can be added to a variety of commercial power wheelchairs with minimal modification. We envision a collection of components that can be attached to standard power wheelchairs from several different manufacturers to convert them into smart wheelchairs. The SWCS is being designed to accommodate all traditional input methods (analog joystick, touch-activated switches, pneumatic "Sip n' Puff" switches, etc.) and to be compatible with multiple brands of wheelchairs.

Figure 1. Smart wheelchair component system.

In this paper, we describe an initial prototype, which was developed to demonstrate compatibility with multiple brands of power wheelchairs. The results of testing the system demonstrate that the prototype can provide navigation assistance on wheelchairs using two different input methods (analog joystick and switch joystick), three different wheel configurations (front-, mid-, and rear-wheel drive), and three different sets of control electronics (MKIVA, Penny+Giles, Curtis). Although these results are promising, the prototype remains several years from commercialization, and further development and testing are needed.


As shown in Table 1 [4-19], prototypes of several smart wheelchairs have been developed, but few have made the transition to a commercial product. A Canadian company, Applied AI [20], sells smart wheelchair prototypes for use by researchers, but these devices are not intended for use outside of a research lab. The CALL (Communication Aids for Language and Learning) Centre of the University of Edinburgh, Scotland, has developed a wheelchair with bump sensors and the capability to follow tape tracks on the floor for use within a wheeled-mobility training program [4]. This chair is sold in the United Kingdom (UK), Australia, and the United States by Smile Rehab, Ltd. (Berkshire, UK), as the "Smart Wheelchair."

Table 1.
Current and recent smart wheelchair research projects.
Dead Reckoning
Automatically reproduces routes that are taught to the system by manually driving the wheelchair from a starting point to a goal point.
Independence Enhancing Wheelchair
Laser Range Finder,
Dead Reckoning
Autonomous navigation between any two points is stored on an internal map of an environment.
The Intelligent
Wheelchair [6]
Vision, Infrared,
Is based on TinMan. Exploring autonomous navigation through vision-based landmark detection.
Intelligent Wheelchair
System [7]
Vision, Sonar,
Gesture Recognition
User provides input to system through facial gestures, which are interpreted through computer vision techniques. Response to user input (facial gestures) adapts based on wheelchair's surroundings.
INRO [8]
GPS, Sonar,
Drop-Off Detector
Provides autonomous navigation and wheelchair convoying.
Luoson III [9]
Gyroscope, Sonar,
Compass, Vision
Provides shared navigation assistance (obstacle avoidance) and target tracking.
MAid [10]
Sonar, Infrared, Laser Range Finder, Dead Reckoning
Semiautonomous mode provides task-specific behaviors, such as entering a restroom. Fully autonomous mode navigates to a goal position supplied by the user.
OMNI [11]
Sonar, Infrared, Bump,
Dead Reckoning
Provides obstacle avoidance and task-specific operating modes.
RobChair [12]
Sonar, Infrared, Bump
Is based on TinMan. Provides local obstacle avoidance assistance.
Rolland [13]
Vision, Sonar, Dead
Reckoning, Infrared, Bump
Learns an environment while navigating; then plans paths through the learned environment. Also learns obstacle avoidance behavior through training.
Dead Reckoning, Sonar
Provides shared-control navigation (obstacle avoidance) and autonomous navigation.
Sonar, Dead Reckoning
Provides obstacle avoidance and "playback" of recorded routes.
Smart Wheelchair [4]
Line Trackers,
Bump Sensors
Is used as a mobility training aid. Follows lines and backs up when it collides with an obstacle.
Smart Wheelchair [16]
Ultrasonic Beacons
Determines its location by time-of-flight. Provides autonomous navigation but not obstacle avoidance.
TetraNauta [17]
Vision, Infrared, Sonar,
Provides autonomous navigation by following landmarks in the environment.
VAHM [18]
Sonar, Infrared,
Dead Reckoning
Offers autonomous navigation based on an internal map and semiautonomous navigation in which the VAHM provides obstacle avoidance in the form of two behavioral primitives (follow wall, avoid obstacles).
Wheelesely [19]
Vision, Infrared, Sonar
Is based on TinMan. Has exploring vision-based navigation assistance.

The majority of smart wheelchairs that have been developed to date have been tightly integrated with the underlying power wheelchair, requiring significant modifications to function properly. Examples of modifications include adding wheel rotation sensors for dead reckoning and bypassing the wheelchair's motor controller to control the wheelchair's motors directly. Currently,

the SWCS, the Notre Dame Computer-Controlled Power Wheelchair Navigation System (CPWNS) [3,5], and the Hephaestus Smart Wheelchair System [21] are the only systems that have been (or are being) developed as stand-alone units that can be added to existing wheelchairs.

The CPWNS is intended for use with multiple brands of wheelchairs, but focuses on providing autonomous navigation. The CPWNS uses computer vision to detect special markers placed in its environment to identify its location as part of an algorithm for accurately reproducing pretrained routes. The CPWNS will only work in environments that have been modified to provide navigation cues for the smart wheelchair and will not work in unmodified environments or without pretrained routes.

The Hephaestus Smart Wheelchair System demonstrated the feasibility of reproducing the desirable obstacle-avoidance behavior developed for the NavChair [22] without requiring modifications to the underlying power wheelchair. During operation, the Hephaestus System interrupts the connection between the joystick and the Everest & Jennings Specialty Controls Interface (EJSCI). The EJSCI performs all filtering and smoothing of user input and thus provides a single point into which all user input and output devices can be connected to the wheelchair. By interrupting user commands before they reach the EJSCI, the Hephaestus System can modify them while remaining completely transparent to the underlying power wheelchair. The Hephaestus differs from the CPWNS in that it does not provide environmental modifications and also cannot provide autonomous navigation between points.

The investigative team developing the SWCS has previously worked on several smart wheelchair projects, including the NavChair [22], the Hephaestus [21], and the TinMan [23], along with research on computer vision and force-feedback joysticks for smart wheelchairs [24,25]. As just described, the SWCS shares with the Hephaestus the goal of compatibility with multiple brands and models of wheelchairs, but the mechanisms for interfacing with wheelchairs have changed significantly with the introduction of digital communication buses in wheelchairs since the Hephaestus was developed. Similarly, the obstacle avoidance behavior and sensors of the SWCS are based on the technologies used by the TinMan, but have also changed in response to advances in technology.


The performance criteria established for the SWCS are-

1. Minimum average obstacle clearance in "safe" mode, with a goal of 30 cm.
2. Minimum diameter of an obstacle that can be detected, with a goal of 2.5 cm.
3. Maximum distance from an object (e.g., table) when docking (see definition in footnote, p. 437), with a goal of 15 cm.
4. Maximum distance from wall when following a wall down a hallway, with a goal of 30 cm.
5. Minimum door width the system is capable of passing through, with a goal of 81 cm.
6. Maximum audible noise, with a goal of 55 dB.

These criteria were chosen to demonstrate that the SWCS could support a wide range of behaviors. Because the performance criteria could not be calculated from real performance data, the criteria were determined based on clinical experience, informal user input, and legal guidelines. One should note that some of these performance criteria are actually mutually exclusive. For example, the SWCS obviously cannot maintain a minimum obstacle clearance of 30 cm (Criterion 1) while simultaneously allowing an adult-sized power wheelchair to pass through a door with a width of 81 cm (Criterion 2). Further work, involving the participation of potential users and deployment of smart wheelchair technology in the real world, is needed to identify more specific design criteria for different user populations and needs.


The total SWCS consists of sensors, control electronics, computational hardware, and navigation assistance software (described in the "Evaluation of Drop-Off Detection" section of this paper). Power for the sensors is drawn from the wheelchair batteries. A voltage regulator that supplies 5 V to the infrared sensors and another voltage regulator that supplies 12 V to the sonar sensors convert the 24 V from the batteries.

The SWCS uses sonar, infrared, and bump sensors in combination for redundancy, because each sensor has different strengths and weaknesses. In keeping with our goal of producing a system that was both modular and configurable, one sonar and one infrared sensor were housed together in an 8.5 5.5 4.0 cm box (shown at the bottom right side of Figure 1), which we referred to as a "sensor module." Eleven sensor modules were mounted on the wheelchair or wheelchair lap tray with the use of Velcro or duct tape. In future prototypes, a mounting system will be developed for the sensors that allows more durability than Velcro or duct tape but still allows flexible positioning of the sensors.

The general configuration of sensors is shown in Figure 2, but the exact location of sensors varied between wheelchair models. For the front corner sensors (sensors 2 and 3 in Figure 2), the sonar and infrared sensors were mounted so that their beams were perpendicular to each other; for all other modules, the sonar and infrared sensors were oriented in the same direction. This change was made for sensors 2 and 3 because of the distance (between 8 cm and 50 cm) at which the infrared sensors are able to detect obstacles. Because of the angle of sensor modules 2 and 3, if the infrared sensors were parallel with the sonar sensors, they would not detect an obstacle until it was almost at the footrests. However, because the infrared sensors are oriented perpendicularly to the sonar sensors, the infrared sensors can observe obstacles near the front corners of the wheelchair. It is desirable to closely approach some obstacles (for example, doorjambs of a doorway that the chair is approaching) but still important to avoid getting too close (e.g., colliding), making the short detection distance of the infrared sensors an asset in this configuration.

Figure 2. Placement of secsor modules.

As shown in Figure 3, the SWCS is "inserted" into a power wheelchair's control system between the user's input device and the wheelchair's motor controller.1 For wheelchairs that use Penny+Giles electronics (including Permobil, Sunrise Medical, and Jazzy), the SWCS connects to the Omni+ module (Permobil and Jazzy) or QTronix Universal Specialty Controls Module (Sunrise Medical). For Invacare wheelchairs, the SWCS interfaces with switch joysticks using the Digital Drive Box. For Everest & Jennings wheelchairs, intercepting the joystick signal currently requires opening the joystick module, reading the wires that carry the joystick signal, and altering the signal to those wires. In the future, we will use the Merlin Alternate Control to connect the SWCS to wheelchairs manufactured by Everest & Jennings. This approach will eliminate the need to open the joystick module.

Figure 3. Smart wheelchair component system.

The Omni+ module, QTronix Universal Specialty Controls Module, and the Digital Drive Box are designed to accept signals from an input device (such as a joystick or attendant control) and present the user's input to the wheelchair's proprietary control electronics. Normally, the input device is plugged directly into the interface module. When the SWCS is installed, however, both the input device and the interface module plug into the SWCS. The SWCS reads the signal from the input device and sends a revised signal to the wheelchair's motor controller. The motor controller then treats the revised signal as if it came directly from the input device. Under most circumstances, the revised joystick signal is identical to the original signal but, if an obstacle is detected, the SWCS alters the joystick signal to avoid collisions.


The navigation assistance software is written in C++ and currently runs on a laptop computer. The software reads the values of the user's input signal and all sensors at a rate of 10 Hz. User input and sensor data are combined into "cases" that are used to make obstacle avoidance decisions. Example cases and wheelchair responses are listed in Table 2, where sensor numbers (except sensors 10 and 11, which are omitted) are based on Figure 2. The specific cases that are in use at any one time vary depending on the specific behavior that is desired from the SWCS (e.g., passing through a narrow doorway versus driving quickly through a room with few obstacles). The specific cases (and resulting algorithm) used during the reliability tests (described in "Reliability Testing" section) are shown in Figure 4.

Table 2.
Example cases for wheelchair response to obstacles.
Joystick Signal
Sensors Indication
Wheelchair Response
Obstacle in Front of Chair
Speed signal above neutral
(forward movement)
Sensors 1, 2, or 3 exceed "stop"
Prevent forward movement
Speed signal above neutral
(forward movement)
Sensors 1, 2, or 3 exceed "slow down"
Limit forward speed
Obstacle Behind Chair
Speed signal below neutral
(backward movement)
Sensors 8, 9, 10, or 11 exceed "stop"
Prevent backward movement
Speed signal below neutral
(backward movement)
Sensors 8, 9, 10, or 11 exceed "slow down" threshold
Limit backward speed
Obstacle at Right;
Left Is Clear
Direction signal above neutral (turning right)
Sensors 3, 5, 7, or 8 exceed "stop"
Turn left, away from obstacle
Direction signal above neutral (turning right)
Sensors 3, 5, 7, or 8 exceed "slow down"
Reduce turning speed
Obstacle at Left;
Right Is Clear
Direction signal below neutral (turning left)
Sensors 2, 4, 6, or 9 exceed "stop"
Turn right, away from obstacle
Direction signal below neutral (turning left)
Sensors 2, 4, 6, or 9 exceed "slow down"
Reduce turning speed
Obstacles at Both Sides
Direction signal not neutral
(turning either direction)
One of sensors 2, 4, 6, or 9 and one of sensors
3, 5, 7, or 8 exceed "stop" threshold
Prevent turning

Figure 4. Flowchart of navigation assistance algorithm used during reliability testing.

Note that each case (each row in Table 2) affects either the speed or direction component of the joystick signal. To stop the chair in response to obstacles in front or behind, the navigation assistance software sets the speed component of the joystick signal to the voltage corresponding to neutral. To stop the chair in response to obstacles at the sides, the software sets the direction component to the neutral voltage. To slow down the chair, the software limits the speed and/or direction components to certain bounds above or below the neutral voltage. To turn the chair, the software sets the direction component to a voltage, which causes the wheelchair to turn in the desired direction.

No single case can cause the software to prevent both forward/backward movement and turning, but multiple cases can be triggered at once and result in a situation in which the wheelchair will not move in any direction. For these situations, the SWCS includes an override switch that allows the user to bypass the software and control the wheelchair directly with the unmodified joystick signal.

The laptop computer provides a visual display used for debugging, but the user interface does not rely on visual feedback. The user drives the wheelchair as normal, and the software prevents movement in certain directions based on the sensor signals. The final system is not expected to provide visual feedback, although auditory and tactile feedback will be explored.


As shown in Figure 5, we performed tests to determine whether the Sharp GP2D12 infrared range finder (also used for obstacle detection) could be used to detect drop-offs (e.g., curbs, descending stairways). To be useful, a drop-off detector must be able to detect drop-offs far enough in advance to stop the chair before it reaches the drop-off. Informal tests indicated that a Quickie S-626 power wheelchair required approximately 27 cm to come to a stop from a speed of 40 cm/s. Obviously, a wheelchair's actual stopping distance depends on many factors, such as the responsiveness of the user's input device, the acceleration and deceleration settings chosen by the user, the weight of the user, and the slope and material of the surface on which the wheelchair is riding. Given this uncertainty, we chose a braking distance of 27 cm as a reasonable starting point for our investigation of drop-off detection.

Figure 5. Drop-off detector mounted on an Invacare Action Arrow (Invacare,Elyria, Ohio).

We tested the distance at which the GP2D12 could detect drop-offs outdoors (in direct sunlight) on the edge of a 12.7 cm curb and indoors on the edge of a 96.5 cm drop. The GP2D12 was attached to the footrests of a Quickie S-626 power wheelchair (see Figure 5), and the voltage response was measured when the wheelchair was on level ground. The wheelchair was then positioned at the furthest distance from the drop-off that resulted in a sensor reading at least 20 percent lower than the original value, and the distance from the drop-off to the wheelchair's front casters was measured. We repeated this test for two sensor angles (45 and 60) under each lighting condition. The deceleration rate was not controlled in this experiment. The results, listed in Table 3, show that (1) the detection distance was approximately 35 cm at 45 and 46 cm at 60 and (2) conditions between indoor and outdoor lighting had no noticeable performance difference.

Table 3.
Results from evaluation of the Sharp GP2D12 sensor for drop-off detection. Distances were measured from front caster to edge of drop.
Lighting Condition
Sensor Angle
Detection Distance

The detection distances recorded in Table 3 clearly limit the maximum wheelchair speed for safe driving. For example, since the Quickie S-626 required 27 cm to come to a complete stop at a speed of 40 cm/s, a detection distance of 45 cm would be sufficient at this speed. As shown in Table 4, however, the SWCS already limits the maximum speed of the wheelchair to a point at which drop-off detection is feasible. Further experiments at the wheelchair's maximum deceleration rate and various speeds will indicate the maximum safe speed for which the wheelchair can be used.

Table 4.
Wheelchair models and input devices used in system testing.
Input Method
Control Electronics
Maximum Speed
Action Arrow
Invacare, Elyria, Ohio
Switch joystick
Forward = 18.8 cm/s
Reverse = 18.0 cm/s
Quickie S-626
Sunrise Medical,
Carlsbad, California
Center-drive wheel
Proportional joystick
Penny+Giles (QTronix)
Forward = 41.7 cm/s
Reverse = 61.8 cm/s
Permobil, Sweden
Proportional joystick
Forward = 20.6 cm/s
Reverse = 16.1 cm/s
Everest & Jennings,
Atlanta, Georgia
Proportional joystick
Not available

The SWCS was evaluated with the wheelchairs listed in Table 4 for performance (in terms of the criteria listed in "Performance Criteria" section) and reliability. These wheelchairs represent three different drive configurations (front-wheel, mid- or center-wheel, and rear-wheel) to verify that the SWCS can function on a variety of wheelchair models. Note that the maximum speed for each wheelchair was limited compared to the maximum speed each wheelchair could achieve. The wheelchair speed was limited based on the computational speed of the computer performing obstacle avoidance calculations and our desire to be able to stop the wheelchair suddenly to avoid a dynamic obstacle without jarring the user.

During all evaluation activities, either (1) an able-bodied member of the investigative team operated the SWCS or (2) we configured it to wander randomly and autonomously.2 The investigative team chose not to perform limited-duration trials involving individuals with disabilities because previous experience has shown that user trials of a smart wheelchair performed over a limited number of sessions are unlikely to produce significant differences in performance between aided and unaided navigation [26]. This does not, of course, discount the performance of evaluating the SWCS with individuals with disabilities. However, we have chosen to delay user trials until the SWCS has been developed to the point that it is ready to conduct long duration trials. Therefore, this paper is limited to the results of bench testing and full usability testing, with a more refined version of the SWCS to be reported in subsequent publications.

Performance Testing

The first two criteria address the safety of the SWCS: its capability (1) to maintain a safe distance from obstacles and (2) detect obstacles of various sizes. The remaining four criteria address functionality: (1) its capability to travel through doorways, (2) its capability to travel through narrow hallways, (3) its capability to pull up to furniture (docking3) without interference from the obstacle avoidance software, and (4) the ability of the user to maintain a conversation without interference from the noise associated with the system, especially the sonar sensors. Note that all "obstacles," "furniture" and "doorways," were formed with the use of empty cardboard boxes.

For all six criteria, a wheelchair driver who did not have a disability tested the SWCS. We performed an iterative cycle of testing and software adjustment until the system could meet each criterion on three successive attempts while avoiding collisions. Our goal in adjusting the control software was to demonstrate that the SWCS could be configured to support a wide range of behaviors, not to demonstrate that a single configuration could support all potential behaviors. Previous experience has demonstrated that a single configuration cannot support the full range of behaviors in which a smart wheelchair could be expected to engage [27,28].

The final results from all tests are shown in Table 5. Only partial results are available for the Everest & Jennings chair because a fault in the wheelchair controller curtailed testing.

Table 5.
Performance results for four wheelchairs. Results are given as mean standard deviation.
Performance Characteristic
Everest & Jennings
Minimum Average Obstacle Clearance in "Safe" Mode (cm)
37.2 4.9
39.4 2.3
35.1 1.9
48.3 2.5
Minimum Diameter (cm) of an Obstacle That Can Be Detected
Not Available*
Maximum Distance (cm) from an Object (e.g., Table) When "Docking"
10.4 2.3
6.7 1.4
12.3 3.4
10.6 1.7
Maximum Distance (cm) from Wall When Following a Wall Down a Hallway
26.2 4.4
28.8 3.9
22.6 4.4
25.2 5.0
Minimum Door Width (cm) System Can Pass Through
Not Available*
Maximum Audible Noise (dB)
52.3 0.6
54.7 0.6
55.3 1.5
54.7 0.6
*Only partial results are available for the Everest & Jennings chair because a fault in the wheelchair controller curtailed testing.
Minimum Obstacle Clearance (Criterion 1)

The wheelchair was positioned 1.5 m from the near edge of a 90 cm 45 cm 1 m obstacle, oriented straight toward the obstacle. The driver attempted to drive toward the obstacle at the maximum speed allowed by the wheelchair (see Table 4), until the wheelchair collided with the obstacle or the system acted to prevent a collision. The nearest distance between the wheelchair and the obstacle was measured. If the distance did not meet the target criterion, or the wheelchair collided with the obstacle, we changed the thresholds that the navigation assistance software used to improve performance and then repeated the test. We repeated the test three times for the final software configuration and then repeated the entire protocol for the wheelchair driving backward toward the obstacle.

Minimum Obstacle Diameter (Criterion 2)

We repeated the protocol for Criterion 1 with the wheelchair driving forward toward a column with radius 2.2 cm and height 1.2 m.

Maximum Distance from an Obstacle When Docking (Criterion 3)

We repeated the protocol for Criterion 1 again. For each trial, if the final distance between the wheelchair and the obstacle was greater than 15 cm, we altered the thresholds to allow closer approach to obstacles in front of the chair and repeated the trial. If the wheelchair collided with the obstacle, we altered the thresholds to make the system more adverse to collisions. This process continued until the SWCS stopped the wheelchair within 15 cm of the obstacle without colliding on three successive attempts with the same software configuration.

Maximum Distance from a Wall When Following
the Wall (Criterion 4)

The driver drove the chair along a 4.3 m plaster wall. A line was marked 30 cm from the wall. The beginning position of the wheelchair was 60 cm, oriented toward the wall at a 60 angle (see Figure 6). The driver began by driving toward the wall until the wheelchair collided with the wall or the system prevented further approach. The distance from the wall at this point was measured. The driver then attempted to orient the wheelchair parallel with the wall and drive along the wall at a constant distance of 30 cm, or as closely as possible, until the wheelchair reached the far wall. The investigators observed whether the wheels nearest the walls moved more than 30 cm away from the wall (as marked by the reference line) and recorded the final distance between the wall and the nearest point on the wheelchair as a single quantitative measure of performance. If the wheelchair collided with the wall at any time, moved outside the reference line, or had a final distance greater than 30 cm, the obstacle avoidance software thresholds were adjusted. We repeated the trial until the SWCS allowed the wheelchair to drive within 30 cm of the wall without colliding on three successive attempts with the same software configuration.

Figure 6. Test to determine maximum distance from a wall when following thewall. Arrows indicate the direction of travel.
Minimum Doorway Width (Criterion 5)

The driver attempted to navigate the wheelchair between a 90 cm 45 cm 1 m obstacle representing the door and right doorjamb and between a 45 cm 45 cm 1 m obstacle representing the left doorjamb (see Figure 7). The obstacles were initially 90 cm apart. The beginning position of the wheelchair was 170 cm from the near edge of the larger obstacle, halfway between the left and right "doorjambs." The larger obstacle projected closer to the beginning position of the wheelchair in order to model a doorway with the door open toward the wheelchair. The driver attempted to drive straight through the doorway. If the navigation was successful, the boxes were moved closer together. If the navigation was not successful (a collision occurred or the system would not allow passage through the doorway) and the doorway was 81 cm wide or wider, the obstacle avoidance software thresholds were adjusted until the doorway could be successfully traversed. We repeated the trial until the wheelchair was able to safely navigate an 81 cm wide doorway on three successive attempts with the same software configuration.

Figure 7. Test to determine minimum doorway width SWCS could passthrough. Arrow indicates the direction of travel.
Maximum Audible Noise (Criterion 6)

We measured system noise with a sound meter when the obstacle avoidance software was activated and the circuitry and all sensors were powered. The sound level directly in front of the wheelchair headrest (driver head position) and 91 cm in front of the headrest (conversational partner position) were measured and recorded three times for each position.

Reliability Testing

We evaluated the SWCS for reliability during tests in which the laptop computer automatically drove the wheelchairs. Each wheelchair moved within an enclosed area (4.5 4.3 m) containing six obstacles (45 cm 45 cm 1 m each), and the SWCS selected random speed and direction signals for the joystick every 7.6 s. The SWCS obstacle avoidance software was also active.

The measures of interest were "failures" and "collisions." Failures were defined as any event that brought the wheelchair to a halt and included electrical faults and operating system crashes. Collisions were defined as any time that the wheelchair came into contact with an obstacle (empty cardboard boxes) regardless of magnitude. Hence, a collision in which the wheelchair brushed, but failed to move, a box was counted the same as a collision that caused movement of the box.

For each wheelchair, we recorded system failures (other than collisions) during an initial observation period during which we adjusted the software to reduce the risk of collisions. We then recorded collisions and system failures during a final observation period in which the software was not adjusted. Results from the reliability trials are shown in Table 6. For the period in which collisions were recorded, the majority of collisions were brushes. A few collisions did move boxes from their original position, but we did not record how many fell in each category because of the difficulty in reliably distinguishing between a "brush" and a "collision."

Table 6.
Results from reliability testing.
Mean Time
Between Failures
(Total Hours)
9.3 (74.2)
60 (60)
56 (56)
Between Collisions (Total Hours)
8.9 (35.5)
18.7 (56)
15 (30)

For the Sunrise Quickie S-626, we observed and traced eight system failures to two electrical problems. We corrected these electrical problems prior to testing with the Invacare Arrow. Reliability testing with the Everest & Jennings Solaire chair was interrupted because of an electrical problem with the wheelchair controller. In addition to collisions, 10 other system failures were observed during 190 hours of testing across the three wheelchairs, or one failure every 19 hours. We traced each of these failures to electrical problems or the computer operating system, rather than the navigation software. We recorded system failures in addition to collisions for two reasons. First, the overall safety of the SWCS requires that the control electronics be reliable, as well as the sensors. Second, we assumed that the underlying wheelchair system was reliable and that any failures of the wheelchair would be due to the SWCS. Future work will include developing a more robust electrical system and implementing the software on a microprocessor rather than a laptop computer.


The SWCS prototype was designed and tested to demonstrate the commercial feasibility of a smart wheelchair system. Rather than constructing a brand new wheelchair from the ground up, we chose to emphasize compatibility with multiple types of wheelchairs. To this end, the SWCS prototype was interfaced with wheelchairs from several different manufacturers. The prototype met our design criteria on power wheelchairs with different motor controllers and drive wheel configurations (i.e., front-, mid-, and rear-wheel drive), and compatibility was established with both a traditional (analog) joystick and a switch joystick.

Results from the performance tests demonstrate that the SWCS can support a wide range of behaviors, including close approach to obstacles, door passage, and wall following. However, the performance test results also demonstrate that different behaviors could require very different (and mutually exclusive) configurations of the control software. Some of the collisions observed during reliability testing could have been avoided if more sensors had been included; however, complete sensor coverage may be impractical in terms of the cost of the final system. Future work will include determining levels of sensor coverage that will balance safety and affordability.

Our initial results with using the Sharp GP2D12 for drop-off detection are promising, but the sensors must be evaluated under many more conditions before they can be considered a reliable solution. Until an inexpensive and reliable solution for detecting drop-offs has been identified, the SWCS will not be safe in unconstrained environments (particularly outdoors). However, we still feel that, even without the capability to detect drop-offs, the SWCS will be useful in indoor environments, such as schools, nursing homes, and assisted-living facilities.


Obviously, much future work remains to be completed before the SWCS is ready for commercialization. This work includes developing hardware, software, and enclosures; creating tools and instructions to simplify the task of configuring the SWCS for individual users; and testing the system with members of the target user population.


The SWCS prototype uses a Pentium-class laptop processor. However, the computational needs of the control algorithm can easily be supported by dedicated microprocessor architecture. In addition to replacing the laptop computer with a microprocessor, the data acquisition cards and other electronics used by the current prototype must also be redesigned to use inexpensive, reliable, and energy-efficient components.


During the performance tests, we used different thresholds to determine just how close the wheelchair could approach obstacles for different tasks, but we expect that the first commercially available system will use a single intermediate threshold that balances safety and functionality. Future work will explore allowing the user to manually change the software thresholds or allowing the chair to automatically adapt these software thresholds based on the user's behavior and observations of the environment [27,28].


Appropriate enclosures for the components of the SWCS will be crucial to the success of the system. The enclosures must be durable and facilitate mounting the components on a variety of wheelchairs. The enclosures also must not interfere with a user's seating and positioning hardware and should not detract from the appearance of the wheelchair. The enclosures will be designed so that they can be attached to wheelchairs with brackets that are already commonly used by wheelchair seating and positioning specialists.

A new footplate will also be developed that can be used to replace the existing footplates on a user's wheelchair. Mounting bump sensors on standard power wheelchair footrests is difficult, because the footplates on most footrests are designed to be smaller than most adult feet. Thus, on a standard footrest, a bump sensor is difficult to position so that the sensor is activated before a person's foot comes in contact with an obstacle.

Configuration Tools for Clinicians

One of the most important tasks that clinicians will face when configuring the SWCS for a client will be determining the number of sensors that will be used, along with each sensor's location and orientation. We expect that this process will be a collaborative effort between the clinician and client that will consider the client's navigation assistance needs along with the client's need for other equipment, such as seating and positioning hardware, a tilt-in-space or recline system, a ventilator, or an augmentative communication device. A critical piece of information that the clinician and client will need to decide is the sensor coverage that results from specific choices of sensor position and orientation. We plan to develop software that allows the clinician to visualize the sensor coverage (and blind spots) resulting from specific sensor location and orientation decisions.


We have planned a range of activities to evaluate the SWCS as it progresses toward commercialization. Mock-powered mobility assessments will be used to evaluate how the SWCS components interact with other seating and positioning equipment. User trials under controlled laboratory and (uncontrolled) real-world conditions will evaluate the capability of the SWCS to facilitate navigation tasks. Finally, the SWCS will undergo several portions of ANSI/RESNA (American National Standards Institute Rehabilitation Engineering and Assistive Technology Society of North America) wheelchair standards testing.

Drop-Off Detection

A longer-range goal is the development of a method for drop-off detection that (1) is robust across multiple lighting conditions and floor surfaces and (2) is affordable. Our belief is that sonar and infrared rangefinders are fundamentally limited in this regard. Instead, we are examining laser rangefinders and computer vision as alternative solutions. While neither of these technologies is currently sufficiently inexpensive for inclusion in a commercial product, either or both may become so in the future.

1. Rosenbloom L. Consequences of impaired movement: a hypothesis and review. In: Movement and child development. Holt KS, editor. London, England: HarperCollins; 1975.
2. Wright BAP. Physical disability-A psychosocial approach. New York: Addison-Wesley; 1983.
3. Fehr L, Langbein WE, Skaar SB. Adequacy of power wheelchair control interfaces for persons with severe disabilities: a clinical survey. J Rehabil Res Dev. 2000;37(3):353-60.
4. Nisbet PD, Craig J, Odor JP, Aitken S. "Smart" wheelchairs for mobility training. Technol Disabil. 1995;5:49-62.
5. Yoder JD, Baumgartner ET, Skaar SB. Initial results in the development of a guidance system for a powered wheelchair. IEEE Trans Rehabil Eng. 1996;4(3):143-51.
6. Gribble WS, Browning RL, Hewett M, Remolina E, Kuipers BJ. Integrating vision and spatial reasoning for assistive navigation. In: Assistive technology and artificial intelligence. Simpson R, editor. New York: Springer; 1998. p. 179-93.
7. Murakami Y, Kuno Y, Shimada N, Shirai Y. Collision avoidance by observing pedestrians' faces for intelligent wheelchairs. IEEE/RSJ International Conference on Intelligent Robots and Systems; 2001 Oct 29-Nov 8; Maui, HI. New York: IEEE; 2001. p. 2018-23.
8. Schilling K, Roth H, Lieb R, Stutzle H. Sensors to improve the safety for wheelchair users. 3rd Annual TIDE Congress; 1998 July; Helsinki, Finland. Helsinki: TIDE; 1998.
9. Chen MT, Luo RC. Multilevel multiagent based team decision fusion for mobile robot behavior control. 3rd World Congress on Intelligent Control and Automation; 2000 Jun 28-Jul 2; Hefei, China. New York: IEEE; 2000. p. 489-94.
10. Prassler E, Scholz J, Fiorini P. A robotic wheelchair for crowded public environments. IEEE Robotics Autom Mag. 2001;8(1):38-45.
11. Borgolte U, Hoyer H, Buehler C, Heck H, Hoelper R. Architectural concepts of a semi-autonomous wheelchair. J Intell Robotic Syst. 1998;22(3-4):233-53.
12. Pires G, Nunes U. A wheelchair steered through voice commands and assisted by a reactive fuzzy-logic controller. J Intell Robotic Syst. 2002;34(3):301-14.
13. Roefer T, Lankenau A. Architecture and applications of the Bremen autonomous wheelchair. Info Sci. 2000;126(1):1-20.
14. Katevas NL, Sgouros NM, Tzafestas SG, Papakonstantinou G, Beattie P, Bishop JM, Tsanakas P, Koutsouris D. The autonomous mobile robot SENARIO: A sensor-aided intelligent navigation system for powered wheelchairs. IEEE Robotics Autom Mag. 1997;4(4):60-70.
15. Balcells AC, del Rio FD, Jimenez G, Sevillano JL, Amaya C, Vicente S. SIRIUS: Improving the maneuverability of powered wheelchairs. International Conference on Control Applications; 2002 Sep 18-20; Glasgow, United Kingdom. New York: IEEE Control Systems Society; 2002. p. 790-95.
16. Seki H, Kobayashi S, Kamiya Y, Hikizu M, Nomura H. Autonomous/semi-autonomous navigation system of a wheelchair by active ultrasonic beacons. International Conference on Robotics and Automation; 2000 Apr 24-28; San Francisco, CA. New York: IEEE; 2000. p. 1366-71.
17. Balcells AC, Gonzalez JA. TetraNauta: A wheelchair controller for users with very severe mobility restrictions. 3rd Annual TIDE Congress; 1998 July; Helsinki, Finland. Helsinki: TIDE; 1998.
18. Bourhis G, Horn O, Habert O, Pruski A. An autonomous vehicle for people with motor disabilities. IEEE Robotics Autom Mag. 2001;8(1):20-28.
19. Yanco HA. Wheelesley: a robotic wheelchair system: Indoor navigation and user interface. In: Assistive technology and artificial intelligence. Mittal VO, Yanco HA, Aronis J, Simpson RC, editors. New York: Springer-Verlag; 1998. p. 256-68.
20. Gomi T, Ide K. The development of an intelligent wheelchair. Conference on Intelligent Vehicles; 1996 Sep 19-20; Tokyo, Japan. New York: IEEE; 1996. p. 70-75.
21. Simpson RC, Poirot D, Baxter MF. The Hephaestus Smart Wheelchair System. IEEE Trans Neural Syst Rehabil Eng. 2002;10(2):118-22.
22. Levine SP, Bell DA, Jaros LA, Simpson RC, Koren Y, Borenstein J. The NavChair Assistive Wheelchair Navigation System. IEEE Trans Rehabil Eng. 1999;7(4):443-51.
23. Miller DP, Slack MG. Design and testing of a low-cost robotic wheelchair prototype. Auton Robots. 1995;2(1): 77-88.
24. Ulrich I, Nourbakhsh I. Appearance-based place recognition for topological localization. IEEE International Conference on Robotics and Automation; 2000 Apr 24-28; San Francisco, CA. New York: IEEE; 2000. p. 1023-29.
25. Protho J, LoPresti EF, Brienza DM. An evaluation of an obstacle avoidance force feedback joystick. RESNA 2000 Annual Conference; 2000 June 27-30; Orlando, FL. Washington (DC): RESNA; 2000.
26. Simpson R, Poirot D, Baxter MF. Evaluation of the Hephaestus Smart Wheelchair System. The 6th International Conference on Rehabilitation Robotics; 1999 July 1-2; Stanford, CA. Stanford: ICORR. p. 99-105.
27. Miller DP. Semi-autonomous mobility verses semi-mobile autonomy. Proceedings of the AAAI Symposium on Agents with Adjustable Autonomy; 1999 March 22-24; Stanford, CA. Menlo Park (CA): AAAI; 1999. p. 79-80.
28. Simpson RC, Levine SP. Automatic adaptation in the NavChair Assistive Wheelchair Navigation System. IEEE Trans Rehabil Eng. 1999;7(4):452-63.
Submitted for publication March 7, 2003. Accepted in revised form August 18, 2003.
1The current prototype has been interfaced with both analog and switch joysticks, and future work is planned to accommodate additional input modalities.
2Since all testing was conducted with the SWCS either "unmanned" or operated by a member of the investigative team, no informed consent procedures were necessary.
3For testing purposes, "docking" was defined as maneuvering the from of the wheelchair as closely as possible to an object. This definition excludes "lateral docking," which was tested by the maximum distance from a wall criterion (Criterion 4).

Go to TOP  

Go to the Contents of Vol. 41 No. 1

  Last Reviewed or Updated Thursday, June 30, 2005 3:25 PM