Figure 4 - vpl diagram to go in circles

Your final diagram should resemble Figure 4, and it is ready for initial testing. Building small pieces of code and testing them as you go is a good idea.

Before you run this program to drive the robot, you should consider the safety aspects. If you simply run the program as in Figure 4, then the robot will start up immediately when the program starts. This might take somebody by surprise and you do not want your robot crashing into people because it might hurt them or itself. Therefore you should have a "start button" so that you can tell it when to begin moving. If you are using a simulated robot then this is not a safety issue, but it is still good practise because the simulator takes a little while to start up.

Add a Data block and a SimpleDialog to your diagram as shown in Figure 5. Notice that the data type in the Data block is set to string and it contains the text "Press OK when the robot is ready". (You do not need to put the quotation marks around the text when you type it in). The output of the Data block goes to the input of the Simple Dialog, which you can drag from the Services toolbox. Hook up the Data block to use the AlertDialogaction of the Simple Dialog and in Data Connections connect the value to the AlertText. Drag a connection from the output of the Simple Dialog to the input of the Data block for the boolean value that sets theTurnRight value.

Figure 5 - Code to delay startup

The effect of these extra activities is to delay sending the request to the robot's drive system until you have clicked on the OK button in the Simple Dialog window. This pauses the program until you are sure that nobody is in the path of the robot. Another useful feature is that it usually takes a little bit of time for the program to start up and connect to the robot. (In the case of the iRobot Create you will hear a couple of tones from the robot when the connection is established). If you try to send a command before the robot is ready, in this case to the Generic Differential Drive service, then the request might be lost or cause an error. Trying to debug this sort of "race condition" is very difficult.

As in Lab 1, specify a manifest for the GenericDifferentialDrive and test out your program. You can chose a manifest for a simulated robot or a real robot. Run the program several times and vary the data values to verify that they affect the robot's behavior, i.e. the direction of the turn and the radius of the circle. The robot will drive in a circle until its batteries run out or you catch it and turn it off.

Step 2: Drive along an Arc

In Step 1, the robot continues driving in circles because its motor powers are still set. To drive along an arc, you must stop the motors after some period of time, I.E. Set the powers to zero.

For this purpose, you need to use the Timer service. Add one to your diagram and connect its input to the output of the Generic Differential Drive (associating the SetDrivePowerSuccess result with the SetTimerrequest). In the Data Connections dialog, check Edit Values Directly and type in 1500 for the value (the units are milliseconds). This allows you to specify an input value for the Timer even though Generic Differential Drive has no output. Instead, this link only indicates execution flow. (You could have accomplished the same thing with a Data block, but this is a useful shortcut that keeps your diagram from growing too large).