Robotics Programming

When programming is first taught, the concept that a program follows the “input—
processing—output” model is used (Fig. 13-4) in which data inputs to the program are
passed to a processing block and then passed out of the program in the form of outputs.

This model is good for initial programs on a PC in which some number crunching is done to help you learn how the different programming statements work, but they have little relevance when programming robots.

Instead, a programming model like the one shown in Fig. 13-5 should be used. In this
model, the program is continually looping (never ending) and reading (or polling) inputs, passing them to a block of code for processing into outputs and then delaying some amount of time before repeating.

The delay block is critical for robot programming as it allows the code to be tuned for the operation of the robot and its parts. If the delay is too short, the robot may vibrate more than move because one set of commands from some input conditions are countermanded by the next set of input conditions, resulting in the original input conditions are true again . . .



Specifying the appropriate amount of delay is something that will have to be found by
trial and error. The total loop time should be less than 1 s, but as to the “best” time, that is something that you will have to find by experimenting with your robot. As a rule of thumb, try to keep the total loop time at least 100 ms (0.1 s) so that the motors have time to start up and initiate action before stopping and a new set of inputs polled.

You may also want to leave the motors running during the delay based on the assumption that chances are the processed output will not change radically from loop to loop. This will help make your robot move more smoothly, which is always desirable.


Graphical Programming

In this chapter, there is a lot of material on text-based programming that probably seems very difficult and complex, especially when you consider that there are many graphical robot programming environments available that could reduce a reasonably complex function like programming a light-seeking robot into the simple chore of drawing a picture like the one in Fig. 13-6.

This program will cause a robot to move toward the brightest point in the room. This is a lot easier to understand than the text-based version, which would look something like

while (1) ................. Loop Forever
If (Left > Right) ............Turn Left
Right Motor = On
Left Motor = Off
else
if (Left < Right) ....................Turn Right
Right Motor = Off
Left Motor = On
else ........................... Left = Right, Go Straight
Right Motor = On
Left Motor = On
endif
endif
Dlay(100) .............Delay 100 ms
endwhile

which would probably take you a lot longer to program than moving some blocks and lines around in a graphic editor. While being more difficult to understand and longer to develop, the text-based program gives you a great deal of flexibility that you don’t have with most graphical programming environments. Both programs perform the same operations and work the same way, but what happens if you discover that rather than turning as soon as the left and right light sensors are different values, the robot could run straight while they were within two values of
each other.

In the graphical programming environment, this would be impossible, but in the text-based program the two if statements could be changed to

if (Left > (Right + 2)

if ((Left + 2) < Right)

which would cause the robot to move forward if Left and Right were +/−2 of each other
rather than turning if they weren’t exactly equal. There are a lot of other cases where you will find that you need to tweak the program to run optimally, but you find that it is impossible to modify the graphic program for these needs.



Another advantage of text-based programming over graphic programming is the ability to add more complex logic to the operation of the robot. For example, if you wanted the robot to turn right if it has turned left five times in a row you can add the code quite easily to the text program whereas the graphic program does not have that capability (and indeed, very few graphical programming environments even have variables).

It is important to not generalize. While most beginner and hobbyist graphical programming environments and languages do have the limitations listed here, more professional ones do not. For example, National Instruments’ LabView programming environment offers the same capabilities and flexibility as a text programming language despite being based on just graphic symbols for operators, variables, and decision structures.

Hopefully you realize that these capabilities do not come free; creating a complex graphic program will require at least the same amount of study and practice as developing a text-based one.