Table 7. The FLAGS bits in the standard SIP

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.

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).

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

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.

21Available only on some robots.

42

Page 48
Image 48
Pioneer 3TM, 2TM manual Stalls and Emergencies, Reserved