There are many ways to improve communications efficiency. In many cases, you will want to have more than one slave computer on a link, and there may be more than one link in your system (as in Figure 6.5).
Broadcasts
In some cases, a host computer will want to convey the same general information to more than one of the slaves. For example, the mobile base in Figure 6.5 may wish to broadcast the current position and heading estimate to all the sensor systems. In this way, slaves can process navigation information in ways not possible if they did not know the current position data.
The simplest way to perform a broadcast is to define a special message, and to have this message write into a special broadcast bulletin board in each of the slaves. This bulletin board can be a reserved block of memory, or an array of data. If communica- tions becomes particularly busy, broadcasts can be transmitted at longer intervals, as long as they are sent reasonably often (every second or so).
The biggest problem with broadcast data such as position is that it is always out of date, and by varying amounts of time. In the case of position data, this can mean that any calculation made by the slave will be wrong because of this latency.
There are two ways to minimize this latency. The first method is to provide the slave with a predictive modeling program that runs at an interrupt rate much faster than the update rate of the broadcast. This modeler simply updates the position estimate in the bulletin board on the assumption that the robot is still accelerating (in each axis) at the same rate it was when the broadcast was received. In this way, the bul- letin board values for the robot’s position are continually updated for any task that might need them.
The second method of reducing broadcast data latency requires fewer system re- sources. This method involves time-stamping incoming broadcasts against a local time source, and provides a method or subroutine that is called in order to retrieve a current estimate of broadcast data. When the method is called, the program simply estimates the probable change for each axis since the data was received. This is sim- ilar to the first method, but the data is only refreshed as actually needed.
Flags
Flags are nothing more than variables (usually booleans, bytes, or integers) that can take on a limited number of values, each of which has a specific assigned meaning.
Flags are a powerful tool in communications. Flags can be sent to slaves and they can be retrieved from slaves. One of the most common uses of such flags is to place them in a block of data that is regularly monitored by the host. The flag might tell the host that there is some other data, somewhere in the blackboard of the slave that it needs to look at. Flags can also request that the host perform emergency shutdown, or any number of other actions.
Two of the most common flags are the slave computer mode and status. By checking these integers or bytes, the host can tell if the slave is doing what it should be doing (mode), and if it is experiencing any problems doing it (status). Error numbers are another common example of flags.
To understand the power of flags, consider that the host computer might receive from a slave a simple byte representing one of 255 possible error codes. Although this code required only a single byte to be communicated, it may result in the operator receiv- ing a whole paragraph of explanation about the nature of the error. A word of warning about flags is prudent at this point. If more than one of the conditions that a flag represents can be true at the same time, a numeric flag can only represent one of these conditions at a time. In these cases, the bits of a byte or integer can each serve as a flag, allowing any combination to be set at the same time. The other so- lution is to use individual flags for each condition, but this is very wasteful of band- width as an entire integer must be read to test each condition.
Templates
Although we have already indicated that we will try to group data contiguously in a slave’s blackboard if we expect to request it at the same time, there will always be times when we want data from a range of different noncontiguous memory locations.
When this is the case, the overhead for requesting a few bytes here and there can be very high.
Thus we need a template. A template is a script that the host loads into the memory of the slave in reserved locations. The script contains a list of starting addresses and the block size for each of these. The last of these pointers is followed by a zero- length block that serves to terminate the template.
The template is then requested by the host and the slave assembles the scattered scraps of data into a single message block. The efficiency of this messaging system is incred- ible, and it is easily implemented.
Post offices
In complex systems such as mobile robots, communications patterns shift with the nature of the task at hand. Furthermore, communications channels are shared resources that many tasks (clients) may need to use. In the case of a base station program, communications may be dictated by the number and type of forms that the operator has open. It is therefore intolerably inefficient for a particular thread to wait in a loop for the channel to become available, and then for the data to arrive.
In an efficient architecture, a task will request data before it absolutely needs it, and while it can still do useful work before the data arrives. To do resource sharing on a case by case basis rapidly results in unreadable code. Thus, we come to the general concept of a resource manager.
A resource manager for a communication channel is usually called a post office. A post office is a module (or better yet an object) that contains an array of pointers to messages and their associated flags, and destination addresses. The elements of this array are called post office boxes. At a minimum, a post office will have the following methods available for the clients to use:
1. Post a request message 2. Post a send message
3. Provide status of a posted message
4. Provide status of the communications resource.
As a task needs to communicate with other systems, it calls the post office and posts its message. The post office puts the message in the next available box, and then re- turns a message identification code that the client can use to request the status of its message in the future.
The reason that the post office does not simply return the box number is that boxes are reused as time goes on. If a client does not pick up its message information before the post office reuses the box, then the data in that box may have nothing to do with the client’s request. In some schemes, the message identifier contains the box number in its lower bits to make it easy for the post office to locate the message when requested to do so by a client.
For a send message, a client provides the post office with a pointer to the message da- ta, the size of the message, the remote processor (e.g., slave) to which the data is to be sent, and the destination address in that processor. The post office places all of this information into the next empty box and returns the message identification number to the client.
For a request message, a client provides the remote processor and address from which it wants data, the number of bytes it wants. It may also pass a vector where it would like the post office to save the received data.
When a message has been posted, the client will normally go about its business until it reaches the point of needing to know the status of its message. To determine this, the client calls the post office, and requests the status of the message by providing the message identification number. The post office will typically return one of the following status codes:
1. Unsent (Post office has not yet gotten around to the message.) 2. Pending (Message was sent but reply has not been received.) 3. Completed
4. Failed
Another useful method for a post office to provide is the status of the communica- tions resource. This status usually indicates if the channel is connected, and the size of the backlog of messages it has to do. In this way, some clients can opt to slow down their requests of the channel when it becomes heavily loaded.
Advanced post offices sometimes support message priority. The priority of a message is usually limited to two or three levels, but can be greater. A higher priority message will get serviced sooner than a lower priority message.
Figure 6.9. Post office monitor and diagnostics display
(Courtesy of Cybermotion, Inc.)
Message priority is handled in a simple way. The post office simply maintains a set of post office boxes for each level of priority. When the channel becomes available, the next message will be from the highest set of boxes that has a message posted. Thus, if there are no messages in the level 3 boxes, the post office will check the level 2 boxes, and so forth.
Many of the field problems in robotics are communications related, so it is important to be able to quickly determine the nature of the problem. The post office diagnostic display in Figure 6.9 shows all of the elements just discussed for a simple single-level post office. The bar at the bottom shows the state of all 32 of the boxes reserved for this robot’s channel. The letter “d” indicates a message is done, while the letter “u”
indicates it is unsent, etc. Clicking the “RxMsgs” button will show the most recent messages received that were rejected. The “Details” button gives statistics about which messages failed.
Although the concept of a post office may seem overly complex at first glance, it is in fact a very simple piece of code to write. The benefits far outweigh the costs.