Force Mode Issue: zero_ftsensor() Called Under Load Causes Unwanted Reaction Force

Technical Questions URScript
1

Problem Description

I’m experiencing an unexpected behavior when using Force Mode for compliant drilling.
When zero_ftsensor() is called while external force is already applied to the TCP,
the robot generates an unintended compensation force in the opposite direction.

Steps to Reproduce

  1. User manually applies approximately 10N downward force on the TCP (tool tip)
  2. Start the program in this state
  3. Program calls zero_ftsensor()
  4. Force Mode is activated

Expected vs Actual Behavior

Expected:

  • Sensor zeroes out, robot moves compliantly in the direction of applied force

Actual:

  • After sensor zeroing, robot pushes upward
  • Robot generates opposing force against the user’s downward push
  • Unwanted force compensation occurs

Root Cause Analysis

My analysis:

  1. zero_ftsensor() is called while 10N downward force is applied
  2. Sensor sets current state (-10N) as new reference point (0N)
  3. When user releases or reduces the force
  4. Sensor now reads relative +10N (upward force)
  5. Force Mode interprets this as external force and compensates in opposite direction

Questions

  1. Is there a standard method to verify no external forces are present
    before calling zero_ftsensor()?

  2. Is it appropriate to check current force with get_actual_tcp_force()
    and only zero when below a threshold (e.g., 3N)?

  3. Are there any recommended best practices to prevent this situation?

Potential Solution Under Consideration

# Check for external forces before zeroing
current_force = robot.get_actual_tcp_force()
force_magnitude = np.linalg.norm(current_force[:3])

if force_magnitude > THRESHOLD:
    # Display warning and wait
    time.sleep(2.0)

robot.zero_ftsensor()

Would appreciate any feedback on whether this approach is correct.

Thank you.

2

As you state yourself, zeroing of the FT sensor must always be done with no external force applied to the tool (which isn’t supposed to be there and stay there at least).

I’ve always been able to program my way out of it by having the robot in free space and instructing operators not to touch the robot while in use.
Is this not possible for you?

I guess the threshold could work. Though not if the sensor drifts too far too fast.