M
OBILE
R
OBOTS
AmigoSH
Figure 16. ActivMedia Robotics’
client-server control architecture
Chapter 5
All M
OBILE
R
OBOTS
platforms use a client-server
mobile robot-control architecture. 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 and reporting sonar and wheel
encoder data, and so on
all on command
from and reporting to a separate client
application, such as the ARIA demo.
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
AmigoBot via its
AmigoBot-SH Operations Software (AmigoSH)
client-server interface. The same AmigoSH
functions and commands are supported in
the various client-programming environments
that accompany your robot or are available
for separate license.
Experienced M
OBILE
R
OBOTS
platform users can be assured that AmigoSH is upwardly
compatible with all
Activ
Media robots, implementing the same commands and
information packets that first appeared in the Pioneer 1-based PSOS, in the original
Pioneer 2-based P2OS, and more recent AROS and ARCOS-based Pioneer 2s and 3s, as
well as Performance PeopleBot, PatrolBot, and PowerBot. AmigoSH, 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
M
OBILE
R
OBOTS
platforms communicate with a client using special client-server
communication packet protocols, one for command packets from the client to the
server and another for Server Information Packets (SIPs) from the server to the 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 207 bytes each.
The two-byte header which signals the start of a packet is the same for both client-
command packets and SIPs: 0xFA (250) followed by 0xFB (251). The subsequent count
byte is 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
21
