rti_release¶
Runs at once Any mode Takes control
End the real-time stream: brake to rest and hold, still paired. The arm brakes to rest from where it was commanded to be, within the joints' real-time acceleration and jerk limits, and holds there; no error is latched. After 0.5 s of holding, the session is paired and idle again: the robot stays in its real-time mode, keeps sending state and holds the arm still, and a new rti_claim() starts another stream. A claim sent while it brakes or during the 0.5 s is ignored.
It works in both real-time modes, also when the stream itself is down. Send it within the command timeout after your last command, or the robot latches RTI_LINK_LOST first. Without an active claim the robot ignores it.
Syntax¶
Arguments¶
None.
Returns¶
Nothing.
Examples¶
import time
from robotclient import RTIClient
rti = RTIClient(robot)
rti.connect(rate_hz=50)
robot.wait_mode("SOFT_RTI")
q = rti.read_once()["j_p"]
rti.claim()
for i in range(50):
q[5] += 0.0005
rti.send_joint_position(q)
time.sleep(0.02)
robot.rti_release()
time.sleep(1)
robot.rti_disconnect(wait=True)
rti.close()
Usage restrictions 3 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
- [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 — no session to release: no claim is active. The message says why
In Python, a code above raises CommandRejected; its number is the code. The call raises:
CommandRejected: 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.