📃MoDeSuite 리뷰

mobile-manipulation

deformable

benchmark

sim2real

MoDeSuite: Robot Learning Task Suite for Benchmarking Mobile Manipulation with Deformable Objects

Published

October 4, 2026

Paper Link (arXiv:2507.21796)
Code Link
Project
Yuying Zhang, Kevin Sebastian Luck, Francesco Verdoja, Ville Kyrki, Joni Pajarinen
Aalto University · Vrije Universiteit Amsterdam / IEEE Robotics and Automation Letters, 2026 (저자 연구실 페이지·코드 README 표기). 이 리뷰는 arXiv v1(2025-07-29)을 읽었다.

💡 mobile manipulation 벤치마크는 대부분 rigid 물체만 다루고, deformable 벤치마크는 대부분 고정된 팔만 다룬다. MoDeSuite는 이 둘을 합친 첫 task suite라고 주장하며, 로봇이 몸통 이동과 팔 조작을 함께 써서 물체의 변형을 이용해야 풀리는 8개 과제를 Isaac Lab 위에 만든다.
⚙️ 탄성 막대·벨트 과제 5개(Place·Bend·Transport·Drag·Lift)는 FEM, 천 과제 3개(Uncover·Cover·Curtain)는 PBD particle로 시뮬레이션한다. 로봇은 바퀴형(Ridgeback + Franka)과 다리형(Spot + arm) 두 가지이고, state 관측(로봇 상태 + 물체 위 4개 점 + 목표 위치)과 DINOv2로 인코딩한 RGB 관측을 제공한다.
🎯 탄성 과제에서 PPO가 SAC보다 대체로 낫고, Spot은 Bend·Transport를 두 알고리즘 모두 0%로 풀지 못했다. 시뮬레이션에서 학습한 Spot의 state 기반 PPO 정책은 실기 Place·Drag에서 각 10/10을 성공했다. 반면 이미지 기반 IL 정책(BC·Retrieval)은 시뮬레이션 Curtain에서 60~80%였지만 실기에서는 한 번도 성공하지 못했다.

🔍 Ping Review

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

긴 고무 막대를 들고 L자 복도를 지나가려면 막대를 벽에 대고 휘게 만들어야 한다. 팔 길이보다 먼 탁자에 막대를 올리려면 몸을 탁자 쪽으로 옮기면서 팔을 뻗어야 한다. 이런 일은 “이동”과 “조작”이 동시에 필요하고, 물체가 휘거나 늘어난다는 사실을 이용해야 한다. 기존 벤치마크는 이 조합을 다루지 않는다. BEHAVIOR-1K·Habitat 같은 mobile manipulation 벤치마크는 주로 rigid 물체를, SoftGym·DeformableRavens 같은 deformable 벤치마크는 주로 고정된 팔을 쓴다.

MoDeSuite는 이 빈칸을 채우려는 Isaac Lab 기반 task suite다. 새로 만든 탄성 과제 5개와, 같은 1저자의 이전 연구 DeMoBot에서 가져온 천 과제 3개를 묶었다. 같은 과제를 바퀴형 로봇과 다리형 로봇 모두로 돌릴 수 있고, 관측(state·이미지)과 행동 공간(joint·end-effector pose·keyboard용 discrete action)을 바꿔 끼울 수 있다.

Fig. 1. 8개 과제를 바퀴형(위 두 줄, Ridgeback + Franka)과 다리형(아래 두 줄, Spot + arm)으로 각각 보여 준다. 보라색 구는 목표 위치다. 빨간 막대와 녹색 벨트는 FEM 탄성체, 파란 천은 PBD 천이다.

Spot의 Place 과제(시뮬레이션). 팔 끝에 달린 탄성 막대(빨간 점은 관측에 쓰이는 막대 위 점)를 탁자 위로 옮긴다. 출처: 프로젝트 페이지 GIF.

핵심 방법론:

MoDeSuite는 새로운 학습 알고리즘이 아니라 과제와 인터페이스의 묶음이다. 모든 과제의 state 관측은 같은 형태로 정의된다.

O = (s_r,\ s_o,\ s_e),\qquad s_r=(p_r,\ q_r,\ q,\ \dot q),\qquad s_o=\{e_i\in\mathbb{R}^3\}_{i=1}^{N},\qquad s_e=(g_r,\ g_o,\ p_o)

s_r은 베이스 위치 p_r·자세 쿼터니언 q_r·팔 관절 위치와 속도, s_o는 탄성체의 FEM 요소(천은 particle) 위치, s_e는 로봇 목표 g_r·물체 목표 g_o·장애물 위치 p_o다. RL 실험에서는 s_o를 물체 위에 고르게 놓인 4개 점으로 줄인다. 행동은 a_{robot}=(a_{base}, a_{arm})이고, Spot의 베이스는 사전학습된 locomotion 컨트롤러에 평면 명령 3개를 주거나 다리 관절 12개를 직접 지령한다. 보상은 탄성 과제에서 “물체 끝(또는 중점)과 목표의 거리 + 로봇과 목표의 거리 + 안정성 페널티”의 음수 합, 천 과제에서 binary sparse reward다.

주요 결과:

RL(시뮬레이션, state 관측, 5 seed, 성공률은 20회 평가): PPO는 Franka에서 Place 95%·Bend·Transport·Lift 100%였지만 Drag는 20%였다. Spot에서는 Place·Drag 100%, Lift 35%, Bend·Transport 0%였다. SAC는 Franka Bend(100%)와 Spot Place(90%)를 빼면 모두 10% 이하였다(Fig. 3의 막대에서 읽은 값).
IL(시뮬레이션, Spot, DINOv2 이미지 특징, 과제당 시연 30개, 20회 평가): BC는 Uncover 85%·Cover 60%·Curtain 60%, Retrieval은 90%·80%·80%였다(Table III).
sim-to-real(Spot, 실기 10회): PPO는 Place·Drag 모두 10/10, SAC는 Place 9/10·Drag 0/10이었다(Table II). 이미지 기반 Curtain은 BC가 커튼에 닿지도 못했고 Retrieval은 10회 중 2회 접촉에 그쳤다. DINOv2 특징의 t-SNE에서 시뮬레이션과 실기 이미지가 분리돼, 저자는 원인을 dynamics가 아니라 시각 domain gap으로 본다.

결론:

