Like the SUO EA, our robot controller uses a rich plan representation to allow team members to share context and communicate with the user. Primitive actions in this domain are basic motion control and communication requests to the physical robot. A goal request from the user is decomposed into individual agent plans (recipes) and intentions to aid or interact with other agents. Recipes are composed of partially ordered sequences of tasks that in turn evolve into primitive actions.
The UV EA uses an internal architecture similar to the SUO EA, as shown in Figure 3. As in the SUO EA, the EA Manager continually applies its Acts to respond to new goals and facts posted in its database. The Acts correspond to algorithms for monitoring requirements at each layer in the MLAA architecture. Some implement user alerts and others implement autonomous control.
The inputs to the UV EA are plans to execute, policy declarations, status reports (including location, speed and orientation) from its own sensor suite, and messages from other agents. These messages include status reports of other agents, reports on mission success or failure, shared information, and requests for help. Depending on communication conditions or policy restrictions, an agent may, or may not, receive from team members status reports (up-to-date locations) of all friendly agents and other entities within visual range. Sentinels are extracted from plans and policy declarations, are evaluated when status reports are received, and may produce alerts. The alerts produced are designed to serve both the autonomous control via the plan manager component, and the user, although the needs of each vary considerably.
For our initial experimentation, all monitoring alerts were derived from regular state messages from each team member. A state message reports the current location, velocity, attitude, and sensor imprecision of an agent. A UV-Robotics Act similar to the SUO Act in Figure 5 is invoked every time a location report is posted in the EA Manager database. Such postings happen several times each second, because each robot receives two such messages every second from its own sensors and two from each team member, based on network conditions. It also receives similar state messages about entities within its own field of vision. This means in a team of three robots each agent will be handling a minimum of at least six state messages per second and possibly many more depending on the environment. Also, there are messages between agents for sharing information, which we are not currently considering except when they update state knowledge about adversarial entities. In the future, the UV EA will be extended to serve the higher layers of the architecture that have more in common with the SUO-EA alert types and triggers.
Our initial implementation of the UV EA detects the following types of alerts. We plan to implement additional monitoring during the project.
The UV EA uses the same techniques as the SUO EA (Section 6.7) for estimating VOA and greatly reducing the number of low-value alerts. In particular, the UV EA keeps event histories for each team member being monitored. These histories are used to determine the value of information and alerts, and to detect Stuck, Divergent, and No-status alerts. For example, the history indicates the time and the robot location at the last progress check, so if the current waypoint has not changed and the robot is further away from the waypoint, then the value of issuing a Divergent alert should be calculated.
The value of issuing an alert takes into consideration customizable latency thresholds and repetition parameters, which are associated with both the automated agent and the user. Some of the agent parameters are customized to improve performance, while others are a function of the behavior of the robot. For example, the value of a divergent alert will be a function of the expected velocity of the agent, because an agent traveling at speed will diverge more quickly than a slow agent. Similarly, a change in orientation will influence the value of an alert because a turning agent, while not decreasing the distance to the waypoint, may indeed be making progress toward the goal.
An example of how monitoring is used to facilitate autonomous control is illustrated by the situation where an agent is patrolling a designated area. When an evader becomes visible, the agent receives a Target-visible alert, which is of type adversarial activity detected. Reacting to either a high-priority policy to pursue evaders or an explicit plan step, the agent commits to a new goal Pursue named-evader. This goal is achieved by the activation and blending of three tasks: Follow named-evader, Relocate named-evader and Search-for named-evader. Thus, the robot will maintain pursuit even when the evader slips in and out of its field of vision.
The user's preferred strategy might be to report the first sighting of the evader or to track its position, noting whenever it disappears from view. However, the autonomous control requires notification only if the likelihood of recovering visual contact is deteriorating and the robot is searching aimlessly. At this point, a Target-Lost alert, which is of type plan constraint violated, will be sent to the agent's EA Manager (and possibly the user). In this example, a policy exists for reacting to this type of alert. It will cause the pursuit goal to be dropped and the original Patrol plan to be resumed.