Local AI Flow a cesta k Jarvisovi: kolik hardwaru dělí Iron Mana od reality

Projekt Local AI Flow od českého vývojáře vystupujícího pod hlavičkou OctopusEngine působí na první pohled nenápadně: je to sada Python skriptů kolem Ollamy¹. Právě tahle nenápadnost je ale důvod, proč se mu vyplatí věnovat katalogizační pozornost. Jde totiž o jeden z mála veřejně dostupných příkladů, kde lokální jazykový model přestává být jen chatovacím oknem a začíná mít ruce a uši — v podobě kamery, mikrofonu a nástrojů, které si dokáže sám vyvolat¹. Otázka, kterou si tenhle text klade, je záměrně technokratická, ne nadšenecká: kolik konkrétních modulů, sběrnic a řádků kódu ještě chybí mezi tímhle projektem a Jarvisem, digitálním komorníkem Tonyho Starka z filmů Iron Man?

Local AI Flow - co přesně je v repozitáři osazeno

Autor Local AI Flow definuje jako "local-first" příkazový workflow pro Ollamu, tedy pro engine, který spouští velké jazykové modely přímo na uživatelově stroji bez volání do cloudu¹. Stačí mu Python 3.10 a vyšší a žádná grafická aplikace — ovládá se čistě z příkazové řádky¹. Podle repozitáře je určen především pro modely řady Qwen, DeepSeek a Gemma, přičemž doporučená konfigurace počítá minimálně s 16 GB RAM¹.

Na "desce" projektu, tedy v jeho adresářové struktuře, najdeme následující osaditelné moduly¹:

• cli_ollama.py - jádro workflow, které posílá prompty do Ollama API a zpracovává překlady, OCR a popis obrázků
• cli_camera.py - zachycení snímku z kamery, s podporou DirectShow na Windows a V4L2 na Linuxu
• cli_record_mp3.py - nahrávání zvuku z mikrofonu do MP3
• cli_speech.py - syntéza řeči přes Piper modely v češtině, angličtině a španělštině
• james.py - interaktivní terminálové rozhraní s podporou tzv. Cowork agentů
• runner.py - dávkové spouštění flow z textových nebo JSON souborů

Mluvené slovo do textu přepisuje Whisper, hlasový výstup obstarává zmíněný Piper¹, a zvuková část si na systémové úrovni vyžádá FFmpeg a PortAudio¹. Konfigurace modelů a API endpointů je centralizovaná v lib/ollama.json, výstupy jednotlivých běhů se ukládají do aktivního adresáře a doplňuje je log v log.txt a evidence úloh v databázi tasks.db¹.

Zvláštní pozornost si zaslouží adresář assistant/, který rozděluje logiku agenta do čtyř os: profily určují, jakou roli má asistent hrát, capabilities popisují procedury, které umí vykonat, commands jsou konkrétní vyvolatelné příkazy a tasks nesou konfiguraci úloh¹. Projekt podporuje i takzvaný "thinking mode" pro modely, které dokážou explicitně vypisovat mezikroky svého uvažování¹. K dispozici je rovněž sada nástrojů MCP (Model Context Protocol) — standardizovaného rozhraní, přes které si model sám vyvolává externí funkce². V lokální vrstvě jde zatím o jednoduché nástroje jako převod ROT13, zjištění data a času nebo kalkulačku, doplněné o odkazy na externí referenční servery pro práci s pamětí entit a se souborovým systémem².

Proč tohle vůbec počítat jako krok k Jarvisovi

Jarvis ve filmech Iron Man dělá tři věci najednou: rozumí přirozenému jazyku, vidí a slyší okolí a nakonec fyzicky zasahuje do světa — otevírá dveře, řídí robotickou zbroj, podává Starkovi nástroje v dílně. Local AI Flow věrohodně pokrývá první dvě třetiny tohoto trojúhelníku, i když to sám autor v dokumentaci takhle nikde neformuluje¹. Rozpoznávání řeči přes Whisper a syntéza přes Piper mu dávají uši a hlas, cli_camera.py oči, a vrstva MCP nástrojů mechanismus, kterým model převádí svá "rozhodnutí" na volání konkrétní funkce místo pouhého textu^{1 2}. Chybí přesně ta poslední třetina, tedy fyzický zásah do světa — v repozitáři, jak je dnes veřejně dostupný, není o motorech, servech ani jiných aktuátorech ani zmínka².