이 논문의 가치는 “이동하면서 deformable 물체를 다룬다”는 문제 설정을 재현 가능한 시뮬레이션 과제로 고정했다는 데 있다. 실험은 그 과제가 현재 RL에게 쉽지 않다는 것(특히 Spot)과, 4개 점짜리 state 관측이면 OptiTrack을 통해 실기로 넘어갈 수 있다는 것을 보인다. 다만 벤치마크 논문으로서 필요한 재현 정보(병렬 환경 수, 하이퍼파라미터, 물성치, 초기 상태 분포)가 본문에 없고, 공개 코드는 일부 서술과 다르다. 이 점은 Ring에서 자세히 본다.

🔔 Ring Review

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

한 줄로 시작하면

MoDeSuite는 “몸을 움직여야만 풀리는 deformable 조작”을 8개 과제로 만들고, 바퀴형과 다리형 로봇에 같은 과제를 걸어 PPO·SAC·BC·Retrieval을 돌려 본 다음, state 기반 RL 정책이 실기 Spot으로 그대로 넘어간다는 것을 보인 task suite 논문이다. 결과가 말해 주는 것은 두 가지다. 같은 과제라도 로봇 형태에 따라 난이도가 크게 달라지고(Spot은 좁은 복도 과제 두 개를 아무 알고리즘으로도 못 풀었다), state 관측의 sim-to-real은 되지만 이미지 관측은 시각 domain gap에서 막힌다.

배경: 왜 이동과 deformable을 같이 봐야 하는가 (§I·§II)

저자는 deformable 물체를 plastic(영구 변형)과 elastic(되돌아오는 변형)으로 나눈다. 다만 이 논문에서 “plastic”은 재료학의 소성 변형이 아니라 Table I의 정의대로 천·로프처럼 형태가 정해지지 않은 물체를 뜻하고, “elastic”은 고무·폼처럼 원래 모양으로 돌아오는 물체를 뜻한다. 본문 §I은 plastic 변형을 “permanent structural changes”라고 설명하지만 과제의 천(커튼·식탁보)은 영구 변형되는 물체가 아니다. 용어가 두 가지 의미로 섞여 있으니 읽을 때 Table I의 정의를 기준으로 삼는 것이 낫다.

서론의 문제의식은 이렇다. mobile manipulation과 deformable manipulation 각각에는 벤치마크가 있지만 둘을 합친 표준 벤치마크가 없다. 실기 실험은 비싸고 표준화가 어렵다. 그래서 RL·IL처럼 데이터가 많이 필요한 방법을 위해 시뮬레이션 벤치마크가 필요하다.

§II는 기존 플랫폼을 Table I로 비교한다. 아래는 그 표를 옮긴 것이다.

분류	이름	물리 엔진	Plastic	Elastic	Mobile-M	Legged-M	비고
Mobile	Behavior-1k	PhysX5	✓	✗	✓	✗	Daily Activities
	AI2THOR	Unity	✗	✓	✓	✗	Indoor Scene
	TDW Transport	PhysX, Flex, Obi	✓	✓	✓	✗	Transport Challenge
	Habitat	Bullet	✗	✗	✓	✓	Indoor Scene
	ManiSkill3	PhysX	✗	✗	✓	✗	Limited Mobile Manipulation Tasks
	ORBIT	PhysX	✓	✗	✓	✓	FEM, Particle System
Deformable	DeformableRavens	Bullet	✓	✓	✗	✗	FEM
	DEDO	Bullet	✓	✓	✓	✗	Particle System
	DAXBench	DAX	✓	✓	✗	✗	Tabletop, Particle System
	PlasticineLab	DiffTaiChi	✓	✓	✗	✗	End-effector, Particle System
	Reform	AGX	✗	✓	✗	✗	End-effector, FEM
	SoftGym	Flex	✓	✗	✗	✗	Particle System
	DexGarmentLab	PhysX	✓	✓	✗	✗	Particle System, FEM
Both	MoDeSuite	PhysX	✓	✓	✓	✓	Particle System, FEM

표를 줄 단위로 읽으면 “첫 번째”라는 주장이 어디에 기대는지 보인다.

ORBIT 행이 스스로 모순된다. 비고란에 FEM이 있는데 Elastic은 ✗다. MoDeSuite의 탄성 과제는 ORBIT(지금의 Isaac Lab)이 제공하는 PhysX FEM soft body 위에 만들어졌다. 그러니 이 표에서 MoDeSuite와 ORBIT을 가르는 유일한 열(Elastic)은 사실상 기반 프레임워크의 기능이다. 본문도 ORBIT은 “프레임워크 설계에 집중했고 두 문제의 통합을 다루지 않았다”고 차이를 과제 쪽에 둔다.
TDW Transport와 DEDO는 Plastic·Elastic·Mobile-M이 모두 ✓다. 이 둘과 MoDeSuite를 가르는 열은 Legged-M 하나뿐이다. 따라서 이 표가 뒷받침하는 차별점은 “deformable + mobile을 처음 합쳤다”가 아니라 “다리형 mobile manipulator까지 포함한 deformable 과제 묶음”에 가깝다.

이것이 MoDeSuite의 의미를 깎지는 않는다. 차별점의 정확한 위치를 바로잡을 뿐이다. 이 블로그의 BEHAVIOR-1K 리뷰와 ManiSkill3 리뷰가 표의 Mobile 쪽 두 플랫폼을 다룬다.

방법 상세 1: 프레임워크와 물리 (§III, §III-A)

Fig. 2. MoDeSuite 구성. 알고리즘(RL·IL), 시뮬레이션(두 mobile manipulator, 두 종류의 deformable 물체, RGB·depth·state 관측, 8개 과제), 백엔드(FEM·PBD 물리, Omniverse·Python·USD, GPU 병렬 학습).

8개 과제 중 5개(Place·Bend·Transport·Drag·Lift)가 새로 만든 탄성 과제이고, 3개(Uncover·Cover·Curtain)는 DeMoBot(Zhang et al., 2024, 같은 1저자)이 IL용 과제로 처음 제안한 것이다. 저자는 DeMoBot 대비 기여를 “locomotion 지원과 베이스 협조 제어가 없던 원래 구현의 한계를 해결한 확장 가능한 벤치마크”로 설명한다.

물리 엔진은 NVIDIA PhysX다. 탄성체는 사면체 메시 기반 FEM(본문 표기는 “element finite methods”)으로, 커튼·식탁보 같은 천은 position-based dynamics(PBD) particle로 시뮬레이션한다. PBD를 쓰는 이유로는 큰 변형에서도 안정적이라는 점을 든다. 장면은 Isaac Sim GUI에서 만들었고, 결론에 따르면 탄성체의 크기·모양도 지금은 GUI에서 바꿔야 한다(프로그램 방식 조절은 향후 과제).

