2026.05.20 - #70 - OpenVO, KISS-IMU, Py123D, Meta Rayban, vLLM-Omni, Pipecat, KubriCount, PCL Tutorial

[changh95]

OpenVO

• https://github.com/PhucNDA/OpenVO
• estimates real-world–scale ego-motion from monocular dashcam footage with varying observation rates and uncalibrated cameras, enabling robust trajectory dataset construction from rare driving events recorded in dashcam.
• (1) explicitly encodes temporal dynamics information within a two-frame pose regression framework and (2) leverages 3D geometric priors derived from foundation models.

KISS-IMU

• https://github.com/sparolab/KISS-IMU

123d

• Unified API for Argoverse 2 - Sensor, CARLA, KITTI-360, NCore (PhysicalAI-AV NCore), nuPlan, nuScenes, PandaSet, Physical AI AV, Waymo Open Dataset - Motion, Waymo Open Dataset - Perception
• Integrated viewer using viser.

Meta Rayban in Korea

Screen.Recording.2026-05-20.at.8.34.52.PM.mov

[james-joobs]

🤖 Weekly Spatial AI 리뷰 (2026.05.20)

---

🎭 vLLM-Omni — One Framework, Every Modality

• 역할: 텍스트·이미지·비디오·오디오를 하나의 추론 엔진에서 통합 서빙하는 any-to-any omni-modality 프레임워크 (vLLM 커뮤니티, 4.8k stars, Apache 2.0)

🤔 왜 만들어졌나 — 문제의식

진지한 multimodal 제품을 만들어 본 팀이라면 한 번쯤 겪는 풍경이에요:

• Qwen-Omni로 듣고 추론 → A 추론 스택
• Stable Diffusion으로 이미지 생성 → B 추론 스택
• Whisper로 음성 인식 → C 추론 스택
• TTS 모델로 음성 합성 → D 추론 스택

→ 4개의 추론 서버를 따로 띄우고, 그 사이에 glue code를 깔고, 4개를 모두 maintenance한다. 이게 multimodal serving의 진짜 비용이에요.

vLLM-Omni는 이 4개를 하나의 heterogeneous pipeline으로 접어버립니다.

🔧 메커니즘 — 왜 단순히 "통합 API"가 아닌가

서로 다른 모달리티 stage는 연산 특성이 근본적으로 달라요:

• AR core (LLM): token-by-token 자기회귀, KV cache 기반, memory-bound
• Diffusion Transformer (DiT): step-wise denoising, batch-parallel, compute-bound
• Encoder (ViT, Whisper): 한 번 forward, encode-only

그래서 단순히 같은 GPU에 욱여넣으면 서로의 자원 패턴이 충돌합니다. vLLM-Omni의 해법:

1. Modality Encoder (Whisper · ViT) → AR Core (vLLM의 검증된 KV cache 관리) → DiT (이미지·비디오 생성) → Decoder의 4단계 DAG
2. OmniConnector가 stage 사이 KV/feature/latent를 RDMA·NVLink 기반 zero-copy로 운반
3. 각 stage를 disaggregate해서 서로 다른 GPU 풀에서 돌리고, dynamic resource allocation으로 부하 변화에 대응
4. Pipelined execution: prefill stage와 diffusion denoising step을 overlap → throughput 극대화

설계 철학의 핵심: "multimodal serving은 latency-bound가 아니라 bandwidth-bound다. 따라서 stage를 쪼개고 빠른 connector로 연결하는 게 모든 걸 한 GPU에 넣는 것보다 낫다."

📦 지원 범위

• 모델: Qwen-Omni, Qwen3-TTS, Bagel, MiMo-Audio, GLM Image, Qwen-Image, CovX, 그리고 모든 HuggingFace 호환 multimodal 모델
• 하드웨어: CUDA · ROCm · NPU · XPU
• API: OpenAI 호환 + streaming + tensor/pipeline/data/expert parallelism 모두 지원
• 최신: v0.20.0 (2026.05) — diffusion 개선, v0.18.0 — unified quantization
  🔗 GitHub | Docs | Forum

---

🎙️ Pipecat — Real-Time Voice AI Agent Framework

![Pipecat Logo](

)

• 역할: WebRTC/WebSocket 기반 실시간 voice & multimodal 대화 에이전트 Python 프레임워크 (12.3k stars, BSD-2)

🤔 음성 에이전트 개발의 진짜 어려움

