Pioneer 3™ Operations Manual

Advanced Robot Control & Operations Software
Chapter 6
ARCOS
All MOBILEROBOTS 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 robot via the
Advanced Robot Control and Operations
Software (ARCOS) client-server interface.
The same ARCOS functions and commands
are supported in the various clientprogramming
environments that
accompany your robot or are available for
separate license.
Figure 18. MOBILEROBOTS client-server
control architecture
Experienced MOBILEROBOTS users can be assured that ARCOS is upwardly compatible with
all MOBILEROBOTS platforms, 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-based Pioneer 2s and 3s, as well as PeopleBot and PowerBot.
ARCOS, 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
MOBILEROBOTS platforms communicate with a 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 207 bytes each.
The two-byte header which signals the start of a packet is the same for both clientcommand
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
30