Section 2.3 Customizing Region Behavior

This section gives you important information on the expected behavior of regions during runtime, and how you can customize those behaviors.

State-variable Properties

Recall the New Program dialogue introduced in the previous section.

The following describes the properties of each state variable.

• writable - True if this state-variable is writable. False if it is non-writable.
• unit - This is just eye candy for the GUI. You will notice that the unit is often displayed next to the state-variable name.
• error - Indicates the allowable error when affecting the state-variable. For example, suppose that we want the robot to change its Velocity to 2.0. Then, it's sufficient to get the Velocity to be between 1.9 and 2.1, given that the error property is 0.1. You need to take this property into consideration when programming, as this property will affect the execution of your program.
• description - A description of the state-variable

The error property is important, and we will refer to it in the remainder of this section.

The goTo Function

At this point we should learn one built-in GSSP function to facilitate our discussion. All built-in GSSP functions and variables are described in Section 2.8 Writing Code in GSSP. Let us create a simple GSSP program on which we can base our discussion. We will tell the robot to go to the location where Position X is 60 and Position Y is 60. If at any time the Battery Level becomes lower than 10, the robot will go to the location where Position X is 0 and Position Y is 0.

Create a new GSSP program using the Generic Robot state-variable set. Attach the following code to the global region.

goTo({'Velocity':3})
goTo({'Position X': 60, 'Position Y':60})
print "I am at the goal."

goTo is a built-in GSSP function that tells the robot to affect one or more writable state-variables. goTo takes as argument a python dictionary where the keys are the names of the state-variables, and the values are the desired values for each state-variable. Here we are telling the robot to change its Velocity to 3, and then change its Position X and Position Y both to 60. goTo is a blocking statement, meaning that execution is paused until the goTo function is completed. The first goTo will complete when the robot is travelling at a Velocity of 3. Then, the second goTo will initiate. After the robot has reached the specified Position X and Position Y, the print statement will be executed (print is a standard python function).

Note that the error property plays a role here. The error property for Velocity, Position X and Position Y are 0.1, 1, and 1 respectively, as we saw in the New Program dialogue. So if the robot gets its Velocity to 3.1, then the first goTo function may complete. Similarly, if the robot's Position X is 59, and Position Y is 61, then the second goTo function may complete.

You are probably wondering why we can't replace the two goTo statements with just one goTo statement: goTo({'Velocity':3, 'Position X': 60, 'Position Y':60}). The reason is that all state-variables given to the goTo function must be at the specified values at the same time in order for the goTo function to complete. By writing goTo({'Velocity':3}) followed by goTo({'Position X': 60, 'Position Y':60}), we are saying: Get the Velocity to 3, and then go to (X,Y)=(60,60), and the Velocity at which the robot travels when it arrives at (60,60) does not matter. On the other hand, by writing goTo({'Velocity':3, 'Position X': 60, 'Position Y':60}), we are saying: Go to (60,60) and travel at a Velocity of 3, but in order for the goTo function to complete, the robot must arrive at (60,60) while travelling at a Velocity of 3.

Now, create a region for Battery Level ranging from 0 to 10. Name this region "Low Battery", and attach the following code to the region.

goTo({'Position X': 0, 'Position Y':0})
goTo({'Velocity': 0})

This completes out simple GSSP program. Your program should now look like the following.

Note that on the right side of the Region Text Editor, there is a set options you can specify for the selected region. We will go through each of these options.

Priority

You might have noticed that if the robot is going towards (60,60), and the battery level drops below 10, then there is a conflict between what the global region wants the robot to do and what the Low Battery region wants the robot to do. The former still wants the robot to go to (60,60), while the latter wants the robot to go to (0,0).

A priority system is used to resolve such conflicts. Each region has a priority, which defaults to 25. You can modify the priority of a region using the Priority Text Field just below the Name Text Field. A higher number means higher priority. So, by changing the priority of Low Battery to a higher number like 26 will ensure that requests for state-variable changes originating from Low Battery will always have precedence over the requests originating from global. Another way to look at it is each call to the goTo function inherits the priority value of the region that called it.

