Setup:
UR5e | PolyScope 5.25.2 | ur_rtde 1.6.3 | RTX 5070 Ti | Robotiq Hand-E gripper 0.990 kg
References read: UR official direct_torque circular trajectory example, NVIDIA IndustReal (USB/gear insertion), ur_rtde API docs. None of these cover the discrete-step inference use case — hence this post.
What I am trying to do:
Deploy a Vision-Language-Action (VLA) policy on the UR5e using direct_torque instead of servoJ. The VLA sends discrete joint-position targets at 50 Hz — not a smooth trajectory, just position steps from learned inference. The torque controller runs at 500 Hz and must track those steps while staying compliant during contact so we do not get protective stops. I read the official documentation but it is written for trajectory following. I cannot find guidance for this discrete-step VLA or RL inference use case and am looking for the correct equation, gains, and limits.
1. Python ur_rtde vs URScript — which is the right path?
In ur_rtde Python, only the V1 friction API is available — friction_comp=True, which is binary with no per-joint tuning. getMassMatrix() from Python costs 7–15 ms round-trip, making real-time dynamics impossible inside a 2 ms loop. GC pauses also make 500 Hz unreliable.
In URScript, the V2 friction API is available — viscous_scale and coulomb_scale per joint, which gives much finer control. The RT loop is reliable at 500 Hz.
Is URScript the only correct path for direct_torque with proper friction tuning? If the Python path is viable, what is the right way to use it? And with V1 friction (binary, Python) vs V2 friction (per-joint, URScript), how different should the gains be?
2. What is the correct control equation for VLA / RL inference?
For trajectory following, a reference velocity is well defined. For discrete position steps from a VLA or RL policy, there is no meaningful reference velocity. We tested two damping options:
Option A: Kd times (v_reference minus qd) — reference velocity from finite-differencing targets
Option B: Kd times (0 minus qd) — brake against current velocity, no reference
Option B behaves much better for step inputs. Is this the correct formulation for this use case? What equation do people actually use for direct_torque outside of trajectory following?
Also: should Coriolis be included in the command? And does get_coriolis_and_centrifugal_torques() return a 6-element list or a 6x6 matrix? We have seen conflicting behavior when indexing it.
3. Is the mass matrix necessary, and if so, full 6x6 or diagonal only?
Is get_mass_matrix() needed for stable tracking at slow manipulation speeds, or does a well-tuned PD with V2 friction compensation give equivalent results? If the mass matrix is needed, is the diagonal approximation sufficient for the UR5e at speeds under 0.5 rad/s, or do the off-diagonal coupling terms matter enough to include?
4. What are reasonable starting-point gains for the UR5e?
With V2 friction active (viscous_scale around 0.9, coulomb_scale around 0.8), what Kp and Kd range is appropriate for direct_torque? Should gains be uniform across all joints or scaled per joint inertia? We found that scaling gains by inertia causes wrist joints to track very poorly — is uniform gain the correct approach for this robot?
With V1 friction (Python path, binary), would the gain range be significantly different?
5. What are the correct max torque limits for direct_torque on the UR5e?
We clamp to 150 Nm for joints 0–2 and 28 Nm for joints 3–5 based on the UR5e datasheet. Is this correct for direct_torque, or does the API apply its own internal limits that we should know about?
6. Does direct_torque compensate gravity internally?
Should gravity torques be added to the command, or does direct_torque handle gravity compensation automatically? Asking to confirm and avoid double-compensation.
Any guidance from UR engineers or anyone who has used direct_torque for compliant manipulation or learned policy deployment is appreciated. Specifically looking for the right equation, gain range, and torque limits for a discrete-step VLA or RL inference setup — not trajectory following.