A Multi-Robot Environment using MAGNET and Player/Stage

OrWhat I Did on My Summer

Vacation

Summer Drove to Minneapolis Wrote some software Drove back to Pittsburgh

Preliminaries Worked at University of Minnesota In the AIRVL lab For Maria Gini

Distributed Robotics and Intelligent Agents for Electronic Commerce

The Project My initial proposal was to use a market

architecture to solve planning for multi-agent SLAM and exploration

What sort of interactions between agents might this entail? Includes all the problems the basic FIRE

scenario brings up Localization assistance is now a

commodity

The Project At the time this seemed like a

reasonable idea We could use existing UMN software

for the market (MAGNET, the Multi Agent Negotiation Testbed)

The lab is doing interesting work on the SLAM problem, and has existing EKF implementation which are supported in-house. (Rybski and Huet)

The Project At the time this seemed like a

reasonable idea The Player/Stage simulator works well

for simulating Pioneers with SICK lasers, which was the target hardware.

A masters student was already working on robot bidding algorithms for MAGNET as part of his thesis.

The Project So what did I actually get done?

Developed some ideas about planning for SLAM using the extended information matrix (sparsified inverse covariance matrix)

Worked out how to maintain an approximate freespace map using uncertain data from several robots using reverse kalman filter on position data

Wrote a 3-layer distributed multi-robot architecture that differs from FIRE in a few interesting ways

The Software I used one language for bidding,

execution, and behaviors. Saves on code and upkeep, since

there’s only one lexer/parser, and one set of parse tree node classes.

Inter-agent synchronization is handled by the success or failure of ‘comm actions’ rather than language features.

The Language Plans are a set of plans and actions. Plans have start and end constraints. Plans and actions end in either success or

failure. End state propagates upwards unless the

executable was specified as try-only. We can define new actions and plans in

terms of existing ones.

The LanguagePlan Language:

Keywords: plan, constraint, agent, self, begin_when, end_when, start, finish, succeed, fail, true, try

Plan: '{' PlanContents '}' | PLANNAMEPlanContents: PlanContents (Define|Agent|Begin|End|Executable) ';'Define: plan PLANNAME Plan | constraint CONSTRAINTNAME ConstraintAgent: agent AGENTNAME | selfBegin: begin_when ConstraintEnd: end_when ConstraintExecutable: [try] ([NAME] Plan|Action)Action: ACTIONNAME( Arguments )Constraint: CBase | Constraint ('&'|'|') Constraint | '!' Constraint | '('

Constraint ')'CBase: CONSTRAINTNAME | start PLANNAME | end PLANNAME | finish

PLANNAME | succeed PLANNAME | fail PLANNAME | true

The LanguageInformal Semantics:plan: Plans contain a set of actions and other plans which they execute

simultaneously.constraint: Constraints are boolean conditionsagent: The agent keyword tells a plan and its childen which agent is to execute

actions in this plan subtree.self: Specifies that the agent executing the plan is to carry out actions in this

subtreebegin_when: the plan begins executing its actions and sub-plans when this is trueend_when: the plan will not succeed unless this is truestart: specifies a constraint that is met once the named plan beginsfinish: specifies a constraint that is met once the named plan endssucceed: specifies a constraint that is met once the named plan succeedsfail: specifies a constraint that is met once the named plan failstrue: specifies a constraint that is always metdefine: defines a named plan or constrainttry: the plan will attempt to execute the given action or plan, but failure will not

propagate upwards

The Language This is enough to compactly

describe all the plans I was working with. Patrol Rendezvous Scan at location(s)

Behavioral Level Behaviors derive from the action

class of the language. They access hardware through a read/read-write lock mechanism which controls access to the Player server.

Actions can be used as combiners for other actions.

Executive Level Executes plans Maintains a globally shared and

automatically updated database of specific state data (agent positions, freespace estimates, etc)

Packages sets of laser scans into cell hits and sends them to a map server which compiles a global freespace estimate.

Planning/Market RFQs contain plans in the language.

This lets us express task bundles, or subtasks for secondary markets.

Incremental bidding procedure, if some tasks are unbid after the first round, request additional bids that must include at least one of the unbid tasks.

Planning/Market Market interface is an extension to

the MAGNET architecture to support distributed bidding with real suppliers, a GUI client, and a robot supplier client with JNI interface to the bid generation code.

What’s missing All covariances are zero Masters student got a real job, bid

generation doesn’t really work.

What Works? Behavioral and Executive are solid Simple bidding, bid search, and

task allocation work. Bid generation is too simple to be

interesting, but works.

Software I Didn’t Write MAGNET

General interface to combinatorial auctions. Developed for research on automated supply chains, electronic commerce, and other ‘real’ markets.

Easy to switch search algorithms Excellent logging, batch experiment execution. Not too difficult to switch bidding procedures Possible to use distributed agents

Software I Didn’t Write Magnet

No easy way to interface with a C/C++ environment.

Task descriptors are limited to commodity domains, not good for robotics tasks where task cost depends mostly on agent state.

www.cs.umn.edu/magnet for papers and info

Maria Gini and John Collins

Software I Didn’t Write Player/Stage

Widely used open source robot simulator, from USC

Clients connect to player server using one of a number of client libraries.

Player server talks to real hardware or a simulator

Software I Didn’t Write Player/Stage

Stage is a 2D simulator, Gazebo is a new 3D simulator with dynamics from the ODE library.

Not easy to extend, making minor changes to the simulator requires tweaking bits in client library, player, and stage.

Designed for mobile robots, primarily Pioneer-like ones.

Software I Didn’t Write Player drivers can encapsulate

high level functionality Localization filters, for eg

Works well with very large numbers of simple robots.

playerstage.sourceforge.net

Further Work Generate some results and write a paper

for ICRA 2004. Using a cargo transportation scenario with

heterogeneous robots. Compare different search algorithms, bidding

procedures. UMN undergrad Matt Reinke is

continuing development of the system. A more extensible bidder (mine was a quick

hack) Reuse executable and behavioral layers in

other projects.