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.