📃cuArms 리뷰

cuArms: GPU-Accelerated Conflict-Based Planning for Multi-Arm Manipulation

• Paper Link (arXiv:2610.36250)

• Project

• Appendix (PDF, 프로젝트 페이지)

• Philip Huang, Fabio Ramos, Jiaoyang Li, Caelan Garrett*, Lars Johannsmeier* (*equal advising)

• NVIDIA · Carnegie Mellon University · University of Sydney, arXiv preprint (cs.RO), 2026

1. 💡 여러 로봇 팔이 한 작업 공간에서 pick-and-place·용접·handover·양팔 운반을 함께 하려면 할당·스케줄·충돌 회피·접촉 skill을 동시에 풀어야 한다. cuArms는 MAPF의 conflict-based 탐색(LaCAM + PIBT)을 로봇 팔로 옮기고, 비싼 기하 검사를 GPU 배치로 몰아 이 문제를 실시간 근처로 끌어내린다.
2. ⚙️ 로봇마다 재사용 가능한 multi-modal roadmap을 GPU에서 만들고(물체 배치가 바뀌면 mode-validity mask만 다시 계산), 탐색 상태마다 모든 로봇의 후보 행동 쌍을 한 번에 GPU로 충돌 검사해 Boolean conflict table을 만든 뒤 CPU의 PIBT가 그 표만 조회해 충돌 없는 다음 joint state를 고른다. 해가 나오면 GPU 배치 shortcut으로 다듬고, 상위 scheduler가 다른 schedule skeleton을 계속 제안한다.
3. 🎯 RoboBallet 용접 벤치마크(4·8팔, 10·40 타깃)에서 150/150을 풀고 첫 해를 중앙값 0.20~0.87 s에 찾으며, 재학습한 RoboBallet RL은 29/150·50/150에 그쳤다. 2팔 tabletop TAMP에서는 ScheduleStream보다 첫 해가 46.4% 빠르고(네 과제 합산 기준) 180/180을 풀며, 추가 계산으로 makespan을 42~57% 줄인다.

---

🔍 Ping Review

🔍 Ping — A light tap on the surface. Get the gist in seconds.

로봇 팔 여러 대가 같은 작업 셀을 쓰면 처리량은 늘지만, 문제는 곧 네 겹이 된다. 어떤 팔이 어떤 일을 맡을지(할당), 언제 어떤 순서로 할지(스케줄), 서로 부딪히지 않게 어떻게 움직일지(충돌 회피), 그리고 잡기·놓기·handover·양팔 운반처럼 물체와 팔의 연결 상태를 바꾸는 hybrid 행동을 어떻게 끼워 넣을지다. 기존 접근은 과제 전용 구조에 기대거나(APEX-MR, Fabrica), 느리거나(xECBS, 샘플링 기반 multi-modal planner), 양팔 skill을 계획하지 못하거나(xECBS, VAMP-MR), 학습에 며칠이 드는(RoboBallet RL) 경우가 많다고 저자들은 정리한다.

cuArms의 답은 두 방향에서 계산량을 깎는 것이다. 알고리즘 쪽에서는 로봇별 roadmap + 로봇 간 충돌만 따로 푸는 conflict-based 탐색으로 joint space를 분해한다. 하드웨어 쪽에서는 그 탐색이 매 스텝 요구하는 비싼 기하 검사를 GPU 배치 한두 번으로 몰아넣는다. 핵심은 기존 CPU planner를 GPU로 옮긴 것이 아니라, 처음부터 “재귀적 의사결정은 CPU, 대량 기하 검사는 GPU”로 갈라 설계했다는 점이다.

적용 도메인(Fig. 1). a) 2팔 tabletop 조작(시뮬레이션), b) 8팔 용접(RoboBallet 벤치마크, 시뮬레이션), c) 실기 handover(물체 재파지), d) 양팔 운반. d)의 teaser 이미지는 렌더링이고 실기 운반 장면은 Fig. 8(b)에 있다.
시스템 개요(Fig. 2). 사람이나 에이전트가 로봇·물체·목표·제약을 정의하면 scheduler(ScheduleStream 등)가 할당·순서·배치·grasp·IK를 담은 schedule skeleton을 낸다. cuArms는 ① 로봇별 multi-modal roadmap을 GPU로 만들고 ② 후보 행동 쌍의 충돌을 GPU conflict table로 검사하며 탐색하고 ③ GPU 배치 shortcut으로 다듬는다. 아래 화살표는 다른 skeleton으로 다시 푸는 바깥 루프다.

핵심 방법론:

