Unexpected Opposite Movement in Force Mode

Technical Questions URScript
1

Hello everyone,
I’m working with a UR5e robot and encountered some confusing behavior while using Force Mode. I’d really appreciate your advice or insights.

Here’s my setup:

  • The robot is equipped with an end-effector, and I enabled Force Mode.

  • Force Mode is configured to only allow movement in the ry direction of the tool frame.

  • I tested the setup by moving the end-effector with my hand and also by pressing it with my finger.

The issue I observed is the following:

  • When I firmly grabbed the end-effector and moved it, it responded correctly in the intended force direction.

  • However, when I pressed the end-effector with my finger, it moved in the opposite direction of what I expected.

This was quite surprising, and I’m not sure why this happens.
I’d like to address this problem through software using URScript and Python, but I’m struggling to determine the best approach.

Has anyone experienced a similar situation? What would be the recommended way to handle or fix this issue in software?

image
image1630×544 117 KB

2

Force mode can behave unexpectedly with rotational degrees of freedom. If I recall correctly, the UR5e only has a force sensor in the last joint so it has to make some estimates on how you are trying to rotate the TCP. I doubt there is much that can be done from a programming standpoint (opening up a linear degree of freedom might help?). If you share more about the specifics of your application, I could maybe help more, but otherwise the robot seems to be operating normally.

3

I agree with @EV1 that the force functions are the more complicated ones. How do you utilize them in your code? are you calling the function in URscript or in GUI? What is the movement/function you use with your force function?

If we have more information, we can maybe give more ideas how to solve the issue.

4

Hello EV1,
Thank you so much for taking the time to think deeply about my issue, and please forgive me for not responding right away.

I agree with your point that the UR5e’s Force Mode can behave unexpectedly on rotational axes, especially since the robot estimates the forces based on torque readings from the last joint. I understand that this estimation can introduce some uncertainty, particularly when small rotational inputs are applied (like around the ry axis).

Currently, I’m calling the force_mode() function directly in URScript for testing, with the following parameters:
selection_vector = [0, 0, 0, 0, 1, 0] # only ry allowed
wrench = [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
limits = [0.001, 0.001, 0.001, 0.02, 1.0, 0.02]
f_type = 2
task_frame = get_actual_tcp_pose()
force_mode(task_frame, selection_vector, wrench, f_type, limits)

At this stage, I’m only testing the basic behavior of Force Mode and haven’t implemented any higher-level control logic yet.
My goal is to first explore software-based solutions, and if those turn out to be insufficient, I’ll then consider hardware alternatives, such as adjusting the degrees of freedom.

Do you know if there’s any general software-based approach that could help compensate or stabilize the internal estimation of force and torque values to address this issue?
I’d like to understand if there’s a known or recommended method to correct this kind of response at the software level before moving toward hardware changes.

Also, one more thought — my end-effector is mounted with four bolts (as shown in the attached setup image), and I wonder if this could somehow influence the internal force estimation or sensor response.
It’s just a hypothesis, but if I were to modify it, would a bolt-free, cap-like mounting structure make a difference?
I plan to experiment with this myself, but I’d really appreciate your opinion if you have any related experience.

Thank you again for your helpful insights and for sharing your knowledge.

5

Hello mvosseler,
Thank you very much for thinking about my problem, and please forgive me for not replying immediately.

I’m currently calling the force_mode() function directly in URScript, not through the GUI.
The script is sent from a Python-based controller, and the parameters are configured as follows:
selection_vector = [0, 0, 0, 0, 1, 0] # only ry allowed
wrench = [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
limits = [0.001, 0.001, 0.001, 0.02, 1.0, 0.02]
f_type = 2
task_frame = get_actual_tcp_pose()
force_mode(task_frame, selection_vector, wrench, f_type, limits)

At this stage, I’m only running isolated Force Mode tests to observe its raw behavior,
and I haven’t implemented any higher-level control framework yet.

My goal for now is to find a software-based solution to the unexpected motion direction issue I’m observing when applying small forces.
If the results are limited, I plan to consider hardware-based alternatives later.

If you have any software-side ideas or insights that could help improve the response of Force Mode or stabilize its behavior,
I’d really appreciate it if you could share them.

Thank you again for taking the time to help and for engaging in this discussion.

6

Hello,

on first look it seems that you haven’t set a force to apply. There is a good example here force_mode_example().

Also I would look into the transposition of the task frame with “get_actual_tcp_pose()”. It could lead to unexpected behavior if one assumes direction based on base-frame.

7

Hi mvosseler,
Thank you so much for actively thinking through this issue with me and helping explore possible solutions. I really appreciate the time and effort you’ve put into this discussion.

I’ve tried several software-based approaches, including the ones you suggested, but it seems there are still some limitations.
After checking the sensor values through get_tcp_force(), I realized that the raw sensor data itself makes it difficult to fully solve this issue through software alone.

At this point, I’m considering hardware-based solutions — such as using an external F/T sensor or redesigning the end-effector — to address the problem more fundamentally.

Thanks again for your support and thoughtful input!