26.08.12 - #76 - FlowDAgger, Transformer Transformer, WorldClaw, Multi-Agent CAD, HuggingFace Kernels, GTSAM for Gaussian Splatting

Dataset site

Awesome-UMI
- UMI와 UMI-like 프로젝트, 수집 장비, 센서, 공개 데이터를 모아둔 사이트.
- 데이터 수집 방식을 보고 싶을 때 유용하다.
datasets.bot
- 여러 곳에 흩어진 공개 로봇 데이터셋을 검색할 수 있게 해둠
- 데이터를 직접 호스팅하기보다 설명과 원본 링크를 정리해 주는 인덱스다.
Open-X-Tactile
- 서로 다른 촉각 센서와 로봇 플랫폼의 데이터를 모아둠
- 15 datasets, 12 sensors, 26,430 trajectories, 17,961,358 frames, 398 tasks.

What Are We Actually Benchmarking in Robot Manipulation?

본 논문은 로봇 조작 벤치마크의 높은 점수가 실제 로봇의 일반적인 조작 능력을 얼마나 잘 설명하는지를 점검합니다.
저자들은 벤치마크 점수가 특정 평가 조건에서의 성공률일 뿐, 일반적인 조작 능력의 충분한 증거로 해석되기 어렵게 만드는 네 가지 문제를 제시합니다.

Shortcut solvability
핵심 능력을 사용하지 않는 작은 모델도 높은 점수를 낼 수 있는가?
Statistical significance
새로운 점수 상승이 평가 노이즈보다 실제로 큰 차이인가?
Creeping overfitting
학습 조건과 크게 다르지 않은 조건만 바꿔도 성능이 무너지는가?
Data-source dependence
일반화 능력보다 테스트 환경과 가까운 학습 데이터가 점수를 만든 것은 아닌가?

저자들은 이 네 가지 진단을 LIBERO, CALVIN, SimplerEnv, RoboCasa, RoboTwin 2.0에 적용해, 각 벤치마크 점수가 어떤 조건에서 실제 진전을 보여주고 어떤 조건에서는 과대해석될 수 있는지 분석합니다.
결론은 벤치마크가 쓸모없다는 것이 아닙니다. 벤치마크 점수는 여전히 유용하지만, 그 점수만으로 일반적인 로봇 조작 능력이 입증됐다고 보기는 어렵다는 것입니다.
따라서 작은 baseline, episode별 성공 결과, 더 넓은 테스트 분포, 학습 데이터의 출처를 함께 확인해야 한다고 제안합니다.

FlowDAgger: Human-in-the-Loop Adaptation of Generative Robot Policies in Latent Space

Project

어떤 문제를 해결하려고 했나?

사전학습된 생성형 로봇 정책은 다양한 행동을 알고 있어도, 실제 환경에서 새로운 물체나 상황을 만나면 실패할 수 있습니다.
이때 정책 전체를 다시 학습하려면 많은 데이터와 시간이 필요합니다. FlowDAgger는 기존 정책의 능력은 유지하면서, 사람이 개입한 교정만 효율적으로 반영하려고 합니다.

아이디어

FlowDAgger는 큰 생성형 로봇 정책의 가중치를 고정하고, 상태마다 어떤 noise를 넣을지 결정하는 작은 정책만 학습합니다.
기존 생성형 정책은 관찰된 상태와 noise를 받아 로봇 행동을 만듭니다.

상태 s + noise w
        ↓
고정된 생성형 정책
        ↓
로봇 행동 a

FlowDAgger에서는 작은 noise policy가 상태에 맞는 noise를 예측합니다.

상태 s
  ↓
작은 noise policy
  ↓ noise w
고정된 생성형 정책
  ↓
로봇 행동 a

따라서 학습되는 것은 거대한 로봇 정책 전체가 아니라, 기존 정책의 행동을 조정하는 작은 noise policy입니다.

정리

FlowDAgger는 현장에서 정책 전체를 다시 학습하지 않습니다.
기존 생성형 정책은 고정하고, 사람이 보여준 교정 행동을 기존 정책 안에서 재현할 수 있는 noise를 역산한 뒤, 작은 noise policy만 학습합니다.
사람의 행동을 직접 모방하는 것이 아니라, 기존 정책의 생성 과정을 조정해 같은 교정 행동을 만들어내는 것입니다.

Details