본문에 없는 것도 적어 둔다. 탄성체의 Young’s modulus·Poisson 비, 천의 강성·질량, FEM 메시 해상도 같은 물성치가 하나도 없다. deformable 벤치마크에서 물성치는 과제 정의의 일부이고, sim-to-real 결과를 해석할 때도 필요하다. 이 값들은 공개된 USD 에셋 안에 들어 있을 것이므로 재현자는 에셋에서 읽어야 한다.

방법 상세 2: 로봇과 행동 공간 (§III-B)

항목	바퀴형 (Ridgeback + Franka)	다리형 (Spot + Spot Arm)
베이스 행동	a_{base}=(v_x, v_y, \omega_z), 평면 속도	사전학습 locomotion 컨트롤러에 (p_x, p_y, r_z) 또는 다리 관절 12개 직접 지령
팔 행동	joint position a_{arm}\in\mathbb{R}^n 또는 end-effector pose a_{arm}\in SE(3)	같음
조합	2가지	베이스 2 × 팔 2 = 4가지, 행동 차원 10~18
RL 실험에서 쓴 설정	joint space	사전학습 locomotion 컨트롤러 + 팔 joint space
discrete 행동	14개: 몸 전·후·좌·우 이동, 좌·우 회전, 손 전·후·좌·우·상·하, 잡기, 놓기 (keyboard 대응)	같음

discrete 행동은 keyboard로 시연을 모으기 위한 것이고, IL 데이터 30개가 실제로 keyboard로 수집됐다(§IV-B). 결론은 컨트롤러를 “joint space, task space, and hypermode”로 요약하는데, “hypermode”는 본문 어디에도 정의가 없다. 맥락상 discrete keyboard 행동을 가리키는 것으로 보인다.

RL 실험의 다리형 설정을 설명하는 문장은 “as described in Section III-D”라고 쓰지만 locomotion 컨트롤러 설명은 §III-B에 있다. 사소한 상호참조 오류다.

방법 상세 3: 관측 공간 (§III-C)

관측은 이미지 기반과 state 기반 두 가지다. 저자는 둘의 trade-off를 분명히 적는다. 이미지는 실기 로봇으로 옮기기 쉽지만 차원이 높아 학습이 어렵고, state는 학습이 쉽지만 실기에서 얻기 어렵다.

state 관측은 Ping의 식처럼 O=(s_r, s_o, s_e)다. 탄성체는 FEM 요소 위치 s_o=\{e_i\in\mathbb{R}^3\}_{i=1}^N, 천은 추적하는 particle 위치 s_o=\{p_i\in\mathbb{R}^3\}_{i=1}^M로 표현한다. s_e=(g_r, g_o, p_o)는 각각 로봇 목표, 물체 목표, 장애물 위치이고 모두 \mathbb{R}^3이다.

이미지 관측은 RGB-D 카메라 영상을 그대로 쓰지 않고 DINOv2 인코더 \phi를 거친 특징을 쓴다.

O = s_{env} = \phi(I)

정의상 이미지 관측에는 로봇 고유감각(proprioception)이 들어가지 않는다. IL 실험(§IV-B)도 o_b=\phi(I_{rgb})만 쓴다. 다리형 로봇이 커튼을 잡고 지나가는 과제에서 팔 관절 상태 없이 이미지 특징만으로 행동을 고른다는 뜻이다.

방법 상세 4: 8개 과제 (§III-D)

과제	물체(물리)	무엇을 해야 하나	보상	성공 판정
Place	탄성 막대(FEM)	팔이 닿지 않는 탁자 위에 막대를 올린다	−(막대 끝↔︎탁자 거리 + 로봇↔︎탁자 거리 + 안정성 페널티), 바퀴형은 안정성 항 0	막대 끝이 탁자 위
Bend	긴 탄성 막대(FEM)	막대를 들고 L자 복도를 지난다. 막대를 휘어야 통과된다	−(막대 끝↔︎목표 + 로봇↔︎목표 + 안정성)	막대 끝과 복도 입구 목표의 거리
Transport	탄성 막대(FEM)	Bend 확장. 복도 가운데 큰 장애물을 돌아간다. 중간 목표로 지역 최적 회피	−(막대 끝↔︎중간·최종 목표 + 로봇↔︎두 목표 + 안정성)	막대 끝과 최종 목표의 거리
Drag	한쪽 끝이 고정된 탄성 벨트(FEM)	벨트를 들어 늘려 장애물 너머로 넘기고, 몸은 body target 근처에 둔다	−(벨트 중점↔︎벨트 목표 + 몸↔︎body target + 안정성)	몸이 body target 근처 + 벨트가 장애물 반대편 목표 근처
Lift	두 벽 사이에 걸린 탄성 벨트(FEM)	벨트를 들어 올려 틈을 만들고 그 밑으로 지나간다(롤러 셔터에서 착안)	−(벨트 중점↔︎목표 + 몸↔︎body target + 안정성)	벨트 중점↔︎목표 거리 + 로봇↔︎로봇 목표 거리
Uncover	식탁보(PBD)	큰 탁자의 덮개를 정해진 방향으로 걷어 낸다	binary sparse	덮개가 완전히 걷히고 손잡이가 탁자 반대편을 넘음
Cover	천(PBD)	천을 잡아 두 상자 사이 틈을 덮는다(long-horizon)	binary sparse	틈이 덮이고 손잡이가 다른 상자로 옮겨짐
Curtain	걸린 커튼(PBD)	팔로 커튼을 밀고 몸을 충돌 없이 통과시킨다	binary sparse	충돌 없이 커튼을 지남

설계 의도가 가장 잘 보이는 장치는 보상에 들어간 로봇 위치 항이다. Drag 설명은 이 항을 “로봇이 팔 움직임에만 기대지 않고 이동성을 쓰도록” 넣었다고 밝힌다. 즉 “이동과 조작의 협조”가 과제 구조에서 자연스럽게 나오기를 기다리지 않고 보상으로 강제한다. 벤치마크 관점에서는 양날이다. 협조가 필요한 과제라는 주장과 협조를 보상으로 유도한 과제라는 사실이 섞이기 때문이다. 보상 항의 가중치와 거리 문턱은 본문에 없다.

본문 §III-D 첫 문단은 “Figure 1 illustrates the five tasks”라고 쓰지만 Fig. 1에는 8개 과제가 두 로봇으로 16칸에 걸쳐 그려져 있다. 탄성 과제 5개만 그렸던 이전 그림의 문장이 남은 것으로 보인다.

천 과제의 어려움으로 저자가 꼽는 점이 흥미롭다. 잡기 동작은 꼭 필요하지만 장면을 거의 바꾸지 않아 이미지로는 진행 상황을 알기 어렵고, 천이 다리형 로봇의 시야와 움직임을 가린다. Curtain에서는 IK 솔버 실패와 end-effector에서 커튼이 미끄러지는 문제도 언급한다.

