Interacting with the environment
Computer systems have to communicate with the world around them, getting information about the external world, and taking actions to change the world. The world is dynamic, so that as the machine is calculating, the world is modifying, needing future computation to take to the new part of the world.
There are a variety of different paths to manage computations that communicate with a outer world. Usually speaking, such a calculation requires to:
1. get details from sensors,
2. perform calculation, remembering some of the results, and
3. take appropriate actions to modify the outer world.
1.3.1.1 Sequential
The most immediately style for developing a program that communicates with the world is the basic imperative style, in which the program provides a sequence of 'instructions' to the computer it is controlling. A library of special procedures is described, some of which read details from the sensors and others of which cause reactions to be operated.
In this model, we should usually write a program that goes an idealized robot in a square, if there is area in front of it.
if noObstacleInFront:
moveDistance(1)
turnAngle(90)
moveDistance(1)
turnAngle(90)
moveDistance(1)
turnAngle(90)
moveDistance(1)
turnAngle(90)
The related problem with this model of programming is that the programme has to check the sensors sufficiently frequently. If the robot examine for free space in front, and then starts rolling, it can turn out that a subsequent sensor reading will give that there is something in front of the robot, either because someone gone in front of it or because the last reading was erroneous. It is rigid to have the discipline, as a programmer, to identify to check the sensor situations frequently enough, and the answering programs can be quite difficult to understand and read.
For the robot rolling toward the light, we can write a program like this:
while lightValue < desiredValue:
moveDistance(0.1)
This would have the robot creep up, one by one, toward the light. We may want to change it so that the robot goes to a distance that was correlated to the difference between the desired light values and current. However, if it takes bigger steps, then mean while the time that it is rolling it will not be sensitive to possible modification in the light number and may not react immediately to them.
1.3.1.2 Event-Driven
User-interface function are usually best managed differently, as event-driven programs. In that case, the program is defined as a collection of functions that are related to particular function that can give place. So, for example, there may kinds into a text area, or when the temperature of a reactor goes too high. An "event loop" executes continuously, examine to see whether any of the triggering function have occurred, and, if they have, calling the associated function.
1.3.1.3 Transducer
An alternative view is that programming a machine that communicates with an external world is like creating a transducer with internal state. Think of a transducer as a operating box that executes continuously. At normal intervals, the transducer takes all of the sensors, does a short amount of calculation, saves some numbers it will require for the next calculation, and then creates output values for the actions.
This calculations occur over and over again. Complex behaviour may rise out of the temporal functions of outputs and inputs.
def step():
distToFront = min(frontSonarReadings)
motorOutput(gain * (distToFront - desiredDistance), 0.0)
Executed normally, this program will automatically calculate the robot's velocity to be proportional to the free memory in front of it.
The basic problem with the transducer method is that it may be very difficult to do programs that are fundamentally sequential.