사람의 교정을 어떻게 학습하는가?

사람은 로봇이 해야 할 교정 행동 a를 보여줄 수 있지만, 그 행동을 만들기 위해 어떤 noise w가 필요한지는 알 수 없습니다.
그래서 FlowDAgger는 기존 생성형 정책을 거꾸로 계산해 다음 조건을 만족하는 noise를 찾습니다.

고정된 정책에 noise w*를 넣었을 때
사람의 교정 행동 a*가 나와야 한다

이렇게 얻은 w*를 정답으로 사용해, noise policy가 상태에 맞는 noise를 예측하도록 학습합니다.
즉, 사람의 행동을 직접 복사하는 것이 아니라 기존 정책 안에서 사람의 교정 행동을 재현할 수 있는 noise를 찾는 방식입니다.

VLA 에서는 어떻게 역산하는가?

생성형 정책은 noise에서 출발해 여러 단계의 계산을 거쳐 행동을 만듭니다.
FlowDAgger는 사람의 행동에서 출발해 이 과정을 반대로 따라가며, 처음 입력된 noise를 복원합니다.
각 단계에서 한 번만 거꾸로 계산하면 오차가 커질 수 있기 때문에, fixed-point iteration을 사용해 이전 상태를 여러 번 보정합니다.
이 과정은 정책의 가중치를 업데이트하는 것이 아니라, 기존 velocity model을 이용해 noise를 역산하는 과정입니다.

World-Action Model에서는?

Cosmos-Policy와 같은 World-Action Model은 미래 장면, 로봇 행동, value를 하나의 joint latent에서 함께 생성합니다.
이 경우에는 action만 따로 역산할 수 없습니다.
FlowDAgger는 먼저 기존 정책이 만든 joint latent를 구한 뒤, action 부분만 사람의 교정 행동으로 바꿉니다. 미래 장면과 value에 해당하는 부분은 그대로 유지합니다.

기존 joint latent
 ├─ 미래 장면: 유지
 ├─ action: 사람의 교정으로 교체
 └─ value: 유지
          ↓
   수정된 joint latent
          ↓
      noise 역산

즉, 기존 정책이 알고 있던 정보는 최대한 보존하고, 사람이 바꾼 행동 부분만 최소한으로 수정합니다.

학습은 반복적으로 진행된다

현재 정책으로 rollout
        ↓
사람이 실패 구간에서 개입
        ↓
교정 행동 a* 수집
        ↓
a*를 noise w*로 역산
        ↓
noise policy 업데이트
        ↓
업데이트된 정책으로 다시 rollout

학습 데이터에는 두 종류가 함께 들어갑니다.

사람이 개입한 교정 데이터
기존 정책이 성공한 자율 실행 데이터
교정 데이터는 실패한 행동을 수정하고, 자율 실행 데이터는 기존에 잘하던 행동을 유지하도록 합니다.

결과

저자들이 보고한 MetaWorld 12개 과제 실험에서 평균 성공률은 0.53에서 0.78로 상승했습니다.
Cosmos-Policy의 공통 7개 과제에서도 평균 성공률이 0.53에서 0.74로 올랐습니다.
실제 로봇 실험에서는 과제별로 5~20개의 intervention episode를 사용했습니다.

Toolbox Packing: 0.13 → 0.80
Glassware Stacking: 0.26 → 0.76
Wire Pull: 0.40 → 0.70
다만 모든 능력이 무조건 좋아진 것은 아닙니다. Hammer 실험에서는 적응 후 held-out skill 평균 성능이 0.96에서 0.88로 감소했습니다.

한계

FlowDAgger는 기존 생성형 정책이 표현할 수 있는 행동 범위 안에서 사람의 교정을 재현합니다.
따라서 사람의 교정 행동이 기존 정책의 행동 분포에서 너무 멀리 떨어져 있다면, 실제로는 그 행동과 가장 가까운 기존 정책의 행동만 만들어낼 수 있습니다.
또한 사람의 교정이 모든 문제를 해결하는 것도 아닙니다. 기존 정책이 과제의 목표나 행동 순서를 잘못 이해하고 있다면, noise를 조정하는 것만으로는 충분하지 않을 수 있습니다.

Transformer Transformer : A Unified Model for Motion-Conditioned Robot Co-design

Project

원하는 end-effector motion과 reward를 주면, 그 동작을 잘 수행할 robot embodiment와 controller를 함께 만든다.

