The Nursing Robot

Johann Borenstein's D.Sc. Thesis "Development of a Nursing Robot System" included the development of a mobile robot system (the Nursing Robot) to help physically handicapped people. Completed in 1986, the Nursing Robot was one of the first fully functioning mobile robots equipped with a manipulator arm. Also integrated were seven different sensor systems. The system was controlled by four networked onboard Sinclair Spectrum Computers (based on the then popular Z80 processor) and an off-board IBM-PC (8086 processor).


Besides the introduction above, most parts of this document were adapted from Paper #05, which was written in Summer 1986. Some of the veteran roboticists among the readers of these lines may get a chuckle out of the technological features of the robot.


Abstract

This document describes the features of the mobile Nursing Robot System developed at the Technion. The Nursing Robot System comprises three major components: a self-propelled vehicle, a robotic arm mounted on it, and a communications post (workstation) next to the disabled person's bed. Onboard the mobile robot low-cost microcomputers are interconnected as a hierarchical network, in order to control a variety of activities: Sensor data processing, motion control, path-planning, communication, and others. The vehicle can move autonomously in a room with unexpected obstacles.

FORTH has been used as the programming language, because of its compactness, speed, and extendibility. The paper discusses the hierarchical structure of the system with special attendance to the hierarchical software of the motion module.


1. INTRODUCTION

Work now in progress at the Technion's Department of Mechanical Engineering aims at the development of an autonomous mobile robot system, capable of performing various tasks for the physically disabled. Such a device, is hoped, will return a measure of independence to many bedridden persons, as well as reducing the number of those in need of hospitalization and constant attendance.

The robot can perform simple services, such as fetching a glass of water, operating electrical appliances or replacing a cassette in a video-recorder. The system contains a vehicle, a five degrees-of-freedom (DOF) robotic arm mounted on the vehicle, and a computerized post next to the disabled person's bed.

In order to interact intelligently with its environment, the robot utilizes the following sensors:

  1. Two ultrasonic range-finders mounted on the vehicle to detect obstacles and provide information to detour the obstacle.
  2. Micro switches attached to the vehicle bumpers to detect collisions with low obstacles (that were not detected by the range-finder sensor).
  3. Incremental encoders attached to the wheels to monitor the relative position of the vehicle.
  4. Three light sources attached to the walls and a rotating light detecting sensor on the vehicle to update the absolute position of the vehicle in the room.
  5. Force sensor, integrated into the robots gripper, to ensure proper handling of delicate objects.
  6. A video camera attached to the arm to permit the detection of target objects {not fully functional at the end of the project in 1986}.
  7. A speech recognition unit to translate verbal instructions into computer language {not fully functional at the end of the project in 1986}.

A prototype of the nursing robot vehicle is shown in Fig.1. It comprises two main components: The mobile platform which houses the computers and the electronic hardware, and a commercially available manipulator, to which the two ultrasonic transceivers and the light detecting sensor are attached. Fig. 1 also shows the specially devised multipurpose gripper with its integrated 3 DOF-force sensor, as well as the floor level bumper with the Micro switches.

This document outlines the hierarchical structure of the computer system and describes a case study at the end. The choice of micro-computers is explained and the advantages of FORTH as a programming and development language will be discussed.


2. THE HIERARCHICAL COMPUTER STRUCTURE

Figure 2 {note: Fig. 2 not included in this document} shows the hierarchical computer structure of the system which consists of three distinct levels of computation. The lowest level comprises three microcomputer controllers that directly interact with electronic hardware:

  1. The sensor controller, activates the ultrasonic transceivers, operates their drivers, and performs range calculations before passing the relevant information to the next higher level or to the motion controller. The light source detector and the force sensor, are read (at approximately 1 kHz) through a multiplexed ADC, which is also connected to the sensor controller.
  2. The motion controller controls the vehicle and performs the motion strategy, which has been explained in a previous paper [1]. This computer also controls the robot-arm in continuous-path mode by repetitively calculating intermediate positions and velocities for the first three arm joints and relating this data to the robots control loops.
  3. The vision controller is solely concerned with the operation of the camera and preprocessing of the picture, in order to reduce the amount of data which have to be passed on to the next higher level.

