Distributed Decision-Making Based on Shared Knowledge in the Multi-Agent Programming Contest

Abstract

The second Multi-Agent Programming Contest 2018 team of the Technische Universität Berlin results from the course Applied Artificial Intelligence Project that has taken place in the summer term 2018. The given target was to use our decision-making and planning framework ROS Hybrid Behaviour Planner (RHBP), which allows developing distributed multi-agent systems in the robotics domain. For the 2018 edition of the contest, the students particularly evaluated recently introduced features for knowledge sharing in RHBP. The united team for the official contest is formed by students from the course and their supervisors.

1 Team Overview: Short Answers

1.1 1.1 Participants and Their Background

• What was your motivation to participate in the contest?

  • The motivation for the participation is twofold. First, we wanted to further evaluate the performance of the RHBP framework within a complex scenario testing certain features. Secondly, students are introduced in the framework and try to apply it to the challenging scenario.

• What is the history of your group? (course project, thesis, ...)

  • Researchers of the DAI-Labor started to participate in the contest in 2007. Since then they have contributed to every edition of the contest and have won four of them using successive generations of the JIAC multi-agent framework. Our current team originates from the supervisors and two volunteering students from the “Applied Artificial Intelligence Project” summer term 2018 course of the Technische Universität Berlin. The applied framework RHBP is developed in one Ph.D. thesis and several independent Bachelor and Master’s theses.

• What is your field of research? Which work therein is related?

  • Our field of research is multi-agent systems applied in the robotics domain.

1.2 1.2 Development

• How much time did you invest in the contest for

  • programming vs. other tasks (for example organization)?

  • creating vs. optimizing your agents?

  • We spend approximately 300 h on the scenario-specific programming and 40 h on the team coordination and contest registration. Moreover, we have done almost no optimisation due to the fact that we still finalised foundational functionality until the contest started.

• How many lines of code did you produce for your final agent team?

  • 8600

• How many people were involved and to which degree?

  • Christopher-Eyk Hrabia (PhD Student at Technische Universität Berlin) - Supervision, technical consulting, RHBP improvements, MAPC communication infrastructure

  • Marc Schmidt and Marie Weintraud (MSc Students at Technische Universität Berlin) - Implementation of everything MAPC 2018 scenario specific like agent behaviour and strategy development.

  • Axel Hessler (Post-Doc at Technische Universität Berlin) was responsible for the infrastructure and overall administration.

• When did you start working on your agents?

  • Mid April 2018 (begin summer term)

1.3 1.3 System Details

• How do your agents work together? (coordination, information sharing, ...)

  • All information is shared amongst the agents. Information sharing differentiates in information that has to be persisted and information that is automatically updates and provided by the simulation server.

  • For each job one agent takes responsibility and coordinates the task decomposition and allocation with a contract net protocol.

• What are critical components of your team?

  • Our most critical components are the special ROS nodes implemented to exhibit the contract net protocol, namely the auctioneer and bidder. Furthermore, the new development pattern BehaviourGraphs for RHBP has also been critical for the executability of our team.

• Can your agents change their behaviour during runtime? If so, what triggers the changes?

  • No, but our agents adjust their behaviour based on the selected behaviour implementations, which is selected through decision-making and planning of RHBP.

• Did you have to make changes to the team (e.g. fix critical bugs) during the contest?

  • Yes, we did not consider to have that many wells and needed to bugfix our code to be able to create more wells. The reason for this was that in the contest setup all jobs allowed to gain considerable more money in comparison to the sample configuration, shared before the contest, which made building wells much easier.

• How do you organize your agents? Do you use e.g. hierarchies? Is your organization implicit or explicit?

  • We have an explicit organisation through contract-net protocol for the job fulfilment.

  • The auctioning agent (job responsible agent) is selected round robin based on the job-id.

  • Drones are responsible for exploration after an initial exploration stage where all agents are implicitly coordinated exploring the map

  • In general, all agents are allowed to fulfill all tasks

• Is most of your agents’ behavior emergent on an individual or team level?

  • We apply a hybrid planning and decision making framework (RHBP - ROS Hybrid Behaviour Planner) for the execution of the agent behaviours. This results in adaptive and reactive behaviour for individual agents, based on the current perception. But the deliberative part still tries to optimize/plan for shortest routes and resource management as charging. All in all this might lead to emergent behaviour on individual and team level.

• If your agents perform some planning, how many steps do they plan ahead?

  • Agent plan ahead as far as possible to determine if a job can be completed within one simulation (max. 1000steps)

  • RHBP planner has a configurable limit for planning steps, here 1000 steps.