입력은 schedule skeleton \Sigma=\big(\{(\hat a_j, R_j, x_j)\}_{j=1}^{M}, \prec_\Sigma\big)이다. 각 행동 \hat a_j는 manipulation skill이거나 move이고, R_j는 참여 로봇, x_j=(q_j^{\mathrm{in}}, q_j^{\mathrm{out}}, d_j, \mathcal{B}_j)는 진입·이탈 관절 형상, 최소 실행 시간, 실행 중 팔과 물체를 감싸는 bounding volume이다. \prec_\Sigma는 로봇별 전순서와 로봇 간 선후 제약이다. cuArms는 skeleton이 고정한 행동 사이의 move 궤적과 모든 행동의 시간 구간 [t_j, t'_j]를 함께 정해 다음을 최소화한다.

J(\tau)=w_{mk}\,C_{mk}(\tau)+w_{soc}\,C_{soc}(\tau)+w_{sod}\,C_{sod}(\tau)

C_{mk}는 makespan(가장 늦게 끝나는 로봇의 완료 시각), C_{soc}는 로봇별 완료 시각의 합, C_{sod}는 이동 거리 비용의 합이다. 제약은 t'_j-t_j\ge d_j, \hat a_j\prec_\Sigma\hat a_k \Rightarrow t'_j<t_k, 그리고 매 시각 움직이거나 기다리는 로봇의 기하와 활성 skill의 \mathcal{B}_j가 장애물·다른 로봇과 충돌하지 않는 것이다.

탐색은 LaCAM(lazy DFS)이 joint state \langle v_1,\hat a_1,\dots,v_{|R|},\hat a_{|R|}\rangle 위를 돌고, 각 상태의 다음 상태는 PIBT가 고른다. 차이는 PIBT가 재귀 중에 충돌 검사를 부르지 않고, 미리 GPU에서 만든 후보 쌍 conflict table을 조회만 한다는 것이다.

주요 결과:

• RoboBallet 용접(Table II): cuArms는 4팔·10타깃, 4팔·40타깃, 8팔·40타깃에서 모두 150/150을 풀고 첫 해까지 중앙값 0.20 / 0.41 / 0.87 s. 재학습한 RoboBallet RL은 4팔에서 29/150(19.3%), 50/150(33.3%). 둘 다 푼 에피소드에서 cuArms의 makespan 중앙값이 20.1% / 27.9% 짧다(본문 서술).
• Anytime 개선(Fig. 5): shortcut과 대체 skeleton 탐색으로 첫 makespan 10.61→5.64 s, 31.16→16.56 s(약 47% 감소).
• Tabletop TAMP(Table IV): Hold·Stack·Pack·Unpack(2~4개 큐브, Panda 2대)에서 cuArms 180/180, ScheduleStream 159/180. 첫 해 0.48~2.96 s로 ScheduleStream보다 46.4% 빠르고, Hold를 뺀 세 과제에서 첫 makespan도 짧다. 추가 계산으로 makespan을 42~57% 줄인다.
• 실기(Fig. 8): Flexiv Rizon4s 2대로 전자부품 handover 재파지와 busbar fixture 양팔 운반. 정량 지표 없이 영상으로만 제시된다.

결론:

cuArms의 기여는 “GPU로 빨라졌다”보다 어느 계산을 GPU로 보낼지를 탐색 알고리즘과 함께 다시 짰다는 데 있다. roadmap을 mode와 분리해 재사용하고, PIBT의 재귀를 CPU에 남긴 채 그 재귀가 묻는 질문을 표 한 장으로 미리 답해 둔다. 그 결과 4~8팔, 수십 개 작업에서 1초 안팎의 첫 해와 anytime 개선을 얻었다. 다만 “실시간”은 skeleton이 주어진 뒤의 조정 단계에 대한 말이고, 8개 물체 TAMP처럼 scheduler까지 포함하면 첫 해에 40~50 s가 걸린다(Fig. 7). 핵심 설계 요소의 ablation이 없고, xECBS·VAMP-MR 같은 같은 계열 planner와의 비교는 arXiv 본문이 아니라 프로젝트 페이지의 부록 PDF에만 있다.

---

🔔 Ring Review

🔔 Ring — An idea that echoes. Grasp the core and its value.

한 줄로 시작하면

MAPF 쪽에서는 수천 대 로봇을 몇 초에 조정하는 LaCAM·PIBT 같은 알고리즘이 이미 있다. 그런데 그것들은 격자 위 이동 로봇을 전제로 한다. 정점 하나에 로봇 하나라는 가정 덕분에 충돌 검사는 “그 칸이 비었나”라는 상수 시간 질문이다. 로봇 팔에서는 같은 질문이 “이 팔의 이 edge가 저 팔의 저 edge와 swept volume에서 겹치나”가 되고, 한 후보가 여러 팔과 동시에 겹칠 수 있다. PIBT의 재귀가 이 질문을 수없이 다시 묻는 순간 알고리즘은 느려진다. cuArms의 통찰은 그 질문의 범위가 미리 정해져 있다는 것이다. 각 로봇이 이번 스텝에 고려할 후보 행동 목록 U_i(s)는 탐색 전에 이미 정해지므로, 가능한 모든 쌍의 충돌을 GPU 한 번에 계산해 두면 재귀는 표 조회만 하면 된다. 나머지 설계(로봇별 roadmap, mode mask, skill edge, 배치 shortcut)는 모두 “기하는 크고 규칙적인 배치로, 결정은 작고 재귀적인 CPU 코드로”라는 같은 원칙을 다른 단계에 적용한 것이다.

배경: 멀티암 조작이 왜 어려운가 (§I·§II)

MAPF 계보. PIBT(Okumura et al., 2019)는 각 로봇이 한 스텝 행동만 정하되 우선순위를 상속하며 충돌을 해소하는 빠른 알고리즘이다. 대신 불완전하고 livelock에 빠질 수 있다. LaCAM(Okumura, 2023)은 PIBT를 lazy successor 생성기로 삼아 joint configuration space 위의 완전한 DFS에 넣었다. db-LaCAM은 이를 kinodynamic 이동 로봇으로 넓혔다. 저자들은 LaCAM 계열이 이동 로봇에서만 보여졌다고 지적한다. 팔은 그래프 구축과 로봇 간 충돌 검사가 훨씬 비싸기 때문이다.

멀티암 계획 계보. 샘플링 기반(dRRT*)이나 MAPF 기법(xECBS)은 단일 query의 start-to-goal 계획에 머문다. Hartmann et al.과 Shome & Bekris는 이를 장기 pick-and-place·handover로 넓혔지만 충돌 검사가 지배적 병목이다. TAMP 쪽에서는 ScheduleStream(Garrett & Ramos, 이 논문의 공저자들)이 temporal durative action 위에서 skeleton을 찾지만 충돌 없는 motion을 rejection sampling으로 뽑아, 경로가 얽히면 비효율적이다. APEX-MR·Fabrica 같은 응용 시스템은 과제 구조를 이용해 확장하지만 새 과제로 일반화하기 어렵다.

가속 계획 계보. CPU SIMD(VAMP)나 GPU(cuRobo, JAX 기반 최적화) 가속이 있고, cuTAMP는 GPU로 여러 task skeleton을 병렬 평가한다. 멀티암에서는 VAMP-MR이 AVX2로 충돌 검사를 벡터화했지만 알고리즘은 그대로라 충돌 검사가 여전히 병목이라고 저자들은 쓴다.

저자들이 정리한 비교표(Table I)를 옮기면 다음과 같다.

방법	병렬화	Skill 지원	Conflict-based
xECBS	✗	✗	✓
Hartmann et al.	✗	✓	✗
APEX-MR	✗	✓	✗
VAMP-MR	CPU SIMD	✗	✓
ScheduleStream	GPU	✓	✗
cuArms	GPU	✓	✓

이 표는 저자들이 고른 세 축에서 cuArms만 모든 칸을 채운다는 것을 보여 준다. 다만 이 다섯 방법 중 arXiv 본문 실험에서 실제로 비교되는 것은 ScheduleStream 하나다(RoboBallet RL은 표에 없다). 나머지 넷과의 비교는 프로젝트 페이지 부록에만 있다. 이 점은 아래 실험·비판 절에서 다시 다룬다.

문제 정식화 (§III)

작업 공간. n대의 팔 R=\{r_1,\dots,r_n\}, 정적 장애물, 움직일 수 있는 강체 물체 집합 \mathcal{O}. 로봇마다 관절 위치·속도 한계를 갖는 configuration space \mathcal{C}_i와 알려진 base 변환이 있다. 로봇·그리퍼·손에 든 물체는 collision sphere의 합집합으로 모델링한다(cuRobo와 같은 방식).

Mode. mode m은 모든 물체의 discrete grasp·attachment·placement 상태다. mode와 로봇 형상이 합쳐져 시스템 상태가 완전히 정해진다. mode는 manipulation skill만 바꿀 수 있다.

Skill과 move. skill a_j는 한 팔 또는 두 팔이 참여하는 파라미터화된 접촉 상호작용이다. 파라미터 x_j=(q_j^{\mathrm{in}}, q_j^{\mathrm{out}}, d_j, \mathcal{B}_j)와 mode 전이 함수 m^{\mathrm{out}}=T_{a_j}(m^{\mathrm{in}})를 갖는다. move는 고정된 mode 안에서 한 로봇이 충돌 없이 움직이는 것이고, 목표 관절 형상은 직접 주거나 IK로 샘플링한다.

Skeleton과 해. skeleton은 위의 \Sigma이고, 해는 move 궤적 \{\xi_j\}와 행동별 구간 \{[t_j,t'_j]\}로 이뤄진 시간 계획 \tau다. 선후 관계가 없는 서로 다른 로봇의 행동은 비동기로 실행될 수 있다. 로봇은 행동 사이에 현재 형상에서 기다릴 수 있고, 기다리는 동안에도 같은 충돌 제약을 지킨다.

네 도메인의 schedule skeleton 예(Fig. 3). a) 각 팔이 move와 단일 팔 pick/place를 번갈아 한다. b) 각 팔이 move와 weld를 반복하고 로봇 간 선후 제약이 없다. c) R1의 Handover #A와 R2의 Receive #A가 선후 제약(빨간 화살표)으로 묶인 두 단일 팔 skill이다. d) Pick·Bimanual Carry·Place가 모두 양팔 skill이라 두 팔이 진입 형상에 모두 도착해야 시작된다.

비용. 앞의 J(\tau)다. 거리 비용 C_{sod}는 관절 공간 경로 길이, task space 경로 길이, collision sphere의 부피 가중 이동 거리, 또는 그 조합 중 하나로 잴 수 있다고 적혀 있다. 그런데 본문 실험에서 어떤 거리 정의와 어떤 가중치 (w_{mk},w_{soc},w_{sod})를 썼는지는 나오지 않는다. 부록 D의 Python API 예시에는 Cost(makespan=1.0, completion=1.0, distance=0.1, metric="joint")라는 기본값이 보이지만, 본문 실험이 이 값을 썼는지는 확인되지 않는다.

이 정식화에서 눈여겨볼 점은 skeleton이 할당·순서·skill 파라미터를 모두 고정한다는 것이다. cuArms 자체는 “누가 무엇을”을 정하지 않는다. 그 몫은 §V의 상위 scheduler에 있다. 그래서 cuArms의 성능을 읽을 때는 항상 어떤 scheduler가 skeleton을 줬는지를 같이 봐야 한다.

방법 상세 1: Multi-modal roadmap (§IV-A)

로봇별 PRM. 로봇마다 정적 환경과 충돌하지 않는 노드·edge로 probabilistic roadmap \mathcal{G}_i를 GPU 메모리에 만든다. 샘플링이 병렬화되기 쉽고, 기하를 캐시해 skeleton이 바뀌어도 재사용할 수 있어 GPU 배치에 잘 맞는다.

Mode-validity mask. 물체가 움직이면 roadmap의 일부 노드·edge가 막힌다. cuArms는 roadmap을 다시 만들지 않고, skeleton이 만들어 낼 수 있는 mode m마다 유효한 노드·edge를 표시하는 mask v_i^m를 만든다. GPU는 캐시된 로봇 형상을 mode별 물체 배치와, 손에 든 물체를 환경·다른 물체와 배치로 검사한다. 정기구학과 로봇-환경 충돌 결과는 mode 간에 재사용되고, 바뀌는 로봇-물체 상호작용만 새로 계산한다. 저자들의 근거는 “물체는 균일 샘플 roadmap의 유효성에 드문드문 영향을 준다”는 관찰이다.

Skill node·edge. skill 파라미터 x_j마다 q_j^{\mathrm{in}}과 q_j^{\mathrm{out}}을 노드로 넣고, 둘을 skill 실행과 mode 전이를 나타내는 edge로 잇는다. 이 노드들은 skeleton에서 이웃한 move의 시작·목표 노드가 된다. skill edge의 충돌 검사는 \mathcal{B}_j로 한다. 실행 시간은 최대 edge 간격의 정수배로 올림해 roadmap motion과 동기화한다. 그래서 skill 실행과 연결 motion의 계획이 모두 “\mathcal{G}_i 위의 유효한 edge 전이 찾기”로 통일된다.

Heuristic. 노드와 현재 행동마다 cost-to-go h_i[v,\hat a]를 계산한다. 단위 비용으로, 각 행동의 목표 집합에서 mode mask 없이 base roadmap 위를 거꾸로 Dijkstra로 돌리고, 목표 도달 후 남은 motion·skill 비용 추정을 더한다. skeleton의 선후 제약 때문에 다음 행동이 막힌 로봇을 충돌 없는 home 형상으로 비켜 세우기 위한 cost-to-home heuristic도 따로 계산한다.

mask 없이 heuristic을 계산하는 선택은 속도를 위한 것으로 보인다. 그 대가로 물체가 길을 막는 mode에서는 heuristic이 실제보다 낙관적이 된다. 논문은 이 효과를 따로 분석하지 않는다.

방법 상세 2: GPU 가속 conflict-driven 탐색 (§IV-B)