All three controllers are interfaced with each other as well as with the medium level with the help of a NETWORK, which is a standard feature in the microcomputers used in this application (Z80A-based SINCLAIR SPECTRUM {note in 1995: These little gems cost $350, including 64 Kbyte RAM, rubber-keyboard, composite video driver, network adapter, and hybrid endless tape drive with 85 Kbyte capacity and 5 sec. average seek time}. The NETWORK is especially attractive during the development phase of the system, since it is readily expandable to 64 computers without any additions of either hardware or software. Therefore, more features may be added to the system even in an advanced state of the development.

The scheduler computer is at the medium hierarchical level. It receives commands from the highest level and relates these commands, via the NETWORK, to the respective controllers (or vice versa). Presently, data are transferred between the scheduler (onboard the robot) and the high level computer (fixed within the bedside post) by means of a RS232 cable. A wireless data link, such as radio or infrared, could be employed, for a commercial system.

At the highest level of the system (this computer is an off-board IBM PC 8086), artificial intelligence algorithms break down spoken commands into adequate series of actions. Relevant sensory information is processed here, global-path planning (for the platform as well as for the robotic arm) is performed while concurrently monitoring the voice recognition input.


3. CONSIDERATIONS FOR THE CHOICE OF MICROCOMPUTERS

Except for the highest level computer, all computers in this application are SINCLAIR SPECTRUM microcomputers. This unconventional choice has some distinct advantages over others in view of the following special circumstances:

  1. The intention in this project is to develop an experimental
  2. prototype. Therefore, readily available off-the-shelf hardware items are preferable to cost- and time intensive own developments.
  3. The use of independent stand alone computers facilitated team work in the development stage, since it permitted several undergraduate student projects to proceed simultaneously, without interfering with each other.

After establishing the advantages of the use of commercially available microcomputers for this project, another important consideration was the weight and size of the computer, several of which were to be installed onboard the mobile robot.

SINCLAIR SPECTRUM microcomputers were found to meet the above requirements as well as to offer some additional desirable features, which are listed below:

1. The computer is small (240mm x 150mm x 30mm) and weighs less than most other microcomputers (570gr). Therefore, the four required computers can easily be installed (even with their own keyboard and housing) onboard the vehicle {note: the camera-computer was not installed at the end of the project in 1986}.

2. With a computer installed and connected to all its peripheral devices, it is still possible to:

a. program and operate the computer with its keyboard,

b. load and save programs with its attached microdrive, and

c. view programs or results on an attached monitor.

These facilities largely simplify the development and especially the debugging of programs allowing for a totally interactive process at any time - even when the robot is "on route". The interactive character is further enhanced by the use of FORTH, as will be explained later.

3. After FORTH has been loaded into the computer, there are still 30K of RAM available to the user. In view of the extreme compactness of compiled FORTH, this has been found sufficient for our application. Also, the operating system is resident in ROM and available at any time.


4. USING FORTH AS A PROGRAMMING AND DEVELOPMENT LANGUAGE

The programming language for all three levels is FORTH, a relatively new, procedure based language [2] of increasing popularity [3,4], which lends itself to this application for several reasons:

  1. Because of its high operating speed [5], FORTH is well suited for the various real-time, control and sensor monitoring applications [6,7].
  2. Because of its extreme compactness, FORTH programs fit easily into limited memory space as in the low level computers here.
  3. The structural design of FORTH naturally enhances the structural design of the whole nursing robot system.
  4. The interactive facility of FORTH allows for easy debugging of already compiled procedures.
  5. During development of the system, the high transportability of the language allows for easy relocation of various routines among the different computers.
  6. Because of its natural extendibility, FORTH serves as a convenient base for development of the very high level language and the artificial intelligence algorithms.


5. CASE STUDY

One part of the motion module has been depicted in Fig.3 in order to demonstrate the interleaving hierarchical software and hardware structure.

At the lowest hierarchical level, the hardware level, electronic devices such as Digital to Analog Converters (DACs), counters etc. are interfaced with the motion controller, mainly through input/output ports of the computer. At the lowest software level, procedures interact with the respective ports by sending or receiving data. These "driver" procedures are normally designed in such a way that replacing a certain electronic device ( e.g., replacing the DACs and power amplifiers with a Pulse Width Modulator, to drive the motors) would only require a change in the driver procedure in question, without having any effect on the higher level procedures.

Data to be input or output by the software drivers is calculated at the next level (e.g., the block marked CONTROLLER in Fig. 3 {Note: Fig. 3 not included in this document}. This is a digital cross-coupled control algorithm, which has been thoroughly analyzed in a previous paper [8]). The block marked SEQUENCER controls the four motion phases: a) acceleration, b) constant velocity, c) deceleration and d) overshoot correction, which are employed for either rotational or translational motion of the vehicle. Also, the SEQUENCER will abort a motion sequence upon receiving an alarm from the sonar sensors (indicating detection of an obstacle). A detailed description of the obstacle avoidance algorithm is given in Paper 03.

At the next level, motion primitives such as FORWARD or RIGHT allow the operator to drive the vehicle on a straight line or to rotate the vehicle on the spot. Alternatively, the high-level directive MOVE will calculate the required amount of rotation and translation to reach a certain location in the room and call the respective motion primitives to perform that motion.

