System and process for controlling electronic components in a ubiquitous computing environment using multimodal integration

Abstract

The present invention is directed toward a system and process that controls a group of networked electronic components using a multimodal integration scheme in which inputs from a speech recognition subsystem, gesture recognition subsystem employing a wireless pointing device and pointing analysis subsystem also employing the pointing device, are combined to determine what component a user wants to control and what control action is desired. In this multimodal integration scheme, the desired action concerning an electronic component is decomposed into a command and a referent pair. The referent can be identified using the pointing device to identify the component by pointing at the component or an object associated with it, by using speech recognition, or both. The command may be specified by pressing a button on the pointing device, by a gesture performed with the pointing device, by a speech recognition event, or by any combination of these inputs.

Claims

Wherefore, what is claimed is:

1. A multimodal electronic component control system comprising:

an object selection subsystem;

a gesture recognition subsystem;

a speech control subsystem; and

an integration subsystem into which the obiect selection, gesture recognition and speech control subsystems provide inputs, said integration subsystem integrating said inputs to arrive at a unified interpretation of what component a user wants to control and what control action is desired, and wherein the integration subsystem comprises,

a dynamic Bayes network which determines from the individual inputs of the obiect selection, gesture recognition, and speech control subsystems, the identity of a component the user wants to control (i.e., the referent), a command that the user wishes to implement (i.e., the command), and the appropriate control action to be taken to affect the identified referent in view of the command, said dynamic Bayes network comprising input, referent, command and action nodes, wherein the input nodes include said individual inputs which provide information as to their state to at least one of a referent, command, or action node, said inputs determining the state of the referent and command nodes, and wherein the states of the referent and command nodes are fed into an action node whose state indicates the action that is to be implemented to affect the referent, and wherein said referent, command and action node states comprise probability distributions indicating the probability that each possible referent, command and action is the respective referent, command and action.

2. The system of claim 1, wherein the object selection subsystem is pointer based in that an electronic component is selected by a user pointing a pointing device at an object that corresponds to, or is associated with, the electronic component, and wherein the input nodes providing information to the referent node comprise a pointing target node which indicates to the referent node what electronic component is associated with the object that the user is currently pointing at.

3. The system of claim 1, wherein the speech control subsystem identifies an electronic component corresponding to a prescribed component name spoken by a user, and wherein the input nodes providing information to the referent node comprise a speech referent node which indicates to the referent node what electronic component the user currently identified by speaking the prescribed name for that component.

4. The system of claim 1, wherein the state of all nodes of the dynamic Bayes network are updated on a prescribed periodic basis to incorporate new information, and wherein the input nodes providing information to the referent node comprise a prior state node whose state reflects the referent node's state in the update period immediately preceding a current period, and wherein the input from the prior state node is weighted such that its influence on the state of the referent node decreases in proportion to the amount of time that has past since the prior state node first acquired the state being input.

5. The system of claim 1, wherein the object selection subsystem is pointer based in that an electronic component is selected by a user pointing a pointing device at an object that corresponds to, or is associated with, the electronic component, and wherein the input nodes providing information to the command node comprise a button click node which indicates to the command node that a user-operated switch resident on the pointer of the object selection subsystem has been activated.

6. The system of claim 1, wherein the gesture recognition subsystem identifies a command indicative of a desired action for affecting an electronic component which corresponds to a prescribed gesture performed by the user with a pointing device, and wherein the input nodes providing information to the command node comprise a gesture node which indicates to the command mode what electronic component the user currently identified by performing the gesture associated with that that component.

7. The system of claim 1, wherein the speech control subsystem identifies a command indicative of a desired action for affecting an electronic component corresponding to a prescribed command word or phrase spoken by a user, and wherein the input nodes providing information to the command node comprise a speech command node which indicates to the command node what command the user currently identified by speaking the prescribed word or phrase for that command.

8. The system of claim 1, wherein the state of all nodes of the dynamic Bayes network are updated on a prescribed periodic basis to incorporate new information, and wherein the input nodes providing information to the command node comprise a prior state node whose state reflects the command node's state in the update period immediately preceding a current period, and wherein the input from the prior state node is weighted such that its influence on the state of the command node decreases in proportion to the amount of time that has past since the prior state node first acquired the state being input.

9. The system of claim 1, wherein input nodes providing information to the action node comprise one or more device state nodes whose state is set to reflect the current condition of an electronic component associated with the node, and wherein each device state node provides information as to the current state of the associated component to the action node whenever the referent node probability distribution indicates the referent is the component associated with the device state node.

10. A computer-implemented multimodal electronic component control process comprising:

a pointer-based obiect selection process module;

a gesture recognition process module;

a speech control process module; and

a dynamic Bayes network into which the obiect selection, gesture recognition and speech control process modules provide inputs, said dynamic Bayes network integrating the inputs to arrive at a unified interpretation of what component a user wants to control and what control action is desired by determining from the individual inputs of the obiect selection, gesture recognition and speech control process modules, the identity of a component the user wants to control (i.e., the referent), a command that the user wishes to implement (i.e., the command), and the appropriate control action to be taken to affect the identified referent in view of the command, wherein the dynamic Bayes network has a process flow architecture comprising a series of input nodes including said individual inputs which provide information as to their state to at least one of a referent node, a command node and an action node, said inputs determining the state of the referent and command nodes, and wherein the state of the referent and command node is fed into an action node whose state is determined by the input from the referent, command and input nodes, and whose state indicates the action that is to be implemented to affect the referent, and wherein said referent, command and action node states comprise probability distributions indicating the probability that each possible referent, command and action is the respective referent, command and action.

11. The process of claim 10, wherein the state of all nodes of the Bayes network are updated on a prescribed periodic basis to incorporate new information, and wherein said input nodes further comprise nodes whose state reflects the same node's state in the update period immediately preceding a current period, wherein the prior node state is input into the same node in the current period thereby allowing the prior states of the nodes to influence the node states in the current period so to preserve prior incomplete or ambiguous inputs until enough information is available to the network to determine the state of an undecided node.

12. The process of claim 11, wherein the input from an input node associated with a prior node state is weighted such that its influence on the state of the corresponding node in the current period decreases in proportion to the amount of time that has past since the node first acquired the state being input.

13. The process of claim 10, wherein said input nodes further comprise one or more device state nodes whose state is set to reflect the current condition of an electronic component associated with the node, and wherein each device state node provides information as to the current state of the associated component to the action node whenever the referent node probability distribution indicates the referent is the component associated with the device state node.

14. The process of claim 13, wherein the device state nodes are set to indicate whether the associated component is activated or deactivated.

15. The process of claim 14, wherein only two action node states are possible for a particular electronic component in that when the component is activated the only action is to deactivate it, and when the component is deactivated the only action is to activate it, and wherein whenever a device state node provides information as to the current state of the associated component as to whether the component is activated or deactivated to the action node, the action node is set to a state indicating the component is to be activated if it is currently deactivated or a state indicating the component is to be deactivated if it is currently activated, regardless of the state of the command node.

16. A computer-implemented process for controlling a user-selected electronic component within an environment using a pointing device, comprising using a computer to perform the following process actions:

computing a similarity between an input sequence of sensor values output by the pointing device and recorded over a prescribed period of time and at least one stored prototype sequence, wherein each prototype sequence represents the sequence of said sensor values that are generated if the user performs a unique gesture representing a different control action for the selected electronic component using the pointing device;

determining if the computed similarity between the input sequence and any prototype sequence exceeds a prescribed similarity threshold; and

whenever it is determined that one of the computed similarities exceeds the similarity threshold, implementing a command represented by the gesture.

17. The process of claim 16, wherein the prescribed period of time in which the sensor values output by the pointing device are recorded is long enough to ensure that characteristics evidenced by the sensor values which distinguish each gesture from any other gesture representing a different control action are captured in the input sequence.

18. The process of claim 17, wherein the prescribed period of time in which the sensor values output by the pointing device are recorded is within a range of approximately 1 second to approximately 2 seconds.

19. The process of claim 16, the process action of computing the similarity between the sequence of sensor values output by the pointing device and recorded over the prescribed period of time and a prototype sequence, comprises an action of computing the similarity using a squared Euclidean distance technique.

20. The process of claim 16, wherein the prescribed similarity threshold is large enough to ensure that characteristics in a prototype sequence as the evidenced by the sensor values thereof that distinguish the gesture associated with the prototype sequence from any other gesture represented by a different prototype sequence, exist in the input sequence, thereby causing the similarity computed between the input sequence and the prototype sequence to exceed the threshold, and causing the similarity computed between the input sequence and any other prototype sequence associated with a different gesture to not exceed the threshold.

21. The process of claim 16, wherein the process is performed continuously for each consecutive portion of the inputted sequence of sensor values output by the pointing device having the prescribed period of time for as long as the electronic component remains selected.

22. The process of claim 16, wherein each gesture is a series of movements of the pointing device in arbitrary directions, and wherein the sensor output or outputs recorded are those that are sure to characterize the motion of the pointing device associated with the gesture.

23. The process of claim 22, wherein the pointing device sensors comprise a magnetometer which has outputs that characterize the movement of the pointer in pitch, roll and yaw, and are used exclusively as the sensor outputs that are recorded.

24. The process of claim 22, wherein the pointing device sensors comprise an accelerometer which has outputs that characterize the movement of the pointer in pitch and roll only, and a gyroscope which has outputs that characterize the movement of the pointer in yaw only, and the combination of the outputs from these two sensors are used as the sensor outputs that are recorded.

25. The process of claim 24, wherein the pointing device sensors comprise a magnetometer which has outputs that characterize the movement of the pointer in pitch, roll and yaw, and wherein the outputs of the magnetometer are used in conjunction with the outputs of the accelerometer and gyroscope as the sensor outputs that are recorded.

26. A system for controlling a user-selected electronic component within an environment using a pointing device, comprising:

a general purpose computing device;

a computer program comprising program modules executable by the computing device, wherein the computing device is directed by the program modules of the computer program to,

