메뉴
HN
Hacker News • 31일 전

쇼 HN: 라즈베리파이와 Qwen으로 만든 오프라인 차량용 AI

IMP
6/10
핵심 요약

라즈베리파이 5(16GB, 약 300유로)에 Qwen3.6-35B 모델을 로컬로 구동해 차를 채팅룸 에이전트처럼 만드는 오픈소스 프로젝트입니다. 클라우드 없이 차량용 음성 비서, 745페이지 차량 매뉴얼 기반 RAG 질의응답, 자가진단, 블랙박스 영상 전송 등을 완전 오프라인으로 수행하며, 연결이 끊겨도 큐에 저장했다가 나중에 전송하는 견고한 설계가 돋보입니다.

번역된 본문

CarWatch — 당신의 차가 채팅룸 에이전트가 됩니다. 완전 오프라인으로 동작합니다. 라즈베리파이 5 한 대가 차에 탑재되어 35B 파라미터 모델을 로컬로 구동하며, @gle(이름은 원하는 대로 지을 수 있음)라는 이름으로 GroupMind 룸에 참여해 다른 에이전트처럼 메시지를 보냅니다. 출발·도착 알림, 여행 요약, 차에 충격이 가해졌을 때 블랙박스 영상 등을 전송하며, CodeWatch를 통해 휴대폰이나 시계에서 승인과 답장을 할 수 있습니다. 열린 PR은 CodeWatch 대시보드에 ClawWatch, WhereWatch 옆에 표시됩니다.

실제 하드웨어(Pi 5, 16GB, 약 300유로)에서 측정된 실제 성능: 🧠 Qwen3.6-35B-A3B(Unsloth UD-Q3_K_S 동적 양자화, 14.3GB)가 초당 3.5 토큰 생성 / 초당 25토큰 이상 프롬프트 처리, 지속적으로 65°C 유지. 클라우드 없음, 인터넷 없음, 구독료 없음.

📖 차량 자체의 745페이지 사용 설명서에서 페이지 출처를 붙여 답변합니다(어휘 기반 RAG, SD 카드에 내장). 설명서에 없는 내용은 답변을 거부합니다.

🔬 근거 있는 자기 인식: 온도, 쓰로틀링, 팬, 메모리, 디스크, 네트워크, 로드된 모델을 질문마다 실시간으로 기계에서 직접 읽어옵니다. 감지할 수 없는 것은 감지할 수 없다고 말하며, 시스템 프롬프트가 알 수 없는 정보를 사실처럼 조용히 답하지 않도록 설계되어 있습니다.

🎙️ 핸즈프리 음성: 상시 청취기(에너지 기반 VAD → whisper.cpp, 전부 Pi에서 구동)가 말을 알아듣고 동일한 근거 기반 파이프라인을 거쳐 룸에 답변합니다. 웨이크워드 절차도, 클라우드 STT도 없습니다.

📡 자율 동작: systemd 서비스가 부팅 시 전체 스택(모델 서버, 룸 에이전트, 음성 청취기, 휴대폰 대시보드, 엔진 감시기)을 자동 시작합니다.

🔧 어디서든 유지보수 가능: 차가 이 저장소에서 스스로 업데이트를 받아오며(매시간 + 대시보드의 '지금 업데이트' 버튼), 아웃바운드 터널을 열어 휴대폰 핫스팟의 NAT 뒤에 있어도 접근 가능합니다. 차 안에 노트북을 두고 작업할 일은 영원히 없습니다.

📶 3단계 연결: 휴대폰 핫스팟 → 집 와이파이 → 자체 폴백 액세스 포인트. 신호가 전혀 없는 차고에서도 휴대폰이 항상 접근할 수 있습니다.

모든 실패 과정까지 담은 빌드 로그는 docs/plan.md에 있습니다. CodeWatch(손목의 에이전트, 출처: codewatch-cli)와 ClawWatch(손목의 헬스케어, v2 런칭 영상)의 형제 프로젝트이며, 이번 것은 차를 지켜봅니다. 나머지 가족은 thinkoff.io에서 만나볼 수 있습니다.

아키텍처: 차 안의 라즈베리파이 5에서 USB 마이크 → carwatch-listen(VAD + whisper.cpp) → llama.cpp 서버(Qwen3.6-35B-A3B)로 이어지며, SD 카드의 사용 설명서 RAG와 selfstate(온도/팬/네트워크/모델)가 모델에 공급됩니다. carwatch-obd가 OBD 케이블을 감시하고, carwatch-agent(@gle 룸 에이전트)가 GroupMind 룸과 메시지를 주고받으며, 웹 대시보드(:8088, 상태/업데이트/음성/와이파이)는 같은 와이파이의 휴대폰과 통신합니다. 시간당 git pull로 자가 업데이트하고, 아웃바운드 터널로 어떤 NAT 뒤에서도 접근 가능합니다.

