Related Work
Recent systems address only part of the always-on, dual-arm regime. ARMS contrasts with these systems across the relevant axes.
ARMS
ARMS is a deliberately simple policy for the always-on, dual-arm setting. Rather than building a dedicated mechanism for each new demand, ARMS keeps a single pretrained backbone and turns everything else into context: three lightweight modules each convert one signal—live perception, embodied state, and past actions—into tokens the backbone reads before it acts.
Real-Robot Deployment and Qualitative Results
ARMS sustains proactive concurrency, self-history recall, and priority arbitration together across composed streams, a real robot, and long horizons, where single-ingredient policies do not. Each module is necessary.
On one 80 GB accelerator, the asynchronous modules keep median trigger-to-decision latency under 200 ms while both arms execute.
Conclusion and Limitations
Limitations
The real-robot evidence is small-scale and based on a single Cobot Magic platform, with only approximately 200 staged always-on streams. Large-scale evidence, especially for the full overload regime exercised mainly in family D, remains limited.
Standing guards are predefined, and the default overload policy uses fixed, dataset-defined priority tiers. Broader real-world data, learned guards and priorities, and richer overload policies are natural next steps.
Frequently Asked Questions
What is ARMS designed for?
ARMS is designed for always-on, dual-arm robotic operation.
What signals do ARMS modules convert into tokens?
The modules convert live perception, embodied state, and past actions into tokens for a pretrained backbone.
What capabilities does ARMS combine?
ARMS combines proactive concurrency, self-history recall, and priority arbitration.
What is the reported trigger-to-decision latency?
On one 80 GB accelerator, median trigger-to-decision latency remains under 200 ms while both arms execute.