input orientation messages transmitted by the pointing device, said orientation messages comprising orientation sensor readings generated by orientation sensors of the pointing device,

generate and store at least one prototype sequence in a training phase, each prototype sequence comprising prescribed one or ones of the orientation readings that are generated by the pointing device during the time a user moves the pointing device in a gesture representing a particular command for controlling the selected electronic component, wherein each prototype sequence is associated with a different gesture and a different command,

record said prescribed one or ones of the orientation sensor readings from each orientation message inputted for a prescribed period of time to create an input sequence of sensor readings,

for each stored prototype sequence, compute a similarity indicator between the input sequence and each prototype sequence under consideration, wherein the similarity indicator is a measure the similarity between sequences,

identify the largest of the computed similarity indicators,

determine if identified largest computed similarity indicator exceeds a prescribed similarity threshold,

whenever the identified similarity indicator exceeds the prescribed similarity threshold, designate that the user has performed the gesture corresponding to the prototype sequence associated with that similarity indicator, and

implement the command represented by the gesture that the user was designated to have performed.

27. The system of claim 26, wherein the program module for generating and storing at least one prototype sequence in a training phase, comprises, for each prototype sequence generated, the sub-modules for:

(a) inputting a user-specified identity of the electronic component that the gesture associated with the prototype sequence applies to;

(b) inputting a user-specified control action that is to be taken in regard to the identified electronic component in response to the user performing the gesture;

(c) causing periodic requests for orientation messages to be sent to the pointing device;

(d) waiting for an orientation message to be received;

(e) whenever an orientation message is received, determining whether the switch state indicates that the pointing device's switch has been activated by the user to indicate that the gesture is being performed;

(f) whenever it is determined that the switch state does not indicate that the pointing devices switch is activated, repeat actions (d) and (e);

(g) whenever it is determined that the switch state does indicate that the pointing devices switch is activated, record a prescribed one or ones of the pointing device sensor outputs taken from the last received orientation message;

(h) waiting for the next orientation message to be received;

(i) whenever an orientation message is received, determining whether the switch state indicates that the pointing devices switch is still activated, and if so repeating actions (g) and (h);

(j) whenever it is determined that the switch state no longer indicates that the pointing device's switch is activated thereby indicating that the user has completed performing the gesture, designating the recorded sensor outputs in the order recorded as the prototype sequence; and

(k) storing the prototype sequence.

28. A computer-implemented process for controlling a user-selected electronic component within an environment using a pointing device, comprising using a computer to perform the following process actions:

inputting orientation messages transmitted by the pointing device, said orientation messages comprising orientation sensor readings generated by orientation sensors of the pointing device;

recording a prescribed one or ones of the pointing device sensor outputs taken from an orientation message inputted whenever a user indicates performing a gesture representing a control action for the selected electronic component;

for each gesture threshold definition assigned to the selected electronic component, determining whether the threshold if just one, or all the thresholds if more than one, of the gesture threshold definition under consideration are exceeded by the recorded sensor output associated with the same sensor output as the threshold;

whenever it is determined that the threshold if just one, or all the thresholds if more than one, of one of the gesture threshold definitions are exceeded by the recorded sensor output associated with the same sensor output, designating that the user has performed the gesture associated with that gesture threshold definition; and

implementing the command represented by the gesture that the user was designated to have performed.

29. The process of claim 28, wherein the process actions of recording the prescribed one or ones of the pointing device sensor outputs, comprises the actions of:

(a) waiting for an orientation message to be received;

(b) whenever an orientation message is received, determining whether the switch state indicates that the pointing device's switch has been activated by the user to indicate that a control gesture is being performed;

(c) whenever it is determined that the switch state does not indicate that the pointing devices switch is activated, repeat actions (a) and (b);

(d) whenever it is determined that the switch state does indicate that the pointing devices switch is activated, recording the prescribed one or ones of the pointing device sensor outputs taken from the last received orientation message.

30. The process of claim 28, wherein each gesture is a movement of the pointer in a single prescribed direction, and wherein the sensor output or outputs included in each gesture threshold definition and so the recorded sensor outputs are those that characterize the motion of the pointing device in the prescribed direction associated with the gesture.

31. The process of claim 30, wherein the pointing device sensors comprise a magnetometer which has outputs that characterize the movement of the pointer in pitch, roll and yaw.

32. The process of claim 30, wherein the pointing device sensors comprise an accelerometer which has outputs that characterize the movement of the pointer in pitch and roll.

33. The process of claim 30, wherein the pointing device sensors comprise a gyroscope which has outputs that characterize the movement of the pointer in yaw only.

34. The process of claim 28, wherein prior to performing the process action of determining if the threshold or thresholds of each gesture threshold definition assigned to the selected electronic component are exceeded, performing a process action of establishing for each gesture representing a control action for the selected electronic component a gesture threshold definition, each of said gesture threshold definitions comprising either (i) a prescribed threshold applicable to a particular single sensor output or (ii) a set of thresholds applicable to a particular group of sensor outputs, which are indicative of the pointing device being moved in a particular direction from a starting point wherein the pointing device is pointed at the object in the environment corresponding to or associated with the selected electronic component.

35. A system for controlling electronic components within an environment using a pointing device, comprising:

a pointing device comprising a transceiver and orientation sensors, wherein the outputs of the sensors are periodically packaged as orientation messages and transmitted using the transceiver;

a base station comprising a transceiver which receives orientation messages transmitted by the pointing device;

a pair of imaging devices each of which is located so as to capture images of the environment from different viewpoints;

a computing device which is in communication with the base station and the imaging devices so as to receive orientation messages forwarded to it by the base station and images captured by the imaging devices, and which,

computes the orientation and location of the pointer from the received orientation message and captured images,

determines if the pointing device is pointing at an object in the environment which corresponds to, or is associated with, an electronic component that is controllable by the computing device using the orientation and location of the pointing device, and if so selects the electronic component,

affects the selected electronic component in accordance with a command received from the pointing device.

36. The system of claim 35, wherein the pointing device further comprises a manually-operated switch whose state with regard to whether it is activated or deactivated at the time an orientation message is packaged for transmission is included in that orientation message, and wherein said command from the pointing device comprises a switch state which indicates that the switch is activated.

37. The system of claim 36, wherein the selected electronic component can be activated or deactivated by the computing device, and wherein a switch state indicating that the pointing device's switch is activated received in an orientation message transmitted by the pointing device after the electronic component is selected is interpreted by the computing device as a command to one of (i) activate the selected component if the component is deactivated, or (ii) deactivate the component if the component is activated.

38. The system of claim 35, wherein the pointing device further comprises a pair of visible spectrum light emitting diodes (LEDs) which are visible when lit from outside of the pointer, said visible spectrum LEDs being employ to provide status or feedback information to the user.

39. The system of claim 38, wherein the computing device instructs the pointing device to light one or both of the visible spectrum LEDs by causing the base station to transmit an command to the pointing device instructing it to light one or both of the visible spectrum LEDs.

40. The system of claim 39, wherein the computing device instructs the pointing device to light one of the visible spectrum LEDs whenever the pointer is pointing at an object in the environment which corresponds to, or is associated with, an electronic component that is controllable by the computing device.

41. The system of claim 39, wherein the computing device instructs the pointing device to light a first one of the visible spectrum LEDs whenever the pointer is pointing at an object in the environment which corresponds to, or is associated with, an electronic component that is activated, and to light the other visible spectrum LEDs whenever the pointer is pointing at an object in the environment which corresponds to, or is associated with, an electronic component that is deactivated.

42. The system of claim 39, wherein the computing device instructs the pointing device to light one of the visible spectrum LEDs whenever the pointer is pointing at an object in the environment which corresponds to, or is associated with, an audio device that is controllable by the computing device, and to vary the intensity of that LED in proportion to the volume setting of the audio device.

43. The system of claim 39, wherein the computing device emits a user-audible sound whenever the pointer is pointing at an object in the environment which corresponds to, or is associated with, an electronic component that is controllable by the computing device.

Description

BACKGROUND

1. Technical Field

The invention is related to controlling electronic components in a ubiquitous computing environment, and more particularly to a system and process for controlling the components using multimodal integration in which inputs from a speech recognition subsystem, gesture recognition subsystem employing a wireless pointing device and pointing analysis subsystem associated with the pointing device, are combined to determine what component a user wants to control and what control action is desired.

2. Background Art

Increasingly our environment is populated with a multitude of intelligent devices, each specialized in function. The modern living room, for example, typically features a television, amplifier, DVD player, lights, and so on. In the near future, we can look forward to these devices becoming more inter-connected, more numerous and more specialized as part of an increasingly complex and powerful integrated intelligent environment. This presents a challenge in designing good user interfaces.

For example, today's living room coffee table is typically cluttered with multiple user interfaces in the form of infrared (IR) remote controls. Often each of these interfaces controls a single device. Tomorrow's intelligent environment presents the opportunity to present a single intelligent user interface (UI) to control many such devices when they are networked. This UI device should provide the user a natural interaction with intelligent environments. For example, people have become quite accustomed to pointing at a piece of electronic equipment that they want to control, owing to the extensive use of IR remote controls. It has become almost second nature for a person in a modern environment to point at the object he or she wants to control, even when it is not necessary. Take the small radio frequency (RF) key fobs that are used to lock and unlock most automobiles in the past few years as an example. Inevitably, a driver will point the free end of the key fob toward the car while pressing the lock or unlock button. This is done even though the driver could just have well pointed the fob away from the car, or even pressed the button while still in his or her pocket, owing to the RF nature of the device. Thus, a single UI device, which is pointed at electronic components or some extension thereof (e.g., a wall switch to control lighting in a room) to control these components, would represent an example of the aforementioned natural interaction that is desirable for such a device.

