Co-NavGPT 읽기 — 네 개의 질문으로

Co-NavGPT: Multirobot Cooperative Visual Semantic Navigation Using Vision Language Models
Bangguo Yu, Qihao Yuan, Kailai Li, Hamidreza Kasaei, Ming Cao · IEEE Robotics and Automation Letters, Vol. 11, No. 2, February 2026

연구실 세미나로 다룬 논문입니다. 여러 대의 로봇이 미지의 실내를 협력해 돌아다니며 목표 물체를 찾는데, 그 "어디로 갈지"를 Vision Language Model이 정하는 프레임워크입니다.

먼저 솔직하게 — 저는 SLAM·localization 쪽을 하다 보니 VLM은 잘 모르는 분야입니다. 그래서 이 글은 전문가의 해설이 아니라, 잘 모르는 사람이 논문을 읽어낸 과정에 가깝습니다. 마침 주제가 VLM이니만큼 진행도 그 방식 그대로 갑니다 — 모르는 상태에서 추론을 먼저 내놓고, 답을 확인하고, 채점합니다.

읽기 전에 본문 어휘를 한 번 세어봤습니다. 논문이 실제로 무엇에 지면을 쓰는지는 초록의 주장보다 빈도가 더 정직하게 보여주는 경우가 있어서요. 그리고 방법론은 논문만이 아니라 저자들이 공개한 구현(Co-NavGPT2)을 함께 대조했습니다. 논문 서술로는 애매하던 부분이 코드에서 풀리기도 했고, 반대로 어긋나는 곳도 나왔습니다.

읽는 순서

Q1–Q4 네 개의 질문, 네 개의 추론 한 문장이 네 질문으로 갈라지고, 질문마다 추론 R1~R4를 답니다
S1–S4 네 개의 답 각 질문에 논문과 코드가 어떻게 답하는지
RESULTS 실험 결과 베이스라인 비교와 어블레이션
D1–D4 비판적 검토 네 가지 물음 — 그리고 키 순서 하나를 바꿔 직접 돌린 실험
F1 확장 방향 TARE 계보가 먼저 간 길에서 배우기

먼저, 어휘를 세어보면

제목부터 결론까지를 통째로 세었습니다. 참고문헌 목록과 페이지 워터마크는 제외했고, 단수/복수는 하나로 합쳤습니다.

추출 원문 6,581 단어 본문 토큰 5,137 불용어 제거 후 3,011 고유어 1,102 상위 5개 점유 10.5%

상위 어휘가 네 갈래로 갈립니다

주제별로 묶은 해석적 분류입니다. 아래 순위 차트의 막대 색이 이 분류를 따릅니다.

최다 빈출 키워드 20

막대에 마우스를 올리면 점유율과 분류가 표시됩니다.

frontier가 4위라는 게 방법론의 핵심 단서입니다. VLM이 좌표를 자유롭게 생성하는 게 아니라 프론티어 후보를 로봇들에게 배분하는 구조라는 뜻이죠. 반대로 training/learning 계열은 상위 40위 안에 아예 없습니다 — "과제별 학습 없이 zero-shot으로 동작한다"는 주장과 어휘 분포가 맞습니다.

재미있는 건 이 네 갈래를 논문의 파이프라인 순서대로 이으면 논문 한 편이 한 문장이 된다는 점입니다.

Co-NavGPT, 한 문장

여러 로봇이 각자 만든 부분 맵을 로봇 상태와 프론티어 영역이 인코딩된 하나의 전역 맵으로 합친 뒤, VLM이 전역 플래너로서 각 로봇에 프론티어를 배분해, 별도의 과제별 학습 없이 미지 환경에서 목표 물체를 협력 탐색하도록 하는 프레임워크.

Q1 – Q4

네 개의 질문, 네 개의 추론

주제가 VLM이니만큼, 이 글도 같은 방식으로 갑니다 — 답을 보기 전에 추론(R)부터 내놓고, 뒤에서 채점합니다.

여러 로봇이 각자 만든 부분 맵을 어떻게 합칠까?

로봇은 각자의 local coordinate 위에 존재할 텐데, 어떻게 global coordinate으로 합칠까?

R1. ICP 같은 registration으로 transformation을 구하지 않을까?

로봇 상태와 프론티어 영역을 어떻게 인코딩할까?

