SoftVTBench · September 25, 2026 · Repeated physical-gripper test

Does the gripper change
when to look again?

The apparent benefit changed on repetition.
We have no reliable hardware-timing advantage yet.

LATEST / 16 EPISODES, ALL OUTCOMES

Same setting, different outcome.

We changed the physical response of the two finger motors: nominal stiffness/damping of 2,000 N/m and 100 N·s/m versus a softer setting of 800 N/m and 30 N·s/m. These motor gains change how the fingers respond to commands; their shape and material are unchanged. Each gripper setting used fresh images every command or reused visual features for eight commands. The frozen policy, action-plan interval and task resets stayed fixed. The robot was not given a hardware descriptor.

Loading audited repeat results…

Compare repeat 1 with repeat 2 under the same declared setting. Watch whether the pastry is actually lifted and reaches the basket. A gripper reaching the basket is not enough. Playback follows the recording rate, not measured execution speed; videos end independently. All four raw views are available.

Dual RGB + bilateral marker flow + language + robot state. Tasks 0–1, reset 12; simulator seed 2000; checkpoint seed 0. The same two contexts are repeated, not four independent test cases.
Gripper / visual intervalRepeatSuccess95% reference intervalCommandsVisual updates

Wilson intervals are descriptive only. All eight arms use the same frozen modified RDP policy, four sampled plans, a 560-command limit, and action-plan updates every eight commands. Runtime 6ec00a56; audit f43d8b8f. All 64 recordings passed full decoding and hash checks. Initial-state inputs match; hidden simulator state and rendering are not bit-exact. Goal success does not establish safe success or tactile necessity.

Decision: do not train a timing network on these unstable preferences or expand the unchanged grid. Diagnose grasp retention before registering the next mechanism. This negative development result is not a general verdict against hardware conditioning.

EARLIER / SEPARATE RESET-11 STUDY

Fewer visual updates can also lose a success.

The comparison below used a different reset and one attempt per setting. It is retained as context; do not pool it with the repeated hardware study above.

Loading…Visual-feature updates
Loading…successful tasks
Loading…Action commands

Renderer-corrected rerun: both cameras and policy inputs now use the restored renderer. The earlier speckled recordings used an older launch path. These are new outcomes on the same inspected cases, not sharper copies of the old trajectories. Two task/reset pairs cannot establish a population success rate.

01 / THE QUESTION

Does vision need to run on every command?

Both runs use the same frozen robot policy. One computes visual features from the two cameras on every command; the other reuses those features for eight commands. Both continue to receive fresh touch and robot state. Cameras still capture images.

Two camera viewsRefresh every 1 or 8 commands
+
Touch + robot stateUpdated every command
→
Same frozen policyAction plan refreshed every 8 commands
02 / WATCH AND COMPARE

Same starting state. Different visual timing.

Videos start together at their native recording rate; this is not a measurement of real-time execution speed. Each recording stops at its own endpoint. The restored renderer is used directly; no video denoising or generated frames were applied. Switch views to inspect the wrist camera or either tactile stream.

03 / THE NUMBERS

Fewer visual updates, one fewer observed success.

Dual RGB + bilateral marker flow + language + proprioception. Policy seed 0; simulator seed 2000; tasks 0–1, reset 11.
Visual refreshSuccess95% reference intervalVisual updatesAction commandsPlan refreshes

Wilson intervals are descriptive reference intervals. Two cases cannot establish equivalent population success rates. The successful episode stops early; failed episodes exhaust the command budget. Thus command totals here are not a like-for-like efficiency comparison among successful runs. An action command is one policy-client command, not a measured distance, energy cost, or physics substep.

04 / WHAT WE LEARNED

Saving computation is useful only if the task still works.

Loading audited results…

A useful timing objective should account for success, computation, and execution cost together. A fixed-schedule diagnostic does not establish that a learned scheduler will improve performance.

05 / THE RESEARCH DIRECTION

Let local feedback decide when to update.

Inspired by Rodney Brooks, the proposed system combines a slow task planner with local visual and fingertip models. A learned controller would use their observations and the robot’s hardware properties to choose update intervals.

Measured here

Fixed visual-update schedules with two physical finger-drive settings. The repeated test found no reliable hardware-dependent preference. The action backbone stayed frozen.

Implemented, not evaluated

Hardware inputs include gripper opening, finger length, fingertip radius, force limit, and tactile sensor count. The timing network is untrained.

Still to test

Learned update intervals, transfer to different grippers, and integration with GPT-6 Astra planning. None is deployed in these experiments.

06 / OTHER DEMOS · RENDERER-CORRECTED RERUN

Three policies, the same starting states.

Six renderer-corrected episodes compare DP, modified RDP, and the decentralized hierarchy on reset 10. These methods differ in gates, primitives, and plan sampling. Their scores are context, not an isolated architecture comparison or a comparison against reset 11 above.

Download three-policy results · Three-policy audit and video hashes
Protocol, limitations, and downloadable evidence

Same modified RDP checkpoint, four latent plans, 560-command limit, SoftVTBench revision 58056111. Runtime revision caa2fc78. Two recorded initial-state hashes match across arms; this does not guarantee identical hidden simulator state. Existing gripper gates and transport primitives remain active.

Goal success only. This experiment does not establish tactile necessity, safe manipulation, hardware transfer, wall-clock or energy savings. SoftVT is used here as a bounded development diagnostic, not as the project’s suite of record for tactile claims. All published videos are checked against their completed source audits. Raw-frame render-quality checks.