Pioneer 2 Operating System
ActivMedia Robotics Operating System
Chapter 6
All
Activ
Media robots use a client-server
mobile robot-control architecture originally
developed by Dr. Kurt Konolige of SRI
International and Stanford University. In the
model, the robot’s microcontroller 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 Saphira, ARIA, or Basic Suite
Navigator.
Figure 14. 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
Activ
Media robot via
the
Activ
Media 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
Activ
Media robot users can be assured that AROS is upwardly compatible
with all
Activ
Media 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
Activ
Media 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 253 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 of the header bytes.
32