53
The
TicksMM
value is the number of encoder pulses (“ticks”) per millimeter of wheel rotation. The value is, of course,
dependent upon the wheel encoder’s resolution, the motor-to-wheel gear ratio and the wheel’s diameter.
The
RevCount
value is the differential number of encoder ticks for a 180-degree turn of the robot. It depends on a
number of factors, principally the length of the wheel base which may change due to payload, tire wear, operating
surface and so on.
The
DriftFactor
is a value in 1/8192 units that gets added or subtracted from the left-wheel encoder count at each
motor cycle. In doing so, it compensates for tire difference and thereby straightens the robot’s translation forward and
backward.
Table 20. Some platform-dependent parameters
VALUES
P
ARAMETER
P3DX
P3AT
P
ERF
PB
encoder ticks/rev
500
500
500
gear ratio
38.3
49.8
38.3
wheel diam (mm)
195
220
195
encoder ticks/mm
132
138
132
The ticksMM
and
revCount
parameters affect the conversion of your motion command arguments into platform-
dependent values used by ARCOS. Unlike previous firmware, ARCOS also uses
ticksMM
and
revCount
to convert its
internal measures into platform-independent position and velocity values that it sends to the client in the standard SIP,
such as
Xpos
and
Ypos
. Accordingly, you’ll notice that the respective ARIA client parameters have many conversion
factors like
DistConvFactor
set to 1.0.
S
TALL
V
AL AND
S
TALL
C
OUNT
An ARCOS 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
Use the
bumpStall
FLASH parameter to set the default for the robot’s 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-related 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
BUMPSTALL
client command #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.
ARCOS implements three FLASH parameters that specify states and numbers of front and rear bumper segments. Set
the
frontBumps
and
rearBumps
values to the number of bumper segments for the front and rear bumpers,
respectively; or to 0 if you don't have a particular bumper. The number of segments is used to isolate the bumper bits,
if any, so that a triggered bumper event is reported correctly in the
STALL
values of the standard SIP. Use the
invertBump
FLASH parameter to invert those bumper-related STALL values, but not the hardware-related states
reported in the
IOpac
.
The
frontBumps
and
rearBumps
byte values also are reported near the end of the
CONFIGpac
. If for any reason you
remove a bumper from your robot, you MUST reset the associated
frontBumps or rearBumps
FLASH value.
Otherwise, the robot will stall incessantly and ARIA won’t let you drive.