www.it-ebooks.info
Visual Programming
Examples
The previous two chapters explained the basics of the Microsoft Visual Programming Language (VPL) and showed how VPL can be used to read robot sensors and control robot actuators. Be sure that you are familiar with the material in Chapters 10 and 11 before reading this one. This chapter offers a few more examples that show how VPL can be used to solve a variety of problems. The examples use the Simulation Environment instead of actual robot hardware so that they are accessible to everyone. In most cases, they can be converted to run with actual hardware just by changing the manifest that is used.
Each example is independent of the others so feel free to dive in and devour a few or just take a bite from all of them.
VPL Explorer
The ExplorerSim service presented in Chapter 9 showed an example of a simulation scenario in which a robot explores its environment and avoids obstacles using its sensors. This type of orchestration service can also be implemented using VPL.
The VPLExplorer project in the chapter12 directory shows an example of how this can be done with a simulated Pioneer3DX robot. This robot is the same one used in the Chapter 9 ExplorerSim service. It is popular for this type of algorithm because of its built-in laser range finder (LRF), which provides accurate distance measurements to obstacles around the robot. The main challenge in this scenario is processing all of the data coming from the LRF at the rate it is produced.
www.it-ebooks.info
Part III: Visual Programming Language
This VPL example was first posted by Paul Roberts on the MSDN Channel 9 Forum in January, 2007. You can see his original post at http://channel9.msdn.com/ShowPost.aspx?PostID=270510.
This section describes several modifications that have been made to Paul’s original diagram. When you run the diagram by pressing F5, the Pioneer3DX robot should be displayed in a Simulation Environment along with several obstacles. The robot should begin moving around on its own, turning as necessary to avoid the obstacles. If you have a wired Xbox controller, you can also use the controller to override the movement of the robot. The robot goes into Manual mode when the Right Shoulder button is held down. In Manual mode, the left thumbstick turns the robot, while the left trigger moves the robot backward and the right trigger moves it forward. In this mode, the controller vibration is used to indicate when the robot is close to an obstacle.
When the VPLExplorer diagram is loaded, it should look like the diagram shown in Figure 12-1.
Figure 12-1
Interfacing with the Xbox Controller
It is often easiest to understand a complicated diagram like this one when it is broken apart into pieces. The activities associated with the Xbox controller are shown in Figure 12-2.
www.it-ebooks.info
Chapter 12: Visual Programming Examples
Figure 12-2
As you can see from the diagram, three different notifications are used from the XInputController activity: TriggersChanged, ThumbsticksChanged, and ButtonsChanged. When either the triggers
or the thumbsticks change, a Get message is sent to the XInputController activity, which responds with the current state of the controller. If the LeftShoulder button is not pressed and the value of the state. State variable is Manual, then the positions of the triggers are used to set the DrivePower on the robot.
The state variable is set to Manual when the RightShoulder button is pressed. The second row of the diagram shows how this happens. When a ButtonsChanged notification is sent, the State variable is set to Manual if the RightShoulder button is pressed and to Unknown if it is not pressed. In addition, the vibration of the controller is set to 0 if it is not pressed. An AlertDialog displays the new state whenever it changes due to a RightShoulder button press.
Reading the LRF Data
The activities used to process the LRF data are shown in Figure 12-3.
Figure 12-3
One interesting aspect of this diagram is the configuration of the SickLaserRangeFinder activity. This activity represents a service for the hardware LRF. Unfortunately, not everyone has a robot with a $10,000 LRF, so we have used simulation for this example. In the past, we have used a generic contract activity and configured it by attaching it to a real or simulated service in a manifest. Because there is no LRF generic contract defined in MRDS, we have configured this activity differently. Instead of selecting Use a Manifest on the configuration page, we specified Use Another Service and then the SimulatedLaserRangeFinder service was dragged onto the page. When VPL starts up all the services, it associates the SickLaserRangeFinder activity with the SimulatedLRF service, which was started in the demoscene.manifest.xml manifest associated with the diagram.
www.it-ebooks.info
Part III: Visual Programming Language
Each time the LaserRangeFinder activity generates a new set of distance measurements, it passes a message from its measurement notification. The simulated LRF sends measurement notifications four times per second. On some computers, it is difficult for the VPL diagram to process that much range data while also displaying the simulation engine window. In this case, the Busy variable is used to throttle the data back. If the Busy variable is true or if the array of measurements is empty, then the data is discarded; otherwise, it is passed along and the Busy variable is set to true.
At this point, the data is passed on to three separate Worker activity blocks. Each of these activity blocks represents the same Worker activity but the three messages are processed in parallel. Look carefully at the Offset and Limit values passed to each worker. The topmost activity is used to process the first 3/8 of the data, the middle activity processes the middle 2/8, and the bottom activity processes the remaining 3/8. Each of the activities is passed a Name string that identifies the range it is processing.
The purpose of the Worker activity is to scan through all of the range data and to return the smallest range that is not 0. The implementation of this activity is shown in Figure 12-4.
Figure 12-4
The LaserRangeFinder project in Chapter 11 showed how to iterate through the range data using a loop construct. The Worker activity uses recursion to step through the data.
If the input Offset + Increment value is larger than the input Limit, then the currently calculated nearest range is sent to the FoundClosest notification. This is the recursion limit. Otherwise, the current array value is compared to the previously nearest distance, and the Offset is incremented and passed back to the Worker ProcessLaser input. The Worker activity continues to pass messages to its own
www.it-ebooks.info
Chapter 12: Visual Programming Examples
input until the Limit is reached and then it will send a notification. Recursion is often a cleaner way to iterate over data in VPL because it doesn’t require any state variables. The state is maintained in the messages being passed.
Back in the main diagram, you see what happens to the Worker activity notifications in Figure 12-5.
Figure 12-5
The notifications are fed into three different If activities. Each If activity determines which result was calculated by matching the name that was passed into the Worker activity. Keep in mind that all three of these calculations are occurring in parallel and there is no way to know which one will finish first. When one finishes, it is identified and its output is saved in an appropriate variable, either Right, Left, or Center. When the Center notification is received, a message is constructed from all three variables and the State variable and passed on to the part of the diagram that acts on the results, as shown in Figure 12-6.
Figure 12-6
www.it-ebooks.info
Part III: Visual Programming Language
When the processing has completed, the Busy variable is set back to false so that another set of range data can be processed. The first If block checks whether the current state is Manual. If so, it sets the left vibration motor according to the center distance and the right vibration motor according to a combination of the right and left distances. This provides tactile feedback to the controller when the robot is running in Manual mode.
If the robot is not running Manual mode, then you start looking more closely at the distance data. If the robot state is Forwards and the closest center value is less then 2000, then the robot is approaching an obstacle head-on and is relatively close. The robot is stopped to prevent a collision with the obstacle and the State is set to Turn.
If the robot is in some state other than Manual or Forwards, then the diagram checks to see if there are no obstacles in the center closer than 3000. If that is the case, then the drive motor is set to move the robot forward and the state is set to Forwards. Finally, if the way ahead isn’t clear, then the robot is turned to the left or right depending on which value is closest.
This diagram incorporates many elements that are used in other diagrams, so it is worthy of some study until you fully understand what is going on. Don’t forget to click the connections between the activities so that you can see how the outputs from one activity are modified before being assigned to the inputs of another activity. Often, the calculations done between activities are relatively invisible but critical parts of the overall algorithm.
When you run the activity, you should see the robot move randomly through the environment, while, it is hoped, avoiding all obstacles, as shown in Figure 12-7.
Figure 12-7
www.it-ebooks.info
Chapter 12: Visual Programming Examples
VPL Sumo
Here is another example showing how you can take a complicated C# orchestration service and distill the robot behavior into a reasonably simple VPL diagram. In this case, parts of the sumo player algorithm implemented in the sample sumo player service shipped in the MRDS Sumo package have been implemented in a VPL diagram.
Like the VPLExplorer diagram in the previous section, the VPLSumo diagram shown here was written by Paul Roberts and posted to the MSDN Channel 9 forum. If you like this project, you should check out his posting to see the two other related diagrams he posted: http://channel9.msdn.com/ShowPost. aspx?PostID=341708.
Open the VPLSumoOne project in the chapter12 directory. You may be surprised at the simplicity of the main diagram and even more surprised when you see the Manouver action on the PlayerOne activity. Most of the functionality in the diagram is in the Start action on the PlayerOne activity.
The VPL Sumo Main Diagram
The main diagram is shown in Figure 12-8.
Figure 12-8
There are just two activities in the diagram and no connections at all. All of the sumo player stuff is in the PlayerOne activity. The SimulatedSumoReferee is there so that its service is started along with the sumo player service.
www.it-ebooks.info
Part III: Visual Programming Language
The PlayerOne Start Action
To understand the PlayerOne sumo player activity, you’ll have to look at the Start action. The first part of this action is shown in Figure 12-9.
Figure 12-9
The behavior of the sumo player is determined by its current mode, which is stored in the SumoMode variable. Here, it is initialized to the Initial mode. Then the state of the SimPlayerOne activity is retrieved with a Get Message. The SimPlayerOne activity represents the SimulatedIRobotLite service, which is the basic service that controls the simulated sumo robots. Its state is modified by setting a new name: “VPLSumo.” It is then passed back to the Configure input on the SimPlayerOne activity to set the new state. Finally, a message is passed to the Connect input of the SimPlayerOne activity, which causes it to announce itself to the referee service. At that point, the referee creates a Player1 sumobot in the Simulation Environment and allows the SimPlayerOne service to connect to it. The process of initializing a sumo player service through the sumo referee is explained in more detail in Chapter 9. Once the SimPlayerOne service is connected to the simulated sumobot, it can read the sensors on the robot and control the simulated robot’s drive.
The next part of the Start action is shown in Figure 12-10.
Figure 12-10
This part of the logic handles the button pushes on the top of the iRobot Create. When a sumobot is placed in the sumo ring, its Play button is pressed and it begins moving exactly five seconds later. When its Advance button is pressed, it becomes inactive.
www.it-ebooks.info
Chapter 12: Visual Programming Examples
In the simulated sumo ring, the referee service sends a message to the SimulatedIRobotLite service associated with the simulated player, telling it that one of its buttons has just been pushed. The SimulatedIRobotLite service responds by sending an UpdatePose notification to our service.
If the current SumoMode is Initial and the Play button has been pushed, then three things happen:
A timer is initialized with an interval of 5000 milliseconds.
The SumoMode is set to Pending, indicating that when the timer completes, play can begin.
The sumobot is stopped by sending a left and right drive value of 0 to the Manouver input of the PlayerOne activity.
If the SumoMode is not Initial, then the robot must already be executing its strategy. In this case, you check whether the Advance button was pressed. If so, the SumoMode is set back to Initial and the robot is stopped by setting its drive values to 0.
The logic that handles the timer completion in Pending mode is shown in Figure 12-11.
Figure 12-11
If the SumoMode is still Pending when the timer completes its five-second wait, then the SumoMode is set to Combat and the sumobot starts moving forward because the left and right drive values of the Manouver input are set to 250.
The logic that keeps the sumobot inside the sumo ring is shown in Figure 12-12.
Figure 12-12
www.it-ebooks.info
Part III: Visual Programming Language
Reading Data from the Infrared Sensors
The iRobot Create has four infrared floor sensors called cliff sensors. These sensors are identical to the cliff sensors used by the Roomba robot to avoid stairs as it vacuums. Two of the sensors are positioned near the front of the robot just left and right of center. The other two sensors are a little farther back on the left and right sides. When one of the floor sensors changes its value, the SimPlayerOne activity sends an UpdateCliffDetail notification. There are five possible cases to process.
If the current SumoMode is anything other than “Combat,” the UpdateCliffDetail notification is ignored.
If one of the front sensors detects the edge of the ring, drastic action must be taken to keep the robot from traveling outside the ring because that is the direction in which it is headed. In this case, a speed value of 300 is applied to the left wheel and a value of -400 is applied to the right wheel to cause the robot to make a sharp right turn.
If neither of the front sensors is over the outer ring but the left cliff sensor is, then the robot is traveling parallel to the edge of the ring. In this case, a speed value of 500 is applied to the left wheel and a value of 100 is applied to the right, causing the robot to make a more gradual right turn.
Like case 3, if the right cliff sensor is over the outer ring, the robot makes a gradual left turn.
The last case occurs when none of the cliff sensors is over the outer ring. In this case, the robot moves straight ahead with a speed value of 250 applied to each wheel.
These five cases specify the motion of the robot as it moves around the sumo ring. The only case not covered is when the front bumpers are engaged, and that is covered by the part of the Start action shown in Figure 12-13.
Figure 12-13
Reading the Create Bumper Sensors
It would be nice if our little sumobot were a bit more aggressive when it comes in contact with its opponent, and that’s what this logic does. The iRobot Create has a front-right bumper and a front-left bumper. This logic is fairly straightforward. When one of the bumpers state changes, an