어떤 "정보"를 맵에 담아 VLM에게 건넬까?

R2. VLM이 잘 이해하는 이미지를 사용해서 인코딩하지 않을까?

VLM이 전역 플래너로서 프론티어를 어떻게 배분할까?

어떠한 "기준" 또는 "목적"으로 배분할까?

R3. 거리나 의미적 단서를 사용하지 않을까?

미지의 환경에서 목표 물체를 어떻게 협력 탐색할까?

각 로봇은 어떻게 "협력적"으로 탐색하고 주행할까?

R4. 역할을 나눠서 협력적으로 navigation 하지 않을까?

S1 – S4

네 개의 답

각 답의 입력과 출력을 따라가면 시스템이 실제로 무엇을 주고받는지 보입니다.

S1. G-ICP 기반 맵 병합

Pose + RGB-D → 3D Merged Map

각 로봇이 자기 좌표계에서 포인트 클라우드를 만들고, G-ICP로 둘 사이의 변환을 구한 뒤 한쪽 좌표계로 옮겨 붙입니다. 여기서부터 로봇들은 같은 지도를 봅니다. 협력이 성립하는 출발점입니다.

다만 어떻게 합치는지는 환경에 따라 다릅니다. G-ICP는 실환경에서만, 그것도 카메라가 아닌 LiDAR 맵으로, 탐색 시작 전 1회만 돕니다. 시뮬레이션(HM3D)은 모든 로봇이 같은 지점에서 출발하고 시뮬레이터가 정확한 자세를 주므로 정합 자체가 필요 없습니다. 이 차이는 D1에서 다시 다룹니다.

S2. 2D Top-view 프론티어 이미지

3D Merged Map → Frontier Candidate Maps

3D 클라우드를 위에서 내려다본 2D 격자로 눌러 담습니다. 채널이 셋입니다.

obstacle  ← 카메라 높이 밴드(0.23~1.53m) 안의 점만
explored  ← 그 아래 모든 점
top-view  ← 각 칸에서 가장 높은 점의 색 (z-buffer)

obstacle은 의미 판단이 아니라 높이 검사입니다. 벽이든 의자든 사람이든 밴드에 걸리면 똑같이 1이 됩니다. 그래서 explored=1, obstacle=0인 칸은 0.23m 아래에만 점이 있는 칸 — 즉 바닥만 보인 칸입니다.

프론티어 = 바닥이 보인 곳과 아무것도 못 본 곳의 경계

거기까지는 갈 수 있고(바닥 확인됨) 그 너머는 모릅니다(미관측). 그래서 가면 새로 보입니다. 계산은 뺄셈인데, 빼는 대상이 면이 아니라 선입니다.

① findContours(explored)      → 탐색 영역의 윤곽선 (1픽셀)
② ① − dilate(obstacle, 7×7)  → 벽에 닿지 않은 부분만 남음
③ 붙어 있는 칸끼리 묶기       → 후보 하나 = 갈 수 있는 방향 하나

장애물 쪽을 굳이 부풀리는 건 두 채널의 픽셀이 정확히 맞지 않아, 그냥 빼면 벽을 따라 실오라기 같은 가짜 프론티어가 남기 때문입니다.

마지막으로 후보마다 지도 이미지를 한 장씩 만듭니다. 배경과 로봇 표시는 모든 장에 동일하고, 빨간 마스크와 좌상단 번호만 장마다 바뀝니다.

R0, R1     로봇의 고유 ID
빨간 선     그 장의 프론티어 (5×5 dilate로 굵게)
좌상단 숫자 후보 번호

S3. 멀티모달 프롬프팅

Candidate Maps + Prompt → Assigned Frontier

시각 프롬프트(후보 이미지 N장)와 텍스트 프롬프트(고정 템플릿 한 벌)를 함께 넣습니다. 후보를 한 장에 다 그리면 VLM이 "3번 프론티어"를 특정하지 못하므로, 장 단위로 쪼개 식별 부담을 없앤 것이 이 논문의 핵심 트릭입니다.

배분 기준은 둘입니다 — 협력적 탐색(로봇들이 흩어져 커버리지를 넓히도록)과 의미적 관련성(목표가 있을 법한 쪽으로). 두 번째가 VLM을 쓰는 이유입니다. "sink를 찾아라"면 침실 쪽보다 타일과 싱크대가 보이는 쪽을 고르는 판단이죠.

