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 accepted abstract; the final formatted paper and its figures are not yet available.
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 |
| Upgraded generator alone | 0.935 |
| Upgraded generator with verification and filtering | 0.959 |
The final comparison improves by 13.5 percentage points, approximately 16.4% relative to the earlier value. Verification and filtering add 2.4 percentage points beyond the upgraded generator. These are benchmark correctness differences, not direct measures 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.
Exact reproduction requires the benchmark, model configuration, revised prompts, interface and participant protocol. The accepted abstract establishes the architecture and reported results, but does not justify inventing omitted implementation details. The publisher still identifies 27 August 2026 as acceptance and says the final formatted version is forthcoming.
Testing and Real-World Use
This could be tested by comparing final-plan-only and inspectable interfaces on matched planning errors, measuring time to a correctly accepted answer and the mistakes that remain after review. In maintenance or disassembly planning, visible intermediate states could help an operator identify whether a correction belongs in perception, task interpretation or the proposed sequence.
Source
See the accepted Frontiers article for the reported benchmark and user-study findings. No paper-specific video or final figure is supplied on that accepted-article page.