Skip to content

rti_set_tcp_vel_limit

Runs at once Any mode Takes control

Cap the tool's straight-line speed under real-time control. The robot keeps the tool centre point's translational speed at or below mps, computed at the arm's measured pose. Position streams are slowed along the direction they travel, through the generator's speed budget, so the arm trails a stream that asks for more. Velocity commands are scaled down as a whole, which keeps their direction. Torque commands are not capped. It takes effect at once.

Joint speed limits do not bound the tool's speed: near a singularity a slow joint can move the tool fast, and this cap is the guard for that case. The arm then crawls; that is the cap working. With the rate limiter off it still caps velocity commands, but not position streams. Without a kinematic model on the robot it does nothing, and RTI.log says so.

Syntax

robot.rti_set_tcp_vel_limit(mps)

Arguments

Name Type Default Description
mps float required The cap in metres per second. 0 switches it off; a negative or non-finite value is refused.

Default values

From the robot XML <safety><max_tcp_velocity>, read at start: 0 (off) on PAR6. Every rti_connect() sets it back to that value.

Returns

Nothing.

Examples

robot.rti_connect(rate_hz=50, wait=True)
robot.rti_set_tcp_vel_limit(0.25)
robot.rti_disconnect(wait=True)

Further details

Warning

Switching it off removes the only guard on the tool's speed near a singularity, until it is set again or the next rti_connect().

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
  • [6003] Invalid arguments — mps is negative or not a finite number, or the message did not carry exactly one value
  • [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
  • [6026] Refused by RTI — rTI could not use the value. The message says why; the setting in force stays

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

  • CommandRejected: The robot refused it: mps is negative or not finite, 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.
  • ValueError: mps is not a number. Nothing is sent.
  • TypeError: mps is not a number. Nothing is sent.

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.

See also

rti_set_vel_scale rti_set_rate_limiter