문제 / 한계 / 목표 / 전체과정

문제

로봇의 성능은 controller만으로 결정되지 않음
같은 end-effector motion이라도 다음 조건에 따라 실행 성능이 달라짐
- 팔 길이
- 관절 수와 배치
- 링크 방향
- 장착 위치
- 로봇의 질량과 관성
따라서 좋은 controller를 찾는 것뿐 아니라, task에 맞는 로봇 몸체를 함께 설계해야 함

기존 접근의 한계

사람이 원하는 end-effector trajectory를 정해도, 모든 로봇이 그 궤적을 똑같이 잘 따라갈 수 있는 것은 아님
로봇 구조 후보를 하나씩 만들고 controller로 평가하면 설계 후보가 많아질수록 시간이 오래 걸림
Evolutionary optimization은 설계 공간이 커질수록 많은 시뮬레이션이 필요함

논문의 목표

입력
- 원하는 end-effector trajectory
- 사용자가 정한 reward
출력
- 해당 motion을 잘 수행하는 로봇 구조
reward에는 다음과 같은 조건을 넣을 수 있음
- tracking precision
- joint velocity
- torque
- robot size
- robot weight

전체 과정

E = 팔 길이, 관절 배치, 모터 구성
τ = 손끝을 아래에서 위로 휘두르는 목표 궤적
A = 그 궤적을 만들기 위한 관절·모터 명령
S = 명령을 실행하며 실제로 나타나는 관절과 링크의 상태

[데이터 생성]

목표 UMI motion
+ procedural robot
+ controller rollout
        ↓
(E, S₁:H, A₁:H, τ₁:H)


[Diffusion 학습]

Motion-to-Robot mask
τ는 고정
E, S, A의 noise 예측

Control mask
E, 현재 S, τ는 고정
future S와 A의 noise 예측


[Motion-to-Robot inference]

target motion + random noise
        ↓ 100-step denoise
robot E + predicted S,A
        ↓
reward로 평가


[방법 1: Zeroth-Order]

N개 생성
→ reward 최고 후보 선택


[방법 2: DGS]

매 denoising step에서
reward gradient로 구조 생성 방향 수정
→ guided 후보 중 최고 선택


[Cross-Embodiment inference]

robot E + current state + target motion
        ↓ 5-step denoise
action 생성
        ↓
로봇 실행

🤖 Weekly Spatial AI 리뷰 (2026.08.12)

🌍 WorldClaw (Tencent Hunyuan) — 에이전트가 3D 오픈월드를 짓다

논문: "WorldClaw: Agentic 3D Open-World Generation at Scale" (arXiv:2608.05248, 2026.08)
저자: Chunchao Guo, Jinpeng Li, Yang Li, Zilong Huang (Tencent Hunyuan)
역할: 텍스트 프롬프트에서 대규모·자유 탐험 가능·인스턴스 편집 가능한 3D 오픈월드를 생성하는 에이전틱 프레임워크 (HunyuanWorld 1.0의 후속)

🤔 왜 만들어졌나 — 기존 3D 월드 생성의 세 갈래 함정

3D 월드 생성 연구는 지금까지 셋 중 하나로 갈렸어요:

접근	대표	한계
통합 표현	HunyuanWorld 1.0, WorldGen	단일 mesh/Gaussian → 인스턴스 단위 편집 불가
순수 Procedural	Infinigen	규칙 기반 → 표현력 제한
Native 3D Diffusion	XCube, CymbaDiff	3D 데이터 부족 → 콘텐츠 다양성 낮음

WorldClaw의 답: 세 축을 명시적으로 분리해 결합 — Procedural terrain (제어 가능) + Generative object composition (다양성) + Agentic refinement (관찰·수정 가능).

🔧 메커니즘 — 3단계 Coarse-to-Fine Agentic 파이프라인

Stage 1: Intent Analysis & Planning

Intent Analysis Agent: 유저 프롬프트에서 씬 타입/테마/스타일/키 지역/오브젝트/공간관계만 추출 (생성적 보완 금지 — 이게 중요)
Scene Planning Agent: 구조화 스펙 산출 → ℛ(regions), 𝒞_terrain(terrain types), 𝒞_object(카테고리·밀도·관계)

Stage 2: Global Terrain Generation (3 substages)