There are some so-called "universal" remote controls on the market that are preprogrammed with the known control protocols of a litany of electronic components, or which are designed to learn the command protocol of an electronic component. Typically, such devices are limited to one transmission scheme, such as IR or RF, and so can control only electronic components operating on that scheme. However, it would be desirable if the electronic components themselves were passive in that they do not have to receive and process commands from the UI device directly, but would instead rely solely on control inputs from the aforementioned network. In this way, the UI device does not have to differentiate among various electronic components, say by recognizing the component in some manner and transmitting commands using some encoding scheme applicable only to that component, as is the case with existing universal remote controls.

Of course, a common control protocol could be implemented such that all the controllable electronic components within an environment use the same control protocol and transmission scheme. However, this would require all the electronic components to be customized to the protocol and transmission scheme, or to be modified to recognize the protocol and scheme. This could add considerably to the cost of a "single UI-controlled" environment. It would be much more desirable if the UI device could be used to control any networked group of new or existing electronic components regardless of remote control protocols or transmission schemes the components were intended to operate under.

Another current approach to controlling a variety of different electronic components in an environment is through the use of speech recognition technology. Essentially, a speech recognition program is used to recognize user commands. Once recognized the command can be acted upon by a computing system that controls the electronic components via a network connection. However, current speech recognition-based control systems typically exhibit high error rates. Although speech technology can perform well under laboratory conditions, a 20%-50% decrease in recognition rates can be experienced when these systems are used in a normal operating environment. This decrease in accuracy occurs for the most part because of the unpredictable and variable noise levels found in a normal operating setting, and the way humans alter their speech patterns to compensate for this noise. In fact, environmental noise is currently viewed as a primary obstacle to the widespread commercialization of speech recognition systems.

It is noted that in the preceding paragraphs, as well as in the remainder of this specification, the description refers to various individual publications identified by a numeric designator contained within a pair of brackets. For example, such a reference may be identified by reciting, "reference [1]" or simply "[1]". Multiple references will be identified by a pair of brackets containing more than one designator, for example, [2, 3]. A listing of references including the publications corresponding to each designator can be found at the end of the Detailed Description section.

SUMMARY

The present invention is directed toward a system and process that controls a group of networked electronic components regardless of any remote control protocols or transmission schemes under which they operate. In general this is accomplish using a multimodal integration scheme in which inputs from a speech recognition subsystem, gesture recognition subsystem employing a wireless pointing device and pointing analysis subsystem also employing the pointing device, are combined to determine what component a user wants to control and what control action is desired.

In order to control one of the aforementioned electronic components, the component must first be identified to the control system. In general this can be accomplished using the pointing system to identify the desired component by pointing at it, or by employing speech recognition, or both. The advantage of using both is to reinforce the selection of a particular component, even in a noisy environment where the speech recognition system may operate poorly. Thus, by combining inputs the overall system is made more robust. This use of divergent inputs to reinforce the selection is referred to as multimodal integration.

Once the object is identified, the electronic device can be controlled by the user informing the computer in some manner what he or she wants the device to do. This may be as simple as instructing the computer to turn the device on or off by activating a switch or button on the pointer. However, it is also desirable to control devices in more complex ways than merely turning them on or off. Thus, the user must have some way of relaying the desired command to the computer. One such way would be through the use of voice commands interpreted by the speech recognition subsystem. Another way is by having the user perform certain gestures with the pointer that the computer will recognize as particular commands. Integrating these approaches is even better as explained previously.

In regard to the user performing certain gestures with the pointer to remotely convey a command, this can be accomplished in a variety of ways. One approach involves matching a sequence of sensor values output by the pointer and recorded over a period of time, to stored prototype sequences each representing the output of the sensor that would be expected if the pointer were manipulated in a prescribed manner. This prescribed manner is the aforementioned gesture.

The stored prototype sequences are generated in a training phase for each electronic component it is desired to control via gesturing. Essentially to teach a gesture to the electronic component control system that represents a particular control action for a particular electronic component, a user simply holds down the pointer's button while performing the desired gesture. Meanwhile the electronic component control process is recording particular sensor values obtained from orientation messages transmitted by the pointer during the time the user is performing the gesture. The recorded sensor values represent the prototype sequence.

During operation, the control system constantly monitors the incoming orientation messages once an object associated with a controllable electronic component has been selected to assess whether the user is performing a control gesture. As mentioned above, this gesture recognition task is accomplished by matching a sequence of sensor values output by the pointer and recorded over a period of time, to stored prototype sequences representing the gestures taught to the system.

It is noted however, that a gesture made by a user during runtime may differ from the gesture preformed to create the prototype sequence in terms of speed or amplitude. To handle this situation, the matching process can entails not only comparing a prototype sequence to the recorded sensor values but also comparing the recorded sensor values to various versions of the prototype that are scaled up and down in amplitude and/or warped in time. Each version of the a prototype sequence is created by applying a scaling and/or warping factor to the prototype sequence. The scaling factors scale each value in the prototype sequence either up or down in amplitude. Whereas, the warping factors expand or contract the overall prototype sequence in time. Essentially, a list is established before initiating the matching process which includes every combination of the scaling and warping factors possible, including the case where one or both of the scaling and warping factors are zero (thus corresponding to the unmodified prototype sequence).

Given this prescribed list, each prototype sequence is selected in turn and put through a matching procedure. This matching procedure entails computing a similarity indicator between the input sequence and the selected prototype sequence. The similarity indicator can be defined in various conventional ways. However, in tested versions of the control system, the similarity indicator was obtained by first computing a "match score" between corresponding time steps of the input sequence and each version of the prototype sequence using a standard Euclidean distance technique. The match scores are averaged and the maximum match score is identified. This maximum match score is the aforementioned similarity indicator for the selected prototype sequence. Thus, the aforementioned variations in the runtime gestures are considered in computing the similarity indicator. When a similarity indicator has been computed for every prototype sequence it is next determined which of the similarity indicators is the largest. The prototype sequence associated with the largest similarity indicator is the best match to the input sequence, and could indicate the gesture associated with that sequence was performed. However, unless the similarity is great enough, it might be that the pointer movements are random and do not match any of the trained gestures. This situation is handled by ascertaining if the similarity indicator of the designated prototype sequence exceeds a prescribed similarity threshold. If the similarity indicator exceeds the threshold, then it is deemed that the user has performed the gesture associated with that designated prototype sequence. As such, the control action corresponding to that gesture is initiated by the host computer. If the similarity indicator does not exceed the threshold, no control action is initiated. The foregoing process is repeated continuously for each block of sensor values obtained from the incoming orientation messages having the prescribed length.

In regard to the use of simple and short duration gestures, such as for example a single upwards or downwards motion, an opportunity exists to employ a simplified approach to gesture recognition. For such gestures, a recognition strategy can be employed that looks for simple trends or peaks in one or more of the sensor values output by the pointer. For example, pitching the pointer up may be detected by simply thresholding the output of the accelerometer corresponding to pitch. Clearly such an approach will admit many false positives if run in isolation. However, in a real system this recognition will be performed in the context on an ongoing interaction, during which it will be clear to system (and to the user) when a simple pitch up indicates the intent to control a device in a particular way. For example, the system may only use the gesture recognition results if the user is also pointing at an object, and furthermore only if the particular gesture applies to that particular object. In addition, the user can be required to press and hold down the pointer's button while gesturing. Requiring the user to depress the button while gesturing allows the system to easily determine when a gesture begins. In other words, the system records sensor values only after the user depresses the button, and thus gives a natural origin from which to detect trends in sensor values. In the context of gesturing while pointing at an object, this process induces a local coordinate system around the object, so that "up", "down", "left" and "right" are relative to where the object appears to the user. For example, "up" in the context of a standing user pointing at an object on the floor means pitching up from a pitched down position, and so on.

As discussed above, a system employing multimodal integration would have a distinct advantage over one system alone. To this end, the present invention includes the integration of a conventional speech control system into the gesture control and pointer systems which results in a simple framework for combining the outputs of various modalities such as pointing to target objects and pushing the button on the pointer, pointer gestures, and speech, to arrive at a unified interpretation that instructs a combined environmental control system on an appropriate course of action. This framework decomposes the desired action into a command and referent pair. The referent can be identified using the pointer to select an object in the environment as described previously or using a conventional speech recognition scheme, or both. The command may be specified by pressing the button on the pointer, or by a pointer gesture, or by a speech recognition event, or any combination thereof.

The identity of the referent, the desired command and the appropriate action are all determined by the multimodal integration of the outputs of the speech recognition system, gesture recognition system and pointing analysis processes using a dynamic Bayes network. Specifically, the dynamic Bayes network includes input, referent, command and action nodes. The input nodes correspond to the aforementioned inputs and are used to provide state information to at least one of either the referent, command, or action node. The states of the inputs determine the state of the referent and command nodes, and the states of the referent and command nodes are in turn fed into the action node, whose state depends in part on these inputs and in part on a series of device state input nodes. The state of the action node indicates the action that is to be implemented to affect the referent. The referent, command and action node states comprise probability distributions indicating the probability that each possible referent, command and action is the respective desired referent, command and action.

In addition, the dynamic Bayes network preserves ambiguities from one time step to the next while waiting for enough information to become available to make a decision as to what referent, command or action is intended. This is done via a temporal integration technique in which probabilities assigned to referents and commands in the last time step are brought forward to the current time step and are input along with new speech, pointing and gesture inputs to influence the probability distribution computed for the referents and commands in the current time step. In this way the network tends to hold a memory of a command and referent, and it is thus unnecessary to specify the command and referent at exactly the same moment in time. It is also noted that the input from these prior state nodes is weighted such that their influence on the state of the referent and command nodes decreases in proportion to the amount of time that has past since the prior state node first acquired its current state.

The Bayes network architecture also allows the state of various devices to be incorporated via the aforementioned device state input nodes. In particular, these nodes provide state information to the action node that reflects the current condition of an electronic component associated with the device state input node whenever the referent node probability distribution indicates the referent is that component. This allows, as an example, the device state input nodes to input an indication of whether the associated electronic component is activated or deactivated. This can be quite useful in situations where the only action permitted in regard to an electronic component is to turn it off if it is on, and to turn it on if it is off. In such a situation, an explicit command need not be determined. For example if the electronic component is a lamp, all that need be known is that the referent is this lamp and that it is on or off. The action of turning the lamp on or off, as the case may be, follows directly, without the user ever having to command the system.

