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배 느립니다. 따라서 "파라미터 수 줄이기"로는 경량화가 되지 않고, 검출 단계를 직접 손대야 합니다.

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마다 한 번만 판단하고, 라벨은 그 5프레임 구간의 다수결로 주는 방식으로 학습했습니다.

원본: CH64 64-12, 3 seed 에러바. 그라운더를 OWL-v2로 바꿔도 HELD 25.3±3.8%로 재현되어 그라운더 종속 결과가 아님을 확인. 단 이 28.3%도 baseline의 순수 offline 수치(39~48%대)에는 크게 못 미쳐 — cadence-aligned는 근본 해결책이 아니라 재수집 없이 얻는 저비용 완화책입니다.

cadence-aligned가 정확히 무엇을 바꾸는가 — 세 가지가 함께 바뀝니다

위 ablation에서 입력만 stride5로 바꾸면 24.2%인데 라벨까지 구간 다수결로 바꾸면 28.3%가 됩니다. 즉 이 방식은 하나의 트릭이 아니라 표집 간격 · 윈도우 구성 · 라벨 정의 세 가지가 동시에 바뀌는 것이고, 각각이 다른 문제를 겨냥합니다.

idx = t − (window−1−k) × stride
→ t−25, t−20, t−15, t−10, t−5, t

③ 라벨 정의 — "지금"이 아니라 "다음 판단까지"

결정 시점 t의 라벨은 그 순간의 행동이 아니라 구간 [t, t+5)에서 조작자가 취한 행동의 다수결입니다. 학습 목표가 "지금 무엇을 하고 있나"에서 "다음 판단까지 무엇을 유지할 것인가"로 바뀝니다 — 행동이 일정 시간 유지되는 운영 구조와 정합합니다. ablation의 +4.1%p가 이 변경의 몫입니다.

그래서 라벨이 실제로 얼마나 바뀌는가 — 데이터에서 직접 세었습니다.

클래스 분포 변화 — 편중이 미세하게 완화되지만 좌우 불균형은 그대로입니다.

bbox_scale 재검증 (2026-08-16) — 현 파이프라인에선 무영향

과거 exp71(PG2 그라운더 + Transformer 헤드)에서 bbox_scale 3.0이 정확도를 크게 끌어올린다고 보고했으나(72%→85%), 현재 배포 구성과 동일한 조건 (exp73 · OWL-v2 · MLP 헤드 · stride=1 · 같은 캐시/분할)에서 1.0/2.0/3.0을 3-seed로 재검증한 결과 차이가 오차범위 안이었습니다.

해석 주의 — 옛 결과가 틀렸다는 뜻이 아니라, 그라운더(PG2→OWL-v2)와 헤드(Transformer→MLP)가 모두 바뀐 다른 구성이었다는 뜻입니다. 현재 3.0을 쓰는 이유는 성능 이득이 아니라 배포 체크포인트가 그 값으로 학습됐기 때문이며, 학습·추론 값이 어긋나면 안 되므로 체크포인트 메타데이터에서 직접 읽어 씁니다.

참고 — bbox_scale은 화면에 그려지는 검출 박스의 픽셀 크기와 무관합니다. 0~1로 정규화된 bbox 4채널 값 자체에 곱하는 입력 특징 스케일링이며, L2 정규화된 256차원 비전 특징과 크기를 맞추려는 조정입니다.

논문 도판 — 최종본

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%)뿐이라 오분류 한두 건이 정확도를 크게 흔든다.

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

미검출 프레임 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(미검출 정밀 분석).
이 문서의 모든 수치는 코드/체크포인트/세션 메타데이터에서 직접 측정했으며, 과거 발표에서 철회·정정한 항목은 본문에 명시했습니다.