Pioneer 2TM - Manual (Page 65)

ActivMedia Robotics
Ticksmm and revcount affect only the conversion of your motion command arguments
into platform-dependent values. Your client must independently convert values
reported back from the server, such as X-Pos and Th, into platform-independent values.
ARIA clients use the conversion factors found in your robot’s respective ARIA\params file
(p3dx.p, for example).
To adjust both the server and client parameter values for your robot, first connect the
robot with a client and have the robot move a certain distance, preferably one to three
or more meters. Measure the actual distance moved, not the client-reported value and
adjust ticksmm accordingly.
Similarly, rotate your robot from the client and measure the actual achieved heading.
Adjust revcount (the measure of differential encoder ticks to achieve 360-degrees
rotation) accordingly.
When you are satisfied that the robot moves and rotates the proper distances and
headings, adjust the related client-side parameters in your robot’s params .p file, so that
your client responds accurately.
S TALL V AL AND S TALL C OUNT
An AROS stall monitor maintains a running average of PWM values for each wheel over a
500 millisecond integration period. PWM values get added to the sum if the wheel speed
is below 100 mm/sec. The average is then compared with the stallval FLASH value. If
it exceeds that value, in other words the motors are being given lots of power but are
barely moving if at all, a stall occurs. Once stalled, power is removed and the motors
relax for the stallwait period, after which power gets reapplied.
B
UMPERS
Introduced in AROS version 1.6, use the BumpStall FLASH parameter to set the default
for the robots behavior when its front and/or rear bumper gets triggered. Normally,
BumpStall is engaged for both front and rear (default value of 0) bumpers. Reset it to 3
to disengage bump stalls altogether; 1 to trigger stalls only when the rear bumpers
engage; or 2 for front bumps only.
You may over-ride the BumpStall FLASH default with the bump_stall client command
number 44, although the command arguments are the reverse: enabling versus disabling
the various bumper-stall combinations.
Your robot’s BumpStall behavior reverts to the FLASH default on reset and up
disconnection from the client.
Next-generation client-side software will need to know if you have bumpers or not and
how they are configured. And new bumper hardware inverts the Pioneer 2’s bumper
signal bits which confuses the client-server software. Moreover, different AROS-enabled
robots have different numbers of bumper segments, front and rear. Accordingly, the
new AROS v1.6 implements three new FLASH parameters that specify states (invert or not)
and numbers of front and rear bumper segments. Unfortunately, we have no way of
knowing automatically what bumpers your robot may have, if any, so we are forced to
assume you DON'T have bumpers or that you have the old-style (non-inverting) bumpers.
Use AROScf to indicate the type and number of bumper segments. Set the new
InvertBump FLASH parameter's value to 1 if you have new bumpers in front, which
signals need to be inverted; 2 if in the rear; or 3 if both front and rear bumper signals
need inverting. Set to the default 0 if your robot has no bumpers or has the original style
(non-inverting) bumpers.
59