Rules have four types of inputs: the robot's sensors, the state of the current tile, the robot's state, and the robot's direction. For any given input, either an exact match is required, or the rule may specify that input as a 'dontcare'. The inputs are defined as follows:
Sensors are unique in having more than a single instance of the type - (there are seven sensor inputs, but only one tile state, robot state, or direction. At present, only digital and analog sensors are supported (corresponding to the Zambonibug's touch and reflective infra-red sensors). The value of a digital sensor input is used directly as a boolean value, while analog sensors are thresholded. Each analog sensor's threshold, and a hysteresis setting, are user-adustable at run-time through a robot settings menu.
The digital sensors are displayed as squares, and the analog sensors as circles. In this rule, the state of the center analog sensor is ignored (denoted by the X in the circle). To enable the rule, the other two inboard sensors must be black (over tape), while the two outboard sensors must be white. The digital sensors are also ignored.
The state of the current tile is used as a second input in rule enabling. It should be remembered that the image associated with a tile state is of no significance to the system: it is defined using an editor to be described later, for the purpose of presenting the state to the user. When the state is created, it is assigned an index; a tile state matches the state required by a rule if its index matches the rule's input tile state index.
One additional complexity in the tile states is a result of the need to maintain the states relative to the robot, rather than relative to the map (otherwise, a straight road tile entered from the West would require different rules than one entered from the North). This is implemented by defining extra tile states where necessary, representing rotations of the state by 90, 180, and 270 degrees. A table defining a mapping between the rotations is defined as well. It is the user's responsibility to identify whether or not states are rotationally symmetric, after which the state editor automatically generates the extra states and mappings. The images for the automatically generated states are created by the system, as rotations of the original user-defined state's image. Whenever a tile state is read from the map it is rotated to normalize the state, and when it is written to the map it is rotated the opposite direction to denormalize it.
This rule's input tile state is used in this rule set to denote a situation in which a tile is being traversed for the first time, and both outboard sensors have identified tape marks.
In addition to the tile state, which is local to a particular tile, there is also a robot state which is carried with the robot. The robot state is used to declare sub-goals which must be satisfied in order to accomplish a larger task. The implementation of robot states is similar to tile states; once again, the user uses the state editor defines the image for the state, and an index is assigned to it. Unlike tile states, the robot state is inherently robot-centric, so there is no need for the rotation mechanism described above.
This rule's input robot state is a 'dontcare', so it is ignored.
The system also maintains a notion of the direction the robot is heading relative to the direction it was heading when it entered the current tile, under control of the Navigation command rule output (to be described below). The direction is partitioned into Forward, Back, Left, and Right for use as a rule input.
The rule shown in this example is used to recognize two types of
tiles: four-way intersections and three-way intersections, entered
from the center post. It is enabled when the tape marks identifying the
tile have been seen (as determined by the tile state), and the robot
encounters the split in the center tape (as determined by the analog
sensors). In point of fact, these circumstances will only occur when
the current direction happens to be \f(CWforward\fP, the robot state
is the \f(CWRobby\fP state, and the digital sensors are not active.
These inputs are not specified in the rule to keep the rule's priority
as low as possible (this has been found in practice to be a useful
programming heuristic in avoiding unexpected behaviors).