Now, suppose that we have to regions. One region tells the robot to increase Velocity, and the other region tells the robot to turn right. Also suppose that these two regions have different priorities. In this case, the robot will increase Velocity and turn right. This is because there is no conflict between the requests originating from the two regions even though one has a higher priority. Since there is no conflict, both requests are sent to the robot.

But what happens if two regions have the same priority, and a conflict occurs between their goTo statements? In this case, the goTo statement that is executed later gets higher priority. Going back to our original program, if we did not increase the priority of Low Battery, then the program might still work the way we want. The global region gets activated when the GSSP program starts and goTo({'Position X': 60, 'Position Y':60}) is executed almost immediately. If we assume that the robot's Battery Level is at 100 in the beginning, then the Low Battery region must be activated some time later. Since Low Battery is activated later than global, its goTo function is executed later than global's goTo, meaning that Low Battery's goTo gets higher priority automatically.

Selection

Selection can be seen as a way to capture the negation of a region. For example, if you create a region for Battery Level ranging from 0 to 10, and set Selection to outside, then this region is satisfied whenever the robot's Battery Level is not between 0 and 10 inclusive. Selection is set to inside by default.

Bounded, Repeat, and Delay

Suppose we attach goTo({'Position X': 60, 'Position Y':60}) to the global region. In doing so, we want the goTo function to be executed whenever the global region's constraints are satisfied. Now suppose the goTo function has completed. At this point, the global region's constraints are still satisfied (in fact they are always satisfied because zero-dimensional regions have no constraints). Since the global region is still satisfied, will the goTo statement be executed again? The answer is no. This subsection will explain in detail the life cycle of regions during execution, which will allow you to understand why this is so.

We will begin by understanding the notions of entry and exit. We say that a robot is inside a region whenever all of the constraints represented by the region are satisfied. We say that a robot is outside a region whenever the constraints represented by the region are not all satisfied. A robot enters a region if the robot was previously outside the region but is now in the region. A robot exits a region if the robot was previously inside a region but is now outside the region. There are some non-obvious situations that are considered entry and exit.

Before the a GSSP program starts up, the robot is not inside any region. So, when the GSSP program starts, the robot immediately enters all regions that the robot is initially in. This includes all zero-dimensional regions.

Consider the case where the sensor for detecting the value of a state-variable fails, and GSSP no longer knows the value of this state-variable. When this happens, if the robot is inside a region that has a constraint on this state-variable, then the robot will exit the region. After the sensor is working agin and the value of the state-variable is once again available to GSSP, the robot will enter any that have a constraint on this state-variable, given that all other constraints of the region are satisfied.

Execution of the code attached to a region begins when the robot enters that region. The Repeat option dictates how many times the code should be executed, and the Delay option dictates how long to wait between each execution. Repeat defaults to 1 and Delay defaults to 0. Note that Repeat can be set to inf to indicate infinite repetition. At the beginning of each repetition, GSSP checks to see if the robot is still inside the region to which the code is attached. If yes, GSSP will proceed to execute all the code attached to the region. If not, the execution of the current repetition will be postponed until the robot enters the region again. Any goTo functions that have been started by the region will also be paused. When the robot enters the region again, the current repetition of the code will commence, and goTo functions will resume operation.

If all repetitions of the code been completed, and the robot is still inside the corresponding region, the code will no longer be executed. If the robot exits the region, and then enters it again, however, the code will start executing again from the first repetition.

Everything we have discussed so far apply when Bounded is set to yes. If Bounded is set to no, then in the case where the robot exits a region, GSSP will act as if the robot did not exit it. So, repetition of code execution will continue even if the the robot exits the corresponding region. This implies that it becomes impossible to re-enter a region that is not bounded.