rti_set_lowpass¶

Runs at once Any mode Takes control

Filter incoming real-time commands with a low-pass filter. The robot passes the main value of every command, a position target, a velocity or a torque, through a second-order Butterworth low-pass filter at cutoff_hz, before the rate limiter and the stream checks; feedforward values are not filtered. It removes noise from a sensor-driven stream, at the cost of lag: about 1 ms at 100 Hz, 3 ms at 60 Hz, 9 ms at 25 Hz. In RTI mode noise reads as acceleration and can end the stream with RTI_ACCELERATION_LIMIT; 60 Hz is a good start there. Each claim starts the filter afresh.

Do not use it in SOFT_RTI: the filter keeps changing the target between your packets, the generator then follows the filter instead of your motion, and the motion gets rougher (measured). Use rti_set_min_duration() there.

Syntax¶

robot.rti_set_lowpass(cutoff_hz)

Arguments¶

Name	Type	Default	Description
`cutoff_hz`	`float`	required	The cutoff in Hz. 0 switches the filter off, and so does 125 Hz or above (half the loop rate). A negative or non-finite value is refused.

Default values¶

From config/system.xml <rti_defaults><lowpass_cutoff_hz>, read at start: 0 (off). It lasts until changed or the robot software restarts; rti_connect() does not reset it.

Returns¶

Nothing.

Examples¶

robot.rti_connect(wait=True)
robot.rti_set_lowpass(60)
robot.rti_set_lowpass(0)
robot.rti_disconnect(wait=True)

Further details¶

Note

It lasts across sessions, from any PC: switch it off (0) when your program is done.

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 — cutoff_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 — 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: cutoff_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: cutoff_hz is not a number. Nothing is sent.
TypeError: cutoff_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.