Lessons Learned in the Application of Robotics Technology to the Field of RehabilitationH.F. Machiel Van der Loos, Ph.D.
AbstractThe Rehabilitation R&D Center of the Palo Alto VA teamed up with the
Stanford University Department of Mechanical Engineering in 1978 under the
leadership of Prof. Larry Leifer to start a rehabilitation robotics program
that has benefited from five major funding cycles to date. Many lessons were
learned along the way, mostly through the interactions between engineering
staff, clinical staff, persons with high level quadriplegia who served as test
subjects and their families and attendants. The prototypes that were developed
acted as sounding boards, revealing what worked, what did not, what had
promise, what was realistic given state-of-the-art elements, and when the level
of technology allowed a certain feature to be usable in a daily use
environment. This paper examines the chronology of the program with a special
emphasis on broad-scope effects. References to discussions of individual
aspects and studies are provided. IntroductionRobotics has always been considered an interdisciplinary science, but constrained to the Engineering disciplines. Rehabilitation Robotics adds one more dimension: the Life Sciences. While this discussion of lessons learned will necessarily focus on technology, the reasons behind the lessons span the expertise domains of engineering, computer science, psychology and occupational therapy. This technical paper has a clinically-oriented counterpart, written by my colleague Joy Hammel, Ph.D., O.T.R. Together, the two papers provide an overview of the U.S. Department of Veterans Affairs/Stanford University (VA/SU) Robotics Program over the past fifteen years. The dominant arena for the technology-based lessons learned is the human-machine interface. It is the most critical aspect of an interactive robot: all of the operator's actions and perceptions are channeled through this one gateway. The second area is the robot-environment interface, since all the robot's capabilities, in terms of tasks it performs under command of the operator, are ultimately enacted here. The VA/SU Robotics Program has predominantly focused on task-based interfaces, with the objective of building a robot with increasingly more powerful capabilities and increasing autonomy vis-à-vis its interactions with the world [8, 12]. In parallel with this robot capability came an increase in the level of cognitive interaction with the user, from the simple motion-based directives to task-level commands. The following sections chart the chronology of the Program through its various stages, describe the technology-based rationale for the decision points, and review the lessons we learned from the successive program phases.
Robotic Aid Project (RAP): 1978-1985.Overview of projectThe goal of RAP-I was to use available industrial robotics technology, in conjunction with commercial and prototype user interface devices, to derive a system usable by persons with quadriplegia [11]. Our goal was to replace the usual interface capabilities of the robot with adaptive access technology. In other words, we sought to duplicate the teach pendant (motion control) and user console (task-program command) of the PUMA-250 manipulator. Using a Zilog MCZ computer (8-bit, Z-80-based), we implemented an interface that included a 4-line, 80-character monochrome display, VOTRAX speech synthesis unit and Interstate Electronics VOTERM voice recognition unit. Each of these microprocessor-based I/O devices required its own interrupt-service routine written on the Z-80 computer as part of the main robot control program. Users could move the robot in any of the three teachbox modes (World, Tool and Joint coordinates) by saying the commands corresponding to Teachbox buttons (Up, Down, Left, Right, Plus, Minus, etc.). Both continuous and step motion modes were included, and robot speed was user-definable. The user could issue commands to implement pre-existing robot programs. These were designated in Military alphabet mode (Alpha, Bravo, Charlie, etc.). A listing of program functions was included as a cheat sheet. User ADL tasks, such as bringing a meal from microwave to table and then piloting the manipulator to bring spoonfuls in the vicinity of the user's face, were shown to be feasible if cumbersome. This research phase culminated in informal clinical trials with users who had a variety of disabilities and impairments [3]. The principal technological conclusions were that the I/O equipment was not reliable enough, and that the system as a whole was not robust enough to work continuously for more than an hour without a software or hardware error requiring rebooting or technical intervention. Lessons learnedThe first phase of the Robotics Program, largely a feasibility study, provided many first-order lessons in the area of Assistive Robotics. The other lessons confirmed or refuted our decisions to use or develop specific technologies. A table top is a very limited spaceA PUMA-250 manipulator mounted on a table top has a roughly hemispheric workspace with a 75 cm (~30") radius. The prototype 2-jaw gripper added 15 cm (~6") to this reach. However, the effective functional horizontal radius for table top manipulations does not change: to be able to reorient and maneuver objects near full arm extension requires the wrist to be partially flexed, reducing the maximum radius. The PUMA was mounted near the center of a 120 cm (~48") diameter table, along with a microwave oven and small refrigerator. This arrangement provided a usable feasibility-study environment, but was restrictive in terms of types of tasks, types of user interaction and extent of workplace structure (see figure 1). Later project phases addressed this issue by: 1. Adding a rotating kiosk at the side of the table so that the PUMA could access up to four different sets of objects and tools, for cooking, feeding, personal hygiene and office tasks. 2. Mounting the manipulator on a mobile robot so that it could navigate through a home and perform a wider variety of tasks. 3. Adding force sensing at the wrist of the manipulator to lessen the need to structure the environment by allowing the robot to use force information when picking up and handling objects. 4. Mounting the manipulator upside-down on an overhead transverse track above a desk surface to increase the lateral extension of the robot and remove the arm from the center of the user's workspace. Computer system limitations rendered the system too fragile for clinical trialsEarly microprocessor-based systems (1978 - 1972) were 2 MHz, 8-bit machines with very limited delivered software and integrated hardware. The adaptive access I/O capabilities we needed were available only in stand-alone units: 8-bit microprocessor-based embedded systems with factory defined interface protocols. They were not designed to be integrated with any particular other system. As a result, we generated much low-level software to interface with them. Inevitable glitches due to timing problems, bugs and undocumented "features", both in the units themselves and on the main Z-80 system, made operation fragile. Subsequent systems incorporated the following changes: 1. Use of 16 and 32-bit computers as they became available, such as the DEC LSI-11 and the 80286 and 80386-based IBM-PC compatibles. 2. Use of better software development environments, such as Borland TurboPascal(TM) and DEC MicroPowerPascal(TM). 3. Use of integrated solutions for voice I/O, such as VOTAN's VPC-2100 card for the IBM-PC. 4. Use of industry-standard video, such as IBM-PC supported EGA and VGA standards. Voice I/O recognition did not exceed the user frustration thresholdVoice recognition technology in 1980 was based on simple single-utterance template matching schemes. Templates were time samplings of the band-pass filtered and then digitized microphone input. Affordable processor technology did not allow for sophisticated algorithms. As a result, any changes in how users said words had a major impact on recognition rates [28]. It was often impossible to notice what changes in a user's voice were responsible for recognition accuracy. With only partial success, we tried many schemes of user training, vocabulary word changes, and parameter tweaking to attempt to enhance performance. Voice output was limited to speech synthesis based on phoneme-string representation of English words or phrases. The synthesis hardware did not produce easily-understandable speech, especially for first-time listeners. After being told what the unit was saying, users could, however, make effective use of the audio feedback. Solutions included: 1. Use of second-generation voice recognition units such as the Kurzweil K-1000 and the VOTAN VPC-2100. The Kurzweil, however, required a lengthy (two-hour) voice training phase to achieve its superior performance. We judged this to be inappropriate for our multi-user clinical trials. 2. Explicit vocabulary design included making words as different from each other as possible. In addition, the vocabulary could be modified on-line to accommodate users who had particular word problems. For example, the words "HOME" and "PHONE" were at times too similar, so users could easily change "PHONE" to "TELEPHONE". 3. The choice of microphone was critical to recognition effectiveness. Subsequent research phases paid particular attention to this aspect. 4. For voice output, two different later commercial products were deemed usable: the DEC DecTalk(TM) text-to-speech synthesizer, which included inflection, letter pair cues, special pronunciation instructions and a high-quality output; and the VOTAN VPC-2100's speech digitizer feature, which allowed previously recorded words and phrases to be spoken back. The DecTalk had an unmistakably artificial voice (actually, eight selectable voices), and the VOTAN unit spoke back a real human voice, but both were clear and understandable. Emphasizing motion commands over task execution is not appropriateIn this early work, duplicating robot functions was our focus. We were most interested in bringing existing robot capabilities to the user. The PUMA came equipped with a teach pendant, and we consequently spent considerable resources to duplicate its functions through voice commands. This feasibility phase showed clearly the onerous nature of this type of control (see next item as well). A second observation was that we were unintentionally training people to be robot engineers. However, the persons with high-level quadriplegia we recruited as test subjects were not interested in learning about robot functions: they just wanted to get the daily-living tasks done. With the proviso that they remained in control of task execution, it was less important how the tasks got done, whether it be through an attendant, special purpose equipment, or a robot. This led to a change in perspective and on the role of the user interface. Two paradigms were explored in later program phases: 1. The voice interface became more task-focused rather than motion-focused. Tasks were given names, and were used as voice "buttons". Motion commands were used to make selections within tasks, such as saying "DOWN" several times to point the gripper at the diskette to retrieve, once the automatic portion of the task had gotten the arm to the location of the top diskette. 2. The interface was divided into two task-oriented components: planning and execution. During the first, the user mapped out robot trajectories on the computer screen. During execution, the user sent the robot on its task, monitored its progress, and gave corrective commands. Motion control by voice is too cumbersomeThe information rate through voice, with each word equivalent to a button press, was one word every two seconds at best. Although voice could conceivably be exploited in a much richer, multi-dimensional manner through the use of non-speech (tonal) qualities, there remain the intractable difficulties of controlling the six axes of the robot simultaneously and in concert. This remains a central problem in all teleoperation applications, and certainly with assistive robots for persons with disabilities. Our program's responses to this human limitation, whether able-bodied or not, but especially in the face of control by persons with severe physical disabilities, were: 1. To use motion commands as a back-up to task execution and for corrective actions during tasks. 2. To remove all coordinate systems except the most used "world" mode. The other piloting modes ("tool" and "joint") were difficult to teach and use, and were essentially never invoked after training. Definitions of tasks through alphabet codes (ALPHA, BRAVO, ...) is not realisticThe robot programming language, VAL, is very similar to the ubiquitous computer language, BASIC, but still requires knowledge of programming and robotics to employ effectively. The goal in this Feasibility Study phase was to make program execution accessible to users. We combined special purpose programs (open the microwave door) with general purpose programs (move an object from location "A" to location "B"). All programs were designated by letters, and invoked through this coding mechanism. Due to the limitations of the voice recognition unit and in order to standardize at least the vocabulary for any task environment, we did not want to include task-specific vocabulary but rather use codes that had been proven to be phonetically easy to distinguish from each other. While this worked reasonably well phonetically, it was an unnatural interfacing strategy. In subsequent research phases, we addressed this topic by: 1. Abandoning the military alphabet for words that were meaningful in context. Each interface would thus be specific to the robot's environment. The constancy of the interface came from the semantics to instruct the robot to do tasks, and from intra-task conventions on object selection. 2. Moving vocabulary words and templates to data files for easy, off-line modification. The robot control program then used the data files to structure its interface. Thus, completely customized vocabularies and screens could be developed for different task environments. Use of spoken commands and feedback is essential in verbal computer interactionUsing voice I/O as part of the interface to computers and robots is not always appropriate. In certain cases, termed "busy hands, busy eyes" applications, voice I/O is considered appropriate. Interactive robot control is such a case, especially since the user needs to supervise ongoing operation, receive status, and possibly issue corrective actions while continuing to observe. The second reason for the use of voice is the disability of the user. Voice, in meaningful, context-dependent, single-word commands (as opposed to dictating a text by voice, or tapping action-specific single-character codes on a keyboard using a mouthstick) can be part of a fast, easy to train and effective interface. The notion of talking to your robot has been questioned repeatedly over the course of the project. Whether this is appropriate or not depends on the situation of use and the relationship set up between user and machine. Some types of assistive robots are conceived as extensions of a person with a disability, such as a wheelchair-mounted robot arm controlled by joystick. Just as it is not appropriate to talk to one's own arm, it would not be appropriate to replace the joystick with a voice interface. However, an assistive robot conceived as a replacement for an attendant can appropriately be commanded to carry out tasks verbally. The role of voice feedback is important. Firstly, it is a requirement based on the "busy hands, busy eyes" argument. Secondly, we believe that an interface between entities that ostensibly have bidirectional communication should be symmetric. Just as a screen is a shared space for a computer user's typed commands and the computer's responses, sound is a shared medium for voice-based interaction. A third argument is the desirability of redundancy in presenting important information or warnings to the user: all commands and replies are displayed on the screen as well as spoken. A complex mechatronic device needs a means of tracing system operation to fix bugsThe 8-bit Z-80 system, as mentioned, was notorious for crashing and requiring rebooting. The problem was often due to communication between the various subsystems, including the robot. Without tracking software in non-volatile memory, the only means of debugging was to note down the state of all the variables presented on the programmer's screen after a crash, and infer where the failure might have occurred. If the engineer was not present, the staff would often not be sufficiently familiar with the system to be able to take effective notes for later use. Since many bugs were intermittent and hard to reproduce, debugging was practiced more as an art than a science. Later robots contained file-based history lists, stored on hard disk, of time-stamped commands, states and errors reported by the various subsystems [25].
Clinical Robotics Laboratory (CRL): 1985-1989.OverviewBased on the lessons learned from the Robotic Aid Project and its 8-bit technology, one of the two spawned projects involved a complete technology modernization of the desktop concept [13]. [The other project focused on mobile robotics and is discussed in the next section.] The Clinical Robotics Laboratory (CRL) was established in the VA Spinal Cord Injury Center (SCIC) for development and evaluation of a new generation of desktop robots to assist people in performing Activities of Daily Living (ADLs). In the CRL, a newer generation of the same robot was used, the PUMA-260 (see Figure 1). Improved software and mechanics made this robot more robust. The 8-bit Z-80 based controller was replaced by an IBM-PC/XT (upgraded to 80286 and then 80386 microprocessors as these became available). The original speech I/O system was replaced by a succession of units, and finally by the VOTAN VPC-2100 card. Visual user feedback was presented on an EGA screen in functionally-distinct windows [9].
Figure 1: CRL desktop robot workstation with ADL-oriented set-up: a microwave oven and refrigerator flank the PUMA-260; a tool rack behind the robot holds items such as toothpaste, shaver, and washcloths. The applications of the CRL phase were the same as the for RAP. The project concentrated on activities of daily living, such as cooking, feeding and personal hygiene. A rotating kiosk with four faces for different task sets was tried and found to be too cumbersome, slow and unreliable. It was replaced with a fixed workspace early in the project. Better attention to workspace design allowed the robot to accomplish the same tasks as the kiosk-based version. The final workstation was used in a study of 24 persons with high-level quadriplegia to assess attitudes to automation in the clinic for ADL tasks [4]. Overall results indicated that training was not a problem, that people were positive toward the technology, and that this type of workspace-bound robot may not be appropriate for tasks like eating, which have a clearly social component. Lessons LearnedA robot needs to be embedded in a user environment to be most effectiveIf the robot is viewed as a peripheral device, it appropriately recedes from view as the task itself comes to the foreground and becomes the focus of attention. Reaching this state means the design has succeeded, training has been effective, and the user has achieved mastery over the robot as a tool. This is a difficult goal for the development team to embrace, because success depends on a diminished apparent presence of the robot itself, which is the focus of attention, of course, for the development team. The robot can do personal hygiene, and was preferred over attendantIt was surprising to many observers and test subjects that the robot could perform facial personal hygiene tasks. It was equally enlightening to learn that our test subjects on the whole preferred having the robot perform the personal hygiene tasks (tooth brushing, shaving, face washing), rather than having an attendant or family member do those tasks, even if the robot was not quite as fast or thorough as a person could be. Reasons cited were control of the task and the possibility of privacy. Worksite design is as important as robot designAs was observed with the RAP system, the table top robot is severely limited in range. It became even more clear in this phase that the worksite itself requires as much attention to design as the robot. Several concepts were tried, and the final one involved explicit design of the task artifacts and tools. Occupational therapists are commonly involved in the making, modifying, and shaping of tools for persons with disabilities so tasks formerly impossible become accessible. In this project, the robot was the client for these services rather than the person with a disability. The CRL team modified spoons, designed cup holders, found appropriate bowls, made wash cloth holders, and otherwise made tasks accessible to the PUMA and its gripper. The design of the worksite became an explicit operation as opposed to a casual activity. The interface needs to have multiple means of activating and stopping the robot to be safeNo matter how much better each version of the robot was compared to the previous one, the complex nature of the integrated system guaranteed that lapses in communications and failures would interrupt proper functioning. Instead of assuming that the robot would perform flawlessly and accepting crashes as a necessary evil, we included functional redundancy at critical nodes. In addition to two vocabulary words to stop the robot (a calm "stop" and a more animated "STOP!"), any loud noise was made a command to stop motion. To make sure the robot could be stopped in the absence of voice capability, two panic switches were mounted on the workstation, one on a gooseneck arm near the user's cheek, and one for the trainer or nearby staff. Finally, any obstruction greater than about 2 kg (5 lb) was sensed by the PUMA's low-level software and caused a shutdown. Equally important to being able to stop the robot was the means to restart it from any level of shutdown. All restarts were accessible by the user, without the need to perform manual actions, and all restarts allowed program continuation from the point of interruption. The only exception to this rule was a complete power failure to the workstation and robot while the robot was in use. A second area of designed redundancy was the means to issue commands. While the primary means was through voice control, keyboard shortcuts were available (two-digit number codes for the commands), and a serial port could accept all command codes. A Macintosh HyperCard stack was written for a later version of the robot to make use of this feature.
Mobile Vocational Assistant Robot (MoVAR): 1983-1988.Overview of projectThe MoVAR project used a unique, patented, 3-wheeled omni-directional base [7] with a PUMA-250 arm mounted on it [14, 20]. It was desk-high and designed to go through interior doorways (see Figure 2). All electronics and power components for the motors and sensors were mounted in the mobile base. A telemetry link to a console received commands and sent position and status information. The mobile base had a bumper-mounted touch sensor system to provide autonomy in the face of obstructions, a wrist-mounted force sensor and gripper-mounted proximity sensors to assist in manipulation, and a camera system to display the robot's activities and surroundings to the user at the console. The robot console had three monitors: graphic robot motion planning, robot status, and camera view. It had keyboard, voice, and head-motion inputs for command and cursor control, and voice output.
Figure 2: MoVAR robot base with instrumented bumpers and joystick; the PUMA-250 carries a camera for remote viewing, a six-axis force sensor and gripper with finger pad-mounted proximity sensors. A wireless digital link allows the mobile base computer to communicate with the user console. A later phase of this project added instructable natural language input capability, coupled to an internal world model, so that typed-in commands such as, "move to a position in front of the desk, and move west when the bumpers are hit" could be executed [2, 15]. Path planning was not a targeted research area for this project due to the many other research groups active in this domain. This project was stopped in 1988 when VA funding was terminated. The hardware and software were subsequently transferred to the Intelligent Mechanisms Group at the NASA Ames Research Center (Mountain View, CA) for use in the development of real-time controllers and stereo-based user interfaces for semi-autonomous planetary rovers. Lessons learnedA mobile robot needs to have subsystem-level redundancy to be safeThe MoVAR endeavor was a technology feasibility project. As such, design criteria focused on basic functional capabilities. Even so, MoVAR was a nine-axis, multi-sensor system. Problems with reliability occurred because each sensory and actuator subsystem was designed to be critical to the completion of a single function. Any failure (e.g., insufficient sensitivity to environmental conditions, broken components, incorrect software) was not recoverable by parallel componentry. While MoVAR achieved functional goals as defined by the "feasibility" criterion, its level of reliability, ease of use, interface competence and system integrity were not commensurate with clinical testing at the end of the development phase. MoVAR is a non-holonomic system, i.e., the actual position of the base depends not only on the number of rotations of the wheels, but on the positional time histories of each of them since leaving a reference location. This fact, coupled with inherent odometry inaccuracies in wheeled vehicles, means that a position tracking system with a number of inputs is essential. MoVAR used odometry as its basic system. A laser-and-beacon absolute positioning system and re-calibration capability using world fixtures such as recharging stations were under development at the end of the project. The sensor fusion and controller-subsystem redundancy issues were topics of separate theoretical work [16, 19]. The issue of system behavior in the event of different type of motor and amplifier failure led to conclusions about the requisite number of controllers, motors, and wheels to guarantee that the robot would not endanger its surroundings. Given available technology, these results were not appropriate to consider for the MoVAR project. The 9-DoF system required more computer power than could be placed on-boardMoVAR confirmed the homily, "You never have enough compute power or disk storage." Although state-of-the-art, the microprocessor-based controller that was placed on board MoVAR (DEC LSI-11, with KXT-11 co-processor for sensor signal preprocessing) and real-time software (DEC MicroPowerPascal) was not powerful enough to perform the kinematic calculations for all nine degrees of freedom simultaneously. It was capable of either mobility or manipulation control. As a compromise, manipulation always occurred while the base was stationary, and the arm did not move during base motion. Ten years since MoVAR's controller was conceived, controllers with the computational power required for such systems and real-time operating systems with sufficient levels of robustness are slowly emerging from the research domain, as exemplified by the Helpmate of Transitions Research Inc. Without AI capability, interface complexity increases with robot capabilityThe mobile base console had three screens, three non-overlapping input modalities, numerous functional modes and hierarchical command levels. A user could not comfortably manage this complexity without extensive training. The cost of the console also became prohibitive. No reduction in complexity was possible without delegating some capability to an intermediate controller. An artificial intelligence subproject begun in 1986 showed the feasibility of natural (typed) language input, coupled with an open world model and extensible motion and command repertoires. This work was also halted in 1988, but was seminal to subsequent advances in robot command interpreters based on natural language at the Stanford University Computer Science Department [15]. Task and motion preview capability avoids unneeded robot motionOne capability of the MoVAR console interface was the on-screen construction of a trajectory, with via points, through a static, graphic depiction of the robot-accessible environment. Head-motion cursor control and voice commands were used to draw the line and to label the locations. This capability allowed a certain amount of task programming by the user [14]. This type of capability was also explored by mounting a two-camera turret on the robot, with individual controls to aim each camera in a vertical stereo-pair configuration. Cross-hairs on the monitors for each camera let the user define a location of interest at the center of each monitor. The robot could then be commanded to go to that location (calculated by triangulation) and use local, proximity and touch-based sensors to manipulate the designated objects [1]. A mobile robot needs to be able to pick things off the floorEvery potential assistive robot user we interviewed mentioned the need to retrieve objects from the floor. A commercial mobile robot should therefore have this capability as a primary design specification. The MoVAR prototype was not initially designed with this specification. However, once the basic computational, manipulation and mobility systems were in place, the project completed a detailed design for a 2-axis MoVAR "torso" to increase vertical and forward reach: its specifications included the ability to lift the PUMA-260 from floor level to a height of 150 cm (~ 60") and extend it forward by 50 cm (~ 20"). This unit was not built due to the termination of the MoVAR project.
Desktop Vocational Assistant Robot: Phase A: 1989-1991; Phase B: 1992-1994.OverviewThe vocationally oriented DeVAR workstation concept grew from the perceived need to target task areas for which reimbursement of capital equipment would be possible. Assistive technology in the vocational domain would be an incentive for people with severe physical disabilities to return to the workforce and become independent of attendants for the job-related portion of the day. The level of robustness of earlier voice controlled robots was not sufficient for half or whole day assistance. The goal of Phase A was to establish this real-world functionality [22] and evaluate it in a desktop vocational environment [5]; the goal of Phase B was to use the robotics technology in a vocational training context [6, 27]. DeVAR used a PUMA-260 manipulator mounted upside-down on a 106 cm (~ 42") overhead track to keep the worksurface available for job-related objects and equipment (see Figure 3). The track allowed the small manipulator to have a large working volume, including side shelving, the work surface, and an approach to the user. No available industrial gripper was appropriate for office use in a scenario including people. The Otto-Bock prosthetic Greifer(TM), modified for servo-control, provided the proper mix of esthetics and function at a reasonable weight.
Figure 3: DeVAR, showing track-mounted upside-down PUMA-260 with Otto-Bock gripper, for manipulation of objects in a vocational desktop environment. In an office environment, it is important to combine communication with manipulation, telephone control, and environmental control. The DeVAR interface included a single command structure for these three types of tasks. The voice recognition and digitizing card (VOTAN VPC-2100) allowed calls to be answered automatically in speakerphone mode. The robot could be commanded to pick up the phone receiver if a private conversation was desired. A computer-interfaced environmental control unit (ECU) based on the X-10 standard allowed control of lights and small appliances by voice. The interface contained a history list recording feature so that all commands and system error reports were time stamped and written to a file [25]. These files allowed system debugging during development and usage recording in our evaluation studies. From a robotics perspective, Phases A and B of this project were similar. Phase B, The Vocational Training Facility (VTF), required several new tasks, such as the loading of laserdiscs. Otherwise, the base set of tasks was derived from those developed and used in Phase A, and spanned ADL and vocational user needs. Lessons LearnedTasks became "operational environments" for interdependent actionsThe earliest DeVAR tasks were completely automated and "linear". The only branching within tasks was in the case of detected errors or robot failure; the only user interaction was to stop and resume the task. As the workstation became more complex, a means was needed to avoid the explosion of task names and action-specific vocabulary to deal with choices and options. Several bottlenecks existed: (a) the voice recognition would become less robust as the number of commands increased; (b) the user would need to remember more words, which was difficult due to the intermittent use of the robot by most users; and (c) robot commands would become more like a robot programming language due to an increased need for syntactic rules to code the more complex command structures. The solution was to keep the simple one-word-per-task concept. Once in a task domain (like the "DISK" floppy diskette insertion program), the screen and voice would cue users when options existed, and would attempt to create as close to a direct-manipulation paradigm as possible. For example, in "DISK", the gripper would point to the top diskette in the holder while the screen informed the user to say "UP" and "DOWN" to move the gripper to the desired diskette. The user's directive "PROCEED" would initiate the subsequent automatic phase to take the diskette nearest the gripper and insert it in the drive. The workstation robot was viewed by users as an applianceWhile the ADL-robot was seen as a clinical assistant, the vocational DeVAR was used as an appliance. In the extended evaluation of the use of DeVAR in a computer-programmer's office [5, 21], it was found that robot tasks tended to be grouped in sets of two or three. The user would work for 30 to 60 minutes, then take a short break, for example to get DeVAR to take a page from the printer, to turn on his oscillating fan, and to get a throat lozenge, before he returned to his real work. This grouping meant that user attention to the robot was intermittent and secondary to his main job activity (computer programming). Users would forget commands and forget robot status with such unfocused use. The robot interface, in other words, needed to be designed accordingly, providing cues and hints, providing a short on-screen history of most recent commands, and showing robot status in a dedicated window. Do not turn robot users into robot programmersSince the surface design of the interface matched the users' perception of DeVAR as an appliance, the deeper structure of the interface also supported the "task set" concept. Tasks were discussed and designed off-line by the user, therapist and engineer, then implemented by the robot programmer. Due to the complexity of the task programming, tasks were not editable by users. Each task has two components: the design of the robot motions and the design of the information to be presented on the screen and spoken to the user through the speaker. This scenario of off-line program editing was the only logical choice given the state of the art in robot programming languages and the absence of touch and force sensors on the robot: generic actions such as "move forward until you touch a surface" were impossible. In other words, a teach pendant was required to position the gripper precisely at each location, with many locations being above and outside the sight and reach of a seated user. The result of making the task creation inaccessible to users meant that the R&D team accumulated a large, centralized repertoire of well-integrated and tested tasks. A more important result was the subsequent R&D work in the design of an iconographic user interface that allowed a user to design new tasks through "storyboarding" [10]. Work with the robot's capabilities, not against themThe most important quality of an assistive robot is its reliability and safety [24]. Knowing the limits of the robot's capabilities is an important aspect in task programming and workstation design. The following points illustrate some of the lessons we have learned in this arena: * Structure the environment as much as possible. We have found that people with severe disabilities naturally tend to structure their environments, partly as a way to make it easier to teach and interact with their attendants. This tendency has helped us in the design of workstations for robot use, since any increase in natural structure helps the robot in performing tasks more reliably. * Use break-away systems to reduce damage. DeVAR makes extensive use of velcro to position objects, small appliance and fixtures. Velcro, sometimes used in conjunction with extra constraints such as locator bars, pegs or holes, provides reasonable positioning accuracy in a workstation environment. This type of mechanical "fuse" is forgiving of programming errors or hardware failure. * Adjust robot speed depending on proximity to user. Although the PUMA-260 is easily capable of 100 cm/sec motions, DeVAR is never programmed at more than 20% of this limit. Close to the user, speed is limited to 1 cm/sec. The closer the robot is to the user, the shorter the reaction time available to stop motion with the panic switch, so the slower the programmed speed. Programming higher speeds for actions away from the user allows for reasonable task times with an acceptable level of safety. * Plan wrist geometries during trajectories to accommodate heavy objects. The PUMA-260 is capable of moving a 500 g (~ 1/2 lb) payload at full speed. However, with a gripper that extends 15 cm (~ 6") from the wrist, the effective payload, even at slow speed, is limited. Moving text books and containers of food requires careful attention to how the wrist is angled so that the motors for the shoulder and elbow are the primary actuators, and the wrist motors serve a stabilizing rather than lifting function. * Plan tasks so that motions are possible even if objects are in a wrong position. To illustrate this point, consider the program to close the door of a small refrigerator. The program works properly if the door starts in the (normal) open position. However, if the door was closed by someone manually or it had swung partially closed, it is important to make sure the program will still function, i.e., make sure the robot's trajectory to the door-approach position at no time intersects with any possible position of the door. With many tasks and objects in a small space, this is a difficult design constraint to follow.
Technology Transfer of DeVAR: 1990-1994.OverviewThe technology transfer of DeVAR began simultaneously on two fronts: a Request for Evaluation (RFE) proposal to the VA by the development team, and a Cooperative R&D Agreement (CRDA) between the RRDC and a small rehabilitation technology company, Tolfa, Inc. of Palo Alto, CA. The RFE resulted in a grant to the VA Technology Transfer Section (TTS) to buy and test DeVARs in clinics nationwide to assess the system as a potential VA-prescribable medical device. The CRDA with Tolfa resulted in final technology development and complete documentation of DeVAR, along with the transfer of intellectual property rights to the company in return for royalties. As part of the evaluation by the VA, it bought two DeVAR systems from Tolfa in 1991. The evaluations, completed in September, 1994 [17, 18, 26], concluded that DeVAR was not sufficiently robust and was too task-limited for the VA to consider it a medical, prescribable device. In 1991, Tolfa spawned a daughter company, Independence Works, Inc., of Palo Alto, CA, and transferred the DeVAR-related rights to it. Independence Works has a new CRDA with the RRDC for continued technology hardening of DeVAR to make it a more robust product. Lessons learnedTechnical documentation is a key to productizationDuring the development of DeVAR at the RRDC, documentation was a secondary concern to pursuing research objectives. However, the transfer to a company meant a halt to the natural flux and upgrading of components, subsystems and software. The documentation of the status of the electrical, mechanical and programming, as well as the creation of the training and technical manuals became a significant project in its own right. This is not a new lesson for corporate R&D, but it is a particularly difficult struggle for a laboratory team to transition from a 10-year R&D phase to a productization effort. The developer needs to stay in the loop during and after the technology transferThe transfer of technology is actually a transfer of an idea, a concept. Associated with this transfer there is often a prototype that embodies the concept. The team that turns the prototype into a product uses the prototype and documentation to understand the concept and the design decisions already made by the R&D team. However, with a complex product, this process has large pitfalls. Changes made by the product team to improve or simplify the design may in fact worsen it because the design rationale had not been adequately transferred along with the prototype. If the prototype developer is not part of the productization team or a consultant to it, there is a danger of losing years of expertise and painfully relearning lessons already confronted during the R&D phase. This lesson is often relearned in the corporate world, and therefore mandates repetition when it has been particularly expensive to the advance of the field. The product assessment protocol that the VA Technology Transfer Section adopted at least 10 years ago, and used in the DeVAR evaluation, explicitly forbids the developer from being included in the evaluation and productization process. While the rationale is commendable (i.e., the productizing company contracted by the VA has to develop the product on its own, based on the VA developer's documentation), the potential pitfalls outlined above increase with system complexity. The conclusions of the VA evaluation of DeVAR were perhaps inevitable based on this factor alone.
DiscussionThe definition of robotic system "Users"The basic assumption in the field of assistive robotics technology is that the robot operator - the person with a disability in our case - is the user. However, as our program has evolved, we have begun to realize that there are in fact many users [23, 25]. As we project the use of the technology beyond the development phase, the end-users will be more numerous: * Therapists will be the gatekeepers of the technology to be prescribed to end-users. The robotics technology will need to include tools, both hardware and software, for proper set-up, adjustment, customization. Without this interface layer, the gatekeepers will not consider the technology for their health care clients. * Physicians will be able to use robot-generated reports of usage to assess the effectiveness of a particular device in assisting a person in becoming functionally more independent for activities of daily living. * Hospital administrators will be indirect users of the technology because of the need for quantification of client outcomes. Since the robot will be able to report on its own actions and functions, questions of cost effectiveness and comparisons with alternate health care strategies can be based directly on the device's own usage data. Importance of clinical evaluation tools and computer-based data collectionAt the beginning of the VA/SU program, the driving force was the perception that then-available technology could be brought to bear on a recognized problem. This force was given direction by the interactions - through focus groups and informal meetings - between the staff (predominantly engineers) and people with high level quadriplegia contacted through Stanford and the VA. Clinical personnel were slowly introduced into the staffing, and by 1987 had become a dominant force in robot development decision-making. One of the principal program changes was the introduction of clinically-based evaluation methods and metrics. This facet is the topic of the companion paper by my colleague Joy Hammel, Ph.D., O.T.R. One robot-based evaluation tool introduced in DeVAR was a history list feature, similar to airplane flight recorders, time stamping all system actions and user commands. Based on the critical role of highly specialized, computer-controlled medical equipment in maintaining life, it could be argued that every such medical device should include a history list gathering function. Computer hardware and software considerationsThe VA/SU rehabilitation robotics program began as the first microprocessors were becoming a force in industry and home computing. Consequently, our robotics endeavor has benefited from the capabilities and endured the shortcomings of each processor generation since then. In addition, due to lower market demand, the development of real-time operating systems, necessary for robot control, has been much slower than those found typically on microprocessor-based systems (e.g., CPM, DOS, MacOS, UNIX). These factors have contributed to two different program approaches to development: (1) buy as much capability as possible in pre-packaged subsystems and then concentrate on high-level system-integration as the means to accomplish function-defined program goals; (2) concentrate on prototype development since there exists no set of pre-existing modules capable of providing the functionality that is desired as a final measure of program success. The first approach was applied in all phases except MoVAR, since no mobile robot design offered omnidirectionality we felt essential to a personal assistant, and no robot controller or operating system existed at the time capable of 10-degree-of-freedom coordinated control, combined with a multi-sensor data acquisition. Each robotics program needs to evaluate available technology and make the decisions on whether to buy or develop. The role of commercially available robot equipmentA problem that rehabilitation robotics has faced in its early years has been a low level of funding, due to the highly exploratory nature of the application domain within robotics and the demographics of the target user population. This situation has resulted in many proofs of concept but few clinically or commercially viable systems. The RTX(TM) robot, originally designed by UMI, Ltd. in the 1980s as an inexpensive human service robot (and currently manufactured by Oxford Intelligent Machines, Ltd.), continues to allow numerous research groups around the world to explore issues in rehabilitation applications. In this same timeframe, industrial robots such as the PUMA, starting at $50,0000, cost five times the price of an RTX robot. The difference in cost reflects both performance and safety provisions. The technology still needs to become safer and cheaper to bring robotics into the mainstream as a "home appliance" class. New uses within rehabilitation, sensor and controller advances in robotics and mechatronics, and additional impetus from related areas such as home automation will cause this new class to evolve and become affordable.
|