Eager vs. Lazy Sensing

Eager sensing is the policy of continually having sensors on, and feeding environmental data into the architecture. Architectures that have such a policy make two assumptions:

  1. sensing ought to be done often, and
  2. sensing is a cheap operation

Sensing ought to be done often in dynamic and unpredictable environments. In such environments an architecture's internal model of reality my quickly become out-of-date because events beyond its control happen. Also, if the architecture wants to assure a rapid speed of response it helps to continually sense to monitor its own actions.

That sensing is a cheap operation depends alot on the sensors and the domain. We may generalize the notion of "cost" to be penalities of operating. Eager sensors assume a low penality. A specific consideration is "is there adequate energy to operate the sensor?" Passive sensors, in general, are more energy efficient than passive ones.

The advantages of eager sensing are:

  1. the architecture is more assured of having a correct model of the environmet
  2. the architecture can have more confidence sooner that its own actions were done correctly.

Lazy sensing is the policy of only having sensors on when environmental data is specifically requested. Architectures that have such a policy assume sensing is a costly operation.

As was mentioned for eager sensing, "cost" may have many dimensions. Active sensors generally take more energy to operate, so it makes sense only to have them on when their data will be used. Active sensors may unintentionally jam each other (e.g. sonar in an enclosed area), so their usage might have to be synchronize. In some applications, obtaining information with active sensors might be fatal for the agent's life (e.g. a radar-equiped military robot facing an opponent who scans for radar), or made have bad effects on someone else's health (e.g. a medical expert system that must decide whether the benefit of performing an X-ray is worth the health risk).


Examples of Eager Sensing Architectures are:

  • Atlantis by E. Gat. The control layer is assumed always active.
  • Behavior-Based Programming by R. Brooks. All modules are always running, even if suppressed.
  • ERE by Drummond et al. The reactor needs sense data to complete its plans.
  • Homer by Vere & Bickmore. The plan interpreter needs sense data to complete its plans.
  • Icarus by Langley. Meander needs sense data to complete its plans.
  • RALPH by Ogasawara and Russell. RALPH needs sense data to do sense-propose-decide loops.
  • Subsumption Architecture by R. Brooks. All modules are always running, even if suppressed.

  • Examples of Lazy Sensing Architectures are:

  • Theo by T. Mitchell et al. Mitchell describes Theo-Agent as a "lazy sensor".

  • Examples of Architectures that make no commitment are:

  • Dynamic Control Architecture by B. Hayes-Roth. The Communication Interface, not the architecture, deals with sensing.
  • SOAR by A. Newell et al. A production system that does not interface with the sensors directly.
  • Teton by VanLehn & Ball. A production system that does not interface with the sensors directly.
  • MAX by D. Kuokka. MAX is too low-level to make a commitment.

  • Other Properties

    Back to the Title Page