Skip to content

What the robot protects against, and what not

Know what the hardware and the software catch, and what they do not, before you decide how the robot is guarded.

What is protected

Against How Where
A target outside the joint limits The planner refuses it; a jog stops at the limit. Firmware 1, the commander and the Python API check the earlier, partly wider limits (Joint limits) Commander, Python API
A speed or acceleration above the limits Clamped to the robot model's limits Commander, Python API
A move through a singularity (Cartesian) The commander stops the move; the API's IK fails and refuses the command Commander, Python API
A pose the arm cannot reach The IK fails and the command is refused Commander, Python API
Self-collision and collision with declared obstacles Collision checking of planned moves and jogs against the robot's meshes and your keep-out shapes Python API (set_shapes)
The E-stop pressed Reported by the board, acted on by the PC software (Emergency stop) Commander, Python API
A driver overheating The TMC5160 shuts its outputs down when it gets too hot; the fan keeps it far below that. The joint then goes limp, and firmware 1 does not tell the PC Control board
A short on a motor output The TMC5160 switches the output off. Firmware 1 reads the driver's short and open-load flags once at start-up and does not report them Control board

What is not protected

Not against Why What you do instead
A collision with something the software does not know There are no joint encoders and no force sensing: the stepper pushes until it stalls, then loses steps silently Keep the workspace clear; check programs in the simulator first; declare obstacles to the Python API's collision checker
Lost steps Open-loop motors; the position is counted, not measured After a stall or a collision, home again; keep speeds and payloads within the limits
A fall on power loss No brakes Switch off only in the parked pose; keep hands and objects out from under the arm
A frozen PC The E-stop acts through the PC software; the firmware does not stop on its own A mains switch on the power supply within reach
Lost communication with the PC The firmware has no timeout: it keeps executing the last packet until the next one arrives. After a move to a position (programs, the Python API) the joint stops near that target. After a jog in the commander the joint keeps turning at the jog speed until it reaches its blocker Keep the mains switch within reach; a short, direct USB cable
Motor temperature Only the drivers are measured, not the motors Reduce the current for long runs (Currents and temperatures)
The tool The robot does not know what the tool does Guard the tool as you would the robot
A wrong joint direction on a new build The firmware trusts its configuration Jog each joint briefly before homing

The commander's safety functions are described in Errors and recovery; the Python API's in Errors.

Comments


Found a mistake on this page? Edit it on GitHub · Report it · Get help · This page as Markdown · llms.txt · The whole manual as PDF