출력이 JSON이어야 하는 이유는 그 답이 곧 좌표가 되기 때문입니다. 사람이 읽는 게 아니라 코드가 받아 즉시 실행합니다.

"frontier_1" → split('_')[1] → 1
             → target_point_list[1] → [237, 194]
             → goal_map[237,194] = 1   # 로봇 출발

S4. Global – Local 정책

Assigned Frontier → Action

VLM은 "어디로"만 정하고, 거기까지 가는 건 FMM이 맡습니다. 논문이 이유를 명시합니다 — VLM은 고수준 계획엔 강하지만 세밀한 저수준 제어에는 신뢰도가 떨어지기 때문입니다.

FMM(Fast Marching Method)은 그래프 탐색이 아닙니다. 목표 지점에서 물결이 퍼지듯 격자 전체에 "목표까지의 거리"를 채우고, 그 거리장의 기울기 방향 — 즉 내리막 — 을 따라 한 걸음씩 내려갑니다.

9 8 7 6 7 8      각 숫자 = 그 칸에서 목표까지의 거리
8 7 6 5 6 7      ███ = 벽,  G = 목표
7 6 5 4 5 6
6 5 ███ 3 4      한 번 풀어두면 어느 지점까지의 거리든
5 4 3 2 1 2      배열 인덱싱 한 번으로 조회 가능
4 3 2 1 G 1

마지막으로 이산 행동 하나로 바꿉니다. 다음 지점의 방위각과 현재 방향을 비교해 많이 틀어져 있으면 회전, 방향이 맞으면 전진 25cm입니다.

정리 — 두 개의 주기

구조를 이해하는 열쇠는 루프가 두 박자로 돈다는 것입니다. VLM 호출은 25스텝에 한 번뿐이고, 나머지 24스텝 동안 로봇은 이미 받은 목표를 향해 스스로 움직입니다.

매 스텝

S1 지각 · 병합 S2 맵 생성 S4 주행

25 스텝마다

S2 프론티어 추출 S3 VLM 배분

채점 — 네 추론은 얼마나 맞았나

답을 다 확인했으니, 처음의 R1~R4를 채점해봅니다.

추론	채점	근거
R1. registration으로 변환을 구할 것	◯	맞음 — G-ICP였습니다 (단, 시뮬레이션은 D1)
R2. VLM이 잘 이해하는 이미지로 인코딩	◯	맞음 — top-view 이미지 + 빨간 마크
R3. 거리·의미 단서로 배분	╱	빗나감 — 기준은 프롬프트 속 한 줄뿐, 거리는 시스템이 계산해 주지 않습니다
R4. 역할을 나눠 협력 주행	△	절반 — Global·Local 분리는 맞지만, 그 Local의 실체는 D3

중요한 건 채점 결과보다 과정입니다. 추론을 내놓고 답과 비교하며 틀린 곳을 확인하는 것 — 이 방식이 뒤의 D2에서 예상 못 한 방식으로 다시 등장합니다.

RESULTS

실험 결과

HM3D 1,000 에피소드, 그리고 4족 로봇 2대의 실환경 데모.

베이스라인 셋과 비교합니다. Greedy는 가장 가까운 프론티어를 고르고, Cost-Utility는 프론티어 크기와 거리를 함께 따집니다. Multi-SemExp는 결이 다른데, 학습된 정책이 물체 간 배치 관계로부터 목표가 있을 법한 위치를 알려줍니다.

지표는 셋입니다 — SR(성공률), SPL(경로 길이로 가중한 성공률), DTG(종료 시점의 목표까지 거리).

Table I, 2-agent 결과 발췌.
방법	SR	SPL
Greedy	0.611	0.328
Multi-SemExp	0.612	0.327
Cost-Utility	0.625	0.323
Co-NavGPT	0.681	0.369

Table II, 어블레이션 (2-agent, HM3D).
조건	SR	Δ	SPL
Full	0.681	—	0.369
w/o Reason	0.660	−0.021	0.337
DownSam. (60×60)	0.675	−0.006	0.346
Obs. (의미 제거)	0.679	−0.002	0.358

