Pioneer 2TM - Manual (Page 48)

ActivMedia Robotics Operating System
sonar array number one; numbers nine through 16 get added to the sequence for sonar
array number two; 17-24 specify the sequence for array three; and 25-32 are for array
four. You may include up to 16 sonar numbers in the sequence for any single array. Only
those arrays whose sonar numbers appear in the argument get re-sequenced. You may
repeat a sonar number two or more times in a sequence. If a sonar number does not
appear in an otherwise altered sequence, the disc will not fire.
Note that for compatibility with earlier ActivMedia robot operating systems, if the string is
empty, all the sonar get disabled, but their polling sequences remain unaltered, just as if
you had sent the SONAR command with an argument value of zero.
In earlier versions of AROS and P2OS, the sonar polling rate is fixed: one sonar per array
gets polled every 40 milliseconds. That common cycle timing accommodates ranging
out to the maximum of the sonar of several meters for general applications, including
features recognition and localization. For other applications, such as close-in obstacle
avoidance, a shorter range but faster rate of update is better.
Hence, we introduce in AROS v1.8 the SonarCycle FLASH parameter which lets you set,
through AROScf, the default sonar cycle time, in milliseconds. Use the SONAR_CYCLE
client command #48 to change the cycle timing on the fly to the command integer's
argument value in milliseconds.
STALLS AND EMERGENCIES
With a robot equipped with forward and/or rear bumpers, by default AROS immediately
stops the robot and notifies the client of a stall if any one or more of the contact sensors
get triggered and the robot is going in the direction of the bump (forward/front or
backward/rear). Send the BUMPSTALL command #44 with an integer argument of zero
to disable that bump-stall behavior. Give the argument value of one to re-enable
BUMPSTALL only when a forward bump sensor gets triggered; two for rear-only
BUMPSTALLs; or three for both rear and forward bump contact-activated stalls.
Change AROS’ bump-stall behavior default with the BumpStall FLASH parameter.
Table 7. The FLAGS bits in the standard SIP
BIT CONDITION IF SET
0 Motors enabled
1 Sonar array #1 enabled
2 Sonar array #2 enabled
3 Sonar array #3 enabled
4 Sonar array #4 enabled
5 STOP button pressed
6 E_stall engaged
7 Far ledge detected (IR)
8 Near ledge detected (IR)
9 Joystick button 1 pressed
10 Recharging “power-good”
11-15 Reserved
In an emergency, your client may want the robot to stop quickly, not subject to normal
deceleration. In that case, send the
E_STOP command (#55).
Like BUMPSTALL, use AROS’ built-in E_STALL
feature to simulate a stall when someone
presses the robot’s STOP button.
21 An
integrated switch in the STOP button
toggles a dedicated digital I/O port (Port
A, bit 3) on the microcontroller thereby
notifying AROS of the condition. AROS
stops the robot’s motors, puts on the
brakes, and throws continuous stalls.
Unlike other stalls, E_STALL also disables the
motors. You must either re-enable the
motors manually (MOTORS button) or
programmatically (ENABLE com-mand #4).
The E_STALL server notifies your client software through the stall bytes and in bit 5 of
the FLAGS byte in the standard so that your client may respond to a STOP E_STALL
differently than a regular stall.
42
21 Available only on some robots.