The block above, designated SCHEDULER, is implemented in the scheduler computer. Its task is to switch on the ultrasonic scanner (implemented in the sensor controller), then to pass on the required task coordinates to the block MOVE, switch off the ultrasonic scanner upon completion of the motion and to pass on a status report to the highest level computer. If invoked directly by the operator at this level, SCHEDULER will move the vehicle to the desired task location, but will stop if an obstacle was detected.

The PATH-PLANNER is implemented in the highest level computer and is in fact an elaborate artificial intelligence program [9] designed to find an optimal path between the present location of the robot and a desired task location, in a room filled with known obstacles. The PATH-PLANNER outputs a list of intermediate coordinates to the SCHEDULER, and then awaits the status report. If an unknown obstacle was detected, the PATH-PLANNER initiates an ultrasonic scan of the obstacle, and adds the resulting new obstacle data to its internal world model. Subsequently, the PATH-PLANNER recalculates an optimal route, until the desired location is reached.

The very highest level of the system comprises the TASK-SEQUENCER. This is an artificial intelligence program which decomposes a natural language command into an appropriate series of actions, including motions of the vehicle and motions of the robot-arm. This level is called the Task level, since the operator only specifies a task (e.g., "Bring glass from table"), without specifying the required steps to perform this task. The actual steps might be different for the same command, since they depend on the room obstacles and the location of the vehicle at the time the command is given.

On its way the Nursing robot can detect obstacles with its two front-and-downward-facing sonars. Upon detection, the robot stops and scans the obstacle horizontally, by means of its Rhino manipulator arm onto which the sonars were mounted. The algorithm detects edges of the obstacles and updates the internal world model with the information. An optimization algorithm then recomputes an optimal path around the obstacle and toward its next intermediate target.

The Nursing robot is capable of visiting a list of predefined target coordinates. An advanced version of the Traveling Salesman Algorithm (see Paper 08) computes not only an optimal tour among its targets, but it does also take into account the robot's need to return to its home position after 20 or so meters of travel to do an absolute position update. Dead-reckoning accuracy is modeled as a resource the robot runs out of over time (or distance). The optimizer also takes into account the fact that certain locations must be visited immediately prior to other locations, for example if the robot needs to fetch a book and bring it to another location while holding the book in its gripper, then visiting other (potentially closer locations) would not make much sense, until the book was delivered and released at the book's target location. The algorithm developed for this task ran on the IBM PC and was also programmed in FORTH.


CONCLUSIONS

A hierarchical multiprocessor and multisensor robotic system of considerable complexity has been designed, built and tested. In order to implement this system, a highly structured and modular software and hardware design has been used. The unconventional choice of microcomputers together with the interactive facility of FORTH have been found to be of utmost value for development and debugging of the system.

{This section added in 1995:} To give the reader a sense of the typical challenges that faced the robotics experimentalist in 1985/86, here are a few anecdotes:

  1. In the absence of fast arithmetic coprocessors, the author developed a unique algorithm for computing trigonometric functions in FORTH. The algorithm was 10 times faster then what was known then, and warranted a Journal Paper (Paper 07).
  2. A student spent two semesters on writing a Z-80 machine language routine to compute square roots.
  3. The author designed and built a 6-axis pulse width modulation (PWM) speed controller for the (normally ON/OFF controlled) Rhino arm.
  4. The author wrote a FORTH algorithm to perform Continuous Path motion with the (now speed-controllable) Rhino arm.


REFERENCES

1) Borenstein, J. and Koren, Y.: A Mobile Platform For Nursing Robots". IEEE Transactions on Industrial Electronics, May 1985, pp.158-165.

2) Brodie, L.: "Starting FORTH". Prentice Hall, Inc., Englewood Cliffs, 1981.

3) The Journal of FORTH Applications and Research, Vol. 1, Issue 1, September 1983.

4) Michaloski, J. L. and Warsaw, B. A.: "A Robot Control System Based on FORTH". Robotics Engineering, May 1986, pp. 22-26.

5) Borenstein, J.: "Fast Fixed Point Trig by Derivation". FORTH DIMENSIONS, May/June 1986, pp. 14-19.

6) Yoerger, D. R., Peterson, P. and Buharali, A. :"Control System Implementation Using FORTH". ASME 83-WA/DSC-28.

7) Lecky, J.E.: "FORTH For Computer Vision in Industrial Applications". Robotics AGE, 1985, pp. 25-28.

8) Borenstein, J. and Koren, Y.: "Motion Control Analysis of A Mobile Robot". Submitted for publication in: ASME Journal of Dynamics, Measurement and Control.

9) Borenstein, J. and Koren, Y.: "Optimal Path Algorithms For Autonomous Vehicles". Paper presented at the 18th CIRP Manufacturing Systems Seminar, June 5-6, 1986, Stuttgart.


This file last updated on 07/04/96 by Johann Borenstein.
Email: johannb@umich.edu