Page 99 - Designing Autonomous Mobile Robots : Inside the Mindo f an Intellegent Machine
P. 99
Chapter 6
wheels turn at the same speed, the robot moves forward. Steering is accomplished by
moving one wheel faster than the other, or driving the wheels in opposite directions.
We decide that all we need is to send this robot a command for the two motor speeds.
40 C0 80 <CR>
80h - Negative checksum
C0h - Right motor speed
40h - Left motor speed
Figure 6.1. A simple, rigid protocol for a differential drive robot
The protocol in Figure 6.1 is about as simple as a protocol can get. Notice that two
ASCII characters describe a hexadecimal 8-bit byte, and that we are using 2’s
complement for representation of the data. Thus, the above command says that the
robot should run its left motor at half speed forward (positive) , and run its right
motor at half speed in reverse (negative). In otherwords, we want the robot to turn
in place. The two data bytes are subtracted from zero and the low byte of the result is
sent as the checksum.
One of the important aspects of a protocol is framing. Framing is the means by which
the receiver/decoder determines where a new message begins. Sending each byte as
two ASCII characters is wasteful of bandwidth, but it allows us to be sure that the
data will never cause the transmission of a byte having the value 0Dh. If this occurred,
the data could be confused at the receiver with the terminating <CR> character.
This could cause a framing error, and possibly even cause mistranslation of the data.
Let’s assume we are happy with this protocol and begin shipping machines. What
happens when we add a camera to the robot and want to be able to pan and tilt it?
There is nothing in the above protocol that says what the message is about—we
have just assumed since there was only one type of message the robot would know.
But if we wish to add a pan and tilt message, the robot must be able to tell which
commands are for which purpose.
We can combine the two messages into a single eleven character message or keep
the messages separate and add a message type identifier to each. We realize that
making our one message longer and longer will eventually lead to problems, so we
decide on the second alternative as shown in Figure 6.2. Since we have already
82

