Good to know · HullRS

Things the robots do that aren’t obvious, found while working with them in 2026.

Starting and stopping

Release the e-stop before switching Baxter on. If the e-stop is pressed while the robot starts, it gets stuck in an odd state and refuses to enable: every request is answered with “robot is still resetting” in its own log. Shutting it down and starting it again with the e-stop released fixes it.
Booting takes a few minutes. The robot answers a ping before it accepts connections.
On a direct cable, the robot’s address can change each time it restarts. Run add_robot.sh again, then restart the bridge.
Untuck before enabling. tuck_arms -u enables the robot itself, with collision avoidance switched off for the move. A robot enabled while tucked moves its arms away from its body by itself, because its collision avoidance pushes them out.
Disabling the motors makes the arms sink down slowly. Make sure nothing is underneath them.
The e-stop disables the robot. After releasing it, the robot needs a reset and then enabling again.

Save the WSL image in the WSL manager before you log out. Otherwise everything you set up is gone at the next login.
Run add_robot.sh every session. The lab machine’s own address can change from day to day, and the robot connects back to it.
Run source ~/baxter_ws/baxter.sh in every terminal for Baxter. The lab’s terminals start with another ROS 2 domain and middleware (Cyclone DDS). Without it, programs don’t see the robot, or see its topics but get no answer from its services.
Two lab machines can both command the same robot. Each keeps its ROS 2 to itself, so neither sees the other. Agree who drives.

Hold an arm by its cuff (the ring behind the hand) and the robot lets it move freely. This is the easiest way to find the coordinates of a place.
After someone has leaned on an arm, it may move oddly. Re-zeroing its force sensing (the tare tool) helps; the arm moves by itself while that runs.
The robot stops an arm before it touches the body or the other arm. A move that stops short has often hit this.

Only two of the three cameras can run at the same time. Asking the robot for the third one made its camera program hang until the robot restarted. The library now refuses that request and explains why.
Pictures are large. An open camera sends its pictures through the bridge all the time, whether a program uses them or not. Close cameras you don’t need.

An electric gripper needs calibrating once after power-on. It opens and closes fully while doing so.
The robot adds mounted electric grippers to its own robot model. MoveIt has to be told which arms have grippers, otherwise it thinks the fingers collide with the hand and refuses every plan.

Use the bridge’s fixed_list mode. The other mode, on_demand, pauses all data for about 0.4 s once per second on the real robot. Arm motions stutter in that mode, and commands go missing.
On a Windows laptop, run the bridge in WSL2, not in a VirtualBox VM. With Windows’ Memory Integrity switched on, VirtualBox runs in a slow mode and stood still for up to 1.3 s at a time.
The bridge machine needs an address the robot can reach. The robot connects back to it for every command. If reading works but enabling times out, this address is usually the problem.

Nothing starts on the base’s computer by itself. ROS and the base’s programs are started by hand each time.
The base has to be switched on even for the joystick. Its motors only work while its computer is on, although nothing has to run on it for the joystick.
Robot 2 and the base share one e-stop button. Pressed, it stops both.
The base’s clock was 9 days behind, because the battery of the computer’s clock is flat. Everything the base sends carries that time.