-
Notifications
You must be signed in to change notification settings - Fork 20
Defense Algorithms
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.
This algorithm is under review. When we have an implementation appropriate for groups, we will outline its usage here.
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 | 5.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 |
| protectors | string | No. Default | protectors | group name for protector agents |
Buffer is currently implemented in degree differences between agent positions, but this should really be metric-based instead in order to more intuitively work with the new Pose system between arbitrary reference frames. Meters is also easier to express for users than degrees (0.00001 is currently the default, which should be updated to something more user friendly, like 5.0 meters in the above table).
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.
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.formation="line";
agent.4.command.assets="protected";
agent.4.command.protectors="defender_2";
agent.4.command.enemies="attackers";