원래 LaCAM·PIBT. LaCAM은 lazy DFS다. 각 탐색 노드에서 다음 joint state 하나를 PIBT로 만들고, 그 노드에 “어떤 로봇이 어떤 행동을 해야 한다”는 제약 queue를 붙여 다음에 같은 노드를 다시 방문하면 다른 successor를 만든다. PIBT는 동적 우선순위 내림차순으로 로봇이 행동을 고르게 하고, 원하는 정점에 아직 행동이 정해지지 않은 로봇이 있으면 그 로봇에 우선순위를 상속해 재귀적으로 비키라고 요청한다. 비킬 수 없으면 backtrack한다.

2D 물체 교환 toy 예(Fig. 4). R1은 A를, R2는 B를 서로의 자리로 옮겨야 한다. (a) 처음엔 두 팔이 서로를 막는다. (b) 우선순위가 높은 R2가 B를 집도록 R1을 밀어낸다. (c) 우선순위가 뒤집혀 B를 든 R2가 물러나고 R1이 A를 집는다. (d) 두 물체가 목표에 놓인다.

이 예에서 저자들은 두 대안이 왜 안 되는지 말한다. 팔마다 독립으로 motion을 계획하고 나중에 retiming하면 이 deadlock은 풀리지 않는다. 순차 계획은 로봇 간 행동 순서를 skeleton에 명시적으로 박아야 한다. PIBT는 이 양보 순서를 탐색 중에 스스로 만든다.

cuArms의 확장. 원래 LaCAM은 장기 manipulation의 과제 진행도를 추적하지 않는다. cuArms는 roadmap 노드 v_i에 현재 symbolic 행동 \hat a를 붙이고, 탐색 노드 s가 \langle v_1,\hat a_1,\dots,v_{|R|},\hat a_{|R|}\rangle를 저장하게 한다. joint state가 현재 mode와 각 로봇의 다음 행동 허용 여부를 결정한다. 각 상태에서 로봇마다 고정된 후보 목록 U_i(s)(motion, wait, skill)를 펼치고 다음 키로 정렬한다.

\mathrm{key}(u)=\begin{cases}(0,\ h_i[s'_i]) & u\ \text{가 skill}\\ (1,\ h_i[s'_i]) & u\ \text{가 motion 또는 wait}\end{cases}

즉 skill이 가능하면 항상 먼저 시도하고, 그다음 cost-to-go가 낮은 행동 순이다. skill은 참여 로봇이 모두 진입 노드에 있고 막는 선후 제약이 없을 때만 열린다. skill을 끝내면 로봇이 이탈 노드로 가고 행동 단계가 넘어가며 mode 전이가 적용된다. 양팔 skill은 PIBT와 LaCAM 양쪽에서 참여 로봇의 행동을 함께 commit하고 함께 제약한다.

핵심: conflict table을 먼저 만든다. Alg. 1의 15행이 이 논문의 중심이다.

C_s=\mathrm{GPUConflictTable}\big(\{U_i(s)\}_{i\in R},\{\mathcal{G}_i\}\big)

모든 로봇 쌍의 모든 후보 쌍에 대해, motion은 시간 정렬한 로봇 궤적으로, skill은 감싸는 부피 \mathcal{B}_j로 충돌을 배치 검사해 Boolean 표를 만든다. 그다음 PIBT는 우선순위 상속과 backtrack 동안 이 표만 조회한다(17행). 재귀적 충돌 검사를 GPU에서 그대로 돌리면 kernel launch와 동기화가 반복돼 병렬성이 죽는데, 이 설계는 재귀 제어 흐름(CPU)과 배치 계산(GPU)을 분리해 그 오버헤드를 없앤다고 저자들은 설명한다. 선후 제약 때문에 막힌 move가 있으면 cost-to-home heuristic으로 비키는 motion을 후보 순위에서 우선한다.

프로젝트 페이지 “How cuArms Works”(4.3 MB, 원 URL 참조). 2D 예제에서 로봇별 roadmap, GPU conflict check를 곁들인 conflict-driven 탐색, 배치 shortcut이 차례로 나온다.

알고리즘 흐름(Alg. 1 요약). 1~3행: 로봇마다 roadmap과 heuristic(GPU). 4~5행: 초기 탐색 노드를 DFS 스택에 넣는다. 6~19행: 스택 맨 위 노드에서 모든 행동이 끝났으면 backtrack해 해를 얻고, 제약 queue가 비었으면 pop한다. 아니면 로봇별 후보를 펼쳐 정렬하고(13~14행), GPU conflict table을 만들고(15행), 제약 하나를 꺼내 확장 제약을 queue에 넣고(16행), PIBT로 successor를 만들어 새 노드면 push한다(17~19행). 22행: 해가 있으면 배치 refinement로 넘긴다.

보장에 대해. 논문은 cuArms의 완전성이나 최적성을 정리로 주장하지 않는다. 관련 서술은 두 가지다. LaCAM이 “complete depth-first search”라는 배경 설명, 그리고 RoboBallet이 “neither completeness nor formal safety guarantees”를 제공한다는 대비다. 대비 문장은 cuArms가 그런 보장을 갖는다는 인상을 주지만, cuArms의 탐색은 유한한 roadmap 위에서 돌기 때문에 완전성이 있다면 그 roadmap에 상대적이다(필자 해석). 안전성도 collision sphere 모델과 discrete한 간격의 edge 검사에 상대적이다. 부록 D의 validator는 0.02 rad 간격 검사와 6 mm 침투 허용치를 쓴다.

방법 상세 3: Anytime refinement (§IV-C)

첫 해는 거친 roadmap과 LaCAM 계열의 최적성 부재 때문에 차선이다. 멀티암 shortcut 자체는 저자 Huang et al.의 선행 연구가 있지만, 팔이 motion과 skill을 비동기로 섞어 실행하는 장기 계획에서는 한 팔의 경로를 줄이다가 다른 팔의 motion이나 skill과 충돌을 만들면 안 된다는 점이 까다롭다.

절차는 두 단계 배치다. ① 각 move 궤적마다 관절 공간 직선 보간 shortcut 후보를 유한 개 열거하고, 정적 환경과 현재 mode의 물체에 대해 배치 검사한다. ② 유효한 단일 팔 shortcut들에서 멀티암 shortcut을 큰 배치로 무작위 샘플링한다. 멀티암 shortcut은 다른 팔 궤적을 그대로 두는 단일 팔(prioritized) shortcut이거나, 두 개 이상의 동시 단일 팔 shortcut을 묶은 composite shortcut이다. 이들의 로봇 간 충돌을 병렬 검사한 뒤, 겹치지 않는 shortcut을 비용 개선 내림차순으로 탐욕적으로 합쳐 원 궤적을 교체한다.

방법 상세 4: Schedule-then-coordinate TAMP (§V)

cuArms 위에 상위 scheduler를 얹은 계층이다. scheduler는 할당·스케줄·mode(배치·grasp) 평가에 강하지만 촘촘한 협응 motion에는 약하다. 반대로 고정 skeleton 아래 motion만 최적화하면 불필요한 양보와 대기를 강요하는 나쁜 할당이나 skill 파라미터를 고칠 수 없다. 그래서 scheduler가 후보 skeleton을 내고 cuArms가 그것을 협응 궤적으로 grounding한다. scheduler는 ScheduleStream 같은 일반 temporal planner, 도메인 전용 최적화, 고정 순서 조립 계획 중 무엇이든 될 수 있다. 모든 후보에서 실패하면 scheduler로 backtrack해 skeleton을 더 받는다. 실제로는 후보 배치를 미리 만들어 backtrack을 줄인다. mode가 공유되면 GPU 메모리의 같은 roadmap을 재사용하고, 새 mode가 생기면 base roadmap은 두고 mask만 갱신한다.

직관: 질문 목록이 정해져 있으면 답을 미리 계산해 둘 수 있다

PIBT를 사무실 복도에 비유하면, 로봇은 사람이고 정점은 복도 칸이다. 내가 가려는 칸에 누가 서 있으면 그 사람에게 “비켜 줄 수 있나요”라고 묻고, 그 사람은 다시 자기 앞사람에게 묻는다. 이동 로봇 MAPF에서는 “누가 서 있나”를 보는 데 비용이 거의 없다. 팔에서는 이 확인이 “두 팔의 7자유도 swept volume이 겹치나”라는 계산이 되고, 한 사람이 여러 사람과 동시에 겹칠 수 있다.

cuArms는 질문을 받기 전에 답을 준비한다. 각 로봇이 이번 스텝에 고려할 후보는 U_i(s)로 고정돼 있으니, \sum_{i<k}|U_i(s)|\cdot|U_k(s)|개의 쌍을 GPU가 한 번에 검사하고 표로 넘긴다. 이 계산은 PIBT가 실제로 묻는 것보다 많은 쌍을 검사할 수 있다. 하지만 GPU에서는 “적게 여러 번”보다 “많이 한 번”이 싸다. Table III가 이 거래를 수치로 보여 준다. 4팔에서는 LaCAM 탐색과 PIBT를 합쳐 7~13 ms에 불과하고, conflict table 구축이 22~66 ms다.

