The communication module provides message and data passing capabilities
both robot 
host and host interprocess communication (IPC).
Several issues had to be considered in the design to meet various
competing requirements.
The first problem, is that the robot--host bandwidth is a scarce resource, much in demand. If every time a host process requires robot state information a request is sent to the robot, the system would quickly bog down. To eleviate this, we had to design a system that would limit robot queries and reuse the results as much as possible.
Another difficulty was the number of host processes. There are many processes, which often require to communicate with several others. If each process had to create a separate connection to all other processes, the number of links would increase quadratically and communication management would quickly become unwieldy. Also, to minimize the impact of future changes in hardware and software architecture, we want to minimize the direct knowledge of system configuration required by each process.
The solution was to use a central data blackboard process we dubbed the ``mailer''. This process provides IPC through the mechanism of Unix message queues. This provides each process its only avenue to data and state information. Any process can request data by sending a request to the mailer via the mailer's message queue. It then performs a hanging read on its message queue until the requested data is available. Request take 3 forms:
This design has many advantages. One is that it is host CPU friendly. Each time a process is complete, rather than polling communications or repeating operations on already processed data, it will suspend until new data arrives. This conserves system resources. The system provides message passing that can work both as events in an event-driven system, or as a synchronization method between essentially asynchronous processes.
It also means it is easy to test and debug software, even if the robot is not available. It is easy to simulate robot state messages, and the mailer can run on any workstation. It also has the advantage that modules have no other point of contact that the mailer, and thus require no knowledge of system configuration, other than the address of the mailer message queue. New processes can be added at anytime and will automatically have access to information available.
For example, when a user requests the robot to move to a new location by clicking on the displayed map, the user interface produces a ``goal update''. This unblocks the path planner which has posted a request for the ``next goal''. The path planner makes the path, and posts a ``path update''. The path executor is in turn waiting for the ``next path''. It receives the new path and issues robot commands appropriately, again through the mailer.