set_gravity_comp

Runs at once Any mode Takes control

Switch gravity compensation on or off for the whole robot. With it on, the robot adds the torque that holds the arm up against its own weight, from its model at the measured pose. It acts wherever the robot drives the joints: EXEC and JOG moves and holds, real-time streams, and the joints already homed while homing goes on. The error state always holds every joint still, with or without it.

In IDLE mode it also decides how the arm is held. On an enabled, homed arm with it on, IDLE is freedrive: the arm floats, can be moved by hand, and feels its joint walls and the haptic zones. With it off, IDLE holds every joint still instead.

The call returns as soon as the robot accepts it. latest_status() shows the switch in gravity_comp once it is in force, and the robot's activity log records each change.

Syntax

robot.set_gravity_comp(enabled)

Arguments

Name	Type	Default	Description
enabled	bool	required	True to add gravity compensation, False to stop adding it.

Default values

On, set each time the robot software starts.

Returns

Any

Always None: the robot's answer carries no data.

Examples

robot.enter_idle_mode(wait=True)
robot.set_gravity_comp(False)  # IDLE now holds every joint still
robot.set_gravity_comp(True)   # freedrive again

Further details

Note

A real-time stream gets gravity compensation only while this switch and rti_set_gravity_comp() are both on.

Further details

Warning

The switch is a step in the torque the joints get, which is why the robot takes it only with the arm at rest. On, IDLE mode makes an enabled, homed arm move when pushed.

Usage restrictions 4 codes

This command runs at once; it is not queued. The robot accepts it in any mode and state, from the client that holds control or when no client does.

It answers with one of these codes when it does not carry the command out:

• [6101] Control held by another client — another client holds control; the message names it
• [6010] Command not allowed now — a joint is commanded to move faster than 0.5 deg/s (config/system.xml <safety_monitor><hold_still_dps>), or a PC drives the arm in a real-time session: switch it with the arm at rest, and in a session use rti_set_gravity_comp()
• [6003] Invalid arguments — the value was not true or false (1 / 0); this client always sends one of them
• [6025] RTI not running or not answering — rTI did not answer within 1 s: it is not running or not responding. The command may still have taken effect

In Python, a code above raises CommandRejected; its number is the code. The call raises:

• CommandRejected: The robot refused it: a joint is moving, a PC drives the arm in a real-time session, or another client holds control. Or RTI refused it or did not answer within 1 s (Errors:).
• RobotTimeout: The robot did not answer within 5 s.
• RobotConnectionError: The client is not connected.

If the connection drops while the call waits for the robot's answer, it raises CommandRejected with the code CONNECTION_LOST (DISCONNECTED after disconnect()); while it waits for the robot's status, RobotConnectionError.

Like every immediate command, it also answers BAD_ARGS when a raw client sends a value the robot cannot read at all, and INTERNAL when it fails inside the robot.

Protocol

A client that does not use robotclient sends this over the TCP command protocol (port 29000) for the example above:

{"id": "c1", "cmd": "set_gravity_comp", "args": [0]}

See also

latest_status rti_set_gravity_comp set_payload set_friction_comp enter_idle_mode