같은 원칙이 roadmap에도 적용된다. 물체가 roadmap에 드문드문 영향을 준다는 관찰 덕분에, mode마다 roadmap을 새로 만드는 대신 “이 mode에서는 이 노드가 막혔다”는 bit mask만 계산하면 된다. 정기구학과 로봇-환경 충돌은 한 번만 계산한다.

이 원칙의 한계도 같은 그림에서 보인다. 표의 크기는 로봇 쌍 수에 비례해 자란다. 4팔→8팔에서 쌍은 6→28(4.67배)이고, 40타깃 conflict table 시간은 65.94→277.46 ms(4.21배)로 거의 같은 비율로 늘었다(필자 계산). 8팔에서는 충돌 검사가 첫 해 시간의 50.2%로 다시 절반을 차지한다. GPU가 병목을 없앤 것이 아니라 팔 수의 제곱으로 자라는 병목을 상수배 줄인 것에 가깝다.

실험 설정 (§VI)

세 질문을 던진다. 첫 해를 얼마나 빨리 찾는가, 추가 계산으로 품질이 얼마나 오르는가, 작업과 로봇 수에 어떻게 확장되는가. 지표는 첫 해까지 시간 t_0, 첫 makespan J_0, 최종 makespan J_f다. 별도 표기가 없으면 시뮬레이션 설정마다 15개 seed를 쓰고 그림은 중앙값과 IQR을 보인다. 모든 결과는 NVIDIA RTX Pro 6000 GPU 워크스테이션에서 측정했다.

본문에 없는 설정값도 짚어 둔다. roadmap 노드 수, edge 시간 간격, U_i(s)의 후보 수, shortcut 배치 크기, 비용 가중치는 본문에 적혀 있지 않다. 부록 D의 API 예시에 Planner(scene, seed=0, roadmap_nodes=1024)가 나오지만 이것이 본 실험의 값인지는 알 수 없다.

실험 1: RoboBallet, 다수 팔과 장기 과제 (§VI-A)

설정. RoboBallet(Lai et al., Science Robotics 2025)은 4대 또는 8대 팔이 장애물이 있는 좁은 셀에서 10개 또는 40개 spot welding 타깃에 도달하는 벤치마크이자 GNN+RL 방법이다. RoboBallet은 2.5 cm·15° 도달 허용치를 쓴다. cuArms 쪽 시스템은 탐욕적 scheduler(매 라운드 완화된 이동 거리 비용으로 Hungarian matching을 해 로봇마다 타깃 하나씩 배정)와 cuArms를 결합한다. 각 용접 타깃의 관절 목표는 GPU IK(cuRobo)로 배치 샘플링해 sub-mm 정밀도를 맞춘다. 에피소드마다 바뀌는 것은 타깃뿐이라 base roadmap을 미리 만들어 재사용하고, 계획 중에는 RRT-guided steering으로 타깃을 base roadmap에 잇는다. 첫 skeleton을 풀면 backtrack해 타깃을 다시 샘플링한 대체 skeleton을 제안하며, 총 16개 skeleton을 평가한다. skeleton당 refinement는 10타깃 2 s, 40타깃 6 s다. RL 정책은 저자들이 처음부터 재학습했다(본문 표현으로 약 2일).

타깃	로봇	방법	성공	t_{\mathrm{offline}} (s)	t_0 (s)	J_0 (s)	J_f (s)
10	4	cuArms	150/150	0.81	0.20	10.61	5.64
40	4	cuArms	150/150	0.81	0.41	31.16	16.56
40	8	cuArms	150/150	1.74	0.87	25.35	14.87
10	4	RL	29/150	1.6×10⁵	0.11	–	6.00
40	4	RL	50/150	2.2×10⁵	0.42	–	24.25

Table II 옮김. t_{\mathrm{offline}}은 cuArms의 base roadmap 구축 시간 중앙값과 RL의 학습 시간이다. RL의 t_0는 총 추론 시간이다. 150 = 에피소드 10개 × seed 15개로 읽힌다(본문 “each with 10 episodes”와 15 seed 설정에서의 필자 해석).
RoboBallet에서의 schedule 탐색과 refinement(Fig. 5). 가로축은 첫 해 이후 추가 시간, 세로축은 makespan. 주황 점선은 RL의 makespan(RL이 푼 에피소드만의 중앙값)이다. 그림에서 읽으면 10타깃에서는 십여 초 뒤 RL 선 아래로 내려가고, 40타깃에서는 수 초 만에 RL보다 짧아진다.

결과. 첫 해까지 중앙값 0.20 s(10타깃), 0.41 s(40타깃). base roadmap은 로봇당 0.22 s 미만으로 미리 만든다(0.81 s / 4대 = 0.20 s, 1.74 s / 8대 = 0.22 s, 필자 계산). shortcut과 대체 skeleton 탐색으로 첫 makespan을 두 설정 모두 약 47% 줄인다(10.61→5.64는 46.8%, 31.16→16.56은 46.9%, 필자 검산). 재학습 RL은 10타깃 에피소드의 19.3%, 40타깃의 33.3%만 완수한다. 예측 행동이 충돌을 피하지 못해 deadlock에 빠지거나 허용치 안에 도달하지 못해서다. 둘 다 푼 에피소드에서는 cuArms의 makespan 중앙값이 20.1%(10타깃), 27.9%(40타깃) 짧다.

프로젝트 페이지 “8 arms · 40 targets” 클립(1.3 / 1.7 MB, 원 URL 참조). 왼쪽 cuArms(페이지 표기: 계획 9.26 s, makespan 9.7 s), 오른쪽 RoboBallet RL의 20초 발췌. 8팔 RL 롤아웃이 페이지에는 있지만 Table II에는 8팔 RL 행이 없다.

로봇 수를 두 배로. 8팔에서도 1초 안에(0.87 s) 해를 찾고 최종 makespan 중앙값은 4팔 대비 10.2% 짧다(16.56→14.87 s). 첫 makespan은 18.6% 짧다(31.16→25.35 s, 필자 계산). 팔을 두 배로 늘려 얻은 개선이 10%대라는 것은 작업 공간이 좁아 팔끼리 서로를 기다리는 시간이 늘었다는 뜻으로 읽힌다(필자 해석, 논문은 이 비율을 해석하지 않는다).

시간 분해(Table III). 첫 해까지의 시간을 단계별로 쪼갠 표다.

단계 (ms, 중앙값)	4팔 · 10	4팔 · 40	8팔 · 40
Greedy scheduler	0.59	5.12	3.06
Roadmap construction (타깃 연결)	98.70	155.39	271.17
Heuristics	47.68	120.81	146.44
Candidate expansion & sort	8.24	24.24	32.06
Conflict table	22.46	65.94	277.46
LaCAM search & PIBT	6.81	13.42	19.51
충돌 검사 비중 (첫 해 시간 대비)	18.1%	24.7%	50.2%

표에서 두 가지가 보인다. 첫째, 탐색 자체는 거의 공짜다. LaCAM과 PIBT를 합쳐 단계 합의 2.6~3.7%다(필자 계산, 중앙값은 더해지지 않으므로 근사). 시간의 대부분은 roadmap 연결과 heuristic(단계 합의 56~79%)이다. 저자들도 새 타깃을 base roadmap에 잇는 단계가 좁은 통로 같은 장애물 때문에 반복 샘플링과 steering을 요구해 큰 병목이라고 인정한다. 둘째, 8팔에서 conflict table이 가장 큰 항목이 된다(277.46 ms). 앞의 직관 절에서 본 대로 로봇 쌍 수에 비례하는 증가다.

블로그의 RoboBallet 리뷰와 대조. 이 블로그의 RoboBallet 리뷰에 정리한 원 논문 수치와 나란히 놓으면 RL 베이스라인을 읽는 데 필요한 맥락이 생긴다.

• 원 논문은 학습이 문제 크기에 따라 6~24시간이면 태스크 해결률 95%에 이르고, 이후 2~6일 동안 품질이 계속 오른다고 보고했다. 평가 셀에서도 40개 중 약 38개 태스크가 풀렸다. cuArms가 보고한 RL 성공률 19.3%/33.3%는 에피소드 단위 완수율(모든 타깃을 허용치 안에 도달)이라 원 논문의 태스크 단위 해결률과 같은 지표가 아니다. 40개 중 38개를 풀어도 에피소드는 실패다. 두 수치가 모순되지는 않지만, 독자가 “RoboBallet은 20~30%만 성공한다”로 읽으면 틀린다.
• 재학습 시간은 1.6\times10^5 s(약 44시간)와 2.2\times10^5 s(약 61시간)다(필자 환산). 원 논문이 말한 품질 개선 구간(2~6일)의 앞쪽 끝이다. 학습 부족 가능성을 배제할 수 없지만 논문은 학습 곡선을 보이지 않는다.
• 원 논문의 대표 설정은 8팔·40태스크인데, Table II의 RL 행은 4팔뿐이다. 8팔 RL 롤아웃 영상이 프로젝트 페이지에 있으므로 학습은 한 것으로 보이지만 수치는 없다.
• 10타깃 RL 성공률(19.3%)이 40타깃(33.3%)보다 낮다. 직관과 반대인데 논문은 설명하지 않는다.
• RL은 2.5 cm·15° 허용치를 쓰고 cuArms는 sub-mm IK 목표를 쓴다. 정밀도에서는 RL에 유리한 비대칭이다. 반면 RoboBallet은 태스크마다 0.5 s dwell을 넣는데, cuArms의 weld skill 지속 시간 d_j가 같은지는 적혀 있지 않다. makespan 비교의 공정성을 판단할 정보가 부족하다.

