A removal plan is more useful when an operator can inspect how it was produced, not just read its final list. This work extends language-guided EV battery disassembly with a stronger generator–verifier workflow and an interface exposing intermediate outputs, helping people locate and correct mistakes in the planning process.
The Problem Behind an Apparently Simple Instruction
An instruction to remove a battery component has to be connected to the physical scene. The system needs to identify which objects are present, interpret the requested target and produce a sequence respecting removal prerequisites. A fluent answer can still fail any of those requirements.
The work builds on the earlier ensemble-planning system. It retains perception-grounded planning while updating the language-model backbone, prompts and interaction. The contribution is therefore both a planning-pipeline comparison and an investigation of how people review its output.
Making the Stages Inspectable
RGB-D observations become structured scene text, with coordinates rewritten into a consistent LUZD representation. Consistent coordinates are important because a spatial phrase must refer to the same frame throughout perception, interpretation and planning.
A single model checkpoint serves generator and verifier roles. The generator proposes an ordered removal sequence; the verifier checks it, and a deterministic filter removes labels or coordinates absent from the perceived scene. The interface displays intermediate outputs and the final filtered plan.
graph TD
A[RGB-D observations] --> B[Structured scene and consistent coordinates]
B --> C[Generator proposes removal sequence]
D[Operator request] --> C
C --> E[LLM verifier]
E --> F[Deterministic scene-membership filter]
B --> F
B --> G[Inspectable interface]
C --> G
F --> G
G --> H[Human review and accepted answer]
Original explanatory diagram based on the published pipeline. Live sensing is used in the interface pilot; the offline accuracy benchmark starts from precomputed, cleaned scene text.
Inspectability matters because different failures require different repairs. If perception missed a component, rephrasing the request may not help. If the scene is correct but a prerequisite is omitted, the plan needs correction. Exposing the stages helps the operator distinguish those cases instead of treating every failure as a bad final answer.
Benchmark Results
The comparison uses the same 200-scene, 600-intent benchmark as the earlier work.
| Configuration | Mean full-list correctness |
|---|---|
| Previous six-sample final pipeline | 0.824 |
| Previous pipeline with replacement backbone | 0.896 |
| Upgraded generator alone | 0.9353 |
| Upgraded generator with verifier | 0.9470 |
| Upgraded generator with verifier and scene filter | 0.9590 |
The overall difference is 13.5 percentage points, but it combines a backbone replacement with prompt, identifier and pipeline changes. Keeping the earlier pipeline and replacing only its model accounts for 7.2 points; the remaining changes together account for 6.3 points. Within the upgraded stack, verification adds 1.17 points and scene filtering another 1.20 points. This is a regression comparison on a reused benchmark, not a held-out test of unseen layouts or a measure of robot safety.
The updated configuration uses two LLM calls instead of seven. Five fewer calls can reduce an important source of overhead, but call count is not a fixed time unit: prompt length, generated output, serving hardware and human review still affect the elapsed task.
What the Human Study Adds
A within-subject study with 12 participants reported lower time to an accepted answer and lower NASA-TLX workload with the new interface. All participants preferred it in this comparison. These findings address the human review process rather than merely the model’s benchmark score.
“Accepted answer” and a correct physical execution are still distinct outcomes. A useful interface can make review faster without establishing that all downstream movements are safe. Likewise, the preference result describes this participant sample and comparison, not a universal preference across all operators and tasks.
Boundaries of Verification
An LLM verifier is not an independent formal proof system and can share the generator’s misconceptions. Deterministic membership filtering provides a narrower guarantee: retained object references must be grounded in the perceived scene. It cannot recover an object that was never detected or certify every physical dependency.
The final article, published on 12 October 2026, supplies the methods, figures and component comparisons. Its two evaluations have different endpoints: offline planning correctness from cleaned scene text, and live interface use up to operator acceptance. The 12-person pilot does not measure robot execution or physical task completion, and its workload, time and preference results are descriptive rather than population-level effects.
Testing and Real-World Use
A next test could execute operator-approved plans on held-out battery layouts, measuring complete-plan correctness, perception failures, motion feasibility, interruptions and end-to-end task time. In a maintenance cell, the interface could help technicians identify whether a proposed plan needs a perception, instruction or ordering correction before robot motion.
Source
See the published Frontiers article, particularly Tables 2–3 for the controlled comparisons and Section 6.4 for limitations. Figure 5 shows the inspectable perception and generation views used to trace errors through the interface.