The most obvious (and common) solution to a protocol is to think of all of the things you will want to tell a robot and all of the things you will want it to tell you, and then simply to define a number of dedicated messages for exchanging this data.
Let’s consider the case of a simple remote controlled robot with differential drive.
Differential drive features one powered wheel on each side of the robot. When both
40 C0 80 <CR>
80h - Negative checksum C0h - Right motor speed 40h - Left motor speed
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.
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
fielded robots with the first protocol, however, our new version of the base station control will not be compatible with our old robots, even if the old robots have no camera controls.
D 40 C0 80 <CR>
80h - Negative checksum C0h - Right motor speed 40h - Left motor speed
D - Message Type (D=Drive, P=Pan)
Figure 6.2. Rigid protocol with message identifier
If we decide to keep the old message formats as we add new ones, things will eventu- ally become very confusing. Worse, the receiving decoder will need to test incoming messages for all of these formats. This will make the decoding process absorb more system resources, and the possibilities for bugs abound. After years of patching such protocols, we will have created a nightmare. Worse yet, whenever we decide to read or set any parameter we had not previously included, we must replace the messaging program(s) at both ends of the communications link before the new data can be accessed.
The problem is that we cannot predict all of the messages we will eventually need for any but the simplest systems. To believe that it is possible to think of all the things you will want to communicate is a dangerous conceit. Within hours of estab- lishing a link to the robot, you will find you need a bit more data, or you will realize that you need to influence the robot in an additional way. The protocol needs to be flexible enough to support the unexpected.
Flashback…
I am reminded of a very painful example. We were working on a project to adapt our commercial security robot for use in a military rack warehouse environment. A rack ware- house is one based on row after row of rack shelving. The problem was that the robot had been designed to operate in office environments. In its native habitat, it used sonar to look for walls and other flat surfaces from which it could correct its dead reckoning.
We were given access to a rack warehouse site where we could do testing. While racks could be at any height, there were always support posts on regular intervals, and we decided to base our approach on these. In the course of early development, we had used our limited funding to add some simple navigation tricks. These tricks used retro-reflec- tive infrared sensors to detect strips of reflective tape mounted to the posts of the racks.
A week or so before a critical milestone test; we were informed that there had been a small administrative change. We would not be installing at the rack warehouse at all, but rather at a pallet warehouse full of crates. To us, the change was a bit like telling General Eisenhower on June 1st that the invasion of Europe was to be a land invasion through Russia instead of an amphibious assault at Normandy. What? Is there a problem?
As luck would have it, we had recently added control variables to the wall imaging algo- rithms that allowed us to navigate from the not-so-straight walls of office cubicles. Our flexible communications protocol and programming language allowed us, on site, to manipulate these variables and view the results. Thus, we were able to adapt the cubicle navigation variables to allow sonar navigation from crates.
This solution was not entirely kosher, since we had to move a significant number of crates to assure that they were roughly along the edges of the aisles. Even so, with a combination of flexible communication and control, ingenuity, and our newly acquired forklift driving skills we saved the day—or so we thought.
Although there were still several years of development time available before scheduled system deployment, several additional “administrative” changes would occur. Despite our warnings about the desperate need, funding for long-range navigation research was omitted from the next budget on the justification that the milestone test had demon- strated that the system needed no further navigational enhancement! Other participants, it seemed, needed the resources.
Our luck held out a bit longer, when in the nick of time we were able to fund the needed long range laser navigation from unrelated commercial contracts. Unfortunately, a final administrative change came when the RFP (Request for Proposals) was issued for the production of the system. The specification mandated that the communications proto- col be changed from our flexible “proprietary” protocol to a rigid protocol that would be used by all future robots fielded by the program, both indoor and outdoor4. Through this and other key decisions, the program management snatched defeat from the very jaws of victory!
Rigid protocols are fairly common in peripheral systems such as printers, laser rang- ers, and other measurement systems. In fairness, a rigid protocol is often the appro- priate choice in such systems. But even in these limited systems one often sees the beginnings of real problems for a rigid protocol.
4 In this the program has thus far succeeded in that no robots of either type have yet been fielded.
The contract to modify our robots was given to a giant defense contractor, and after several costly overruns, the warehouse robot program was placed in mothballs and the manager was given a
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.