실험 2: Multi-arm TAMP, tabletop (§VI-B)

설정. Panda 2대로 큐브 2~4개를 들기(Hold)·쌓기(Stack)·담기(Pack)·꺼내기(Unpack). Pack·Unpack은 6개·8개도 평가한다. cuArms와 ScheduleStream 베이스라인 모두 ScheduleStream의 symbolic planner로 skeleton을 탐색하고 grasp·배치·IK를 샘플링하며, 상위 탐색 예산은 총 60 s다. 차이는 motion이다. ScheduleStream은 팔마다 경로를 따로 계획한 뒤 충돌을 피하도록 retiming하고, cuArms는 skill과 move를 함께 조정한다. cuArms는 다른 샘플 파라미터를 가진 skeleton을 최대 16개 탐색하고, skeleton당 refinement는 Pack 2 s, 나머지 1 s다. cuArms는 makespan과 경로 거리를 섞은 가중 목적함수를 최적화한다.

과제	cuArms 성공	t_0 (s)	J_0 (s)	J_f (s)	ScheduleStream 성공	t_0 (s)	J_0 (s)
Hold	45/45	0.48	5.46	2.37	44/45	1.75	3.74
Stack	45/45	2.26	12.84	6.67	38/45	4.02	16.11
Pack	45/45	2.96	12.02	6.96	38/45	4.54	17.45
Unpack	45/45	1.60	11.50	6.55	39/45	3.30	13.25

Table IV 옮김(물체 2~4개). 45 = 물체 수 3종 × seed 15개로 읽힌다(필자 해석). ScheduleStream은 refinement가 없어 J_f 열이 없다.

헤드라인 수치 검산. 본문의 “46.4% 빠르다”는 네 과제의 t_0를 합산해 비교한 값이다. cuArms 합 7.30 s, ScheduleStream 합 13.61 s로 1-7.30/13.61=46.4\%가 정확히 나온다(필자 검산). 과제별로 보면 편차가 크다.

과제	t_0 감소	J_0 차이 (cuArms vs SS)	J_0\to J_f 감소
Hold	72.6%	+46.0% (cuArms가 김)	56.6%
Stack	43.8%	−20.3%	48.1%
Pack	34.8%	−31.1%	42.1%
Unpack	51.5%	−13.2%	43.0%

Table IV 값으로 필자가 계산. 본문의 “42~57%”는 마지막 열의 범위와 일치한다.

본문은 Hold를 예외로 명시한다(“better initial makespan except for the Hold task”). 들고만 있으면 되는 단순 과제에서는 독립 계획 + retiming이 오히려 짧은 첫 해를 준다는 뜻이다. cuArms는 refinement 뒤에야(2.37 s) ScheduleStream의 3.74 s를 이긴다.

Tabletop refinement(Fig. 6). 파란 점선이 ScheduleStream의 첫 makespan, 보라 실선이 cuArms의 makespan 중앙값과 IQR이다. 캡션은 “가중 목적함수가 개선되는 동안 makespan은 늘 수 있다”고 적는다. 이 그림이 그리는 것은 makespan이지 최적화 대상인 J가 아니다.

프로젝트 페이지 “Stack four objects” 클립(0.4 / 0.6 MB, 원 URL 참조). 왼쪽 cuArms(페이지 표기: 계획 4.67 s, makespan 10.2 s), 오른쪽 ScheduleStream(계획 3.66 s, makespan 20.15 s). 같은 skeleton을 최적화한다. 이 한 사례에서는 계획 시간이 ScheduleStream 쪽이 더 짧다.

물체 수 확장.

물체 수에 따른 확장(Fig. 7). (a)(c) 첫 makespan, (b)(d) 첫 해까지 시간. ScheduleStream은 8개 Pack에서 해를 하나도 찾지 못해 점이 없다. cuArms도 8개에서 첫 해까지 Pack 약 40 s, Unpack 약 50 s가 걸린다(그림에서 읽은 근사치).

cuArms는 8개까지 해를 찾고 makespan의 증가 기울기가 ScheduleStream보다 완만하다. 하지만 (b)(d)의 세로축이 보여 주듯, 물체가 6~8개가 되면 첫 해까지의 시간이 수십 초로 늘어난다. 프로젝트 페이지의 클립 메타데이터는 이 시간의 대부분이 scheduler 몫임을 보여 준다. Pack 8개는 scheduling 39.34 s + 해 4.20 s, Unpack 8개는 49.41 s + 4.22 s로 적혀 있다. 초록의 “real-time initial solutions”는 skeleton이 주어진 뒤 cuArms의 조정 단계에 대한 말이다.

프로젝트 페이지 “Pack · 8 objects” 클립(1.3 MB, 원 URL 참조). 페이지 표기로 scheduling 39.34 s, 해 4.20 s, makespan 약 17.7 s.

실험 3: 실기 전자부품 조립 (§VI-C)

Flexiv Rizon4s 팔 2대로 두 과제를 한다. (a) handover로 부품을 손에서 손으로 넘겨 방향을 바꾸는 재파지, (b) busbar fixture를 두 팔이 함께 잡아 서버 트레이로 옮기는 양팔 운반이다. GPU 가속 skill sampler가 handover 자세나 운반 궤적을 하드코딩하지 않고 제약을 만족하는 자세를 샘플링하고, ScheduleStream 기반 symbolic planner가 skeleton을 만든다. cuArms는 카메라 마운트를 피하는 접근 motion을 포함한 협응 계획을 낸다.

실기 양팔 전자부품 조립(Fig. 8). 왼쪽 세 장 (a) Handover: 자동 샘플링·최적화한 handover 자세로 부품 재파지. 오른쪽 세 장 (b) Bimanual carry: 충돌 없는 접근, 협응 grasp, busbar fixture를 서버 트레이로 운반.

프로젝트 페이지 실기 클립(4.6 / 5.5 MB, 원 URL 참조). 왼쪽 Bimanual Handover, 오른쪽 Bimanual Carry.

이 절에는 시행 횟수, 성공률, 계획 시간, 실행 시간이 하나도 없다. 본문은 “Videos of successful execution are available”로 끝난다. 실기 실험은 시스템이 실제 하드웨어로 이어진다는 존재 증명이고, 성능 평가는 아니다.

부록 (프로젝트 페이지 PDF): 같은 계열 planner와의 비교

arXiv v1은 본문 8쪽뿐이고 부록이 없다. 프로젝트 페이지에는 6쪽짜리 Appendix PDF가 따로 있고, 여기에 Table I의 다른 방법들과의 비교가 들어 있다. 그림 번호는 본문에서 이어진다(Fig. 9~14, Table V~IX). 아래는 그 부록을 읽은 것이다.

A. MRMG 장기 멀티암 조립

Hartmann et al.의 Multi-Modal Multi-Robot Multi-Goal 벤치마크. UR5 2~4대가 부품 7~24개를 집어 놓아 나선 탑·트러스·큐브를 만든다. 순서·할당·관절 목표는 원 벤치마크대로 skeleton에 고정한다. 비용 J는 경로의 각 스텝에서 가장 많이 움직인 팔의 관절 거리에 모든 팔 관절 거리의 1%를 더한 합이다(원 벤치마크 정의). 베이스라인은 벤치마크와 함께 발표된 prioritized planner와 AIT* 결과(25회 중앙값, 500~1000 s 계획)다. cuArms의 t_0에는 roadmap 구축이 포함된다.

과제	로봇	부품	cuArms t_0 / J_0 / J_f	Prioritized t_0 / J_0 / J_f	AIT* t_0 / J_0 / J_f
Spiral-2	2	7	0.32 / 85.0 / 44.4	14.14 / 47.7 / 46.6	2.02 / 110.7 / 43.9
Spiral	4	15	1.29 / 202.2 / 88.9	196.74 / 122.9 / 106.5	31.00 / 311.5 / 94.0
Truss	3	14	1.07 / 144.0 / 68.9	24.68 / 89.3 / 76.8	3.77 / 211.9 / 66.4
Cube	4	24	7.53 / 336.3 / 129.5	117.86 / 161.5 / 135.6	59.44 / 423.7 / 119.8

부록 Table V 옮김. cuArms는 15 seed 중앙값, refinement 10/30/30/60 s.
MRMG 비용-계획 시간 곡선(부록 Fig. 9). 점선은 베이스라인이 발표한 첫 해와 최종 해를 잇는다(중간 곡선이 아니다). 오른쪽 위는 완성된 구조물과 팔의 최종 형상.

cuArms는 15 seed 모두 성공하고, 첫 해가 AIT*보다 3.5~24배, prioritized보다 16~152배 빠르며, 첫 해 비용이 AIT*보다 21~35% 낮다. prioritized는 첫 해 비용이 더 낮지만 14~197 s가 걸린다. 최종 비용은 prioritized보다 4.5~16.5% 낮고 AIT*의 8% 이내다(Spiral에서는 더 낮다). 모두 Table V로 필자가 검산해 일치를 확인했다. 단, 베이스라인 수치는 다른 하드웨어에서 발표된 값이다.

B. xECBS one-shot 멀티암 motion planning

