OVERVIEW: PROXIES FOR TEAMWORK
Effective coordination of robots, agents and people promises to improve the safety, robustness and quality with which shared goals are achieved
by harnessing the highly heterogeneous entities' diverse capabilities as tasks require. Proxy-based integration architectures are emerging as a
standard method for coordinating teams of heterogeneous entities. Such architectures are designed to meet imposing challenges such as ensuring
that the diverse capabilities of the group members are effectively utilized, avoiding miscoordination in a noisy, uncertain environment and
reacting flexibly to changes in the environment. Our goal is to create a proxy-based integration infrastructure where there is a beneficial
symbiotic relationship between the proxies and the team members. By leveraging the coordination abilities of both the proxies and the
socially capable team members, the quality of the coordination can be improved.
The approach taken with Machinetta is to provide each RAP (we use the term RAP to refer to a Robot, Agent and/or Person.) with a proxy and
have the proxies act together in a team. Machinetta proxies build on our work over the last decade, where we developed the STEAM teamwork model
of multiagent teamwork (link to STEAM paper) and followed that up with the TEAMCORE proxies (link to Pynadath and Tambe, JAAMAS'2003). Teamwork
models provide reuse of teamwork capabilities across domains, flexibility in team coordination, and programming using high-level
team-oriented programs (see below) without the need to specify low-level coordination rules. One major advance in Machinetta is that the proxies
are implemented as lightweight Java processes and can run on various devices, including handheld computers. The proxies work with the whole
spectrum of RAPs, from relatively simple robots to expert human users. The design of the proxies makes them easily configurable and reusable
across domains, thus providing the agents community with a useful piece
of software for future research. RAP teams, utilizing the proxy infrastructure, are being evaluated in an urban disaster rescue domain.
Robots, agents and people each have different strengths and weaknesses. Creating teams of RAPs provides the possibility of leveraging the
diverse strengths of each RAP to overcome the limitations of the others. Engaging in teamwork imposes certain constraints on the team members
(e.g., informing other team members when there are successes or failures), which lead to desirable properties of team behavior. Since
team members have a responsibility towards each other, a team can achieve its goals robustly, with team members covering for failed
teammates, supplying key information to help each other, etc. In addition to performing the tasks performed by previous versions of a
proxy architecture, such as initiating and terminating team plans, aiding recovery from failures and communicating information, our proxies
have additional features that make them unique. These new features include the incorporation of adjustable autonomy reasoning, a novel role
allocation algorithm and the representation of coordination tasks as roles.
Teams of RAP-proxy pairs execute Team-Oriented Programs (TOPs), abstract team plans that provide high-level descriptions of the activities to be
performed. TOPs specify the team's joint plans, and the inter-dependencies between those plans, but do not contain all of the
details of coordination and communication required. Such programs identify the domain capabilities required to perform each role, which
helps in determining how best to allocate tasks to team members. The team plans are reactively instantiated in response to events in the
environment. The role allocation algorithms attempt to assign RAPs to
the roles that are required in the plan. The proxies can make small changes to the plan and dynamically change assignments of tasks to RAPs
to better achieve the goals. Since roles are only specified abstractly, individual RAPs are free to carry out their assigned tasks as they see
fit, based upon their own capabilities. In the current implementation, TOPs are specified in XML and loaded by the proxies at runtime.