DESCRIPTION OF THE DRAWINGS

The specific features, aspects, and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where:

FIG. 1 is a diagram depicting an object selection system according to the present invention.

FIG. 2 is an image depicting one version of the wireless RF pointer employed in the object selection system of FIG. 1, where the case is transparent revealing the electronic component within.

FIG. 3 is a block diagram illustrating the internal components included in one version of the wireless RF pointer employed in the object selection system of FIG. 1.

FIG. 4 is a flow chart diagramming a process performed by the pointer to package and transmit orientation data messages.

FIG. 5 is a block diagram illustrating the internal components included in one version of the RF base station employed in the object selection system of FIG. 1.

FIG. 6 is a diagram depicting a general purpose computing device constituting an exemplary system for implementing the host computer of the present invention.

FIG. 7 is a flow chart diagramming an overall process for selecting an object using the object selection system of FIG. 1.

FIG. 8 is a flow chart diagramming a process for determining a set of magnetometer correction factors for use in deriving the orientation of the pointer performed as part of the overall process of FIG. 7.

FIG. 9 is a flow chart diagramming a process for determining a set of magnetometer normalization factors for use in deriving the orientation of the pointer performed as part of the overall process of FIG. 7.

FIGS. 10A-B depict a flow chart diagramming the process for deriving the orientation of the pointer performed as part of the overall process of FIG. 7.

FIG. 11 is a timeline depicting the relative frequency of the production of video image frames by the video cameras of the system of FIG. 1 and the short duration flash of the IR LED of the pointer.

FIGS. 12A-B are images respectively depicting an office at IR frequencies from each of two IF pass-filtered video cameras, which capture the flash of the IR LED of the pointer.

FIGS. 12C-D are difference images of the same office as depicted in FIGS. 12A-B where FIG. 12C depicts the difference image derived from a pair of consecutive images generated by the camera that captured the image of FIG. 12A and where FIG. 12D depicts the difference image derived from a pair of consecutive images generated by the camera that captured the image of FIG. 12B. The difference images attenuate background IR leaving the pointer's IR LED flash as the predominant feature of the image.

FIG. 13 depicts a flow chart diagramming the process for determining the location of the pointer performed as part of the overall process of FIG. 7.

FIG. 14 is a flow chart diagramming a first process for using the object selection system of FIG. 1 to model an object in an environment, such as a room, as a Gaussian blob.

FIG. 15 is a flow chart diagramming an alternate process for using the object selection system of FIG. 1 to model an object in an environment as a Gaussian blob.

FIG. 16 depicts a flow chart diagramming a process for determining what object a user is pointing at with the pointer as part of the overall process of FIG. 7.

FIG. 17 is a flow chart diagramming a process for teaching the system of FIG. 1 to recognize gestures performed with the pointer that represent control actions for affecting an electronic component corresponding to or associated with a selected object.

FIG. 18 depicts a flow chart diagramming one process for controlling an electronic component by performing gestures with the pointer using the system of FIG. 1.

FIG. 19 depicts a flow chart diagramming a process for identifying the maximum averaged match score as used in the process of FIG. 18.

FIGS. 20A-B depict a flow chart diagramming another process for controlling an electronic component by performing gestures with the pointer using the system of FIG. 1.

FIG. 21 is a network diagram illustrating a dynamic Bayes network used to integrate inputs from the system of FIG. 1 (both via pointing and gesturing), speech, past beliefs and electronic component states to determine the desired referent and command, and then to use these determinations, along with the component state information, to determine an appropriate action for affecting a selected electronic component.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description of the preferred embodiments of the present invention, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

In general, the present electronic component control system and process involves the integration of a unique wireless pointer-based object selection system, a unique gesture recognition system that employs the wireless pointer, and a conventional speech control system to create a multimodal interface for determining what component a user wants to control and what control action is desired.

The pointer-based object selection system will be described first in the sections to follow, followed by the gesture recognition system, and finally the integration of these systems with a conventional speech recognition system to form the present electronic component control system.

1.0 Object Selection Using a Wireless Pointer

In general, the present multimodal interface control system requires an object selection system that is capable of allowing a user to point a pointing device (referred to as a pointer) at an object in the environment that is, or is associated with, an electronic component that is controllable by the control system, and by computing the orientation and location of the pointer in terms of the environment's pre-defined coordinate system, can determine that the user is pointing at the object. Any object selection system meeting the foregoing criteria can be used. One such system is the subject of a co-pending U.S. patent application entitled "A SYSTEM AND PROCESS FOR SELECTING OBJECTS IN A UBIQUITOUS COMPUTING ENVIRONMENT", having a Ser. No. of 10/160,692, and a filing date of May 31, 2002 Referring to FIG. 1, the object selection system described in the co-pending application employs a wireless pointer 10, which is pointed by a user at an object in the surrounding environment (such as a room) that the user wishes to affect. For example, the user might point the device 10 at a lamp with the intention of turning the lamp on or off. The wireless pointer 10 transmits data messages to a RF transceiver base station 12, which is in communication with a host computer 14, such as a personal computer (PC). In tested versions of the object selection system, communications between the base station 12 and the host computer 14 were accomplished serially via a conventional RS232 communication interface. However, other communication interfaces can also be employed as desired. For example, the communications could be accomplished using a Universal System Bus (USB), or IEEE 1394 (Firewire) interface, or even a wireless interface. The base station 12 forwards data received from the pointer 10 to the host computer 14 when a data message is received. The host computer 14 then computes the current 3D orientation of the pointer 10 from the aforementioned received data. The process used for this computation will be described in detail later.

The object selection system also includes components for determining the 3D location of the pointer 10. Both the orientation and location of the pointer within the environment in which it is operating are needed to determine where the user is pointing the device. In tested embodiments of the system these components included a pair of video cameras 16, 18 with infrared-pass filters. These cameras 16, 18 are mounted at separate locations within the environment such that each images the portion of the environment where the user will be operating the pointer 10 from a different viewpoint. A wide angle lens can be used for this purpose if necessary. Each camera 16, 18 is also connected via any conventional wireless or wired pathway to the host computer 14, so as to provide image data to the host computer 14. In tested embodiments of the system, the communication interface between the each camera 16, 18 and the host computer 14 was accomplished using a wired IEEE 1394 (i.e., Firewire) interface. The process by which the 3D location of the pointer 10 is determined using the image data provided from the cameras 16, 18 will also be discussed in detail later.

The aforementioned wireless pointer is a small hand-held unit that in the tested versions of the object selection system resembled a cylindrical wand, as shown in FIG. 2. However, the pointer can take on many other forms as well. In fact the pointer can take on any shape that is capable of accommodating the internal electronics and external indicator lights and actuators associated with the device—although preferably the chosen shape should be amenable to being pointed with a readily discernable front or pointing end. Some examples of possible alternate shapes for the pointer would include one resembling a remote control unit for a stereo or television, or one resembling an automobile key fob, or one resembling a writing pen.

In general, the wireless pointer is constructed from a case having the desired shape, which houses a number of off-the-shelf electronic components. Referring to the block diagram of FIG. 3, the general configuration of these electronic components will be described. The heart of the pointer is a PIC microcontroller 300 (e.g., a PIC 16F873 20 MHz Flash programmable microcontroller), which is connected to several other components. For example, the output of an accelerometer 302, which produces separate x-axis and y-axis signals (e.g., a 2-axis MEMs accelerometer model number ADXL202 manufactured by Analog Devices, Inc. of Norwood Massachusetts) is connected to the microcontroller 300. The output of a magnetometer 304 (e.g., a 3-axis magnetoresistive permalloy film magnetometer model number HMC1023 manufactured by Honeywell SSEC of Plymouth, Minn.), which produces separate x, y and z axis signals, is also connected to the microcontroller 300, as can be an optional single axis output of a gyroscope 306 (e.g., a 1-axis piezoelectric gyroscope model number ENC-03 manufactured by Murata Manufacturing Co., Ltd. of Kyoto, Japan). The block representing the gyroscope in FIG. 3 has dashed lines to indicate it is an optional component.

There is also at least one manually-operated switch connected to the microcontroller 300. In the tested versions of the wireless pointer, just one switch 308 was included, although more switches could be incorporated depending on what functions it is desired to make available for manual activation or deactivation. The included switch 308 is a push-button switch; however any type of switch could be employed. In general, the switch (i.e., button) 308 is employed by the user to tell the host computer to implement some function. The particular function will be dependent on what part of the object selection system process is currently running on the host computer. For example, the user might depress the button to signal to the host computer that user is pointing at an object he or she wishes to affect (such as turning it on or off if it is an electrical device), when the aforementioned process is in an object selection mode. A transceiver 310 with a small antenna 312 extending therefrom, is also connected to and controlled by the microcontroller 300. In tested versions of the pointer, a 418 MHz, 38.4 kbps bi-directional, radio frequency transceiver was employed.

Additionally, a pair of visible spectrum LEDs 314, 316, is connected to the microcontroller 300. Preferably, these LEDs each emit a different color of light. For example, one of the LEDs 314 could produce red light, and the other 316 could produce green light. The visible spectrum LEDs 314, 316 can be used for a variety of purposes preferably related to providing status or feedback information to the user. In the tested versions of the object selection system, the visible spectrum LEDs 314, 316 were controlled by commands received from the host computer via the base station transceiver. One example of their use involves the host computer transmitting a command via the base station transceiver to the pointer instructing the microcontroller 300 to illuminate the green LED 316 when the device is being pointed at an object that the host computer is capable of affecting, and illuminating the red LED when it is not. In addition to the pair of visible LEDs, there is an infrared (IR) LED 318 that is connected to and controlled by the microcontroller 300. The IR LED can be located at the front or pointing end of the pointer. It is noted that unless the case of the pointer is transparent to visible and/or IR light, the LEDs 314, 316, 318 whose light emissions would be blocked are configured to extend through the case of the pointer so as to be visible from the outside. It is further noted that a vibration unit such as those employed in pagers could be added to the pointer so that the host computer could activate the unit and thereby attract the attention of the user, without the user having to look at the pointer.