Panda 팔 2~8대의 6개 장면(원형 배치 2·4·6·8대, Bin Picking 4대, Shelves 8대), 장면당 50 query. xECBS·ECBS·prioritized는 저자들이 발표한 결과(Intel Core i9-12900H, 60 s 제한)를 쓰고, VAMP-MR은 저자들이 Intel Core Ultra 9 285K에서 직접 돌렸다. cuArms의 roadmap 구축(장면당 2.9~16.5 s)은 t_0에서 제외된다.

장면	cuArms 성공 / t_0 / J_f	xECBS 성공 / t_0 / J_f	VAMP-MR (CBS-MP) 성공 / t_0 / J_f
Bin Picking	100% / 0.083 / 26.5	96% / 3.49 / 23.5	32% / 0.080 / 24.1
Shelves	38% / 0.24 / 44.8	84% / 7.98 / 40.3	6% / 0.49 / 33.4
Two Robots	100% / 0.026 / 12.5	100% / 0.092 / 12.6	96% / 0.005 / 12.6
Four Robots	100% / 0.052 / 19.3	98% / 0.395 / 19.4	84% / 0.033 / 19.6
Six Robots	100% / 0.083 / 33.7	92% / 3.49 / 31.3	58% / 0.30 / 33.4
Eight Robots	98% / 0.13 / 41.9	80% / 9.44 / 40.9	32% / 2.51 / 39.4

부록 Table VI 일부 옮김(t_0 s, J_f rad, 각 방법이 푼 query에 대한 중앙값). ECBS·Prioritized·VAMP-MR(RRT) 열은 생략. 원 표 기준 Shelves 최고 성공률은 xECBS다.
xECBS 벤치마크 비용-계획 시간 곡선(부록 Fig. 10). 장면 성공률 50% 이상(Shelves는 30%)인 방법만 그린다. 그래서 (b) Shelves의 cuArms 곡선은 38%의 푼 query만 대표한다.

cuArms는 6개 중 5개 장면에서 가장 많은 query를 풀고, 첫 해를 중앙값 26~243 ms에 찾는다(공통으로 푼 query에서 xECBS보다 3.5~57배 빠름). 최종 비용은 2·4대에서 xECBS의 1% 이내, 나머지에서 6~13% 높다. 열린 2·4대 장면의 쉬운 query에서는 VAMP-MR이 더 빠르다(0.2~33 ms). 저자들은 이 경우 cuArms 시간의 대부분이 start·goal을 roadmap에 잇는 query별 준비이고 탐색은 약 20%뿐이라고 설명한다.

가장 중요한 음성 결과는 Shelves다. 8대가 한 선반으로 손을 뻗는 장면에서 cuArms는 38%, xECBS는 84%다. 저자들의 진단은 정직하다. PIBT는 한 번에 한 로봇을 밀어내며 충돌을 푸는데, 한 팔을 비키게 하려면 다른 여러 팔을 동시에 비켜야 하는 경우가 많고, 큰 팔 8대가 같은 공간을 다투면 PIBT가 이 의존을 쉽게 풀지 못한다. 이것은 cuArms의 탐색 엔진이 가진 구조적 한계다. 직관 절의 “질문을 미리 계산한다”는 설계는 질문이 쌍 단위일 때 효과적이지만, 셋 이상이 얽힌 의존은 표 한 장으로 풀리지 않는다.

프로젝트 페이지 “Shelves · 8 arms” 클립(2.1 MB, 원 URL 참조, 0.25배속). 페이지 표기로 첫 해 4.58 s, refinement 포함 11.10 s, 비용 49.04 rad. 성공한 한 query다.

C. 양팔 LEGO 조립

APEX-MR의 LEGO 조립 4과제(벽돌 12~258개, Yaskawa GP4 2대). APEX-MR의 조립 순서·선후 제약·할당·skill 파라미터를 skeleton으로 쓴다. 베이스라인 VAMP-MR은 APEX-MR planner를 CPU 벡터화 충돌 검사로 돌린다. 한 번에 한 팔을 손으로 설계한 waypoint 사이에서 RRT로 계획하고(다른 팔은 home에서 대기), temporal plan graph(TPG)로 비동기화한 뒤 shortcut한다. 두 방법 모두 후처리 시간 5 s(Big Chair 20 s)를 받는다.

과제	벽돌	cuArms t_0 / J_0 / J_f	VAMP-MR t_0 / J_0 / J_f
Cliff	12	1.30 / 207 / 144	1.37 / 273 / 145
Vessel	36	2.18 / 318 / 264	1.29 / 547 / 278
RSS	47	3.15 / 618 / 447	6.36 / 1007 / 514
Big Chair	258	13.6 / 1911 / 1756	3.36 / 3465 / 1789

부록 Table VII 옮김(t_0 s, J = 실행 makespan s, 3 seed 중앙값).
LEGO 조립 makespan-계획 시간(부록 Fig. 11). VAMP-MR은 먼저 순차 계획을 찾고, TPG 비동기화와 shortcut으로 내려온다.

cuArms의 첫 해는 VAMP-MR의 순차 계획보다 24~45% 짧고, 최종 해는 1~13% 짧다(필자 검산 일치). Big Chair에서는 cuArms가 첫 해에 13.6 s로 VAMP-MR(3.36 s)보다 느리지만, VAMP-MR은 TPG 구축에 25 s가 더 든다. 여기서 비교가 공정한지 볼 때 기억할 점이 있다. VAMP-MR의 첫 해는 한 팔씩 움직이는 순차 계획이라 J_0가 클 수밖에 없다. 최종 해의 1~13% 차이가 두 시스템의 실제 격차에 더 가깝다. 프로젝트 페이지는 “Six LEGO assembly tasks”로 Fish·Faucet을 더 보여 주지만 부록 표에는 4과제만 있다.

D. 코딩 에이전트를 scheduler로

부록에서 가장 흥미로운 절이다. 손으로 짠 scheduler(용접은 Hungarian, tabletop은 ScheduleStream) 대신 코딩 에이전트(Claude Opus 5.5, GPT-6 Astra)가 cuArms의 Python API를 도구로 써서 skill·skeleton·비용을 직접 작성한다. 세션은 20분, 새 Docker 컨테이너, 모델 API 외 네트워크 차단, API는 읽기 전용이다. 최종 계획은 컨테이너 밖의 신뢰된 validator가 따로 채점한다. validator는 0.02 rad 간격 재생, 관절 위치·속도 한계, sphere 모델 충돌(6 mm 침투 허용), grasp 5 mm·0.05 rad, 용접 2.5 cm·15° 등을 검사한다.

과제	손으로 짠 scheduler + cuArms 성공 / t_0 / J	Opus+ 성공 / t_0 / J	Astra+ 성공 / t_0 / J
RoboBallet 4×10	10/10 / 0.29 / 5.69	10/10 / 163 / 6.30	10/10 / 144 / 4.45
RoboBallet 4×40	10/10 / 0.49 / 18.1	10/10 / 341 / 18.9	10/10 / 169 / 15.2
RoboBallet 8×40	10/10 / 0.85 / 15.6	9/10 / 651 / 13.9	10/10 / 327 / 12.1
Stack (2~4)	30/30 / 0.85 / 7.01	30/30 / 279 / 4.06	30/30 / 118 / 3.48
Pack (2~8)	38/50 / 5.17 / 7.96	50/50 / 237 / 5.49	50/50 / 110 / 2.99
Unpack (2~8)	48/50 / 4.89 / 9.43	49/50 / 311 / 5.67	50/50 / 127 / 3.27

부록 Table VIII 옮김. t_0는 첫 validated 계획까지 시간(s), J는 세 방법이 모두 푼 instance의 makespan 중앙값(s).
에이전트의 anytime 거동(부록 Fig. 13). 손으로 짠 scheduler 대비 최고 validated makespan 비율의 중앙값을 세션 시간에 따라 그렸다. Tabletop에서 Astra는 약 0.4까지 내려간다.

에이전트 쪽 결과는 본문 주장을 새로 읽게 만든다. tabletop에서 Opus+는 손으로 짠 scheduler makespan의 0.51~0.79배, Astra+는 0.32~0.61배다(본문 서술). 에이전트는 주로 배치·접근 높이·grasp 각도를 훑어 skill 자체를 짧게 만든다(Table IX: 접근 높이 sweep이 Astra 세션의 98%, grasp 각도 sweep이 95%). RoboBallet에서는 허용치 안에서 용접 자세를 다시 잡고 할당을 재배분한다. 비용은 분 단위 세션과 API 사용이다. Astra는 세션의 80%(15.9분), 명령 68개를 쓰고, Opus는 47%(9.3분), 명령 11개를 쓴다. 저자들은 손으로 짠 baseline이 “compute-matched가 아니다”(약 1분 대 최대 20분)라고 명시한다. 또 계획을 가속·저크 한계에 맞게 늦춘 executable makespan은 원 makespan의 1.49배(Astra), 1.66배(Opus), 1.62배(손으로 짠 skeleton)여서, 에이전트의 짧은 계획이 더 거친 motion에서 나온 것은 아니라고 한다.

프로젝트 페이지 “Human intent” 클립(0.6 / 0.7 MB, 원 URL 참조). 같은 handover 과제를 Astra+cuArms에 “속도만”(왼쪽)과 “속도와 부드러움의 균형”(오른쪽) 자연어 선호로 맡긴 결과. 페이지 표에 따르면 최고 관절 속도 2.8→1.7 rad/s, 도구 경로/직선 비율 1.38→1.00. 이 실험은 부록 PDF에 없고 프로젝트 페이지에만 있다.

