Skip to content

rti_set_state_rate

Runs at once Any mode Takes control

Set how often the robot sends its state packet in SOFT_RTI. The robot sends a state packet every 4 ms tick, 250 a second, however slowly you command. This lowers the rate: the robot then sends one every 250 / hz ticks, rounded. It matters most over TCP, where state is many times your command traffic: a PC that reads too slowly fills the robot's send buffer, and the robot then closes the stream. set_recipe() makes each packet smaller.

There is no off: the state stream is how RTIClient notices that the robot left real-time control. In RTI mode, where you close the loop every tick, the robot ignores this call; send it after a SOFT_RTI rti_connect().

Syntax

robot.rti_set_state_rate(hz)

Arguments

Name Type Default Description
hz float required Packets per second, from 10 to 250 (clamped); 0 sends every tick again. A negative or non-finite value is refused.

Default values

Every tick (250 per second), set each time the robot software starts and at every rti_connect() in RTI mode. A SOFT_RTI rti_connect() keeps the value it finds, so it lasts until changed.

Returns

Nothing.

Examples

robot.rti_connect(rate_hz=10, wait=True)
robot.rti_set_state_rate(50)
robot.rti_disconnect(wait=True)

Further details

Note

RTIClient.control() waits 0.1 s for each packet by default, the very gap between packets at 10 Hz: at low rates give it a longer timeout.

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 — hz 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 — in RTI mode (hard RTI) the state stream follows your packets: give rti_connect() a rate_hz (SOFT_RTI) to throttle it. Or RTI could not use the value. The message says why

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

  • CommandRejected: The robot refused it: hz 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: hz is not a number. Nothing is sent.
  • TypeError: hz 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

set_recipe rti_connect