직관: deformability는 장애물이자 도구다

rigid 막대라면 L자 복도(Bend)는 막대 길이와 복도 폭으로 통과 여부가 정해지는 기하 문제다. 탄성 막대라면 벽에 대고 휘게 만들어 기하적으로 불가능한 통과를 가능하게 할 수 있다. Drag의 벨트는 늘어날수록 그리퍼와 벨트 사이 힘이 커져 다리형 로봇의 균형을 흔든다. Lift는 벨트를 들어 올린 채로 그 밑을 지나야 해서 팔을 들고 있는 동안 몸을 움직여야 한다. 그래서 이 과제들에서 deformability는 극복할 장애물이면서 동시에 이용할 수 있는 도구다. 이 이중성이 과제 설계의 핵심이다.

state를 4개 점으로 줄인 선택도 같은 맥락에서 이해된다. 막대·벨트의 변형은 길이 방향 곡선 하나로 거의 요약되므로 점 몇 개로 충분하다. 그리고 점 몇 개는 실기에서 모션캡처 마커로 바로 측정할 수 있다. 실기 Place·Drag가 넘어간 이유의 상당 부분이 여기에 있을 것이다. 같은 요약이 천에는 통하지 않는다. 천 과제를 state 기반 RL로 돌리지 않고 이미지 기반 IL로만 평가한 것도 이 차이와 맞닿아 있다.

실험 1: 시뮬레이션 RL (§IV-A, Fig. 3)

셋업은 다음과 같다. 탄성 과제 5개에서 PPO와 SAC를 rl_games로 학습하고, 관측은 state(물체 위 4개 점 포함)다. 바퀴형은 joint space, 다리형은 사전학습 locomotion 컨트롤러 + 팔 joint space 행동을 쓴다. 과제·알고리즘마다 5 seed로 학습하고, 성공률은 학습된 에이전트의 20회 평가로 잰다.

Fig. 3. 위: Place 과제의 평균 return(5 seed 평균, 음영은 표준편차). 가로축은 Spot 5M, Franka 20M step이다. 아래: 5개 탄성 과제의 성공률(20회 평가). 본문은 막대 그림이 “upper-right corner”에 있다고 쓰지만 실제로는 그림 아래쪽에 있다.

논문은 성공률을 숫자로 주지 않는다. 아래 표는 Fig. 3 막대의 높이를 눈금에 맞춰 읽은 값이다. 높이가 1% 미만인 최소 높이 막대는 20회 중 1회 성공(5%)보다 낮으므로 0%로 읽었다.

로봇·알고리즘	Place	Bend	Transport	Drag	Lift	평균
Spot-PPO	100	0	0	100	35	47
Spot-SAC	90	0	0	10	10	22
Franka-PPO	95	100	100	20	100	83
Franka-SAC	0	100	0	5	0	21

(단위 %, Fig. 3에서 읽은 근사치. 평균은 필자 계산.)

저자의 해석은 두 가지다. ① 다리형(Spot)이 균형 유지 때문에 바퀴형보다 확연히 어렵고, 특히 좁은 공간 과제(Bend·Transport)에서 그렇다. ② PPO가 거의 모든 과제·로봇에서 SAC보다 낫고, 예외는 Spot의 Bend다. 그리고 “MoDeSuite의 모든 과제는 풀 수 있지만 여전히 어렵다”고 결론짓는다.

막대 값과 맞대 보면 다음이 보인다.

“예외는 Spot Bend”는 막대와 맞지 않는다. Spot Bend는 PPO·SAC 모두 0%로 동률이고, 실제로 SAC가 PPO와 같은 곳은 Franka Bend(둘 다 100%)다. 막대만 보면 PPO가 SAC보다 낮은 칸은 하나도 없다. 저자가 덧붙인 설명(Spot이 좁은 벽이나 탄성체와 부딪혀 균형을 잃는다)은 Spot Bend가 두 알고리즘 모두에서 실패한 이유로 읽는 것이 맞다.
“모든 과제를 풀 수 있다”는 Franka 기준이다. Spot 설정에서는 Bend·Transport가 어느 알고리즘으로도 0%다. Franka도 Drag는 최고 20%에 그친다. 즉 10개(과제 × 로봇) 설정 중 PPO·SAC 어느 쪽으로도 풀리지 않은 것이 2개, 최고 성공률이 50% 미만인 것이 2개(Spot Lift 35%, Franka Drag 20%)다.
“다리형이 더 어렵다”는 평균으로는 맞지만 과제마다 다르다. Drag는 반대로 Spot-PPO 100% 대 Franka-PPO 20%다. 저자는 Drag에서 벨트 장력이 특히 다리형의 제어를 불안정하게 만든다고 설명했는데, 결과는 그 반대다. 왜 Franka가 Drag에서 실패하는지는 논의되지 않는다. 바퀴형 베이스와 팔의 도달 범위 차이 같은 원인이 있을 수 있지만 논문 안에서는 확인할 수 없다.
학습 예산이 다르다. Place 곡선의 가로축은 Spot 5M, Franka 20M step이다. 다른 과제의 예산과 병렬 환경 수, 하이퍼파라미터는 본문에 없다. 로봇 간 비교에서 예산 차이가 얼마나 작용했는지 알 수 없다.
분산 표시가 막대에는 없다. 학습 곡선은 5 seed 평균과 표준편차인데, 막대는 “학습된 에이전트의 20회 평가”라고만 되어 있다. 5 seed 각각을 평가해 합친 것인지, 대표 seed 하나인지 밝히지 않는다. Spot-PPO의 Place 곡선은 음영이 −9,000 근처까지 내려갈 만큼 seed 간 편차가 큰데, 막대는 100%다.

실험 2: 이미지 기반 IL (§IV-B, Table III)

다리형 로봇의 천 과제 3개에서 두 IL 방법을 비교한다. BC는 고전적인 supervised behavior cloning이고, Retrieval은 DeMoBot의 retrieval 방법을 “state similarity만” 쓰도록 단순화한 것이다. 두 방법 모두 RGB를 DINOv2로 인코딩한 특징 o_b=\phi(I_{rgb})를 입력으로 쓰며, 과제당 keyboard로 모은 시연 30개로 학습한다.

방법	Uncover	Cover	Curtain
BC	85% (17/20)	60% (12/20)	60% (12/20)
Retrieval	90% (18/20)	80% (16/20)	80% (16/20)

(Table III. 괄호의 분수는 20회 평가로 필자가 환산한 값.)

