GOAL-DTU: Development of Distributed Intelligence for the Multi-Agent Programming Contest

Abstract

We provide a brief description of the GOAL-DTU system for the Multi-Agent Programming Contest, including the overall strategy and how the system is designed to apply this strategy. Our agents are implemented using the GOAL programming language. We evaluate the performance of our agents for the contest, and finally also discuss how to improve the system based on analysis of its strengths and weaknesses.

A Team Overview: Short Answers

1.1 A.1 Participants and Their Background

• What was your motivation to participate in the contest? To work on implementing a multi-agent system capable of competing in a realistic, albeit simulated, scenario.

• What is the history of your group? (course project, thesis, $\ldots$) The name of our team is GOAL-DTU. We participated in the contest in 2009 and 2010 as the Jason-DTU team [4, 5], in 2011 and 2012 as the Python-DTU team [6, 7], in 2013 and 2014 as the GOAL-DTU team [8], in 2015/2016 as the Python-DTU team [9] and in 2017 and 2018 as the Jason-DTU team [10]. The members of the team are as follows:

  • Jørgen Villadsen, PhD

  • Alexander Birch Jensen, PhD student

  Asta Halkjær From, MSc student and now PhD student, was a consultant until the tournament started. We are affiliated with the Algorithms, Logic and Graphs section at DTU Compute, Department of Applied Mathematics and Computer Science, Technical University of Denmark (DTU). DTU Compute is located in the greater Copenhagen area. The main contact is associate professor Jørgen Villadsen, email: ’jovi@dtu.dk’

• What is your field of research? Which work therein is related? We are responsible for the Artificial Intelligence and Algorithms study line of the MSc in Computer Science and Engineering programme.

1.2 A.2 Statistics

• How much time did you invest in the contest (for programming, organizing your group, other)? Approximately 200 man hours

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

• How many people were involved? 3 (1 programming)

• When did you start working on your agents? August 2019

1.3 A.3 Agent system details

• How does the team work together? (i.e. coordination, information sharing, ...) How decentralised is your approach? A task is delegated to a set of agents that are attached to the needed blocks. One agent is assigned as the so-called submit agent and the other agents follow/search for this submit agent before aligning the pattern in a goal area. Beyond this, each agent keeps track of the position of other agents. This information is exchanged when two agents are within vision range. The agents confirm their identify by agreeing on the part of the environment they both are able to perceive based on vision.

• Do your agents make use of the following features: Planning, Learning, Organisations, Norms? If so, please elaborate briefly. Planning is used when delegating tasks. Agents have set positions in the final pattern for submission.

• Can your agents change their behavior during runtime? If so, what triggers the changes? The agent’s behavior changes if they are delegated a submission task. Furthermore, other agents will try to avoid blocking agents with a task.

• Did you have to make changes to the team (e.g. fix critical bugs) during the contest? We encountered timeout problems when the simulations ran too fast. We did not manage to resolve this beyond putting artificial limit. Furthermore, we did not manage to handle the automatic transition between simulations in each matchup.

• How did you go about debugging your system? Partly using the debugger and partly using console output.

• During the contest you were not allowed to watch the matches. How did you understand what your team of agents was doing? Did this understanding help you to improve your team’s performance? We tracked them using console output although this feature could be vastly improved. It did not help towards performance beyond discovering timeout problems in fast simulations.

• Did you invest time in making your agents more robust? How? Some robustness comes almost for free using GOAL as we never deeply commit to a plan. We also considered tracking if an agent ending being stuck, but ultimately the feature was not completed.

1.4 A.4 Scenario and Strategy

• What is the main strategy of your agent team?

  • If the agent is selected to hand in blocks for a task (part of a task plan):

    • Detach any attached blocks not needed for the task. The agent will only detach blocks if it considers it non-obstructive to future movement. If not, it will move until it reaches a position where it considers it safe to detach.

    • Rotate the block into the position dictated by the task plan. If rotation is blocked, move until rotation is possible.

    • If the agent observes part of the pattern to be handed in, or if the agent is the one to submit the task and is on a goal, wait for other agents (skip action).

    • If the agent observes the entire pattern, connect with other agents as described by the task plan and then submit (the submit action is performed by the submit agent).

    • If the agent finds the submit agent (waiting in a goal area), move to place the attachment(s) as described by the task plan to form the final pattern.

    • If the agent is the submit agent, move towards a goal area.

    • If not the submit agent and believe that submit agent is in a goal area, move towards the position of the submit agent.

    • If a goal area is known, move towards it (to see if we can find the submit agent there).

    • Move into the most promising direction based on the exploration heuristics.

  • If the agent is not selected to hand in any task (not part of the current task plan)

    • If a block or dispenser is in vision:

      • $*$ Rotate such that a free attachment spot is facing the direction of the block/dispenser. If rotation is blocked, move.

      • $*$ If it is a block, attach it to the agent.

      • $*$ If it is a dispenser, request a block.

      • $*$ If not next to the block, move towards it.

    • Move into the most promising direction based on the safe exploration heuristics.

  • Perform skip action.

• Your agents only got local perceptions of the whole scenario. Did your agents try to build a global view of the scenario for a specific purpose? If so, describe it briefly. No global view is attempted beyond the position of other agents in the team.

• How do your agents decide which tasks to complete? Based on the currently collected blocks.

• Do your agents form ad-hoc teams to complete a task? Yes, see above.

• Which aspect(s) of the scenario did you find particularly challenging? The random map change events and deciding which blocks to clear (ultimately, we avoided trying to clear blocked paths).

• If another developer needs to integrate your techniques into their code (i.e., same programming language tools), how easy is it to make that integration work? That entirely depends on the programming language. Prolog is deeply integrated into much of the code.

1.5 A.5 And the moral of it is ...

• What did you learn from participating in the contest? We learned about using GOAL and general training in solving complex problems with no obvious solution.

• What are the strong and weak points of your team? Our agents are rather flexible and rarely idle. Weak points are that we are possibly too greedy collecting blocks which makes it harder to navigate the map as the simulation progresses.

• Where did you benefit from your chosen programming language, methodology, tools, and algorithms? GOAL helps our agents become flexible. We are forced to think in moment-to-moment reasoning and not just plans.

• Which problems did you encounter because of your chosen technologies? The freedom can make it harder to keep things simple as the complexity grows. Furthermore, GOAL had some integration issues with the provided EIS interface. We have to attempt changes to the source code to run.

• Did you encounter new problems during the contest? We were unaware of the feature that allows for multiple simulations without restarting. Furthermore, we had not tested GOAL with very fast simulations (the fact that we did not sent idle actions in our testing created an artificial slowdown).

• Did playing against other agent teams bring about new insights on your own agents? We learned that with another team playing the map became even harder to navigate based on our approach. However, we probably also won some matches by creating the same problem for the opponent.

• What would you improve (wrt. your agents) if you wanted to participate in the same contest a week from now (or next year)? Less rigid task submission plans and a less greedy approach to mindlessly collecting all blocks possible.

• Which aspect of your team cost you the most time? Navigating the map and trying to make the agents find each other for submission.

• What can be improved regarding the contest/scenario for next year? Set up test matches early using the contest setup to discover technical difficulties.

• Why did your team perform as it did? Why did the other teams perform better/worse than you did? We did not use roles for agents to help with different tasks. We saw other teams using interesting strategies to solve the tasks. Ultimately, we also had some false assumptions about the scenario which created artificial problems that could have been avoided. In the end, some parts of the design should be completely redone.