University of Southern California Dissertations and Theses

The task matrix: a robot-independent framework for programming humanoids

(USC Thesis Other)

The task matrix: a robot-independent framework for programming humanoids

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content THE TASK MATRIX: A ROBOT-INDEPENDENT FRAMEWORK FOR
PROGRAMMING HUMANOIDS
by
Evan Drumwright
A Dissertation Presented to the
FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF PHILOSOPHY
(COMPUTER SCIENCE)
August 2007
Copyright 2007 Evan Drumwright
Dedication
It is humbling to think of all the people that helped me get here. As Newton said, “If
I have seen farther, it is by standing on the shoulders of giants.” I would first like to
thank my wife Suzanne, who has provided more support to me than I ever could have
imagined that I would need. Suzanne: thank you for keeping my spirits high, my belly
full, and my thoughts pure though seven years of graduate school. My entire family,
particularly my father, has been a never ending well of strength for me too, and I thank
them for that.
I truly appreciate my labmates at USC. I could not have wished for a better envi-
ronment to spend six years! I wish to thank all of my labmates for their inspiration. In
particular, I want to single out Dylan Shell, who has been not only a wonderful source of
discussion, dissent, and reference, but also a great friend. I would be remiss if I did not
thank Kale, Gabe, Sri, Andre, Dave, Boyoon, Marin, Nate, Khartik, Maxim, Jun, Peter,
Stefan, Amit, Chad, Monica, and Chris– ordering unindicative– for all of the volleyball,
ping pong, surfing, and Tekken, as well as for the technical assistance, good company,
and lively discussions. You guys made life in L.A. worth living.
I would also like to thank my advisor, Maja Matari´ c, who cast me out into the world
of research and forced me to find my direction. Maja was very patient while I peram-
bulated around the landscape of robotics, and I thank her for that. I also must thank
Stefan Schaal, for being one of the knowledgable and entertaining lecturers at USC, as
ii
well as for providing immense technical assistance and for being a paragon of scientific
investigator.
iii
Epigraph
Success is going from failure to failure without loss of enthusiasm.
– Winston Churchill
iv
Table of Contents
Dedication ii
Epigraph iv
List of Tables viii
List of Figures ix
Abstract xvii
1 Introduction 1
1.1 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Related Work 6
2.1 Robot programming systems . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Manual programming . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Task-level programming . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Programming by demonstration . . . . . . . . . . . . . . . . . 10
2.2 Complex behaviors from primitives for manipulators and humanoids . . 12
2.2.1 PaT-Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Coste-Mani` ere, Espia, and Rutten . . . . . . . . . . . . . . . . 13
2.2.3 Jenkins and Matari´ c . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.4 Hierarchical reinforcement learning . . . . . . . . . . . . . . . 13
2.3 Behavior fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Robot independent programming . . . . . . . . . . . . . . . . . . . . . 17
2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 The Task Matrix 20
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Common skill set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 The perceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
v
3.4.2 Implemented conditions . . . . . . . . . . . . . . . . . . . . . 32
3.5 Task behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5.2 Complex task behaviors . . . . . . . . . . . . . . . . . . . . . 37
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Task Programs 40
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Movement notation and work measurement systems . . . . . . . . . . . 40
4.2.1 Movement notation . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.2 Work measurement systems . . . . . . . . . . . . . . . . . . . 42
4.3 Primitive task behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Reach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2 Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.3 Grasp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.4 Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.5 Fixate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.6 Explore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.7 Postural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.8 Canned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5 Validation 68
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3 Robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.1 Asimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3.2 Mannequin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.3 Bandit II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4 Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5 Common skill set implementation . . . . . . . . . . . . . . . . . . . . 76
5.5.1 Locomotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5.2 Motion control . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5.3 Motion planning (configuration space to configuration space) . . 79
5.5.4 Motion planning (configuration space to operational space) . . . 81
5.5.5 Collision checking . . . . . . . . . . . . . . . . . . . . . . . . 83
5.5.6 Inverse kinematics . . . . . . . . . . . . . . . . . . . . . . . . 85
5.5.7 Grasp configuration . . . . . . . . . . . . . . . . . . . . . . . . 85
5.6 Validated primitive task behaviors . . . . . . . . . . . . . . . . . . . . 85
5.6.1 Reach / Position . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.6.2 Grasp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.6.3 Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
vi
5.6.4 Fixate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.6.5 Explore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.6.6 Postural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.6.7 Canned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.7 Developed complex task behaviors . . . . . . . . . . . . . . . . . . . . 94
5.7.1 Pickup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7.2 Putdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.7.3 Greet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.7.4 Vacuum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6 Future work 120
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.2 Validation on physically embodied humanoids . . . . . . . . . . . . . . 120
6.3 Interaction control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.4 Simultaneous behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.5 The space of physical tasks . . . . . . . . . . . . . . . . . . . . . . . . 124
6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Bibliography 126
A Motion and posture encoding 135
vii
List of Tables
2.1 A comparison of the features of the methods discussed in this chap-
ter with those of the Task Matrix. indicates that the feature has been
implemented, indicates that the feature has been partially implemented,
and indicates that the feature has not been implemented. . . . . . . . 18
3.1 The list of messages that may be sent by task behaviors in the Task Matrix 35
4.1 The list of primitive elements of MTM and whether or not they are
implemented by the task behaviors in this chapter. indicates that the
element is fully implemented, indicates that the element is partially
implemented, and indicates that the element is not implemented.

means that the element is implemented indirectly via a skill in the com-
mon skill set or another task behavior, or both. . . . . . . . . . . . . . . 50
viii
List of Figures
3.1 The interaction between components in the Task Matrix. Arrows indi-
cate the direction of data flow. . . . . . . . . . . . . . . . . . . . . . . 21
3.2 A depiction of the interaction between robot behaviors and the com-
mon skill set that leads to portable behaviors. This diagram indicates
that the robot behavior neither queries nor commands the robot directly,
nor does it have a priori knowledge of the robot’s degrees-of-freedom.
The behavior is able to make queries and send commands at run-time
only via the skill layer. Note that locomotion is provided by the skill
layer, but cannot be called directly by the task behaviors; it can only be
called by sending joint-space commands to the translational and rota-
tional degrees-of-freedom of the base. . . . . . . . . . . . . . . . . . . 25
3.3 The MDM for performing the Pick-and-place task. Parameters are rep-
resented by the shaded boxes. Transitions are indicated by lines with
arrows. Boolean conditions are in unaccented text, messages are in ital-
icized text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 The MTM atomic element reach (with search and select) . . . . . . . . 44
4.2 The MTM atomic element move . . . . . . . . . . . . . . . . . . . . . 45
4.3 The MTM atomic element turn and apply pressure . . . . . . . . . . . 45
4.4 The MTM atomic element position . . . . . . . . . . . . . . . . . . . . 47
4.5 A depiction of the reach task behavior in action. This figure shows the
process of reaching to a broom in a simulated real-world environment
in a collision-free manner. . . . . . . . . . . . . . . . . . . . . . . . . 52
4.6 Using the position behavior to move a tennis ball over the table . . . . . 53
4.7 Before and after pictures of using grasp to clutch a broom . . . . . . . 55
ix
4.8 Depiction of using the grasp behavior to clutch a tennis ball . . . . . . 56
4.9 Using release to relinquish the grip on the vacuum . . . . . . . . . . . 57
4.10 The determination of and for the function in Section 4.3.5. (b)
depicts the robot and the target, a tennis ball; the frame of the robot’s
current view is displayed in black and the desired view (that allows fixat-
ing on the target) is displayed in red. (a) shows the sequence of rotations
necessary (first a “yaw” of radians, followed by a pitch of radians)
to get from the current frame to the desired frame. . . . . . . . . . . . . 59
4.11 Depiction of the action of the fixate behavior; the simulated robot is
commanded to focus on the dustbuster. The robot turns on its base while
simultaneously orienting its head. . . . . . . . . . . . . . . . . . . . . 61
4.12 The random walk state machine. The state machine executes for the
specified duration. Solid lines indicate nominal transitions; dotted lines
indicate transitions due to failure. For example, if the robot fails to move
forward, it will then attempt to move backward. Failure occurs when a
behavior would cause collision with the environment or result in the
robot moving outside of the desired exploration region. . . . . . . . . . 62
4.13 A sample run of the explore behavior using the simulated depth sensor.
As the depth sensor (depicted by the red polyhedral outline protruding
from the robot’s head) scans a surface, a brown texture is drawn over
the surface; this brown texture represents the robot’s model of the envi-
ronment for use with collision detection. Note that the frames are not
sampled from the animation at uniform intervals. . . . . . . . . . . . . 63
4.14 Using the postural behavior to prepare the simulated robot for waving . 65
4.15 Utilizing an aperiodic-canned behavior to get the simulated robot to wave 67
5.1 View of the sparse environment. The environment contains a hand vac-
uum, broom, soda can (on table), and confetti (on table, not visible in
image). The robot testbeds are confined to the portion of the environ-
ment represented by the gray plane. . . . . . . . . . . . . . . . . . . . 69
x
5.2 “Bird’s eye view” of the dense environment for kinematically simulated
robots. The environment contains a washing machine, dryer, and box
of detergent (far left); couch; clothes (bottom, left of center); stove and
broom (bottom, right of center); table and stool (top right); sink, coffee
maker, and refrigerator (bottom right). Additionally, door entry ways
are present throughout. The robot testbeds are confined to the portion of
the environment represented by the textured ground. . . . . . . . . . . . 70
5.3 The dense environment for the dynamically simulated Bandit robot. The
environment contains a washing machine, dryer, couch, stove, table
(with tennis ball), stool, television, sink, and refrigerator. The Bandit
robot is confined to the portion of the environment represented by the
textured ground. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4 The specifications of the kinematically simulated robots utilized in the
validation; Asimo is on the left, the mannequin is on the right. Asimo
is 1.24m tall and consists of 26 degrees-of-freedom (plus the 3 DOF
virtual base); the mannequin is 1.48m tall and consists of 27 DOF and
the 3 DOF virtual base. . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.5 The specifications of the dynamically simulated Bandit II robot. Bandit
is 1.75m tall with 51 DOF; although the base is theoretically uncon-
strained (i.e., six DOF), gravity and a virtual counterweight effectively
constrain the base to three DOF. . . . . . . . . . . . . . . . . . . . . . 73
5.6 The physically embodied Bandit II robot, upon which the two dynami-
cally simulated robots are based. . . . . . . . . . . . . . . . . . . . . . 74
5.7 Depiction of controller performance (joint position) for a single DOF in
a shoulder joint of Bandit II for execution of a periodic canned task over
nine seconds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.8 Depiction of controller performance (joint velocity) for a single DOF in
a shoulder joint of Bandit II for execution of a periodic canned task over
nine seconds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.9 Depiction of controller performance (joint acceleration) for a single DOF
in a shoulder joint of Bandit II for execution of a periodic canned task
over nine seconds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.10 Depiction of controller performance (joint position) for a single DOF in
a shoulder joint of Bandit II for execution of a postural task over one
second. This plot depicts the results of applying the torques from Figure
5.13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
xi
5.11 Depiction of controller performance (joint velocity) for a single DOF in
a shoulder joint of Bandit II for execution of a postural task over one
second. This plot depicts the results of applying the torques from Figure
5.13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.12 Depiction of controller performance (joint acceleration) for a single DOF
in a shoulder joint of Bandit II for execution of a postural task over one
second. This plot depicts the results of applying the torques from Figure
5.13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.13 Depiction of torque commands for a single DOF in a shoulder joint of
Bandit II for execution of a postural task over one second; the results of
applying these torques can be seen in Figures 5.10–5.12. Contributions
from computed torque as well as error feedback (proportional, deriva-
tive, and integrative terms) are plotted, as well as the composite con-
troller. The computed torque component is responsible for the majority
of controller output, as feedback torque magnitudes are close to zero. . . 84
5.14 The result of running the reach behavior on the simulated Asimo robot
on three different targets: (a) a hand vacuum, (b) a tennis ball, and (c) a
broom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.15 The result of running the reach behavior on the simulated mannequin
robot on three different targets: (a) a hand vacuum, (b) a tennis ball, and
(c) a broom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.16 The result of running the reach behavior on the simulated Bandit II robot
on the tennis ball target. . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.17 “Bird’s eye view” of Asimo (a) and the mannequin (b) reaching to a
broom in a simulated environment. This task requires locomotion as
well as navigation through an obstacle-ridden environment. . . . . . . . 88
5.18 The Bandit II robot reaching to a tennis ball in a simulated environment. 89
5.19 A sequence of reaches on the simulated Asimo to the tennis ball, which
is moved interactively. This picture demonstrates the ability of reach to
attain targets in various locations with different obstacle configurations. 90
5.20 A sequence of reaches on the mannequin to the tennis ball, which is
moved interactively. This picture demonstrates the ability of reach to
attain targets in various locations with different obstacle configurations. 91
5.21 Successive frames depicting the execution of the fixate behavior on the
mannequin (target object is the hand vacuum). . . . . . . . . . . . . . . 96
xii
5.22 Successive frames depicting the execution of the fixate behavior on the
mannequin (target is Asimo walking in a “figure eight” pattern). Note
that an omniscient sensing model is used (rather than the simulated
depth sensor) for simplicity. . . . . . . . . . . . . . . . . . . . . . . . 97
5.23 Successive frames depicting the execution of the fixate behavior on Asimo
(target is the rolling tennis ball); the first frame depicts the state before
the behavior is executed. Note that Asimo is not able to look fully down-
ward at the tennis ball; for this reason, an omniscient sensing model is
used (rather than the simulated depth sensor). . . . . . . . . . . . . . . 98
5.24 Successive frames depicting the execution of the fixate behavior on Ban-
dit II (target is the tennis ball). . . . . . . . . . . . . . . . . . . . . . . 98
5.25 Successive frames depicting the execution of the fixate behavior on the
mannequin (target is the rolling tennis ball); the first frame depicts the
state before the behavior is executed. As the caption in Figure 5.23
notes, Asimo is not able to look fully downward at the tennis ball, so
an omniscient sensing model is used (rather than the simulated depth
sensor). The same omniscient sensing model is used in this example for
consistency even though the mannequin is capable of looking directly at
the tennis ball. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.26 Depiction of one form of robustness of the fixate behavior; as the simu-
lated robot attempts to turn, impending collision with the table halts the
behavior immediately before contact would occur. . . . . . . . . . . . . 100
5.27 Bandit II grasping a tennis ball. . . . . . . . . . . . . . . . . . . . . . . 101
5.28 Bandit II releasing a tennis ball. . . . . . . . . . . . . . . . . . . . . . 101
5.29 Successive samples taken from one run of the explore behavior using
the simulated depth sensor. As the depth sensor scans a surface (except
the floor), a brown texture is drawn over the surface; this brown texture
represents the robot’s model of the environment within the perceptual
model. Note that the frames are not sampled from the animation at
uniform intervals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.30 Images taken from the explore behavior executed on Asimo in the dense
environment at one minute (a), five minutes (b), and fifteen minutes (c).
The maximum range on the depth sensor was temporarily increased to
3m for better performance. . . . . . . . . . . . . . . . . . . . . . . . . 103
xiii
5.31 Images taken from the explore behavior executed on the mannequin in
the dense environment at one minute (a), five minutes (b), and fifteen
minutes(c). In contrast to Figure 5.30, the depth sensor has a maxi-
mum range of 1.5m; additionally, the octree visualization is coarser to
decrease memory usage. . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.32 Using the postural behavior to prepare the mannequin for waving . . . . 105
5.33 Using the postural behavior to prepare the Bandit II robot for waving. . 105
5.34 Using a postural behavior to prepare a kinematically simulated robot for
waving; an obstacle has been added in this case, for which the behavior
uses motion-planning to deftly avoid. . . . . . . . . . . . . . . . . . . . 106
5.35 The waving task behavior executed on both the Asimo and mannequin
simulated robot platforms . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.36 The waving task behavior executed on the simulated Bandit II robot
platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.37 Samples taken from Asimo performing the pickup behavior. (a) depicts
before execution begins. (b) depicts the first phase, for which fixate
focuses on the target (the vacuum). (c) depicts reaching to the vacuum
(using reach). (d) depicts grasping the vacuum using grasp. Note that
Asimo continues to fixate upon the vacuum during the entire movement. 108
5.38 Samples taken from the mannequin performing the pickup behavior. (a)
depicts before execution begins. (b) depicts the first phase, for which
fixate focuses on the target (the vacuum). (c) and (d) depict reaching
to the vacuum (using reach). The behavior of the grasp behavior is not
observable on the mannequin. Note that the mannequin continues to
fixate upon the vacuum during the entire movement. . . . . . . . . . . . 109
5.39 Depiction of the message-driven machine used to realize the pickup
task behavior. Black arrows indicate transitions that cause states to be
started. Red arrows indicate transitions that cause states to be forcibly
terminated. The green boxes represent parameters that are passed to the
primitive subtasks. The state with a double outline (e.g., the grasp state)
indicates the final state for the machine. . . . . . . . . . . . . . . . . . 110
xiv
5.40 Depiction of the message-driven machine used to realize the putdown
task behavior. Black arrows indicate transitions that cause states to be
started. Red arrows indicate transitions that cause states to be forcibly
terminated. The green boxes represent parameters that are passed to the
primitive subtasks. The state with a double outline (e.g., the release
state) indicates the final state for the machine. . . . . . . . . . . . . . . 111
5.41 Samples taken from Asimo performing the putdown behavior. (a) depicts
before execution begins. (b) depicts the first phase, for which fixate
focuses on the target surface (the table). (c) depicts positioning the vac-
uum (using position). (d) depicts releasing the vacuum using release.
Note that Asimo continues to fixate upon the table during the entire
movement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.42 Samples taken from the mannequin performing the putdown behavior.
(a) depicts before execution begins. (b) depicts the first phase, for which
fixate focuses on the target surface (the table). (c) and (d) depict posi-
tioning the vacuum (using position). The behavior of the release behav-
ior is not observable on the mannequin. Note that the mannequin con-
tinues to fixate upon the table during the entire movement. . . . . . . . 113
5.43 Depiction of the message-driven machine used to realize the greet task
behavior. Black arrows indicate transitions that cause states to be started.
Red arrows indicate transitions that cause states to be forcibly termi-
nated. The green boxes represent parameters that are passed to the prim-
itive subtasks. The state with a double outline (e.g., the go-rest-posture
state) indicates the final state for the machine. . . . . . . . . . . . . . . 114
5.44 Samples of depicted execution of the greet macro behavior run on the
simulated Asimo (the target is another simulated Asimo). An omni-
scient sensing model is used in place of the simulated camera for sim-
plicity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.45 Samples of depicted execution of the greet macro behavior run on the
mannequin (the target is a simulated Asimo). An omniscient sensing
model is used in place of the simulated camera for simplicity. . . . . . . 116
5.46 Depiction of the message-driven machine used to realize the vacuum
task behavior. Black arrows indicate transitions that cause states to be
started. Red arrows indicate transitions that cause states to be forcibly
terminated. The green boxes represent parameters that are passed to the
primitive subtasks. The state with a double outline (e.g., the putdown
state) indicates the final state for the machine. . . . . . . . . . . . . . . 117
xv
5.47 Samples taken from Asimo performing the vacuum behavior. (a)–(c)
depict the position behavior moving the vacuum tip over the debris. (d)
depicts the vacuum on the table, having just been put there and released
using putdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.48 Samples taken from the mannequin performing the vacuum behavior.
(a)–(c) depict the position behavior moving the vacuum tip over the
debris. (d) depicts the vacuum on the table, having just been put there
and released using putdown. . . . . . . . . . . . . . . . . . . . . . . . 119
A.1 The XML document describing the wave posture for Asimo. . . . . . . 136
A.2 The XML document describing the wave posture for the mannequin. . . 137
A.3 The XML document describing the wave posture for the Bandit II model. 138
A.4 The XML document describing the wave trajectories for Asimo. . . . . 139
A.5 The XML document describing the wave trajectories for the mannequin. 140
A.6 The XML document describing the wave trajectories for the Bandit II
model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
xvi
Abstract
The present state of designing behaviors for humanoid robots can be viewed as analo-
gous to programming a computer using machine language. Even when such complex
issues as interaction control and locomotion can be bypassed, programming generally
is still pursued in a highly robot-dependent manner. Though roboticists currently use
sophisticated tools like human motion capture systems to assist with behavior design,
a core tenet of software development– component reuse– is frequently overlooked. As
a result, a behavior that allows a robot to perform a task will often fail on a different
robot, even if the kinematic and dynamic properties between the two robots are highly
similar. This problem prevents software reuse and, by extension, limits development of
high-level humanoid behaviors for performing a broad range of tasks.
This dissertation aims to address the above limitations in the state-of-the-art by first
separating humanoid tasks into robot-dependent and robot-independent components,
thereby facilitating component reuse, and then identifying and implementing a set of
primitive task programs for a humanoid robot that, when executed sequentially and con-
currently, allow a broad range of humanoid tasks to be performed.
This dissertation presents a framework for integrating a library of performable task
behaviors that are portable across many humanoid robots with little or no modification.
The framework, called the Task Matrix, provides an application-programming interface
(API) to program humanoid robots in an abstract manner; the robot-specific components
xvii
lie in the implementation of the API. The Task Matrix describes formally how tasks can
interact, both in sequence and concurrence. This specification permits complex behav-
iors to be constructed from a small vocabulary of primitive task behaviors. Such a
vocabulary is provided and is applied toward implementing a set of behaviors for exe-
cuting human occupational tasks. This work is validated on three simulated humanoid
robots by performing both the primitive behaviors in various circumstances and complex
behaviors composed of the primitives.
The contributions of this dissertation are the Task Matrix framework and the set
of primitive task programs. It is hoped that roboticists can use these contributions to
facilitate performance of occupational tasks on various humanoid robots with minimal
effort.
xviii
Chapter 1
Introduction
Controlling humanoid robots is a very challenging endeavor. The roboticist must man-
age kinematics, dynamics, locomotion, and the application of forces to the environment;
these challenges supplement those presented by programming mobile robots, including
sensor fusion, environmental mapping, and object recognition. Also problematic, how-
ever, is the fact that most humanoid robot behaviors are tied strongly to the robot plat-
form on which they are developed. Additionally, there often exists no formal method to
“port” a behavior written for one humanoid robot to another. This problem exists even
if the differences between the two robots are minimal (e.g., there is a slight difference in
kinematics, but the dynamic properties of the robots are highly similar). The portability
issue prevents the construction of libraries of robot behaviors to complement the evolv-
ing physical designs of humanoids robots; programs to perform behaviors are typically
rewritten for each new robot design.
This dissertation makes two contributions toward ameliorating the problems listed
above. First, a framework is introduced for developing robot-independent humanoid
behaviors. This framework treats humanoid robots abstractly so that behaviors written
within the framework function on multiple robot platforms. Second, a set of behaviors
is provided that has been developed within this framework. These behaviors are based
on a well-established model of human task decomposition and enable the performance
of occupational tasks on various robot platforms.
The framework introduced above is called the Task Matrix: the term matrix refers to
an environment in which something develops rather than a mathematical table. The Task
1
Matrix is a substrate for developing robot-independent primitive behaviors that utilize
motion-control [SS00] and for constructing complex behaviors from these primitives.
Four heterogeneous components comprise the Task Matrix: the common skill set, the
perceptual model, conditions, and task behaviors. By utilizing these four components, it
is straightforward to command humanoid robots to perform tasks using the Task Matrix
framework.
The robot programmer utilizes two of the components described above, the com-
mon skill set and the perceptual model, to control the robot and query the environment,
respectively. These components allow the robot’s actuators and sensors to be treated
abstractly. Conditions utilize the perceptual model to symbolically label the state of
the environment. These symbolic labels serve to determine when tasks may begin or
continue execution; additionally, the set of states corresponding to a symbolic condition
can be computed to parameterize the execution of a task. The task behaviors are the
core of the Task Matrix and permit humanoids to be controlled in a robot-independent
manner. Each behavior controls some subset of the kinematic chains of the humanoid;
multiple behaviors can be performed concurrently if the set of chains utilized by each
task program is mutually exclusive. The execution of multiple behaviors in sequence
and concurrence allows robots utilizing the Task Matrix to generate complex action.
A set of robot-independent primitive task behaviors is also presented within this
dissertation. These behaviors are inspired from a well-studied system for measuring
occupational task performance times that functions by decomposing tasks into primitive
elements. Many of the primitive tasks derived from this system (e.g., reach, grasp,
and release) are recognizable to roboticists. This dissertation not only demonstrates
programs for performing these tasks, but also employs these programs to develop more
complex behaviors. Both the primitive and complex task programs are evaluated on
three simulated humanoid robot platforms.
2
The framework presented in this dissertation is principally limited in two ways.
The first limitation is that the task programs must be performable using the motion-
control paradigm [SS00]; interaction control [SS00] is not supported. This is not a
limitation intrinsic to the Task Matrix framework; rather, interaction control is a com-
plex domain encompassing stiffness control [Gro72], hybrid control [Ino71], impedance
control [Hog85], and Khatib’s operational space control [Kha87], to name just a few
models of interaction control, and the Task Matrix has not been extended to handle this
paradigm. As a consequence of lacking the ability to handle interaction control, the set
of implemented primitive task programs is only a subset of the primitive elements of the
work measurement system mentioned above; programs for tasks that are best performed
with interaction control have not been developed.
The second limitation of the Task Matrix framework lies within its method for man-
aging multiple simultaneous behaviors. The Task Matrix requires that all behaviors
assume exclusive control of some set of the robot’s degrees-of-freedom. This model of
exclusive control falls under the arbitration action-selection mechanism (ASM) [Pir99]
(in contrast to the command fusion ASM [Pir99]). A manifest limitation of using the
arbitration ASM on humanoid robots is that task programs are often forced to secure
more actuators than are necessarily utilized; for example, a reaching program must keep
the robot’s base stationary to keep from invalidating determined collision-free motion
plans. A less obvious limitation is that behaviors must treat uncontrolled degrees-of-
freedom as moving obstacles because the behaviors are independent and provide no
means to communicate their intentions.
In practice, both limitations were inconsequential to the tasks demonstrated within
this dissertation on simulated robots. Nevertheless, both issues are discussed further in
Chapter 6.
3
In addition to the limitations noted above, this dissertation ignores the issue of homi-
nine movement; rather, performing tasks is the focus of the research in this document.
Human-like movement is certainly desirable, given that humanoid robots possess human
morphology. A significant body of research exists toward the goal of modeling human
movement in the computer graphics, biomechanics, neuroscience, and robotics com-
munities; [AIL85, HW98, Sch01, FvT01, CGC
+
04, JM04, LHP05] are indicative of
the state-of-the-art in modeling human movement. Incorporating these models into the
behaviors in the Task Matrix framework is challenging. Key robotics functions such
as inverse kinematics and motion planning that are utilized by the Task Matrix can be
modified to accommodate these models. However, there is no guarantee that complex
behaviors composed of primitives will appear hominine: performing tasks in a human-
like manner is somewhat a gestalt process. Consequently, this dissertation concentrates
on utilizing the hyper-redundancy of humanoid robots to perform multiple tasks simul-
taneously instead of employing redundant degrees-of-freedom to achieve human-like
motion.
1.1 Outline
The remainder of this document is organized as follows:
Chapter 2 discusses work related to the novel research described in this proposal.
Chapter 3 introduces the Task Matrix and describes its set of four heterogeneous
elements: the common skill set, the perceptual model, conditions, and task behav-
iors.
Chapter 4 presents a set of primitive task behaviors for performing motion-
controlled humanoid tasks in a robot independent manner.
4
Chapter 5 uses three simulated robot platforms to validate the primitive task
behaviors and demonstrates how these behaviors are combined to develop com-
plex task behaviors.
Chapter 6 discusses future extensions to the research in this dissertation.
5
Chapter 2
Related Work
This chapter surveys work related to this dissertation. The chapter is subdivided into four
sections: robot programming systems, complex behaviors from primitives for manipu-
lators and humanoids, behavior fusion for humanoids, and robot-independent program-
ming. A large body of research has been conducted on robot programming, producing
complex behaviors from primitives, and fusion of behaviors. This chapter focuses on the
application of these topics to humanoid robots to treat the subjects in a tractable manner.
2.1 Robot programming systems
There are multiple means to program robots, resulting from the complexities involved in
robot programming, the vast number of platforms (including mobile robots, manipula-
tors, and humanoids), and the different environmental conditions (i.e., known/unknown,
accessible/inaccessible, static/dynamic, etc.). This section discusses three ways of pro-
gramming robots– manual programming, task-level programming, and programming by
demonstration– that are relevant to the Task Matrix framework.
2.1.1 Manual programming
Manual programming of robots can be achieved by using a robot programming language
(typically for manipulators), a synchronous programming language (typically for mobile
robots), or a control architecture (typically for mobile robots). The first language type,
of which V AL II [SGS84] and AML [TSM82] are examples, require the user to specify
6
every detail of the manipulator’s actions and sensory interaction. Thus, these languages
are most useful for programming industrial robots, for which the environment is static
and tasks vary little. For dynamic environments and variable tasks, such languages are
cumbersome to use.
Synchronous programming languages are languages for programming “reactive sys-
tems”, which were defined by Berry [Ber98] as those systems for which the computer’s
“role is to react to external stimuli by producing appropriate inputs in a timely way,
the leader of the interaction being the environment.” Thus, synchronous languages are
suitable for programming robots in dynamic environments. Prominent synchronous pro-
gramming languages include Esterel [Ber98], LUSTRE [HCRP91] and Argos [Mar91].
These languages are suited toward programming control of various real-time systems
and permit multiple threads of control to execute concurrently. Additionally, researchers
have developed several synchronous languages for control of mobile robots. Such lan-
guages include RAPs [Fir89], TCA [Sim94], PRS [GL87], ESL [Gat96], and Mae-
stro [CMS00]. Both general purpose and robot-specific synchronous programming lan-
guages often share many common constructs useful for programming real-time systems
including exception handling (failure recovery), monitors (devices that test for a con-
dition and takes an action if the condition holds), and synchronization points (a given
point where different threads must wait until a certain number of threads have reached
it).
Control architectures are used to manage multiple concurrently running behaviors
(i.e., programs). Though these architectures do not provide the sophisticated constructs
of synchronous programming languages, they can be adept at governing multiple behav-
iors running both reactively and non-interactively (i.e., for planning). Each behavior is
typically coded in a procedural language, like C or LISP. For mobile robots, some of
the noteworthy architectures are Subsumption [Bro86], SSS [Con92], AuRA [AB97],
7
and behavior-based [Ark98]; these architectures allow mobile robots to navigate around
environments while simultaneously avoiding obstacles, for example. Control architec-
tures for managing concurrently running behaviors have been relatively ignored for
humanoid robots. The requirement that humanoid behaviors be cognizant of dynam-
ics makes running several behaviors simultaneously quite difficult; this requirement is
not present for mobile robots, which generally can ignore dynamics.
The Task Matrix, introduced in the next chapter, acts as a synchronous programming
language to develop complex behaviors from primitives; this “language” exists not in
the form of procedural statements, but as a series of interconnections between primitive
behaviors described in Chapter 3. The synchronous languages mentioned above typi-
cally contain more capabilities than the macro task behavior mechanism for building
complex behaviors in the Task Matrix framework. This mechanism does not support
monitors, synchronization points, or branching or looping constructs; however, macro
behaviors do provide for exception handling. The remaining features can be readily
added to the Task Matrix while retaining backward compability with previously devel-
oped macro task behaviors.
The Task Matrix does not actively manage running behaviors like a control architec-
ture. Instead, each task behavior runs on a mutually exclusive subset of a humanoid’s
kinematic chains. Additionally, task behaviors in the Task Matrix are generally uncon-
cerned with managing dynamics, in contrast to the approach of Faloutsos et al. [FvT01];
the behaviors can assume the existence of robot skills for balancing and locomotion.
This assumption leads to considerable simplification, because fusing of behaviors that
utilize robot dynamics can be ignored.
8
2.1.2 Task-level programming
Task-level programming systems allow the user to specify subgoals of a task to be
accomplished and permit the user to remain mostly ignorant of the low-level actions
that effect those tasks. For example, a user could specify that a pin should be placed
in a hole rather than specifying the robot movements necessary to perform the insertion
[LP82]. Once the user specifies the goal, a planning system formulates a plan to reach
that goal.
Within task level programming, symbolic representations of states and actions are
used to account for uncertainty and variability. For example, states can be expressed
using symbols like aligned, against, and near-to, and actions can be expressed using
symbols like move-to, grasp-object, and move-above [LP82, LS84, Sch99]. These sym-
bolic state and action representations are akin to the Boolean conditions and task pro-
grams, respectively, presented in the next chapter.
Research into task-level programming has tended to focus on using task-level behav-
iors to plan sequences for performing complex tasks [LPJMO89, LP82, Nar94, Seg88,
Che05]. Specifically, such research has attempted to circumvent the EXP-hard and
PSPACE-complete complexities of planning under uncertainty [Nar94] or to ascertain
how to ignore extraneous data in constructing plans from observed task executions
[Seg88, Che05]. Subsequently, research into “good” sets of state and action symbols
for robotics has been relatively overlooked; researchers (e.g., [LP82, Seg88]) tend to
propose new sets of symbols in an ad hoc manner.
Although one of the promises of task-level programming is to approach robot pro-
gramming in a platform-independent manner, roboticists have paid little attention to this
capacity. Researchers typically treat the underlying robot in an abstract manner; sub-
sequently, such research is not grounded to either physical or simulated robots. For
9
example, Segre [Seg88] did not utilize a robot within his experiments. In contrast,
Lozano-P´ erez [LP82] intended that that the output of his system be a sequence of state-
ments in a robot programming language (see Section 2.1.1); however, this output is
obviously quite robot-specific. Alternatively, task-level programming systems may be
coupled too tightly to a specific platform when using a robot to perform experiments;
for example, Lozano-P´ erez’s task-level program [LPJMO89] for Pick-and-place tasks
assumed that the robot employs a parallel-jaw gripper.
The framework proposed in this dissertation proposes an alternate approach to task-
level programming. It is advocated here that “plans” (i.e., behaviors) be manually
devised rather than using automated planning; the contention is that humans can con-
struct compendia of complex “macro” task behaviors rather easily. Planning using first-
order logic has not proven fast enough to be viable on robots in dynamic environments,
and a library of task behaviors would circumvent this difficulty. Additionally, task-level
programming has focused primarily on performing sequences of task primitives; the
work presented here manages concurrent execution of task behaviors as well.
2.1.3 Programming by demonstration
Programming robots, particularly humanoids, is very challenging, so learning mecha-
nisms are often employed to simplify the process. However, as Schaal [Sch99] notes,
the state and action spaces for humanoids are so large as to make na¨ ıve exploration
through these spaces intractable. Programming by demonstration (PbD), which aims to
leverage data from human demonstration to program humanoids, serves as one possible
avenue to reduce exploration of these huge state-action As Dillmann et al. [DRE
+
99]
state, the goal of programming by demonstration systems is “to reconstruct and repli-
cate demonstrations or at least a set of environmental states with the highest accuracy
possible.”
10
Programming by demonstration is particularly relevant to this research because of its
treatment of movement and task representations. Indeed, this section will focus on these
two areas, rather than attempting to survey the significant body of research spanning
the domain of PbD. given that considerable research has been conducted in PbD. With
regard to movement representations, PbD must be concerned with mapping movement
from a human to a humanoid robot (e.g., Ude et al. [UAR04]). This mapping can lead
to a generalized representation of movement, which could then be used to perform the
same movement on multiple humanoids. The research presented here does not currently
consider such a representation; rather, when movement cannot be determined algorith-
mically (i.e., via motion planning, inverse kinematics, etc.), a form of the movement
appropriate for each robot is stored using a compact representation.
Programming by demonstration systems generally try to decompose the observed
task execution of the demonstrator into a sequence of tasks that are performable by the
robot (e.g., [Dil04]). This decomposition, as Dillmann et al. [Dil04] note, assumes
that some basic skills are already implemented on the robot system. Note that a similar
assumption is made on the researched presented in this dissertation (see Section 3.2).
The Task Matrix framework presented in the next chapter also assumes that complex
tasks can be decomposed into a set of constituents. However, a complex task can be
composed of concurrently running tasks and even other complex tasks in addition to
the sequence of tasks that typical PbD systems treat; the Task Matrix framework is able
to utilize more sophisticated complex and primitive tasks because it need not decode
observed task performances.
11
2.2 Complex behaviors from primitives for manipula-
tors and humanoids
This section describes several avenues of research that have produced complex behav-
iors from primitives for both manipulator and humanoid robots and agents. In particular,
this section concentrates on generating elaborate behavior from sequences of primitive
behaviors; the next section focuses on emergent behavior as a function of the outputs of
multiple concurrent behaviors. Note that the concept of using primitives to create com-
plex behavior is a well-studied topic covering many fields; thus, only its applicability to
manipulator and humanoids is discussed here.
2.2.1 PaT-Nets
Badler et al. [BBB
+
99] developed a set of parametric primitive behaviors for “vir-
tual” (kinematically simulated) humans; these behaviors include balancing, reaching,
gesturing, grasping, and locomotion. Badler et al. introduced Parallel Transition Net-
works (PaT-Nets) for triggering behavioral functions, symbolic rules, and other behav-
iors. There are key differences between the work of Badler et al. and that presented
here. In particular, Badler et al. focus on motion for virtual humans, for which the kine-
matics are relatively constant, in deterministic, known environments. The research in
this dissertation is concerned with behaviors for humanoid robots with somewhat differ-
ent kinematics (e.g., varying numbers of degrees-of-freedom in the arms, varying robot
heights, etc.) that operate in dynamically changing, uncertain environments.
12
2.2.2 Coste-Mani` ere, Espia, and Rutten
Coste-Mani` ere, Espiau, and Rutten [CMER92] used Esterel (mentioned in Section
2.1.1) to perform a task with two simulated robots in an assembly cell. The authors
utilized a set of “robot tasks”, elementary actions such as “trajectory tracking, force
controlled assembly, and gross motion”. These tasks are specified in Esterel such that
complex programs can be devised consisting of robot tasks, sensory conditions, branch-
ing and looping constructs, synchronization points, and even other programs. The most
prominent distinction between the Task Matrix and the work of Coste-Mani` ere et al. is
in the collections of elementary robot skills. The latter work allows the set of primitives
to be chosen arbitrarily; in contrast, the Task Matrix uses a commonly defined set of
robot skills to allow for execution of task programs on various robot platforms.
2.2.3 Jenkins and Matari´ c
Jenkins and Matari´ c [JM04] used a machine learning tool to extract primitive motions
from a corpus of motion-capture data. The authors also used the same tool to formulate a
deterministic state machine using these primitive motions to form more complex behav-
iors. The work presented in this dissertation focuses on tasks, rather than motions, and
uses manual programming rather than unsupervised learning to determine the vocabu-
lary of primitives.
2.2.4 Hierarchical reinforcement learning
Hierarchical reinforcement learning utilizes time-extended actions called macros and
options in order to facilitate the learning process. For example, Bentivegna [Ben04]
utilized hierarchical reinforcement learning to get a humanoid robot to play air hockey.
13
These time-extended actions serve to decrease the cardinality of the action space. Hier-
archical reinforcement learning first focused on macros [NS72, LRN86], which Barto
and Mahadevan [BM03] claim act as “open-loop control policies” (though the macro
actions themselves may utilize closed-loop policies, learning processes that utilize the
macro actions have no means of determining whether the macros executed successfully).
Sutton and Singh [SPS99] presented the concept of options, which specify conditions (as
subsets of the state space) under which a time-extended action is likely to be successful.
Macros and options both use human experience to decompose a task into independent
subtasks. This decomposition allows the learning algorithm to focus on relatively small
portions of the state-action space (i.e., those portions relevant to the subtask at hand);
consequently, learning the meta-task should be faster than with non-hierarchical meth-
ods.
Options manifest certain similarities to the task programs introduced in the next
chapter. Both mechanisms are intended to be used as self-contained building blocks for
complex behavior. Both options and task programs employ preconditions and incondi-
tions to determine whether the given method may begin or continue execution. Finally,
both options and task programs can pass messages, though options must use a circuitous
manner (i.e., by augmenting the state-action space). The primary difference between
options and task programs is that the latter can utilize planning in order to determine an
appropriate course of action. In contrast, options are restricted to using control policies,
which implies reactive behavior and precludes planning.
2.3 Behavior fusion
This dissertation takes an approach akin to the “Ostrich method” from operating sys-
tems design [Tan01] to achieving multiple tasks concurrently. The Ostrich method for
14
handling resource deadlocks, used by many modern operating systems, assumes that
deadlocks never occur. Analogously, it is assumed here that all tasks that do not uti-
lize common degrees-of-freedom may be executed contemporaneously. It is possible
to violate this assumption; for example, a lower-body behavior for kicking a ball could
conflict with an upper-body behavior for holding a cup steady. The choice of vocabulary
can mitigate this problem. One solution to the above example consists of composing a
new behavior that kicks a ball while simultaneously keeping a cup study. However,
utilizing such a methodology would expand the space of necessary primitive behaviors
exponentially.
Coelho approached the problem of performing multiple behaviors simultaneously
by utilizing a small set of “basis” controllers to perform a pick-and-place task on a
manipulator [Coe01]. This basis set consists of three controllers: a “harmonic func-
tion path” controller (a controller for following a given path), a “contact configuration”
controller (a controller for grasping), and a “kinematic conditioning” controller (a con-
troller for adjusting the robot’s posture). Coelho employs Huber’s subject-to opera-
tor [HG00] that uses null-space projections to perform multiple task objectives (e.g.,
grasping while adjusting the posture of the arm) simultaneously; the subject-to operator
prioritizes commands from one controller over another to ensure that lower priority con-
trollers do not counteract higher priority tasks. Huber [HG00] claims that this operator
allows composite controllers to provide the convergence and stability properties of the
original controllers.
Sentis and Khatib have approached this problem [SK05] in a similar manner by
using Khatib’s operational space formulation [Kha87]. Sentis and Khatib define a hier-
archy of three types of behaviors– constraints, operational tasks, and postures– in order
of decreasing priority. In this manner, a humanoid can be made to hold on to a con-
strained object in the environment (a constraint), manipulate the object (an operational
15
task), and pose the “arm” in a human-like manner. Sentis and Khatib use the nullspace
of higher priority tasks in a recursive manner; available redundancy in the robot with
regard to performing a high priority task can be utilized to concurrently perform a lower
priority task. Unfortunately, Sentis and Khatib’s approach requires that all tasks be for-
mulated in the operational space framework. This stipulation excludes behaviors not
readily expressible within this formulation and requires roboticists to transform existing
behaviors into this framework. The latter requirement is non-trivial given that Khatib’s
operational space control method requires the inverse of the joint-space inertia matrix;
this matrix requires O(n
3
) in the number of robot degrees-of-freedom to determine,
changes unpredictably from interaction with the environment, and can easily become
ill-conditioned [Fea04].
Beccari and Stramigioli [BS98] utilized impedance control [Hog85] to fuse out-
puts from several behaviors, including a trajectory following behavior and an obstacle
avoidance behavior, for use on a robotic manipulator. In particular, the fusion occurs
using the superposition principle; the outputs from all behaviors are summed, and the
resulting torques sent to the robot motors. Like Sentis and Khatib’s work, Beccari and
Stramigioli require all behaviors to be encoded into the impedance control paradigm;
this model is not always feasible or appropriate. It is also unclear how the work of
Beccari and Stramigioli would extend to balancing, which Sentis and Khatib’s method
handles adeptly.
The works of Coelho, Sentis and Khatib, and that of Beccari and Stramigioli focused
on controllers. The research presented in this dissertation, however, operates at a higher-
level (the “planning” or “high-level control” level), and assumes the existence of a
motion controller. Such a controller could be implemented using PD control, computed-
torque control, or even impedance control (though, as noted in Chapter 1, using the last
controller to manage interaction with the environment is not currently supported).
16
2.4 Robot independent programming
Davis [Dav89] proposed a method for constructing plans independent of agents. Davis
relied upon “primitive actions”, defined as actions that “represent basic physical
motion”; Davis utilized the following primitive actions: raise, lower, push, pull, rotate
clockwise, rotate counter-clockwise, move-to, flip up, flip down, grasp, and release. Sim-
ilar to the Task Matrix, Davis assumed that the basic skills are implemented on each
agent and that tasks can be broken into subtasks. The task decompositions in this disser-
tation were drawn from research in occupational biomechanics in contrast to Davis’ ad
hoc decompositions. Davis also attempted to address all embodied agents, identifying
shared characteristics between them, while the work here examines only humanoids. It
should be noted that Davis’ system was only a proposal; he did not demonstrate it on
any robotic platforms, physically embodied or simulated.
Alissandrakis, Nehaniv, and Dautenhahn [AND02] also researched performing
actions across several platforms in the context of imitation learning. Like Davis’ pro-
posal, this research applies to general agents (Alissandrakis et al. applied it to chess
pieces). Alissandrakis et al. used a correspondence library to map actions on one plat-
form to actions on another. This correspondence library is similar to the common skill
set introduced in the next chapter; however, the latter is a small set while the former is
potentially unbounded. Like Davis’ work, the research of Alissandrakis et al. was not
demonstrated on any robotic platforms.
Vaughan, Gerkey, and Howard [VGH03] developed Player, an ubiquitous frame-
work that provides common interfaces for groups of similar devices. Player categorizes
like devices into predetermined classes (e.g., laser range-finders, planar robots, etc.),
each of which is associated with an abstract interface. Drivers are used to implement
specific interfaces for particular devices (e.g., a “SICK laser” driver would implement
17
Method Behavior fusion
Interaction control
Complex tasks from primitives
Sequential and concurrent behavior execution
Robot independence
Interaction with objects
Learning of primitive and complex behaviors
Preconditions and exception handling
Controller agnosticism
Segre [Seg88]
Lozano-Perez et al. [LP82, LPJMO89]
Chen [Che05]
Dillmann et al. [DRE
+
99, Dil04]
Badler et al. [BBB
+
99]
Coste-Mani` ere, Espia, Rutten [CMER92]
Jenkins and Matari´ c [JM04]
Coelho [Coe01]
Khatib and Sentis [SK05]
Bentivegna [Ben04]
Beccari and Stramigioli [BS98]
Davis [Dav89]
Alissandrakis et al. [AND02]
Vaughan et al. [VGH03]
Task Matrix
Table 2.1: A comparison of the features of the methods discussed in this chapter with
those of the Task Matrix. indicates that the feature has been implemented, indicates
that the feature has been partially implemented, and indicates that the feature has not
been implemented.
the laser range-finder interface). Using Player, developers are able to program robots
using the abstract interfaces, which may make the resulting programs portable across
robot platforms. Player’s interfaces are analogous to skills in the Task Matrix; both
18
serve to allow the programmer to treat devices in an abstract manner. However, Player
provides a large set of possible interfaces that robots may employ; in contrast, the Task
Matrix assumes the existence of a common skill set, which defines a set of capabilities
that all robots must implement. The result of this distinction is that a program written for
the Task Matrix will be robot independent, while a program written for Player may not
be. For example, a Player program that utilizes a laser range-finder will fail on a robot
that lacks this sensor; programs in the Task Matrix may make no such assumptions (and
do not even manage sensors directly).
2.5 Summary
This chapter discussed research relevant to the Task Matrix framework introduced in
the next chapter. First, robot programming systems for mobile and manipulator robots
were compared to the Task Matrix. Second, various methods for constructing complex
behaviors from primitives were examined. Next, behavioral fusion for mobile robots
and humanoids was studied, and this method was contrasted with the arbitration selec-
tion method employed by the Task Matrix. Finally, research into robot-independent
programming was covered. Comparisons between the Task Matrix and the related work
cited in this chapter, using relevant features for programming humanoids, are summa-
rized in Table 2.1.
19
Chapter 3
The Task Matrix
3.1 Introduction
The Task Matrix is a framework for performing tasks with humanoids in a robot-
independent manner. It consists of four primary components: the common skillset, a
perceptual model, conditions, and task behaviors. The core of the Task Matrix is the
set of task behaviors; the remaining components exist to facilitate the operation of these
behaviors. The common skillset serves as a constant, abstract interface between the task
behaviors and robots; similarly, the perceptual model presents an interface to a represen-
tation of the environmental state. Conditions are used to test robot and environmental
states (via the common skillset and perceptual model) to permit, halt, or influence exe-
cution of a task behavior in a reusable manner. Figure 3.1 depicts the interaction of
components in the Task Matrix.
The Task Matrix operates upon a n degree-of-freedom, “floating” (i.e., non-fixed)
base”, loop-free structured robotR, which is formally represented here by a four-tuple
< x
t
;f(:);g(:);K > where x
t
2X (X R
m
andm n) is a vector describing the
dynamical state of the robot at timet; f : xut! _ x is a model of the dynamic
evolution of the robot state as a function of current state, motor commands (u2U,
whereUR
r
andr n), and time (t);g :X!C, whereCR
n
, is a function that
transforms the robot state into the robot configuration space [LPW79, LP81, LP83]; and
K is a directed graph, in particular a tree, that specifies the connectivity of the robot,
20
4 ASK B EHA VIORS # ONDITIONS # OMMONSK ILLSET 0 ER C EPTUALMO DEL 2 OB OT %N VIR ONMEN T # OMMANDS QUER IES QUER YR ESULTS 1 UER IESPR EINC ONDITIONS SA TISFYINGSTA T ES QUER YR ESULTS + INEMA TIC C OMMANDS * OIN T P OSITIONS 1 UER IESR OB OTSTA T E QUER YR ESULTS 5 SER
DEFINEDPR O C ESS 3 ENSOR YP ER C EPTIONS 1 UER IES OBJEC TS STA T ES QUER YR ESULTS O B JEC TS STA T ES EN VIR ONMEN TALMO DEL 1 UER IES OBJEC TS STA T ES QUER YR ESULTS Figure 3.1: The interaction between components in the Task Matrix. Arrows indicate
the direction of data flow.
with vertices representing links and edges representing joints.
1
Note that there are no
cycles inK because the robot is kinematically loop-free.
The Task Matrix currently assumes configuration space to be the Cartesian product
of joint space and the manifold SE(2) [Gil06], the latter of which corresponds to planar
1
The floating base is represented as a virtual link (vertex) and a virtual three-DOF joint (edge), which
connect to another link on the robot such as the pelvis. A directed edgee from vertexi to vertexj indicates
that joint e is an outer joint for link i and an inner joint for link j; in other words, joint e affects only the
kinematics of link j.
21
position and orientation of the robot’s base
2
. It is also possible to defineC
obs
=C
C
free
as the subset of configuration space in which the robot is in unpermitted contact
with itself or the environment. Additionally, the manifolds
_
C and

C are defined as the
manifolds of the first and second-derivatives of configuration space.
The few assumptions that the Task Matrix makes about the humanoid robot follow:
1. The humanoid is not fixed to the environment (i.e., its base is “floating”)
2. The robot’s base is constrained to the manifold SE(2); the robot is thus unable to
kneel or jump or bend at the pelvis.
3
3. All degrees-of-freedom except the robot’s base are holonomically constrained.
This assumption indicates solving a two-point boundary problem may be required
to get from one configuration of the base to another; in contrast, linear interpola-
tion can be used to get from one configuration to another for a non-base degree-
of-freedom.
We preface the remainder of this chapter by noting several manifolds that will be
used throughout:
XR
m
: the state space of the robot
CR
n
: the configuration space of the robot (a three degree-of-freedom joint is
used to model the position and orientation of the robot’s base)
UR
n3
: the motion-control command space of the robot
O R
6
: an operational space, the Cartesian product of three-dimensional
Euclidean space and SO(3) [LaV06]
2
Humanoid bases generally are constrained to lie on the manifold SE(3) [Gil06]
3
This limitation is not intrinsic to the Task Matrix, but to its current implementation.
22
3.2 Common skill set
Skills act much like an application programming interface (API) for robot behaviors.
Programs interact with skills rather than interfacing directly with the robot. An API
provides the same advantages for robot programs as it does for computer programs:
the interface remains relatively constant and specifies expected inputs and outputs. In
this way, the Task Matrix is able to provide robot independence in the same manner
that application programming interfaces provide independence across different com-
puter architectures and operating systems.
The API metaphor is not completely applicable to robotics. APIs are generally deter-
ministic, both in reading state and performing actions; in contrast, robotics is character-
ized by uncertainty. The skills in the Task Matrix framework attempt to produce some
minimum level of performance (i.e., satisficing behavior), without specifying that level
of performance; control error generally increases with movement speed, making quan-
tification difficult.
A skill in the Task Matrix is a function P : RtR
c
! R
d
u is a
function mapping a vector of arbitrary dimension and/or an arbitrary function to a vector
of arbitrary dimension, an arbitrary function, and/or motion-control commands:
R is a robot (defined above)
t is time
c;d2Z

and are arbitrary functions
u is a vector of motion-control commands (defined above), that influences the
evolution of the robot state
23
The common skill set is a specification, composed of a predetermined set of skills as
defined above, that ensures portability of task behaviors for all robots that implement it.
For convenience, we will denote the common skill set by the Greek letter . Figure 3.2
depicts the interaction between a behavior, the common skill set, and a robot. The set of
skills in the common skill set may be used within the motion-control paradigm for robot
control; this model is very useful at driving humanoids to perform free-space motions,
though its utility for facilitating interactions with the environment is limited. Chapter
6 discusses the possibility of adding more effective environmental interaction through
support of the interaction control paradigm.
The common skill set was constructed in a principled manner by examining a large
class of tasks, occupational tasks, which is described in detail in the next chapter. Com-
mon elements were identified and robot-dependent components were culled from this
set. Of the set of robot-dependent components, prevalent functions in manipulator
and humanoid robotics (e.g., motion-planning, inverse kinematics, motion control, etc.)
were established as standalone components to minimize implementation effort: many
of these functions (e.g., motion control) are provided directly by the robot, while others
(e.g., direct kinematics) are easily computed.
The skills presented below consist of methods for identifying the degrees-of-
freedom (DOF) belonging to a kinematic chain; for querying the position, velocity, and
acceleration of a DOF; for sending position, velocity, and acceleration commands to a
DOF; for calculating direct and inverse kinematics; for performing motion planning; for
checking whether a desired posture would cause the robot to be in a state of collision;
for determining the “hand” configuration of the robot necessary to grasp a given object;
for obtaining the orientation describing the robot’s view; and for attaching and detaching
objects from the robot’s end-effector.
24
4 ASK B EHA VIOR # OMMON3 K ILLSET 2 OB OT * OIN TP OSITION $ EGR EES
OF
FR EEDOM * OIN TC OMMANDS & OR W AR DK INEMA TICS )N V ERSEK INEMA TICS - OTIONPLANNING ' R ASPC ONFIGUR A TION # OLLISIONCHECK ING 6 IEWTR ANSF OR M , O C OMOTION ! TTACHDETACHOBJEC T 1 UER IES # OMMANDS Figure 3.2: A depiction of the interaction between robot behaviors and the common
skill set that leads to portable behaviors. This diagram indicates that the robot behavior
neither queries nor commands the robot directly, nor does it have a priori knowledge
of the robot’s degrees-of-freedom. The behavior is able to make queries and send com-
mands at run-time only via the skill layer. Note that locomotion is provided by the skill
layer, but cannot be called directly by the task behaviors; it can only be called by send-
ing joint-space commands to the translational and rotational degrees-of-freedom of the
base.
Definition 1 (Degrees-of-freedom) Given a kinematic chain K K, identify all
degrees-of-freedom that correspond to the kinematic chain.
This skill allows kinematic chains to be dealt with abstractly; for example, by utiliz-
ing this skill, it is possible to query joint positions for all degrees-of-freedom in the arm
without knowing those DOFs.
25
Definition 2 (Joint position / velocity / acceleration query) Returns the current robot
joint space configuration or first or second derivative of configuration at time t; for-
mally, evaluatesg(x
t
), _ g(x
t
), or g(x
t
).
Definition 3 (Motion controller) Given a triple of configuration space command
vectors fq
d
2 C; _ q
d
2
_
C; q
d
2

Cg, the motion controller, represented by
u(q
t
0
;q
d
; _ q
t
0
; _ q
d
; q
t
0
; q
d
), issues motor commands to the robot either directly or by
passing the commands through an intermediate motion controller.
The above definition does not specify the accuracy with which the robot must
achieve the desired commands. The common skill set can potentially utilize multiple
controllers for use in various situations: the task behaviors are ignorant of the underly-
ing controller type or types. For example, an adaptive controller might be used instead
of a computed-torque controller when an object is held.
In addition to the usual responsibility of a motion controller to drive the joints of a
robot, the motion controller is also responsible for locomotion; the virtual-base position,
velocity, and acceleration commands must be translated into joint-space commands.
Definition 4 (Forward kinematics) Given a desired kinematic chain K K and a
configuration space vectorq2C, determine the operational space configurationo2O
of the end-effector ofK for configurationq.
This skill provides a function F : CK ! O that will be used further in the
remainder of this section. Note thatK is a proper subset ofK; the chainK must not
contain more than one end-effector.
Definition 5 (Inverse kinematics) Given an operational space vectoro2O, a desired
kinematic chainKK, and the forward kinematic functionF :CK!O, determine
a pointq such thatF (q;K) = o, or report that such a point does not exist.
26
Note that K is a proper subset of K; the skill need not provide for determining
multiple goals corresponding to multiple end-effectors simultaneously.
Definition 6 (Motion planning – configuration space to configuration space) Given
two points q
I
;q
G
2 C
free
determine a path
: [0; 1] ! C such that
(0) = q
I
,

(1) =q
G
, and8t2 [0; 1];
(t)2C
free
.
Informally, motion planning is consistent with its standard definition in the robotics
community, that of finding a collision-free path between two points in configuration
space.
Definition 7 (Motion planning – configuration space to operational space) Given
points q
I
2 C
free
and o 2 O, kinematic chain K, and forward kinematics function
F :YK!O, determine a path
: [0; 1]!C such that
(0) =q
I
,F (
(1);K) =o,
and8t2 [0; 1];
(t)2C
free
.
The above requires a collision-free path to be found between a point in configura-
tion space and a point in operational space. For humanoid robots, there are typically
infinitely many elements in configuration space that correspond to a single element in
operational space.
Definition 8 (Collision checking) Given a pointq2C, the current robot configuration
g(x
t
) =q
t
2C, and kinematic chainsKK, determine whetherq

2C
free
, whereq

is defined below:
8i2n;q

i
=
8
<
:
q
i
if9j s.t. edge
j;i
2K
q
t
i
if69j s.t. edge
j;i
= 2K
Informally, this skill determines whether a given joint-space configuration is
collision-free. If the kinematic chain to be tested is only a subset of the configuration
27
space of the robot, then the current configurations should be used for those degrees-of-
freedom not in the chain.
Definition 9 (Grasping configuration) Given an objectO and end-effector E 2 K,
determine the set of relative transformationsX =fx
1
;x
2
;:::;x
N
g (x
i
2O) viable for
graspingO withE.
Definition 10 (Robot view) Return a 3 3 orthonormal matrix, the first column of
which is a free vector aligned with the robot’s viewpoint, the second column of which
is a vector pointing upward through the robot’s head, and the third column necessarily
being the cross-product of the first and second columns.
Definition 11 (Attaching / detaching object) Given an end-effector of the robotE and
an object to graspO, attach or detach theO to or fromE. Alternatively, given an end-
effector of the robotE, return any object currently grasped by the robot.
This skill is necessary to accommodate humanoids that use non-mechanical (i.e.,
electromagnetic or kinematically simulated) means for grasping objects. This skill acts
to switch on or off an electromagnet or to trigger code to move grasped objects as a
function of robot configuration for kinematically simulated humanoids. Additionally,
this skill can be queried to determine whether a given hand is grasping an object. This
ability is utilized within the grasping condition.
3.3 The perceptual model
The perceptual model aims to provide a layer of abstraction for humanoid robot sens-
ing to complement the layer that the common skill set provides for humanoid robot
kinematics and motor control. The Task Matrix is ignorant about sensing modalities
and operation. Unlike the common skill set, common elements between the different
28
sensing modalities are not identified; neither are like sensing modalities categorized
(e.g., depth sensor, color blob tracking sensor, etc.). Rather, a database is maintained
for representing the state of the environment. This database is known as the percep-
tual model. An external, user-defined process updates the perceptual model at regular
intervals. Meanwhile, task behaviors can query the model.
Formally, the perceptual model, which will be called , is a collection of functions:
:O!O returns the operational space configuration of objectO
:O!R
6
returns the operational space velocity (linear and angular) of object
O
:TX (XR
3
)!Z returns the set of all objectsZ of a given typeT (e.g.,
ball, vehicle, etc.) within a region of Euclidean spaceX

:;! [0;1] returns the current time
The core of the perceptual model database consists of objects. An object describes
a physical entity (e.g., tool, obstacle, person, etc.) within the perceptual model with
which the robot can interact. The database stores state information for each object,
including position, orientation, velocity (linear and angular), and axis-aligned bounding
box. Additional optional object data can be stored as well, such as task frames (if the
object is a tool), the taxonomological classification (e.g., a ball is a toy is an obstacle),
and whether the object is currently grasped by the robot.
The robot programmer does not implement the perceptual model. Instead, the pro-
grammer implements the external process mentioned above. Task behaviors in the Task
Matrix typically operate under a passive sensing paradigm; the interpretation of sen-
sory data occurs within the external process, rather than within the task behaviors. The
advantage of this paradigm is that the user can be ignorant of the details of the robot’s
29
perceptual system, including sensor types and sensing direction (as a function of robot
configuration). The disadvantage is that the robot configuration cannot be directly con-
trolled by the programmer-defined external process to sense in a particular way; for
example, a sensor cannot be intentionally pointed toward a particular location to disam-
biguate an object type.
Task behaviors can employ active sensing, in which the task behavior directs the
sensors (by changing the robot’s configuration) to perceive the environment. For exam-
ple, the explore task behavior described in the next chapter generates random points in
configuration space (in a subspace of configuration space, to be precise) to survey the
environment. Unfortunately, designing algorithms to work with general arrays of sen-
sors has been far more difficult than constructing portable task behaviors in practice.
Tackling this endeavor requires knowledge about the field of sensing and the direction
of sensing as a function of the robot configuration, for each sensor in the array. Addi-
tionally, the sensory data must be “fused” to reduce uncertainty. The explore behavior
makes some assumptions (discussed in the next chapter) that reduce the algorithmic
complexity at the potential expense of behavior portability.
3.4 Conditions
Conditions are Boolean functions that allow for checking the state of the world using
symbolic identifiers. They are typically employed as either preconditions, conditions
that must be true for a task behavior to begin execution, or inconditions, conditions that
must be true for a task behavior to continue execution. However, they may be used
elsewhere within task behaviors; for example, the grasp behavior described in Section
4.3.3 uses a condition to determine whether the robot is already grasping an object and
can exit indicating success.
30
Conditions may also be used inversely to the manner described above. In particular,
conditions can be utilized to determine the set of states corresponding to a Boolean
expression of symbols. For example, the putdown macro task (see Section 5.7.2) utilizes
the intersection of two conditions– above and near– to determine a valid location to
place an object.
Conditions promote code reuse, help ensure robot independence, and simplify pro-
gramming. Code reuse is promoted in the same manner as that of functions in a pro-
gramming language; for example, both the reach and grasp task behaviors (described
in Chapter 4) utilize the grasping condition (described below). Conditions help ensure
robot independence and simplify coding by allowing the programmer to deal with sym-
bols rather than numerics. For example, instead of checking whether specific degrees-
of-freedom of the robot are at certain positions appropriate for grasping, the programmer
can call the postural condition (described below); the posture itself is robot-specific, but
this data can be stored externally and replaced when porting to a new robot platform.
3.4.1 Definition
A conditionC is a Boolean functionC :Rt
i
!f0; 1g where:
R is an robot (defined in Section 3.1)
t is time
is the common skill set defined in Section 3.2
is an optional vector of parameters
31
3.4.2 Implemented conditions
The current set of conditions in the Task Matrix have been implemented in an ad hoc
manner; they have been developed as necessary to realize error checking for the prim-
itive tasks described in Chapter 4. These implemented conditions are described in the
remainder of this section.
3.4.2.1 Postural
The Postural condition is satisfied if all degrees-of-freedom for a specified kinematic
chain of the robot are equal (to within some tolerance) to predetermined values. These
values are stored externally so that porting to new robot platforms is simplified.
3.4.2.2 Near
Parameter Description
x the identifier for an object
y the identifier for an object
distance the maximum distance between the objects
The near condition determines whether an objectx is sufficiently near some object
y. Near can operate upon either the bounding box or a reference point (e.g., center-of-
mass, task frame, etc.) of an object.
3.4.2.3 Above
Parameter Description
x the identifier for an object
y the identifier for an object
32
The above condition determines whether the bounding box for an objectx is com-
pletely above the bounding box for an objecty (i.e., whether the bottom ofx’s bounding
box is above the top ofy’s bounding box).
3.4.2.4 Graspable
Parameter Description
object the identifier for an object
The graspable condition is satisfied if one of the robot’s hands is able to grasp the
specified object. In particular, if the homogeneous transformation of one of the robot’s
hands is equal (to within some tolerance) the compound transformation of the object’s
homogeneous transformation and one of the transformations output by the grasping con-
figuration skill (Definition 9), the condition is satisfied.
3.4.2.5 Grasping
Parameter Description
object the identifier for an object
The grasping condition is satisfied if one of the robot’s hands is currently grasping
the specified object.
3.5 Task behaviors
The core component of the Task Matrix is the set of task behaviors. A task behavior is a
function of time and state that runs for some duration, possibly forever, performing robot
skills. Task behaviors may run interactively (e.g., reactively) or may require consider-
able computation for planning. Additionally, both end-users and other task behaviors
can send parameters to a task behavior that influences its execution.
33
The execution of a task behavior occurs in three phases: 1) pre-execution, 2) plan-
ning, and 3) control-loop. During the first phase, the preconditions for the task behav-
ior are checked and the requisite kinematic chains are assigned. In the planning and
control-loop phases, the common skill set may be called and the perceptual model may
be queried. The distinction between these two phases from the programmer’s viewpoint
is somewhat arbitrary; however, the planning phase runs only once while the control-
loop phase executes continually until the task behavior terminates.
3.5.1 Definition
A task behaviorT :R

t!

maps inputs to messages.
R is a robot (defined in Section 3.1)
is a set composed of Condition functions, which are defined in Section 3.4.1;
these functions act as preconditions and inconditions and take as input a vector
parameters
is the perceptual model (defined in Section 3.3)
is the set of common skills defined in Section 3.4.1
is an optional set of ` robot-dependent trajectory functions
1
;
2
;:::;
`
,
where
j
:Rt!fq; _ q; qg
is a tuple of parameters for the behavior
: !
maps task behavior parameters to Boolean function (i.e., condition)
parameters
t is time

is a set of messages such as task-complete and goal-achieved, described below
34
3.5.1.1 Messages
Task behaviors can communicate with other task behaviors (see Section 3.5.2) to per-
form complex tasks. The method of communication is via message passing. The Task
Matrix employs a fixed set of messages, described below:
Table 3.1: The list of messages that may be sent by task behaviors in the Task Matrix
Message Description
planning-started Sent immediately before a task behavior begins planning
planning-ended Sent immediately after a task behavior finishes planning
controlloop-started Sent immediately before a task behavior begins its
control loop
controlloop-ended Sent immediately after a task behavior ends its
control loop
force-quit Sent when a task behavior is forced to terminate execution
task-failed Sent by a task behavior if it fails to complete
task-successful Sent by a task behavior if it completes successfully
task-complete The last message sent by a task behavior; always sent
goal-achieved Sent by recurrent tasks to indicate that the task just now
achieved its goal; either this message or goal-failed is sent
once every control-loop
goal-failed Sent by recurrent tasks to indicate that the task just now
failed to achieve its goal; either this message or
goal-achieved is sent once every control-loop
task-failed-to-start Sent when a task failed to begin execution in or before
the planning phase
3.5.1.2 Postures and motions
Some task behaviors, in particular the postural and canned behaviors introduced in the
next chapter, utilize data external from the task behaviors and Task Matrix. These
data are robot-specific, and are therefore isolated from these robot independent com-
ponents. The data take two forms: postures and motions. The former consists of a set of
35
Algorithm 1 The reach task behavior planning phase
fDetermine degrees-of-freedom for motion-planningg
DOFs = skillset.get-DOFs()
qinit = skillset.get-position(DOFs)
fIf both arms are active, select one for reachingg
if contains(active-chain, leftarm) and contains(active-chain, rightarm) then
if (B(0:5)) then
IK-chain = leftarm
else
IK-chain = rightarm
else
if contains(active-chain, leftarm) then
IK-chain = leftarm
else
IK-chain = rightarm
fDetermine the list of operational space goalsg
rel-transforms = skillset.get-grasp-configs(target-object)
fori = 1 to size(rel-transforms) do
goals[i] = target-object-transform . rel-transforms[i]
fAttempt to plang
path = skillset.plan-motion(qinit, goals)
if not empty(path) then
trajectories = get-trajectories(DOFs, path)
start-time = perceptual-model.get-time()
Algorithm 2 The reach task behavior control-loop phase
fGet the current trajectory timeg
current-time = perceptual-model.get-time() - start-time
fSend motor commandsg
for alli in trajectories do
i.set-time(current-time / duration)
skillset.set-command(DOFs[i],i.getX(),i.getXD(),i.getXDD())
fCheck whether task is completeg
if current-time duration then
send-message(task-successful)
36
degree-of-freedom / joint-space position pairs, and the latter consists of a set of degree-
of-freedom / trajectory pairs. Porting task behaviors to new robot platforms therefore
requires modification of the posture and motion data (as well as the implementation of
the common skill set and the process to update the perceptual model). However, there
is active research [MRC05] into methods that potentially can obviate the former task by
storing postures and motions in a manner dependent on the kinematic features of the
robot.
3.5.2 Complex task behaviors
Task behaviors running in isolation are useful, but one of the key strengths of the Task
Matrix is the ability to build complex task behaviors from sequences and combinations
of simple task behaviors. Such complex task behaviors are designated macro task behav-
iors and can be realized via the Message-Driven Machine construct, described below.
3.5.2.1 Message-Driven Machines
Message-Driven Machines (MDMs) are a state-machine mechanism that allows for con-
current and sequential execution of task behaviors. MDMs consist of a set of states, each
state corresponding to a task behavior, and transitions. There is a many-to-one mapping
from states to task behaviors (i.e., multiple states may utilize the same task behavior)
within a MDM; the task behaviors in this mapping may be primitive behaviors or other
MDMs. A transition within a MDM indicates that a task behavior is to be executed or
terminated, depending on the transition type, and is followed if the appropriate message
is received.
Figure 3.3 depicts a simple sequential MDM for performing the Pick-and-place task.
Execution begins at the start state and proceeds as follows: if the robot is already grasp-
ing an object, it transitions to the Release
1
state, where it begins execution (thereby
37
Start
Release
1
is-grasping? ! is-grasping?
task-done
task-done
task-done
task-done
Reach
1
Grasp
Reach
2
Release
2
Arm Hand Object
Target
location
Figure 3.3: The MDM for performing the Pick-and-place task. Parameters are repre-
sented by the shaded boxes. Transitions are indicated by lines with arrows. Boolean
conditions are in unaccented text, messages are in italicized text.
dropping the grasped object). A transition is made to the Reach
1
state, which causes
the robot to reach to the target object. When the robot has successfully reached the tar-
get object, it is made to grasp the object. Next, the robot reaches to the target location
(the Reach
2
state). Finally, the robot releases the object, now at its target location. The
outline drawn around the Release
2
state in Figure 3.3 indicates that the macro task ends
38
execution upon termination of this state. Note that the MDM presents its own paramet-
ric interface (the shaded boxes in Figure 3.3); these parameters are “wired” to the task
behaviors contained within the MDM.
It is natural to wonder what happens if one of the subtasks in a macro task fails.
MDMs can catch and recover from failures in execution using an alternate path of exe-
cution, transitioned to by receiving the task-failed message. By default, if a task-failed
message is not “caught”, execution of the MDM terminates.
3.6 Summary
This chapter presented the components of the Task Matrix and discussed both robot-
independent and robot-specific constituents. The common skill set, the perceptual
model, conditions, and task behaviors were discussed in detail. The next chapter
describes the primitive task behaviors currently implemented in the Task Matrix.
39
Chapter 4
Task Programs
4.1 Introduction
This chapter presents a set of parametric, robot-independent primitive task behaviors
developed for the Task Matrix framework. The set of task behaviors described here was
inspired by research into human occupational tasks and driven by practice in developing
complex task behaviors.
4.2 Movement notation and work measurement systems
Considerable research has been undertaken in the area of decomposition of human tasks
into primitive constituents. The domains analyzed tend to fall into two categories: dance
movements and occupational tasks.
The former category is convenient for analysis due to its exclusive focus on free-
space movements; it follows that this category is insufficient for investigating tasks that
manipulate objects.
4.2.1 Movement notation
Movement notation attempts to formalize descriptions of movements of the human body.
The majority of research in this area has been in dance notation. For example, Camurri,
Morasso, Tagliasco, and Zaccaria [CMTZ86] list five systems for expressing dance in
40
symbols– Feuillet, Stepanov, Laban, Benesh, and Eshkol-Wachman– and note that sev-
eral other systems have been developed. Each system has particular strengths and each
focuses on different aspects of movement. For example, Feuillet notation is concerned
with the dancer’s path along the floor while the Benesh system focuses on the paths in
the space of the body extremities.
Camurri et al. also provide an elementary dictionary of dance and movement termi-
nology. This dictionary essentially taxonomizes motion into movements dominated by
gravity, movements that are locomotive in nature, postural movements, and movements
that interact with the environment. Each movement can also be assigned one of a num-
ber of attributes from several categories that describe spatial, temporal, and qualitative
characteristics of the movement as well as parts of the body involved and geometric
shape of the movement path.
Movement notation is convenient for expressing the motion of a human (or
humanoid) in a relatively compact, efficient manner. It is worth studying movement
notation systems for their expressiveness and completeness (i.e., ability to decompose
any observed movement within a system). Unfortunately, systems for movement nota-
tion have several drawbacks with regard to adaption for performing tasks with humanoid
robots. The systems are usable only for highly limited domains, in particular, specific
schools of dance (e.g., Russian, French, and Italian classical ballet schools utilize differ-
ent movements), and are composed of very large vocabularies of primitives; Campbell
and Bobick [CB95] note that classical ballet employs between 800-1000 “steps” (a step
is only one component of a primitive movement). However, the most limiting factor in
adapting movement notation systems into a vocabulary of primitive tasks is the inability
of these systems to deal with objects in the environment.
41
4.2.2 Work measurement systems
Work measurement systems were originally developed to measure and minimize perfor-
mance time for occupational tasks. Though considerable effort was initially expended
to analyze work flow via time-lapse photography [Nie88], the advent of work measure-
ment systems allowed trained individuals to analyze task efficiency quickly and without
special equipment. Work measurement systems, initially developed in the early twenti-
eth century, function by decomposing an occupational task into a sequence of primitive
elements. Mean times compiled for primitive elements allow for a rough computation
of the mean time required to perform a given task.
Work measurement systems make for a compelling choice for developing a set of
primitive task behaviors for humanoid robots. These systems are proven at decompos-
ing tasks into their primitive constituents. Additionally, such systems are not overly
specific at determining how a task may be done, allowing for variation in task perfor-
mance over different robot platforms. Unfortunately, work measurement systems are
not efficient or even capable of decomposing non-occupational tasks, such as dance and
sports. These systems also focus on classification (work measurement in particular) and,
subsequently, are somewhat ill-suited to performance of the primitive tasks. As a result,
a work measurement system is used only as inspiration, rather than as a canonical ref-
erence, for the construction of the vocabulary of primitive task behaviors introduced in
this chapter.
There exist numerous work measurement systems; the most prominent are MTM
[AJMHK73], MODAPTS [MS02], and MOST [Zan90]. The differences between these
systems consist of small variations in the vocabulary of primitive tasks; note, how-
ever, that the overlap between the vocabularies of these systems is considerable. The
Motion-Time Measurement system (MTM), serves as the inspiration for the primitive
42
task behaviors presented later in this chapter. MTM (specifically MTM-1) was cho-
sen because its vocabulary is quite small and because it is one of the oldest and most
prominent of all work measurement systems
MTM [KH82, KB87] has been developed in several variations, which vary in the
amount of detail that the system can capture (and the difficulty with which the system
is learned by a human observer). MTM-1 [AJMHK73] includes the atomic motion ele-
ments reach, move, turn, apply pressure, grasp, position, release, disengage, eye move-
ments, and body movements. Additionally, MTM-1, like all MTM systems, specifies
how some motions may be performed simultaneously. The remainder of this section
describes these atomic motion elements in further detail.
4.2.2.1 Reach
Reach is consistent with the standard definition of the word, that of stretching the arm
in order to touch or grasp an object. The time units assigned to a particular case is
dependent upon the distance that the hand moves and whether the dominant or secondary
hand is used to perform the task. Additionally, MTM-1 subcategorizes reaching into five
cases, listed below:
reaching to an object in a fixed location, or to an object in the other hand or on
which the other hand rests
reaching to a single object in a location which may vary slightly from cycle to
cycle
reaching to an object jumbled with other objects in a group so that search and
select occur (see Figure 4.1)
reaching to a very small object or where accurate grasping is required
43
reaching to an indefinite location to get the hand out of the way or in position for
body balancing or the next movement
Figure 4.1: The MTM atomic element reach (with search and select)
4.2.2.2 Move
Move indicates that an object is moved with some imprecision (contrast with position
below). The timing of the movement is modified by the distance that the object is moved,
as well as the weight of the object. MTM-1 divides move into three subcategories:
moving an object to the other hand or against a “stop”
moving an object to an approximate or indefinite location (see Figure 4.2)
moving an object to an exact location
4.2.2.3 Turn and apply pressure
Turn and apply pressure is a movement that describes applying forces or torques to
objects (see Figure 4.3). The MTM Manual. [AJMHK73] defines turn as “the basic
44
Figure 4.2: The MTM atomic element move
motion employed to rotate the hand about the long axis of the forearm”. MTM-1 com-
bines these somewhat dissimilar actions together due to the prevalence of their simul-
taneous application. This element’s timing is modified by the approximate quantity of
force applied and the degrees turned about the arm.
Figure 4.3: The MTM atomic element turn and apply pressure
45
4.2.2.4 Grasp
The semantics of grasp, like reach, is consistent with the accepted definition of the word.
MTM-1 identifies five types of grasps:
the pick up grasp (further subcategorized by whether the object is floating in space
or lying close against a flat surface and the size of the object)
regrasping (i.e., grasping the object in a different manner)
transfer grasping (i.e., transferring the object to a different hand)
grasping among a jumbled collection of objects
“contact”, “slide”, or “hook” grasping (indicates grasping with the finger tips,
sliding the object along a surface, or scooping the object into the hand, respec-
tively)
4.2.2.5 Position
Position, as seen in Figure 4.4, is used to indicate a more refined movement than move;
position is typically used in the context of mating parts. The timing of the position
element is a function of the symmetry of the handled object (i.e., “symmetrical”, “semi-
symmetrical”, or “non-symmetrical”), and the difficulty of the object to handle (i.e.,
“easy” or “difficulty”). These object characteristics are completely subjective; the MTM
manual [AJMHK73] leaves the determination of object symmetry and handling diffi-
culty to the observer. Additionally, position is subdivided into three categories, based
on the “class of fit”: “loose” (no pressure required), “close” (light pressure required),
and “exact” (heavy pressure required).
46
Figure 4.4: The MTM atomic element position
4.2.2.6 Release
The release element is complementary to the grasp element; it consists of only two
cases: a “normal” release performed by opening the fingers as an independent motion
and a “contact release”.
4.2.2.7 Disengage
Disengage is complementary to position, indicating that the operator is separating two
objects. Similarly to position, disengage is subdivided into three categories, based on
the “class of fit”: “loose” (very slight effort required, the movement blends with the sub-
sequent move), “close” (normal effort required, the hand recoils slightly), and “tight”
(considerable effort required, the hand recoils markedly). Also like position, the tim-
ing of the disengage movement is dependent upon the handling difficulty of the object
(either “easy” or “difficult”).
47
4.2.2.8 Eye movements
Timing measurement for eye movements is also measured by the MTM-1 system. This
element considers both the “eye travel time” (a function of the distance between points
from and to which the eye travels and perpendicular distance from the eye to the line of
travel) and the “eye focus time” (the time required to focus upon an object). Note that
head movement is not considered.
4.2.2.9 Body, leg, and foot motions
MTM-1 groups several disparate motions in five subcategories under the single element
body, leg, and foot motions. The individual motion times are determined by the distance
that the body, leg, or foot moves. The subcategories of this element are: foot, leg, or
foreleg motion; sidestep; bend, stoop, kneel, or arise; sit; and walk.
4.3 Primitive task behaviors
MTM-1 is a compelling system to use as inspiration for developing a set of primitive
behaviors for performing occupational tasks. It has proven successful at decomposing
occupational human tasks into primitive elements. However, MTM-1– as well as other
work-measurement systems– are difficult to adapt directly to task behaviors. These sys-
tems focus primarily on measuring work, not decomposing tasks. Consequently, the
systems make several arbitrary distinctions between some tasks. For example, the posi-
tion and move elements in MTM-1 are distinguished only by the precision required to
position an object. However, the promise behind utilizing a system such as MTM-1
for inspiration remains clear: if a set of task behaviors can implement every element
48
that MTM-1 can recognize, the likelihood that arbitrary occupational tasks can be per-
formed is high. Table 4.1 shows the elements and subelements of MTM-1 that have
been implemented by the task behaviors presented in this chapter.
The remainder of this chapter discusses nine primitive task behaviors developed to
perform both occupational tasks and communicative tasks like waving and bowing. The
first five task behaviors discussed– reach, position, grasp, release, and fixate– were
directly inspired from MTM-1 (in particular, the reach, move/position, grasp, release,
and eye movements atomic elements, respectively). The remaining three task behaviors–
postural, periodic-canned, and aperiodic-canned– are used to drive robots to particular
postures and perform predetermined movements.
4.3.1 Reach
The reach task behavior utilizes motion planning to formulate a collision-free plan for
driving the humanoid from its current configuration to one that allows grasping of a
specified object with a “hand” of the robot. More formally, given an objectO at opera-
tional space configurationY and a set of feasible homogeneous transformationsZ, the
reach behavior is to drive the robot in a collision-free manner to a configuration such
that one of the hands (specifically, a hand that is not currently grasping an object) is at
operational space configurationW , whereW is a composition of transformationsZ2Z
andY .
Reach currently handles three of the five subcategories of the MTM-1 reach element
described in Section 4.2.2.1. Reach does not provide reaching to get the hand out of
the way or in position for the next movement (this is accomplished as needed by other
tasks) or reaching that requires “search and select”.
The reach behavior is flexible in multiple ways. It utilizes motion planning for gen-
erating collision-free paths. The program exits prematurely if the object is graspable
49
MTM element Achieved
Reach
to object in fixed location
to object in variable location
to object jumbled with other objects
to small object
to indefinite location
Move
an object to other hand or against a stop
an object to approximate location
an object to exact location
Turn and apply pressure
Grasp
pickup
regrasp
transfer
among a jumbled collection of objects
contact / slide / hook
Position
loose
close
exact
Release
normal
contact
Disengage
loose
close
tight
Eye movements
Body, leg, and foot motion
foot, leg, or foreleg motion
sidestep

bend, stoop, kneel, or arise

sit
walk

Table 4.1: The list of primitive elements of MTM and whether or not they are imple-
mented by the task behaviors in this chapter. indicates that the element is fully imple-
mented, indicates that the element is partially implemented, and indicates that the
element is not implemented.

means that the element is implemented indirectly via a
skill in the common skill set or another task behavior, or both.
50
but not already grasped, thereby avoiding unnecessary planning. Reach can also use
variable kinematic chains; if both arms are “free”, then one can be used to reach to the
object while the other can be positioned for maneuvering in tight spaces, but if one arm
is occupied, then the task behavior can still be run. Additionally, if one arm is cur-
rently grasping an object, reach employs the other arm to prepare for grasping. Finally,
reach can utilize multiple target hand configurations for grasping. If one configuration
is unreachable due to joint limits or obstacles, another will be attempted automatically;
the multiple hand configurations also may be used for grasping a tool in various ways
for performing several tasks.
Reach, unlike many of the primitive task behaviors in the Task Matrix, requires
closed-loop execution to permit precise interaction with the environment. Precise reach-
ing is complicated by the nonholonomically constrained bases of most humanoids; if the
robot’s base deviates from its intended trajectory, error feedback may be insufficient to
draw the robot back to the desired path. This difficulty is illustrated in the next chapter,
in which it is seen that even simulated robots can deviate from prescribed trajectories.
Reach monitors trajectory execution and utilizes a mechanism analogous to operational
space control [SS00] to keep the robot’s hand in the desired operational space config-
uration. In particular, inverse kinematics is used with a reference posture criterion to
keep the hand in the determined operational space configuration while simultaneously
minimizing the distance to the determined joint space configuration.
parameters:
duration the duration of the movement (not the planning)
object the symbolic identifier of the object to which to reach for grasping
kinematic chains: base, torso, both arms
1
1
Reach can utilize a single arm if both arms are not free
51
Figure 4.5: A depiction of the reach task behavior in action. This figure shows the
process of reaching to a broom in a simulated real-world environment in a collision-free
manner.
skills: degrees-of-freedom, motion planning (configuration space to operational
space), joint position / velocity / acceleration query, motion control, forward kine-
matics, inverse kinematics, grasp configuration, locomotion
4.3.2 Position
Position is analogous to reach with a tool or object used as the end-effector of the robot,
rather than the hand. Correspondingly, much of the same programming code from the
reach behavior is used to realize position; subsequently, position suffers from the same
limitations described above (other than pregrasping, which is not applicable). The posi-
tion behavior can be formally specified as follows. Given an objectO grasped by the
52
robot and a set of operational space configurationsZ, position should move the robot in
a collision-free manner to a configuration such thatO is at configurationZ2Z.
The position behavior corresponds to the MTM-1 elements move and position. The
precision required to move an object is not considered; thus, the two MTM-1 elements
are able to be combined into a single task behavior. The motion-control nature of the
position behavior means that it is unable to move objects in ways that require interaction
with the environment. For example, position is unfit for using a tool to compress a
spring. Subsequently, position does not handle all cases of the MTM-1 position element:
it cannot handle cases that require “light” or “heavy” pressure (see Section 4.2.2.5).
However, the Task Matrix position behavior does not need to consider the symmetry
of the object or its ease of handling; MTM must consider both. Similarly, the task
behavior need not consider moving the object to an indefinite location, as is specified in
the MTM-1 move element, because the target location is a requisite parameter (i.e., the
goal-transforms parameter, see below) for the position behavior.
Position, like reach, requires closed-loop execution.
Figure 4.6: Using the position behavior to move a tennis ball over the table
53
parameters:
duration the duration of the movement (not the planning)
object the symbolic identifier of the object to position
goal-transforms a list of valid goal transforms that describe how the object may
be positioned
preconditions: grasping(object)
kinematic chains: base, torso, both arms
2
skills: degrees-of-freedom, motion planning (configuration space to operational
space), joint position / velocity / acceleration query, motion control, forward kine-
matics, inverse kinematics, grasp configuration, locomotion
4.3.3 Grasp
The grasp task behavior is used for grasping objects for manipulation. Grasp utilizes
predetermined postures of the fingers to grasp an object tightly; these postures are
defined such that some deformation of the grasped object would occur if the object stiff-
ness were sufficiently low. Whether or not deformation occurs
3
, the attempt to achieve
this posture with motion control will cause motor torques to be applied to the fingers
continually. This application is necessary to generate contact forces to achieve suffi-
cient sticking friction between the fingers and the object.
The strategy above is feasible, if not necessarily advisable for physically embodied
robots. Uncertainty in object position and orientation can make this approach difficult.
2
Position can utilize a single arm if both arms are not free
3
In rigid body simulation, which is employed in the next chapter, deformation cannot occur.
54
For interaction with the environment, it is often preferable to utilize an interaction con-
trol scheme [SS00] (e.g., force control); such an approach lies outside of the scope of
this thesis and is discussed further in Chapter 6.
The grasp behavior is formally specified as follows. Given an objectO at operational
space configurationX and the current robot configurationc2C, attachO to the robot’s
hand such that (a)O is at configuration X at robot configuration c and (b) a forward
kinematics functionf
O
:C!O can be determined such that the configuration forO is
dependent upon the robot’s configuration.
The grasp behavior currently does not handle four of five of the MTM-1 grasp sub-
categories. “Regrasping” and “transfer grasping” can be readily implemented using
position-control, and can thus be incorporated into the Task Matrix. However, grasping
among a jumbled collection of objects and the “contact”, “slide”, and “hook” grasps
will likely require the Task Matrix to be extended to encompass interaction control.
Figure 4.7: Before and after pictures of using grasp to clutch a broom
Note that the reach behavior (see above) is responsible for positioning the robot hand
such that grasping can occur.
parameters:
object the symbolic identifier of the object to position
55
Figure 4.8: Depiction of using the grasp behavior to clutch a tennis ball
preconditions: ready-to-grasp(object) and graspable(object)
kinematic chains: fingers
skills: degrees-of-freedom, motion control, attach object
4.3.4 Release
Release is used to release the grasp on an object. It utilizes a “rest” posture for the robot
hand (defined in a robot-specific posture file), and generates joint-space trajectories to
drive the fingers from the current grasping configuration to the rest posture. Note that
release neither secures the object in a safe location nor necessarily drops the object;
rather, the fingers only release the object from the grasp. Thus, release is equivalent to
the MTM-1 “contact” release (see Section 4.2.2.6).
The release behavior is formally specified as follows. Given a grasped objectO at
operational space configurationX, detachO from the robot’s hand such that (a)O is at
configurationX and (b) no forward kinematics functionf
O
:C!O can be determined
such that the configuration forO is dependent upon the robot’s configuration.
parameters:
56
duration the duration of the movement (not the planning)
object the symbolic identifier of the grasped object to release
preconditions: grasping(object)
kinematic chains: hand
skills: degrees-of-freedom, joint position / velocity / acceleration query, motion
control, detach object
Figure 4.9: Using release to relinquish the grip on the vacuum
4.3.5 Fixate
The fixate behavior focuses the robot’s view on both moving and non-moving objects.
Fixate was developed for two purposes. First, it aims to make the appearance of executed
tasks more human-like by directing the robot to look at objects that it is manipulating.
However, the primary objective of fixate is to facilitate updating of the robot’s model of
the environment where it is changing (i.e., at the locus of manipulation).
The fixate behavior can be formally specified as follows. Given an object O at
Cartesian-space positionX, function :!R (defined below), and current con-
figuration of the robot2C, drive the robot to a configurationc

such that (c

)< (c)
57
and c

2C
free
, if such a configuration c

exists. is a function that determines the
distance from the current bearing to the desired bearing of the robot’s view (without
consideration of the “roll” of the robot’s head); the function is defined as :
2
+
2
,
where and are determined as seen in Figure 4.10.
The fixate behavior as currently implemented does not quite adhere to the formal
specification above. Rather, fixate uses inverse kinematics to move the robot toward
the configuration
@
@c
, where c2C is the current configuration of the robot. If the
configuration obtained by this gradient descent method is not collision-free, then the
task behavior terminates; otherwise, the new configuration c
@
@c
(c) is input to the
motion controller. Thus, no planning is used in an attempt to move around obstacles in
the current implementation.
Fixate corresponds only roughly to MTM-1’s eye movements element; the former
specifies head and base movement, while the latter specifies only eye movement. How-
ever, both the fixate behavior and the eye movements element accomplish the same task,
that of “looking” at a specific location.
Fixate is able to utilize variable kinematic chains. Nominally, it can control both
the base and head orientation; this allows the robot to turn around to look at objects
behind it. During object manipulation, however, the degrees-of-freedom in the base are
typically unavailable to the fixate behavior. In this latter case, fixate is able to utilize
only the degrees-of-freedom in the head to focus on manipulated objects.
The fixate behavior can operate in both recurrent and non-recurrent modes. In the
former mode, the behavior stops only when the behavior is forcibly terminated. In the
latter, the behavior ends as soon as the goal is achieved (the head is facing the target).
parameters:
max-diff the maximum differential scalar between the current and desired con-
figurations (determines how fast the robot’s head and base can turn)
58
x
y
z
x
y
z
!
x
y
z
"
(a)
x
y
z
x x
y
z
(b)
Figure 4.10: The determination of and for the function in Section 4.3.5. (b)
depicts the robot and the target, a tennis ball; the frame of the robot’s current view is
displayed in black and the desired view (that allows fixating on the target) is displayed in
red. (a) shows the sequence of rotations necessary (first a “yaw” of radians, followed
by a pitch of radians) to get from the current frame to the desired frame.
59
target the symbolic identifier of the object on which to fixate
recurrent if set to true, the behavior is recurrent (see above)
preconditions: none
sent messages:
goal-achieved sent whenever the goal is achieved (i.e., the head is facing the
target)
goal-not-achieved sent whenever the goal is not achieved (i.e., the head is not
facing the target)
kinematic chains: base and head
4
skills: degrees-of-freedom, joint position/ velocity / acceleration query, motion
control, forward kinematics, inverse kinematics, collision checking, locomotion,
robot view
4.3.6 Explore
Explore is actually a macro task composed of the primitive tasks scan (see below)
and random-walk for actively sensing (i.e., mapping and modeling) the environment.
Explore is neither primitive itself, nor is it typically used as a primitive component in
a complex task. Nevertheless, it is included in this section because of its utility and
prevalence; the explore behavior is typically called before execution of any other task
behaviors so that the robot can work under a more accurate model of the environment.
Explore can be informally defined as follows. Given a regionXR
3
of the envi-
ronment, continuously drive the robot to new configurations such that the robot’s sensors
4
If the base is occupied, only the head will be utilized.
60
Figure 4.11: Depiction of the action of the fixate behavior; the simulated robot is com-
manded to focus on the dustbuster. The robot turns on its base while simultaneously
orienting its head.
perceive every possible point ofX, given infinite time. Naturally, not every point inX
may be perceivable due to the given robot’s kinematics and the obstacle layout of the
environment.
The random-walk behavior executes a random walk around the environment (or
within the specified bounding region) using a state machine (see Figure 4.12 composed
of three phases: turn, forward, and reverse. Turn uses motion planning to turn the rotate
the robot’s base to a random, collision-free orientation. Forward causes the robot to
locomote directly forward, unless there is an obstacle preventing immediate progress
(which triggers the turn behavior). If turn fails, it triggers the reverse behavior for back-
ward locomotion. The random-walk state machine enables exploration to occur in a
robust manner.
Explore not only identifies the objects in the environment for future reference, it
also models the environment for use with collision avoidance. Additionally, explore
61
uses this incrementally updated model to avoid collisions while performing its random
walk. The behavior of the state machine described above decreases the likelihood of
a collision with parts of the environment that remain to be modeled; the random walk
attempts to move forward (i.e., the direction that the base is facing) as much as possible.
The scanning motion of the head makes it likely that the region into which the robot is
walking has already been modeled.
Start
Turn Turn
Forward
Reverse
Figure 4.12: The random walk state machine. The state machine executes for the spec-
ified duration. Solid lines indicate nominal transitions; dotted lines indicate transitions
due to failure. For example, if the robot fails to move forward, it will then attempt to
move backward. Failure occurs when a behavior would cause collision with the envi-
ronment or result in the robot moving outside of the desired exploration region.
In addition to the random-walk behavior, the scan behavior is used to move the head
from side to side and upward and downward in a periodic manner. This movement
allows the robot to perceive a greater part of the environment than would be possible by
keeping the head stationary.
parameters:
duration the duration of the task execution
62
Figure 4.13: A sample run of the explore behavior using the simulated depth sensor.
As the depth sensor (depicted by the red polyhedral outline protruding from the robot’s
head) scans a surface, a brown texture is drawn over the surface; this brown texture
represents the robot’s model of the environment for use with collision detection. Note
that the frames are not sampled from the animation at uniform intervals.
scan-period the period of the scanning movement of the scan subtask
region the region of the world to explore (describes a bounding box)
preconditions: none
kinematic chains: base and head
skills: degrees-of-freedom, collision checking, joint position / velocity / accelera-
tion query, motion control, forward kinematics, inverse kinematics, locomotion
Explore makes an assumption that potentially limits the performance of this behavior
across humanoid robot platforms: it presumes that the robot’s sensory array is located
63
on its head. If, for example, the robot contains sensors on its arms, explore may fail
to sense as much of the environment as the robot is capable, even given unlimited time
to explore. Additionally, the explore behavior does not explore the environment in an
efficient manner; random walking frequently reexamines portions of the environment
that were recently scanned.
4.3.7 Postural
The Postural behavior is used frequently within the Task Matrix to drive one or more
kinematic chains of the robot to a desired posture. It employs motion planning to achieve
the commanded posture in a collision-free manner. Additionally, the postural behavior
is somewhat intelligent; if the posture consists of a single arm or leg, the behavior will
mirror the posture to an alternate limb randomly (if both limbs are free) or determin-
istically (if one limb is occupied performing another task or is already in the desired
posture).
The postural behavior is defined formally as follows. Given the robot’s current
configuration c 2 C, a projection function g : Y ! C (where Y C) that maps
components ofC not found inY to their current joint positions, and vectorc
G
2Y such
thatg(c
G
)2C
free
, drive the robot in a collision-free manner fromc tog(c
G
).
Postures are certainly robot dependent, but the postural behavior remains robot inde-
pendent. Desired postures are stored externally from the behavior and may be quickly
exchanged when porting to a new robot.
parameters:
duration the duration of the task execution (not the planning)
kinematic chains: variable
5
5
The kinematic chains used by the postural behavior are dependent on the posture to be achieved.
64
skills: degrees-of-freedom, motion planning (configuration space to configuration
space), joint position / velocity / acceleration query, motion control
Figure 4.14: Using the postural behavior to prepare the simulated robot for waving
4.3.8 Canned
The canned behavior is an abstract task behavior implemented by two derived behav-
iors, periodic-canned and aperiodic-canned. A canned behavior commands the robot to
follow a set of predetermined (i.e., “canned”) joint-space trajectories. Correspondingly,
canned behaviors are primarily useful for open-loop movements that do not involve
interactions with objects (e.g., waving, bowing, etc.).
The canned behavior can be formally defined as follows. Given a desired duration
T and a set ofk configuration space trajectory functionsx
1
;x
2
;:::;x
k
(defined below),
continually send kinematic commands x
1
(t)[x
2
(t):::[x
k
(t) to the robot for time
t = [0;T ]. Eachx
i
is a function of the formx
i
: [0;T ]!R
3
; the output corresponds to
position, velocity, and acceleration components for specific degrees-of-freedom of the
robot
65
The primary difference between the two derived behaviors, periodic-canned and
aperiodic-canned is that the former handles periodic movements (e.g., waving) while
the latter handles aperiodic (i.e., point-to-point) movements. Both derived behaviors
currently require that the joint-space positions of degrees-of-freedom for the utilized
kinematic chains coincide with the beginning of the trajectories. This requirement pre-
vents large discontinuities from damaging the robot due to excessive torque commands
but is somewhat limiting; for example, the robot is forced to return to a home position
to begin waving, rather than converging to a nearby point in the trajectory. Ijspeert et al.
[INS02] have demonstated a method that obviates this requirement, however, that future
versions of the canned behavior could incorporate.
4.3.8.1 Periodic-canned
parameters:
duration the duration of the task execution
kinematic chains: variable
6
skills: degrees-of-freedom, joint position / velocity / acceleration query, motion
control
4.3.8.2 Aperiodic-canned
parameters:
duration the duration of the task execution
period the period of the movement
6
The kinematic chains used by the periodic-canned behavior are dependent on the trajectory sets
utilized.
66
kinematic chains: variable
7
skills: degrees-of-freedom, joint position / velocity / acceleration query, motion
control
Figure 4.15: Utilizing an aperiodic-canned behavior to get the simulated robot to wave
4.4 Summary
This chapter presented a set of primitive task behaviors that utilize the motion-control
paradigm. These primitive behaviors can be continually improved, both to better the
performance of the individual tasks and to boost the effectiveness of the complex task
behaviors. The next chapter validates these primitive tasks on two simulated humanoid
robots and uses the primitives to construct several complex task behaviors.
7
The kinematic chains used by the aperiodic-canned behavior are dependent on the trajectory sets
utilized.
67
Chapter 5
Validation
5.1 Introduction
This chapter validates both the Task Matrix framework for robot independent execution
of tasks and the set of primitive task behaviors presented in the previous chapter. First,
the simulated environments and the humanoids used in the validation are introduced.
Details of the common skill set (introduced in Chapter 3) implementation are also given.
Next, the primitive task behaviors are validated on both robot platforms under various
conditions. Finally, a set of complex task behaviors is described and depicted to show
the viability of the primitive task behaviors toward realizing complex behavior.
It is evident by viewing the execution of the task behaviors (movie depictions of the
performances are available from http://robotics.usc.edu/drumwrig/movies.html)
that the behaviors are able to meet the formal task specifications given in the previous
chapter on the simulated humanoid robots described below.
5.2 Environments
Multiple environments were used in the validation: a “sparse” environment (Figure 5.1)
and two “dense” environments (Figure 5.2). The three environments are populated by
objects and obstacles (the latter two more so than the first). The sparse environment
contains objects to perform the vacuuming task (described in Section 5.7.4) as well as
68
a few obstacles. The dense environments are large and obstacles are dispersed through-
out; these two environments are useful at showing the ability of the simulated robots to
navigate amongst obstacles to accomplish their goals.
Figure 5.1: View of the sparse environment. The environment contains a hand vacuum,
broom, soda can (on table), and confetti (on table, not visible in image). The robot
testbeds are confined to the portion of the environment represented by the gray plane.
5.3 Robots
Three humanoids were utilized in the validation: two kinematically robots and
one dynamically simulated robot were used. The kinematic structures of the three
humanoids are depicted in Figure 5.4 and Figure5.5. These platforms are used to illus-
trate the viability of the Task Matrix for performing tasks on different robots using robot-
independent behaviors. The robots vary considerably both in number and placement of
the degrees-of-freedom. Additionally, the robots differ significantly in height; the height
disparity will frequently stymie an approach that attempts to retarget [Gle98] the motion
from one robot to another.
69
Figure 5.2: “Bird’s eye view” of the dense environment for kinematically simulated
robots. The environment contains a washing machine, dryer, and box of detergent (far
left); couch; clothes (bottom, left of center); stove and broom (bottom, right of center);
table and stool (top right); sink, coffee maker, and refrigerator (bottom right). Addi-
tionally, door entry ways are present throughout. The robot testbeds are confined to the
portion of the environment represented by the textured ground.
The three platforms provide a virtual three degree-of-freedom (two DOF translation
and one DOF rotation) base joint to the user. As Chapter 3 stated, the Task Matrix
assumes the presence of this virtual joint. The direct consequence of using this joint on
the two kinematically simulated robots is that, for all task behaviors that utilize loco-
motion (i.e., the reach, position, fixate, and explore), the robots’ legs do not move while
walking.
The remainder of this section briefly discusses the (simulated) physical properties of
the three robotic platforms.
5.3.1 Asimo
Asimo is the culmination of many years of development of walking humanoids by the
Honda Motor Corporation [HHHT98]. The kinematically simulated model stands 1.24
70
Figure 5.3: The dense environment for the dynamically simulated Bandit robot. The
environment contains a washing machine, dryer, couch, stove, table (with tennis ball),
stool, television, sink, and refrigerator. The Bandit robot is confined to the portion of
the environment represented by the textured ground.
meters high and contains 26 DOF: a 2 DOF neck, two 6 DOF arms (including fingers),
and two 6 DOF legs.
5.3.2 Mannequin
The mannequin is a kinematically simulated humanoid robot. It stands 1.48 meters
high and contains 27 DOF: a 3 DOF neck, two 6 DOF arms, a two DOF torso, and
two 5 DOF legs. Unlike Asimo, the mannequin has no fingers. Grasping occurs via
71
Neck (2)
Shoulder (3)
Elbow (1)
Wrist (1)
Fingers (1)
Base
[virtual] (3)
Hip (3)
Knee (1)
Ankle (2)
1.24m
1.48m
Neck (3)
Shoulder (3)
Elbow (1)
Wrist (2)
Knee (1)
Ankle (2)
Base
[virtual] (3)
Hip (2)
Torso] (2)
Figure 5.4: The specifications of the kinematically simulated robots utilized in the vali-
dation; Asimo is on the left, the mannequin is on the right. Asimo is 1.24m tall and con-
sists of 26 degrees-of-freedom (plus the 3 DOF virtual base); the mannequin is 1.48m
tall and consists of 27 DOF and the 3 DOF virtual base.
electromagnetic-type affixation, which is simulated in the skill layer (i.e., the grasp task
behavior did not have to be modified).
5.3.3 Bandit II
Bandit II is the second iteration of a humanoid project developed by the Interaction
Lab at the University of Southern California. The physically embodied robot (shown in
Figure 5.6) has a fixed base and 19 degrees-of-freedom; it is controlled via an embedded,
black-box PID controller. The dynamically simulated model of Bandit II is mounted
on a differentially-driven base; this modification provides locomotion, which the Task
Matrix requires. The model has also been augmented with additional joints in the arm
for greater dexterity, for a total of 23 degrees-of-freedom, as seen in Figure 5.5.
72
M . ECK # LA W % LB O W 7 R IST 7 HEEL " ASE ;VIR TUAL= 3 HOULDER Figure 5.5: The specifications of the dynamically simulated Bandit II robot. Bandit is
1.75m tall with 51 DOF; although the base is theoretically unconstrained (i.e., six DOF),
gravity and a virtual counterweight effectively constrain the base to three DOF.
The model is simulated using Featherstone’s Articulated Body Method [Fea87] for
reduced-coordinate articulated bodies with the Physsim simulation library [Dru07]. Key
simulation parameters are detailed below:
integration step-size: 1e
4
downward acceleration due to gravity: 9.8m/s
2
simulated robot mass: 72 kg
moments-of-inertia computed using triangle meshes from geometric model with
Mirtich’s method [Mir96] and constant density
In the absence of contact, the Articulated Body Method permits reasonably accurate
robotic simulation. Unfortunately, the state-of-the-art in contact modeling for rigid bod-
ies is primitive. Analytical methods for determining nonpenetration constraints run in
73
Figure 5.6: The physically embodied Bandit II robot, upon which the two dynamically
simulated robots are based.
polynomial time in the number of contact points in the expected case, and exponential
time in the worst case. Determining whether non-impulsive forces can be used to satisfy
nonpenetration and frictional constraints is NP-hard [Bar94]: there are multiple known
inconsistent configurations (i.e., configurations for which there is no solution), such as
Painlev´ e’s problem [Pai95]. Recent work has incorporated non-penetration and fric-
tional constraints into the time-stepping equations [AP97, ST00, AP02]. These formu-
lations generally permit proving the existence of solutions, but have yet to be extended
to forward dynamics of robots in generalized (i.e., joint-space) coordinates.
Several kludges were required to get the simulated robot to exhibit similar behavior
to that observed in the physical world as a result of the problems noted above. For exam-
ple, the robot drives around the environment using forces applied to the base; sticking
74
friction is poorly modeled, which causes the robot’s base to drift considerably while both
at rest and during locomotion.
1
Poor modeling of sticking friction affects grasping as
well. We simulate grasping using virtual springs and dampers applied between the end-
effectors and the target object. Simulated grasping is not significantly advanced beyond
this technique at this time; Miller’s thesis is representative of the state-of-the-art on sim-
ulated grasping [Mil01], and that work simulates dynamics only for objects (robots are
kinematically simulated). Though the method used here for simulated grasping is more
effective than using sticking friction, it tends to make the differential equations “stiff”
[Gea71], which leads to numerical instability. This issue will be discussed further in
Section 5.6.1.
In addition to the work-arounds described above, the rotational inertia of the robot
base was made extremely high around all but the up-axis. This has the effect of a large
virtual counterweight placed under the center-of-mass of the base. This virtual counter-
weight precludes the need to provide balancing control for the robot.
5.4 Sensing
The two kinematically simulated platforms utilize an identical simulated camera that
functions both as a three-dimensional depth sensor and object recognition system. The
camera employs a 160x124 resolution with a 35 degree field-of-view. It can sense as
close as .2m and as far as 1.5m (unless noted otherwise, e.g., in Figure 5.30). The
sensing is idealized in several ways. All points in the camera’s field of view are sensed
equally well. It is also assumed that, for purposes of object recognition, if an object
lies in any part of the field of view and is not completely obstructed by other objects, the
1
Physically embodied robots will drift from a predicted path due to imperfections in modeling (e.g.,
perfectly stiff tires, viscous friction, etc.). However, these imperfections tend to reduce energy from the
system rather than adding to it and leading to instability.
75
camera can identify that object uniquely with absolute certainty. The sensing boundaries
on the simulated sensor can be seen outlined in red in Figure 5.22. Note, however, that
the absence of this outline does not necessarily indicate the absence of the sensor; the
presence of the wireframe is ubiquitous in this chapter so that the direction that the
mannequin is facing can be readily determined.
As a depth sensor, the camera is able to construct a model of the environment usable
for collision detection and, by extension, motion planning. The model is constructed and
revised by the user-defined external module for updating the perceptual model described
in Chapter 3; specifically, an octree representation models the environment from the
depth readings in a passive manner. This is similar to the volumetric representation
of the environment constructed using a physically implemented humanoid robot with
stereo vision described in Kagami et al. [KKN
+
03].
As noted above, the simulated sensor is far from realistic. However, it does provide
a more challenging testbed for evaluation than would be possible using an omniscient
sensory model. The dynamically simulated robot does not employ simulated sensing
(i.e., it uses an omniscient sensing model); the validation for this platform concentrates
on dynamic issues like nonholonomic locomotion, imperfect control, and grasping.
5.5 Common skill set implementation
This section describes implementation details of the common skill set used for vali-
dation; these details implicitly explain certain artifacts observed in the figures in this
chapter (e.g., the somewhat strange arm movements seen during execution of the reach
and position behaviors on the kinematically simulated humanoids.
76
5.5.1 Locomotion
Locomotion for the kinematically simulated robots is trivially accomplished given that
the degrees-of-freedom for the base are actual rather than virtual; thus, no translation is
necessary. This section will therefore focus on the locomotion skill for the physically
simulated Bandit II platform instead. The simulated Bandit II robot is a more challeng-
ing platform for which to provide locomotion given that it is underactuated; only two
degrees-of-freedom (the two wheels) are available for motion on the three-dimensional
manifold SE(2) [Gil06]. As a result, planning is generally necessary (via the motion
planning skills) to get from one point on SE(2) to another. Note that we plan under the
differential constraints, even though the robot is moved using forces applied directly to
the base; thus, the kinematics of the Bandit II robot adhere to the equations below:
_ x =
r
2
(u
l
+u
r
) cos
_ z =
r
2
(u
l
+u
r
) sin
_
=
r
L
(u
r
u
l
)
The planar position of the robot are described byx andz, is the orientation of the
robot,r is the radius of each wheel,L is the length of the wheel axle, andu
l
andu
r
are
the angular velocities of the left and right wheels, respectively.
5.5.2 Motion control
For the kinematically simulated humanoids, only the position component of the triple of
position, velocity, and acceleration commands is utilized. When a command is received
77
1.56994
1.56996
1.56998
1.57
1.57002
1.57004
1.57006
1.57008
1.5701
1.57012
0 10000 20000 30000 40000 50000 60000 70000 80000 90000
joint angle (radians)
time
Left shoulder joint
desired
true
Figure 5.7: Depiction of controller performance (joint position) for a single DOF in a
shoulder joint of Bandit II for execution of a periodic canned task over nine seconds.
by the skill set, the appropriate joint in the kinematic model of the robot is immediately
driven to the desired position.
Motion control for the physically simulated robot is far more involved. A composite
computed-torque PID controller achieves the desired motion. Specifically, a floating-
base inverse dynamics algorithm from Featherstone [Fea87] is employed along with the
contact forces determined from simulation to compute the actuator torques necessary to
yield desired joint accelerations. Control error is minimized using the PID (feedback)
component of the controller; feedback gains were tuned heuristically prior to incor-
porating computed torque control. Figures 5.7–5.12 demonstrate the effectiveness of
the controller for tracking trajectories. As figure 5.13 illustrates, the inverse dynamics
method is quite accurate and generally results in little error.
78
Figure 5.8: Depiction of controller performance (joint velocity) for a single DOF in a
shoulder joint of Bandit II for execution of a periodic canned task over nine seconds.
5.5.3 Motion planning (configuration space to configuration space)
The state-of-the-art in motion planning within configuration space is the balanced, bidi-
rectional rapidly-exploring random tree (RRT) [KV00, LaV06]. The RRT is probabilis-
tically complete: as the number of random samples tends to infinity, the probability of
finding a solution goes to unity (if a solution exists). Unfortunately, only a finite num-
ber of samples and time can be utilized. The implementation of the RRT used in the
validation indicates failure if a solution is not found within one minute.
Also pertinent to the RRT implementation is the means of collision checking of con-
tinuous configuration-space paths; all motion-planning algorithms require this ability.
The fastest algorithms for detecting collision along a continuous path typically operate
by discretizing the path into a number of samples, which are then checked individually
(though there are many alternative methods that do not adopt this approach; see [SSL05]
79
-0.02
-0.01
0
0.01
0.02
0.03
0.04
0.05
0 10000 20000 30000 40000 50000 60000 70000 80000 90000
joint acceleration (rad/sec^2)
time
Left shoulder joint
desired
true
Figure 5.9: Depiction of controller performance (joint acceleration) for a single DOF in
a shoulder joint of Bandit II for execution of a periodic canned task over nine seconds.
for one such approach). For simplicity, this is the approach that is employed here. The
path is discretized such that no two configuration space samples are farther than 0:1
apart.
2
The simulated Bandit II robot’s base is differentially constrained, and the motion
planner respects these constraints. To get from one configuration of the base (i.e., planar
position and orientation) to another, a local planner is used. This local planner operates
in three phases: orienting the robot to face the new planar position, moving forward
to the new planar position, and orienting the robot to the commanded orientation. The
local planner fails if it generates a posture in collision.
2
Units are meaningless for this quanitity because the configuration spaces are composed of spaces
with different topologies, such as Euclidean and SO(2).
80
Figure 5.10: Depiction of controller performance (joint position) for a single DOF in a
shoulder joint of Bandit II for execution of a postural task over one second. This plot
depicts the results of applying the torques from Figure 5.13.
The motion planner’s solution path, if any, will often contain unncessary intermedi-
ate configurations. A single pass over the solution path is made in an attempt to remove
such configurations.
5.5.4 Motion planning (configuration space to operational space)
Motion planning from configuration space to operational space presents additional chal-
lenges over planning purely in configuration space. For humanoid robots, reaching to a
given point in operational space (whether the end-effector is a hand, a foot, or the head)
is typically underconstrained: there are multiple (often infinite) points in configuration
space that correspond to a single operational space configuration.
81
Figure 5.11: Depiction of controller performance (joint velocity) for a single DOF in a
shoulder joint of Bandit II for execution of a postural task over one second. This plot
depicts the results of applying the torques from Figure 5.13.
The na¨ ıve approach to this problem utilizes collision checking and resolved-motion
rate control (RMRC) [BI66] (using a random initial configuration) to find a collision-
free, inverse kinematics solution followed by motion planning within configuration
space (using an algorithm like RRT) to obtain a collision-free path from the robot’s
initial state to the aforementioned solution. Unfortunately, this approach can fail to
find a solution when one exists. The RDT-IK algorithm, developed by Drumwright
and Ng-Thow-Hing [DNTH06b], addresses this issue, and is probabilistically complete
[LaV06]: as the number of random samples tends to infinity, the probability of finding
a solution tends to unity if a solution exists.
RDT-IK works by generating a RRT in configuration space. For tree nodes that yield
configurations for the end effector sufficiently close to an operational-space goal (within
two meters in this implementation), RMRC begins, starting from the close node. Like
82
Figure 5.12: Depiction of controller performance (joint acceleration) for a single DOF
in a shoulder joint of Bandit II for execution of a postural task over one second. This
plot depicts the results of applying the torques from Figure 5.13.
the RRT algorithm described above, the RDT-IK algorithm discretizes the path between
two configuration-space samples so that no two samples are farther than 0:1 apart.
Note that multiple images of robots reaching in this chapter, including Figures 5.19
and 5.20, depict the robots with strange configurations of the arm that is not reaching.
This artifact is due to the RDT-IK algorithm; later implementations of this algorithm,
such as that used for the Bandit II skillset, use biased sampling to minimize this effect.
5.5.5 Collision checking
Collision checking is performed differently for the kinematically and dynamically sim-
ulated robots. For the kinematically simulated robots, collision checking uses the octree
83
Figure 5.13: Depiction of torque commands for a single DOF in a shoulder joint of
Bandit II for execution of a postural task over one second; the results of applying these
torques can be seen in Figures 5.10–5.12. Contributions from computed torque as well
as error feedback (proportional, derivative, and integrative terms) are plotted, as well
as the composite controller. The computed torque component is responsible for the
majority of controller output, as feedback torque magnitudes are close to zero.
model of the environment described in Section 5.4 (for checking against the environ-
ment) and the polyhedral models of the robots (for self-collision checking). The poly-
hedral collision checker for self-collision checking is V-Collide [mRGoMPBSA].
The dynamically simulated robot uses the collision checker embedded in the phys-
ical simulator; the simulator’s collision checker is a modified version of the Proximity
Query Package (PQP) library [GLML].
84
5.5.6 Inverse kinematics
The inverse kinematics method employed is the Jacobian pseudo-inverse [NH86], com-
puted using the formulaJ
T
(JJ
T
)
1
(whereJ is the Jacobian relating joint space veloc-
ities to end effector velocities). The pseudo-inverse is determined using the singular
value decomposition (SVD) to avoid remove ill-conditioning due to singularities in the
Jacobian: J
+
= V
+
U
T
, where UV
T
is the SVD of J and
+
is the tranpose of
with every nonzero entry replaced by its reciprocal. The inverse kinematics method
terminates if the operational-space error is within 1e
4
units (error is computed over the
six-dimensional operational-space vector of concatenated position and orientation, and
thus has no physical meaning); if inverse kinematics requires more than 1000 iterations,
the method terminates prematurely and indicates failure.
5.5.7 Grasp configuration
The grasp configuration skill is implemented using a table lookup method for a fixed
number of objects (currently a tennis ball, a broom, and a hand vacuum). At least one
relative transformation from each object is specified; multiple transforms are specified
when there are multiple ways to grasp an object (e.g., for the tennis ball and the broom).
5.6 Validated primitive task behaviors
Most of the primitive task behaviors described in the previous chapter were validated
in this section (the exceptions are the aperiodic canned task behavior, which is almost
identical to the periodic canned task behavior in both functionality and implementation,
and the grasp and release behaviors, for which successful execution is not apparent
on the mannequin for reasons described in Section 5.3). These behaviors are validated
85
on the simulated robots in the various environments. None of the task behaviors was
modified in any way before being executed on an alternate robot platform; similarly,
none of the task behaviors contains any robot specific code.
(a) (b) (c)
Figure 5.14: The result of running the reach behavior on the simulated Asimo robot on
three different targets: (a) a hand vacuum, (b) a tennis ball, and (c) a broom.
(a) (b) (c)
Figure 5.15: The result of running the reach behavior on the simulated mannequin robot
on three different targets: (a) a hand vacuum, (b) a tennis ball, and (c) a broom.
86
Figure 5.16: The result of running the reach behavior on the simulated Bandit II robot
on the tennis ball target.
87
(a)
(b)
Figure 5.17: “Bird’s eye view” of Asimo (a) and the mannequin (b) reaching to a broom
in a simulated environment. This task requires locomotion as well as navigation through
an obstacle-ridden environment.
88
(a) (b)
(c) (d)
Figure 5.18: The Bandit II robot reaching to a tennis ball in a simulated environment.
89
(a) (b)
(c) (d)
(e) (f)
Figure 5.19: A sequence of reaches on the simulated Asimo to the tennis ball, which is
moved interactively. This picture demonstrates the ability of reach to attain targets in
various locations with different obstacle configurations.
90
(a) (b)
(c) (d)
(e) (f)
Figure 5.20: A sequence of reaches on the mannequin to the tennis ball, which is moved
interactively. This picture demonstrates the ability of reach to attain targets in various
locations with different obstacle configurations.
91
5.6.1 Reach / Position
The reach and position behaviors are nearly identical; the latter utilizes a grasped object,
while the former does not, but the majority of code remains unchanged from one behav-
ior to the other.
The success of the two behaviors can be determined partially by their ability to
reach to different target objects amongst different obstacle configurations. Figures 5.14,
5.15, and 5.16 demonstrate the ability of reach to function with different target objects.
Figures 5.17 and 5.18 show that reach is able to use locomotion to navigate amongst
obstacles. And Figures 5.19 and 5.20 illustrate the ability to reach to multiple targets
sequentially.
5.6.2 Grasp
Figures 4.7 and 4.8 have already depicted using grasp to get the simulated Asimo to
grasp both a broom and a tennis ball. The mannequin does not have fingers, so “grasp-
ing” for that model produces no visible effect. Figure 5.27 depicts the simulated Bandit
Ii robot grasping a tennis ball. The difficulty of modeling contact in physical simulation
prevents the robot from grasping an assortment of objects.
5.6.3 Release
Figure 4.9 previously depicted release on Asimo holding a vacuum. As is the case with
grasp, releasing an object grasped by the mannequin produces no visible effect. Figure
5.28 depicts the simulated Bandit II robot releasing a tennis ball.
92
5.6.4 Fixate
Fixate is not quantitatively evaluated here (e.g., using magnitude of differential orienta-
tion). Rather, it is shown that fixate is able to give the appearance of focusing on both
static and moving objects successfully. Figures 4.11 and 5.21 show both Asimo and the
mannequin fixating on a static object (the hand vacuum). Figures 5.25 and 5.23 demon-
strate the ability to focus on moving objects. Finally, Figure 5.26 shows that fixate is
relatively robust; the behavior will not send motor commands that will cause collision.
5.6.5 Explore
The explore macro task behavior attempts to model the robot’s environment. As the
previous chapter indicated, this behavior is not primitive in either the sense that it is an
indivisible behavior or in the sense that it is used to compose more complex tasks. How-
ever, explore is generally necessary to obtain both an accurate model of the environment
for motion planning and a map of objects in this environment. This behavior is of crit-
ical importance to the kinematically simulated robots, which use simulated perception,
and is thus validated here. Figures 4.13 and 5.29 depict explore in operation on the
simulated Asimo and mannequin, respectively. The behavior’s operation on the dense
environment is shown in Figures 5.30 and 5.31. As seen in these figures, the model of
the environment becomes more accurate as the behavior continues execution.
5.6.6 Postural
The postural behavior is relatively simple; it drives the robot to a desired posture using
motion planning to avoid collisions. Similar to the canned behavior (see below), pos-
tures are robot specific and are stored in a XML file external to the task behavior; the
XML files that define the posture to prepare for waving are listed in Figure A.1 (for
93
Asimo), Figure A.2 (for the mannequin), and Figure A.3 (for Bandit II). The results of
running this behavior on the three simulated robots can be seen in Figures 4.14, 5.32,
and 5.33.
5.6.7 Canned
The canned behavior is relatively “brittle”: it runs open-loop, and thus does not attempt
to detect impending collision. As the previous chapter noted, the canned behavior does
determine whether the appropriate kinematic chain of the robot is in the posture corre-
sponding to the beginning of the trajectory. The canned behavior is validated here by
having each simulated robot perform a waving motion.
Though canned utilizes no robot specific programming, it does reference a XML file
that describes the robot-specific motions. The versions of the XML file that are specific
to the platforms used for validation are listed in Figures A.4, A.5, and A.6. Figure
5.35 shows both kinematically simulated humanoids waving and Figure 5.36 shows the
dynamically simulated Bandit II robot waving.
5.7 Developed complex task behaviors
This section discusses several complex task behaviors composed from Task Matrix prim-
itives. Some of these macro task behaviors (i.e., pickup and putdown) can be used as
primitive behaviors, illustrating the capability for the Task Matrix to recursively subdi-
vide complex tasks into simpler subtasks. The macro tasks discussed here are imple-
mented using instantiations of the message-driven machines presented in the remainder
of this section. None of these macro task behaviors has been modified to facilitate exe-
cution on an alternate robot platform; additionally, there exists no robot-specific code
within the macro task behaviors.
94
The complex task behaviors are validated only on the kinematically simulated
humanoids. The primitive means of modeling contact currently precludes prolonged
sequences of behaviors.
5.7.1 Pickup
Pickup was developed due to the frequent need to perform a grasp immediately follow-
ing a reach. Additionally, this behavior fixates on the target object during execution
to achieve human-like performance and to facilitate updating the perceptual model for
objects to be manipulated. Figure 5.39 presents the diagram for the message-driven
machine used to realize the pickup behavior. The MDM executes the reach behavior
first; almost immediately thereafter, the fixate behavior is called; delaying execution
of the fixate behavior allows the reach behavior to secure the base degrees-of-freedom.
After reach successfully completes, the grasp behavior executes. When grasp com-
pletes, fixate is terminated.
Note that pickup does not actually transport the target object anywhere, as Figures
5.37 and 5.38 depict. These figures show a marked difference in the behavior of the two
robots from that of the reach behavior: pickup has the robot focus on the target (using
fixate) while reaching.
95
Figure 5.21: Successive frames depicting the execution of the fixate behavior on the
mannequin (target object is the hand vacuum).
96
Figure 5.22: Successive frames depicting the execution of the fixate behavior on the
mannequin (target is Asimo walking in a “figure eight” pattern). Note that an omniscient
sensing model is used (rather than the simulated depth sensor) for simplicity.
97
Figure 5.23: Successive frames depicting the execution of the fixate behavior on Asimo
(target is the rolling tennis ball); the first frame depicts the state before the behavior is
executed. Note that Asimo is not able to look fully downward at the tennis ball; for this
reason, an omniscient sensing model is used (rather than the simulated depth sensor).
Figure 5.24: Successive frames depicting the execution of the fixate behavior on Bandit
II (target is the tennis ball).
98
Figure 5.25: Successive frames depicting the execution of the fixate behavior on the
mannequin (target is the rolling tennis ball); the first frame depicts the state before the
behavior is executed. As the caption in Figure 5.23 notes, Asimo is not able to look
fully downward at the tennis ball, so an omniscient sensing model is used (rather than
the simulated depth sensor). The same omniscient sensing model is used in this example
for consistency even though the mannequin is capable of looking directly at the tennis
ball.
99
Figure 5.26: Depiction of one form of robustness of the fixate behavior; as the simulated
robot attempts to turn, impending collision with the table halts the behavior immediately
before contact would occur.
100
Figure 5.27: Bandit II grasping a tennis ball.
Figure 5.28: Bandit II releasing a tennis ball.
101
Figure 5.29: Successive samples taken from one run of the explore behavior using the
simulated depth sensor. As the depth sensor scans a surface (except the floor), a brown
texture is drawn over the surface; this brown texture represents the robot’s model of the
environment within the perceptual model. Note that the frames are not sampled from
the animation at uniform intervals.
102
(a)
(b)
(c)
Figure 5.30: Images taken from the explore behavior executed on Asimo in the dense
environment at one minute (a), five minutes (b), and fifteen minutes (c). The maximum
range on the depth sensor was temporarily increased to 3m for better performance.
103
(a)
(b)
(c)
Figure 5.31: Images taken from the explore behavior executed on the mannequin in the
dense environment at one minute (a), five minutes (b), and fifteen minutes(c). In contrast
to Figure 5.30, the depth sensor has a maximum range of 1.5m; additionally, the octree
visualization is coarser to decrease memory usage.
104
Figure 5.32: Using the postural behavior to prepare the mannequin for waving
Figure 5.33: Using the postural behavior to prepare the Bandit II robot for waving.
105
Figure 5.34: Using a postural behavior to prepare a kinematically simulated robot for
waving; an obstacle has been added in this case, for which the behavior uses motion-
planning to deftly avoid.
106
Figure 5.35: The waving task behavior executed on both the Asimo and mannequin
simulated robot platforms
Figure 5.36: The waving task behavior executed on the simulated Bandit II robot plat-
form.
107
(a) (b)
(c) (d)
Figure 5.37: Samples taken from Asimo performing the pickup behavior. (a) depicts
before execution begins. (b) depicts the first phase, for which fixate focuses on the target
(the vacuum). (c) depicts reaching to the vacuum (using reach). (d) depicts grasping the
vacuum using grasp. Note that Asimo continues to fixate upon the vacuum during the
entire movement.
108
Figure 5.38: Samples taken from the mannequin performing the pickup behavior. (a)
depicts before execution begins. (b) depicts the first phase, for which fixate focuses
on the target (the vacuum). (c) and (d) depict reaching to the vacuum (using reach).
The behavior of the grasp behavior is not observable on the mannequin. Note that the
mannequin continues to fixate upon the vacuum during the entire movement.
109
3 TAR T TASK
DONE / BJEC T 2 EACH ' R ASP & IXA T E PLANNING
STAR T ED $ UR A TION TASK
DONE Figure 5.39: Depiction of the message-driven machine used to realize the pickup task
behavior. Black arrows indicate transitions that cause states to be started. Red arrows
indicate transitions that cause states to be forcibly terminated. The green boxes represent
parameters that are passed to the primitive subtasks. The state with a double outline
(e.g., the grasp state) indicates the final state for the machine.
5.7.2 Putdown
The putdown behavior puts a grasped object on top of a surface, at which point the
robot relinquishes control over the object. Figures 5.41 and 5.42 depict the simulated
humanoids putting a vacuum on the table in the sparse environment. As Figure 5.40
indicates, the putdown behavior is quite similar to pickup. In particular, the sequence of
events is (1) position, (2) fixate, and (3) release, where position takes the place of reach
and release replaces grasp.
Putdown utilizes symbols, rather than numerics (i.e., relative homogeneous trans-
formations) to allow the programmer to specify the surface on which the object is to be
laid. The target parameter (see Figure 5.40) specifies the surface using the two con-
ditions above and near. The Task Matrix then determines a number of sample states
110
of the objects that jointly satisfy the two conditions, and passes those samples to the
position behavior (both reach and position accept a set of goal transforms, in case one
or more goals is unreachable using motion planning); as Figures 5.41 and 5.42 show,
these samples result in the grasped object being placed at a random location on the tar-
get surface (the two-dimensional projection of the bounding box of the smaller object
must lie inside the two-dimensional projection of the bounding box of the larger object,
so the vacuum in Figures 5.41 and 5.42 cannot lie only partially on the table). Note
that the use of conditions to parameterize the behavior is not restricted to putdown; vac-
uum (see Section 5.7.4) utilizes a condition in this way as well. The use of symbolic
states for robotic manipulation is not novel here; this concept has been in use since the
introduction of task-level programming [LP82, LS84].
3 TAR T TASK
DONE / BJEC T 0 OSITION 2 ELEASE & IXA T E PLANNING
STAR T ED $ UR A TION 4 AR GET TASK
DONE Figure 5.40: Depiction of the message-driven machine used to realize the putdown task
behavior. Black arrows indicate transitions that cause states to be started. Red arrows
indicate transitions that cause states to be forcibly terminated. The green boxes represent
parameters that are passed to the primitive subtasks. The state with a double outline
(e.g., the release state) indicates the final state for the machine.
111
(a) (b)
(c) (d)
Figure 5.41: Samples taken from Asimo performing the putdown behavior. (a) depicts
before execution begins. (b) depicts the first phase, for which fixate focuses on the target
surface (the table). (c) depicts positioning the vacuum (using position). (d) depicts
releasing the vacuum using release. Note that Asimo continues to fixate upon the table
during the entire movement.
5.7.3 Greet
Greet causes the robot to face a human (or another humanoid) and wave to him, her, or
it. As the MDM diagram of Figure 5.43 shows, greet is composed of the primitive task
behaviors fixate, get-ready-to-wave, wave, and go-rest-posture (get-ready-to-wave and
go-rest-posture are both postural behaviors). Fixate is utilized twice; once to initially
focus on the target and again to maintain the focus thereafter. Figures 5.44 and 5.45
depict the kinematically simulated robots waving to a walking humanoid.
112
Figure 5.42: Samples taken from the mannequin performing the putdown behavior. (a)
depicts before execution begins. (b) depicts the first phase, for which fixate focuses on
the target surface (the table). (c) and (d) depict positioning the vacuum (using position).
The behavior of the release behavior is not observable on the mannequin. Note that the
mannequin continues to fixate upon the table during the entire movement.
5.7.4 Vacuum
The most complex task behavior presented in this chapter is the vacuum behavior. Vac-
uum is itself composed of the macro task behaviors pickup and putdown; additionally, it
uses the position and fixate behaviors, as well as a special behavior for randomly select-
ing one of a class of objects. Depictions of the execution of the vacuum behavior on
both the simulated Asimo and mannequin are seen in Figures 5.47 and 5.48.
Vacuum functions in the following manner. A vacuum cleaner, specified by the user,
is first secured in the robot’s grip using pickup. Next, for every piece of debris in a user-
prescribed location (determined using the special find behavior), the robot first focuses
113
Start
task-done
Wave
duration
Wave
period
Fixate
Get-ready-to-wave
task-done
Target
task-done
Fixate
Wave
task-done
Go-rest-posture
task-done
Figure 5.43: Depiction of the message-driven machine used to realize the greet task
behavior. Black arrows indicate transitions that cause states to be started. Red arrows
indicate transitions that cause states to be forcibly terminated. The green boxes represent
parameters that are passed to the primitive subtasks. The state with a double outline
(e.g., the go-rest-posture state) indicates the final state for the machine.
on the debris (using fixate) and then positions the tip of the vacuum over the debris
(using position). Finally, the vacuum cleaner is placed on a surface specified by the user
using putdown. Note that the vacuum cleaner is assumed to be “on” prior to execution
of this task; there is no provision for switching on the vacuum.
There are two noteworthy aspects of the vacuum task behavior. The first is the
use of a condition, above (introduced in Chapter 3), that is used to position the tip
of the dustbuster above the debris. The Task Matrix uses this predicate to generate goal
configurations (i.e., six dimensional operational-space configurations) for the vacuum
114
Figure 5.44: Samples of depicted execution of the greet macro behavior run on the
simulated Asimo (the target is another simulated Asimo). An omniscient sensing model
is used in place of the simulated camera for simplicity.
115
Figure 5.45: Samples of depicted execution of the greet macro behavior run on the
mannequin (the target is a simulated Asimo). An omniscient sensing model is used in
place of the simulated camera for simplicity.
116
that position attempts to reach. The second remarkable aspect is the use of a special
task behavior, find, to randomly select a single object from a group of like objects. Find
differs from all other task behaviors currently in the matrix in that it does not utilize
any kinematic chains of the robot. Additionally, it consists of little more than a call to
the perceptual model. The power of using find in this manner is the ability to drive the
message-driven machine using messages from find. As Figure 5.46 indicates, if find is
successful in finding an appropriate object, that object is passed as a parameter to fixate
and position. Conversely, if find is not successful (e.g., because there is no more debris
in the prescribed region), then the vacuuming is complete and the putdown behavior is
triggered.
Start
task-done
Object
(dustbuster)
Target
region
Pickup
Putdown
Find
Fixate
Position
task-done
parameter-set
data: obj x
task-done
task-done
task-failed
Object
(debris)
task-done
task-failed
task-failed
Figure 5.46: Depiction of the message-driven machine used to realize the vacuum task
behavior. Black arrows indicate transitions that cause states to be started. Red arrows
indicate transitions that cause states to be forcibly terminated. The green boxes represent
parameters that are passed to the primitive subtasks. The state with a double outline
(e.g., the putdown state) indicates the final state for the machine.
117
(a) (b)
(c) (d)
Figure 5.47: Samples taken from Asimo performing the vacuum behavior. (a)–(c) depict
the position behavior moving the vacuum tip over the debris. (d) depicts the vacuum on
the table, having just been put there and released using putdown.
5.8 Summary
This chapter validated the primitive task behaviors introduced in the previous chapter on
three humanoids with significantly different kinematics in multiple environments. These
primitive task behaviors have no robot-specific programming and were not modified
between execution across the different platforms. In addition to showing that the primi-
tive task behaviors performed the same function on both robots, this chapter introduced
multiple complex task behaviors– pickup, putdown, greet, and vacuum– built using these
118
Figure 5.48: Samples taken from the mannequin performing the vacuum behavior. (a)–
(c) depict the position behavior moving the vacuum tip over the debris. (d) depicts the
vacuum on the table, having just been put there and released using putdown.
primitive behaviors. Many of the elements in this set of primitive behaviors– consisting
of reach, position, fixate, grasp, release, postural, and canned– are used multiple times
in constructing these complex task behaviors.
119
Chapter 6
Future work
6.1 Introduction
This dissertation concludes with the future directions that this research should take. Sec-
tion 6.2 discusses validation on physically embodied humanoids. Section 6.3 considers
interaction control; specifically, the challenges to abstracting interaction control are dis-
cussed, and it is argued that interaction control is not a promising avenue for extension
of this work in the short term. Section 6.4 examines the difficulties with the Task matrix
framework’s arbitration action-selection mechanism, and proposes potential directions
in that area. Finally, Section 6.5 discusses extension to a greater space of tasks than the
occupational tasks considered in this dissertation.
6.2 Validation on physically embodied humanoids
The Task Matrix framework was developed to mitigate the problem of developing robust
behaviors for humanoid robots. The previous chapter demonstrates that the Task Matrix
has been used successfully to perform various tasks on both kinematically and dynami-
cally simulated humanoids in virtual environments. It is regrettable that the work in this
thesis was not validated upon an actual humanoid robot; access to walking humanoids
is limited at this time. However, validation on simulated robots is a first step in that
direction.
120
Humanoids in real, human-populated environments will require far more robustness
built into the task behaviors than is currently present. The current behaviors assume
perfect knowledge and perfect action; these presumptions can be satisfied mostly by
instrumenting the environment and driving the robot slowly. Advancing technology,
including improved sensors, more effective perception algorithms, and more accurate
controllers, will minimize error in both perception and action. The Task Matrix frame-
work makes few assumptions and is unlikely to preclude the use of such new technology.
Indeed, the common skill set seeks to separate those algorithmic and control components
from the task behaviors in order to yield automatic performance upgrades as technology
advances.
6.3 Interaction control
Regardless of how well the task behaviors presented in Chapter 4 can be made to per-
form in the real world, there will remain tasks that are ill-suited for the motion control
paradigm of the current framework. Theoretically, the tasks in this class could be per-
formed using motion-control, but the errors in perception and action must be smaller
than the tolerance required to accomplish a given task. It also seems more natural to
control certain tasks using applied force rather than, or in addition to, end-effector posi-
tion; scrubbing a surface with a sponge is an example of such a task.
It is difficult to treat interaction control abstractly in the same manner as the Task
Matrix treated motion control. Motion control can be categorized into joint-space con-
trol and operational-space control, and commands in each space can be transformed into
the other.
1
The inputs and outputs to motion control are straightforward: joint-space (or
1
Information loss may result if transforming from joint-space to operational-space and back to joint-
space on redundant robots; however, the operational-space trajectory should remain constant.
121
operational-space) commands are input and the output is the robot performing those
commands to the best of its ability.
In contrast, interaction control encompasses a broad range of schemes including
stiffness control, impedance control, hybrid control, etc. Many of the various schemes
present different inputs, in part because they attempt to control different things. For
example, hybrid force/position control permits the regulation of force and position
simultaneously in order to perform tasks with both force and position constraints, while
force control attempts to control primarily the force applied by the end-effector. The
various interaction control methods specify environmental properties in various ways,
further complicating abstraction. For example, compliance control models the environ-
ment using stiffness and compliance matrices; force control requires those two matrices
and three others as well. Given the multifaceted approaches above, it is unsurprising
that there does not exist a unified method for performing interaction control. At present,
there does not even exist a prescriptive means for selecting an interaction control scheme
that is appropriate for a given task and robot; the process by which researchers select a
given scheme is unclear.
In addition to the issues above, it is also quite difficult to simulate interaction control.
As noted in the previous chapter, the state-of-the-art in contact modeling for rigid body
simulation is rather primitive. The research focus in rigid body simulation generally is
plausible motion, as noted by Barzel et al. [BHW96] and Guendelman et al. [GBF03],
rather than physically accurate motion. Good control benefits from, if not requires,
accurate models of the plant, and it is imaginable that new methods for interaction will
arise when contact can be modeled with more stability and accuracy than is available at
the present time.
122
In summary, it is nontrivial to unify the various interaction control schemes, and it
is possible that new schemes will be discovered. It therefore seems premature to be
concerned with incorporating interaction control into the Task Matrix framework.
6.4 Simultaneous behavior
One of the more intriguing aspects of humanoid robots is the potential for perform-
ing multiple tasks simultaneously using the inherent kinematic redundancies. Not only
are there redundant degrees-of-freedom in operational-space, but humanoids generally
possess two arms.
The arbitration action-selection mechanism employed by the Task Matrix makes
performing several activities simultaneously difficult, because degrees-of-freedom are
locked in a conservative manner; for example, reach locks the DOF in the base to keep
another behavior from moving the robot while it is reaching. Additionally, even when
tasks can operate simultaneously upon mutually exclusive degrees-of-freedom of the
robot, a coordination problem arises: the individual behaviors have to command the
robot in such a way that they do not cause the robot to collide with itself. If the robot is
commanded to move too quickly, it might not even be possible to avoid self-collision.
These problems indicate that a more proficient means of performing behaviors simulta-
neously is warranted.
The most trivial way to address the problem of simultaneous task performance is to
assign all degrees-of-freedom exclusively to a single task. Performing two behaviors
simultaneously (e.g., reach and fixate) would be achieved by creating a new task that
does exactly both. Such an approach would require a library of tasks exponential in the
number of single-activity tasks. Additionally, if one of the primitive behaviors required
123
modification, all of the compound behaviors would require modification; the principle
of code reuse would be violated.
Recent work in both robotics (e.g., Sentis and Khatib [SK05]) and humanoid anima-
tion (e.g., Baerlocher and Boulic [BB04]) has suggested a different approach: tasks are
assigned priorities, and a control method performs the tasks simultaneously. Degrees-
of-freedom unused by a high-priority task can be utilized by a lower priority task using
the null-space of the manipulator Jacobian. However, these approaches use a gradient-
descent approach to satisfy the given constraints. Such an approach can converge to
a local minimum, which might cause a task to fail when a solution exists. Addition-
ally, the tasks must be expressible using an objective function. Nevertheless, these
approaches are intriguing and could serve as the foundation for performing multiple
behaviors simultaneously in the Task Matrix framework.
Another possible avenue for simultaneous behaviors is in motion planning. Planning
collision-free motions in static environments is PSPACE-hard [Rei79]. However, ran-
domized algorithms for motion planning have made it possible to generate collision-free
trajectories for high-DOF humanoids in near real-time [DNTH06a]. Additional con-
straints could be integrated into the planning process; for example, if it were known that
the robot would be waving while reaching, the waving trajectories could be integrated
into the planning process. Planning in this manner presents few technical obstacles–
existing techniques like rapidly-exploring random trees could be readily adapted toward
this purpose– but has received little attention to the present time.
6.5 The space of physical tasks
This dissertation focuses on occupational tasks, which is some subset of the space of
physical tasks that humans perform. Work measurement systems are intriguing in this
124
respect, because they belong to the few studies of human tasks. Little is known about
the space of tasks, and important questions remain: Do there exist physical tasks that
can be reduced to others (i.e., by requiring the same movements, skills, etc.)? Can
physical tasks be neatly categorized using some objective criterion (e.g., sporting tasks,
occupational tasks, musical tasks, etc.?) If some physical tasks can be reduced to others,
is the space of physical tasks fixed?
Roboticists currently program humanoids to perform a control theoretic benchmark
task or possibly a real world task. The implicit assumption is that if the robot can
perform some set of tasks, it can be readily programmed to perform others. This dis-
sertation has worked backward, first focusing on a subset of the space of tasks and then
determining what common elements are necessary to accomplish tasks in that subset. A
natural extension of this effort would be to apply the same process to a different subset
of tasks; examining tasks required in sport seems to be a good direction, especially since
that domain appears to be highly compatible with the motion control paradigm used by
the Task Matrix framework.
6.6 Summary
This chapter discussed extensions to this research. Short-term extensions to this research
would permit the Task Matrix framework to capture more tasks (i.e., those using interac-
tion control) and perform more tasks simultaneously. Long-term extensions would focus
on decomposing classes of tasks beyond occupational tasks. Finally, validation of this
dissertation will be conducted in the long-term as improvements in physical simulation
and greater numbers of humanoid robot platforms permit.
125
Bibliography
[AB97] Ronald C. Arkin and Tucker R. Balch. AuRA: Principles and practice
in review. Journal of Experimental and Theoretical Artificial Intelli-
gence (JETAI), 9(2):175–188, April 1997.
[AIL85] Michael A. Arbib, T. Iberall, and D. Lyons. Coordinated control pro-
grams for movements of the hand. Experimental Brain Research,
pages 111–129, 1985.
[AJMHK73] William Antis, Jr. John M. Honeycutt, and Edward N. Koch. The
Basic Motions of MTM. The Maynard Foundation, 1973.
[AND02] Aris Alissandrakis, Chrystopher .L. Nehaniv, and Kerstin Dauten-
hahn. Imitation with ALICE: Learning to imitate corresponding
actions across dissimilar embodiments. IEEE Trans. on Systems, Man,
and Cybernetics, 32(4):482–496, 2002.
[AP97] Miha Anitescu and Florian A. Potra. Formulating dynamic multi-
rigid-body contact problems with friction as solvable linear comple-
mentarity problems. Nonlinear Dynamics, 14:231–247, 1997.
[AP02] Mihai Anitescu and Florian A. Potra. A time-stepping method for stiff
multi-rigid-body dynamics with contact and friction. Intl. Journal for
Numerical Methods in Engineering, 55:753–784, 2002.
[Ark98] Ronald C. Arkin. Behavior-Based Robotics. MIT Press, May 1998.
[Bar94] David Baraff. Fast contact force computation for nonpenetrating rigid
bodies. In Proc. of SIGGRAPH, Orlando, FL, July 1994.
[BB04] Paolo Baerlocher and Ronan Boulic. An inverse kinematic architec-
ture enforcing an arbitrary number of strict priority levels. The Visual
Computer, 20(6):402–417, Aug 2004.
126
[BBB
+
99] Norman I. Badler, Rama Bindiganavale, Juliet Bourne, Jan Allbeck,
Jianping Shi, and Martha Palmer. Real time virtual humans. In Proc.
of Intl. Conf. on Digital Media Futures, Bradford, UK, 1999.
[Ben04] Darrin C. Bentivegna. Learning from Observation Using Primitives.
PhD thesis, Georgia Institute of Technology, 2004.
[Ber98] G´ erard Berry. The foundations of Esterel. In G. Plotkin, C. Stirling,
and M. Tofte, editors, Proof, Language, and Interaction: Essays in
Honour of Robin Milner. MIT Press, 1998.
[BHW96] Romen Barzel, John F. Hughes, and Daniel N. Wood. Plausible
motion simulation for computer graphics animation. In R. Boulic and
G. H´ egron, editors, Computer Animation and Simulation (Proc. Euro-
graphics Workshop), pages 183–197, 1996.
[BI66] Adi Ben-Israel. A newton-raphson method for the solution of systems
of equations. Journal of Mathematical Analysis and Applications,
15:243–252, 1966.
[BM03] Andrew G. Barto and Sridhar Mahadevan. Recent advances in hier-
archical reinforcement learning. Discrete Event Dynamic Systems:
Theory and Applications, 13(4):343–379, 2003.
[Bro86] Rodney A. Brooks. A robust layered control system for a mobile
robot. IEEE Trans. on Robotics and Automation, 2(1):14–23, April
1986.
[BS98] Giuseppe Beccari and Stefano Stramigioli. Impedance control as
merging mechanism for a behavior-based architecture. In Proc. of
the 1998 IEEE Intl. Conf. on Robotics and Automation, pages 1429–
1434, Leuven, Belgium, May 1998.
[CB95] Lee Campbell and Aaron Bobick. Recognition of human body motion
using phase space constraints. In Proc. of 5th Intl. Conf. on Computer
Vision, pages 624–630, Cambridge, MA, 1995.
[CGC
+
04] M.F. Chan, D.R. Giddings, C.S. Chandler, C. Craggs, R.D. Plant, and
M.C. Day. An experimentally confirmed statistical model on arm
movement. Human Movement Science, 22(6):631–648, April 2004.
[Che05] Jason R. Chen. Constructing task-level assembly strategies in robot
programming by demonstration. Intl. J. of Robotics Research,
24(12):1073–1085, Dec 2005.
127
[CMER92] Eve Coste-Mani` ere, Bernard Espiau, and Eric Rutten. A task-level
robot programming language and its reactive execution. In Proc. of
the IEEE Intl. Conf. on Robotics and Automation (ICRA), pages 2751–
2756, Nice, France, 1992.
[CMS00] Eve Coste-Mani` ere and Reid Simmons. Architecture, the backbone
of robotic systems. In Proc. of the IEEE Intl. Conf. on Robotics and
Automation (ICRA), pages 67–72, San Francisco, CA, April 2000.
[CMTZ86] Antonio Camurri, Pietro Morasso, Vincenzo Tagliasco, and Renato
Zaccaria. Dance and movement notation. In P. Morasso and
V . Tagliasco, editors, Human Movement Understanding, chapter 3,
pages 85–124. Elsevier Science Publishers, 1986.
[Coe01] Jefferson Coelho. Multifingered grasping: Haptic reflexes and control
context. PhD thesis, Univ. of Massachusetts, Amherst, Sept 2001.
[Con92] Jon Connell. SSS: A hybrid architecture applied to robot navigation.
In Proc. of IEEE Intl. Conf. on Robotics and Automation (ICRA-92),
pages 2719–2724, Nice, France, May 1992.
[Dav89] William S. Davis. Robotic task planning: independent of agents but
dependent on time. In 690-695, editor, Proc. of IEEE Intl. Conf. on
Robotics and Automation, 1989.
[Dil04] R¨ udiger Dillmann. Teaching and learning of robot tasks via robot
observation of human performance. Robotics and Autonomous Sys-
tems, 47(2-3):109–116, June 2004.
[DNTH06a] Evan Drumwright and Victor Ng-Thow-Hing. The task matrix: An
extensible framework for creating versatile humanoid robots. In Proc.
of the IEEE Intl. Conf. on Robotics and Automation (ICRA), Orlando,
FL, USA, 2006.
[DNTH06b] Evan Drumwright and Victor Ng-Thow-Hing. Toward interactive
reaching in static environments for humanoid robots. In Proc. of
IEEE/RSJ Intl. Conf. on Intelligent Robots and Systems (IROS), Bei-
jing, Oct 2006.
[DRE
+
99] R¨ udiger Dillmann, Oliver Rogalla, Markus Ehrenmann, Raoul
Z¨ ollner, and Monica Bordegoni. Learning robot behaviour and skills
based on human demonstration and advice: the machine learning
paradigm. In Proc. of 9th Intl. Symp. of Robotics Research (ISRR),
Detroit, MI, 1999.
128
[Dru07] Evan Drumwright. The Task Matrix: a Robot-Independent Frame-
work for Programming Humanoids. PhD thesis, 2007.
[Fea87] Roy Featherstone. Robot Dynamics Algorithms. Kluwer, 1987.
[Fea04] Roy Featherstone. An empirical study of the joint space inertia matrix.
The Intl. J. of Robotics Research, 23(9):859–871, September 2004.
[Fir89] James Firby. Adaptive Execution in Complex Dynamic Worlds. PhD
thesis, Yale University, January 1989.
[FvT01] Petros Faloutsos, Michiel van de Panne, and Demetri Terzopoulos.
The virtual stuntman: dynamic characters with a repertoire of motor
skills. Computers and Graphics, 25(6):933–953, December 2001.
[Gat96] Eran Gat. A language for supporting robust plan execution in embed-
ded autonomous agents. In L. Pryor, editor, Proc. of the AAAI Fall
Symposium on Plan Execution. AAAI Press, 1996.
[GBF03] E. Guendelman, R. Bridson, and R. Fedkiw. Nonconvex rigid bodies
with stacking. ACM Trans. on Graphics, 22(3):871–878, 2003.
[Gea71] C. William Gear. Numerical Initial Value Problems in Ordinary Dif-
ferential Equations. Prentice Hall, Engelwood Cliffs, NJ, 1971.
[Gil06] Robert Gilmore. Lie Groups, Lie Algebras, and Some of Their Appli-
cations. Dover Publications, 2006.
[GL87] Michael Georgeff and Amy Lansky. Reactive reasoning and planning.
In Proc. of National Conf. on Artificial Intelligence, pages 972–978,
Seattle, WA, July 1987.
[Gle98] Michael Gleicher. Retargeting motion to new characters. In Computer
Graphics, Proceedings of SIGGRAPH 1998, pages 33–42, August
1998.
[GLML] Stefan Gottschalk, Ming Lin, Dinesh Manocha, and Eric Larsen. PQP
– The Proximity Query Package. http://www.cs.unc.edu/ geom/SSV/.
[Gro72] Roland C. Groome. Force feedback steering of a teleoperator system.
Master’s thesis, Dept. of Aeronautics and Astronautics, MIT, 1972.
[HCRP91] Nicolas Halbwachs, Pouzet Caspi, Pascal Raymond, and Daniel
Pilaud. The synchronous data-flow programming language LUSTRE.
Proceedings of the IEEE, 79(9):1305–1320, Sept 1991.
129
[HG00] Manfred Huber and Roderic Grupen. A hybrid architecture for learn-
ing robot control tasks. Robotics Today, 13(4), 2000.
[HHHT98] Kazuo Hirai, Masato Hirose, Yuji Haikawa, and Toru Takenaka. The
development of Honda humanoid robot. In Proc. of the IEEE Intl.
Conf. on Robotics and Automation (ICRA), pages 1321–1326, Leu-
ven, Belgium, May 1998.
[Hog85] Neville Hogan. Impedance control: An approach to manipulation,
part I, II, III. Journal of Dynamic Systems, Measurement, and Control,
107:1–23, Mar 1985.
[HW98] Jessica Hodgins and Victor Wooten. Animating human athletes. In
Y Shirai and S Hirose, editors, Robotics Research: The Eighth Intl.
Symposium, pages 356–367, Berlin, 1998. Springer-Verlag.
[Ino71] Hiroshi Inoue. Computer controlled bilateral manipulator. Bulletin of
the JSME, 14(69):199–207, 1971.
[INS02] Auke Ijspeert, Jun Nakanishi, and Stefan Schaal. Learning attractor
landscapes for learning motor primitives. In S Becker, S Thrun, and
K Obermayer, editors, Advances in Neural Information Processing
Systems 15, pages 1547–1554, 2002.
[JM04] Odest C. Jenkins and Maja J Matari´ c. Performance-derived behav-
ior vocabularies: Data-driven acquisition of skills from motion. Intl.
Journal of Humanoid Robotics, 1(2):237–288, October 2004.
[KB87] Delmar W. Karger and Franklin H. Bayha. Engineered Work Manage-
ment. Industrial Press, Inc., New York, NY , fourth edition, 1987.
[KH82] Delmar W. Karger and Walton M. Hancock. Advanced Work Mea-
surement. Industrial Press, Inc., New York, NY , 1982.
[Kha87] Oussama Khatib. A unified approach to motion and force control of
robot manipulators: The operational space formulation. IEEE Journal
on Robotics and Automation, 3(1):43–53, Feb 1987.
[KKN
+
03] Satoshi Kagami, James J. Kuffner, Jr., Koichi Nishiwaki, Masayuki
Inaba, and Hirochika Inoue. Humanoid arm motion planning using
stereo vision and RRT search. Journal of Robotics and Mechatronics,
15(2):200–207, April 2003.
[KV00] James J. Kuffner, Jr. and S. M. La Valle. RRT-connect: an efficient
approach to single-query path planning. In Proc. of the Intl. Conf.
130
on Robotics and Automation (ICRA), pages 995–1001, San Francisco,
USA, 2000.
[LaV06] Steven LaValle. Planning Algorithms. Cambridge University Press,
2006.
[LHP05] Karen Liu, Aaron Hertzmann, and Zoran Popovic. Learning physics-
based motion style with nonlinear inverse optimization. In Proc. of
SIGGRAPH, 2005.
[LP81] Tomas Lozano-P´ erez. Automatic planning of manipulator trans-
fer movements. IEEE Trans. on Systems, Man, and Cybernetics,
11(10):681–698, 1981.
[LP82] Tomas Lozano-P´ erez. Task planning. In Michael Brady,
John M. Hollerbach, Timothy L. Johnson, Tomas Lozano-Perez, and
Matthew T. Mason, editors, Robot motion: planning and control,
pages 474–498. MIT Press, 1982.
[LP83] Tomas Lozano-P´ erez. Spatial planning: A configuration space
approach. IEEE Trans. on Computing, C–32(2):108–120, 1983.
[LPJMO89] Tomas Lozano-P´ erez, Joseph L. Jones, Emmanuel Mazer, and
Patrick A. O’Donnell. Task-level planning of pick-and-place robot
motions. Computer, 22(3):21–29, 1989.
[LPW79] Tomas Lozano-P´ erez and M. A. Wesley. An algorithm for planning
collision-free paths among polyhedral obstacles. Communications of
the ACM, 22(10):560–570, 1979.
[LRN86] John E. Laird, Paul S. Rosenbloom, and Allen Newell. Chunking
in soar: The anatomy of a general learning mechanism. Machine
Learning, 1:11–46, 1986.
[LS84] Anthony Levas and Mallory Selfridge. A user-friendly high-level
robot teaching system. In Proc. of Intl. Conf. on Robotics and Automa-
tion (ICRA), pages 413–416, Cambridge, MA, 1984.
[Mar91] F. Maraninchi. The Argos language: Graphical representation of
automata and description of reactive systems. In Proc. of IEEE Work-
shop on Visual Languages, Kobe, Japan, Oct 1991.
[Mil01] Andrew T. Miller. GraspIt: A Versatile Simulator for Robotic Grasp-
ing. PhD thesis, Columbia University, 2001.
131
[Mir96] Brian Mirtich. Fast and accurate computation of polyhedral mass
properties. Journal of Graphics Tools, 1(2), 1996.
[MRC05] Meinard M¨ uller, Tido R¨ oder, and Michael Clausen. Efficient content-
based retrieval of motion capture data. In Proc. of SIGGRAPH 2005,
Los Angeles, CA, 2005.
[mRGoMPBSA] UNC Research Group on Modeling Physically-Based Simulation and
Applications. V-Collide: Collision Detection for Arbitrary Polygonal
Objects. http://www.cs.unc.edu/ geom/V COLLIDE/.
[MS02] Fred E. Meyers and James R. Stewart. Motion and Time Study for
Lean Manufacturing, 3rd. Ed. Prentice Hall, Upper Saddle River, NJ,
2002.
[Nar94] Sundar Narasimhan. Task Level Strategies for Robots. PhD thesis,
Massachusetts Institute of Technology, 1994.
[NH86] Y . Nakamura and H. Hanafusa. Inverse kinematics solutions with sin-
gularity robustness for robot manipulator control. Journal of Dynamic
Systems, Measurement, and Control, 108:163–171, Sept 1986.
[Nie88] Benjamin W. Niebel. Motion and time study. Richard D. Irwin, Inc.,
eighth edition, 1988.
[NS72] Allen Newell and Herbert A. Simon. The Theory of Human Problem
Solving. Prentice Hall, Englewood Cliffs, NJ, 1972.
[Pai95] Paul Painlev´ e. Sur le lois du frottement de glissemment. C. R.
Acad´ emie des Sciences Paris, 121:112–115, 1895.
[Pir99] Paolo Pirjanian. Behavior coordination mechanisms - state-of-the-art.
Technical Report IRIS-99-375, IRIS, School of Engineering, Univer-
sity of Southern California, October 1999.
[Rei79] John H. Reif. Complexity of the mover’s problem and generalizations.
In IEEE Symposium on Foundations of Computer Science, pages 421–
427, San Juan, Puerto Rico, 1979.
[Sch99] Stefan Schaal. Is imitation learning the route to humanoid robotics?
Trends in Cognitive Sciences, 3(6):233–242, 1999.
[Sch01] Stefan Schaal. Cs545 lecture ix (inverse kinematics). Presentation,
2001.
132
[Seg88] Alberto Maria Segre. Machine learning of robot assembly plans.
Kluwer Academic Publishers, 1988.
[SGS84] Bruce Shimano, Clifford Geschke, and Charles Spalding. Val-II: A
robot programming language and control system. In Proc. of SME
Robots VIII Conf., Detroit, MI, USA, June 1984.
[Sim94] Reid Simmons. Structured control for autonomous robots. IEEE
Trans. on Robotics and Automation, 10(1):34–43, Feb 1994.
[SK05] Luis Sentis and Oussama Khatib. Synthesis of whole-body behav-
iors through hierarchical control of behavioral primitives. Intl. J. of
Humanoid Robotics, 2(4):505–519, 2005.
[SPS99] Richard S. Sutton, D. Precup, and Satinder Singh. Between MDPs and
semi-MDPs: A framework for temporal abstraction in reinforcement
learning. Artificial Intelligence, 112:181–211, 1999.
[SS00] Lorenzo Sciavicco and Bruno Siciliano. Modeling and Control of
Robot Manipulators, 2nd Ed. Springer-Verlag, London, 2000.
[SSL05] Fabian Schwarzer, Mitual Saha, and Jean-Claude Latombe. Adaptive
dynamic collision checking for single and multiple articulated robots
in complex environments. IEEE Trans. on Robotics and Automation,
June 2005.
[ST00] David Stewart and J.C. Trinkle. An implicit time-stepping scheme for
rigid body dynamics with coulomb friction. In Proc. of the IEEE Intl.
Conf. on Robotics and Automation (ICRA), San Francisco, CA, April
2000.
[Tan01] Andrew S. Tanenbaum. Modern Operating Systems, 2nd. ed. Prentice
Hall, 2001.
[TSM82] Russell H. Taylor, Phillip D. Summers, and J.M. Meyer. AML: A
manufacturing language. Intl. J. of Robotics Research, 1(3), 1982.
[UAR04] Aleˇ s Ude, Chris G. Atkeson, and Marcia Riley. Programming full-
body movements for humanoid robots by observation. Robotics and
Autonomous Systems, 47(2–3):93–108, June 2004.
[VGH03] Richard T. Vaughan, Brian P. Gerkey, and Andrew Howard. On
device abstractions for portable, reusable robot code. In Proc. of the
IEEE/RSJ Intl. Conf. on Intelligent Robots and Systems (IROS), pages
2121–2427, Las Vegas, NV , Oct 2003.
133
[Zan90] Kjell B. Zandin. MOST Work Measurement Systems, 2nd. Ed. Marcel
Dekker, Inc., New York, NY , 1990.
134
Appendix A
Motion and posture encoding
This appendix presents XML documents used for representing the posture at the begin-
ning of a waving movement and for encoding the trajectories used to wave. Two doc-
uments represent the posture for beginning waving for Asimo and the mannequin (Fig-
ures A.1 and A.2, respectively) and two documents encode the trajectories for waving
for Asimo and the mannequin (Figures A.4 and A.5, respectively).
135

Figure A.1: The XML document describing the wave posture for Asimo.
136

Figure A.2: The XML document describing the wave posture for the mannequin.
137

Figure A.3: The XML document describing the wave posture for the Bandit II model.
138

time="1" />

value="-1.384" time="1" />

time="1" />

value="-1.4994" time="1" />

time="1" />

Figure A.4: The XML document describing the wave trajectories for Asimo.
139

value="-1.571" time="1" />

time="1" />

value="-1.445" time="1" />

value="-1.8" time="1" />

time="1" />

time="1" />

Figure A.5: The XML document describing the wave trajectories for the mannequin.
140

value="0" time="1" />

value="0" time="1" />

Figure A.6: The XML document describing the wave trajectories for the Bandit II
model.
141

Abstract (if available)

Abstract The present state of designing behaviors for humanoid robots can be viewed as analogous to programming a computer using machine language. Even when such complex issues as interaction control and locomotion can be bypassed, programming generally is still pursued in a highly robot-dependent manner. Though roboticists currently use sophisticated tools like human motion capture systems to assist with behavior design, a core tenet of software development -- component reuse -- is frequently overlooked. As a result, a behavior that allows a robot to perform a task will often fail on a different robot, even if the kinematic and dynamic properties between the two robots are highly similar. This problem prevents software reuse and, by extension, limits development of high-level humanoid behaviors for performing a broad range of tasks.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Design of adaptive automated robotic task presentation system for stroke rehabilitation

PDF

The representation, learning, and control of dexterous motor skills in humans and humanoid robots

PDF

Nonverbal communication for non-humanoid robots

PDF

Optimization-based whole-body control and reactive planning for a torque controlled humanoid robot

PDF

Estimation-based control for humanoid robots

PDF

Modeling motor memory to enhance multiple task learning

PDF

A robotic system for benthic sampling along a transect

PDF

Machine learning of motor skills for robotics

PDF

Coordinating social communication in human-robot task collaborations

PDF

Towards socially assistive robot support methods for physical activity behavior change

PDF

Robot life-long task learning from human demonstrations: a Bayesian approach

PDF

Iterative path integral stochastic optimal control: theory and applications to motor control

PDF

Macroscopic approaches to control: multi-robot systems and beyond

PDF

Managing multi-party social dynamics for socially assistive robotics

PDF

Design and control of a two-mode monopod

PDF

Computational model of stroke therapy and long term recovery

PDF

Modeling dyadic synchrony with heterogeneous data: validation in infant-mother and infant-robot interactions

PDF

Situated proxemics and multimodal communication: space, speech, and gesture in human-robot interaction

PDF

Coalition formation for multi-robot systems

PDF

Self-assembly and self-repair by robot swarms

Asset Metadata

Creator Drumwright, Evan (author)

Core Title The task matrix: a robot-independent framework for programming humanoids

School Viterbi School of Engineering

Degree Doctor of Philosophy

Degree Program Computer Science (Robotics

Publication Date 07/24/2007

Defense Date 05/08/2007

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag humanoids,OAI-PMH Harvest

Language English

Advisor Matarić, Maja J. (committee chair), Schaal, Stefan (committee member), Schweighofer, Nicolas (committee member)

Creator Email drumwrig@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-m646

Unique identifier UC1118262

Identifier etd-Drumwright-20070724 (filename),usctheses-m40 (legacy collection record id),usctheses-c127-528354 (legacy record id),usctheses-m646 (legacy record id)

Legacy Identifier etd-Drumwright-20070724.pdf

Dmrecord 528354

Document Type Dissertation

Rights Drumwright, Evan

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Repository Name Libraries, University of Southern California

Repository Location Los Angeles, California

Repository Email cisadmin@lib.usc.edu