Terrain Planning: scale, base elevation, noise freq, geomorphic operator까지 파라미터로 내려줌. 필요 시 외부 검색 툴 호출
Terrain Assets:
- Scene Layout Map: 지역을 색상으로 인코딩한 2D 분할맵
- GPT-Image-2로 프로토타입 이미지 생성 → Hunyuan3D로 3D 프로토타입 변환
- Materials: 복잡 표면은 generative texture, 대규모 영역은 procedural (Blender node)
Refinement: 지역별 heightfield 합성 공식
H(𝐱) = Σ_r m̃_r(𝐱)[h_r + Σ_k w_{r,k} N_{r,k}(𝐱) + Σ_j α_{r,j} G_{r,j}(𝐱)]
render-based agent가 predefined 시점에서 검사 → 국소 수정

Stage 3: Regional Object Generation & Placement

세 가지 재사용 스킬:

Region Composition: 현재 terrain 렌더 → 카메라 파라미터 기록 → conditional 이미지 생성
Object Generation: SAM3 sliding-window inference로 개별 인스턴스 세그멘테이션 → SAM3D가 single-view mesh 복원
Object Placement: 두 개의 대응 ray(object center ↔ terrain camera)로 3D anchor 회복
→ 초기 스케일: s_i = (Z_t/Z_o)(f^o_i/f̂_i)
→ 배치 변환: T^place_i = [s_i R_i | P_t − s_i R_i P_o] T^{l2c}_i
→ 2D projection 보존하며 anchor depth/scale 공동 최적화

Scene Refinement 태스크 큐:

저품질 SAM3D 결과 → coarse mesh + object image를 조건으로 Hunyuan3D 리파인 (정체성 보존)
부양·관통·불안정 접촉 검출 → 오브젝트 재배치 또는 지형 국소 변형 (co-deformation)

🧩 Foundation 모델 조합 (Agent Skills)

Skill	역할
Claude Opus 4.8	백본 에이전트 (모든 planning/refinement 두뇌)
GPT-Image-2	Layout map, asset 대표 이미지, region composition
SAM3	텍스트 가이드 2D 인스턴스 세그멘테이션
SAM3D	Single-view 3D 재구성 (mesh + appearance + transform)
Hunyuan3D	Terrain asset 프로토타입 & 오브젝트 mesh 정교화
BlenderMCP	Blender 5.1.1 실행 인터페이스
Hardware	4× NVIDIA H20 GPU

🌟 결정적 차별점

Instance-level editable textured mesh — HunyuanWorld 1.0의 monolithic 표현과 달리 각 나무·바위·건물이 개별 객체로 남아 있어 개별 편집·이동·교체 가능.

⚠️ 논문의 한계 (§ 5, 저자 스스로 명시)

Backbone 의존성: Claude Opus 4.8 / GPT-Image-2 필수 → 오픈소스로 재현 어려움
LLM 코드 생성 불안정: Blender node graph를 단순화하는 경향
Long-horizon 비용: 오브젝트 수 × refinement iteration에 비례
정량 벤치마크·ablation 전무 — 전부 정성 평가

💡 한 줄 요약

"3D 월드 생성의 세 갈래 함정(통합 표현 vs procedural vs native diffusion)을 이제 하나의 pipeline에서 배치할 수 있게 됐다. Terrain은 procedural로 통제하고, 오브젝트는 SAM3+SAM3D로 다양성 확보하고, agent가 render로 검증한다."

🔗 Project Page | GitHub | arXiv | HF Papers

🔧 Multi-Agent CAD (MAC) — 토큰 100배 절감으로 텍스트→CAD를 실용화

저자: Guanxing Qu, Xueyan Zou (Tsinghua University, IEI Lab)
역할: 자연어에서 3D 프린트 가능한 STEP/STL CAD 모델을 생성하는 4-에이전트 파이프라인 — 단일 에이전트 대비 토큰 116× 절감

🤔 왜 만들어졌나 — Text-to-CAD의 진짜 병목

단일 에이전트 text-to-CAD (CAD Skills, earthtojake/text-to-cad 등)의 문제:

매 반복마다 전체 대화 컨텍스트를 재재생
CAD는 반복이 많은 태스크 → 토큰 비용 폭증
결과: 파트 1개 만드는데 API 호출 1,307번, 토큰 103.9M, 비용 ¥125.69

MAC의 인사이트 두 가지:

