Creating Algorithms (Java)

Introduction

GAMS provides an extensible algorithms infrastructure for encoding distributed artificial intelligence. The expressiveness of the algorithm infrastructure is limited only by a developer's imagination and the functionality of the platforms that the developer has access to. In this wiki, we take a look at how to extend the BaseAlgorithm class, the features that GAMS provides to algorithm developers, and the interactions between algorithms and platforms.

---

Methods

The GAMS controller directly calls three algorithm methods during normal execution: analyze, plan, and execute, in that order. Developers will need to provide implementations of each of these methods, and the intentions of these methods are the following:

1. analyze: Analyzes the state of the algorithm, the platform, sensor readings, knowledge, or the interactions amongst agents. Usually the results of this analysis are used to either effect better plans or to produce results that a human or another agent might find useful.
2. plan: Plans the next step or a sequence of next steps. Most algorithms provided by GAMS only plan one movement at a time. However, more extensive plans are certainly possible, and we do provide some examples of this, e.g., Snake Area Coverage--so named because the pathing looks serpentine.
3. execute: Executes the next planned action.

---

Method implementations: Blocking vs. Non-Blocking

All methods should be non-blocking to allow for platform.sense (), platform.analyze (), and algorithm.analyze () to be called frequently and for updates to the knowledge base to be sent out to other agents or human overseers. If you must use blocking calls, the best way to support them is to create a polling class/infrastructure that launches a thread for the blocking operation and provides a polling mechanism for checking if the blocking operation has completed.

---

Provided Variables and Platform Handle

GAMS provides pre-configured variables based on the invocation of initVars on the BaseController. The init_vars function provides the id of the agent along with the estimated number of processes, and this information is used to populate a set of variables in the knowledge base for usage in algorithms and platforms.

The key variables you should know about are the following:

• self: the Self class is a self-referencing variable based on the id of the agent. self.device is a container for all variables that begin with device.{.id} in the knowledge base (where .id is the id passed in through init_vars). self.id is an Integer container that directly maps to .id in the knowledge base.
• platform: The Base_Platform platform is a reference to the current platform (the sensors and actuators facade for controlling the platform). During the execute method for an area coverage algorithm, for instance, platform.move (Position location) might be called to order the agent to move to a new location. Anything implemented in a platform can be accessed via this handle
• status: Algorithm status is a set of flags that may be useful for algorithms, especially ones implemented as finite state machines. There are flags here that may be enabled to let other agents know you are deadlocked, waiting, ok, etc.
• sensors: Sensor is a facade for representing sensor readings, typically over a geographic area. Sensors can be configured with ranges to aid with discretization of search spaces, for instance.