성능을 가장 크게 떨어뜨리는 건 reason 필드 제거입니다. 이 부분은 뒤의 D2에서 다시 짚습니다.

D1 – D4

비판적 검토

공개 코드를 함께 읽고 나서 남은 네 가지 물음.

D1. 실험에서는 맵 병합을 하지 않습니다

S1은 G-ICP 병합을 답으로 내놓지만, 정량 실험(HM3D)에서는 그 절차가 실행되지 않습니다.

point_sum += agent[i].point_sum # main.py — 이게 전부

모든 로봇이 같은 지점에서 출발하고(방향만 다름) 시뮬레이터가 정확한 자세를 주므로 처음부터 같은 좌표계 위에 있습니다. 합치기는 덧셈 한 줄입니다.

멀티로봇 SLAM에서 어려운 부분은 원래 정합입니다 — 서로 어디 있는지 모르는 로봇들의 상대 변환을 찾고 드리프트를 보정하는 것. 그 문제가 실험 설정에서 아예 발생하지 않습니다. G-ICP는 실환경 데모에만 등장하고, 그것도 StaticTransformBroadcaster로 한 번 계산해 고정합니다. 주행 중 재정렬은 없습니다.

D2. 추론을 시키지만 추론할 공간이 없습니다

텍스트 프롬프트에 Let's think step by step.이 들어 있습니다. 예시 없이 이 한 문장만으로 모델이 답보다 추론을 먼저 쓰게 만드는 zero-shot CoT(Kojima et al., NeurIPS 2022)입니다. GSM8K에서 10.4% → 40.7%를 낸 기법이죠.

작동 원리는 생성 순서에 있습니다. LLM은 토큰을 앞에서부터 뽑으니, 중간 단계를 먼저 뱉어놓으면 그 토큰들이 뒤따르는 답의 조건이 됩니다. 그런데 이 구현에서는 두 가지가 그것을 막습니다.

첫째, JSON 모드가 사고 공간을 봉쇄합니다. response_format={"json_object"}는 첫 토큰부터 JSON만 허용하므로, Let's think step by step.이 있어도 풀어놓을 자리가 없습니다.

둘째, reason이 결정 뒤에 옵니다.

{
    "robot_0": "frontier_1",     ① 생성
    "robot_1": "frontier_0",     ② 생성
    "reason":  "..."             ③ 생성 — ①②를 보고 씀
}

배분을 확정한 뒤에 이유를 씁니다. 추론이 답을 만드는 게 아니라 답이 추론을 만듭니다. 원조 CoT 계열은 반대입니다 — Kojima는 아예 호출을 둘로 나눠 추론 단계에서는 형식 제약을 걸지 않고, 답은 "Therefore, the answer is"로 따로 뽑습니다.

그래서 reason은 해석 가능성의 외형이지 검증이 아닙니다. 여기서는 가능성의 문제가 아니라 생성 순서가 그것을 보장합니다.

그런데 어블레이션에서는 이걸 제거했을 때 낙폭이 가장 컸습니다(−0.021). 답 뒤에 생성되는데 왜 영향을 줬을까요. 논문 정보만으로는 구분할 수 없습니다. 다만 이건 확인 가능한 질문입니다 — reason을 앞으로 올리면 정말 좋아질까? 논문에 이 실험이 없어서, 직접 돌려봤습니다.

D2-실험. JSON 키 순서 하나를 바꿔봤습니다

미리 두 가지를 밝혀둡니다. 첫째, 이건 아주 작은 스케일입니다 — 고정 에피소드 20개짜리 파일럿이라, 결론이 아니라 방향을 보는 실험으로 읽어주세요. 둘째, 저는 VLM 실험 설계 경험이 없습니다. 놓친 변수나 잘못 잡은 설정이 있을 수 있으니, 이상한 부분이 보이면 짚어주시면 감사하겠습니다.

설계는 최대한 단순하게 — 원래 코드 그대로 gpt-4o(temperature 0.1, json_object), HM3D에서 chair와 tv_monitor 에피소드를 고정해 각 10회씩. 조건은 둘입니다.

A. 정답 뒤 (원래 코드)   {robot_0, robot_1, reason}   = 사후 정당화
B. 정답 앞 (CoT)        {reason, robot_0, robot_1}   = 추론이 답에 선행

유일한 차이 = JSON 안 토큰 순서.  프롬프트·모델·씬 완전 동일.

