Building Multirobot Coalitions
Through Automated Task Solution
Synthesis
Authors: Lynne Parker and Fang Tang
Presented by: Raj Dasgupta
Overview
• Problem Studied: How to make teams or coalitions of robots
perform a task that requires multiple robots
• Approach: “sensor sharing” between robots to form coalitions
• Coalition
– Temporary organization of entities that bring together diverse
capabilities for solving a particular task that cannot be handle by
single robots
– shorter-lived than teams
• Focus of paper - automated techniques for coalition
formation
• Solution: ASyMTRe (Automated Synthesis of Multirobot Task
solutions through software Reconfigurations)…and its
distributed version ASyMTRe-D
– Looks at ‘schema’ as the basic robot competence instead of a ‘task’
– A reasoning algorithm to generate coalitions using complete
information, with solution quality increasing with reasoning time
ASyMTRe Approach: Schema
• Schema (recall from lecture)
–
–
–
–
Programmatic block for implementing a behavior
Maps input (affordances) to output (actuator)
Consists of data and methods (similar to OO)
Can be networked – output of one schema can be
“hooked” up with input of another schema
• Ronald Arkin applied schemas to reactive mobile
robots
– Input goes from perceptual schema to motor schema
– Output of motor schemas a summed up (vector
summation) – recall potential fields
Communication Schema
• Three components from existing reactive systems
– Environmental Sensors (ES)
– Perceptual Schema (PS)
– Motor Schema (MS)
• New component: Communication Schema (CS)
– distributes information between different schema
situated on different robots
• Schemas are dynamically “hooked up” at runtime
• ‘Hook up’ or connections are determined by the
information required to perform a task
Information Types
• Information is an invariant - doesn’t matter
how the robot acquires or generates it
• Inputs and outputs are labeled with
information type unique to a task
• Information types have semantic meaning and
define specific sensing or computational data
of a schema or a sensor
– E.g., global position of a robot
• F = {F1, F2….}: set of information types
Information Type and Schema
• F = {F1, F2….}: set of information types
• For Schema Si:
– IS_i: set of input information sets
– OS_i: set of output information sets
– IS_i , OS_i are subset of F
• Inputs can be AND-ed (solid line) or OR-ed (dashed line)
• Connection condition for schemas: Schemas A’s output
and schema B’s input can be connected only if:
– the output information type of schema A matches the input
information type of schema B
Model
• R: set of robots, |R| = n
• T: set of motor schemas that define the grouplevel task to be achieved
• U: utility function
• Robot Ri can be represented as (ES_i, Si)
– ES_i: set of sensors, O ES^i_j is the output from the j-th
sensor of robot i
– Si : set of schemas pre-programmed into robot Ri
(similar to set of primitive behaviors)
• J-th schema of robot i is represented as
Schema Connections
• A schema is activated iff its input can be obtained from
the output of another schema or sensor
• Connections between schemas regulated by
connection constraints
• A solution to problem specified as (R, T, U) is a
combination of schemas such that
– all the inputs of every motor schema required to perform
task T are satisfied of every robot in R, along with all inputs
from schemas that feed into the relevant motor schemas
Potential Solution
• Gives the j-th potential solution for robot i, Six: xth schema for robot i, Fiy: y-th information type
that needs to be transferred to robot i
• Specifies the way to connect the schemas
• E.g.: Suppose T = {MS1}, assume ES1 and ES2 are
present
– POSi1 = {PS1, PS2, PS3, MS1}
– POSi2 = {PS2, CS1, CS2, MS1}, when F2 and F3 are
transferred from other robots
Solution Quality
• Gives how to select between multiple potential solutions
• Sensory computation system (SCS)
– Module that computes a function of its sensory inputs and
produces outputs
– SCSij = (Sij, ES_ij, oS_ij)
• Each SCSij is assigned
– cost Cij
– Success probability pij (determined via a learning process)
• Calculate utlity of SCSij as:
• Select the POSij that gives maximum utility of corresponding
SCSij
Potential Configuration Space (PCS)
• Original configuration space (OCS)
– Combination of all schemas on all robots
– Very large space
• Remove duplicate (equivalent) schemas across robots
• What we are left with is called Potential configuration
space (PCS)
• With n robots, each with h schemas, each schema
needing k inputs:
– Size complexity of OCS: O((nhk)nh)
– Size complexity of PCS: O((h’k)h’), where h’ is the number
of duplicate schemas, h’ < nh
OCS to PCS Example
Theorem 1: Is a solution exists in the OCS, it must exist in the PCS
ASyMTRe Configuration Algorithm
• Searches through the set of PCS to find the set of
POS (step II on last slide)
– Greedy search
• Selects the POS-s that have the highest utility for
each robot
• Non-superadditive environment because larger
coalition means higher communication and
computation costs...means that sum of maximum
utilities for each robot does not give the global
maximum utility
ASyMTRe Configuration Algorithm
• Impose a maximum cooperation size constraint
• Heuristics for speeding up search:
– Sort robots according to
• increasing sensing capabilities (more sensory capabilities is
better)
• Number of other robots with which they can cooperate with
(fewer cooperators is better)
• Algorithm is an anytime algorithm – finds a
solution within a short time, improves on it given
more time...can find optimal solution given
sufficient time
ASyMTRe Configuration Algorithm
ASyMTRe Configuration Algorithm
Properties
• Theorem 2: Correctness (proof done by
contradiction)
• Theorem 3: Completeness and Optimality, given
sufficient time (proof done by showing that
algorithm generates the entire schema search
space with all O(n!) orderings of all robots to
explore all possible POS-s, given enough time)
• In practice, problem of generating coalitions is
NP-hard, with worst case time complexity of
O(n!) ...works only for small values of ‘n’
Distributed ASyMTRe-D Approach
• Based on contract net protocol
• Three major steps:
1. Make request: Robot sends request for
information type it needs for each POS
• Simple request:
– synchronous request sent to other robots
– pn: no. of robots that reply saying they can provide required
information
– smaller value of pn means requesting robot can send out
more requests (because they get help from fewer robots)
• Complex request (?)
Distributed ASyMTRe-D Approach
2. Serve request and submit help
– Replies sent in a FCFS manner
– Simple replies sent immediately (so that requesting
robot can guess value of ‘pn’ quickly)
– (Complex replies?) sent after evaluating utility of
providing requested information
•
•
more capable robots chosen by requester because they
give higher utility
Max-to-help (k) constraint – limits the no. of robots to
which a robot can provide information so that capable
robots don’t get overworked
Distributed ASyMTRe-D Approach
3. Rank and confirm help
– Solutions ranked by decreasing utilities
– Ties (utility) broken using FCFS
– No robot responds within a certain timeout
period – request reattempted
– Cannot find PoS even after reattempts
•
•
Abort task
Inform (broadcast) task abort so that robots that had
agreed to offer information can be released from their
commitment and serve other requests
Experiment: Multi-robot
Transportation (ASyMTRe)
• Robots have to go from start to goal location
• Motor schema – go-to-goal provided on robots
– Requires localization capability on robots
• Some robots cannot localize
– Need information from more capable robots (with
localization capability) to reach goal
• Robots can have up to 3 sensors
– DGPS (global positioning)
– Camera (relative positionin w.r.t. other robots)
– Laser (relative positionin w.r.t. other robots)
• Every robot has comm-s
• Every robot can compute global position given a
relative position
Perceptual Schemas used
• PS1: estimate global position using laser+env.
map or DGPS
• PS2: give goal position
• PS3: estimate relative position of another robot
using camera or laser; plus a fiducial marker
• PS4: calculate self global position given relative
position w.r.t. another robot and global position
of other robot
• PS5: calculate other robot’s global position given
self global position and relative position of other
robot
Physical robot implementation
• Four robots
• Experiment 1: Two robots with laser-based positioning
using map go from start to goal
• Experiment 2: Four robots; two from experiment 1,
one with laser only, one with camera only
• Experiment 3: Two more robots, one with full sensor
capabilities, one with no sensors
• Some failuters due to variable lighting conditions, out
of field of view
• All robots able to reach goal position using sensor
sharing using ASyMTRe
Cooperative Box Pushing (ASyMTRe)
• Two robots need to push a box
• Motor schema: push- pushes box along straight line; available on all
robots
• Sensors: laser, camera, gripper, bumper, odometry
• Pushing methods:
– Bumper: two robots calculate applied forces and share this
information with each other to determine which robot should push
harder
– Odometry: two robots calculate their relative displacements along line
of pushing, share this information and try to reduce difference of
relative displacements
– Grippers: two robots compute angles between line of pushing and
actual moving direction; take action to reduce this angle during next
step; no information sharing (comm) required
– Laser or camera: helper robot calculates relative vector of box and
enables robots push box; helper has to move with robots and keep
them in FOV
Multi-robot Transportation (ASyMTRe-D)
• Robots assigned series of goal positions to visit
ASyMTRe vs. ASYmTRe-D
ASyMTRe vs. ASYmTRe-D
Conclusion and Future Work
• ASyMTRe can be used as a lower-level for forming
robot coalitions to achieve higher level robot
operations such as task allocation and task planning
• Future work:
– Learning new semantic information labels
– Hierarchically and autonomously “chunking” schemas into
higher level capabilities
– Formation quality related issues
– Formal methods for incorprating motion constraints
– Other configuration search techniques besides greedy
– More expressive goal specifications
– Human-robot coalitions