평가 환경은 데이터 수집 환경과 “identical”하다. 저자는 같은 환경인데도 실패가 나는 이유로 mobile manipulator와 deformable 물체의 dynamics, 그리고 locomotion 컨트롤러의 정확도 한계를 든다. 이 표는 “학습 분포 안에서의 재현” 성능이다. 초기 상태가 바뀌었을 때의 일반화는 재지 않았다. 20회 평가에서 BC와 Retrieval의 차이는 Cover·Curtain에서 4회(12 대 16)다. 시드나 반복 학습 결과가 없어서 이 차이가 안정적인지 판단할 근거는 없다.

Spot의 Curtain 과제(시뮬레이션). 팔로 커튼을 밀어내고 그 틈으로 몸을 통과시킨다. 출처: 프로젝트 페이지 GIF.

실험 3: 실기 Spot 배포 (§IV-C, Table II, Fig. 4·5)

시뮬레이션에서 학습한 정책을 fine-tuning 없이 실기 Spot에 올린다. 대상은 Place·Drag·Curtain이다. Place에는 수영용 폼 누들, Drag에는 고무 스트레칭 밴드, Curtain에는 100 cm × 120 cm 천을 썼다. state 관측은 OptiTrack으로 얻고, 이미지는 Intel RealSense D415로 찍는다. 과제마다 사전학습 에이전트 두 개(SAC·PPO)를 그대로 배포했다.

state 기반: Place·Drag

영역	방법	Place SR	Place Steps	Drag SR	Drag Steps
Sim (60 Hz, 20회)	SAC	90%	217.6	10%	92.5
	PPO	100%	83.4	100%	81.3
Real (10 Hz, 10회)	SAC	90%	172.1	0%	–
	PPO	100%	62.6	100%	32.9

(Table II. Steps는 과제를 끝내는 데 쓴 제어 행동 수.)

Table II의 시뮬레이션 성공률(Place SAC 90·PPO 100, Drag SAC 10·PPO 100)은 Fig. 3의 Spot 막대와 정확히 같다. 즉 실기에 올린 것은 Fig. 3의 Spot 정책이다.

저자는 두 방법 모두 성공률이 sim과 real에서 잘 맞는다고 보고, SAC Drag만 실기에서 “약간” 떨어졌다고 쓴다. 원인으로는 SAC가 시뮬레이션에서 악용하는 위험한 움직임을 하드웨어 제한이 막았다는 점을 든다. 수치로 보면 SAC Drag는 시뮬레이션에서도 20회 중 2회만 성공한 정책이다. 2/20에서 0/10으로 간 것을 “sim-to-real 정렬”의 예외로 논하기에는 출발점이 이미 실패에 가깝다.

Steps 열은 해석에 주의가 필요하다. 저자는 제어 주파수가 달라(실기 10 Hz, 시뮬레이션 60 Hz) step 수가 다르지만 “전체 경향은 일관된다”고 쓴다. 논문이 적은 주파수로 시간을 환산하면 다음과 같다.

	Place SAC	Place PPO	Drag PPO
Sim (Steps ÷ 60 Hz)	3.6 s	1.4 s	1.4 s
Real (Steps ÷ 10 Hz)	17.2 s	6.3 s	3.3 s
실기/시뮬레이션 시간 비	4.7×	4.5×	2.4×

(필자 계산.)

실기는 같은 과제를 2.4~4.7배 더 오래 걸려 끝낸다. 매 step의 행동이 실기에서 6배 길게 유지되는데도 step 수가 6분의 1로 줄지 않았다는 뜻이다. “경향이 같다”는 SAC가 PPO보다 느리다는 순서가 유지된다는 의미로는 맞지만, 실행 속도가 보존된다는 의미로 읽으면 안 된다. 또한 Drag SAC의 시뮬레이션 Steps 92.5가 성공한 2회만의 평균인지, 실패 에피소드도 포함한 값인지 밝히지 않는다.

Fig. 5. Drag 과제의 PPO 롤아웃. 위: 시뮬레이션. 가운데: 벨트 위 점들의 궤적(빨강 시뮬레이션, 파랑 실기). 아래: 실기. 점의 위치는 구간마다 눈에 띄게 어긋나지만 과제는 성공한다.

실기 Spot의 Drag. 녹색 고무 밴드를 들어 기둥 너머로 넘긴다. 출처: 프로젝트 페이지 GIF.

저자는 Fig. 5의 궤적 차이를 실제 물성과 환경 조건의 불가피한 차이로 돌린다. 이 그림이 보여 주는 더 흥미로운 사실은, 물체 궤적이 꽤 어긋나도 정책이 과제를 끝낸다는 점이다. 보상과 성공 조건이 벨트 중점과 몸의 위치만 보기 때문에 벨트 모양이 정확히 같을 필요는 없다. state 기반 sim-to-real의 성공이 “물리를 잘 맞췄기 때문”인지 “과제가 물체 궤적 오차에 둔감하기 때문”인지는 이 실험으로 가를 수 없다. 물성 랜덤화나 물성을 바꾼 대조 실험이 없기 때문이다.

이미지 기반: Curtain

Fig. 4. Curtain의 sim-to-real 비교. 행마다 BC·Retrieval·수동 원격조작·시뮬레이션의 카메라 영상 시퀀스(Start·Approach·Manipulate). 위 가운데는 시뮬레이션과 실기 셋업, 오른쪽 위는 DINOv2 특징의 t-SNE(파랑 시뮬레이션, 빨강 실기). BC 행은 접근 단계에서 끝난다.

시뮬레이션에서 60~80%였던 두 정책은 실기에서 한 번도 성공하지 못했다. Retrieval은 10회 중 2회 커튼에 다가가 접촉했고, BC는 커튼에 닿지도 못했다. 저자는 원인을 두 갈래로 확인한다. 실기에서 사람이 원격조작한 관측 궤적은 시뮬레이션 궤적과 비슷했으므로 dynamics는 잘 맞는다고 보고, DINOv2 특징의 t-SNE에서 두 분포가 갈라지므로 실패의 주원인은 시각 domain gap이라고 결론짓는다.

이 진단은 그럴듯하지만 근거가 정성적이다. t-SNE는 군집 분리를 과장하는 경향이 있는 시각화이고, 분포 거리 같은 정량 지표는 없다. “관측 궤적이 비슷했다”는 판단도 수치 없이 그림 비교에 기댄다. Fig. 4의 시뮬레이션 영상(흰 배경, 단색 커튼, 격자 바닥)과 실기 영상(실험실 철골 구조와 조명)을 보면 domain gap이 크다는 것은 분명하다. 다만 렌더링 랜덤화나 배경 합성 같은 기본적인 완화책을 시도하지 않았으므로, 이 결과는 “이미지 기반 sim-to-real은 어렵다”보다 “아무 시각 랜덤화 없이 학습한 이미지 정책은 넘어가지 않는다”로 읽는 것이 정확하다.

