- Mapping the Scenario
- Pseudocode and Flowcharting RSVP
- Statecharts for Robots and Objects
This chapter is from the book
This chapter is from the book
This chapter is from the book
Pseudocode and Flowcharting RSVP
Flowcharting is an RSVP used to work out the flow of control of an object to the whole system. It is a linear sequence of lines of instructions that can include any kind of looping, selection, or decision-making. A flowchart explains the process by using special box symbols that represent a certain type of work. Text displayed within the boxes describes a task, process, or instruction.
Flowcharts are a type of statechart (discussed later in this chapter) since they also contain states that are converted to actions and activities. Things like decisions and repetitions are easily represented, and what happens as the result of a branch can be simply depicted. Some suggest flowcharting before writing pseudocode. Pseudocode has the advantage of being easily converted to a programming language or utilized for documenting a program. It can also be easily changed. A flowchart requires a bit more work to change when using flowcharting software.
Table 3.4 list advantages and disadvantages of pseudocode and flowcharting. Both are great tools for working out the steps. It is a matter of personal taste which you will use at a particular time in a project.
Table 3.4 Advantages and Disadvantages of Pseudocode and Flowcharting
RSVP Type |
Advantages |
Disadvantages |
Pseudocode: A method of describing computer instructions using a combination of natural language or programming language. |
Easily created and modified in any word processor. Implementation is useful in any design. Written and understood easily. Easily converted to a programming language. |
Is not visual. No standardized style or format. More difficult to follow the logic. |
Flowcharting: Flow from the top to the bottom of a page. Each command is placed in a box of the appropriate shape, and arrows are used to direct program flow. |
Is visual, easier to communicate to others. Problems can be analyzed more effectively. |
Can become complex and clumsy for complicated logic. Alterations may require redrawing completely. |
The four common symbols used in flowcharting are
Start and stop: The start symbol represents the beginning of the flowchart with the label “start” appearing inside the symbol. The stop symbol represents the end of the flowchart with the label “stop” appearing inside the symbol. These are the only symbols with keyword labels.
Input and output: The input and output symbol contains data that is used for input (e.g., provided by the user) and data that is the result of processing (output).
Decisions: The decision symbol contains a question or a decision that has to be made.
Process: The process symbol contains brief descriptions (a few words) of a rule or some action taking place.
Figure 3.4 shows the common symbols of flowcharting.
)
Figure 3.4 The common symbols of flowcharting
Each symbol has an inbound or outbound arrow leading to or from another symbol. The start symbol has only one outbound arrow, and the stop symbol has only one inbound arrow. The “start” symbol represents the beginning of the flowchart with the label “start” appearing inside the symbol.
The “stop” symbol represents the end of the flowchart with the label “stop” appearing inside the symbol. These are the only symbols with keyword labels. The decision symbol will contain a question or a decision that has to be made. The process symbol will contain brief descriptions (a few words) of a rule or some action taking place. The decision symbol has one inbound arrow and two outbound arrows. Each arrow represents a decision path through the process starting from that symbol:
TRUE/YES
FALSE/NO
The process, input, and output symbols have one inbound and one outbound arrow. The symbols contain text that describes the rule or action, input or output. Figure 3.5 shows the “Lighting candles” flowchart.
)
Figure 3.5 The lighting candles flowchart
Notice at the beginning of the flowchart, below the start symbol, BR-1 is to wait until the singing begins. A decision is made on whether the singing has started. There are two paths: If the singing has not started, there is a FALSE/NO answer to the question and BR-1 continues to wait. If the singing has started, there is a TRUE/YES answer and BR-1 enters a loop or decision.
If there are candles to light, that is the decision. If yes, it gets the position of the next candle, positions the robot arm to the appropriate position to ignite the wick, and then ignites the wick. An input symbol is used to receive the position of the next candle to light. The BR-1 is to light all the candles and stops once complete.
Flow of Control and Control Structures
The task a robot executes can be a series of steps performed one after another, a sequential flow of control. The term flow of control details the direction the process takes, which way program control “flows.” Flow of control determines how a computer responds when given certain conditions and parameters. An example of sequential flow of control is in Figure 3.6. Another robot in our birthday scenario is BR-3. Its task is to open the door for the guests. Figure 3.6 shows the sequential flow of control for this task.
)
Figure 3.6 The flowchart for BR-3
The robot goes to the door, opens it, says, “Welcome,” and then closes the door and returns to its original location. This would look like a rather inconsiderate host. Did the doorbell ring, signaling BR-3 that guests were at the door? If someone was at the door, after saying “Welcome,” did BR-3 allow the guest to enter before closing the door? BR-3 should be able to act in a predictable way at the birthday party. That means making decisions based on events and doing things in repetition.
A decision symbol is used to construct branching for alternative flow controls. Decision symbols can be used to express decision, repetition, and case statements. A simple decision is structured as an if-then or if-then-else statement.
A simple if-then decision for BR-3 is shown in Figure 3.7 (a). “If Doorbell rings, then travel to door and open it.” Now BR-3 will wait until the guest(s) enters before it says “Welcome.” Notice the alternative action to be taken if the guest(s) has not entered. BR-3 will wait 5 seconds and then check if the guest(s) has entered yet. If Yes then BR-3 says “Welcome” and closes the door. This is shown in Figure 3.7 (b) if-then-else; the alternative action is to wait.
)
Figure 3.7 The flowchart for if-then and if-then-else decisions
In Figure 3.7, the question (or condition test) to be answered is whether the doorbell has rung. What if there is more than one question/condition test that has to be met before BR-3 is to open the door? With about BR-1, what if there were multiple conditions that had to be met before lighting the candles:
“If there is a singing AND the lighter is lit then light the candles.”
In this case, both conditions have to be met. This is called a Nested decision or condition.
What if there is a question or condition in which there are many different possible answers and each answer or condition has a different action to take? For example, what if as our BR-1 or BR-3 travels across the room it encounters an object and has to maneuver around the object to reach its destination. It could check the range of the object in its path to determine the action to take to avoid it. If the object is within a certain range, BR-1 and BR-3 turn to the left either 90 degrees or 45 degrees, travel a path around the object, and then continue on their original path to their destinations as shown in Figure 3.8.
)
Figure 3.8 Robots obstacle avoidance
Using the flowchart, this can be expressed as a series of decisions or a case statement. A case is a type of decision where there are several possible answers to a question. With the series of decisions, the same question is asked three times, each with a different answer and action. With a case statement, the question is expressed only one time. Figure 3.9 contrasts the series of decisions in the case statement, which is simpler to read and understand what is going on.
)
Figure 3.9 Contrast case statement from a series of decisions
Repetition or looping is shown in Figure 3.10. In a loop, a simple decision is coupled with an action that is performed before or after the condition test. Depending on the result, the action is performed again. In Figure 3.10 (a), the action will be performed at least once. If the condition is not met (singing has not started—maybe everyone is having too much fun), the robot must continue to wait. This is an example of a do-until loop, “do” this action “until” this condition is true. A while loop performs the condition test first and if met, then the action is performed. This is depicted in Figure 3.10 (b), while singing has not started, wait. BR-1 will loop and wait until singing starts, as in the do-until loop. The difference is a wait is performed after the condition is met. Another type is the for loop, shown in Figure 3.10 (c), where the condition test controls the specific number of times the loop is executed.
)
Figure 3.10 Repetition flowcharts for (a) do-until, (b) while, and (c) for loops
Subroutines
When thinking about what role your robot is to play in a scenario or situation, the role is broken down into a series of actions. BR-1’s role is to be a host at a birthday party. This role is broken down into four states:
Idle
Traveling
Lighting candles
Waiting
Removing dishes
This can be broken down into a series of actions or tasks:
Wait until singing begins.
Travel to birthday cake table.
Light the candles on the cake.
Travel to the original location.
Wait until party is over.
Remove dishes from cake table.
Travel back to original location.
These are short descriptions of tasks. Each task can be further broken down into a series of steps or subroutines. “Lighting candles” is a composite state that is broken down into other substates:
Locating wick
Igniting wick
Actually, “Remove dishes from cake table” and “Travel back to original location” should also be broken down into subroutines. Removing dishes from the cake table requires the positioning of the robot arm to remove each plate and cup subroutines, and traveling requires the rotating of motors subroutines.
Figure 3.11 shows the flowcharting for LightingCandles and its subroutines LocatingWick and IgnitingWick.
)
Figure 3.11 Flowcharting for LightingCandles and its subroutines LocatingWick and IgnitingWick
A subroutine symbol is the same as a process symbol, but it contains the name of the subroutine with a vertical line on each side of the name of the subroutine. The name of a subroutine can be a phrase that describes the purpose of the subroutine.
Flowcharts are then developed for those subroutines. What’s great about using subroutines is the details don’t have to be figured out immediately. Figuring out how the robot will perform a task can be put off for a while. The highest level processes can be worked out and then later actions/tasks can be broken down.
A subroutine can be identified and generalized from similar steps used at different place, in the robot’s process. Instead of repeating a series of steps or developing different subroutines, the process can be generalized and placed in one subroutine that is called when needed. For example, the traveling procedure started out as a series of steps for BR-1 to travel to the cake table (TableTravel) and then a series of steps to travel back to its original location (OriginTravel). These are the same tasks with different starting and ending locations. Instead of subroutines that use the starting and ending locations, a Travel subroutine requires both the current and final locations of the robot to be used.