Pioneer 2TM, 3TM manual Stallval and Stallcount, Bumpers

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

STALLVAL AND STALLCOUNT

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.

BUMPERS

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