음성 에이전트를 만들 때 사람들이 처음 떠올리는 건 "어떤 STT/LLM/TTS를 쓸까"예요. 하지만 진짜 어려운 건 streaming orchestration이에요. First-byte latency를 800ms 안으로 들이려면 이 모든 게 동시에 일어나야 합니다:

1. 마이크 → VAD가 발화 시작/끝 감지
2. STT 스트리밍 시작
3. 아직 transcript가 끝나기 전, 부분 transcript로 LLM 호출 시작
4. LLM 토큰 스트림이 나오자마자 TTS로 즉시 흘려보냄
5. 사용자가 말을 끊으면 → 모든 단계를 즉시 cancel

이걸 하나의 framework로 매끄럽게 묶는 게 핵심이고, Pipecat이 그걸 잘합니다.

🔧 메커니즘 — Composable Frame Pipeline

각 stage는 비동기 async generator처럼 동작하면서 Frame 객체 (Audio / Text / LLMResponse / Control)를 흘려보내요. 이 설계의 묘미:

• Backpressure 자동: 다운스트림이 느리면 업스트림이 알아서 천천히 보냄
• Cancellation 자동: interruption 발생 시 CancelFrame이 거꾸로 흘러서 in-flight 요청 전부 종료
• WebRTC > WebSocket: 첫 패킷 latency와 jitter buffer가 실제 통화 품질의 차이를 만들어요

🌟 S2S(Speech-to-Speech)를 일급 객체로

요즘 OpenAI Realtime, Gemini Multimodal Live처럼 audio-in/audio-out을 직접 받는 모델이 등장하면서, 전통적인 STT→LLM→TTS 3-step pipeline 자체가 사라지는 흐름이에요. Pipecat은 같은 framework 안에서 양쪽 모두 똑같이 다루도록 설계됐어요 — 미래의 갈림길에서 흔들리지 않는 추상화.

📦 만들 수 있는 것

• 음성 비서, AI companion, 멀티모달 인터페이스, 인터랙티브 스토리텔링
• 비즈니스 에이전트 (고객 지원, 예약 접수), 복잡한 dialog system

🔌 지원 공급자 (60+)

• STT: Deepgram, AssemblyAI, OpenAI Whisper, Groq, Azure, AWS, Google
• LLM: OpenAI, Anthropic, Gemini, Groq, Mistral, Ollama
• TTS: OpenAI, ElevenLabs, Deepgram, Cartesia, Azure, AWS
• S2S: OpenAI Realtime, Gemini Multimodal Live, AWS Nova Sonic, Ultravox, Grok Voice Agent

🛠️ 부가 도구

• Pipecat Flows: state machine 기반 구조화 대화
• Pipecat Subagents: multi-agent 메시지 버스
• Client SDKs: JS, React, React Native, Swift, Kotlin, C++, ESP32 (임베디드)
• Whisker: 실시간 파이프라인 디버거 / Tail: 터미널 대시보드

🔗 GitHub | Examples | Docs | Website

---

🔢 KubriCount — Count Anything at Any Granularity

![KubriCount Teaser](

)
![KubriCount 5 Granularity Levels](

)

• 논문: "Count Anything at Any Granularity" (Chang Liu, Haoning Wu, Weidi Xie — 상하이 자오통대)
• 역할: 오브젝트 카운팅을 5단계 의미 단위(granularity) 축으로 다시 정의한 새로운 패러다임

🤔 기존 counting의 한계

세는 문제는 두 갈래로 발전해 왔어요:

• (a) class-specific: cars/people/cells처럼 미리 정해진 카테고리만
• (b) class-agnostic: visual exemplar 박스 3개 주면 비슷한 거 다 세줌

그런데 사용자의 실제 의도는 훨씬 더 세밀해요:

• "이 사진에서 빨간 사과만 세줘"
• "Granny Smith 종만 세줘"
• "과일은 다 합쳐서 세줘"

기존 모델은 이 granularity를 명시적으로 제어할 수 없어요. KubriCount는 이걸 해결합니다.

🔧 메커니즘 — 5단계 명시적 의미 계층

Counting을 (visual exemplar, semantic-granularity text) 쌍으로 conditioning합니다. 5 레벨:

Level	의미	예시
1. Identity	정확히 이 객체와 같은 individual	"이 특정 사과"
2. Attribute	같은 색/크기 등 속성	"빨간 것만" / "큰 것만"
3. Category	같은 카테고리	"사과"
4. Instance	같은 instance type	"빨간 사과 (Granny Smith)"
5. Concept	추상 개념	"과일"

