Sensing the Environment

EIS provides a standard model for agent-environment interaction in which the agent periodically senses the environment, generating a set of perceptions. Interleaved between the sensor invocations, the agent is able to perform actions in the environment. One consequence of this model is that EIS provides a standard format for the perceptions that it generates. The normal mechanism for handling this is to convert that format into whatever format is used by the associated agent language. This enforces replication of effort – raw data is converted into an intermediary format which is then converted into a final format – can have a significant impact on the performance of the agent language. It also raises the issue of how to distinguish between beliefs generated by the agent and beliefs that arise from the EIS perceptions. The solution in Jason, for example, is the use of annotated beliefs.

In ASTRA, a different approach is adopted:

  1. The percepts generated by EIS are stored in their intermediary format in a separate belief base, with one belief base per environment.
  2. Each time the agent senses its environment, the new percepts are compared against the previous percepts to identify what changes have occurred. These changes are mapped to custom EIS events that can be handled by plan rules.
  3. A custom EIS formula notation has been developed that allows the agent to query a specified EIS belief base. This can be either the default environment belief base of a specified belief base.

As indicated above, querying of the percepts generated by an EIS environment is done using a custom formula notation. For example, the below code extends the Tower program to check whether the gripper his holding block “a”:

  package examples;
  
  agent Tower {
      module EISAPI eis;
      module Console C;
      
      initial !init();
      
      rule +!init() {
          eis.launch("tower", "towerenv.jar");
          eis.join("tower");
          eis.link("gripper");
          if (eis.getState() == "paused") eis.startEnv();
          
          if (EIS.holding("a")) {
              C.println("the gripper is holding block a");
          } else {
              C.println("the gripper is NOT holding block a");
          }
      }
  }

This custom formula allows you to write code that checks the percepts from the EIS environment, but sometimes you want to trigger some behaviour based on the addition or retraction of some percept. This can be handled through a custom EIS event type as is indicated in the code below:

  package examples;
  
  agent Tower {
      module EISAPI eis;
      module Console C;
      
      initial !init();
      
      rule +!init() {
          eis.launch("tower", "towerenv.jar");
          eis.join("tower");
          eis.link("gripper");
          if (eis.getState() == "paused") eis.startEnv();
      }
      
      rule +@eis(string id, string entity, holding(string X)) {
          C.println("the gripper is holding " + X);
      }
  
      rule -@eis(string id, string entity, holding(string X)) {
          C.println("the gripper is no longer holding " + X);
      }
  }

As can be seen in this second example, EIS events are treated in much the same way as standard belief events. The difference is the syntax, and the inclusion of two fields: id and entity. These fields hold the id of the environment in which the event occurred (here id would be bound to “tower”) and the name of the entity that generated the percept (here the entity would be “gripper”).

This may seen a little overly complex compared to the formula used to query the percept, but there is good reason for it: ASTRA allows an agent to join multiple EIS environments and to control multiple EIS entities. For the purposes of an agent that is linked to only one environment and one entity, these fields can be ignored. Further information on how to link an agent to multiple environments and/or multiple entities is provided in later sections of this lesson.