A Framework for Distributed Sensing and Control

1. lntroduction

Both the availability and need for sensor systems is growing, as is their complexity in terms of the number and kind of sensors within a system. But most robotic sensor­ based systems to date have been designed around a single sensor or a small number of sensors, and ad hoc techniques have been used to integrate them into the complete system and for operating on their data. in the future, however, such systems must oparate in a reconfigurable multi-sensor environment; for example, there may be several cameras (perhaps of different types), active range finding systems, tactile pads, and so on. in addition, a wide variety of such sensing devices, including mechanical, electronic, and chemical, are available for use in sensor systems, and a sensor system may include several kinds of sensing devices. Thus, at least three issues regarding the configuration of sensor systems arise:

1. How to develop a coherent and efficient treatment of the information provided by many sensors, particularly when the sensors are of different kinds.
2. How to allow for sensor system reconfiguration, both as a means of providing greater tolerance for sensing device failure, to permit dynamic allocation of sensing resources, and to facilitate future incorporation of additional sensing devices.

1 This work was supported in part by the System Development Foundation and NSF Grants ECS- 8307483 and MCS- 82-21750. Chuck Hansen is an ARO Fellow.

A Framework for Distributed Sensing and Control 1

Tom Henderson, Chuck Hansen, and Bir Bhanu

Department of Computer Science The University of Utah Salt Lake City, Utah 84112

3. How to control the sensors.

We have previously proposed the Multi-sensor Kerne! System [5, 7) and Logical Sensor Specification [4] as solutions for the first two problems, respectively. The rest of this paper gives our method for answering the third.

The purpose of the logical sensor specification is to permit an implementation independent description of the required data and the nature (type) of that data. in addition, alternative ways of producing the same output can be defined. This makes it possible to recover if some sensor fails. One can also choose an alternative based on higher Ievei considerations (e.g., speed, resolution, etc.). Thus, a use for logical sensors is evident in any sensor system which is composed of several sensors, where sensor reconfiguration is desired, and/ or where the sensors must be actively controlled.

As described in more detail elsewhere [4]. the principal motivations for logical sensor specification are: the emergence of significant multi-sensor systems, the benefits of data abstraction, and the availability of smart sensors (thus, the Substitution of hardware for software, and vice versa, should be transparent above the implementation Ievel; see also Organick et. al [10]).

Logical sensors are then a means by which to insulate the user from the peculiarities of input devices. Thus, for example, a sensor system could be designed to deal with camera input, without regard to the kind of camera being used. in addition, logical sensor specification is also a means to create and package "virtual " physical sensors. For example, the kind of data produced by a physical Iaser range tinder sensor could also be produced by two cameras and a stereo program. This similarity of output result is more important to the user than the fact that the information may be obtained by using one physical device, or by using two physical devices and a program. Logical sensor specification allows the user to ignore such differences of how output is produced, and treat equivalent means of obtaining data as logically the same.

Related work has been done in several areas. The need for some device-independent interactive system has resulted in the Graphical Kerne! System (GKS) which is now a Draft International Standard. The main idea behind GKS is to provide "a means whereby interactive graphics applications could be insulated from the peculiarities of the input devices of particular terminals, and thereby become portable" [11]. Some encouraging results reported in the robotics Iiterature including a systematic study of robotic sensor design for dynamic sensing undertaken by Beni et al. [3). Another related research effort is the programming environment (called the Graphical Image Processing Language) under development as part of the IPON project (an advanced architecture for image processing) at the University of Pennsylvania [2]. The hierarchical robot control system described by Albus [1) is a precursor to the logical sensor scheme proposed here.

2. Logical Sensor Specification

Figure 1 shows the basic components of a logical sensor.

The logical sensor name uniquely identifies the logical sensor. The characteristic output vector is a vector of types which serves as a description of the output vectors that will be produced by the logical sensor. Thus, the output of a logical sensor is a set (or stream) of vectors, each of which is of the type declared by that logical sensor's characteristic output vector. Programs 1 to n represent alternative ways in which to obtain data with the same characteristic output vector. Hence, each alternate subnet is equivalent, with regard to type, to all other alternate subnets in the Iist. Eac_h alternate subnet in the Iist is itself composed of: (1) a set of input sources. Each element of the set must be a logical sensor (or the set may be empty). Allowing null input permits a physical sensor, which has only an associated program (the device driver), to be described as a logical sensor, thereby permitting uniformity of sensor treatment. (2) a computation unit over the input sources. Currently such computation units are software programs, but in the future, hardware units may al so be used. Finally, the role of the selector (whose inputs are alternate subnets and an acceptance test name) is to detect failure of an alternate and switch to a different alternate. lf switching cannot be done, the selector reports failure of the logical sensor.