🔧 HieraCount 모델

• Positive-only prompting: negative example 없이 multi-grained counting 학습
• Hierarchy-aware loss: granularity 계층 구조를 loss에 인코딩 → level 1에서 맞으면 level 2도 자동으로 맞도록 유도
• Granularity-aware prompts + 텍스트/이미지 hybrid prompt

📊 진짜 contribution은 데이터셋

![KubriCount Pipeline](

)

Kubric (Google의 photorealistic 3D synthesis 엔진)으로 제어 가능한 3D 장면을 생성한 뒤, mask-conditioned consistent image editing + VLM-based filter loop를 돌려서:

• 110,507장 이미지
• 약 7.3M annotated objects
• 157 카테고리
• 최대 250 objects/image (역대 최대 스케일)
• annotation: count뿐 아니라 center points, 2D/3D boxes, masks, metadata 모두 포함

이 정도 규모의 fully automatic pipeline은 counting 분야 최초예요.

결과 시각화

![KubriCount Visual Results](

)

🔗 Project Page | arXiv | GitHub | Dataset (HF)

---

✋ Snap-it, Tap-it, Splat-it — 촉각으로 3D 재구성하기 (3DV 2024)

![Snap-it Real-world Results](

)
![Depth Map Comparison](

)

• 논문: "Snap-it, Tap-it, Splat-it: Tactile-Informed 3D Gaussian Splatting for Reconstructing Challenging Surfaces" (Bristol / Google Zurich / NVIDIA, 3DV 2024)
• 역할: 카메라가 도저히 못 다루는 표면(투명 유리, 광택 금속, 면도날처럼 얇은 구조)을 로봇 촉각 센서로 보정해 재구성하는 multimodal 3D reconstruction

🤔 왜 vision-only로는 안 되나

3DGS는 photometric loss로 학습돼요. 즉 "여러 시점에서 본 픽셀 색이 일치하도록" Gaussian 위치를 조정해요. 그런데 non-Lambertian 표면(유리·금속)에서는:

• 시점에 따라 specular highlight가 격렬하게 변함
• 모델은 이걸 "거기엔 공간이 비어 있고 reflection만 잠시 보인 거야"로 잘못 해석
• → 표면 자리에 Gaussian이 안 박히거나 floaters로 흩어짐

투명한 컵 → 카메라는 통과해서 뒤만 봄. 광택 강한 금속 → 시점마다 highlight가 다른 위치. 이게 vision-only 3D 재구성이 망가지는 본질적 이유예요.

🔧 메커니즘 — 촉각이 ground truth를 주는 이유

촉각 센서 (TacTip 류)는 표면을 누르면 그 지점의 local geometry를 깊이맵 형태로 직접 측정해요. 빛과 무관 → specular 표면에서도 ground truth depth를 줍니다.

문제: touch는 sparse해요 (몇 군데 grasp). 이 sparse 정보를 dense 3DGS 학습에 어떻게 녹이느냐가 핵심.

1️⃣ Dual Initialization

COLMAP point cloud $G_c$ + tactile contact points $G_t$ → 두 소스에서 Gaussian 동시 초기화. tactile Gaussian의 위치는 contact point, color/scale은 random으로 시작.

2️⃣ 3D Transmittance Loss $\mathcal{L}_T$ — 핵심 아이디어

$$\mathcal{L}_T = -\frac{1}{P}\sum_i \hat{T}(p_i)$$

Touch 위치 주변의 average 3D transmittance를 최소화합니다. 직관적으로:

"여기 빈 공간일 리 없다. Gaussian이 이 표면을 덮어라."

이게 specular highlight 때문에 비어버리는 문제의 직접적인 해결책이에요.

3️⃣ Edge-aware Smoothness + Proximity Mask $\mathcal{L}_S$

![Proximity Mask](

)

Depth gradient를 RGB gradient에 정렬시키는 smoothness loss를 쓰되, touch location 근처에서는 Gaussian decay mask로 약화시켜요. 이게 없으면 smoothness가 transmittance loss가 만든 sharp surface를 다시 뭉개버립니다.

총 손실 = photometric + $\mathcal{L}_T$ + $\mathcal{L}_S$

📊 결과

Glossy Synthetic (full-view: 100 views + 5 grasps)

