Snuf architecture

Introduction

In this document I give a short outline of the architecture of the controlling software for Snuf. After this, the two main components of this architecture (the goal state machine and the echo-locator state machine) are described as well.

Architecture

The controlling software for Snuf is implemented in different layers. These layers represent the different abstractions used to control the behavior of Snuf. The architecture (see figure 1) was set up to make a flexible and extensible implementation possible using object oriented techniques.

Figure 1: Outline of architecture of controlling software.

As shown in the figure, the architecture is an event-driven design. At the top are the available event-sources: Sensors, echo-locator and timers. Among these events, some are generated from the Motor driver (bottom): the 'goal reached' and 'goal aborted' event, identifying if the given goal has been reached or if the given goal is aborted. Events are handled by state-machines. Depending on the current state, different actions can be taken. The goal-state machine is to define the next goal (location) for Snuf. The Echo-state machine is mainly for defining escape behavior, based on the echolocation input. Each state machine can add commands to the Command queue. The motor driver will execute commands (however, it is possible to add other 'execution machines'). This unit is responsible for controlling the motors. It will execute commands like 'go to position (x, y)', 'turn around r degrees' etc. So while the event handlers and motor driver are conceptually low level drivers, the state machines have a higher level of abstraction. By this is it possible to prescribe the behavior of Snuf in more 'high level' terms. I will describe the current implementation of state-machines in the next two sections.

Note the architecture is extensible in the number and types of events to be handled the number of states/and or state-machines, and the number and type of execution machines.

Goal State Machine

The goal state diagram (figure 2) describes how the state-machine can make a transition from one state to another and what event triggers such a transition.

Figure 2: A simplified sate diagram of the goal state machine.

Three states ('Default', 'GotoHome' and 'HomeAndChooseNew') define the general behavior of Snuf; two others ('GotoBatteryLoader' and 'Loading') are implemented for automatic battery charging. Each state defines a different goal to achieve. Table 1 gives a summary of these goals.

Table 1: Goal states

Most important is the searching for blocks in the default state and the 'Homing' of a captured block in the GoToHome state. So Snuf will first start looking for a block and if found, it would try to bring it to a location named 'home'. Figure 3 depicts this typical instance of a sequence of state transitions.

Figure 3: A typical instance of a sequence of goal-state transitions.

A 'GotoHome' goal state can be put back to the Default state by a Goal-Aborted event. This event is emitted from the Echo-locator typically. This engine will empty the command stack to enter emergency commands for escaping an object. Pre-empty a command will cause this goal-aborted event.

Echo state machine

The echo state machine defines the escaping behavior of Snuf. Its state-transitions are given in Figure 4.

Figure 4: A simplified sate diagram of the echo state machine.

Three events play an important role: 'No echo', 'Crit echo' and 'Esc Echo'. Actually, these events are from one source: the distance to some object, measured by the echo-locator. If the distance is larger than 25 cm, a 'NoEcho' event is fired. A distance between 15 and 25 cm will cause a Critical Echo event, and less than 15 cm will cause an Escape Echo event. As we can see in the picture, a critical echo will slow down the robot, and the command queue is pre-emptied to start a new command: move away from object. Since the echo locator also gains information about the direction of the object, it is possible to calculate a movement away from the object. If this state is entered too many times, the robot may have entered a kind of dead end, and therefore it will go to the EchoTooMany state to command a turnaround of 180 degrees. If the measured distance is even smaller than 15 cm, immediate action is taken: the robot is ordered to go back 5 cm. Note that this may not be enough to escape. If so, new state transitions are made from default via critical-state to the escape-state to go back another 5 cm.