A power supply 320 provides power to the above-described components of the wireless pointer. In tested versions of the pointer, this power supply 320 took the form of batteries. A regulator in the power supply 320 converts the battery voltage to 5 volts for the electronic components of the pointer. In tested versions of the pointer about 52 mA was used when running normally, which decreases to 1 mA when the device is in a power saving mode that will be discussed shortly.

Tested versions of the wireless pointer operate on a command-response protocol between the device and the base station. Specifically, the pointer waits for a transmission from the base station. An incoming transmission from the base station is received by the pointer's transceiver and sent to the microcontroller. The microcontroller is pre-programmed with instructions to decode the received messages and to determine if the data contains an identifier that is assigned to the pointer and which uniquely identifies the device. This identifier is pre-programmed into the microcontroller. If such an identifier is found in the incoming message, then it is deemed that the message is intended for the pointer. It is noted that the identifier scheme allows other devices to be contacted by the host computer via the base station. Such devices could even include multiple pointers being operated in the same environment, such as in an office. In the case where multiple pointer are in use in the same environment, the object selection process which will be discussed shortly can be running as multiple copies (one for each pointer) on the same host computer, or could be running on separate host computers. Of course, if there are no other devices operating in the same environment, then the identifier could be eliminated and every message received by the pointer would be assumed to be for it. The remainder of the data message received can include various commands from the host computer, including a request to provided orientation data in a return transmission. In tested versions of the object selection system, a request for orientation data was transmitted 50 times per second (i.e., a rate of 50 Hz). The microcontroller is pre-programmed to recognize the various commands and to take specific actions in response.

For example, in the case where an incoming data message to the pointer includes a request for orientation data, the microcontroller would react as follows. Referring to the flow diagram in FIG. 4, the microcontroller first determines if the incoming data message contains an orientation data request command (process action 400). If not, the microcontroller performs any other command included in the incoming data message and waits for the next message to be received from the base station (process action 402). If, however, the microcontroller recognizes an orientation data request command, in process action 404 it identifies the last-read outputs from the accelerometer, magnetometer and optionally the gyroscope (which will hereafter sometimes be referred to collectively as "the sensors"). These output values, along with the identifier assigned to the pointer (if employed), and optionally the current state of the button and error detection data (e.g., a checksum value), are packaged by the microcontroller into an orientation data message (process action 406). The button state is used by the host computer of the system for various purposes, as will be discussed later. The orientation data message is then transmitted via the pointer's transceiver to the base station (process action 408), which passes the data on to the host computer. The aforementioned orientation message data can be packaged and transmitted using any appropriate RF transmission protocol.

It is noted that while tested versions of the object selection system used the above-described polling scheme where the pointer provided the orientation data message in response to a transmitted request, this need not be the case. For example, alternately, the microcontroller of the pointer could be programmed to package and transmit an orientation message on a prescribed periodic basis (e.g., at a 50 Hz rate).

The aforementioned base station used in the object selection system will now be described. In one version, the base station is a small, stand-alone box with connections for DC power and communications with the PC, respectively, and an external antenna. In tested versions of the object selection system, communication with the PC is done serially via a RS232 communication interface. However, other communication interfaces can also be employed as desired. For example, the PC communications could be accomplished using a Universal System Bus (USB), or IEEE 1394 (Firewire) interface, or even a wireless interface. The antenna is designed to receive 418 MHz radio transmissions from the pointer.

Referring now to the block diagram of FIG. 5, the general construction of the RF transceiver base station will be described. The antenna 502 sends and receives data message signals. In the case of receiving a data message from the pointer, the radio frequency transceiver 500 demodulates the received signal for input into a PIC microcontroller 504. The microcontroller 504 provides an output representing the received data message each time one is received, as will be described shortly. A communication interface 506 converts microcontroller voltage levels to levels readable by the host computer. As indicated previously, the communication interface in tested versions of the base station converts the microcontroller voltage levels to RS232 voltages. Power for the base station components is provided by power supply 508, which could also be battery powered or take the form of a separate mains powered AC circuit.

It is noted that while the above-described version of the base station is a stand-alone unit, this need not be the case. The base station could be readily integrated into the host computer itself. For example, the base station could be configured as an expansion card which is installed in an expansion slot of the host computer. In such a case only the antenna need be external to the host computer.

The base station is connected to the host computer, as described previously. Whenever an orientation data message is received from the pointer it is transferred to the host computer for processing. However, before providing a description of this processing, a brief, general description of a suitable computing environment in which this processing may be implemented and of the aforementioned host computer, will be described in more detail. It is noted that this computing environment is also applicable to the other processes used in the present electronic component control system, which will be described shortly. FIG. 6 illustrates an example of a suitable computing system environment 100. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.

The object selection process is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like (which are collectively be referred to as computers or computing devices herein).

The object selection process may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

With reference to FIG. 6, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. Components of computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.

The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 6 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 6 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.

The drives and their associated computer storage media discussed above and illustrated in FIG. 6, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 6, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointer 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus 121, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195. Further, a camera 163 (such as a digital/electronic still or video camera, or film/photographic scanner) capable of capturing a sequence of images 164 can also be included as an input device to the personal computer 110. While just one camera is depicted, multiple cameras could be included as input devices to the personal computer 110. The images 164 from the one or more cameras are input into the computer 110 via an appropriate camera interface 165. This interface 165 is connected to the system bus 121, thereby allowing the images to be routed to and stored in the RAM 132, or one of the other data storage devices associated with the computer 110. However, it is noted that image data can be input into the computer 110 from any of the aforementioned computer-readable media as well, without requiring the use of the camera 163.

The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in FIG. 6. The logical connections depicted in FIG. 6 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 6 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

The exemplary operating environment having now been discussed, the remaining part of this description section will be devoted to a description of the program modules embodying the object selection process performed by the host computer. Generally, referring to FIG. 7, the object selection process begins by inputting the raw sensor readings provided in an orientation message forwarded by the base station (process action 700). These sensor readings are normalized (process action 702) based on factors computed in a calibration procedure, and then combined to derive the full 3D orientation of the pointer (process action 704). Then, the 3D location of the pointer in the environment in which it is operating is computed (process action 706). Once the orientation and location of the pointer is known, the object selection process determines what the pointer is being pointed at within the environment (process action 708), so that the object can be affected in some manner. The process then waits for another orientation message to be received (process action 710) and repeats process actions 700 through 710.

The object selection process requires a series of correction and normalization factors to be established before it can compute the orientation of the pointer from the raw sensor values provided in an orientation message. These factors are computed in a calibration procedure. The first part of this calibration procedure involves computing correction factors for each of the outputs from the magnetometer representing the three axes of the 3-axis device, respectively. Correction factors are needed to relate the magnetometer outputs, which are a measure of deviation from the direction of the Earth's magnetic field referred to as magnetic north (specifically the dot product of the direction each axis of the magnetometer is pointed with the direction of magnetic north), to the coordinate frame established for the environment in which the pointer is operating. The coordinate frame of the environment is arbitrary, but must be pre-defined and known to the object selection process prior to performing the calibration procedure. For example, if the environment is a room in a building, the coordinate frame might be establish such that the origin is in a corner with one axis extending vertically from the corner, and the other two horizontally along the two walls forming the corner.

Referring to FIG. 8, the magnetometer correction factors are computed by the user first indicating to the object selection process that a calibration reading is being taken, such as for instance, by the user putting the object selection process running on the host computer into a magnetometer correction factor calibration mode (process action 800). The user then points the pointer in a prescribed direction within the environment, with the device being held in a known orientation (process action 802). For example, for the sake of the user's convenience, the pre-determined direction might be toward a wall in the front of the room and the known orientation horizontal, such that a line extending from the end of the pointer intersects the front wall of the room substantially normal to its surface. If the pre-defined coordinate system of the environment is as described in the example above, then the pointer would be aligned with the axes of this coordinate system, thus simplifying the correction and normalization factor computations. The user activates the switch on the pointer when the device is pointed in the proper direction with the proper orientation (process action 804). Meanwhile, the object selection process requests the pointer provide an orientation message in the manner discussed previously (process action 806). The object selection process then inputs the orientation message transmitted by the pointer to determine if the switch status indicator indicates that the pointer's switch has been activated (process action 808). If not, the requesting and screening procedure continues (i.e., process actions 806 and 808 are repeated). However, when an orientation message is received in which the button indicator indicates the button has been depressed, then it is deemed that the sensor readings contained therein reflect those generated when the pointer is pointing in the aforementioned prescribed direction and with the prescribed orientation. The magnetometer readings contained in the orientation message reflect the deviation of each axis of the magnetometer from magnetic north within the environment and represent the factor by which each subsequent reading is offset to relate the readings to the environment's coordinate frame rather than the magnetometer axes. As such, in process action 810, the magnetometer reading for each axis is designated as the magnetometer correction factor for that axis.

In addition to computing the aforementioned magnetometer correction factors, factors for range-normalizing the magnetometer readings are also computed in the calibration procedure. Essentially, these normalization factors are based on the maximum and minimum outputs that each axis of the magnetometer is capable of producing. These values are used later in a normalization procedure that is part of the process for determining the orientation of the pointer. A simple way of obtaining these maximum and minimum values is for the user to wave the pointer about while the outputs of the magnetometer are recorded by the host computer. Specifically, referring to FIG. 9, the user would put the object selection process running on the host computer in a magnetometer max/min calibration mode (process action 900), and then wave the pointer about (process action 902). Meanwhile, the object selection process requests the pointer to provide orientation messages in the normal manner (process action 904). The object selection process then inputs and records the magnetometer readings contained in each orientation message transmitted by the pointer (process action 906). This recording procedure (and presumably the pointer waving) continues for a prescribed period of time (e.g., about 1 minute) to ensure the likelihood that the highest and lowest possible readings for each axis are recorded. Once the recording procedure is complete, the object selection process selects the highest reading recorded for each axis of the magnetometer and designates these levels as the maximum for that axis (process action 908). Similarly, the host computer selects the lowest reading recorded for each axis of the magnetometer and designates these levels as the minimum for that axis (process action 910). Normalization factors are then computed via standard methods and stored for each magnetometer axis that convert the range represented by the maximum and minimum levels to a normalized range between 1.0 and -1.0 (process action 912). These magnetometer normalization factors are used to normalize the actual readings from the magnetometer by converting the readings to normalized values between 1.0 and -1.0 during a normalization procedure to be discussed shortly. It is noted that the maximum and minimum values for an axis physically correspond to that axis of the magnetometer being directed along magnetic north and directly away from magnetic north, respectively. It is noted that while the foregoing waving procedure is very simple in nature, it worked well in tested embodiments of the object selection system and provided accurate results.