모델	Chamfer Distance
3DGS baseline	0.0075
Ours	0.0034 (-55%)

학습 시간: 1시간 vs NeRO 25시간 → 10배 빠름

Minimal-view (5 views + 5 grasps) — 진짜 어려운 셋팅

모델	CD	PSNR
3DGS	0.0111	20.08
Ours	0.0026 (-77%)	20.55

Shiny Blender ablation: 3DGS 0.0037 → +smoothness 0.0028 → +transmittance 0.0022 → full 0.0013 (-65%)

![RGB Rendering Comparison](

)

🤖 왜 로봇에 중요한가

로봇 manipulation은 결국 접촉이 일어나는 표면을 정확히 알아야 해요. Vision-only digital twin은 유리컵·금속툴·얇은 wire 같은 걸 잡지 못해요. 이 논문은 다음 패러다임을 깔끔하게 보여줍니다:

"로봇이 어차피 만져볼 거면, 그 만지는 행위 자체로 3D 모델을 더 정확히 만들자."

= Active Perception. Touch gave us ground truth where light couldn't.

🔗 arXiv | HTML | HuggingFace Paper

---

🌐 PCL Tutorial (Web-based) — by Hyungtae Lim (MIT)

![PCL Tutorial Screenshot](

)

• 역할: Point Cloud Library를 브라우저에서 직접 만져보면서 배우는 TypeScript 인터랙티브 튜토리얼

🤔 PCL 학습의 진짜 어려움

PCL은 SLAM/LiDAR/자율주행 학습자의 첫 관문이에요. 그런데 진입 장벽이 다음 두 가지에서 옵니다:

1. 세팅이 깨짐: C++ + CMake + Boost + PCL ≥1.8 조합이 OS마다 달라요. "Hello World 띄우는 데만 반나절"이 흔해요.
2. 직관이 안 잡힘: 알고리즘 코드를 봐도 "voxel size를 0.1m → 0.5m로 바꾸면 무슨 일이 일어나는지" 가 안 느껴져요. 함수 호출 → 결과 → 끝.

기존 튜토리얼은 대부분 정적 코드 + 캡처 이미지 위주였어요.

🔧 접근법 — TypeScript로 reimplement해서 WebGL로 그리기

저자 Hyungtae Lim(Patchwork, TRAVEL, KISS-Matcher 저자, MIT)이 한 일:

• 모든 PCL 알고리즘을 TypeScript로 reimplement → WebGL(three.js)로 브라우저에서 실시간 렌더
• 서버 호출 없이 클라이언트에서 다 처리 → 슬라이더를 움직이면 즉시 결과 갱신
• C++ 정답 구현이 옆에 같이 있음 → 학습 흐름이 자연스럽게:
  1. 슬라이더로 직관 형성
  2. C++ 코드 학습
  3. 자기 데이터(KITTI/NaverLabs/Stanford Bunny 또는 drag-and-drop)로 실험

📚 14개 챕터 — 후반부의 깊이가 다른 이유

#	주제
1	Point cloud 기본 + pointer 관리
2	Voxelization (downsampling)
3	PassThrough filtering
4	Transformation (4×4 matrices)
5	Statistical Outlier Removal
6	Radius search & K-NN
7	Normal estimation
8	RANSAC plane segmentation
9	Patchwork (ground segmentation) — 저자 본인 연구
10	Euclidean clustering
11	TRAVEL (range-image clustering) — 저자 본인 연구
12	ICP
13	Generalized ICP / GenZ-ICP
14	KISS-Matcher (global registration) — 저자 본인 연구

후반부 4개 챕터(Patchwork·TRAVEL·GenZ-ICP·KISS-Matcher)는 모두 저자 본인의 SOTA 연구를 입문자가 직접 만져볼 수 있게 만든 거라 학습 자료로서의 깊이가 다릅니다.

🛠️ 스택

• TypeScript 76% / C++ 12%
• Frontend: React + Vite + three.js
• C++ side: PCL ≥1.8, CMake ≥3.10, Boost ≥1.58, PCLVisualizer
• 데이터셋: KITTI (outdoor LiDAR), NaverLabs (indoor LiDAR), Stanford Bunny + drag-and-drop
• 센서별 데모: VLP-16, HDL-64
• MIT License

학생·연구자의 진입 장벽을 낮추는 게 목표. PCL/SLAM/LiDAR perception 입문에 최고의 자료.

🔗 Live Tutorial | GitHub | Patchwork | TRAVEL