EdgeGround-VLA 모델 구조 & 학습 방식 정리

1. 추론 파이프라인

전체 흐름 — 다이어그램

위 블록도가 담지 못한 세 가지를 함께 표시합니다 — 텍스트가 들어가는 위치, 호출되지 않는 언어 디코더, 제어 계층의 되먹임(재검출).

flowchart TB
  CAM["카메라
720x1280 RGB"]

  subgraph PER["인지 — Perception"]
    direction TB
    TXT["텍스트 프롬프트
'gray basket'
런타임 불변 · 고정 상수"]
    OWL["OWL-v2 검출기
0.155B · 1902ms · zero-shot
학습 안 함"]
    KV["Kosmos-2 vision_model
0.303B · 54ms · frozen"]
    PRJ["image_proj
Linear 1024→256 + L2norm
0.262M · Stage 1 학습 후 동결"]
  end

  BB["bbox 4채널
cx, cy, area, has_bbox"]
  VIS["비전 피처 256채널"]
  CAT["프레임 특징 260-dim
window 6 → 1560-dim"]

  subgraph POL["정책 — Policy"]
    MLP["MLP 액션 헤드
1560→512→128→8
0.866M · Stage 2 학습 대상"]
  end

  ACT["8클래스 로짓
STOP · FWD · L · R
FWD+L · FWD+R · ROT_L · ROT_R"]

  XYZ["x, y, z (3-DoF)
ACTION_3D 룩업(LUT) — 클래스별 (lx, ly, az)"]

  RT["→ 런타임 파이프라인(⑦ Runtime)에서 계속
추론 제어(threshold·skip_n·회전규칙)·CAN·바퀴 전달은 별도 도표"]

  LM["Kosmos-2 언어 디코더 1.361B
호출 0회 · 로드도 제거함"]

  CAM --> OWL
  CAM --> KV
  TXT --> OWL
  OWL --> BB
  KV --> PRJ
  PRJ --> VIS
  BB --> CAT
  VIS --> CAT
  CAT -.-> MLP
  MLP -.-> ACT
  ACT -.-> XYZ
  XYZ -.-> RT
  KV -. "미사용" .-> LM

  classDef used fill:#0f2a1f,stroke:#2f7d5d,color:#dcfce7
  classDef train fill:#123524,stroke:#4ade80,color:#dcfce7,stroke-width:2px
  classDef slow fill:#2b1010,stroke:#b45454,color:#fee2e2
  classDef unused fill:#1a1a1a,stroke:#4b5563,color:#9ca3af,stroke-dasharray:4 3
  classDef text fill:#2a1030,stroke:#a78bfa,color:#ede9fe
  classDef data fill:#111c2e,stroke:#334155,color:#cbd5e1
  classDef out fill:#123524,stroke:#4ade80,color:#dcfce7,stroke-width:2px
  classDef note fill:#0d1117,stroke:#334155,color:#94a3b8,stroke-dasharray:4 3
  classDef pretrained fill:#0f2a1f,stroke:#4ade80,color:#dcfce7,stroke-dasharray:2 2
  class OWL slow
  class KV used
  class PRJ pretrained
  class MLP train
  class LM unused
  class TXT text
  class CAM,BB,VIS,CAT,ACT data
  class XYZ out
  class RT note

보라 = 텍스트 입력(고정 상수) · 빨강 = 지연 병목(전체의 97%) · 초록 굵은선 = Stage 2 학습 대상(행동 헤드) · 초록 점선 테두리 = Stage 1에서 학습 후 동결(image_proj) · 회색 점선 = 호출되지 않는 경로. 텍스트 관련 상세는 1-2절.

런타임 파이프라인 — 위 모델 파이프라인과의 차이

위 다이어그램은 한 번의 완전한 forward를 보여줍니다. 실제 운영에서는 grounding_skip_n=3이라 3번의 호출 중 1번만 이 전체 경로를 타고, 나머지 2번은 OWL-v2를 건너뛰고 Kosmos-2 비전만 다시 계산합니다(bbox는 직전 값 유지). 그리고 클래스 번호 이후 CAN 통신으로 바퀴에 전달되는 부분은 모델 파이프라인에 없던 하드웨어 경로입니다.
위 모델 파이프라인 도표에 있던 "제어 · SERVING CONTROL" 블록은 이 도표로 옮겼습니다 — 모델 구조와 런타임 동작은 별개 관심사이므로, 위 도표는 8클래스 로짓 출력에서 끝나고 threshold·skip_n·회전 규칙은 아래 도표 상단의 "추론 제어 파라미터 요약" 패널에 있습니다.

하드웨어 연결 구조 — Jetson ↔ CAN ↔ MCU

Jetson Orin NX가 인지·정책을 전담하고, 산출된 3자유도 속도 명령을 CAN 버스(can0, 500kbps)로 바퀴 제어 MCU 보드에 전달합니다. 같은 버스에 PSD·초음파 센서도 물려 있으나 본 VLA 파이프라인의 행동 입력에는 쓰이지 않습니다.

근거: ROS_action/.../omni_controller/omni_drive_node.py의 Psd(dev="can0", bitrate=500000) · robovlm_nav/serve/vla_control_utils.py의 pop.driving.Driving()

프레임 특징 벡터 — 260차원

FRAME_DIM = 4 + 256 = 260
  ├ bbox 4채널  : cx, cy, area, has_bbox   ← OWL-v2 출력 (area는 bbox_scale=3.0 배율 적용)
  └ 비전 256채널: Kosmos-2 vision_model(1024) → image_proj → L2 normalize

헤드 입력 : window=6 프레임을 flatten → (6 × 260) = 1560차원
헤드 출력 : 8클래스 로짓

액션 공간 — 3DOF 8클래스

1-2. 텍스트 입력은 어디에 있는가 — 정리

즉 "언어가 입력이 아니라 설정값"입니다

텍스트가 파이프라인 안에 존재하기는 하지만, 사용자가 런타임에 지시문을 바꿔 행동을 바꾸는 조건화(language conditioning)는 하지 않습니다. multi_prompt=False로 단일 쿼리만 쓰며, 값도 코드에 고정돼 있습니다. 그래서 엄밀히는 VLA가 아니라 "오픈 보캐블러리 객체 검출 + 액션 헤드"이고, 이것이 2026-07-23 미팅에서 모델 정의를 그렇게 바꾸기로 결정한 근거입니다.

왜 언어 경로를 쓰지 않게 됐는가 — 측정 결과 2건

2. 파라미터 — "0.46B"와 "1.8B"는 둘 다 맞습니다

이전 미팅에서 언급된 두 숫자가 서로 다른 것을 가리킵니다. 실측으로 정리하면:

레이턴시 — 병목은 검출기

파라미터 수와 속도가 역전되어 있습니다 — OWL-v2는 Kosmos-2 비전의 절반 크기인데 35배 느립니다. 따라서 "파라미터 수 줄이기"로는 경량화가 되지 않고, 검출 단계를 직접 손대야 합니다.

OWL-v2 단독 / Kosmos-2 단독 / 융합 — 그라운딩 인코더 기여도 ablation (2026-09-14 추가)

배포와 동일 조건(exp73 split·MLP·window=6·bbox_scale=3.0, val=33ep/2,431프레임, 3-seed)에서 입력 특징만 3갈래로 나눠 학습해 각 인코더의 기여도를 분리했습니다 (scripts/ablate_owlv2_kosmos2_fusion.py).

다른 그라운더 조합(PG2 기반, Exp14)에서도 같은 방향의 결과(bbox_only 67.4% / image_only 75.6% / 융합 76.7%)가 이미 관측된 바 있어, "이미지가 핵심·bbox는 보조"라는 결론이 그라운더를 OWL-v2로 바꿔도 재현됩니다.

클래스별 분해 — "어느 경우에" 어느 인코더가 더 기여하는가 (2026-09-14 추가)

위 표는 평균 정확도만 보여줍니다. 심사위원3 의견4("어느 경우에 어느 인코더가 결정에 더 기여하는지")에 답하기 위해 클래스별로 분해했습니다.

3. 학습 방식

하이퍼파라미터 요약 — 모델 구조·학습·서빙(런타임)으로 분리

owlv2_thresh와 num_classes처럼 값 자체가 핵심인 항목을 본문 산문에서 분리해 한 표로 모았습니다. 서빙 항목은 배포 시 환경변수로 바뀔 수 있어 학습 하이퍼파라미터와 구분합니다.

학습되는 것 / 안 되는 것

데이터셋 (V6)

학습 하이퍼파라미터 — Stage 2(행동 헤드)

window       = 6 프레임          bbox_scale = 3.0
num_classes  = 8                 optimizer  = AdamW, lr = 5e-4
epochs       = 300               scheduler  = CosineAnnealingLR
class weight = 1/빈도 정규화      ← FORWARD 46.03%(7,641/16,599) 편중 보정
seeds        = 0, 1, 2 (다중 시드로 분산 확인)

학습 하이퍼파라미터 — Stage 1(image_proj 사전학습)

Stage 2와 완전히 분리된 별도 학습(1.1절) — 데이터·클래스·하이퍼파라미터 전부 다름.

epochs       = 30                batch size = 16
optimizer    = AdamW, lr = 3e-4   scheduler  = CosineAnnealingLR
temperature  = 0.07 (대조학습)    num_classes = 5 (강좌/약좌/중앙/약우/강우)
class weight = strong_L 0.91 · weak_L 1.00 · center 1.17 · weak_R 1.01 · strong_R 0.91
검증 분할     = 에피소드 단위 20%, seed 42

cadence-aligned 학습 — 결론만

그라운딩이 ~2초 걸려 실기 판단 주기는 6Hz가 아니라 약 1.3Hz이고, 그 사이 로봇은 직전 명령을 유지합니다(zero-order hold). 이 조건을 학습에 반영해 stride=5 간격 표집 + 구간 다수결 라벨로 학습한 실험은 연속 학습 7.1%→28.3%(HELD 프록시 지표)로 개선을 보였지만, 배포 헤드는 이 방식을 쓰지 않고 stride=1(매 프레임) 학습입니다 — 그래도 95/100 실기 성공률이 나왔기 때문에, cadence-aligned는 근본 해결책이 아닌 보조 완화책으로 결론 나 채택을 보류했습니다. HELD는 프레임 단위 판단 정확도 프록시일 뿐 에피소드 성공률과 다른 척도라 직접 비교할 수 없다는 점도 확인됐습니다. 상세 ablation은 CH64 64-12 참조.

bbox_scale 재검증 (2026-08-16) — 결론만

배포 구성(exp73·OWL-v2·MLP·stride=1)에서 bbox_scale 1.0/2.0/3.0을 3-seed로 재검증한 결과 차이는 오차범위 안이었습니다. 현재 3.0을 쓰는 이유는 성능 이득이 아니라 배포 체크포인트가 그 값으로 학습됐기 때문이며, 학습·추론 값이 어긋나면 안 되므로 체크포인트 메타데이터에서 직접 읽어 씁니다. 과거 exp71(PG2+Transformer 헤드)에서 관측된 72%→85% 개선은 그라운더·헤드가 모두 다른 구성이었기 때문으로, 현재 구성엔 적용되지 않습니다.

논문 도판 — 최종본

KCI 초안에 싣는 확정 도판입니다. 이 페이지의 설명과 동일한 구조를 논문 형식으로 정리한 것으로, 수정사항 브리핑에서 Figure별 이력을 추적합니다.

4. 추론 제어 로직 — 학습으로 못 고친 걸 여기서 막습니다

2절에서 말한 "has_bbox=False를 학습한 적이 없다"는 구조적 결함을, 재학습이 아니라 제어 계층에서 우회했습니다. 현재 적용 중인 설정:

5. 실기 결과와 핵심 발견

그라운딩 성공률 — threshold 곡선

사람 라벨 296프레임(목표 있음 217·없음 79) 기준. threshold 0.25에서 오탐률 0%, 정탐률 94.9%. 0.20으로 낮추면 정탐 97.2%지만 오탐 12.7%가 발생.

행동 헤드 — val 혼동행렬

배포 헤드(exp73_owl_stage1v3_v6_mlp.pt, OWL-v2)를 학습과 동일한 stride=1 방식으로 채점한 결과 val 정확도 74.1%(n=2,431)로, 체크포인트에 저장된 값(74.13%)과 일치한다. 표본이 충분한 6개 클래스는 66.7~84.5%로 고르게 분포하며 특정 클래스가 붕괴한 것이 아니다. ROT_L·ROT_R만 낮게 나오는데, 두 클래스는 val 2,431개 중 28개(1.15%)뿐이라 오분류 한두 건이 정확도를 크게 흔든다.

오류를 심각도로 분해 (2026-08-19 추가)

오류 629건을 성격별로 나누면 81.4%가 "같은 방향 성향 내 혼동"(대체 가능한 행동)이고, 실제로 주행을 실패시키는 좌우 반전은 전체의 1.97%(48건)뿐이다. 좌·우·중립 3방향으로 축약하면 정확도는 74.13%→81.65%(+7.52%p)로 오른다. val 프레임 단위 정확도가 실기 성공률(95%)보다 낮게 보이는 이유를 뒷받침하는 근거 — 프레임 단위 채점은 폐루프 재정정 기회를 반영하지 못한다(scripts/plot_action_head_error_severity.py).

image_proj(Stage 1) 학습 곡선

train 96.10% / val 94.09%(격차 2.01%p), train loss 0.107 / val loss 0.173 — 둘 다 함께 수렴해 과적합 징후가 없다. Stage 2(행동 헤드)의 17.40%p 격차와 대조되는 지점으로, 과적합이 파이프라인 전체가 아니라 Stage 2에 국한된 현상임을 보여준다(scripts/train_stage1_v3_5cls_owl_fastloss.py, 비전 특징 캐싱으로 재학습 277분→21.8분 단축).

목표 위치 선정 기준 (2026-09-14 추가, 심사위원3 의견7 대응) — 실기 5개 목표 방향(중앙·강좌·약좌·강우·약우)은 임의로 고른 것이 아니라 Stage 1의 5-class 방향 대조학습 카테고리(강좌/약좌/중앙/약우/강우, 3절 참조)와 정확히 대응합니다. 즉 모델이 학습 단계에서 구분하도록 훈련된 방향 스펙트럼 전체를 실기 평가가 그대로 커버하도록 설계됐습니다.

실패의 정체 — "안 보인다"가 아니라 "경계에 걸린다"

미검출 프레임 197장을 로컬에서 재실행해 confidence를 확인했습니다:

즉 실패의 절반 이상이 타겟이 보이는데도 confidence가 0.10~0.20에 걸리는 경우입니다. 임계값을 0.15로 더 내려도 추가 회수는 +24.9%p인데 오탐이 0%→40.5%로 급증해 0.20이 적정선입니다.

6. 다음 단계 제안

7. RoboVLMs와의 관계 — "참고했으나 코드는 쓰지 않음"

자주 나오는 질문이라 코드 레벨로 확인한 결과를 정리합니다. 현재 95% 모델의 실행 경로에는 RoboVLMs 코드가 한 줄도 없습니다.

RoboVLMs를 실제로 import하는 파일 — 구(舊) 파이프라인 2개뿐

현재 파이프라인 — 전부 무관

가중치 계보도 없습니다 — RoboVLMs로 post-train된 kosmos_ph_google-robot-post-train.pt는 현재 파이프라인에서 참조 0건입니다.

부록 — 배포 체크포인트 이력

세션 파일 메타데이터(runtime_config)로 복원한 실제 배포 이력입니다.

image_proj·행동 헤드를 함께 재학습해 2026-08-07 배포 전환. 실기 100건 재검증 95/100 — episode_log.csv의 runtime_config.stage1_path/checkpoint_path로 확인. 이전 체크포인트는 runs/v5_nav/mlp/shared/stage1_v2_projs.pt에 롤백용으로 보존.

근거 상세: CH64 — 64-13(파라미터·레이턴시), 64-15(has_bbox 미학습), 64-17(임계값 ROC), 64-18(100회 결과), 64-19(요인 분해·배포 이력), 64-20(미검출 정밀 분석).
이 문서의 모든 수치는 코드/체크포인트/세션 메타데이터에서 직접 측정했으며, 과거 발표에서 철회·정정한 항목은 본문에 명시했습니다.