PAPER DEEP DIVE
FORCA: A Force-Aware Coding Agent for Contact-Rich Robot Manipulation
Coding agents can translate language instructions into robot programs. For contact-rich manipulation, a key challenge is to generate and refine control logic that responds to physical interaction. We present FORCA, a coding agent that takes visual observations and wrist force/torque (F/T) measurements as input to write Python programs for contact probing and force-responsive motion. Between executions, the agent inspects force records alongside visual outcomes to diagnose failures and revise both motion and force-feedback control logic. FORCA requires no demonstrations, task-specific training, or simulation. Across five real-robot tasks, we demonstrate its effectiveness in three forms of contact-rich manipulation: improving manipulation accuracy, adapting to changes in object or surface properties, and regulating contact under surface variation and object motion. Compared with a vision-only variant of the same agent, FORCA improves grasp accuracy and task success and reduces contact loss in wiping and peeling.
Paper information
Title: FORCA: A Force-Aware Coding Agent for Contact-Rich Robot Manipulation
Authors: Xiao Tan, Yixuan Wang, Zhexi Wang, and Wenzhen Yuan, all at the University of Illinois Urbana-Champaign.
Paper: https://arxiv.org/abs/2610.31841, submitted on October 22, 2026.
Code status: As of October 29, 2026, neither the paper nor its project material links to a public implementation. Searches on GitHub using the method name, full title, and author information also found no official repository. The controller details below therefore come from the paper rather than source code.
One-sentence summary: FORCA lets a coding agent write complete robot programs from language, RGB-D observations, and wrist force/torque measurements, then revise both the motion and the force-feedback logic after real rollouts using the recorded wrench traces and visual outcomes, without demonstrations, task-specific training, or simulation.
Why force matters in robot programming
Foundation-model coding agents can already turn an open-ended instruction into a sequence of perception, grasping, planning, and execution calls. Their evidence is mostly visual and proprioceptive. That is often enough to find an object and move toward it, but contact-rich manipulation asks a different set of questions. Has the tool actually touched the surface? Does a sudden increase in resistance indicate a released latch, a mechanical stop, or a jam? Did contact disappear when the object moved? Is the current press approaching a force that could damage the object?
Vision is a weak observer for several of these states. Transparent drawer handles can blend into the background, reflective surfaces can corrupt depth, and neither mass nor friction is directly visible. The hardest case is not a static geometric error. A trajectory tuned on a stationary vase can fail when a person moves that vase during wiping. The same tapping motion can send a light cube and a heavy cylinder very different distances.
Learned force or tactile policies can react to these changes, but they usually need demonstrations, teleoperation data, or substantial robot-specific training. Classical compliant control and guarded motion are more sample efficient, but their thresholds, nominal trajectories, and transition rules must be designed per task. FORCA targets the space between these approaches: a general coding agent writes task-specific force logic at deployment time and then revises that logic after observing a real failure.
The central design choice is that wrist force/torque is used in two loops. During execution, generated code can probe for contact, use the contact pose to update geometry, and regulate Cartesian motion at 100 Hz from live force. Between executions, the coding agent aligns force traces, robot states, and images to diagnose the failure and rewrite the code. Experience is therefore retained as an inspectable Python program rather than as an opaque policy update.
This division of labor is important for robot engineering. The coding agent does not have to invent object segmentation, grasp generation, or trajectory optimization. It composes established modules and focuses its generated code on the part that changes with the physical interaction: when to probe, what a force pattern means, how to react while contact evolves, and when a state transition should occur.
Problem formulation
The paper defines one rollout as one complete cycle in which the agent writes or revises a task program and executes it once on the real robot. A wrist sensor returns a six-dimensional wrench. At sample \(k\), it can be written as:
$$\begin{aligned}w_k&=(f_k,\tau_k),\\ f_k&\in\mathbb{R}^{3},\quad \tau_k\in\mathbb{R}^{3}\end{aligned}$$
Here \(f_k\) is force and \(\tau_k\) is torque. The program does not receive a full tactile image showing where every fingertip touches the object. It observes the net mechanical effect at the wrist. That signal can mix tool weight, grasp force, inertial effects, and contact reaction. The generated code must therefore use calibration or relative changes to identify the component relevant to the current task.
Given a language instruction \(l\), RGB-D observation \(O_{\mathrm{RGB-D}}\), predefined skills \(S\), and the wrist interface \(\mathcal{I}_{\mathrm{FT}}\), program synthesis is:
$$\mathcal{P}=\mathcal{A}\left(l,O_{\mathrm{RGB-D}},S;\mathcal{I}_{\mathrm{FT}}\right)$$
\(\mathcal{A}\) is the coding agent and \(\mathcal{P}\) is a complete Python program containing an action sequence and force-dependent logic. The program runs without calling the foundation model, so language-model latency does not determine the low-level control rate.
Force can enter the program in two different ways. It can support discrete decisions, such as ending an approach, accepting a latch release, or pausing forward motion while contact is absent. It can also support continuous control, such as changing Cartesian velocity from the difference between measured and target force. FORCA's contribution is not a universal force threshold. It is a framework in which the agent writes, executes, diagnoses, and rewrites these task-specific uses of contact.
Method: code generation, contact, and revision
1. Start from reusable robot skills
The initial library is assembled under human supervision from open-source components. SAM 3 localizes the tool mentioned in the language instruction. GraspGen proposes candidate grasps, and a vision-language model selects one. PyRoKi computes a collision-free path, after which the robot executes the routine. The paper illustrates this sequence by having the robot acquire a whiteboard eraser for the instruction “wipe the vase.”
These modules reduce the part of the problem that must be regenerated. Object segmentation, grasp candidates, and trajectory planning already have explicit interfaces. The coding agent concentrates on task ordering and the force-dependent control that is most sensitive to changes in material, surface, and mechanism state.
2. Contact probing updates a geometric belief
A transparent drawer handle shows why visual geometry is not enough. The image gives an approximate location, but the depth edge is unstable. A direct grasp can miss above or beside the handle. FORCA writes a probing action that moves toward the estimated surface and defines a contact condition. The robot pose at contact and known tool geometry then update the surface or grasp estimate:
$$\hat{h}^{+}=\hat{h}+\Delta h\left(x_{\mathrm{contact}},g_{\mathrm{tool}}\right)$$
\(\hat{h}\) is the visual estimate, \(x_{\mathrm{contact}}\) is the robot pose where contact is detected, \(g_{\mathrm{tool}}\) describes the tool, and \(\hat{h}^{+}\) is the corrected estimate. A generic form of the contact test is:
$$C_k=\mathbf{1}\left[g_{\mathrm{probe}}(f_k,\tau_k,x_k)\geq\tau_{\mathrm{probe}}\right]$$
The paper deliberately leaves \(g_{\mathrm{probe}}\) and \(\tau_{\mathrm{probe}}\) task-specific. They are generated or revised by the coding agent, not fixed by FORCA. This matters because a single wrist threshold cannot distinguish every kind of contact across wiping, peeling, door handles, and tapping.
The door-handle experiments reveal that probing is also a state-estimation loop. An early camera estimate placed the door three to four centimeters too close. The robot missed it and then rejected a real touch. The revised program searched farther and trusted the touch to update door depth. The agent changed how contact evidence was interpreted, not merely a coordinate offset.
3. A generated controller regulates contact at 100 Hz
For sustained contact, a host-side loop reads wrench and robot state over RTDE at 100 Hz and updates Cartesian velocity commands. The paper does not prescribe one closed-form controller. It allows generated logic to decide the feedback relation:
$$v_{k+1}^{c}=\Pi_{\mathcal{P}}\left(f_k,f^{*},x_k,v_k^{c}\right)$$
\(v_k^{c}\) is the current Cartesian velocity command, \(f^{*}\) is the desired contact force, \(x_k\) is robot state, and \(\Pi_{\mathcal{P}}\) is the feedback mapping implemented by program \(\mathcal{P}\). The mapping can adjust velocity smoothly from force error, pause forward motion when contact is missing, or resume once contact returns.
This structure matches wiping and peeling. A wiping tool must follow a curved object while maintaining normal pressure. Once a person moves the vase, offsets tuned for a static vase no longer track the surface. A peeling blade faces a related problem: it must follow an irregular cucumber while avoiding sustained pressure above the safe range. Vision knows where the object is, but it does not directly reveal whether the blade has briefly separated from the skin.
The robot still enforces a hard 30 N safety limit. Any rollout that reaches it is stopped and counted as a failure. This protection is separate from the task-level target force and from the coding agent's generated conditions. The vision-only baseline remains subject to the same robot-level safety protections but never receives force data.
4. Revision changes the response to contact
After a rollout, the agent examines camera images, wrench traces, and robot state. It may write analysis code to isolate a relevant time window, align force drops with unpeeled regions, or compare a resistance peak with handle rotation. The revision can be summarized as:
$$\mathcal{P}_{r+1}=\operatorname{Revise}\left(\mathcal{P}_{r},F_{0:T}^{(r)},X_{0:T}^{(r)},O_{\mathrm{visual}}^{(r)}\right)$$
The revised object can be a motion parameter, contact threshold, action order, or the state-transition logic itself. In the door-handle case, the final program uses a resistance rise to recognize an end stop and looks for latch release around 61 to 65 degrees. It accepts an end stop only after 65 degrees and waits for a force drop before pulling.
The figure makes the distinction from parameter tuning concrete. Images show unpeeled regions around 53 to 62 mm and 92 to 101 mm. The force trace shows that the blade had less than 1 N of contact in the same intervals. The agent adds a contact gate: move a short distance, check force, and wait in place when contact is insufficient instead of continuing through air.
Before a revised program runs, checks screen the code and planned motion for errors, reachability, and workspace violations. Development stops when the agent declares convergence, after 20 rollouts, or after four hours of wall-clock time. The final program is then frozen and evaluated repeatedly rather than accepted on a single successful run.
5. Three distinct roles for force
Precision manipulation uses contact as geometric and mechanism-state evidence. The robot probes a transparent drawer or a door surface, updates its estimate, and uses force to determine whether a latch has released or a handle has reached a stop. Physical adaptation uses contact outcomes to infer how mass, geometry, and friction affect motion. Contact regulation uses live wrench to maintain a desired interaction while surfaces move.
All three settings share the outer loop of code synthesis, real execution, evidence collection, and code revision. Their inner loops differ. A precision task may rely mainly on a few probe events and discrete force conditions. A tapping task may revise the impact from the observed endpoint. Wiping and peeling need continuous feedback within a rollout. FORCA does not force these cases into one control template; the agent writes the relevant code for the task.
flowchart LR
A[Instruction and RGB-D] --> B[Reusable robot skills]
B --> C[Coding agent writes P]
C --> D[Probe with wrist wrench]
D --> E[Correct pose and geometry]
E --> F[100 Hz force-responsive loop]
F --> G[Real robot rollout]
G --> H[Align force state and images]
H -->|failure| I[Rewrite motion and feedback logic]
I --> C
H -->|success| J[Freeze program]
J --> K[Evaluate over 10 trials]
Experimental evidence
The hardware consists of a UR5e arm, a wrist force/torque sensor, a WSG-50 gripper, and a fixed RealSense D455 RGB-D camera. Claude Fable 5 performs all coding and analysis in the reported experiments. Each task is limited to 20 rollouts and four hours. Final programs are frozen and evaluated over repeated trials. Human involvement is restricted to execution authorization, scene setup, and final acceptance.
The vision-only baseline uses the same foundation model, instructions, and basic skills. It cannot access live or recorded wrench data, cannot generate force-responsive routines, and cannot inspect force during revision. It can still write visual feedback code and use images to adjust trajectories. This controls the model and the skill library so that the main difference is the availability of force.
Drawer and door handle
Each frozen precision program is executed for ten trials. The drawer is transparent, making handle localization difficult from depth alone. The door handle adds grasp, rotation, latch release, pulling, and retreat. Table 1 reports translational error, rotational error, and task success.
| Task | Method | Translational error (mm) | Rotational error (deg) | Success |
|---|---|---|---|---|
| Drawer | Vision-only | 8.3 ± 5.4 | 9.6 ± 3.2 | 40% |
| Drawer | FORCA | 5.3 ± 1.6 | 1.0 ± 0.3 | 100% |
| Door handle | Vision-only | 65.3 ± 16.9 | 55.5 ± 14.9 | 10% |
| Door handle | FORCA | 20.0 ± 0.9 | 0.6 ± 0.5 | 100% |
The drawer trial reduces translational error by about 36 percent and rotational error from 9.6 to 1.0 degree. Success rises from 4/10 to 10/10. The door result is larger: translational error falls from 65.3 to 20.0 mm, rotational error from 55.5 to 0.6 degree, and success from 1/10 to 10/10. The failure history shows why. The vision-only agent can push the handle down, but often grasps too shallowly or at a bad angle, then loses the handle during the pull. FORCA probes the door surface, uses contact to correct the model, and identifies latch release and mechanical stop from the force trace.
The numerical improvement should not be read as a simple sensor swap. The drawer obtains a large rotational gain from a short probing phase, but the door requires a sequence of contact interpretations. FORCA must distinguish a real touch from a missed probe, infer a rotation axis from measured motion, and identify both latch release and end stop. The baseline can see that the door did not open, yet it lacks direct evidence that the handle is slipping inside the gripper.
Adaptation to mass and friction
The cube-to-target task asks the robot to tap an object so that it slides into a target region without overshooting. The object’s mass, contact geometry, and surface friction change the response. The paper tests a 61.9 g cube and a 663.6 g cylinder on a whiteboard and a woodboard. The mass differs by more than ten times, and the two surfaces impose different friction.
FORCA first develops a tapping program from scratch for the cube on the whiteboard in 13 iterations. It then reuses that program for the other physical configurations. After each attempt, it combines the impact force record with the final object position and revises the program. The three new configurations reach the target band after an average of two additional revisions, compared with 13 for the original development.
The evidence here is primarily the reduction in adaptation iterations, not a universal success claim. The retained program preserves an action pattern that is useful across physical conditions and can be corrected from a small number of real interactions. The boundary is that the target is still a geometric band and the code is specialized to tapping. The paper does not yet demonstrate a long-term library that can decide by itself which prior program should be reused for an unrelated task.
Wiping and peeling under motion
Vase wiping removes a marker line with a whiteboard eraser. FORCA refines a program on a static vase and then transfers the frozen program, without further revision, to a vase translated and rotated by a person. The evaluation reports marker removal, contact loss, and maximum force. Contact loss is the fraction of active task time where pressing force stays below a threshold for at least 0.2 seconds:
$$\begin{aligned}L_s(t)&=\mathbf{1}\left[\forall u\in[t-\Delta,t],\ f_s(u)<\tau_s\right],\\ \Delta&=0.2\,\mathrm{s}\end{aligned}$$
For wiping, \(f_s\) is the tool-normal projection and \(\tau_s=1.5\,\mathrm{N}\). For peeling, \(f_s\) is the base-frame \(z\) force and \(\tau_s=0.8\,\mathrm{N}\). Excessive force uses a 10 N upper threshold:
$$E(t)=\mathbf{1}\left[f_p(t)>F_{\mathrm{high}}\right],\qquad F_{\mathrm{high}}=10\,\mathrm{N}$$
The peeling target band is:
$$4.5\,\mathrm{N}\leq f_p(t)\leq 7.5\,\mathrm{N}$$
| Task and setting | Method | Removal | Contact loss | Maximum force (N) |
|---|---|---|---|---|
| Static vase wiping | Vision-only | 73% | 42.6% | 11.8 |
| Static vase wiping | FORCA | 99% | 0.7% | 11.3 |
| Hand-held vase wiping | Vision-only | 21% | 55.9% | 17.5 |
| Hand-held vase wiping | FORCA | 93% | 1.6% | 12.3 |
| Hand-held cucumber peeling | Vision-only | 37.4% peeled | 40.6% | 13.4% excessive |
| Hand-held cucumber peeling | FORCA | 81.1% peeled | 2.2% | 2.7% excessive |
On the static vase, both methods remove most of the marker. The visual program tunes fixed trajectory offsets to the stationary geometry. Those offsets no longer track the object when a person holds and moves it. The vision-only removal rate drops to 21 percent and contact loss rises to 55.9 percent. FORCA retains 93 percent removal with 1.6 percent contact loss. The difference comes from regulating motion during execution rather than remembering a single successful path.
The cucumber is held by a person and has a curved, slightly irregular surface. FORCA uses a 4.5 to 7.5 N target band and waits when contact falls below the lower boundary. The frozen program peels 81.1 percent of the intended strip on average, compared with 37.4 percent for the baseline. Contact loss falls from 40.6 to 2.2 percent, and the fraction of active time above the excessive-force threshold falls from 13.4 to 2.7 percent. One representative rollout covers 90.6 percent of the intended length with FORCA and 28.9 percent with the baseline.
Wiping and peeling show why a visual offset correction is not sufficient. Both surfaces move during a rollout. A program must react to the current force and change its velocity within a fraction of a second. Because the reaction is represented as source code, a developer can associate a specific gap in the peeled strip with a specific contact condition and revise that condition.
Development cost and what the revisions reveal
The paper also measures the physical and reasoning effort needed to reach a working program. The door handle uses 17 iterations, the drawer 8, tapping from scratch 13, a new tapping condition two on average, and both wiping and peeling the full budget of 20. Agent reasoning dominates each iteration.
| Task | Iterations | Agent reasoning (min/iteration) | Robot motion (min/iteration) |
|---|---|---|---|
| Door handle | 17 | 10 | 3 |
| Drawer | 8 | 5 | 1.5 |
| Cube-to-target, from scratch | 13 | 4 | 1 |
| Cube-to-target, new condition | 2 | 4 | 1 |
| Vase wiping | 20 | 4 | 1 |
| Cucumber peeling | 20 | 5 | 1.5 |
The door-handle history is informative because failures occur at different layers. In early trials, the robot misses the door or rejects a real touch because the visual depth is wrong. The first firm grasp turns the handle only 18 degrees under the 10 N limit, which is insufficient to release the latch. Later trials misread small motions as blocked, press along the wrong axis, or collide with a cable plug that is absent from the collision model. After latch release, end-stop push-back consumes force budget intended for pulling. Release and retreat introduce another set of failures involving handle rebound and a stale force reading.
These errors are not all caused by a bad threshold. Some are scene-model errors, some are state-estimation errors, and some are mistakes in how one action hands control to the next. FORCA can revise the search distance, the handle model, the accepted angle for an end stop, the force drop required before pulling, and the force-sensor zeroing before retreat. That breadth is the reason the paper argues for revising the feedback program rather than tuning a single global parameter.
The cost is equally important. A door-handle iteration takes about 10 minutes of agent reasoning plus 3 minutes of robot motion. Wiping and peeling use all 20 real rollouts. A hand-engineered controller may be faster for a stable, well-understood task. FORCA is aimed at tasks where the physical response is uncertain and where a new executable first version is more valuable than immediate engineering efficiency.
What the contributions really establish
The paper makes three linked contributions. First, it synthesizes task-specific motion and force-feedback control, not just calls to a fixed family of force primitives. The generated program decides when contact evidence is needed and how it changes subsequent motion. Second, it revises the feedback logic itself. This goes beyond fitting a trajectory offset: the agent can change the state-transition semantics, such as waiting for contact recovery before advancing a peeling blade. Third, it keeps deployment experience in executable code that can be rerun, inspected, and locally changed when physical conditions shift.
The cube experiment gives the clearest evidence for code as a form of retained experience. A program developed for one mass and surface needs 13 iterations from scratch, but a new physical condition needs about two revisions. The paper does not claim that this solves lifelong learning or automatic skill retrieval. It does show that a developed contact routine can remain useful beyond the exact condition in which it was created.
Limitations and residual questions
The authors explicitly identify iteration cost. Each iteration lasts several minutes, with reasoning taking most of the time, and the present method depends on real-robot rollouts. This can be expensive or unsafe when each attempt needs a human reset, risks the object, or occupies shared equipment. The authors suggest preliminary refinement in simulation, but the paper does not report such transfer.
The authors also identify the limits of wrist sensing. A wrist wrench captures the combined effect of contact, not the location and pressure distribution at the fingertips. This makes it difficult to diagnose how a handle slides within a gripper or which part of a tool is touching a surface. Distributed tactile sensing may provide richer evidence, but it is left to future work.
Task complexity is the third stated limitation. Longer action sequences and tighter force constraints may prevent the agent from diagnosing the true failure and producing a successful program even after repeated attempts. The 17-step door-handle development already contains tightly coupled failures; a substantially longer task could make the causal search much harder.
A separate concern is statistical scope. Five real tasks are meaningful evidence, but each final program is evaluated over ten trials on one UR5e, one gripper, and one fixed camera. The paper reports means and standard deviations or rates, yet does not show variation across lighting, camera placement, gripper types, or multiple independent development sessions. Code quality and failure diagnosis may also depend on the exact foundation model, so the result is not proof that any coding agent will reproduce the same iteration counts.
The vision-only comparison controls the model and skill library, but it changes several mechanisms at once. FORCA has contact geometry, live force regulation, and force-grounded revision; the baseline has none. The experiment does not isolate how much comes from probing, how much from online control, and how much from rewriting the feedback state machine. A stronger ablation would disable one channel at a time.
Finally, reproducibility is restricted by the absence of public code, prompts, skill-interface versions, and complete generated programs. Since the study uses a specific model and a wrist-sensing robot setup, an engineering team would need to reconstruct the runtime, safety checks, calibration, and evaluation protocol before applying the method. The paper supplies the conceptual method and outcome data, not a drop-in implementation.
Conclusion
FORCA presents a practical route between hand-coded contact control and end-to-end robot learning. The agent writes an executable program from language and visual context, uses wrist force during execution, and diagnoses failures from paired force traces and images. Across precision manipulation, physical adaptation, and sustained contact regulation, the approach produces large improvements over a vision-only coding agent.
The boundaries are just as concrete. Real rollouts are expensive, wrist force does not reveal distributed contact, and long or tightly constrained tasks can defeat the revision process. The next steps should test simulation-assisted candidate selection, richer tactile evidence, and a program library that can retrieve and compose successful contact routines. For robot engineering, the most important near-term lesson is the executable layer itself: the model writes and revises code, the robot runs deterministic checks and safety guards, and every failure remains tied to a version of the program that produced it.
Golden line: A robot starts to learn at deployment when each physical failure can be traced back into code and the next contact can rewrite that code.