CAD 생성은 자연스럽게 단계 분해된다: 사양 → 구조 → 코드 → QA. 단계 간 인터페이스만 구조화된 JSON으로 넘기면 conversation replay가 사라진다
흔한 조작(extrude/revolve/fillet…)은 LLM이 필요 없다: 결정론적으로 build123d 코드로 직접 번역하면 그 스텝의 토큰 비용은 0

🔧 4-에이전트 아키텍처

Stage	Agent	Input → Output
1	Spec Planner	자연어 → `CADBrief` JSON (3개 검증 타깃 포함)
2	Geometric Architect	`CADBrief` → `ArchitectPlan` JSON (sketch/step/selector)
3	Python Coder	`ArchitectPlan` → `temp_design.py` (build123d 코드)
4	Autonomous Skill Loop	코드 + STEP/STL → 최종 STEP + Dual-Engine QA 보고서

통신 프로토콜: conversation replay가 아니라 구조화된 JSON state handoff. 각 에이전트는 선행 결과의 compact 요약만 받음.

🌟 결정론적 Translator — Zero-Token 트릭

_plan_to_code 함수가 다음 조작들을 LLM 없이 build123d 코드로 번역:

extrude / revolve / hole / boolean
pattern (linear · circular · mirror)
fillet / chamfer / shell

→ 이 스텝의 토큰 사용 0. LLM은 어려운 부분에만 호출.

🛡️ Aider Repair Loop + Hybrid Model Routing

실패 feature는 Aider 0.82.3으로 LLM 코드 리페어
각 QA 패스 후 10초 human checkpoint (자동 반복 / 사람 개입 / 중단)
Planner엔 저가 모델, Architect·Coder엔 Qwen 3.7-max 같은 강력 모델 라우팅

📊 벤치마크 (P1–P10, 10 mechanical parts)

메트릭	단일 에이전트 baseline	MAC	개선
Token 사용량	103.9M	896k	116×
비용	¥125.69	¥9.67	13×
API 호출 수	1,307	50	26×
Feature pass rate	97.9%	99.3% (140/141)	+

🎯 Articulable Print-in-Place — 진짜 인상적인 결과

0.4–1 mm clearance의 다-바디 조립체
Ball-in-cage fidget, rotating gyroscope
별도 조립 없이 한 번에 프린트해도 회전·움직임 유지
LLM이 clearance를 정확히 지정해야 가능 — 실제로 작동한다는 게 놀라운 결과

🎨 3D 프린트 갤러리

Honeycomb organizer, gyroscope, lighthouse, smartphone stand 등 창작 프린트 10점 실증.

🛠️ 스택

CAD kernel: build123d (B-rep, OpenCascade)
Agent orchestration: LangGraph (stateful workflow)
Code repair: Aider 0.82.3
Default LLM: Qwen 3.7-max (DashScope) — OpenAI-호환이라 GPT/DeepSeek/Gemini/Claude/Ollama 스왑 가능
3D runtime: cadpy (STEP↔GLB 변환)
Web UI: FastAPI + Uvicorn + <model-viewer> (Terminal 모드도)
MIT · Python 3.11+

💡 한 줄 요약

"Text-to-CAD의 진짜 병목은 LLM이 아니라 conversation replay. 단계 분해 + JSON handoff + 결정론적 zero-token translator만 잘 배치하면 토큰이 100배 준다."

🔗 GitHub | Baseline: earthtojake/text-to-cad

⚡ Hugging Face Kernels — 커널을 모델처럼 배포하기 (Major Revamp)

블로그: "🤗 Kernels: Major Updates" (Sayak Paul, Daniël de Kok, David Holtz, 2026.07.06)
역할: GPU 커스텀 커널 (FlashAttention, activation 등 native code)을 HF Hub에서 마치 모델처럼 배포·검색·설치·검증하는 라이브러리의 대규모 리비전

🤔 왜 만들어졌나 — CUDA 커널 배포의 진짜 지옥

CUDA/HIP 커널을 프로덕션에 붙이려면:

빌드 지옥: sm_XX 아키텍처 매칭, CUDA 버전 매칭, PyTorch 버전 매칭
ABI 지옥: libstdc++ 링크 문제, GLIBC 버전 충돌
신뢰 지옥: 커널은 native code라 로딩 프로세스와 동일 권한 → 서명 안 된 커널을 실행하면 사실상 임의 코드 실행