Není to kritika projektu, spíš přesné vymezení, kde v pomyslné stavebnici na Jarvise Local AI Flow končí a kde by muselo navazovat něco jiného. OctopusEngine ostatně sám dlouhodobě vyvíjí i hardwarovou větev pod značkou OctopusLab, konkrétně vývojové desky pro ESP32 určené mimo jiné pro robotická vozítka³. Deska ROBOT Board z tohoto projektu umí osadit řadič H-můstek L293D pro dva stejnosměrné motorky nebo tři serva³, tedy přesně tu vrstvu, která Local AI Flow chybí. Jde ale o oddělené repozitáře bez veřejně zdokumentovaného propojení, takže spojit "mozek" se "svaly" by si dnes musel každý uživatel navrhnout sám.

Co by ještě muselo přibýt k mechanické ruce podávající nářadí

Scénář, který má uživatel na mysli — AI řízená robotická ruka, jež podává nářadí, obsluhuje 3D tiskárnu nebo plní dílčí úkoly jako v dílně Tonyho Starka — se dnes neskládá z jednoho produktu, ale ze tří samostatně řešitelných vrstev. Každá z nich už přitom má funkčního open-source zástupce.

Vrstvu jazykového a plánovacího rozhodování prakticky obsluhuje sám Local AI Flow: lokální model přes Ollamu vezme hlasový nebo textový příkaz a rozhodne, jaký nástroj nebo funkci zavolat^{1 2}. Chybí v ní ale centrální kus — most mezi "rozhodnutím" modelu a fyzickým aktuátorem. Tuhle mezeru dnes zaplňuje otevřená knihovna LeRobot od Hugging Face, která nabízí hardwarově agnostické Python rozhraní pro řízení robotických ramen a trénování takzvaných policies, tedy modelů převádějících vjem na akci, metodami jako Diffusion Policy nebo ACT (Action Chunking with Transformers)⁴. LeRobot funguje jako standard napříč levnými rameny typu SO-100/SO-101 i složitějšími humanoidními platformami, jako je sedmiosý OpenArm⁷.

Vrstva samotného ramene a řízení jeho pohybu, tedy kinematiky, je z hlediska dostupnosti hardwaru dnes nejvyzrálejší. Hiwonder přímo nabízí stavebnici SO-ARM101 postavenou na standardu LeRobot — šestiosé rameno určené k učení "teach-by-doing"⁵. Na druhém konci spektra stojí demonstrace, kterou začátkem roku 2026 publikoval Espressif: průmyslové robotické rameno řízené deskou ESP32-P4-Function-EV-Board, kde čip sám bez externího výpočetního uzlu počítá dopřednou i inverzní kinematiku podle Denavit-Hartenbergových parametrů, komunikuje s motory přes sběrnici CAN a vidí okolí přes USB kameru s rozlišením 640×480⁶. Je to přesně ten typ řešení, který dokazuje, že výpočet kinematiky dnes zvládne i jediný mikrokontrolér za pár stovek korun, ne serverová farma.

Vrstva vnímání prostoru — kam přesně sáhnout, jaký objekt uchopit — je naproti tomu pořád nejslabším článkem. Espressifova demonstrace řeší vizuální detekci na úrovni jedné kamery a jednoho objektu⁶, zatímco Jarvisova schopnost interpretovat v reálném čase celou dílnu a podat "ten správný šroubovák" vyžaduje robustní 3D vnímání hloubky a manipulaci s neznámými objekty. Tuhle úlohu teprve řeší akademický i komerční výzkum — rodina modelů typu vision-language-action, na kterou cílí i zmíněné policies v LeRobotu — a rozhodně ne se spolehlivostí blízkou lidské ruce⁴.

Odhad vzdálenosti: proč jde o roky integrace, ne o objev