E. 코딩 에이전트와 함께한 실기 tabletop

Kinova Gen3 2대(사람 같은 배치, 바깥을 향함)와 머리 위치의 ZED Mini. 에이전트가 SAM 3로 블록을 분할하고 알려진 상자 모양을 마스크에 맞춰 포즈(xy·yaw)를 추정한 뒤, 부록 D 절차대로 할당·grasp·배치·순서를 정하고 cuArms로 계획한다. 로봇 형상, 카메라 포즈, 테이블 높이, 물체 모양은 알려졌다고 가정한다. 궤적은 사람이 시각화해 검토한 뒤 실행하고, 팔마다 TOPP-RA로 retiming해 TPG로 동기화한다.

코딩 에이전트 + cuArms 실기 tabletop(부록 Fig. 14). 왼쪽 세 장 (a) Pack: 두 팔이 색 블록을 매트에 놓는다. 오른쪽 세 장 (b) Stack: 두 팔이 블록을 탑으로 쌓는다.

이 절도 시행 수와 성공률이 없다.

비판적으로 보면

강점

• “무엇을 GPU로 보낼지”를 알고리즘과 함께 설계했다. PIBT의 재귀 제어는 CPU에 두고, 그 재귀가 물을 질문(후보 쌍 충돌)을 미리 GPU 배치로 답해 두는 분리는 간단하지만 이식성이 높다. Table III에서 LaCAM과 PIBT가 단계 합의 4% 미만이라는 것이 이 분리가 실제로 작동한다는 증거다. mode-validity mask로 roadmap을 mode 간에 재사용하는 설계도 같은 원칙의 일관된 적용이다.
• MAPF의 lazy 탐색을 hybrid manipulation으로 넓혔다. 탐색 노드에 symbolic 행동 단계를 넣고, skill을 roadmap의 특수 edge로 만들고, 양팔 skill을 PIBT·LaCAM 양쪽에서 함께 commit하는 확장은 handover·운반 같은 협응 skill을 같은 탐색 안에서 다루게 한다. Fig. 4처럼 우선순위가 뒤집히며 양보 순서가 탐색 중에 생기는 것은 독립 계획 + retiming이나 순차 계획으로는 얻기 어렵다.
• 자기 방법에 불리한 결과를 숨기지 않는다. Hold에서 첫 makespan이 ScheduleStream보다 길고, xECBS Shelves에서 38% 대 84%로 지고, MRMG에서 prioritized의 첫 해 비용이 더 낮고, LEGO Big Chair에서 첫 해가 VAMP-MR보다 느리다는 것을 모두 표와 본문에 적는다. Shelves 실패의 원인(PIBT의 한 번에 한 로봇 밀어내기)도 스스로 진단한다.
• 부록의 비교 범위가 넓다. 같은 계열 planner들(xECBS·ECBS·prioritized·AIT*·VAMP-MR)과 네 벤치마크에서 원 벤치마크의 비용 정의를 그대로 써서 비교한다. 코딩 에이전트 실험도 신뢰된 외부 validator, 네트워크 차단, compute-matched가 아니라는 단서까지 갖춰 신중하게 설계됐다.
• anytime 곡선을 보고한다. 첫 해와 최종 해만이 아니라 추가 시간에 따른 makespan 곡선(Fig. 5·6·9·10·11)을 IQR과 함께 보여 줘, 계산 예산에 따른 품질 거래를 독자가 직접 읽을 수 있다.

약점·한계

• 핵심 설계 요소의 ablation이 없다. 이 논문의 주장은 “알고리즘 분해 + GPU 배치의 공동 설계”인데, 어느 쪽이 얼마나 기여하는지 분리한 실험이 없다. GPU conflict table 대 재귀 중 충돌 검사(CPU 또는 GPU), mode mask 재사용 대 roadmap 재구축, conflict-based 탐색 대 prioritized 계획을 같은 구현에서 바꿔 본 결과가 없다. Fig. 5의 “약 47% 감소”도 shortcut과 대체 skeleton 탐색 두 가지를 합친 값이라 각각의 기여를 알 수 없다. 저자들이 Table III으로 “GPU가 충돌 검사 병목을 18.1~24.7%로 줄였다”고 쓰지만, 줄이기 전의 값(CPU 기준선)이 없으므로 이 문장은 측정된 감소가 아니라 현재 비중의 보고다.
• arXiv 본문만 보면 같은 계열 planner와의 비교가 없다. Table I이 나열한 xECBS·Hartmann·APEX-MR·VAMP-MR과의 비교는 모두 프로젝트 페이지 부록에 있다. 본문 실험의 베이스라인은 RL 하나와 ScheduleStream 하나이고, ScheduleStream은 공저자들의 이전 시스템이며 cuArms도 그 symbolic planner를 그대로 쓴다. 부록 비교는 강점이지만, 그중 MRMG·xECBS는 다른 하드웨어에서 발표된 수치(xECBS는 노트북급 i9-12900H)와 RTX Pro 6000 GPU 결과를 비교한다. “몇 배 빠르다”는 알고리즘 차이와 하드웨어 차이가 섞인 값이다.
• “실시간”과 “domain-agnostic”의 범위. 첫 해 1초 안팎은 skeleton이 주어진 뒤의 cuArms 단계다. Fig. 7에서 물체 8개 TAMP는 첫 해에 40~50 s가 걸리고, 프로젝트 페이지 기준 그 대부분이 scheduler 시간이다. “domain-agnostic”도 planner에 대해서는 맞지만 시스템 전체로는 도메인이 sampler와 scheduler를 공급해야 한다(Fig. 2 캡션, 용접은 전용 Hungarian scheduler). 부록 D가 스스로 “domain-agnostic temporal planner도 전문가가 쓴 도메인 기술에 의존한다”고 적는다.
• 결과의 상당 부분이 scheduler에 묶여 있다. 부록 D에서 코딩 에이전트가 같은 cuArms 위에서 tabletop makespan을 0.32~0.61배(Astra)까지 줄인다. 손으로 짠 scheduler와 cuArms 조합이 남긴 여지가 그만큼 크다는 뜻이다. 같은 표에서 손으로 짠 scheduler + cuArms는 Pack 2~8개에서 38/50, Unpack에서 48/50만 푼다. 본문의 “cuArms also solves all instances”는 물체 2~4개(Table IV)에 대한 말이고, 6~8개에서는 실패가 있다(부록은 다른 instance 집합과 skeleton 16개 탐색 설정이라 직접 비교는 아니다).
• makespan의 의미가 실행 시간과 다르다. 부록 C는 “각 motion이 관절 속도 한계로 달린다”고 정의하고, 부록 D는 가속(15 rad/s²)·저크(500 rad/s³) 한계에 맞게 늦춘 executable makespan이 원 makespan의 1.49~1.66배라고 보고한다. 본문의 makespan 비교(특히 100 ms 관절 속도 명령을 내는 RoboBallet RL과의 비교)가 같은 동역학 가정 위에 있는지는 적혀 있지 않다. 또 Fig. 6 캡션대로 cuArms가 최적화하는 것은 가중 J인데 보고되는 것은 makespan이고, 가중치는 본문에 없다.
• RL 베이스라인의 조건. 위 RoboBallet 대조에서 본 것처럼, 성공률 지표는 원 논문의 태스크 단위 해결률과 다른 에피소드 단위 완수율이다. 재학습 시간(약 44~61시간)은 원 논문이 말한 품질 개선 구간의 앞쪽 끝이고 학습 곡선이 없다. 8팔 RL 수치가 없고, 10타깃 RL이 40타깃보다 낮은 역전도 설명이 없다. RL이 약하게 나왔을 가능성을 배제할 근거가 부족하다.
• 완전성·안전성은 모델에 상대적이다. 논문은 RoboBallet이 “completeness나 formal safety guarantee가 없다”고 대비하지만, cuArms 자신의 보장은 정리로 제시하지 않는다. 탐색은 유한 roadmap 위에서 돌고, 충돌은 sphere 근사와 discrete 간격 검사로 판정한다(validator 기준 6 mm 침투 허용). 산업 응용을 말하는 논문이라면 이 상대성을 명시하는 편이 정확하다.
• PIBT의 구조적 한계. Shelves 38%는 우연이 아니라 탐색 엔진의 성질에서 나온다. 한 팔을 움직이려면 여러 팔이 동시에 비켜야 하는 밀집 상황에서 PIBT는 약하고, 쌍 단위 conflict table은 이 다자 의존을 직접 표현하지 못한다. 8팔 용접에서 팔을 두 배로 늘려도 최종 makespan이 10.2%만 준 것도 같은 밀집 효과의 다른 얼굴일 수 있다(필자 해석).
• 재현 정보가 부족하다. roadmap 크기, edge 간격, 후보 수, shortcut 배치 크기, 비용 가중치가 본문에 없고 코드도 공개되지 않았다(아래 절). 실기 실험(본문 Flexiv, 부록 Kinova)은 시행 수·성공률이 없고, 부록 E는 사람이 실행 전에 궤적을 검토한다.

코드 공개 범위

