5. Conclusions and future research

Altaira is a system which has undergone a very rapid development. In this section, some of the changes that have taken place in response to deficiencies in early versions are discussed, as well as observations regarding the present state of the system.

5.1 Evolution

Several of Altaira's features were introduced during its development specifically to address deficiencies in the original specification. These changes have redcuced the sizes of the rulesets, and also assisted in debugging.

  • The rule recorder was added in response to the difficulty of debugging rulesets. Frequently, while exploring a course, an unexpected behavior will occur, but there will be several more execution cycles before the user is able to react and stop the robot. This was a particular problem when executing in real mode, as the robot's inertia made single-stepping to identify the problem impractical. The rule recorder permits the necessary look back to the problem in the execution.

  • The original language specification did not have 'dontcare' rule inputs or 'nochange' rule outputs. Rule enabling and firing were combined into a multidimensional array lookup based on rule inputs (consequently, only a single rule could be enabled on any given execution cycle, so the notions of rule priority and amalgamation did not exist). Since reflexive, tactical, and strategic rule elements had to be present in all rules, the resulting rulesets were quite large and unwieldy (the original solution to the VPC compulsory problem required over 2100 rules).

  • Addressing this problem led to a new difficulty: identifying the rule responsible for a behavior. When an unexpected behavior occurs, there are 1024 different input combinations which may be responsible. This made locating an erroneous rule difficult, creating the need for the search mechanism.

    • The description of Altaira in [16] reflects the system's status before these changes were made.

    web page last updated on March 18, 1998