Z pohledu jednotlivých komponent k sestavení domácího Jarvise nechybí žádná zásadní technologie, kterou by bylo nutné teprve vynalézt. Lokální LLM na spotřebitelském hardwaru už běží — Local AI Flow to dokazuje na Qwen a Gemma se 16 GB RAM¹. Hlasové rozhraní je hotové řešení v podobě Whisperu a Pipera¹, MCP dává standardizovaný způsob, jak model propojit s libovolnou funkcí², levná robotická ramena s otevřeným řízením existují a stojí řádově tisíce korun⁵, a i výpočet kinematiky přímo na mikrokontroléru bez PC má hotovou demonstraci v podobě ESP32-P4⁶. Chybí ale integrační vrstva, která by tohle vše svázala do jednoho spolehlivého systému s nízkou latencí a bezpečnostními pojistkami. A právě tahle vrstva bývá v reálných inženýrských projektech vždy nejdražší a nejpomalejší, protože ji nelze koupit jako hotovou součástku.

Namístě je proto technokratický, ne utopický odhad. Sestavit funkčního "Jarvise v dílně" — hlasem ovládanou ruku, která spolehlivě podá konkrétní nářadí ze stálého, předem naučeného sortimentu — je dnes otázkou týdnů až měsíců integrační práce jednoho zkušeného makera, ne desetiletí výzkumu. Sestavit Jarvise, který stejně spolehlivě zvládne neznámý předmět v neuspořádané dílně tak, jak to dělá film, zůstává úlohou na roky vývoje v oblasti obecného robotického vnímání — tam totiž limitem není dostupnost desek ani modelů, ale přesnost a spolehlivost samotného uchopení.

Jak si to reálně poskládat na vlastním hardwaru

Kdo chce scénář z tohoto textu vyzkoušet doma, může postupovat po vrstvách popsaných výše, aniž by musel čekat na jediné hotové "AI rameno v krabici".

Základní hlasovou a rozhodovací vrstvu rozjede rovnou klonování Local AI Flow a instalace Ollamy s modelem z rodiny Qwen nebo Gemma — podmínkou je stroj s alespoň 16 GB RAM a nainstalovaným FFmpeg a PortAudio pro zvukovou část¹. Pro hlasový vstup a výstup stačí zapojit skripty cli_record_mp3.py a cli_speech.py, pro zrak cli_camera.py¹.

Fyzickou vrstvu lze poskládat dvěma směry podle rozpočtu a cíle. Levnější a rychlejší cesta vede přes stavebnici Hiwonder SO-ARM101 kompatibilní s LeRobotem, kde uživatel nemusí sám řešit kinematiku ramene — tu za něj odemyká přímo knihovna LeRobot a její předtrénované modely typu ACT nebo Diffusion Policy^{4 5}. Náročnější, ale poučnější cesta kopíruje Espressifovu demonstraci na desce ESP32-P4-Function-EV-Board s CAN modulem pro DM motory a USB kamerou, kde si uživatel osadí a naprogramuje výpočet kinematiky přímo na desce⁶. Kdo chce zůstat u české komunitní scény, najde odrazový můstek pro ovládání motorů a serv i v desce ROBOT Board z projektu OctopusLab se zmíněným řadičem L293D³ — jde ale o desku určenou primárně pro pojezdová vozítka, ne pro víceosé rameno, takže by vyžadovala vlastní mechanickou nástavbu.

Poslední krok, který dnes nikde nedostanete hotový, je samo propojení: napsat vlastní MCP nástroj nebo capability modul v adresáři assistant/ projektu Local AI Flow, který přijme příkaz z jazykového modelu (třeba "podej mi křížový šroubovák") a přeloží ho na sekvenci pohybů odeslanou přes LeRobot nebo přímo po sériové či CAN lince do řídicí desky ramene^{1 4}. Právě tahle spojka mezi jazykovým a mechanickým světem je dnes jediné, co si musí každý zájemce postavit sám — a je to zároveň nejpřesnější odpověď na otázku, jak blízko k Jarvisovi skutečně jsme: technologicky blízko, integračně ještě ne.