Defense Algorithms

Introduction

Defense algorithms are a special set of algorithm implementations that try to protect or defend important areas or agents. In this wiki page, we'll highlight some of the defense algorithms provided in the GAMS repository.

Shield

This algorithm is under review. When we have an implementation appropriate for groups, we will outline its usage here.

Zone Coverage

Zone coverage is a core algorithm that can be invoked via the device.{.id}.command, swarm.command and other invocation commands. Information on arguments necessary are provided below.

Arguments

Key	Value	Description
command	"zone coverage"	Command to initialize algorithm

The following are all optional arguments to the zone coverage command.

Arg	Value	Required	Default	Description
assets	string	No. Default	assets	group name for asset agents
buffer	double	No. Default	2.0	Distance between members in meters
enemies	string	No. Default	enemies	group name for enemy agents
formation	string	No. Default	line	type of formation (line | arc | onion)
protectors	string	No. Default	protectors	group name for protector agents

Buffer is the distance in meters that the protectors will try to keep between them. This is not a guaranteed separation, and no guarantee of collision avoidance is provided. No attempt is made to avoid collision with enemies, or the protected assets.

Assets, enemies, and protectors specify group names. By default they point to "group.assets", "group.enemies", and "group.protectors", respectively. As with other algorithms like formation sync, you must define members in groups. Currently, for assets and enemies, only group sizes of 1 are supported. If a larger group is specified, on the first member will be used. An arbitrarily large number of protectors may be specified.

The asset/enemies/protectors value provided as an argument is the name of a group that has already been defined in the knowledge base. To define a group, simply create a MADARA String_Vector container that points to a location in the knowledge base with the prefix "group." and the postfix "members". So, if you wanted to define a group called "defender_beta", then you would create a String_Vector that pointed to "group.defender_beta.members". You would then add the defender_beta members to the String_Vector and send this out to all of the devices that would need to participate in the formation (at the least). The group listing does not have to be in any kind of order, but the order the group listing is specified will determine the position of the device in the formation.

group.protected.size=1;
group.protected.0="agent.0";
group.defender_2.size=4;
group.defender_2.0="agent.1";
group.defender_2.1="agent.3";
group.defender_2.2="agent.4";
group.defender_2.3="agent.5";
group.attackers.size=1;
group.attackers.0="agent.2";

agent.4.command="zone coverage";
agent.4.command.size=0; // dummy for backwards compatibility
agent.4.command.formation="line";
agent.4.command.assets="protected";
agent.4.command.protectors="defender_2";
agent.4.command.enemies="attackers";

Arguments may be specified in two formats: a "vector-style" and a "map-style". The vector-style is consistent with older GAMS algorithms. The map-style is newer, and will eventually be the exclusive style available, but for now, is only available for agent.N.command arguments. Other methods of launching commands (e.g., swarm.command) only support vector-style.

In vector-style, the key value pairs are expressed as follows:

agent.0.command="zone coverage";
agent.0.command.size=4;        // number of key-value pairs, times two
agent.0.command.0="buffer";    // first key name
agent.0.command.1=3.0;         // first value
agent.0.command.2="formation"; // second key name
agent.0.command.3="arc";       // second value

The same semantics expressed in map-style are:

agent.0.command="zone coverage";
agent.0.command.size=0;          // dummy required for backwards compatibility
agent.0.command.buffer=3.0;      // first parameter
agent.0.command.formation="arc"; // second parameter