Factors for range-normalizing (in [-1,1]) the accelerometer readings are also computed in the calibration procedure. In this case, the normalization factors are determined using the accelerometer output normalization procedures applicable to the accelerometer used, such as the conventional static normalization procedure used in tested embodiments of the object selection process.

Once the calibration procedure is complete, the object selection process is ready to compute the orientation of the pointer each time an orientation data message is received by the host computer. The orientation of the pointer is defined in terms of its pitch, roll and yaw angle about the respective x, y and z axes of the environment's pre-defined coordinate system. These angles can be determined via various sensor fusion processing schemes that essentially compute the angle from the readings from the accelerometer and magnetometer of the pointer. Any of these existing methods could be used, however a simplified procedure was employed in tested versions of the object selection system. In this simplified procedure, the yaw angle is computed using the recorded values of the magnetometer output. Even though the magnetometer is a 3-axis device, the pitch, roll and yaw angles cannot be computed directly from the recorded magnetometer values contained in the orientation data message. The angles cannot be computed directly because the magnetometer outputs a value that is the dot-product of the direction of each magnetometer sensor axis against the direction of magnetic north. This information is not sufficient to calculate the pitch, roll, and yaw of the device. However, it is possible to use the accelerometer readings in conjunction with the magnetometer outputs to compute the orientation. Specifically, referring to FIGS. 10A and B, the first action in the procedure is to normalize the magnetometer and accelerometer values received in the orientation message using the previously computed normalization factors to simplify the calculations (process action 1000). The pitch and roll angles of the pointer are then computed from the normalized x-axis and y-axis accelerometer values, respectively (process action 1002). Specifically, the pitch angle=-arcsin(a₁), where a₁ is the normalized output of the accelerometer approximately corresponding to the rotation of the pointer about the x-axis of the environment's coordinate system, and the roll angle=-arcsin(a₂) where a₂ is the normalized output of the accelerometer approximately corresponding to the rotation of the pointer about the y-axis of the environment's coordinate system. Next, these pitch and roll values are used to refine the magnetometer readings (process action 1004). Then, in process action 1006, the previously computed magnetometer correction factors are applied to the refined magnetometer values. Finally, the yaw angle is computed from the refined and corrected magnetometer values (process action 1008).

Specifically, the range-normalized accelerometer values representing the pitch and roll are used to establish the rotation matrix R_a1,a2,0, which represents a particular instance of the Euler angle rotation matrix R_θx,θy,θz that defines the composition of rotations about the x, y and z axes of the prescribed environmental coordinate system. Next, a 3-value vector m is formed from the range-normalized values output by the magnetometer. The pitch and roll then corrects the output of the magnetometer as follows:

m_corected=R_a1,a2y0m  (1)

Let N be the output of the magnetometer when the pointer is held at (pitch, roll, yaw)=(0, 0, 0), as determined in the calibration procedure. Then, project onto the ground plane and normalize as follows:
##EQU1##

And finally, the yaw angle is found as follows:
##EQU2##

The computed yaw angle, along with the pitch and roll angles derived from the accelerometer readings, are then tentatively designated as defining the orientation of the pointer at the time the orientation data message was transmitted by the device (process action 1010).

It is noted that there are a number of caveats to the foregoing procedure. First, accelerometers only give true pitch and roll information when the pointer is motionless. This is typically not an issue except when the orientation computations are being used to determine if the pointer is being pointed directly at an object. In such cases, the problem can be avoided by relying on the orientation information only when the device is deemed to have been motionless when the accelerometer readings were captured. To this end, the orientation (i.e., pitch, roll and yaw) of the pointer is computed via the foregoing procedure for the last orientation message received. This is then compared to the orientation computed for the next to last orientation message received, to determine if the orientation of the pointer has changed significantly between the orientation messages. If the orientation of the pointer did not change significantly, then this indicates that the pointer was motionless prior to the transmission of the last orientation message. If the pointer was deemed to have been motionless, then the orientation information is used. However, if it is found that a significant change in the orientation occurred between the last two orientation messages received, it is deemed that the pointer was in motion and the orientation information computed from the last-received orientation message is ignored. Secondly, magnetic north can be distorted unpredictably in indoor environments and in close proximity to large metal objects. However, in practice, while it was found that for typical indoor office environments magnetic north did not always agree with magnetic north found outdoors, it was found to be fairly consistent throughout a single room. Thus, since the above-described magnetometer correction factors relate the perceived direction of magnetic north in the environment in which the pointer is operating to the prescribed coordinate system of that environment, when the environment is a room, it will not make any difference if the perceived direction of magnetic north within the room matches that in any other room or outdoors, as the orientation of the pointer is computed for that room only. Finally, it should be noted that the foregoing computations will not provide accurate results if the perceived magnetic north in the environment happens to be co-linear to the gravity vector—a situation not likely to occur.

The foregoing designation of the pointer's orientation is tentative because it cannot be determined from the accelerometer reading used to compute the roll angle whether the device was in a right-side up, or upside-down position with respect to roll when the accelerometer outputs were captured for the orientation data message. Thus, the computed roll angle could be inaccurate as the computations assumed the pointer was right-side up. Referring now to FIG. 10B, this uncertainty can be resolved by computing the orientation assuming the pointer is right-side up (process action 1012) and then assuming the pointer is up-side down (process action 1014). Each solution is then used to compute an estimate of what the magnetometer outputs should be given the computed orientation (process actions 1016 and 1018). It is then determined for each case how close the estimated magnetometer values are to the actual values contained in the orientation message (process actions 1020 and 1022). It is next ascertained whether the estimated magnetometer values for the right-side up case are closer to the actual values than the estimated value for the upside-down case (process action 1024). If they are, then the pointer is deemed to have been right-side up (process action 1026). If, however, it is determined that the estimated magnetometer values for the right-side up case are not closer to the actual values than the estimated value for the upside-down case, then the pointer is deemed to have been up-side down (process action 1028). It is next determined if roll angle computed in the tentative rotation matrix is consistent with the deemed case (process action 1030). If it is consistent, the tentative rotation matrix is designated as the finalized rotation matrix (process action 1034). If, however, the tentative rotation matrix is inconsistent with the minimum error case, then the roll angle is modified (i.e., by 180 degrees) in process action 1032, and the modified rotation matrix is designated as the finalized rotation matrix (process action 1034).

One way to accomplish the foregoing task is to compute the orientation (R) as described above, except that it is computed first assuming the pitch angle derived from the accelerometer output reflects a right-side up orientation of the pointer, i.e., Pitch_{right-side up}=-arcsin(a) where a is the normalized output of the accelerometer approximately corresponding to the rotation of the pointer about the x-axis of the environment's coordinate system. The orientation is then computed assuming the pitch angle derived from the accelerometer output reflects an up-side down orientation of the pointer, i.e., Pitch_{up-side down}=-π+arcsin(a). A separate estimate of what the magnetometer outputs (m*) should be given the orientation computed for the right-side up condition and for the up-side down condition are then computed as follows:

m*=R^TN,  (4)

where N is the direction of magnetic north. m* is the estimated magnetometer output assuming the pointer is in the right-side up condition when R is the orientation computed assuming the pointer was in this condition, whereas m* is the estimated magnetometer output assuming the pointer is in the up-side down condition when R is the orientation computed assuming the pointer was in that condition. The error between the estimated magnetometer outputs (m*) and the actual magnetometer outputs (m) is next computed for both conditions, where the error is defined as (m*-m)^T (m*-m). The pointer orientation associated with the lesser of the two error values computed is deemed to be the actual orientation of the pointer. It is noted that the roll angle derived from the accelerometer output could be used to perform as similar error analysis and determine the actual orientation of the pointer.

It is further noted that the 2-axis accelerometer used in the tested versions of the pointer could be replaced with a more complex 3-axis accelerometer, or an additional 1-axis accelerometer or mercury switch oriented in the appropriate direction could be employed, to eliminate the need for the foregoing error computation procedure. This would be possible because it can be determined directly from the "third"-axis readout whether the pointer was right-side up or upside-down with respect to roll. However, this change would add to the complexity of the pointer and must be weighed against the relatively minimal cost of the added processing required to do the error computation procedure.

