A UR3 screw-driving sequence must coordinate TCP Z feed, RZ rotation, axial force, and tightening moment while the tool works on a tilted surface. The reported Force Waypoint test uses the TCP feature in Frame mode with RX set to 10 N and 60°/s and Z set to 20 N and 100 mm/s. During execution, however, the head does not remain fixed in X and Y. The evidence does not establish whether this comes from the selected force frame, unconstrained axes, program configuration, or another cause, so verify those conditions before changing the motion strategy.
Separate confirmed behavior from unresolved causes
| Item | Evidence | Engineering decision |
|---|---|---|
| Work surface | Tilted | Express feed and rotation relative to the intended TCP/tool frame, then verify that frame before running. |
| Desired feed | TCP Z direction | Monitor the axial force component associated with that direction. |
| Desired rotation | RZ until a moment or depth limit is reached | Define a termination criterion before commanding each increment. |
| Observed problem | X and Y do not remain fixed during the Force Waypoint | Do not assume the cause; record the programmed frame, constrained directions, and actual TCP path. |
| Measurement limitation | Force and moment measurements are accepted as imprecise | Use conservative stopping criteria and verify the completed joint mechanically. |
Why a single force check is insufficient
A condition based on force() or one result from get_tcp_force() samples the measurement only when that statement executes. It does not continuously supervise a longer movel command. The requested component mapping is also ambiguous: the evidence calls array element 2 “Force Z” and element 5 “Moment RX,” but it supplies neither the indexing convention nor confirmed component definitions. Confirm both against the controller documentation or displayed values before using them as stop conditions.
Do not infer the required tightening axis solely from an array position. The stated motion is RZ, while the requested moment is described as RX; resolve that axis mismatch experimentally or from the controller’s documented wrench-vector ordering before running the tool.
Use incremental feed-and-rotate supervision
The evidence-supported workaround is to divide the operation into very small motions and read the wrench between them. A suggested Z increment is 0.02 mm, paired with a small RZ increment. This is discrete supervision rather than continuous or real-time force control.
- Verify that TCP Z follows the screwdriver axis on the tilted surface and that RZ rotates about that same axis.
- Read
get_tcp_force(), extract the documented axial-force and tightening-moment components, and compare them with the selected limits. - If neither the force, moment, nor depth termination condition has been reached, command a
movelstep of 0.02 mm in Z with a small RZ increment. - Repeat the measurement and motion cycle until a termination condition is true, then stop issuing increments.
# Structural pseudocode only; confirm controller syntax and vector indexing
loop:
wrench = get_tcp_force()
axial_force = documented_axial_component(wrench)
tightening_moment = documented_rotation_axis_component(wrench)
if axial_force_limit_reached or moment_limit_reached or depth_limit_reached:
exit loop
movel(0.02_mm_Z_increment + small_RZ_increment)
Verify the sequence before production
Run at a safely reduced operating condition and log the TCP pose and complete force/moment vector after every increment. Confirm that X and Y remain within the process tolerance, Z advances in the intended direction, RZ turns the screw correctly, and the selected moment component changes with tightening. A permanent rotation controlled directly to a specified moment is not established by the evidence; the supported approach is repeated small RZ increments with measurement-based termination.
FAQ
Why does one UR3 force condition not monitor the entire movel?
The condition reads the force at the instant it executes. Supervise the process by alternating small motion increments with new get_tcp_force() readings.
What motion increment can I use for UR3 screw driving?
The supplied evidence suggests a 0.02 mm Z increment combined with a small RZ increment. Check the force, moment, and depth termination conditions after every step.
Which get_tcp_force element is Force Z or tightening moment?
The evidence proposes elements 2 and 5 but does not establish the indexing convention, and it conflicts by pairing RZ motion with a moment described as RX. Confirm the documented vector order and rotation axis before using either element.
