Page 102 - Designing Autonomous Mobile Robots : Inside the Mindo f an Intellegent Machine

Communications and Control

As an example, I recently interfaced a cable printer to a system and found that there
were up to six different messages for performing each of the dozens of tasks. It was
clear that some of these messages were more recent additions with added functional-
ity, but the older messages were maintained for backward compatibility. For some
reason, some of the older messages did not appear to work properly. The protocol
was very inefficient and confusing, and it took an excessive effort to finally debug
the interface.

Flexible protocols

For all of the reasons expounded upon, a robot communications protocol must be
flexible. One way of making a protocol flexible is to allow it to access all public
variables. This is called a blackboard approach. If access is to be restricted to certain
areas, this can be accomplished in the encoder or decoder as opposed to making the
protocol itself restrictive. This comes under the rule “You can always saw a board
shorter, but you can’t saw it longer.”

Blackboards and exposing parameters with absolute addressing
In microcontroller applications, addressing is often absolute. Memory fields vary in
size from a few kilobytes to a few megabytes. Thus, a memory location will always
contain the same data and its address can be specified in a message to request or set
that data.
The overhead of the message format will usually be such that it is very inefficient to
request or set a single variable at a time. The simplest solution to this problem is to
group variables together if they are likely to be written or read together. For ex-
ample, the robot’s azimuth, X position, and Y position will usually be requested
together. If these variables are located contiguously, the protocol need only specify
the beginning address of the block and the number of bytes.

More than two decades ago we were faced with the same requirements just discussed.
We elected to use a protocol based on the Intel hex file format. This format described a
method of placing an image of data in a file in a way that it could be read and loaded
to absolute memory locations in a target system. This format was used most com-
monly for saving memory images to be used by a PROM (programmable read-only
memory) burner. Our “set data” message was identical to a line of such a file. We
used a spare data field to specify the destination computer, allowing the message to
address up to 256 different blackboards or computers. Figure 6.3 shows a “set data”

85