공개 코드와 대조

본문 서론은 코드를 “논문 채택 후 공개”한다고 썼고, 지금은 carolzyy/MoDeSuite에 올라와 있다(커밋 470681a 기준). Isaac Sim 4.2.0과 Isaac Lab 위에서 동작하는 DirectRLEnv 과제 16개(8과제 × 2로봇)와 rl_games 설정, Spot locomotion 정책(controller/model/spot_policy.pt), keyboard 원격조작 스크립트가 들어 있다. IL 데이터셋과 학습된 모델은 README의 Google Drive 링크로 배포된다. 아래는 논문 서술과 코드를 정적으로 대조한 결과다. 코드는 실행하지 않았고, 공개 코드가 논문 실험 당시 코드와 같은지는 알 수 없다.

항목	논문	공개 코드
시뮬레이션 제어 주파수	60 Hz (Table II 캡션)	Spot 탄성 과제 `dt=1/200`, `decimation=2` → 100 Hz (`task/Place/spot_place_env.py:27,44`). Franka 과제 `dt=1/80`, `decimation=2` → 40 Hz (`task/Place/franka_place_env.py:29,40`). Spot 천 과제 `decimation=5` → 40 Hz (`task/Curtain/spot_curtain_env.py:26,38`). 60 Hz인 설정은 없다
Spot 행동 차원	10~18	탄성 과제 9(베이스 명령 3 + 팔 관절 6, `spot_place_env.py:29`), 천 과제 9~10(Curtain 9, Uncover·Cover 10)
Spot 베이스 행동	(p_x, p_y, r_z) “linear translation”, “rotation”	사전학습 locomotion 정책에 넣는 속도 명령 (v_x, v_y, \omega_z) (`controller/spot_loco_solver.py:61-89`). 이 보행 정책은 Isaac Lab v1.4.1 Spot flat 환경(50 Hz, action scale 0.2)과 같은 관측·스케일 구조인데, 환경 step마다(100 Hz) 호출된다. 래퍼에 정의된 `_decimation = 10`은 쓰이지 않는다 (`controller/spot_loco_solver.py:46,59,103-114`)
Spot 팔 행동	joint position a_{arm}\in\mathbb{R}^n	관절 목표 = a + \Delta t\cdot 6\cdot a \approx 1.06\,a이고 rl_games가 행동을 ±1로 자르므로(`clip_actions: 1.0`) 팔 관절 목표가 ±1.06 rad 안으로 제한된다 (`task/Place/spot_place_env.py:196-199`, `task/Place/agents/rl_games_ppo_cfg.yaml:7`)
Place 보상	3항: 막대 끝↔︎탁자, 로봇↔︎탁자, 안정성 페널티	거리 4항(로봇↔︎탁자, 손끝↔︎탁자, 막대 끝↔︎탁자, 막대 중점↔︎탁자) + 높이 보너스 2개(각 +0.75) + 성공 +10 + 넘어짐 −500 (`spot_place_env.py:300-321`)
안정성 페널티	연속 페널티로 읽힘	몸체 기울기 45° 초과 시 −500 후 에피소드 종료 (`spot_place_env.py:223-245, 321, 335`)
Curtain 성공	“without any collisions”	로봇 x 좌표가 커튼 위치 + 0.3 m를 넘었는지만 확인. 충돌 검사 없음 (`task/Curtain/spot_curtain_env.py:303-314`)
Drag 성공	몸이 body target 근처 + 벨트가 장애물 반대편 벨트 목표 근처	Spot은 `(robot_tar_dis < 0.3) & (robot_tar_dis < 0.05)`로 같은 변수에 두 문턱이 걸려 몸 문턱이 xy L1 0.05 m다. 벨트 쪽은 “벨트 노드 4개 중 2개 이상이 목표의 y를 넘었는가”만 보고, 벨트 중점↔︎목표 거리 `band_tar_dis`는 계산만 하고 판정에 쓰지 않는다 (`task/Drag/spot_drag_env.py:323-330`). Franka는 몸 문턱 0.3 (`task/Drag/franka_drag_env.py:269`)
Lift 성공	벨트 중점↔︎목표 거리 와 로봇↔︎로봇 목표 거리	벨트 중점이 목표 0.1 m 안이면 성공. 로봇 위치 조건은 없다 (`task/Lift/spot_lift_env.py:355-359`)
Bend 성공 문턱	막대 끝↔︎목표 거리(값 미기재)	Franka 0.5 m (`task/Bend/franka_bend_env.py:273`), Spot 0.3 m (`task/Bend/spot_bend_env.py:335`). 로봇마다 다르다
관측 s_e	(g_r, g_o, p_o), 장애물 위치 p_o 포함	장애물 위치는 어느 과제 관측에도 없다. 예를 들어 Spot Place 관측은 막대 4점·로봇 위치(3D)·쿼터니언·탁자 중심·전 관절 위치·속도다 (`task/Place/spot_place_env.py:283-292`)
천 과제 state 관측	추적 particle 위치 \{p_i\}_{i=1}^M	천은 손잡이 `RigidObject`로만 감싸고 particle 위치를 관측으로 내보내지 않는다. `get_cloth_point()`는 반환값 없는 미완성 함수다 (`task/Curtain/spot_curtain_env.py:281-298`)
탄성체 잡기	Drag는 “lift and stretch the belt”	막대·벨트는 로봇 USD 안 `arm_ee` 아래 prim으로 처음부터 손끝에 붙어 있다. 잡는 단계가 없다 (`task/Place/spot_place_env.py:80-85`, `task/Drag/spot_drag_env.py:61-66`)
바퀴형 베이스	Ridgeback 위의 Franka, 베이스 행동은 속도 (v_x, v_y, \omega_z)	가상 prismatic x·y + revolute z 관절로 모델링한 베이스다 (`cfg/robotcfg.py:18-43`). 바퀴 동역학은 없다. 행동은 관절 위치 목표에 \Delta t\cdotscale\cdot a를 더해 가는 누적 증분이다 (`task/Place/franka_place_env.py:192-195`)
discrete 행동	14개(잡기·놓기 포함)	키 바인딩 13개(팔 6·베이스 6·잡기 토글 1). 별도의 놓기 키는 없다 (`controller/se3_keyboard.py:173-196`)
이미지 관측(DINOv2)	이미지 관측 \phi(I)	환경은 원시 RGB를 반환한다. DINOv2 경로는 `process = False`로 꺼져 있고 `self.encoder`는 어디에서도 정의되지 않는다 (`spot_curtain_env.py:212-233`)
IL 방법(BC·Retrieval)	§IV-B에서 평가	학습·평가 코드가 레포에 없다. 시연 수집 스크립트(`script/teleop_se3_agent.py`)만 있다
초기 상태	언급 없음	모든 과제가 고정된 기본 자세로 리셋한다. 코드 주석이 “should be random initial pose, however all zero now”라고 적는다 (`spot_place_env.py:169`)
병렬 환경 수	“parallelized environments”, 수는 미기재	과제 config 기본값 `num_envs=4`, `script/train.py`의 CLI 기본값 1
에셋	바퀴형 8개 과제	Franka Lift·Drag·Transport와 천 과제가 참조하는 USD 3개(`Franka.usd`, `franka_drag.usd`, `franka_rod_long.usd`)가 레포에 없다. Franka 과제 중 레포 에셋만으로 로드되는 것은 Place·Bend뿐이다
Franka 천 과제	Fig. 1에 바퀴형 천 과제 3개가 그려져 있다	Uncover의 성공 함수 `cover_check()`는 정의만 되고 호출되지 않아 성공 플래그가 늘 0이고, 함수 본문도 Place의 막대 판정(`self.rod`, 탁자 범위)을 그대로 복사한 것이다 (`task/Uncover/franka_uncover_env.py:275-304`). Cover의 `pass_flag()`는 정의되지 않은 변수 `curtain_position`·`robot_current_position`을 참조하므로 `_get_dones()`에서 호출되는 순간 NameError가 난다 (`task/Cover/franka_cover_env.py:342-355`)
평가 스크립트	20회 평가	`script/play.py`의 에피소드 집계와 20회 후 종료가 `if args_cli.video:` 블록 안에만 있다. 영상 기록 옵션 없이 돌리면 에피소드를 세지 않고 끝나지 않는다 (`script/play.py:205-227`)

