Arm not retracting during homing

[byrnete]

Hi, I need some help regarding my Stretch RE1’s arm. Recently had to repair a belt clamp within the arm housing, and that all worked well, however now the arm is acting up. During the repair, a screwdriver fell onto the circuit board atop the arm motor, and damaged one of the components - the reset button. However, we have two Stretch RE1’s and the other one is currently unused, so for now, we switched the boards around so that this one is in better condition.

For context, the reason we had to do this blindly is that we’re under a tight deadline that comes up this week (9/22-9/28), so waiting for new parts or the long process of diagnosing was decided against.

Anyway, I went through the process to get this Stretch RE1 to recognize the motor again, since it didn’t recognize the board’s ID. Now I’m facing an odd issue.
Whenever I try and home the arm, it will retract slightly, then extend a couple inches. It’s supposed to retract fully and then extend, but it believes it hit’s a hardstop or something.
I tried going through the effort values, to see if it just believed there was a virtual stop. When I recalibrated the effort values, the arm freaked out and performed the retract/extend loop extremely fast, and ended up with effort values of -90 and 90.
When I use the keyboard teleop, it stutters going in (Since it hits that virtual hardstop from the effort values), but it DOES retract fully.

While I’m on the subject of recalibrating the motor, does anyone know how to speed up the Stretch’s base? Right now it is agonizingly slow, and I recognize that it’s like that for a reason, however for my project it is a requirement to hit a minimum speed (roughly twice the base speed).

Here are the arm’s effort values diagnostic graphs. These are from the command
stretch_diagnostic_check.py --arm.

Here are the graphs from when I ran REx_calibrate_guarded_contact.py --arm

[bshah]

Hey, the microcontroller in each PCB stores a “encoder table” in its flash memory. This table is used to convert encoder reading into motor positions, and is unique to each motor. You’d never need to touch the table since the motors are pre-calibrated, but swapping PCBs between robots will definitely require the encoder table to be corrected.

On the other robot that now has the damaged PCB, run REx_stepper_calibration_flash_to_YAML.py hello-motor-arm to download the table into a YAML file. Copy the file over to your main robot. There, use REx_stepper_calibration_YAML_to_flash.py hello-motor-arm. Afterwards, the arm should smoothly track position goals, and know its end-stops.

For the mobile base speed, I’d confirm that you’re getting the max 0.3m/s of an RE1 by sending velocity goals using the Python API directly (robot.base.set_velocity(0.3, 0.0)).

Lastly, you can reach out to our support email, and we can get your team set up with a replacement PCB for the other robot.