Moving-target MPC: experimental final approach

This is an experimental attempt to update the last approach as a cube moves. It has not established a commissioned moving-object capability. The physical trial exposed a conflict between command-space table clearance and endpoint tolerance under tracking error; the constraint analysis below is the starting point for further development.

The reusable implementation is an asynchronous handoff: the solver proposes a future segment while control continues on an already checked segment. The diagram answers what happens if that replacement is accepted, late or rejected? It assumes the low-level controller, state stream and watchdog remain healthy.

        flowchart TB
  accTitle: An MPC proposal crosses a checked future handoff
  accDescr: Fresh visual and body state updates feed the worker solver. A proposed future command window reaches the buffer, which checks timing, predecessor and continuity. Acceptance queues the window; rejection preserves the existing checked tail and endpoint hold.
  O["Fresh cube/body state<br/>and future boundary"] --> W["Worker solves<br/>future command window"]
  W --> B["Buffer checks time,<br/>identity and continuity"]
  B -->|accepted| Q["Queue unchanged window"]
  B -->|rejected| H["Retain checked tail<br/>and endpoint hold"]
  Q --> C["Fixed-rate command sampling"]
  H --> C
    

Scope narrowed to the final approach

Early versions tried broader phase tracking. The retained design applies MPC only from fresh visual pregrasp to grasp. MotionGen still owns global approach, payload transport, placement and return. A fixed-cube reference at clearance and fresh cube/IMU observations update the target during the final approach. A one-time ChArUco observation cannot observe later unmodeled translation.

An asynchronous solver must not interrupt control

Each accepted window has an absolute activation time, predecessor identity and predicted/commanded q, dq, ddq. The reviewed contract uses a 240 ms future handoff and a 0.8 s, 81-state tail that ends at zero velocity and acceleration. If a replacement is rejected or late, that previously checked tail decelerates into a hold.

Command-minus-measured tracking offset is remeasured for the full window. It must not be faded away, accumulated repeatedly or treated as a constant from an old prediction. Both predicted physical geometry and desired command geometry are checked. An early ideal-plant replay with measured equal commanded hid a persistent-offset stall.

One physical window requested 0.257 rad/s against a 0.2 rad/s limit and was correctly rejected. A rejected high-level solve must leave a healthy low-level hold in place while bounded retries remain possible. Expiring a planning deadline must not independently drop torque ownership.

Progress must be relative to the current object

Nominal joint progress could report advancement while missing a moving goal. An object-relative criterion improved a simulated 5 mm target-movement case: 81 windows over 20 s reached 3.704 mm and 0.954° terminal error. This supports using object-relative progress in that replay; it does not establish successful moving-target hardware operation.

The unresolved physical constraint conflict

On August 21, the measured physical goal had 7.074 mm table clearance, but the desired command under the tracking-offset model had −1.588 mm. Bringing that command to the required 5 mm floor needed a 6.588 mm shift, exceeding the 5 mm target tolerance.

A tested padding workaround produced 194 valid windows without satisfying termination; error remained about 6.27 mm. The workaround was removed. It did not solve the incompatibility. A related corrected offset test exposed a real 0.06 mm self-collision and was rejected rather than hidden by a tolerance.

The useful result is a clearer execution and rejection contract, together with a concrete remaining limitation. Future changes should reproduce the measured tracking-offset case and show how both endpoint and clearance requirements are met before claiming an improved moving-target controller.

Evidence: tabletop MPC development, nonideal replay and August 21 endpoint analysis. Source identities.

Follow the code

Implementation concern	Code entry point	Responsibility
Moving target update	tabletop_mpc.py · MovingGraspMPC.update_moving_grasp_goal	Use the observed object with the selected grasp geometry.
Worker solve	tabletop_mpc.py · MovingGraspMPC.solve_window	Produce predicted motion and a command window for the frozen handoff.
Window acceptance	mpc_command_buffer.py · RollingMPCCommandBuffer.install	Reject stale, fast, discontinuous or wrong-predecessor windows.
Command sampling	mpc_command_buffer.py · RollingMPCCommandBuffer.command	Sample the accepted window and retain its endpoint hold.

A high-level solve rejection is distinct from a low-level control fault. The diagram assumes state freshness, the control driver and watchdog remain healthy. The independent safety path still governs an actual loss of control health.

Checks and evidence to inspect

test_mpc_command_buffer.py checks future boundaries, tracking-offset preservation, rejection and held endpoints. test_tabletop_workflow.py contains the rejected-window retry cases. The physical endpoint/clearance conflict above remains unresolved; this path is not a commissioned moving-object capability.