Pioneer 3TM User Manual

 

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. 

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.   

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.