Hello,
I’m a developer in charge of unmanned café development and have been working with UR robots for about three years.
I’m reaching out because an error occurred during robot operation.
While performing a FORCE motion to press the ice dispenser lever — moving in the Y-axis direction for about 1.5 seconds — the following error occurred:
“The robot cannot reach the requested pose. Script function force_mode is unable to find an inverse kinematics solution.”
This script has been running without any issues for over six months and has not been modified. Also the lever-pressing motion where the error occurred has also been executed thousands of times before without any problems. The FORCE motion starts from a fixed waypoint defined in absolute coordinates.
I would really appreciate any insights or suggestions that could help me understand the cause of this issue.
Thank you in advance for your time and support.
I believe I’ve encountered that error before, when the robot was nearing a position in singularity (3 joints pointing in the same direction). Or the arm is stretched far out.
At this position, the robot cannot exert the correct force anymore and will stop with an error.
Maybe something has moved just a tiny bit on your setup? The lever going a bit further than before?
I’ve also been experimenting quite a bit with force_mode lately, and I completely understand the frustration you’re facing.
The singularity issue that occurs during force_mode operations has been a tricky one for me as well.
From your description, the most interesting part is that this problem suddenly appeared after months of flawless operation, without any software updates or code changes.
That makes it particularly puzzling.
It would, of course, be ideal if we could see a snapshot of the robot’s pose at the exact moment the error occurred—but I assume that’s not possible.
Still, based on your explanation, here’s what I believe might be happening.
1. The “narrow solution corridor” eventually gets crossed
Every cycle, force_mode solves a new TCP pose that satisfies both the force conditions and the fixed-axis constraints, then runs inverse kinematics again.
In tasks like pressing a dispenser lever, the space of valid poses (position + orientation) forms a very thin corridor in 6D space.
For a long time, your motion likely stayed safely inside that corridor—but small accumulated changes (0.5–2 mm shifts, a few degrees of rotation, tiny timing or force variations) can eventually push the solver just beyond the feasible range.
So while it seems “sudden,” it’s really a case of having operated on the edge of the valid region for a long time.
2. Small factors accumulate and cross a threshold
Wrist alignment / pose margin loss: When the wrist and elbow axes become almost collinear, even a 1–2° change can make the IK unsolvable.
Over-constrained rotation axes: If only translation is compliant and all rotations are fixed, micro-torques from contact can’t be absorbed, making the required pose unrealistic.
Tight limits: Very small positional or angular limits restrict natural micro-adjustments, shrinking the solution corridor further.
Environmental drift: The dispenser might have shifted by a few millimeters, lever stiffness may have changed with temperature or wear, or even slight end-effector or base movement could matter.
F/T bias and damping: Long use or temperature variation causes zero-point drift; low damping amplifies vibration, making it easier to hit boundary conditions.
Timing / seed nondeterminism: A small delay or numerical difference between cycles can send the solver to the “other side” of the pose manifold, especially near singular regions.
In short, even with the same script, once the physical or control conditions deviate just slightly, you can end up stepping over the edge of that corridor.
Of course, these are my personal hypotheses based only on your post, not your actual code or logs.
Still, I hope this gives you a helpful checklist to investigate.
You’re probably already doing this—but comparing logs from a successful run and the failing case is the most direct way to pinpoint what changed.
Practical measures that helped me in similar cases
Build in geometric slack
Before contact, bend the wrist or elbow by 5–10°.
Avoid straight-line wrist alignment (0°/180°) to widen the IK solution region.
Allow a bit of rotational compliance
Using only Y translation as compliant (1) and fixing all rotations (0) makes the system fragile.
Set rotational axes to 1 (compliant) with zero torque targets, letting the object subtly align the tool.
Start with generous rotational limits and tune down gradually.
Redesign the limits values
Remember: compliant axes use velocity limits, while fixed axes use deviation limits.
Slightly increasing deviation limits for fixed axes allows natural micro-sliding, reducing IK loss.
Standardize the entry procedure
Before starting force mode: stop → short wait (20–30 ms) → increase damping → re-zero F/T sensor.
These four steps dramatically reduce instability at the edge of feasibility.
Add passive mechanical compliance
Using spring plungers, elastomer pads, or soft ball tips makes the valid region physically wider.
When software adjustments aren’t enough, a little hardware flexibility can make a big difference.
Routine drift management
Regularly re-zero F/T sensors and verify payload/CoG or bolt tightness daily or per shift to keep cumulative error low.
In my experience, this kind of issue is not a software bug, but rather a probabilistic exposure near the boundary of the valid workspace.
For me, giving the pose a bit more margin, adding rotational compliance, and relaxing the limits or entry procedure has consistently reduced recurrence—without changing the script or hardware.
I hope this perspective and checklist help you find stability in your system again.
Good luck with the troubleshooting, and thanks for sharing such an interesting case!
Thank you very much for your detailed and insightful response.
Your analysis really helped me gain a clearer direction in understanding the root cause.
I’ll test the measures you suggested and share the outcome once I’ve applied them.
As you mentioned, it seems that small accumulated offsets in the setup — such as slight changes in the lever position — were the cause of the issue.
Thank you for your reply; it was a great help.