A Multi-Robot Environment using MAGNET and Player/Stage

1. A Multi-Robot Environment using MAGNET and Player/Stage Or What I Did on My Summer Vacation

2. Summer • Drove to Minneapolis • Wrote some software • Drove back to Pittsburgh

3. Preliminaries • Worked at University of Minnesota • In the AIRVL lab • For Maria Gini • Distributed Robotics and Intelligent Agents for Electronic Commerce

4. 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

5. 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)

6. 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.

7. 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

8. 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.

9. 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.

10. The Language Plan Language: Keywords: plan, constraint, agent, self, begin_when, end_when, start, finish, succeed, fail, true, try Plan: '{' PlanContents '}' | PLANNAME PlanContents: PlanContents (Define|Agent|Begin|End|Executable) ';' Define: plan PLANNAME Plan | constraint CONSTRAINTNAME Constraint Agent: agent AGENTNAME | self Begin: begin_when Constraint End: end_when Constraint Executable: [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

11. The Language Informal Semantics: plan: Plans contain a set of actions and other plans which they execute simultaneously. constraint: Constraints are boolean conditions agent: 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 subtree begin_when: the plan begins executing its actions and sub-plans when this is true end_when: the plan will not succeed unless this is true start: specifies a constraint that is met once the named plan begins finish: specifies a constraint that is met once the named plan ends succeed: specifies a constraint that is met once the named plan succeeds fail: specifies a constraint that is met once the named plan fails true: specifies a constraint that is always met define: defines a named plan or constraint try: the plan will attempt to execute the given action or plan, but failure will not propagate upwards

12. The Language • This is enough to compactly describe all the plans I was working with. • Patrol • Rendezvous • Scan at location(s)

13. 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.

14. 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.

15. 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.

16. 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.

17. What’s missing • All covariances are zero • Masters student got a real job, bid generation doesn’t really work.

18. 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.

19. 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

20. 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

21. 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

22. 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.

23. 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

24. 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.