25
Because of the real-time nature of client-server mobile-robotics interactions, we made a conscious decision to provide
an unacknowledged communication packet interface. Retransmitting server information or command packets typically
serves no useful purpose because old data is useless in maintaining responsive robot behaviors.
Nonetheless, the client-server interface provides a simple means for dealing with ignored command packets: Most of
the client commands alter state variables in the server. By examining those values in respective SIPs, client software
may detect ignored commands and re-issue them until achieving the correct state.
T
HE
C
LIENT
-S
ERVER
C
ONNECTION
Before exerting any control, a client application must first establish a connection with the robot server via a serial link
through the robot microcontroller’s
HOST
serial port either via the internal
HOST
or the User Control Panel
SERIAL
connector. After establishing the communication link, the client then sends commands to and receives operating
information from the server.
When first started or reset, ARCOS is in a special wait state listening for communication packets to establish a client-
server connection.
7
To establish a connection, the client application must send a series of three synchronization
packets containing the
SYNC0
,
SYNC1
and
SYNC2
commands
in succession, and retrieve the server responses.
Specifically, and as examples of the client command protocol described below, the sequence of synchronization bytes
is:
SYNC0: 250, 251, 3, 0, 0, 0
SYNC1: 250, 251, 3, 1, 0, 1
SYNC2: 250, 251, 3, 2, 0, 2
When in wait mode, ARCOS echoes the packets verbatim back to the client. The client should listen for the returned
packets and only issue the next synchronization packet after it has received the appropriate echo.
Autoconfiguration (SYNC2)
ARCOS automatically sends robot identifying information back to the client following the last synchronization packet
(
SYNC2
). The configuration values are three NULL-terminated strings that comprise the robot’s FLASH-stored
name
,
type
, and
subtype
. You may uniquely
name
your robot with the FLASH configuration tool we provide. The
type
and
subtype
are constants set at the factory and normally not changed thereafter. (See next chapter for details.)
The
type
string typically is
Pioneer
. The
subtype
depends on your robot model; P3
DX-SH
or P3
AT-SH,
for example.
Clients may use these identifying strings to self-configure their own operating parameters. ARIA, for instance, loads and
uses the robot’s related parameter files found in the special
Aria/params
directory.
Opening the Servers—OPEN
Once you’ve established a connection with ARCOS, your client should send the
OPEN
command #1 (250, 251, 3, 1, 0,
1) to the server, which causes the microcontroller to perform a few housekeeping functions, start its various servers,
such as for the SONAR and motors, and begin transmitting server information to the client.
Note that when at first connected, your robot's motors are disabled regardless of their state when last connected. To
enable the motors after starting a connection, you must either do it manually (press the white
MOTORS
button on the
User Control Panel), from the LCD accessory’s interactive mode, or have your client send an
ENABLE
client command
#4 with an integer argument of 1. See
Client Commands
below.
Once connected, send the
ENABLE
command
or press the white
MOTORS
button on the User Control Panel
to enable your robot’s motors.
7
There also is maintenance mode for ARCOS downloads and parameter updates; see next chapter for details.
