Activmedia robotics operating system, Client-server communication packet protocols, Chapter 6 activmedia robotics operating system – Pioneer 2TM User Manual

Page 37: Lient, Erver, Ommunication, Acket, Rotocols

Advertising
background image

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

Advertising
This manual is related to the following products:

3TM