• If you have a perceive-think-act cycle, how is it synchronized with the server?

  • The decision-making and planning cycle, which we consider the “think”, is initially triggered by the “request action” (“perceive”) from the server for each agent. If answering a request action takes too long the agents are dropping the request and are starting over with the most recent request.

• How did you go about debugging your system?

  • We have not used special tools besides RHBP rqt plugings. In general we applied manual logging and stepwise debugging with PyCharm.

• Which operating system did you use, and is your team portable to other operating systems?

  • Ubuntu 16.04 - Everything (every Linux) that supports ROS will work.

• What hardware did you use to run your agent team? (RAM, CPU, disk space, multiple computers, any other notable requirements)

  • Virtual Machine with 32 GB RAM, 4 Cores Intel(R) Xeon(R) CPU E5-2697A v4 @2.60 GHz, no special hard-disk.

1.4 1.4 Scenario and Strategy

• What is the main strategy of your agent team? Our strategy is based on the following parts.

  • Exploration with drones

  • If jobs can be fulfilled they are targeted with highest priority.

  • If no job is in queue and enough money for well building is available, wells are build

  • If neither jobs are targeted or wells are built, opponent wells are attacked

  • In all other cases the agents are randomly exploring the resource nodes and already build wells.

• How do your agents decide which jobs to complete?

  • Only mission jobs and priced jobs are addressed.

  • We do not have a cost-benefit analysis, we try to complete jobs in the order they appear.

  • If jobs can be completed in time they are processed

• Do you have different strategies for the different roles?

  • Partially yes, in our strategy drones are responsible for exploration but in general everything else is done by all agents.

• Do your agents form ad-hoc teams to complete a task?

  • No, all job completion is pre-planned by the coordination agents.

• How do your agents decide when and where to build wells?

  • The selected position depends on the location of the agent. Building takes place if enough money is available and no other job tasks are due, see above.

• If your agents accumulated a lot of currency, why did they not spend it immediately?

  • The reason is that our solutions puts highest priority on job completion, this can potentially result in an accumulation of money .

1.5 1.5 And the Moral of It Is ...

• What did you learn from participating in the contest?

  • Focusing on strategic aspects would have improved the result.

  • The sample scenarios have been much more difficult than the final contest configurations, which made it difficult to configure our agents appropriately.

  • We should focus less on job completion because it was not as crucial as expected.

  • Effective well building/dismantling showed out to be more important.

• What are the strong and weak points of your team?

  • Strong: job completion

  • Weak: We have not been able to implement a cost-benefit analysis of jobs and our behaviour model is rigid not providing enough freedom for adaptation.

• How viable were your chosen programming language, methodology, tools, and algorithms?

  • The chosen approach with Python, ROS, RHBP was suitable and performed well in our opinion.

• Did you encounter new problems during the contest?

  • Yes, we pre-planned to less possible well building locations (we build around the border of the map)

• Did playing against other agent teams bring about new insights on your own agents?

  • Yes, our job execution performed well, but the locations for well building was not well chosen and leaded to long travel times for the agents.

• What would you improve if you wanted to participate in the same contest a week from now (or next year)?

  • We would put less priority on job completion and concentrate on more effective well building.

• Which aspect of your team cost you the most time?

  • Understanding this question as time of steps in the matches. Our agents spend most time for the on demand job completion as well as time for travelling between the well building locations.

• Why did your team perform as it did? Why did the other teams perform better/worse than you did?

  • Because we focused to much on fulfilling the scenario of the contest instead of developing a unique strategy.

1.6 1.6 The Future of the MAPC

• What can be improved regarding the contest for next year?

  • Providing similar preconditions for all participants: Hardware limitations, connection, match appointments.

• What kind of scenario would you like to play next? What kind of features should the new scenario have?

  • It would be interesting to have the possibility of eliminating opponent agents as well as a dynamic agent creation and not a fixed amount of agents.

  • The sample configuration should be closer to the actual contest configuration to allow for selecting the strategy more effectively.

• Should the teams be allowed to make changes to their agents during the contest (even based on opponent agent behaviour observed in earlier matches)? If yes, should only some changes be legal and which ones (e.g. bugfixes), and how to decide a change’s classification? If no, should we ensure that no changes are made and how?

  • No, all used code should be submitted before the contest. Nevertheless, bugfixes could be allowed through reviewed pull requests.

• Do you have ideas to reduce the impact of unforeseen strategies (e.g., playing a second leg after some time)?

  • Everything that is not exploiting bugs in the simulation and is possible with the given API should be allowed. Unforeseen strategies should be encouraged to make the contest more interesting. The challenge should be to create autonomous agents that are performing well also in unexpected situations.