가장 무게가 큰 것은 성공 판정과 초기 상태다. 첫째, 성공 판정이 논문 서술보다 느슨한 곳이 셋이다. Curtain은 충돌 검사 없이 x 좌표만 보므로 커튼을 밀어내지 않고 뚫고 지나가도 성공으로 셀 수 있다. Lift는 로봇이 목표에 갔는지 보지 않는다. Drag는 벨트가 목표 근처인지가 아니라 목표선을 넘었는지만 본다. 둘째, 같은 과제의 성공 문턱이 로봇마다 다르다(Bend는 Franka 0.5 m, Spot 0.3 m. Drag의 몸 문턱은 Franka 0.3, Spot 0.05). 그러니 Fig. 3에서 Bend를 “Franka 100%, Spot 0%”로 비교하는 것은 같은 기준의 비교가 아니다. 셋째, 초기 상태가 고정이면 20회 평가의 성공률은 같은 시작점에서 정책과 물리의 확률성만 반영한다. IL의 “identical environment” 평가와 같은 성격이고, 벤치마크로서 일반화를 재는 장치가 없다는 뜻이다. 공개 코드가 논문 실험 당시와 같은 판정을 썼는지는 알 수 없으므로, 이 차이는 “논문 수치가 틀렸다”가 아니라 “레포로 재현하면 논문이 말한 것과 다른 과제를 재게 된다”로 읽어야 한다.

바퀴형 천 과제가 미완성 사본이라는 점은 논문의 실험 구성과도 맞물린다. 논문은 천 과제를 다리형 로봇의 IL로만 평가했고, Fig. 1의 바퀴형 천 과제 3칸에 대응하는 결과는 어디에도 없다. 공개 코드 기준으로 “8개 과제 × 2개 로봇 = 16개 환경”이 모두 쓸 수 있는 상태는 아니다.

그 밖의 관찰도 있다. 16개 환경 중 11개(탄성 과제 10개와 Franka Uncover)는 _get_dones()가 (time_out, resets) 순서로 반환하는데, Isaac Lab 규약은 (terminated, time_outs)다. 제공된 rl_games 설정에 value_bootstrap이 없어 두 플래그를 같은 done으로 취급하므로 학습 결과에는 영향이 없을 가능성이 높지만, 규약대로 bootstrapping을 켜면 성공·넘어짐 종료가 time-out처럼 처리된다. 저장소에는 LICENSE 파일이 없고(README 배지는 MIT), Spot locomotion 컨트롤러 등 일부 파일 머리에는 NVIDIA의 재배포 제한 문구가 남아 있다. README의 실행 예시는 scripts/ 경로를 쓰지만 실제 폴더 이름은 script/이고, 과제 표에서 Drag는 “rod”로, Cover는 Uncover와 같은 설명으로 적혀 있다.

비판적으로 보면

강점

문제 설정이 명확하고 과제가 잘 골라졌다. Bend의 L자 복도, Lift의 롤러 셔터, Drag의 늘어나는 벨트는 “변형을 이용해야 풀린다”는 조건을 기하로 강제한다. rigid로 바꾸면 과제가 불가능하거나 쉬워지는 구조라, deformability가 장식이 아니라 과제의 본질이다.
같은 과제를 두 로봇 형태로 돌린다. Fig. 3의 표에서 보듯 같은 과제의 난이도가 로봇에 따라 뒤집힌다(Drag는 Spot이 쉽고, Bend·Transport는 Franka만 풀린다). 이런 비교는 형태(morphology)를 벤치마크 축으로 넣었기 때문에 가능하다.
실기 검증이 있다. 벤치마크 논문으로는 드물게 탄성 과제 2개를 실기 Spot에서 확인했고, 실패한 이미지 기반 결과(Curtain 0/10)도 숨기지 않고 보고했다. Fig. 4의 t-SNE와 원격조작 비교는 실패 원인을 좁히려는 시도로서 의미가 있다.
state 표현이 실기와 연결되도록 설계됐다. 물체를 점 4개로 요약한 관측은 학습을 쉽게 하면서 모션캡처로 바로 측정할 수 있다. 이 선택이 Place·Drag의 zero-shot 이전을 가능하게 한 핵심으로 보인다.
코드와 에셋이 공개됐다. 16개 환경, 로봇·물체 USD, Spot locomotion 정책, 시연 데이터와 모델(Drive)이 함께 있다.

약점·한계