키 순서만 바꾼 A/B 결과. 20 에피소드 파일럿입니다.
에피소드	조건	success ↑	SPL ↑	DTG (m) ↓	fallback ↓
chair	정답 뒤 (post-hoc)	2/10	0.073	2.65	26%
chair	정답 앞 (CoT)	2/10	0.088	1.94	13%
tv_monitor	정답 뒤 (post-hoc)	7/10	0.638	3.93	62%
tv_monitor	정답 앞 (CoT)	8/10	0.690	2.67	30%
종합 (20ep)	정답 뒤 (post-hoc)	9/20	0.356	3.29	37%
종합 (20ep)	정답 앞 (CoT)	10/20	0.389	2.31	18%

성공률 차이는 1판이라 유의하지 않습니다. 주 신호는 나머지 두 지표입니다 — DTG(종료 시점 목표까지 남은 거리)가 3.29m에서 2.31m로 1m 가까이 줄었고, fallback(무효 JSON으로 기본값에 떨어진 비율)이 37%에서 18%로 절반이 됐습니다. reason을 먼저 쓰게 했더니 형식 오류 자체가 줄어든 겁니다.

왜 좋아졌을까. reason 텍스트를 뜯어보면, 길이도 어휘도 거의 동일합니다 — "말을 더 많이 해서"가 아닙니다. 유일하게 갈린 건 하나, 안 고른 후보까지 3개 이상 비교하는 비율이 0% vs 31%였습니다.

정답 뒤:  "Robot_0 is closer to frontier_2 ..."           ← 이미 고른 2개만 서술
정답 앞:  "Robot_0 is closer to frontiers 3 and 4,
           while Robot_1 is closer to 0, 1, 2, 5 ..."     ← 고르기 전이라 후보 전체를 비교

사후 정당화와 진짜 추론의 차이가 텍스트에 그대로 드러납니다.

반증도 하나 얻었습니다. 처음 가설은 "비교를 하면 두 로봇을 다른 구역으로 분업시켜 중복 배정이 줄 것"이었는데, 데이터는 정반대였습니다 — 같은 프론티어에 두 로봇을 보내는 중복 배정이 3.4% → 19.7%로 오히려 6배. 그런데도 DTG와 SPL은 CoT가 더 좋습니다. 커버리지 분업은 성능 향상의 이유가 아닙니다.

남는 열린 질문 — 후보를 '비교'하는 것이 왜 성능이 되는가. 저희 가설은 이렇습니다. 배분은 결국 argmax 문제인데, 비교 없이 고르면 '최선'이 아니라 '그럴듯한 것'을 고르게 됩니다. 다만 비교 → 더 나은 배분의 인과 고리는 직접 검증하지 못했고 (비교를 강제/금지하는 조건을 나눠 돌리면 분리할 수 있을 겁니다), 20 에피소드는 방향을 보여주는 파일럿입니다. 그리고 VLM을 잘 모르는 사람이 설계한 실험인 만큼 해석 자체가 틀렸을 수도 있습니다 — 그래서 더더욱 결론이 아니라 논의거리로 열어둡니다.

D3. 로컬 주행은 시뮬레이터의 정답 기하를 씁니다

논문은 로컬 경로를 FMM이 짠다고 서술하는데, 코드를 보면 FMM이 주 경로가 아닙니다.

plan_path = self.search_navigable_path(goal)   # ① 시뮬레이터 navmesh
if len(plan_path) > 1:
    action = self.greedy_follower_act(plan_path)
else:
    self.stg, ... = self._get_stg(...)          # ② FMM — ①이 실패할 때만
    action = self.ffm_act()

①을 따라가면 _sim.get_straight_shortest_path_points(), 즉 Habitat 시뮬레이터의 navmesh를 직접 조회합니다. 로봇이 만든 맵이 아니라 환경의 정답 기하입니다. 게다가 실패하면 주변 8개 점을 더 시도해 총 9번 도전하므로, 시뮬레이션에서 FMM은 사실상 예비용입니다.

목표(프론티어)는 여전히 VLM이 정하지만, 거기까지의 경로에는 특권 정보가 들어갑니다. 절대 성능(SR 0.68)은 그 위에서 나온 값입니다.