2026-10-29 확인 시점에 planner 코드는 공개되지 않았다. 프로젝트 페이지에는 Paper(PDF)와 Appendix(PDF) 링크만 있고 Code 링크는 없다. 페이지 하단은 “Anonymous research project · Under double-blind review”로 표기된다. GitHub에서 cuarms로 검색되는 저장소는 프로젝트 페이지 자체(cuArms/cuArms.github.io, 설명 “Anonymous submission to ICRA 2026”)와 무관한 동명 저장소 하나뿐이다. 프로젝트 페이지 저장소의 트리 항목 188개는 영상·포스터·PDF와 사이트 빌드 스크립트(scripts/build.py, 미디어 복사용)이고 planner 소스는 없다. NVlabs·nvidia-isaac 조직에서 같은 이름의 저장소도 찾지 못했다. 부록 D·E에 Python API(Scene, Action, Skeleton, Cost, Planner)의 형태가 소개되지만 패키지는 공개되지 않았다. 따라서 이 리뷰의 모든 수치는 논문과 부록이 보고한 값이며, 코드 대조나 실행 확인은 하지 않았다.

관련 연구와의 자리 매김

RoboBallet과의 관계: 학습 대 탐색. RoboBallet 리뷰에서 본 것처럼 RoboBallet은 할당·스케줄·motion을 학습된 GNN 정책 하나로 푸는 쪽에 걸었다. 조합 폭발을 그래프 표현과 오프라인 학습으로 흡수하고, 추론은 스텝당 1 ms 미만이다. cuArms는 정반대 쪽에서 같은 벤치마크를 푼다. 학습 없이 탐색으로, 대신 탐색이 요구하는 기하를 GPU로 몰아서 푼다. 두 논문을 나란히 읽으면 “멀티암 셀 계획은 오프라인 학습으로 상각할 문제인가, 온라인 탐색을 충분히 빠르게 만들 문제인가”라는 질문이 선명해진다. cuArms의 결과는 적어도 이 벤치마크에서 온라인 탐색 쪽이 학습 없이 성공률과 makespan 모두에서 앞설 수 있음을 보인다. 다만 위에서 짚은 대로 RL 베이스라인의 조건이 충분히 밝혀지지 않았다.

GPU 가속 계획의 계보. cuArms는 cuRobo 리뷰의 collision sphere 표현과 GPU IK를 부품으로 쓴다(용접 타깃의 관절 목표 샘플링, 부록 D 샌드박스의 cuRobo 포함). cuRobo가 단일 로봇의 궤적 최적화를 GPU로 병렬화했다면, cuArms는 그 병렬화를 다중 로봇 간 충돌 질의와 multi-modal roadmap의 mode별 유효성으로 넓혔다. 같은 NVIDIA 그룹의 cuTAMP가 task skeleton을 GPU로 병렬 평가한 것과 짝을 이룬다.

MAPF에서 manipulation으로. LaCAM·PIBT는 수천 대 이동 로봇을 다루던 알고리즘이고, db-LaCAM이 kinodynamic으로 넓혔다. 저자들은 LaCAM 계열이 이동 로봇에서만 보여졌다고 쓰며, cuArms를 고차원 팔과 hybrid skill로의 확장으로 내세운다. 공저자 Jiaoyang Li(CMU)가 참여한 xECBS·APEX-MR·VAMP-MR이 바로 앞 단계이고, 부록은 그 셋과 모두 비교한다. TAMP 평가 쪽에서는 KinDER 리뷰가 TAMP·RL·IL 베이스라인을 같은 물리 추론 환경에서 비교한다. 다만 KinDER는 단일 로봇 과제가 중심이라, cuArms가 다루는 다중 팔 협응은 아직 그런 공통 벤치마크 밖에 있다(필자 해석).

코딩 에이전트가 planner를 도구로 쓰는 흐름. 부록 D는 LLM 코딩 에이전트가 손으로 짠 scheduler를 대신해 skill·skeleton·비용을 작성하고 cuArms를 API로 부른다. ASPIRE 리뷰의 에이전트가 시뮬레이터와 실행 피드백으로 skill 코드를 쌓아 가는 것과 같은 계열이다. cuArms 쪽에서 흥미로운 점은 에이전트의 이득이 주로 skill 파라미터 튜닝(배치·접근 높이·grasp 각도)에서 왔다는 것이다. 빠른 planner가 있으면 에이전트가 그 위에서 수백 번 시도하며 상위 결정을 고를 수 있다. planner의 속도가 에이전트 루프의 처리량을 정한다는 점에서, “실시간 첫 해”의 진짜 수혜자는 사람보다 에이전트일 수 있다(필자 해석).

요약

cuArms는 멀티암 조작 계획을 skeleton이 고정한 행동 사이의 협응 문제로 정의하고, 로봇별 multi-modal roadmap, LaCAM·PIBT 기반 conflict-driven 탐색, GPU 배치 shortcut으로 푼다. 기여의 핵심은 계산 분할이다. 재귀적 결정(PIBT 우선순위 상속, LaCAM의 lazy 제약)은 CPU에 두고, 그 결정이 물을 기하 질문(후보 쌍 충돌, mode별 유효성, shortcut 유효성)은 미리 큰 GPU 배치로 답해 둔다. 이 덕분에 RoboBallet 4·8팔 용접에서 1초 안에 첫 해를 찾아 450/450을 풀고, 2팔 tabletop TAMP에서 ScheduleStream보다 빠르고 짧은 계획을 내며, 부록의 MRMG·xECBS·LEGO 벤치마크에서도 첫 해 속도에서 대체로 앞선다.

한계는 범위와 근거의 종류에 있다. “실시간”은 skeleton이 주어진 뒤의 단계에 대한 말이고, 8개 물체 TAMP는 scheduler까지 포함해 수십 초가 걸린다. 결과의 상당 부분이 scheduler 품질에 묶여 있다는 것은 부록의 코딩 에이전트 실험이 스스로 보여 준다. 공동 설계의 각 요소를 분리한 ablation이 없고, 같은 계열 planner와의 비교는 arXiv 본문이 아니라 프로젝트 페이지 부록에 있으며 일부는 다른 하드웨어의 발표 수치와 겨룬다. PIBT의 한 번에 한 로봇 해소는 밀집한 8팔 Shelves에서 38%라는 분명한 약점을 드러낸다. 그럼에도 “MAPF의 lazy 탐색을 GPU 기하와 짝지어 hybrid manipulation으로 옮긴다”는 설계는 명료하고, 빠른 planner를 에이전트의 도구로 쓰는 부록 D의 방향은 멀티암 셀 설계를 사람 손에서 자동화 루프로 옮기는 실용적 출발점이 될 수 있다. 코드가 공개되면 conflict table의 실제 기여를 ablation으로 확인해 볼 수 있을 것이다.

이 글에 대해

• 읽은 범위: arXiv v1(2026-10-26 제출, 본문 8쪽)을 PDF와 HTML로 읽었다. 범위 수치(0.48~2.96 s, 42~57%, 18.1~24.7% 등)와 모든 표 값은 PDF에서 옮겼다. 부록은 arXiv에 없고 프로젝트 페이지의 Appendix PDF(6쪽, Fig. 9~14, Table V~IX)에서 읽었다. 프로젝트 페이지의 Paper PDF는 저자 표기가 익명이라는 점 외에 arXiv 본문과 같다. 학회 게재 표기는 arXiv에 없고 프로젝트 페이지는 double-blind 심사 중이라고 적는다.
• 그림: arXiv HTML이 Fig. 1~7을 SVG로만 실어 모든 그림을 PDF에서 300 dpi로 래스터화해 잘랐다. 본문 Fig. 1~8과 부록 Fig. 9·10·11·13·14를 실었고, 부록 Fig. 12(코딩 에이전트 도식)는 생략했다. 모든 그림을 열어 캡션과 대조했다.
• 영상: 프로젝트 페이지 mp4를 원 URL로 참조한다(CORS 허용·크기 확인, 장당 0.4~5.5 MB). 27 MB 하이라이트 영상, 18 MB 전체 supplementary 영상, 13~28 MB Kinova·LEGO 영상은 임베드하지 않았다. 프로젝트 페이지에서 볼 수 있다. 영상 캡션의 계획 시간·makespan은 프로젝트 페이지 content.js의 표기값이며 논문 표의 중앙값과 다른 단일 사례다. Human intent 실험은 부록 PDF에 없고 프로젝트 페이지에만 있다.
• 코드: 미공개(위 “코드 공개 범위” 절). 코드 대조나 실행 확인은 없다.
• 표기: “필자 계산·검산”은 논문 표 값으로 직접 계산한 값(합산 기준 46.4% 재현, 과제별 감소율, 4→8팔 변화율, 로봇 쌍 수 대비 conflict table 증가, 단계별 비중, RL 학습 시간 환산)이다. 단계별 비중은 중앙값을 더한 근사다. “필자 해석”은 논문이 말하지 않은 추론(150·45의 구성, 완전성의 roadmap 상대성, 밀집 효과, 에이전트 수혜 해석)이다. “그림에서 읽은 근사치”는 Fig. 7의 8개 물체 첫 해 시간이다. RoboBallet 원 논문 수치는 이 블로그의 RoboBallet 리뷰에 정리한 값이다.
• 조회 시점: 논문·프로젝트 페이지·GitHub 2026-10-29.