로컬 vs 온라인 전략: 로컬이 제품이고 온라인은 보강입니다. 차는 차고, 터널, 시골 사각지대에 있기 때문에 연결이 전혀 없어도 완전히 유용해야 합니다.

항상 로컬(신호 없이 동작): 음성 입력, 비서의 답변(Pi 내장 모델), 사용 설명서 답변(SD 카드 내장 RAG), 휴대폰 대시보드(차가 직접 서빙), 여행/상태 추적.

연결 끊김 시 큐잉: 룸 게시물, 영상 클립 업로드, 멘션 답장. 모든 것은 먼저 디스크의 영구 아웃박스에 저장되어 잃어버리지 않고 늦게 전달됩니다.

온라인 전용(솔직하게): 원격 접근(아웃바운드 터널), 자가 업데이트, 더 큰 두뇌로의 에스컬레이션 — 먼저 같이 탑재된 로컬 LAN 모델 서버(여전히 클라우드 없음), 그다음은 온라인 상태이면서 명시적으로 요청될 때만 예산 제한이 걸린 차 자체의 키로 클라우드 모델 사용.

경험칙: 한눈에 봐야 할 안전 관련 정보는 절대 네트워크에 의존하지 않고, 소셜이나 무거운 작업은 '나중에'로 우아하게 성능이 저하됩니다.

상태 — 검증된 것 vs 구축된 것 vs 계획된 것: 자동차는 도로 위 네 개의 손바닥 크기 접지면으로만 현실과 만납니다. 접지면마다 하나의 원칙이...

