We recently purchased the hardware upgrade accessory to convert our Stretch-RE2 robot to the SE3 configuration. As part of the process, we sent our robot to Hello Robot for the upgrade and repair.
After receiving the robot back, we formatted and reinstalled the system from scratch. Initially, we encountered a persistent issue where the D405 camera was not recognized. After repeated troubleshooting, we discovered that the D405 cable was disconnected during return shipping. Once reconnected, the D405 camera functioned correctly.
However, we are now facing more critical issues:
After running the setup sequence (REx_firmware_updater.py --install, stretch_configure_tool.py, and finally stretch_robot_home.py), the arm connected to the robot’s central lift axis begins to drop downward as if under constant downward force.
The gripper is also completely unresponsive and shows no reaction to commands.
We are trying to determine the root cause and have a few suspicions:
Could this be related to URDF or configuration mismatches after the upgrade?
One critical issue is that we have not received the original data or configuration package associated with our specific stretch-re2-xxxx unit after the hardware upgrade. We have contacted Hello Robot to request this, but we have not yet received a response.
Could the missing configuration data for the upgraded stretch-re2-xxxx be the reason for these malfunctions?
We would greatly appreciate any guidance, suggestions, or advice from the community on how to resolve these issues. Thank you very much in advance for your support.
I have a feeling the above following issue might be related to the lift params not updating properly which is expected to be taken care by the stretch_configure_tool.py command.
Could you send us the output log as text file of the command stretch_configure_tool.py -v command in verbose mode. And also send the output log as a text file of the command stretch_params.py. This will help us identify if the lift params were updated properly or something else is wrong.
For the above following issue, could you send the output of the following commands.
I added this as it might help clarify device detection status.
Just to clarify, the issues with the D405 camera were resolved after reconnecting a loose cable. But now, after reinstalling the system and running the setup sequence, we’re experiencing the following:
The lift no longer holds its position after boot—it immediately drops, as if no torque is applied.
The gripper remains unresponsive to all commands.
These issues were not present before the reinstall. Based on the symptoms, it feels like none of the newly installed hardware components from the upgrade are being properly recognized or configured by the system.
@hyuk6745 Thankyou for attaching the outputs. Here some comments and debug suggestions looking the outputs you have provided.
It looks like none of the dynamixel servos from the end effector where found in the USB bus. This usually means either the UDEV rules for the WACC board is not set right or else the dynamixel cable that runs from the gripper into the WACC board is disconnected. And I believe this is the reason the the gripper seems to be unresponsive.
For this issue you can first check physically if the cable from gripper to WACC board is connected securely as per the installation guide.
And then run the command REx_discover_hello_devices.py --discover --dynamixels. This tool will scan through the USB bus looking for dynamixels connected to the robot and update the UDEV rules of the ftdi drivers which is communicating with the dynamixel motors in wrist and head. It will be great if you could send the output of this command.
The lift might be dropping because of the change in end-effector weight after Stretch 3 gripper upgrade which in-directly may affect the gravity compensation feature of the lift. To fix this you can try to increase the following parameters set from stretch_user_params.yaml. You can try incrementally increasing the feedforward current param by 0.1 units until the lift stays put without dropping during regular operation.
param.gains.i_safety_feedforward
param.lift.i_feedforward
Please let me know how the above debug suggestion work.
Thank you for your detailed response and helpful suggestions!
Just to note up front—while I’m not certain whether serial numbers have any privacy implications, I’ve chosen to redact them in the shared materials just to be safe (marked with a note like “I removed the serial number”). Any references to serial numbers below are from my own logs and outputs.
I’ve run the command REx_discover_hello_devices.py --discover --dynamixel, and it looks like the WACC is now properly detected. You can find the output log here: output
After confirming WACC detection, I attempted to run REx_discover_hello_devices.py --discover to ensure the other components (hello-motor-arm, hello-motor-right-wheel, hello-motor-left-wheel, hello-motor-lift) would also be recognized correctly. Unfortunately, that scan did not succeed. The output of that attempt is here:output
I also checked the stretch_user_params.yaml file, but I couldn’t find the parameters you mentioned—param.gains.i_safety_feedforward or param.lift.i_feedforward. I’m sharing a capture of the file below in case that helps:
I’ve been thinking more about the issue, and I suspect it might be related to the hardware components we had repaired—specifically the hello-motor-arm and hello-motor-lift. I also happen to have a properly functioning Stretch 3 unit, so I did a side-by-side comparison with the upgraded Stretch 2, and I noticed several differences:
When running ls -l /dev/hello*, the list of connected devices differs noticeably between the two robots.
As far as I understand, the /dev/ device files are created based on udev rules. (I could be wrong, but I wanted to share as much context as I can.) When I looked into those rules, it seems like the serial numbers defined there still correspond to the pre-upgrade hardware, which makes me wonder if that mismatch is preventing proper detection.
Based on all this, my current guess is that the system isn’t recognizing the new hardware because it’s still expecting the original serial numbers. If there were a way to refresh or regenerate the device configuration using the correct serial numbers, that might resolve the issue.
Would you happen to know if there’s a supported way to do that?
(For context, I’ve also unplugged and replugged all USB connections during this process.)
Thanks again—I really appreciate your time and support.
@hyuk6745 I think we might be able to solve this issue over a support call/email thread more efficiently. I have followed up to the mail you sent us at support@hello-robot.com.
