Robot safety, memory and touch | Robotics

What actually changed in the last 24 hours? Three new preprints tackle three practical limits in robot manipulation: keeping obstacles out of a coding agent’s plan, retaining useful history without querying a vision model every step, and using touch without adding too much latency. These are research results, not installable tools or independent validation.

SafeHarness makes safety constraints part of the plan

The SafeHarness preprint, submitted on September 17, studies coding agents that write robot controllers. Its tasks require a robot to complete a manipulation goal without touching an obstacle. The authors find that the agent often focuses on completing the task and collides, even when the instruction already forbids contact.

Their approach splits execution into route planning and contact. Before motion, it represents objects and obstacles as boxes, proposes waypoints, and replans when a route is no longer feasible. At contact, it selects a position that also avoids the obstacle. In the authors’ evaluation, SafeHarness achieves 71.9% task success and 87.5% collision avoidance. Those are study results, not a safety certification for a physical arm.

The maker takeaway is smaller and more useful: a text instruction such as “do not hit the camera” is not a geometric check before a motion command. Even with a simple planner, the forbidden zone needs to affect both the route and the gripper’s final approach.

Workspace Models shifts expensive memory work into training

Workspace Models, also submitted on September 17, proposes condensing the useful history of a task into a lightweight memory token. During training, a large vision model identifies which moments and information matter. During deployment, the policy queries that compact representation instead of calling visual reasoning on every control cycle.

The authors evaluate it in simulation and on hardware, and report that the token can replace observations for tasks that need multi-step memory. The point is not that a robot gains magical memory. A camera losing sight of an object, a moved part, or a previous action should not force a heavy query on every frame.

The preprint does not link a public package. For a Raspberry Pi, Jetson, or laptop project, first measure the historical state the task actually needs and store only that. A part position, a confirmed action, or a grasp flag is usually easier to control than sending the whole video history to a remote model.

Agile-WAM combines vision and touch with limited physical tests

Agile-WAM proposes an action model that predicts visual, tactile, and action evolution for contact-rich tasks. The preprint was submitted on September 17. It uses separate temporal horizons because video may change little between frames while touch can change sharply when a surface is contacted.

The authors report nine simulated and five physical manipulation tasks. In the five physical experiments, they report a 29.4% relative gain in overall success and 11.9 ms inference latency. That is a promising control result, but it comes from the authors and does not turn every inexpensive tactile sensor into a robust system.

There is a straightforward idea to carry into a build. Do not process every signal as if it updates at the same rate. If you add a force switch, load cell, or tactile sensor to a gripper, sample the contact event more often than the camera. Then measure whether the stop or gripper close reacts within the time your mechanism needs.

All three papers share a clear limitation. They are newly released preprints and neither replace safety testing nor provide a complete recipe for home hardware. Still, they leave three useful questions for any project: what must the robot not touch, what does it need to remember, and which signal needs to react first?