As indicated previously, both the orientation and location of the pointer within the environment in which it is operating are needed to determine where the user is pointing the device. The position of the pointer within the environment can be determined via various methods, such as using conventional computer vision techniques [1] or ultrasonic acoustic locating systems [2, 3]. While these methods, and their like, could be used successfully, they are relatively complex and often require an expensive infrastructure to implement. A simpler, less costly process was developed for tested versions of the system and will now be described. Specifically, the position of the pointer within the environment is determined with the aid of the two video camera having IR-pass filters. The cameras are calibrated ahead of time to the environment's coordinate system using conventional calibration methods to establish the camera parameters (both intrinsic and extrinsic) that will be needed to determine the 3D position of the pointing end of the pointer from images captured by the cameras. In operation, the aforementioned IR LED of the pointer is flashed for approximately 3 milliseconds at a rate of approximately 15 Hz by the device's microcontroller. Simultaneously, both cameras are recording the scene at 30 Hz. This means that the IR light in the environment is captured in 1/30^th of a second exposures to produce each frame of the video sequence produced each camera. Referring to the time line depicted in FIG. 11, it can be seen that the flash of the IR LED will be captured in every other frame of the video sequence produced by each camera due to the approximately 15 Hz flashing rate. Referring now to FIGS. 12A and B, images depicting the scene at IR frequencies and capturing the flash from the pointer are shown, as produced contemporaneously from each camera. As can be seen, the IR LED flash appears as a bright spot against a background lower intensity IR noise. Referring now to FIG. 13, the procedure for ascertaining the location to the pointer in terms of the pre-defined coordinate system of the environment will be described. First, the image coordinates of the IR LED flash are determined in each contemporaneously captured frame from the cameras that depicts the flash. This is accomplished by first performing a standard subtraction process on a contemporaneously produced pair of frames from each of the cameras (process action 1300). The resulting difference images represent the scene with most of the background IR eliminated and the IR LED flash the predominant feature in terms of intensity in the images, as shown in FIGS. 12C and D which depict the scene from the cameras captured in the image of FIGS. 12A & B respectively once the background IR is eliminated via the subtraction method. A standard peak detection procedure is then performed on the difference image computed from each pair of frames produced by each of the cameras (process action 1302). This peak detection procedure identifies the pixel in the difference image exhibiting the highest intensity. The image coordinates of this pixel are deemed to represent the location of the pointer in the image (process action 1304). Once the image coordinates of the pointer (as represented by the IF LED) are computed from a pair of images produced contemporaneously by each camera, standard stereo image techniques (typically involving triangulation) are employed to determine the 3D location of the pointer in the environment (process action 1306).

Once the pointer's location and orientation at a given point in time are known it is possible to determine where the user is pointing in anticipation of affecting an object in the vicinity. There are numerous methods that can be used to determine the pointed-to location and to identify the object at or near that location. In tested versions of the system, a Gaussian blob scheme is employed to accomplish the foregoing task. This entails first modeling all the objects in the environment that it is desired for the user to be able to affect by pointing at it with the pointer, as 3D Gaussian blobs. In other words, the location and extent of the object is modeled as a single 3D Gaussian blob defined by the coordinates of a 3D location in the environment representing the mean μ of the blob and a covariance Σ defining the outside edge of the blob. These multivariate Gaussians are probability distributions that are easily learned from data, and can coarsely represent an object of a given size and orientation.

The modeling of the objects of interest in the environment as Gaussian blobs can be accomplished in any conventional manner. In tested versions of the object selection system, two different methods were employed. Referring to FIG. 14, the first involves the user initiating a target training procedure that is part of the object selection process (process action 1400), and then holding the button on the pointer down as he or she traces the outline of the object (process action 1402). In addition, the user enters information into the process that identifies the object being traced (process action 1404). Meanwhile, the target training procedure causes a request to be sent to the pointer directing it to provide an orientation message in the manner described previously (process action 1406). The orientation message transmitted by the pointer is inputted (process action 1408), and it is determined whether the button state indicator included in the message indicates that the pointer's button is activated (process action 1410). If not, process actions 1406 through 1410 are repeated. When, it is discovered that the button state indicator indicates the button is activated, then in process action 1412, the location of the pointer (as represented by the IR LED) is computed and recorded in the manner described above using the output from the video cameras. Next, a request is sent to the pointer directing it to provide an orientation message, and it is input when received (process action 1414). It is then determined whether the button state indicator still indicates that the pointer's button is activated (process action 1416). If so, process actions 1412 through 1416 are repeated. If, however, it is discovered that the button state indicator indicates the button is no longer activated, then it is deemed that the user has completed the tracing task and in process action 1418, a Gaussian blob is defined for the series of locations recorded during the tracing. Specifically, for recorded locations x_i, the mean and covariance of the these points is computed as follows:
##EQU3##

The computed mean and covariance define the Gaussian blob representing the traced object. This procedure can then be repeated for each object of interest in the environment.

An alternate, albeit somewhat more complex, method to model the objects of interest in the environment as Gaussian blobs was also employed in tested versions of the object selection process. This method has particular advantage when an object of interest is out of the line of sight of one or both of the cameras, such as if it were located near a wall below one of the cameras. Since images of the object from both cameras are needed to compute the pointers location, and so the points x_i in the tracing procedure, the previously described target training method cannot be used unless both of the cameras can "see" the object.

Referring to FIG. 15, this second target training method involves the user first initiating the training procedure (process action 1500), and then entering information identifying the object to be modeled (process action 1502). The user then repeatedly (i.e., at least twice) points at the object being modeled with the pointer and depresses the device's button, each time from a different position in the environment within the line of sight of both cameras (process action 1504). When the user completes the foregoing action at the last pointing location, he or she informs the host computer that the pointing procedure is complete (process action 1506). Meanwhile, the training procedure causes a request to be sent to the pointer directing it to provide an orientation message in the manner described previously (process action 1508). The orientation message transmitted by the pointer is inputted (process action 1510), and it is determined whether the button state indicator included in the message indicates that the pointer's button is activated (process action 1512). If not, process actions 1508 through 1512 are repeated. When, it is discovered that the button state indicator indicates the button is activated, then in process action 1514, the orientation and location of the pointer are computed and recorded using the procedures described previously. It is next determined if the user has indicated that the pointing procedure is complete (process action 1516). If not, process actions 1508 through 1516 are then repeated as appropriate. If, however, the pointing procedure is complete, a ray that projects through the environment from the pointer's location along the device's orientation direction is established for each recorded pointing location (process action 1518). Next, the coordinates of the point in the environment representing the mean of a Gaussian blob that is to be used to model the object under consideration, are computed (process action 1520). This is preferably accomplished as follows. For each pointing location:

x_l+s_iw_i=μ  (6)

where x_i is the position of the pointer at the i^th pointing location, w_i is the ray extending in the direction the pointer is pointed from the i^th pointing location, and s_i is an unknown distance to the target object. This defines a linear system of equations that can be solved via a conventional least squares procedure to find the mean location that best fits the data.

The covariance of the Gaussian blob representing the object being modeled is then established (process action 1522). This can be done in a number of ways. First, the covariance could be prescribed or user entered. However, in tested versions of the target training procedure, the covariance of the target object was computed by adding a minimum covariance to the spread of the intersection points, as follows:

Σ=Σ₀+(x_i+s_lw_l-μ)(x_l+s_lw_l-μ)^T  (7)


It is noted that the aforementioned computations do not take into account that the accuracy in pointing with the pointer is related to the angular error in the calculation of the device's orientation (and so in the ray w_i). Thus, a computed pointing location that is far away from the object being modeled is inherently more uncertain than a computed pointing location which is nearby the target. Accordingly, the foregoing target training procedure can be refined by discounting the more remote pointing location to some degree in defining the Gaussian blob representing an object being modeled. This can be accomplished using a weighted least squares approach, as follows:
##EQU4##

where W_i is the weight assigned to the i^th pointing location, ŝ_l is an estimate of the distance to the target object, possibly computed using the previous procedure employing the non-weighted least squares approach, c and η are parameters related to the angular error of the pointer, and I is the identity matrix. As before, Eq. (8) is generated for each pointing location to define a linear system of equations that can be solved via the least squares procedure to find the mean location that best fits the data, but this time taking into consideration the angular error associated with the computed orientation of the pointer.

It is noted that the foregoing procedures for computing the mean and covariance of a Gaussian blob representing an object allow the represented shape of the object to be modified by simply adding any number of pointing locations where the pointer is pointed along the body of the target object.

Once a Gaussian blob for each object of interest in the environment has been defined, and stored in the memory of the host computer, the pointer can be used to select an object by simply pointing at it. The user can then affect the object, as mentioned previously. However, first, the processes that allow a user to select a modeled object in the environment using the pointer will be described. These processes are preformed each time the host computer receives an orientation message from the pointer.

One simple technique for selecting a modeled object is to evaluate the Gaussian distribution at a point nearest the mean of each Gaussian representing an object of interest in the environment which is intersected by the a ray cast by the pointer, along that ray. The likelihood that the pointer is being pointed a modeled object i is then:

l_l=g(x+∥μ_l-x∥w,Σ_l)  (9)

where x is the position of the pointer (as represented by the IR LED), w is a ray extending from x in the direction the pointer is pointed, and g(μ,Σ) is the probability distribution function of the multivariate Gaussian. The object associated with the Gaussian blob exhibiting the highest probability l can then be designated as the selected object.

Another approach is to project each Gaussian onto a plane normal to either w or μ-x, and then to take the value of the resulting 2D Gaussian at the point where the ray w intersects the plane. This approach can be accomplished as follows. Referring to FIG. 16, the ray that projects through the environment from the pointer's location along the device's orientation direction, is established (process action 1600). In addition, a line is defined between the mean point of each of the Gaussian blobs and the pointer's location (process action 1602). Next, for each Gaussian blob a plane normal to the line between the blob mean and the pointer's location, or alternately a plane normal to the ray, is then defined (process action 1604). Each Gaussian blob is then projected onto the associated plane using standard methods, to define a 2D Gaussian (process action 1606). The aforementioned ray is also projected onto each of these planes (process action 1608). This projection may be a point if the ray is normal to the plane or a line if it is not normal to the plane. For each projected Gaussian, the likelihood that the pointer is being pointed at the associated object is computed based on how far the origin of the projected Gaussian is from the closest point of projected ray using standard methods (process action 1610). Essentially, the shorter the distance between the origin of the projected Gaussian and the closest point of projected ray, the higher the probability that the pointer is being pointed at the object associated with the Gaussian. Thus, in process action 1712, the Gaussian blob having the highest probability is identified. At this point the Gaussian blob associated with the highest probability could be designated as the selected object. However, this could result in the nearest object to the direction the user is pointing being selected, even though the user may not actually be intending to select it. To prevent this situation, a thresholding procedure can be performed. Referring to FIG. 16 once again, this thresholding procedure involves determining if the probability computed for the Gaussian blob identified as having the highest probability exceeds a prescribed threshold (process action 1614). If the computed probability exceeds the threshold, then the object associated with the Gaussian blob exhibiting the highest probability is designated as being the object the user is pointing at (process action 1616). The threshold will vary depending on the environment, but generally should be high enough to ensure an object is actually being pointed at and that the user is not just pointing at no particular object. In this way, the process does not just pick the nearest object. Thus, if it is determined the computed probability the Gaussian blob identified as having the highest probability does not exceed the prescribed threshold, then no object is selected and the procedure ends. The foregoing procedure is then repeated upon receipt of the next orientation message, as indicated previously. It is noted that the thresholding procedure can also be applied to the first technique for selecting a modeled object, if desired.