ln order to solve most recognition and manipulation problems, however, it is necessary to be able to reposition sensors (e.g., aim cameras) and adapt rapid ly to changing conditions (e.g., if an object is slipping from the grasp of a robot hand, perhaps more force should be applied). Thus, in addition to a stream of sensed data flowing from physical sensors on up through some hierarchy of logical sensors, there may also be a stream of control commands (or signals) flowing in the reverse direction.

Each logical sensor has a control command interpreter to interpret the control commands coming from a Ievei up in the hierarchy and to send commands down to logical sensors lower in the hierarchy. Moreover, the select function now plays a more sophisticated role in the logical sensor. Namely, the select function monitors both the sensor data going up and the command stream to be issued. Given the command (or commands) to be executed and the sensor data being produced locally, the select function is able to short circuit the path back to the root logical sensor and to modify the commands to be issued. Such a function may be viewed as a micro-expert system which knows all about the interface represented by the logical sensor in which it is located. Thus, a log ical sensor acquires some of its meaning now not simply as a sensor/ algorithm combination, but also as an interface between two layers of sensing and analysis.

Another requirement on the logical sensor is that it now also acts as a "logical controller." lf the control command received at a particular sensor requires that control commands be sent to the source input logical sensors, then those commands will depend on which alternate subnet is currently selected by the selector function. For example, suppose range data can be obtained from a stereo camera system, a Iaser range tinder system or a robot hand with tactile sensing. Then to obtain range data from a given region in space requires aiming and focusing two cameras, or a1mmg a camera and a Iaser, or positioning a robot arm. The high Ievei command to scan a region must then be broken down into the appropriate lower Ievei commands.

A logical sensor can be viewed as a network composed of sub-networks which are themselves logical sensors. Communication within a network is controlled via the flow of data from one sub-network to another. Hence, such networks are data flow networks.

Once the logical sensors are specified, they are stored as s- expressions. in order to actually obtain an executable system from the logical sensor specification, it is necessary to translate the database expressions into some executable form, e.g., to produce source code for some target language, and then either interpret or compile and run that source. We currently have two implementations of the logical sensor specification language running: a C version (called C-LSS) running under UNIX, and a functiona l language version (called FUN- LSS) which produces FEL code (Function Equation Language) [9]. These have been described elsewhere [4]. C-LSS produces a UNIX shell script from the specification.

3. An Example

We are currently applying the methodology to some interesting and hard problems. in particular, we are developing and testing a specification for the UTAH/MIT Dextrous Hand. This gives us the opportunity to try out the method on a distributed multi-processor system, as the Hand is controlled by six M68000s.

Shown in Figure 2 are some of the logical sensors which comprise the specification of a sensor and control scheme for the UTAH/ MIT dextrous robot hand. The robot hand has four fingers each with four degrees of freedom [8]. The high Ievel commands for hand control are interpreted as a set of commands to a lower-level right on down to the control of the joint positions of each finger which define the configuration of the robot hand.

A grasping action requires several hand operations, including the attainment of an approach configuration. One of these is the "curl" position (the control command to the hand logical sensor). Ta curl the hand requires that each finger move away from the median axis of the hand (the control command "abduct" to each of the finger logical sensors). Finally, the abduct command requires that each joint achieve a specific angle (the 9ii control commands to the joint logical sensors). Thus, the feedback loop for position control can be located in the programs which are part of the joint logical sensor specification. Moreover, concise local knowledge for what to do in case of error condit ions (slipping, too much force, etc.) can be embedded in the appropriate select function .

4. Conclusions

We have presented a framework for the specification of sensing and control systems. Moreover, the methodology lends itself nicely to distributed processing. The method permits the specification of fault tolerance (both software and hardware) and dynamic reconfiguration of the sensing system. The incorporation of control now permits closed loop Operation and adaptation to changing conditions.

Our specific accomplishments include:

1. The development of a methodology for the specification of distributed sensing and control. in particular, one based on a reasonably weil understood underlying computational model, i.e., dataflow.
2. The development of an oparat ional environment for computing with respect to the methodology.

The successful implementation of such a methodology provides a very significant and fundamental tool for the specification of distributed sensing and control systems. Moreover, we believe that our approach permits an effective conceptual decomposition of the problern into manageable units. For a more complete treatment of logical sensors as a framework for distributed sensing and control (with detailed examples), see Henderson et. al [6].