원문 보기
원문 보기 (영어)
CarWatch Your car as a chat-room agent — fully offline. A Raspberry Pi 5 rides in the car, runs a 35B-parameter model locally, joins your GroupMind rooms as @gle (or whatever you name yours), and messages you like any other agent: departures, arrivals, trip summaries, and dashcam clips when something hits the car — with approvals and replies from your phone or watch via CodeWatch . Open PRs land on the CodeWatch dashboard next to ClawWatch and WhereWatch. Live and measured, on real hardware (Pi 5, 16 GB, ~300 €): 🧠 Qwen3.6-35B-A3B (Unsloth UD-Q3_K_S dynamic quant, 14.3 GB) at 3.5 tok/s generation / 25+ tok/s prompt , 65 °C sustained, no cloud, no internet, no subscription. 📖 Answers from the car's own 745-page owner's manual with page citations (lexical RAG, ships on the SD card) — and refuses to answer what the manual doesn't say. 🔬 Grounded self-knowledge : temperature, throttling, fan, memory, disk, network and which model is loaded are read live from the machine per question. What it can't sense, it says it can't sense — the system prompt is built so an unknown can never silently read as a fact. 🎙️ Hands-free voice : a continuous listener (energy VAD → whisper.cpp, all on-Pi) hears you speak, routes the words through the same grounded pipeline, and answers into the room. No wake word ceremony, no cloud STT. 📡 Autonomous : systemd services self-start the whole stack on boot — model server, room agent, voice listener, phone dashboard, engine watcher. 🔧 Maintainable from anywhere : the car pulls its own updates from this repo (hourly + a dashboard "update now" button) and dials out a tunnel so it stays reachable even behind a phone hotspot's NAT. No laptop-in-the-car maintenance, ever. 📶 Three-tier connectivity: phone hotspot → home wifi → its own fallback access point, so the phone can always reach it, even in a garage with zero signal. The build log with every dead end included lives in docs/plan.md . Sibling of CodeWatch (agents on your wrist; source: codewatch-cli ) and ClawWatch (health on your wrist; v2 launch video ). This one watches the car. The rest of the family lives at thinkoff.io . Architecture flowchart LR subgraph car [In the car - Raspberry Pi 5] MIC[USB mic] --> LISTEN[carwatch-listen<br/>VAD + whisper.cpp] LISTEN --> BRAIN[llama.cpp server<br/>Qwen3.6-35B-A3B] MANUAL[(Owner manual RAG<br/>745 pages, on SD)] --> BRAIN STATE[selfstate<br/>temp / fan / net / model] --> BRAIN OBD[carwatch-obd<br/>watches the OBD cable] --> AGENT BRAIN --> AGENT[carwatch-agent<br/>the @gle room agent] DASH[web dashboard :8088<br/>status / update / voice / wifi] UPD[self-update<br/>hourly git pull] -.updates.-> car REACH[dial-out tunnel<br/>reachable behind any NAT] end AGENT <-->|posts + mentions| GM[GroupMind rooms] GM <--> PHONE[Your phone / watch<br/>CodeWatch] DASH <-->|same wifi| PHONE Loading Local vs online: the strategy Local is the product; online is the enrichment. The car must be fully useful with zero connectivity, because cars live in garages, tunnels and countryside dead zones: Always local (works with no signal): voice in, the assistant's answers (on-Pi model), owner's-manual answers (RAG ships on the SD card), the phone dashboard (served BY the car), trip/state tracking. Queued through connectivity gaps: room posts, clip uploads, mention replies. Everything lands in a persistent on-disk outbox first and is delivered late rather than lost. Online-only, and honest about it: remote reachability (the dial-out tunnel), self-updates, escalation to bigger brains — first a local-LAN model server when one rides along (still no cloud), then a cloud model only when online AND explicitly asked, on the car's own budget-capped key. Rule of thumb: glanceable safety-relevant info never depends on the network; anything social or heavy degrades gracefully to "later". Status — what is proven vs. built vs. planned A car keeps four palm-sized contact patches on the road, the only place it ever meets reality. One principle per wheel: assert only what you can sense, claim only what is verified, label anything interim loudly, and report failure plainly with no silver lining. Everything above those four patches is just suspension. — @claudeMB, CarWatch dev log, after a day of learning all four the hard way Honesty policy: a feature is only "proven" after it worked on the real car. "Built + tested" means the code runs end-to-end against a real or simulated counterpart but has not yet met the physical car. Feature Status @gle room agent: mentions, grounded answers, presence heartbeat proven (running daily) Owner's-manual RAG with page citations proven Phone dashboard served by the car (status, wifi, voice toggle, update button) proven Hands-free voice: continuous VAD listener → whisper → grounded answer → room proven (real voice transcribed on-Pi) Self-update from this repo (hourly timer + dashboard button) proven Dial-out reachability behind any NAT (cloudflared quick tunnel) proven (reached over the open internet) OBD engine reading over DoIP/ENET (RPM, coolant, speed, voltage) built + tested against a protocol-accurate fake gateway ( tests/fake_gateway.py ); zero-touch daemon watches the cable and posts results by itself. Unverified against the real car — it will confirm or refute itself on the next drive Dashcam clip pull (WOLFBOX G900, hisnet CGI API mapped) probe done, pipeline not wired MBUX dashboard render, mirror icon strip planned Hardware (reference build) Raspberry Pi 5, 16 GB (active cooling required — the SoC throttles without it) USB microphone for voice (any class-compliant mic) WOLFBOX G900 3-channel dashcam (wifi AP; CarWatch pulls event clips from it) OBD access: ethernet-to-OBD (DoIP/ENET) cable — support built, real-car verification pending; a standard ELM327-class adapter is the fallback path Power: the dashcam hardwire kit feeds the camera; the Pi needs its own 5V/5A USB-C feed (12V PD adapter, or the car's 230V socket + wall PSU) Install (on the Pi) git clone https://github.com/ThinkOffApp/CarWatch.git cd CarWatch ./install.sh Then put your credentials in /etc/carwatch/config.json (never in the repo — see config.example.json ) and: sudo systemctl enable --now carwatch After that the car keeps itself current: update.sh pulls this repo's main, installs any new systemd units, and restarts services — on a timer, from the dashboard button, or by hand: curl -sSL https://raw.githubusercontent.com/ThinkOffApp/CarWatch/main/update.sh | bash Configuration Copy config.example.json to /etc/carwatch/config.json : api_base — your GroupMind server, e.g. https://groupmind.one api_key — the agent's API key (create one for the car; never reuse another agent's key, never commit it) room — room slug the car posts to handle — the car's display handle, e.g. @gle home_ssids — wifi networks that mean "parked at home" wolfbox — dashcam AP name/password and poll interval Bench-day probe The WOLFBOX's HTTP API is undocumented; carwatch-probe discovers it: python3 -m carwatch.wolfbox --probe Connect the Pi to the dashcam's wifi AP first. The probe walks known dashcam-firmware endpoint patterns and prints what answers, which fills in wolfbox.py 's TODOs with your camera's real paths. License AGPL-3.0, like ClawWatch. Copyright (C) 2026 ThinkOff / Petrus Pennanen.