기존에는 도커/소스 빌드로 해결 → 실무 마찰이 컸어요.

Kernels 라이브러리는 이 문제를 **"Hub-first + Trust-first + Reproducible-first"**로 재설계.

🔧 리뉴얼의 핵심 8가지

1️⃣ New "kernel" repo type on the Hub

지원 accelerator / OS / backend 버전을 메타데이터로 명시 → discoverability + trend 추적 가능

2️⃣ Trusted Publisher System

기본은 신뢰된 퍼블리셔만 로드. 신뢰 안 되는 소스는 trust_remote_code=True 명시적 opt-in

3️⃣ Sigstore Cosign 서명

단명 개인키(ephemeral)로 서명 → 유출돼도 창이 짧음
GitHub workflow에서 검증
CLI: kernels verify-signature

4️⃣ CLI 분리 재정비

kernels (loading/prep) vs kernel-builder (dev) 완전 분리
Agent-optimized 비대화형 명령 — Claude Code 등에서 사용하기 좋음

5️⃣ Torch Stable ABI

특정 Torch 버전으로 빌드 → 이후 ~2년 ABI 유지 보장

6️⃣ Apache TVM FFI

PyTorch/JAX/CuPy 넘어 cross-framework 호환

7️⃣ `manylinux_2_28` 툴체인

libstdc++ 동적 링킹 → 전역 초기화 corruption 이슈 해결

8️⃣ Nix Hermetic Build + Git SHA1 임베드

공개 바이너리와 재컴파일 결과가 비트 단위로 일치하는지 검증 가능 → supply chain 신뢰성 확보

🚀 사용 예 — 로딩과 dispatch

from kernels import get_kernel
kernel_module = get_kernel("Atlas-Inference/gdn", version=1, trust_remote_code=True)

백그라운드에서 자동 처리: GPU arch, CUDA/Torch 버전, OS/libstdc++를 감지해 맞는 variant를 자동 선정.

사전 호환성 체크:

from kernels import has_kernel
has_kernel("kernels-community/activation", version=1)  # -> bool

상세 진단:

from kernels import get_kernel_variants, VariantAccepted
for d in get_kernel_variants("kernels-community/activation", version=1):
    print(d.variant.variant_str, "OK" if isinstance(d, VariantAccepted) else f"rejected: {d.reason}")

🔒 왜 서명이 중요한가

Kernel은 native code라 로딩 프로세스와 같은 권한을 가짐 = 파일시스템·네트워크·GPU 메모리에 완전 접근 가능. 서명 안 된 커널을 실행한다는 건 사실상 임의 코드 실행 허용. HF의 접근:

기본은 신뢰된 퍼블리셔만
Sigstore ephemeral key → 유출돼도 창이 짧음
Git SHA1 임베드 → "이 바이너리가 정확히 이 소스에서 나왔다"를 검증

🌟 왜 이게 인프라의 판을 바꾸나

Kernel 배포가 표준화되면:

연구자가 새 커널 발표 → pip install 대신 get_kernel("author/name") 한 줄
Transformers/Diffusers가 optimized kernel을 dynamic dispatch → 하드웨어별 최적 구현 자동 선택
Supply chain 공격 위험 최소화

모델 배포에서 HuggingFace Hub가 표준이 됐듯, 커널 배포에서도 같은 역할을 노림.

💡 한 줄 요약

"커널을 모델처럼 배포하되, native code라는 보안 위험을 서명·재현성·명시적 신뢰 opt-in으로 감싼다."

🔗 Blog | Kernel Hub | GitHub | CLI Docs

🧭 GTSAM — 20년 된 SLAM 라이브러리가 3DGS·Foundation Model 시대에 되살아나다

웹사이트: gtsam.org — Georgia Tech Smoothing and Mapping library (BSD, Frank Dellaert et al.)
역할: Factor Graph 기반 SLAM·SfM·센서 퓨전 C++ 라이브러리 — SLAM 학계의 사실상 표준 (Version 4.2 stable, 4.3 개발 중)

🤔 왜 지금 다시 이야기하나 — 오래된 라이브러리, 새로운 시대의 재조명

GTSAM은 2003년부터 있어온 옛날 라이브러리예요. Bayes tree, iSAM2, 팩터 그래프 최적화 — SLAM 대학원생이라면 다들 만져본 도구.