반대로 실환경 코드에는 이 navmesh 경로가 없습니다. 거기서는 FMM만 돕니다. 시뮬과 실환경의 로컬 정책이 서로 다른 코드인 셈이라, 시뮬 결과가 실환경에서 실제로 도는 경로를 검증하지 못합니다.

D4. 실환경 5 FPS는 VLM을 자주 안 부르기 때문입니다

실환경 데모에서 5 FPS가 나옵니다. 비교 대상인 Shen et al.의 방법은 multimodal CoT 기반 점수 협의 구조라 시뮬레이션에서도 0.5 FPS 미만입니다. 차이의 원인은 VLM 호출 빈도입니다.

VLM  25 스텝에 1회   "어디로"   ← 전체 스텝의 4%
FMM  매 스텝         "어떻게"   ← 나머지 96%, 전부 해석적 계산

시간 예산:  5 FPS × 25 스텝 = VLM 한 번에 5초

매 스텝 불렀다면 0.2초 안에 끝나야 하는데, 원격 API로는 불가능합니다. 최적화해서 빨라진 게 아니라 안 부르니까 빨라진 것이고, 그 판단의 근거도 속도가 아니라 "VLM은 저수준 제어에 신뢰도가 떨어진다"였습니다. 실시간성은 역할 분리의 부산물인 셈입니다.

대신 대가가 있습니다 — 프론티어가 잘못 배분되면 다음 호출까지 25스텝 동안 대처할 방법이 없습니다.

확장 방향 — TARE 계보에서 배우기

전통 탐색 플래너들이 먼저 간 길에, Multi-Robot VLN이 갈 방향이 있습니다.

TARE(RSS 2021)에서 출발한 계보가 멀티로봇으로 확장되며 세 갈래로 갈라졌습니다. 흥미로운 건 세 축 모두 Co-NavGPT가 가정으로 치워둔 것이라는 점입니다.

TARE 계보의 세 확장과 Co-NavGPT의 대응 상태.
축	논문	푼 문제	Co-NavGPT
통신	M-TARE Sci. Robotics 2023	대규모 환경 + 제한된 통신	통신 제약 없음
상대 위치	MUI-TARE RA-L 2023	초기 위치 미지 상태의 맵 병합	같은 위치에서 시작
이질성	HEHA 2025	로봇마다 주행 능력이 다름	동일 로봇 가정

F1-(b) 제한된 통신

M-TARE의 핵심은 표현 해상도를 둘로 나눈 것입니다. 근거리는 고해상도로 정밀하게, 원거리는 저해상도로 가볍게 유지합니다. 저해상도 전역 맵이 통신 비용을 낮춘다는 게 멀티로봇 확장의 열쇠였습니다.

통신 범위 밖으로 나간 로봇을 다시 잇는 방법으로는 "pursuit" 전략을 제안합니다. 미리 약속한 장소에서 만나는 rendezvous 방식과 달리, 정보 교환이 탐색을 빠르게 할 때만 기회주의적으로 서로 접근합니다. 로봇 20대, 통신 범위 10~300m로 1,400회 이상 실험해 rendezvous 계열보다 우수함을 보였습니다.

VLN으로 옮기면 — top-view를 압축해 공유하고, "지금 만날 가치가 있는가"를 VLM이 판단하게 하는 방향이 자연스럽습니다.

F1-(c) 초기 위치를 모를 때

MUI-TARE는 D1에서 본 가정을 정면으로 없앱니다. 로봇들이 서로 어디 있는지 모르는 상태에서 시작하죠.

기존 방식에는 딜레마가 있었습니다. 단일 프레임 매칭은 빠르지만 오정합 위험이 크고, 시퀀스 매칭은 견고하지만 한 로봇이 다른 로봇의 궤적을 길게 되짚어야 해서 중복 탐색이 생깁니다. MUI-TARE는 병합 품질 점수를 두고 임계값에 못 미칠 때만 더 되짚게 합니다.

또 하나 배울 점은 협력을 단계적으로 켠다는 것입니다. 병합 전에는 각 로봇이 독립적으로 계획하고, 병합 후에야 협력합니다. 공통 좌표계가 확립돼야 협력이 의미를 갖기 때문입니다.

F1-(d) 이종 로봇

