ActivMedia Robotics
Chapter 6 ActivMedia Robotics Operating System
All ActivMedia robots use a client-server mobile robot-control architecture originally developed at SRI International, Inc. and Stanford University. In the model, the robot’s controller servers work to manage all the low- level details of the mobile robot’s systems. These include operating the motors, firing the sonar, collecting sonar and wheel encoder data, and so onall on command from and reporting to a separate client application, such as ARIA.
With this client/server architecture, robotics applications developers do not need to know many details about a particular robot server, because the client insulates them from this lowest level of control. Some of you, however, may want to write your own robotics control and reactive planning programs, or just would like to have a closer programming relationship with your robot. This chapter explains how to communicate with and control your ActivMedia robot via the ActivMedia Robotics Operating System (AROS) client-server interface. The same AROS functions and commands are supported in the various client-programming environments that accompany your robot or are available for separate license.
Figure 16. ActivMedia Robotics client-server control architecture
Experienced ActivMedia robot users can be assured that AROS is upwardly compatible with all ActivMedia robots, implementing the same commands and information packets that first appeared in the Pioneer 1-based PSOS and in the original Pioneer 2-based P2OS. AROS, of course, extends the servers to add new functionality, improve performance, and provide additional information about the robot's state and sensing.
CLIENT-SERVER COMMUNICATION PACKET PROTOCOLS
ActivMedia robots communicate with a control client using special client-server communication packet protocols, one for command packets from client to server and another for server information packets (SIPs) from the server to client. Both protocols are bit streams consisting of five main elements: a two-byte header, a one-byte count of the number of subsequent packet bytes, the client command or SIP packet type, command data types and argument values or SIP data bytes, and, finally, a two-byte checksum. Packets are limited to a maximum of 206 bytes each.
The two byte header which signals the start of a packet is the same for both client- command packets and SIPs: 0xFA, 0xFB. The byte count value counts the number of all subsequent bytes in the packet including the checksum, but not including the byte count value itself or the header bytes.
Data types are simple and depend on the element (see descriptions below): client commands, SIP types, and so on, are single 8-bit bytes, for example. Command arguments and SIP values may be 2-byte integers, ordered as least-significant byte