그런데 2026년에 GTSAM 블로그가 갑자기 뜨거워졌어요. 이유: 3D Gaussian Splatting과 Geometric Foundation Model이 SLAM 판을 뒤집는 와중에, "그럼 팩터 그래프는 폐기해야 하나?" 라는 질문에 GTSAM 팀이 "아니, 오히려 완벽하게 결합된다" 라고 답하고 있음.

2026년 최근 3개 블로그 포스트가 정확히 이 흐름:

날짜	제목	핵심
08.04	3D Gaussian Splatting meets Factor Graph SLAM	3DGS의 rendering loss를 GTSAM factor로
06.24	VGGT-SLAM: SL(4) Factor Graph Optimization	VGGT submap을 15-DoF projective로 정렬
05.20	Continuous-Time State Estimation via Gaussian Processes	이산→연속 시간 확장

🔧 하이라이트 1: 3D Gaussian Splatting meets Factor Graph SLAM (2026.08.04)

문제: 기존 3DGS SLAM (SplaTAM, MonoGS)는 rendering 품질은 뛰어난데 loop closure가 없음. Drift가 쌓여도 전역 교정 불가. Loop closure를 붙인 시스템도 rendering objective와 분리된 pose graph로 처리 → 최적화가 파편화됨.

해법 — GaussianSplatFactor:

Rendering을 GTSAM factor로 표현
gsplat으로 candidate camera pose에서 렌더 → photometric residual 계산 → Jacobian을 GTSAM nonlinear optimizer에 제공
se(3) generator + central difference로 viewpoint 미분
iSAM2 Bayes tree의 camera pose + PyTorch/Adam으로 최적화되는 Gaussian을 alternating optimization

결과:

Poses, loop closures, rendering이 하나의 factor graph 안에 native하게 존재
DINOv2 appearance matching + geometric verification으로 자동 loop detection
KITTI 73~85% error 감소, TUM-RGBD 10~40% 개선

🔧 하이라이트 2: VGGT-SLAM (2026.06.24)

문제: VGGT (CVPR 2025 best paper)는 uncalibrated monocular RGB에서 dense point cloud + camera pose를 뽑아냄. 하지만 3090에서 ~60 frame이 한계. 로봇은 수천 장을 incremental하게 처리해야 함.

해법 — SL(4) Factor Graph:

Submap을 만들고 서로 chaining
초기 시도는 Sim(3) transformation — VGGT는 camera intrinsic이 unknown이라 애매성이 더 큼 (실패)
핵심 통찰: projective geometry에서 image + known pixel correspondence로 3D 재구성하면 15 DoF projective ambiguity 존재
4×4 homography (determinant=1로 정규화) → Special Linear Group SL(4) manifold
GTSAM에서 SL(4) factor graph 최적화 구현

VGGT-SLAM 2.0: shared keyframe으로 15 DoF 제약, calibration consistency 활용, Jetson Thor에서 real-time

🌟 GTSAM의 핵심 개념 — Factor Graph가 아직도 강력한 이유

Factor Graph는 확률 변수(camera pose, landmark)와 관찰 constraint(observation)를 이분 그래프로 표현. 그 위에서 MAP inference = nonlinear least squares 최적화.

왜 20년 지나도 살아남나:

Sparse structure를 자연스럽게 표현 — Bayes tree로 O(n²) → O(n log n)
iSAM2: incremental smoothing — 새 관찰이 들어올 때 전체 재최적화 없이 국소 업데이트
Any factor → 어떤 새로운 sensor/model도 factor로 wrap하면 즉시 통합 가능

3DGS든 VGGT든 factor 하나로 감싸면 기존 SLAM 인프라 전체가 무료로 딸려옴 — 이게 GTSAM 팀의 주장이자 실증.

💡 한 줄 요약

"3DGS와 Foundation Model이 SLAM을 재정의하는 와중, GTSAM은 '팩터 그래프는 죽지 않았다, 오히려 이 두 트렌드를 담는 완벽한 그릇'임을 GaussianSplatFactor와 SL(4) factor graph로 증명. 20년 된 라이브러리가 신흥 기술을 흡수하는 방식을 보여주는 모범 사례."

🔗 gtsam.org | GitHub | 3DGS Factor 블로그 | VGGT-SLAM 블로그 | Blog

📌 요약

