With a swarm of UAVs it is important to have a policy that defines how individual UAVs perform. Like any good administrative task, this requires a swarm leader, whose location and knowledge make it the best choice. This demo suggests that if all UAVs are created equal, then there must be a way to automatically determine who is in charge and how other UAVs should work with the UAV in command. Rather than have some kind of bidding exercise, this demonstration suggests that all UAVs understand their own condition; and by publishing how they view themselves they could self organize, because they all operate under the same policies.
For this demo, we will assume that Distance to the Target is a primary driver. The UAV that is the closest is a likely candidate for leadership. Next is Orientation toward the Target. If the orientation is directly away from the target, then this UAV is less likely a candidate for leadership than one of equal distance from the target and already heading toward that target. Another condition is Threat Maneuver. If a UAV is in the middle of maneuvering to avoid a threat, then it may want to relinquish its command situation. The UAV's Weapon Supply is also a consideration. Also considered is the UAV's Health.
For this demo, we will show that leadership is a dynamic state. A UAV could become damaged, it could be forced to take evasive maneuvers to avoid a threat, or any number of other situations could arise that need to be considered while the UAVs are collectively pursuing the target. The leadership role can change dynamically with the new leader taking over for the old leader.
This demonstration also considers retreat as an equal objective as to determining leadership. If the weapon supply falls below a threshold or if the self-diagnosis determines the UAV is unworthy of participating in the mission, then the UAV will just go home.
For humans these are "subjective" policy decisions that can easily be modeled in KEEL, where they become 100% auditable, so policies can be re-evaluated and updated as necessary. When the policies are described with KEEL and implemented as KEEL Engines, they are no longer "subjective". The KEEL solutions are explicit.
For this reason, this KEEL design includes a number of "configuration parameters". These will help the human policy makers tune the policies without the KEEL language / toolkit. The general concept is that the mission itself will dictate how different parameters are interpreted. These configuration parameters are not exposed in this demonstration.
In this demonstration, six (6) UAVs are represented by balls. The user's mouse indicates the target (or goal for the UAVs to attack).
By moving the mouse over the screen (representing a very fast moving target), each of the UAVs will self-evaluate and determine if it should be the leader (it will turn RED), or if it should be a supporting UAV (it will turn BLACK).
The smaller circle within the larger circle indicates whether the UAV is in the process of some level of collision avoidance. If it is, this circle will turn Yellow. If it is not evaluating an obstacle, it will be shown as Green.
While the KEEL Engine for each of the UAVs is evaluating distance to the target, heading, threat status, diagnostic status and weapon supply, only distance to the target, heading, and threat avoidance have active sensors. As stated before, the configuration parameters defining the importance of the different variables used in the analysis are not displayed.
It is very difficult (impossible) to watch this demo and determine whether it is operating correctly. The KEEL toolkit, however, allows snapshots of the inputs to be used to drive the KEEL Toolkit (and the "dynamic graphical language") and see exactly how the data items are interpreted. This capability is required when dealing with any kind of safety critical application.
|
Copyright , Compsim LLC, All rights reserved |