5.2 Current Observations
The following observations regarding this system may be made at this
time. First, the following strengths have been noticed.
The use of images representing tile states is a very natural
mechanism for users to use in implementing a finite state machine for
recognizing tile types. In fact, users have been able to
implement sequences of tile states to recognize tiles without any
explicit recognition of the underlying finite state machine.
Similarly, users are able to make use of the visual representation of
tiles, directions, navigation commands, and motor commands with little
or no training. It is interesting that while the necessary
translation from absolute directions in the map to directions relative
to the robot was a significant source of confusion to the team members
when implementing the language and required several explanations,
using the result has been quite straightforward.
The system has shown itself to be quite useable by children. Four
children, aged eight through thirteen, have had the opportunity to
play with Altaira; a nine year old was able to create a line-following
ruleset equivalent to the one described in
Section 4.1
while the
thirteen year old was able to create a ruleset that was capable of
distinguishing and mapping curves and straight tiles. The difficulty
in implementing the examples other than line following lies not in the
language, but in the complexity of the problem itself (though, as we
discuss in the next group of observations, the system could help
manage this complexity better).
Several weaknesses have also been identified, which lead directly to the
extensions to the work currently in progress.
There is no mechanism analogous to separate compilation for parts of
rulesets. This leads to two difficulties. First, it is not possible
to divide the labor of creating rulesets among several people, as
there is no practical way to combine their work. Second, in
situations where one ruleset is essentially an extension of another
(such as the VPC compulsory and final problem), if an error is found
in the original ruleset there is no mechanism to automatically
incorporate changes in the extended ruleset. This needs to be
addressed to improve scalability.
The unstructured nature of the robot and tile states forces a single
state to be used to represent several pieces of information. In the
compulsory problem solution, a single tile state is used to represent
a tile type, the tile exits which have been explored, and the exit
which was used most recently. Using a structured state with multiple
components would permit these items to be separated, reducing the size
of the stateset and simplifying the rules.
It is very difficult to gain an overall sense of the structure of the
ruleset, and the transitions between states, when working with the
system. The rule editor window shows each rule in isolation; there is
no sense of its context. Consequently, it is very difficult to have
confidence in the correctness of a ruleset. This deficiency is
probably the greatest obstacle to ruleset development in the system as
it stands now.
The state menus are displayed as simple palettes. It is likely that
displaying them in a graphical format, as in
Figures 10 and
11
in this
paper, would help to provide this global view of the ruleset.
The available set of sensors can be expanded. The current program
design will add more short-range sensors (differential
sensors synthesized by using the difference between two
analog sensors) easily; long-range
sensors (sonar rangefinders) will be somewhat more difficult,
and will tie into the next extension.
The tile-based navigation should be replaced by a system
in which the robot's tile map is replaced by a more general,
feature-based map.
In this case, the state input to the rules is replaced by a local
pattern, and the existing simple lookup replaced by a pattern match.
In effect, the illusion provided by the state-based rule lookup now in
place
would be replaced by a reality which would be appropriate to more
general environments. It would also be necessary to replace the
navigator with a more complete module which would maintain both exact
position and direction, and would be updated based on distance sensor
( e.g. sonar) readings.
An alternative direction for future research lies in using Altaira as
an introduction to programming for children (LEGOsheets and LEGO Logo
were both developed for this environment, as well). We have contacted
several grade school and middle school teachers in our local area, who
have expressed interest in this application of the language.
web page last updated on March 18, 1998