Hi all, @sitaneja and I resolved the issue offline a few weeks ago. For posterity’s sake, here’s what we found.
There were four independent issues at play. The first was a transient Serial communication error that gave the following traceback:
If you run into this error, here are a couple things to try:
- Ensure that no active or background process is using stretch_body. Only one stretch_body instance can communicate with the hardware at a time (e.g. attempting a homing sequence with
stretch_robot_home.pywhile the stretch_ros keyboard teleop withroslaunch stretch_core keyboard_teleop.launchare running will result in serial transport errors). The Linux commands top, ps, and pkill will help you identify and kill background processes. - Ensure that the state of your Startup Applications Preferences looks like the image below.
- A full power cycle helps reset the robot to a working state.
- Additional information can be found in the troubleshooting guide.
The second issue involved the autonomy demos available in the stretch_ros repo.
These demos are supposed to serve as inspirational examples, and they haven’t been hardened to work 100% of the time in every environment. However, in this case, the reason they were consistently failing was unrelated to the demos themselves. Each Stretch ships with a calibrated kinematic model, which means that Stretch knows information about itself (e.g. the length of its arm). This model is used in the demos to form maps, pick up objects, and perform other autonomous tasks. @sitaneja had changed the robot physically, such that the calibrated model no longer held true. When the model is drastically wrong, where the robot believes its movements/sensing are happening won’t match reality, leading to consistent failure. Given the importance of a good kinematic model for developing autonomous tasks, we’ve released a set of calibration tools to help users automatically and visually check the quality of their robot’s current kinematic model, as well as perform new calibrations if necessary. More details on all of this is available in the stretch_calibration package’s README.
The third issue was the cause of the second issue. An offset was introduced in the head pan joint, such that the head would return to angle away from zero (facing forward) when the robot was homed. The following image contrasts what the angle should look like nominally verse what an incorrect offset from home would look like. This offset was likely introduced by back-driving the joint (physically moving the joints by hand) while the head was holding a position. @aedsinger wrote a post on which joints can be safely back-driven. Ultimately, this offset is the reason why the kinematic model no longer matched the real robot; when the robot believed it was looking forward, it was actually forming a map skewed to the left, leading to consistent failure to accomplish the tasks.
If you are experiencing this issue, follow the instructions outlined in the head pan calibration guide to re-zero the head pan joint.
The last issue was with the battery life of the robot. Even from full charges, the robot’s battery voltage would drop quickly from 12.7 V to critically low voltages near ~10 V. As covered in the safety guide, Stretch will beep rapidly when this happens. Using the robot consistently down to critically low voltage will impact the lifetime of the battery and its ability to hold charge. The charger included with the robot has a Repair mode that allows it to revive severely discharged batteries. More information on the charger and this Repair mode can be found in the troubleshooting guide.