벤치마크의 재현 정보가 본문에 없다. 하이퍼파라미터, 병렬 환경 수, 학습 시간과 하드웨어, 보상 가중치와 거리 문턱, 물성치(탄성 계수, 천 강성), FEM 메시 해상도가 하나도 없다. 성공률도 숫자 없이 막대로만 준다. 일부는 공개 코드의 config에서 찾을 수 있지만, 코드가 논문과 다른 곳(제어 주파수, 행동 차원, 보상 항)이 있어 어느 쪽이 논문 수치를 낸 설정인지 확정할 수 없다.
평가 프로토콜이 일반화를 재지 않는다. 공개 코드에서는 모든 과제가 고정된 초기 상태로 리셋하고, 물체 모양·크기·물성 변화도 없다(결론도 모양 조절이 GUI에서만 가능하다고 인정한다). IL은 수집 환경과 “identical”한 환경에서 평가한다. 벤치마크가 알고리즘을 비교하는 도구가 되려면 초기 상태 분포와 held-out 변형(다른 막대 길이, 다른 천 크기)이 필요하다. 공개 코드에서는 같은 과제의 성공 문턱마저 로봇마다 달라(Bend 0.5 m 대 0.3 m), Fig. 3의 로봇 간 비교가 같은 기준인지도 확인할 수 없다.
결과 서술이 자기 그림과 어긋난다. “PPO가 SAC보다 낫고 예외는 Spot Bend”(실제로는 Spot Bend 동률 0%), “모든 과제를 풀 수 있다”(Spot 설정 2개는 0%), “다리형이 Drag에서 특히 불안정”(실제로는 Spot이 Drag 100%, Franka 20%), “Franka = fixed-base manipulator”(Ridgeback 위의 이동형), “Fig. 1은 다섯 과제”(8과제), “막대 그림은 오른쪽 위”(아래쪽), “Section III-D”(III-B), 정의되지 않은 “hypermode”. 하나하나는 작지만, 벤치마크 논문에서 결과 서술의 신뢰도는 곧 비교 기준의 신뢰도다.
“첫 번째”의 근거가 좁다. Table I에서 MoDeSuite를 TDW Transport·DEDO와 구분하는 열은 Legged-M 하나이고, ORBIT과 구분하는 Elastic 열은 MoDeSuite가 쓰는 Isaac Lab FEM 기능 그 자체다. 천 과제 3개는 같은 1저자의 DeMoBot에서 왔다. 기여는 “다리형까지 포함해 mobile + deformable 과제를 한 인터페이스로 묶은 것”으로 보는 것이 정확하다.
IL 비교가 얇다. 시연 30개, 한 가지 인코더(DINOv2), 두 가지 방법이고, 그중 Retrieval은 저자 이전 연구의 단순화판이다. diffusion policy 같은 현재의 표준 IL 기준선이 없고, BC와 Retrieval의 차이(20회 중 1~4회)는 시드 반복 없이 판단하기 어렵다. 공개 코드에는 BC·Retrieval 구현과 DINOv2 인코딩 경로도 없어서 Table III를 레포만으로 재현할 수 없다.
sim-to-real 결론이 과제의 둔감함과 섞여 있다. Place·Drag 성공은 물리 정합성 덕분일 수도, 성공 조건이 물체 궤적 오차에 둔감하기 때문일 수도 있다(Fig. 5에서 점 궤적이 어긋나도 성공). 물성을 바꾼 대조 실험이나 domain randomization 유무 비교가 없어 둘을 가를 수 없다. 실기 제어 인터페이스(Spot SDK로 무엇을 지령했는지, 10 Hz 루프에서 행동을 어떻게 유지했는지)도 서술되지 않는다.
Curtain의 시각 gap 진단이 정성적이다. t-SNE 분리와 “관측 궤적이 비슷했다”는 그림 비교뿐이다. 시각 랜덤화를 하나도 쓰지 않은 상태의 실패이므로, 이 결과로 이미지 기반 sim-to-real의 난이도를 일반화하기는 어렵다.

요약

MoDeSuite는 mobile manipulation과 deformable manipulation의 교집합을 Isaac Lab 위의 8개 과제로 고정한 task suite다. 탄성 막대·벨트 과제 5개는 FEM, 천 과제 3개는 PBD로 시뮬레이션하고, 바퀴형과 다리형 로봇, state와 이미지 관측, 여러 행동 공간을 바꿔 끼울 수 있다. 실험은 PPO가 SAC보다 대체로 낫고, Spot이 좁은 복도 과제 두 개를 풀지 못하며, state 기반 PPO 정책은 실기 Place·Drag에서 10/10을 성공하지만 이미지 기반 IL은 실기 Curtain에서 0/10이라는 것을 보인다.

한계는 벤치마크로서의 엄밀함 쪽에 있다. 재현 정보(하이퍼파라미터, 병렬 환경 수, 물성치, 보상 가중치)가 본문에 없고, 성공률은 숫자 없이 막대로만 주며, 결과 서술 여러 곳이 자기 그림과 어긋난다. 공개 코드는 고정된 초기 상태, 충돌 검사 없는 Curtain 성공 판정, 논문과 다른 제어 주파수, IL 코드 부재를 보여 준다. 그래서 지금의 MoDeSuite는 알고리즘 순위를 매기는 표준 벤치마크라기보다, “이동하면서 변형을 이용해야 하는 과제”를 바로 돌려 볼 수 있는 출발점으로 쓰는 편이 맞다. 초기 상태 랜덤화, 물체 변형의 held-out 세트, 숫자로 된 결과표가 더해지면 벤치마크로서의 가치가 크게 올라갈 것이다.

이 글에 대해

읽은 범위: arXiv v1(2025-07-29, 9쪽)을 HTML과 PDF로 읽었다. 저자 연구실 페이지와 코드 README는 이 논문을 IEEE RA-L 2026으로 표기하지만, 저널판 본문은 대조하지 않았으므로 저널판에서 수치·서술이 바뀌었을 수 있다. 그림 5장은 arXiv HTML의 원본 그림이다. 프로젝트 페이지의 본문과 그림을 함께 보았다.
공개 범위와 코드 대조: 코드는 carolzyy/MoDeSuite 커밋 470681a 기준으로 읽었다. “공개 코드와 대조” 절의 내용은 모두 정적 대조이며, 코드를 실행하거나 논문 수치를 재현하지 않았다. 표의 파일:라인은 이 커밋 기준이다.
영상: 본문의 영상 3개는 프로젝트 페이지의 GIF를 640 px 폭 mp4로 옮긴 사본이다.
표기: Fig. 3의 성공률 표는 막대 높이에서 읽은 근사치다. “필자 계산·환산”은 논문 표 값으로 직접 계산한 값(평균, 20회 기준 분수, 주파수 환산 시간)이다.