Suddenly robot become unresponsive and stuck. Neither it is working with remote control and nor it is responding to keboard-teleop. Please help as this is very worrisome for me and I am not able to use it currently . Adding the photo below in which position it is stuck.
Hi, do you have SSH access? If so, what is the result of running stretch_robot_system_check.py? If you don’t have SSH access perhaps the battery voltage has dropped and the NUC is not powered?
Please find the output below. It is still not working.
For use with S T R E T C H ™ RESEARCH EDITION from Hello Robot Inc.
---- Checking Devices ----
[Pass] : hello-wacc
[Pass] : hello-motor-left-wheel
[Pass] : hello-motor-arm
[Pass] : hello-dynamixel-wrist
[Pass] : hello-motor-right-wheel
[Pass] : hello-motor-lift
[Pass] : hello-pimu
[Pass] : hello-respeaker
[Pass] : hello-lrf
[Pass] : hello-dynamixel-head
---- Checking Pimu ----
Transport RX Error on RPC_ACK_SEND_BLOCK_MORE False 0 102
---- Debug Exception
--------------- New RPC -------------------------
Framer sent RPC_START_NEW_RPC
Framer rcvd on RPC_ACK_NEW_RPC CRC: True NR: 1 B0: 101 Expected B0: 101:/dev/hello-pimuFramer sent RPC_SEND_BLOCK_MORE
Framer rcvd on RPC_SEND_BLOCK_MORE CRC: True NR: 1 B0: 103 Expected B0: 103:/dev/hello-pimu
Framer sent RPC_SEND_BLOCK_MORE
Framer rcvd 0 bytes on RPC_SEND_BLOCK_MORE
Exception: TransportError
Transport RX Error on RPC_ACK_NEW_RPC 0 0 100
---- Debug Exception
--------------- New RPC -------------------------
Framer sent RPC_START_NEW_RPC
Framer rcvd 0 bytes on RPC_ACK_NEW_RPC
Exception: TransportError
[Pass] Voltage = 13.0443024635
[Pass] Current = 2.58393252597
[Pass] Temperature = 39.8432568098
[Fail] Cliff-0 = 36.9019165039 out of range -50 to 20
[Fail] Cliff-1 = 50.9273071289 out of range -50 to 20
[Fail] Cliff-2 = 61.3916015625 out of range -50 to 20
[Fail] Cliff-3 = 95.1186523438 out of range -50 to 20
[Pass] IMU AZ = -9.79487991333
[Pass] IMU Pitch = -3.36792349815
[Pass] IMU Roll = 0.225784301758
---- Checking EndOfArm ----
[Dynamixel ID:013] ping Succeeded. Dynamixel model number : 1060
[Pass] Ping of: wrist_yaw
[Fail] Not Calibrated: wrist_yaw
[Dynamixel ID:014] ping Succeeded. Dynamixel model number : 1060
[Pass] Ping of: stretch_gripper
[Fail] Not Calibrated: stretch_gripper
---- Checking Head ----
[Dynamixel ID:012] ping Succeeded. Dynamixel model number : 1060
[Pass] Ping of: head_tilt
[Dynamixel ID:011] ping Succeeded. Dynamixel model number : 1060
[Pass] Ping of: head_pan
---- Checking Wacc ----
[Pass] AX = 9.52845573425
---- Checking hello-motor-left-wheel ----
[Pass] Position = 1.65612566471
---- Checking hello-motor-right-wheel ----
[Pass] Position = -0.447153270245
---- Checking hello-motor-arm ----
[Pass] Position = 2.07304978371
[Fail] Position Calibrated = False
---- Checking hello-motor-lift ----
[Pass] Position = 2.41213226318
[Fail] Position Calibrated = False
---- Checking for Intel D435i ----
Bus 002 Device 002: ID 8086:0b3a Intel Corp.
Thanks for sharing the output. You are having communication errors. Let’s try two things:
- Are you still running the Xbox controller or another process in the background? Do a ‘ps aux | grep python’ to see what is running.
Stretch launches the Xbox controller script on default at startup until you turn that feature off (see
https://docs.hello-robot.com/quick_start_guide). If you have more than one process communicating with the hardware at one time you can have these errors.
- Try a full system power down. Then do a stretch_robot_system_check.py, report back the output.
Let me know if you have any questions, thanks!
It’s working after running following command twice -
pkill -f stretch_xbox*
Great! Turn off the auto-start feature as described in the Quick Start Guide to avoid this in the future.
Actually I use the remote often because carrying it from one place to other is not an good option for me.
Ah, I see! We’ll get back to you soon with some options to support your use case.
1 Like
Hi Sidh. The design intent for Stretch is that there is only one instance of the Robot class - otherwise there is resource contention for the USB devices that control its actuators, etc. I think it is best to stick within this design intent (rather than taking on the complex challenge of supporting multi-process resource management). So I see two options:
Simplest: Start and stop the xbox controller script from the command line. So:
- Disable hello_robot_xbox_teleop from the Application/Startup dialog as described in the startup guide
- Just run
stretch_xbox_controller_telop.pywhenever you need to teleop the robot. Ctrl-C to kill it when done. - You can then run your own Robot controller whenever the xbox controller isn’t running.
More complex: Allow a single Robot controller to switch between ‘xbox controller mode’ and ‘custom controller mode’. The switching could be triggered by a button on the xbox controller.
This second option is in theory straightforward but might take a bit of work to get it working well. We could help with some reference design code if desired.
–Aaron
Thanks for this information Sir 
Hello,
I wanted to piggyback on this issue because my Stretch is not responding as expected when using the xbox controller for teleop. When the controller connects only the two lower lights of the circle light up, and the actuators for both the base and the arm are unresponsive. I can make the wrist, the camera and the gripper move with the buttons on the controller.
I was hoping someone would have some guidance for me
Thanks in advance!
Hi. The issue is unrelated to the above issue. It is possible to inadvertently get your XBox controller into the incorrect mode. The upper two lights should illuminate when it is paired (not the lower two).
To change the controller mode:
- Hold the center button down for 5s. It will switch modes. Release.
- Repeat until top half of ring (upper two lights) are illuminated.
Thank you for your quick response! This solved the problem!