The Electronic Moth - fischertechnik Mobile Robots II Manual De Instrucciones

Conclusion:
If the robot finds the track, it follows it tirelessly. If we create the track
as a closed loop, the robot goes round it. But you must avoid too sharp
curves, where the photosensors could lose contact to the line. Although
the robot tries to locate the track again, we have to admit that this is
only possible where there are no obstacles.

4.6 The Electronic Moth

The problem of linking different modes of behavior such as searching,
following and avoiding has already arisen several times. Consequently, we
want to investigate the interaction of such behavior in another experiment.
Let's summarize our previous results. The simple light finder follows a
flashlight held in front of it more or less blindly. The robot assumes that no
obstacle can exist where the flashlight previously was. It also assumes that
it does not really reach the light. But these assumptions only correspond to
reality in exceptional cases. We are forced to guide the robot with the
flashlight around each obstacle. We actually would need a robot, which can
avoid obstacles on its own. To do this, we can supplement the "Robot with
Obstacle Detection" model with the property of light search, as shown in the
diagram. Connect the phototransistors to
patterns cannot be active simultaneously, they are assigned different
priorities. In this case, the robot is normally searching for light. If an
obstacle is detected, which is more or less a danger for the robot, the
behavior mode of obstacle avoidance becomes active. Once there is no
longer an obstacle, the robot can again search for the light source.
As a result, we have provided the robot with the essential capability to
navigate independently and avoid dangers. If you have a friend, who also
owns a fischertechnik construction kit, you can carry the experiment even
further. A light source is mounted an each of the two robots, and then the
robots search for each other.
We have worked according to the principle of "trial and error" until now.
You probably "simply" started with your programs and have discovered
during the course of experiments how the robot did what it was supposed
to (or how it didn't do that).
Of course, professional software developers cannot use such design
methods for their products. In such cases, a precise design strategy must
be defined before the first program line is written. That is not something
that you can simply do, but instead you use fixed guidelines. Procedures
have become standard, which use such strange names as "top-down
design." An attempt is made to define the overall system from the top
down, without dealing with all details from the start. Let's try to program
our moth according to the top-down design. To do this, we have to begin
with the main program, called the "main loop."
E6 and E7. We use everything else
from the obstacle detection
model. From a scientific
point of view,
we have equipped
the robot with two
behavior modes. But
because both behavior
The diagram shows the simple design. The main loop is composed simply of
the behavior modes necessary for the robot: SEARCH, CONTACT and GO. The
variable VAR1 seems strange to us, and how can be give priority to the
behavior modes of the robot with such a simple loop?
Well, priority is assigned by the sequence of the subprograms, and the vari-
able VAR1 serves for assigning the movement orders. If we think this over
very carefully, we can reduce the necessary drive
movements of the robot to a clearly
defined number of maneuvers. The robot needs
a search movement, an avoidance movement
and a correction movement. Avoidance and cor-
rection movements must be distinguished ac-
cording to directions: right or left. This makes it
clear that the SEARCH subprogram can calculate
one of n (n = total number of movements) pos-
sible movements. The same applies to the CON-
TACT
subprogram. Because CONTACT is executed after SEARCH, it overwrites the
instructions of SEARCH. The GO subprogram only executes what it is
commanded to do. The top-down design procedure really seems to be
useful. But we don't know what the subprograms look like. Let's start with
the first subprogram, SEARCH. This subprogram is responsible for querying
the photosensors. Depending on the two sensors, four possible variants
exist: left sensor, right sensor, left and right sensors, and no sensor. These
define exactly four possible drive maneuvers: FIND, FORWARD, LEFT and
RIGHT: These drive maneuvers are also assigned to subprograms; we are
proceeding strictly according to top-down design criteria.
The design of the first subprogram, SEARCH, is now clear. SEARCH provides
a parameter, which is converted into GO.
The actual subprogram is very simple. The output parameter is set via sever-
al comparisons. A check is conducted in the CONTACT subprogram in the
finished program to determine whether obstacles triggered the sensor on the
robot. For simplicity's sake, we will ignore this program now and take a
look at how the motor movements are activated in GO.
Surprisingly, this subprogram calls additional subprograms. Doesn't this ever
GB+USA
25