} }
In the code in Listing 3-4, the main task simply performs sensor and variable initialization, and then exits, leaving the execution to all the other tasks. You could use separate tasks to monitor the sensors continuously, to refresh the NXT display, and to run the FSM itself. In a more general situation than the one in the saturating counter example, a program that imple-ments an FSM can be composed of more tasks running simultaneously.
■ Note
You’ll learn about multitasking programs in Chapter 5, when I discuss the Omni-Biped software.The sensor-monitoring tasks would communicate with the FSM task by using global vari-ables, via function calls, or by passing variables as arguments. The most important task is the one implementing the FSM: the whole behavior of our FSM is in fact coded inside this task.
My purpose was just to whet your appetite; I won’t show any other example here. I’ll discuss an FSM implementation in detail in the program for the NXT Turtle, described in Chapter 6.
Decision Tables
For completeness, a final topic remains to be explained. For example, consider the problem pictured in Figure 3-5. You have a motorized arm that can swivel around by a maximum of 90 degrees. At the lower limit of its run, it has a limit switch, so that the arm can be brought to its zero position at every system startup. The arm has only four allowed positions, or states:
• 0: full down (limit switch pressed)
• 1: down
• 2: mid
• 3: up
C H A P T E R 3■ F I N I T E S TAT E M A C H I N E S 56
Figure 3-5. The robotic arm of the decision table example
Now, let the angle between state 0 and 1 be A, the one between 1 and 2 be B, and the last between 2 and 3 be C. You would want to move the arm around these allowed states, having as a sensor only the servomotor’s internal encoder. You can use the limit switch, which is pressed when the arm is in state 0, to reset the incremental encoder. This encoder is a sensor built inside the NXT servomotors, and is called incremental (or relative): it can measure the shaft angle relative to program startup or to a software reset command, although it cannot measure angles with respect to an absolute reference position. Every time the system is turned on, the encoder does not know the motor shaft position relative to a world reference system. The encoder starts measuring the shaft relative position from the startup angle, in a relative way. In our example, we want to measure the arm angle using as a reference the downmost position, cor-responding to the state 0. So, at the beginning of the program, we have to bring the arm down until the limit switch is closed; when the arm is in this downmost position, we can issue a reset command for the encoder.
Now you know the hardware framework. The problem is how to write a piece of software to move the arm between any two states of the allowed ones. For example, knowing that the arm is in state 0 and wanting to reach state 3, you should rotate the arm by an angle equal to A+B+C. To move from state 2 to 1, the arm should be rotated by an angle equal to –B. Finally, to go from state 2 to 0, the angle should be –A–B.
You can implement the solution to this problem as an FSM in many ways, by using the common NXC control flow structures if–then–elseor switch–case. If there are 4 allowed states, as shown in this simple example, you should write a total of 16 different functions to go from any state to another—taking also into account the cases in which you move from a state to come back to itself. This can be at least tiring, not to mention tricky and messy.
This is why decision tableswere created. Decision tables are a precise, compact, and ele-gant way to model complicated logic. You use them to associate conditions (the actual state) with actions to perform.
For the preceding example, the decision table contains the angles by which the servomo-tor must rotate to move the arm from the actual state to the new state. The system knows that the initial state is 0, after you’ve brought the arm to its zero position by using the limit switch.
You can write the decision table as shown in Table 3-1.
C H A P T E R 3■ F I N I T E S TAT E M A C H I N E S 57
Table 3-1. The Decision Table to Manage the Robotic Arm
Obviously, if the new state is the same as the actual state, the angle is null. Also, the actions are reversible. So, the angle to go, say, from state 3 to 0, is the opposite of the one to go from 0 to 3. The table is thus anti-symmetric, with the diagonal filled with zeroes.
Practical examples of decision tables are in the AT-ST program to control the legs and the head position, and in JohnNXT to move the head, the arms, the torso, and the laser. Yes, every JohnNXT moving part (except the treads) is regulated by its own state variable, by using these decision tables.
Summary
In this chapter, you got a smattering of information about FSMs: theoretic models used to give robots a simple behavior. I’ve analyzed the situation focusing on the aspects most relevant to our goals, and coupled the analysis with some practical examples. In the next chapter, you’ll build the AT-ST biped, with leg movements and general behaviors that are regulated with FSMs and decision tables.
C H A P T E R 3■ F I N I T E S TAT E M A C H I N E S 58
NXT AT-ST
A
lso known as “chicken walker,” because of its shape and walking motion, the All Terrain Scout Transport (AT-ST) is a bipedal war craft employed by the Galactic Imperial Forces in the Star Warssaga.In this chapter, you’ll build the AT-ST biped shown in Figure 4-1, guided by detailed build-ing instructions. You’ll program it to walk around, and by the end of this chapter, you’ll have at your command one of the most famous battle robots in the history of cinema.
Figure 4-1. The impressive-looking NXT AT-ST
59