Pioneer 2TM - Manual (Page 37)

ActivMedia Robotics
ActivMedia Robotics Operating System
Chapter 6
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 onall on command from and
reporting to a separate client application,
such as ARIA.
Figure 16. ActivMedia Robotics
client-server control architecture
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.
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.
C LIENT -S ERVER C OMMUNICATION P ACKET P ROTOCOLS
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
31