바퀴 로봇은 계단을 못 오르고 다리 로봇과 드론은 오릅니다. HEHA의 예시가 좋은데 — 계단을 먼저 발견한 건 지상 로봇인데 갈 수 있는 건 다리 로봇입니다.

가장 중요한 통찰은 목적함수를 바꾼 것입니다.

기존 (min-sum):  Σ 모든 로봇의 경로 길이   → 총 이동량 최소화
HEHA (min-max):  max 로봇별 경로 길이     → 가장 늦게 끝나는 로봇 기준

탐색 완료 시각은 마지막 로봇이 결정합니다. 그러니 최소화할 대상은 합이 아니라 최댓값(makespan)이어야 한다는 것이죠. 여기에 주행가능성 제약까지 붙으면 NP-hard가 되어, 빠른 근사해를 내는 PEAF라는 알고리즘을 새로 만들었습니다.

VLN으로 옮길 때 이 축이 가장 유망해 보입니다. HEHA는 주행가능성을 제약 조건으로 수식화해야 했지만, VLM에게는 텍스트로 그냥 주면 됩니다.

robot_0: 바퀴형, 계단 불가, 배터리 40%
robot_1: 4족,   계단 가능, 배터리 90%

조합 최적화 없이 상식으로 배분할 수 있는 영역입니다. 전통 플래너가 어려워하는 걸 VLM이 쉽게 하는 지점이죠. 다만 그 반대도 성립합니다 — min-max 최적화는 정확한 거리 계산이 필요해 VLM이 잘 못 합니다. 결국 이종 로봇이 함께 이해할 수 있는 context를 어떻게 만드느냐가 관건이 될 것 같습니다.

마무리

이 논문의 실제 기여는 연속적인 기하 문제를 VLM이 다룰 수 있는 이산 선택 문제로 바꾼 인터페이스 설계에 있습니다. VLM이 좌표를 자유롭게 뱉으면 벽 속을 지목할 수 있는데, 기하학적으로 유효한 후보만 만들어놓고 고르게 하면 그 실패가 원천 차단됩니다. 후보마다 이미지를 따로 만든 것도 구체적 실패 모드에 대한 구체적 해법이고요.

RA-L 기준에서 실질적 성과는 4족 로봇 2대에서 5 FPS로 돌렸다는 것입니다. D1~D4에서 본 미해결 과제들이 분명 있지만, Multi-Robot VLN을 실환경에서 데모했다는 데 의의가 있다고 봅니다.

특히 D2를 한 번 더 짚고 싶습니다. 이 글은 추론 R1~R4를 먼저 내놓고 답과 비교하며 채점하는 방식으로 썼습니다. 맞은 것도(◯), 절반만 맞은 것도(△), 틀린 것도(╱) 있었죠. 그 비교가 없었다면 "그럴듯한 이해"에 머물렀을 겁니다 — 틀린 추론을 틀렸다고 확인하는 순간에 이해가 생기니까요. 그런데 정작 이 논문의 VLM은 답을 먼저 확정하고 추론을 뒤에 씁니다. 키 순서만 바꿔 실험해보니 전 지표가 같거나 개선됐고, 달라진 유일한 단서는 "후보를 비교하는가"였습니다. 추론은 비교할 때 비로소 작동합니다 — 글이든 VLM이든 마찬가지인 것 같습니다.

그리고 남은 과제들은 대부분 이미 답이 나와 있는 방향입니다. 통신 제약, 초기 위치 미지, 이종 로봇 — 전통 탐색 플래너들이 지난 몇 년간 하나씩 풀어온 문제들이니까요. 그 해법들을 VLM 문맥으로 옮기는 것이 다음 걸음일 것 같습니다.

키워드 빈도 전체 표

불용어 제거·표제어 통합 후 상위 33개.
#	키워드	분류	빈도	점유율

산출 방법
pdftotext -layout으로 본문을 추출한 뒤 REFERENCES 이후를 잘라냈습니다. 줄바꿈 하이픈 결합, 인용 표기 [12] 제거, IEEE Xplore 워터마크와 러닝 헤더 제거, 일반 영어 불용어 및 논문 상투어(method, result, show 등) 제외, 두 글자 이하 토큰 제외, 복수형→단수형 통합 순으로 처리했습니다. 클러스터 분류는 자동 산출이 아니라 논문 내용을 근거로 한 사람의 판단입니다.