Pioneer 2 - Manual (Page 38)

Pioneer 2 Operating System
32
P2OS responds to each client command, forming a succession of identical synchronization packets. The
client should listen for the returned packets and only issue the next synchronization packet after it has
received the echo.
Autoconfiguration
P2OS automatically sends configuration information back to the client in the last sync packet ( SYNC2 ).
After the SYNC byte, there are three NULL -terminated strings that comprise the robot’s name, class, and
subclass. You may uniquely name your Pioneer 2 with a special configuration tool we provide with the
robot. The class and subclass also are parameters stored in the robot's flash PROM, but are constants not
changed by the user. (See Chapter 7, Updating and Reconfiguring P2OS for details.)
The Pioneer class string is simply Pioneer ; the subclass depends on your robot model; P2DX or P2AT,
for example. Clients may use these identifying parameters to self-configure their own operating parameters.
The Saphira client software, for instance, loads a special, related Pioneer parameters file found in the
Saphira
params directory.
Opening the Servers—
OPEN
Once a communication link is established, the client should then send the OPEN command, which causes
the Pioneer to perform a few housekeeping functions, start its sonar and motor controllers (among other
things), listen for client commands, and begin transmitting server information.
Note that once connected, Pioneer 2's motors are disabled, regardless of their state when last connected. To
enable the motors after starting a connection, you must either enable the motors manually (white MOTORS
button) or send an ENABLE command with the integer argument 1.
Keeping the Beat— PULSE
A P2OS safety watchdog expects the Pioneer server to receive at least one communication packet from the
client every few seconds. Otherwise, it assumes the client/server connection is broken and shuts down the
robot’s motors.
It’s good practice to send a PULSE to Pioneer just after opening the servers. And if your client application
will be otherwise distracted for some time, periodically issue the PULSE client command to let the server
know you are indeed alive and well. If the robot shuts down due to lack of communications traffic, it will
revive upon receipt of a client command and automatically accelerate to the last-specified speed at the
current heading.
Closing the Connection—
CLOSE
To close a connection, disable the motors and sonar, and reset P2OS to the wait state, simply issue the
client
CLOSE command.
Movement Commands
The P2OS server accepts several different motion commands (Table 6-6) of two mutually exclusive types:
either direct wheel-velocity control or P2OS motor controls. The robot server automatically abandons any
P2OS translational or rotational setpoints and switches to direct wheel-velocity control mode when it
receives a SETVEL2 command. Any other motion command makes P2OS abandon direct wheel-velocity
control. For example, if the P2OS is in two-wheel velocity mode and is given a
HEAD command, it disables
two-wheel velocity mode and starts controlling the heading and velocity of the robot.
When in P2OS motion control (recommended), translation and rotation operate independently. P2OS will
try to make the robot achieve the desired velocity and heading as soon as the commands are received, using
its internal acceleration and deceleration managers, which default values you may set (see Chapter 7,
Updating and ReconfiguringP2OS) and change on the fly (SETRA and SETA).