It is further noted that the calculation associated with the weighted least squares approach described above can be adopted to estimate the average angular error of the pointer without reference to any ground truth data. This could be useful for correcting the computed pointer orientation direction. If this were the case, then the simpler non-weighted least squares approach could be employed in the alternate target object training procedure, as well as making the object selection process more accurate. The average angular error estimation procedure requires that the pointer be modified by the addition of a laser pointer, which is attached so as to project a laser beam along the pointing direction of the pointer. The user points at the object with the pointer from a position in the environment within the line of sight of both cameras, and depresses the device's button, as was done in the alternate target object training procedure. In this case, this pointing procedure is repeated multiple times at different pointing locations with the user being careful to line up the laser on the same spot on the surface of the target object. This eliminates any error due to the user's pointing accuracy. The orientation and location of the pointer at each pointing location is computed using the procedures described previously. The average angular error is then computed as follows:
##EQU5##

wherein i refers to the pointing location in the environment, n refers to the total number of pointing locations, w is a ray originating at the location of the pointing device and extending in a direction defined by the orientation of the device, x is the location of the pointing device, and μ is the location of the mean of the Gaussian blob representing the target object

Without reference to ground truth position data, this estimate of error is a measure of the internal accuracy and repeatability of the pointer pointing and target object training procedures. This measure is believed to be more related to the overall performance of the pointer than to an estimate of the error in absolute position and orientation of the device, which is subject to, for instance, the calibration of the cameras to the environment's coordinate frame.

2.0 Gesture Recognition

As described above, the orientation and position of the pointer may be found by a combination of sensors and signal processing techniques. This allows an object, which is an electronic component controllable by a computer via a network connection or an extension thereof, to be selected based on a geometric model of the environment containing the object. The selection of a target object is accomplished by a user merely pointing at the object with the pointer for a moment.

Once the object is selected, the electronic device can be controlled by the user informing the computer in some manner of what he or she wants the device to do. As described above, this may be as simple as instructing the computer to turn the device on or off by activating a switch or button on the pointer. However, it is also desirable to control device in more complex ways than merely turning them on or off. Thus, the user must have some way of relaying the desired command to the computer. One such way is by having the user perform certain gestures with the pointer that the computer will recognize as particular commands. This can be accomplished in a variety of ways.

One approach involves matching a sequence of sensor values output by the pointer and recorded over a period of time, to stored prototype sequences each representing the output of one or more sensors that would be expected if the pointer were manipulated in a prescribed manner. This prescribed manner is the aforementioned gesture. The stored prototype sequences are generated in a training phase for each electronic component it is desired to control via gesturing. To account for the fact that a gesture made by a user during runtime may differ from the gesture performed to create the prototype sequence in terms of speed and amplitude, the aforementioned matching process can not only entail comparing a prototype sequence to the recorded sensor values but also comparing the recorded sensor values to various versions of the prototype that are scaled up and down in amplitude and/or warped in time (i.e., linearly stretched and contracted). The procedure used to generate each prototype sequence associated with a particular gesture is outlined in the flow diagram shown in FIG. 17. Specifically, the user initiates a gesture training mode of the electronic component control process running on the aforementioned host computer (process action 1700). The user then inputs the identity of the electronic component that is capable of being controlled by the host computer and specifies the particular control action that is to be associated with the gesture being taught to the control system (process action 1702). Next, the user activates the aforementioned button on the pointer and performs a unique gesture with the pointer, which the user desires to represent the previously specified control action for the identified component (process action 1704). Finally, the user deactivates (e.g., releases) the pointer's button when the gesture is complete (process action 1706). Meanwhile, the gesture training process causes periodic requests to be sent to the pointer directing it to provide orientation messages in the manner described previously (process action 1708). The process waits for an orientation message to be received (process action 1710), and upon receipt determines whether the switch state indicator included in the message indicates that the pointer's button is activated (process action 1712). If not, process actions 1710 and 1712 are repeated. When, it is discovered that the button state indicator indicates the button is activated, then in process action 1714, a portion of a prototype sequence is obtained by recording prescribed pointer sensor outputs taken from the last orientation message received. The process waits for the next orientation message to be received (process action 1716), and upon receipt determines whether the switch state indicator included in the message indicates that the pointer's switch is still activated (process action 1718). If so, process actions 1714 through 1718 are repeated. If, however, the switch state indicator included in the message indicates that the pointer's switch has been deactivated, then it is deemed that the gesture has been completed, and in process action 1720, the recorded values are designated as the prototype sequence representing the gesture being taught to the system (process action 1722). The foregoing procedure would be repeated for each control gesture it is desired to teach to the component control system and for each electronic component it is desired to control via gesturing.

During operation, the electronic component control system constantly monitors the incoming pointer orientation messages after an object associated with a controllable electronic component has been selected, to assess whether the user is performing a control gesture applicable to that component. This gesture recognition task is accomplished as follows. Referring to FIG. 18, particular sensor readings obtained from incoming orientation messages are first recorded for a prescribed period of time to create an input sequence (process action 1800). Next, assuming more than one control gesture has been taught to the control system for the electronic component under consideration, a previously unselected one of the prototype sequences representing the various gestures applicable to the electronic component is selected (process action 1802). If only one gesture was taught to the system for the electronic component under consideration, then the associated prototype sequence for that gesture is selected. A similarity indicator is then computed between the input sequence and the selected prototype sequence (process action 1804). The similarity indicator is a measure of the similarity between the input sequence and the prototype sequence. This measure of similarity can be defined in various conventional ways. In tested versions of the control system, the similarity indicator was computed as follows.

As mentioned above, the matching process can entail not only comparing a prototype sequence to the recorded sensor values but also comparing the recorded sensor values to various versions of the prototype that are scaled up and down in amplitude and/or warped in time. In tested versions, the amplitude scaling factors ranged from 0.8 to 1.8 in increments of 0.2, and the time warping factors ranged from 0.6 to 2.0 in increments of 0.2. However, while it is believed the aforementioned scaling and warping factors are adequate to cover any reasonable variation in the gesture associated with a prototype sequence, it is noted that different ranges and increments could be used to generate the scaling and warping factors as desired. In fact the increments do not even have to be equal across the range. In practice, the prototype sequence is scaled up or down in amplitude by applying scaling factors to each value in the prototype sequence. Whereas, the prototype sequence is warped in time by applying warping factors that expand or contract the overall sequence in time.

Essentially, a list is established before initiating the matching process which includes every combination of the scaling and warping factors possible, includes the case where one or both of the scaling and warping factors are zero. Note that the instance where both the scaling and warping factors are zero corresponds to the case where the prototype sequence is unmodified. Given this prescribed list, and referring now to FIG. 19, a previously unselected scaling and warping factor combination is selected (process action 1900). Next, in process action 1902, the prototype sequence is scaled in amplitude and/or warped in time using the selected factor combination to produce a current version of the selected prototype sequence (which may be the prototype sequence itself if the selected factor combination is zero scaling and zero warping). A so called "match score" is computed between corresponding time steps of the input sequence and the current version of the prototype sequence using a standard Euclidean distance technique (process action 1904). A time step refers to the prescribed sensor value or values taken from the same pointer orientation message—i.e., the value(s) captured at the same time by the pointer. Correspondence between time steps refers to computing the match score between the sensor values associated with the first time step in both sequences, then the second, and so on until the last time step of the current version of the prototype sequence is reached. Once all the match scores have been computed they are summed and divided by the number of time steps involved, thereby producing an average match score (process action 1906). Thus, the average match score ƒ(p_i(w,s),x) based on the aforementioned Euclidean distance function ƒ can be computed as follows:
##EQU6##

for selected warp w and scale s, where p_l(w,s,t) is the recorded sensor value(s) at time step t of the current version of the selected prototype sequence i, x(t) refers to the corresponding sensor values of the input sequence at time step t, and n refers to the length of the current version of the selected prototype sequence p_i(w,s) and so the length of x as well, The foregoing process is then repeated for every other combination of the warp and scale factors.

Specifically, it is determined if all the warp and scale factor combinations from the prescribed list have been selected (process action 1908). If not, the process actions 1900 through 1908 are repeated. Once an average match score has been computed for every version of the prototype sequence (including the unmodified sequence), the maximum averaged match score is identified (process action 1910). This maximum averaged match score is the aforementioned similarity indicator for the selected prototype sequence.

Referring once again to FIG. 18, the similarity indicator is then computed for each remaining prototype sequence by first determining if there are any remaining unselected prototype sequences (process action 1806). If so, then process actions 1802 through 1806 are repeated. When a similarity indicator has been computed for every prototype sequence, it is next determined which of the similarity indicators is the largest (process action 1808). The prototype sequence associated with the largest similarity indicator is designated as the best match to the input sequence (process action 1810). The gesture associated with the designated prototype sequence is the most likely of the gestures the system has been trained for to match the pointer movements as represented by the input sequence. However unless the similarity is great enough, it might just be that the pointer movements are random and do not match any of the trained gestures. This situation is handled by ascertaining if the similarity indicator of the designated prototype sequence exceeds a prescribed similarity threshold (process action 1812). If the similarity indicator exceeds the threshold, then it is deemed that the user has performed the gesture associated with that designated prototype sequence. As such, the gesture is identified (process action 1814), and the control action associat