The application protocol is almost never sent directly to the robot from the base sta- tion. Even if the message is sent by wire, it will be coded in a format such as RS-232.
In reality it will travel over radio modems, telephone modems, the internet, or other means, and each of these will have its own protocol.
Some layers have to do with the way data is modulated onto carriers, while other la- yers are concerned with traffic handling, blocking, routing, and other matters. When the various protocols are part of a single master architecture (such as the factory MAP architecture), then these various protocols are usually called layers.
Most of these protocols are invisible to the user, but it is important to realize that the data stream may be broken into blocks for transmission. In fact, if you use a dial-up modem, it may use one of a variety of encoding protocols depending on line condi- tions. The timing of the application protocol decoders must be tolerant of this fact if the application protocol is to take advantage of all of the wondrous means of com- munications available today.
The last link from the base station to the robot will almost always be wireless. This can be infrared, FSK radio, or spread spectrum. The advent of inexpensive 802.11 Ethernet radios has opened up many possibilities for communications with mobile robots. The Ethernet protocol allows multiple data protocols to be exchanged with the robot at the same time but for different purposes.
For example, the robot’s application protocol may be riding on an Ethernet link in a TCP format, while compressed audio and video are transmitted in parallel using their own streaming media formats as shown in Figure 6.5. In this case, all of the computers on the robot serve as slaves on the supervisor link, which is mastered by the host computer.
A second link is used for internal control of the robot in autonomous operations.
This control link is hosted by the mobile base, and all other onboard computers are slaves. The control link does not extend outside of the robot. Both links use a superset of the protocol described in Figures 6.3 and 6.4. In this configuration, the host computer can communicate directly with the onboard slave computers for diagnostics and fine tuning.
Notice that the only physical communications channel from the host computer is an Ethernet link to multiple 802.11 radio Ethernet access points. Riding on the Ethernet protocol are multiple TCP connections for the video and data. At the vehicle, the port server changes the TCP stream by converting the data into a simple RS-232 stream.
Slave 2 (Sonar)
Slave 3 (Lidar)
Master Mobile Base
Xducers
Laser Ranger 802.11
Ethernet Radio
Slave 1 Mobile Base
Video Server
RS-232 RS-232
Port Server
Camera Ethernet
802.11 Ethernet Access Point
802.11 Ethernet Access Point
Host Computer
Ethernet
Mobile Robot
Control
Supervisor
Figure 6.5. Simplified communications diagram of SR-3 Security Robot
(Courtesy of Cybermotion, Inc.)
Figure 6.6 shows perhaps the most popular current communications configuration for robotics research. In this case, an onboard laptop computer serves as the main control for the robot, and only it communicates with sensor systems (usually by RS- 232). This configuration has the advantage that the main onboard computer has a built-in screen and keyboard facilitating local diagnostics, as well as video capture. It has the disadvantage that the host cannot communicate with the sensor systems directly. It can also be a bit costly in production.
The direction that all of this is taking is toward systems like the elegantly simple struc- ture shown in Figure 6.7. In this case, all of the sensor systems as well as the main computer use Ethernet communications. This configuration has the advantage that the base can communicate directly with the sensors. This assumes, however, that all the sensor systems are available with Ethernet interfaces. At present, this is not the case.
Another advantage in having the main onboard processor Ethernet equipped is that it can now communicate directly with other robots, door and gate controls, and ele- vator interfaces. There are some complications that occur as a result of all these intercommunications; for example, each robot must now behave politely in the connections it makes to shared resources. If this is not done, then these resources could become locked and unavailable to other clients and robots.
Figure 6.6. Communications structure using a laptop computer onboard
Slave 2 (Sonar)
Slave 3 (Lidar)
Xducers
Laser Ranger 802.11
Ethernet Radio
Lap Top Master Computer
RS-232 RS-232
Camera Ethernet
802.11 Ethernet Access Point
802.11 Ethernet Access Point
Host Computer
Ethernet
Mobile Robot
If one does not immediately appreciate the elegant simplicity that wireless Ethernet systems have brought to mobile robots, it is instructive to see how things were done only a few years ago. Figure 6.8 is the equivalent system as implemented for the SR-2 system fielded by Cybermotion before 1998. Since only low-speed radio modems were available, video had to be sent over separate channels. As robots moved through facilities, they would exceed the range of both systems.
Radio repeaters would relay the data channel to the robot, but at the expense of bandwidth. Video, however, could not be handled by repeaters and each receiver was connected to a switch. As the robot moved from location to location, the host computer would send commands to the switch to select the nearest video receiver.
Actually, things were even messier than this when two-way voice communications were required. In these situations, yet another transceiver was added to the robot.
Slave 2 (Sonar)
Slave 3 (Lidar)
Xducers
Laser Ranger 802.11
Ethernet Radio
Lap Top
Master Computer Camera
Ethernet
802.11 Ethernet Access Point
802.11 Ethernet Access Point
Host Computer
Ethernet
Mobile Robot
Figure 6.7. Communications structure based entirely on Ethernet