분야	프로젝트	한 줄 통찰
3D 월드 생성	WorldClaw (Tencent)	통합 표현 vs procedural vs diffusion을 하나의 에이전틱 pipeline에 배치 — 인스턴스 편집 가능한 3D 오픈월드
CAD 생성	Multi-Agent CAD (Tsinghua)	4-에이전트 + JSON handoff + zero-token deterministic translator → 토큰 100× 절감, print-in-place articulable까지
인프라	HF Kernels 리뉴얼	커널을 모델처럼 Hub 배포 + Sigstore 서명 + Nix hermetic build로 supply chain 신뢰 확보
SLAM	GTSAM	20년 된 factor graph 라이브러리가 3DGS·VGGT를 factor로 wrap해서 흡수 — GaussianSplatFactor + SL(4) factor graph

26.08.12 - #76 - FlowDAgger, Transformer Transformer, WorldClaw, Multi-Agent CAD, HuggingFace Kernels, GTSAM for Gaussian Splatting #79

Description

Dataset site

What Are We Actually Benchmarking in Robot Manipulation?

FlowDAgger: Human-in-the-Loop Adaptation of Generative Robot Policies in Latent Space

어떤 문제를 해결하려고 했나?

아이디어

정리

사람의 교정을 어떻게 학습하는가?

VLA 에서는 어떻게 역산하는가?

World-Action Model에서는?

학습은 반복적으로 진행된다

결과

한계

Transformer Transformer : A Unified Model for Motion-Conditioned Robot Co-design

문제

기존 접근의 한계

논문의 목표

전체 과정

Activity

james-joobs commented on Aug 12, 2026

🤖 Weekly Spatial AI 리뷰 (2026.08.12)

🌍 WorldClaw (Tencent Hunyuan) — 에이전트가 3D 오픈월드를 짓다

🤔 왜 만들어졌나 — 기존 3D 월드 생성의 세 갈래 함정

🔧 메커니즘 — 3단계 Coarse-to-Fine Agentic 파이프라인

Stage 1: Intent Analysis & Planning

Stage 2: Global Terrain Generation (3 substages)

Stage 3: Regional Object Generation & Placement

🧩 Foundation 모델 조합 (Agent Skills)

🌟 결정적 차별점

⚠️ 논문의 한계 (§ 5, 저자 스스로 명시)

💡 한 줄 요약

🔧 Multi-Agent CAD (MAC) — 토큰 100배 절감으로 텍스트→CAD를 실용화

🤔 왜 만들어졌나 — Text-to-CAD의 진짜 병목

🔧 4-에이전트 아키텍처

🌟 결정론적 Translator — Zero-Token 트릭

🛡️ Aider Repair Loop + Hybrid Model Routing

📊 벤치마크 (P1–P10, 10 mechanical parts)

🎯 Articulable Print-in-Place — 진짜 인상적인 결과

🎨 3D 프린트 갤러리

🛠️ 스택

💡 한 줄 요약

⚡ Hugging Face Kernels — 커널을 모델처럼 배포하기 (Major Revamp)

🤔 왜 만들어졌나 — CUDA 커널 배포의 진짜 지옥

🔧 리뉴얼의 핵심 8가지

1️⃣ New "kernel" repo type on the Hub

2️⃣ Trusted Publisher System

3️⃣ Sigstore Cosign 서명

4️⃣ CLI 분리 재정비

5️⃣ Torch Stable ABI

6️⃣ Apache TVM FFI

7️⃣ manylinux_2_28 툴체인

8️⃣ Nix Hermetic Build + Git SHA1 임베드

🚀 사용 예 — 로딩과 dispatch

🔒 왜 서명이 중요한가

🌟 왜 이게 인프라의 판을 바꾸나

💡 한 줄 요약

🧭 GTSAM — 20년 된 SLAM 라이브러리가 3DGS·Foundation Model 시대에 되살아나다

🤔 왜 지금 다시 이야기하나 — 오래된 라이브러리, 새로운 시대의 재조명

🔧 하이라이트 1: 3D Gaussian Splatting meets Factor Graph SLAM (2026.08.04)

🔧 하이라이트 2: VGGT-SLAM (2026.06.24)

🌟 GTSAM의 핵심 개념 — Factor Graph가 아직도 강력한 이유

💡 한 줄 요약

📌 요약

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

7️⃣ `manylinux_2_28` 툴체인