Jak JBlanked łączy Flipper Zero, Cardputer i PicoCalc z lokalną sztuczną inteligencją za pomocą ZimaBoard 2

Dziękujemy JBlanked za udokumentowanie innego sposobu wykorzystania lokalnej AI w tworzeniu oprogramowania dla urządzeń wbudowanych. W swoim pełnym filmie przekształca ZimaBoard 2 w lokalny serwer Ollama i łączy urządzenia przenośne, w tym Cardputer-ADV, PicoCalc i Flipper Zero, ze współdzielonym środowiskiem AI.

Zamiast próbować uruchamiać duży model językowy bezpośrednio na każdym małym urządzeniu, eksperyment rozdziela obciążenie: ZimaBoard 2 obsługuje lokalną usługę AI, a urządzenia przenośne pełnią funkcję lekkich interfejsów programistycznych. Następnie JBlanked korzysta ze swojego agenta Picoware o otwartym kodzie źródłowym do tworzenia aplikacji, sprawdzania informacji o urządzeniach i zarządzania sprzętem za pośrednictwem tego lokalnego połączenia z AI.

Informacja o współpracy: Ten artykuł opiera się na konfiguracji zaprezentowanej przez JBlanked oraz publicznej dokumentacji Picoware i FlipperHTTP. Wersje oprogramowania, dostępność modeli AI, kompatybilność sprzętowa i wydajność lokalnego wnioskowania mogą z czasem ulec zmianie.

Rezultat: jeden kompaktowy serwer domowy może zapewnić warstwę AI kilku urządzeniom typu maker o ograniczonych zasobach. Przenośny sprzęt nadal korzysta z własnego oprogramowania układowego i interfejsu, podczas gdy bardziej wymagające obliczeniowo zadania związane z modelami językowymi mogą być obsługiwane przez Ollama na lokalnym serwerze.

Lokalna konfiguracja AI w skrócie

Projekt łączy kompaktowy serwer x86 z kilkoma platformami wbudowanymi. Zamiast wymuszać ten sam stos oprogramowania na każdym urządzeniu, JBlanked używa różnych warstw połączeń, zależnie od możliwości poszczególnych urządzeń.

Dlaczego warto użyć ZimaBoard 2 jako serwera AI?

Interesującym elementem tego projektu nie jest samo to, że ZimaBoard 2 może uruchamiać aplikację AI. Chodzi o sposób, w jaki płyta zmienia architekturę małych projektów wbudowanych.

Urządzenia takie jak Cardputer, PicoCalc i Flipper Zero projektuje się z myślą o mobilności i wyspecjalizowanym sprzęcie wbudowanym. Są przydatne jako interfejsy, do obsługi skryptów, eksperymentów z oprogramowaniem układowym, narzędzi sieciowych i aplikacji przenośnych, ale ich zasoby pokładowe są znacznie bardziej ograniczone niż w przypadku typowej stacji roboczej AI.

Miniaturowy serwer domowy ZimaBoard 2 zapewnia osobny host x86 z przewodową siecią, obsługą pamięci masowej i możliwością rozbudowy przez PCIe. Dzięki temu urządzenia przenośne mogą pozostać niewielkie, a bardziej wymagające zadania serwerowe są przenoszone na inne urządzenie.

W przepływie pracy JBlanked ZimaBoard 2 uruchamia ZimaOS, a Ollama zapewnia lokalną usługę modelu językowego. Gdy usługa ta jest dostępna w sieci lokalnej, zgodne urządzenia mogą się z nią komunikować bez konieczności posiadania przez każde urządzenie przenośne wystarczającej mocy obliczeniowej i pamięci do samodzielnego hostowania modelu.

Film pokazuje również istotny szczegół dotyczący prezentowanej konfiguracji serwera: podczas działania Ollamy pulpit systemowy ZimaOS wskazuje kartę NVIDIA GeForce RTX 3060 z 12 GB pamięci VRAM. Oznacza to, że wydajność pokazana w demonstracji należy rozpatrywać w kontekście lokalnego serwera wyposażonego w GPU, a nie testu ZimaBoard 2 działającego wyłącznie na CPU.

Ollama uruchomiona w środowisku ZimaOS. Widoczny za nią pulpit systemowy pokazuje kartę NVIDIA GeForce RTX 3060 i 12 GB pamięci VRAM, co wskazuje, że prezentowany lokalny serwer AI ma dostęp do akceleracji GPU.

Jak działa lokalne połączenie z AI

Podstawowy projekt można zrozumieć jako trzy warstwy:

• Warstwa serwera: ZimaBoard 2 uruchamia ZimaOS i hostuje Ollama.
• Warstwa agenta lub sieciowa: Picoware lub stos sieciowy Flippera wysyła żądania między urządzeniem wbudowanym a lokalnym serwerem.
• Warstwa urządzenia: Cardputer-ADV, PicoCalc lub Flipper Zero zapewnia fizyczny interfejs i wykonuje działania specyficzne dla urządzenia.

Taki podział jest przydatny, ponieważ model językowy nie musi działać bezpośrednio na każdym elemencie sprzętu. Oprogramowanie układowe każdego urządzenia może udostępniać obsługiwane funkcje, a serwer zapewnia możliwości modelu wykorzystywane do interpretowania żądań lub wspomagania zadań programistycznych.

Cardputer-ADV i PicoCalc korzystają z Picoware Agent

Projekt Picoware autorstwa JBlanked to środowisko oprogramowania układowego typu open source obsługujące Cardputer-ADV, PicoCalc, Flipper Zero oraz inne urządzenia oparte na ESP32 lub Raspberry Pi Pico.

W tym eksperymencie najważniejszym elementem jest Picoware Agent. Agent zapewnia interfejs oparty na LLM z różnymi kontekstami działania, zamiast pełnić wyłącznie funkcję ogólnego okna czatu.

Jego udokumentowane tryby obejmują ogólny czat, Kreator aplikacji służący do tworzenia lub edytowania aplikacji Picoware oraz funkcje zarządzania urządzeniem, które mogą pracować z informacjami i poleceniami. Połączenie tych możliwości z instancją Ollama na lokalnym serwerze zapewnia urządzeniu przenośny przepływ pracy wspomagany przez AI, a jednocześnie przenosi obciążenie związane z modelem poza niewielkie urządzenie.

Flipper Zero wysyła żądania do lokalnego serwera AI

Flipper Zero korzysta z innego sposobu interakcji. Na nagraniu JBlanked pokazuje, jak urządzenie przygotowuje ustrukturyzowane dane żądania dla lokalnego modelu za pośrednictwem płytki deweloperskiej obsługującej Wi-Fi, podłączonej do Flippera.

Wyświetlone na ekranie dane żądania zawierają pole modelu dla qwen3.5:9b. To wyraźnie ilustruje podział obowiązków: Flipper przygotowuje i wysyła żądanie, podczas gdy wybrany model językowy działa na wydajniejszym lokalnym serwerze.

Flipper Zero przygotowuje dane żądania dla lokalnej usługi AI. Na ekranie widać pole modelu ustawione na qwen3.5:9b, a nad urządzeniem podłączono płytkę deweloperską obsługującą Wi-Fi.

To rozróżnienie ma znaczenie. Flipper nie uruchamia lokalnie pełnego modelu językowego. Jego rolą jest zapewnienie przenośnego interfejsu i ścieżki sieciowej, podczas gdy Ollama i wybrany model działają na serwerze.

Co właściwie potrafi lokalny Agent AI?

Połączenie urządzenia przenośnego z LLM staje się ciekawsze, gdy model potrafi zrobić więcej niż tylko odpowiedzieć na pytanie. JBlanked pokazuje serwer AI jako element procesu programowania systemów wbudowanych.

Tworzenie aplikacji Picoware

Picoware zawiera kontekst App Creator dla swojego Agenta AI. Dzięki temu programista może opisać aplikację lub zmianę w języku naturalnym i skorzystać z pomocy modelu przy tworzeniu lub edytowaniu odpowiedniej aplikacji Picoware.

W demonstracji App Creator otrzymuje polecenie zbudowania prostej aplikacji, która po uruchomieniu wyświetla powitanie „hello from youtube”. Agent zwraca uporządkowany opis żądanego działania oraz sposobu funkcjonowania interfejsu.

App Creator Picoware uruchomiony na PicoCalc. Agent realizuje prośbę o aplikację wyświetlającą „hello from youtube”, a obok urządzenia znajdują się Flipper Zero i Cardputer-ADV.

Może to skrócić drogę od pomysłu do prototypu, szczególnie na urządzeniu, na którym wpisywanie i edytowanie dużych ilości kodu źródłowego bezpośrednio na małym ekranie byłoby w innym przypadku uciążliwe.

Kod wygenerowany przez AI nadal wymaga weryfikacji. Wynik, który wygląda wiarygodnie, może zawierać nieprawidłowe interfejsy API, niepełną obsługę błędów, niebezpieczne założenia lub działanie niezgodne z docelowym sprzętem.

Analizowanie oprogramowania układowego i informacji programistycznych

Przepływ pracy z Agentem może również służyć jako asystent programistyczny. Zamiast traktować urządzenie przenośne jak zwykłego klienta czatu, system może łączyć lokalne odpowiedzi modelu z informacjami udostępnianymi przez urządzenie i jego oprogramowanie układowe.

Takie podejście jest szczególnie przydatne na małych ekranach, gdzie ręczne przeglądanie logów, dokumentacji lub wyników poleceń może być wolniejsze niż poproszenie Agenta o zinterpretowanie konkretnego żądania.

Zarządzanie urządzeniem

Framework Agent w Picoware obejmuje również funkcje zarządzania urządzeniem. Model może korzystać z narzędzi udostępnianych przez oprogramowanie układowe, zamiast jedynie zwracać tekst do ręcznego wykonania przez użytkownika.

W jednym z przykładów na nagraniu pada pytanie: „ile sieci znajduje się w pobliżu?”. Menedżer urządzeń odpowiada, że dostępnych jest sześć pobliskich sieci Wi-Fi, pokazując, że Agent może korzystać z informacji na poziomie urządzenia, aby odpowiadać na praktyczne prośby, zamiast polegać wyłącznie na ogólnej wiedzy modelu.

Menedżer urządzeń Picoware na PicoCalc odpowiada na pytanie „ile sieci znajduje się w pobliżu”. Interfejs zgłasza sześć pobliskich sieci Wi-Fi, pokazując, jak agent może łączyć lokalną AI z informacjami uzyskanymi z urządzenia.

W tym właśnie agent AI różni się od zwykłego chatbota. Model językowy zapewnia warstwę interpretacji i instrukcji, natomiast oprogramowanie układowe określa, jakie operacje na urządzeniu i źródła informacji są faktycznie dostępne.

Dlaczego współdzielony lokalny serwer AI jest przydatny w przypadku małych urządzeń

Ta architektura rozwiązuje podstawowy problem projektów AI dla systemów wbudowanych: najbardziej przenośne urządzenia często dysponują najmniejszą mocą obliczeniową dostępną dla modeli językowych.

Współdzielony serwer zmienia ten kompromis. Deweloper może zachować fizyczny interfejs w kieszonkowym urządzeniu, zapewniając mu jednocześnie dostęp do wydajniejszej lokalnej maszyny przez sieć.

Jeden backend AI, wiele urządzeń twórców

Jednym z bardziej użytecznych wniosków z eksperymentu JBlanked jest to, że ZimaBoard 2 nie jest powiązany z jednym interfejsem. PicoCalc i Cardputer-ADV mogą uczestniczyć za pośrednictwem Picoware, a Flipper Zero może komunikować się z tym samym lokalnym środowiskiem AI za pomocą własnego mechanizmu sieciowego.

Dzięki temu serwer staje się wielokrotnie użytecznym elementem większego laboratorium twórcy. Zamiast tworzyć od nowa środowisko AI dla każdego nowego mikrokontrolera lub komputera przenośnego, deweloperzy mogą utrzymywać usługę wnioskowania centralnie i skupić się na budowie integracji klienta odpowiedniej dla każdego urządzenia.

Ta koncepcja może również uprościć eksperymentowanie. Model można zmienić na serwerze bez wymiany urządzenia przenośnego, a oprogramowanie układowe urządzenia przenośnego może rozwijać się niezależnie od środowiska uruchomieniowego AI.

Co ten eksperyment potwierdza — a czego nie

Projekt JBlanked stanowi użyteczną demonstrację tego, jak lokalna sztuczna inteligencja może znaleźć zastosowanie w tworzeniu systemów wbudowanych, jednak należy odróżnić architekturę od gwarancji dotyczących wydajności lub bezpieczeństwa.

Lokalność nie oznacza braku konfiguracji

Lokalne uruchamianie Ollamy eliminuje konieczność wysyłania każdego żądania wnioskowania do hostowanej usługi chatbota, ale cały system nadal wymaga standardowego planowania serwera i sieci.

Należy zainstalować początkowy model i pakiety aplikacji, zapewnić urządzeniom przenośnym dostęp sieciowy do serwera, a każdą udostępnioną usługę skonfigurować z uwzględnieniem zamierzonych granic sieci. Przed włączeniem funkcji zarządzania urządzeniami programiści powinni również dokładnie sprawdzić, które narzędzia Agent AI może wywoływać.

Znaczenie ma również konfiguracja akceleratora. RTX 3060 widoczny w panelu ZimaOS firmy JBlanked ma 12 GB pamięci VRAM, dlatego przy wyborze modelu nadal trzeba uwzględnić dostępną pamięć GPU, obsługę środowiska uruchomieniowego oraz wymagania wydajnościowe planowanego zadania.

W przypadku zastosowań związanych z generowaniem kodu szczególnie ważne jest przechowywanie kopii zapasowych lub korzystanie z kontroli wersji. Jeśli edycja wspomagana przez AI spowoduje powstanie niezdatnej do użytku aplikacji lub konfiguracji oprogramowania układowego, programista musi mieć możliwość powrotu do znanego, działającego stanu.

Kto powinien rozważyć taką konfigurację?

Ta architektura jest szczególnie interesująca dla programistów i twórców, którzy już pracują z urządzeniami wbudowanymi, ale chcą eksperymentować z lokalnymi modelami LLM bez przekształcania każdego projektu w integrację z chmurowym API.

Może się przydać:

• Programiści Cardputer i PicoCalc tworzący aplikacje Picoware.
• Użytkownicy Flipper Zero eksperymentujący z narzędziami połączonymi z siecią.
• Programiści systemów wbudowanych, którzy chcą korzystać z pomocy AI blisko testowanego sprzętu.
• Użytkownicy homelabów szukający kolejnego praktycznego zadania dla lokalnego serwera.
• Twórcy, którzy chcą, aby wiele energooszczędnych urządzeń współdzieliło jeden backend AI.

Usługa AI w chmurze może być prostszym rozwiązaniem dla użytkowników, którzy potrzebują tylko okazjonalnych rozmów lub generowania kodu i nie chcą utrzymywać serwera. Większa stacja robocza albo wydajniejszy system wyposażony w GPU może być również lepszym wyborem, gdy najważniejsze są rozmiar modelu i szybkość wnioskowania.

Podejście oparte na ZimaBoard 2 staje się jeszcze bardziej atrakcyjne, gdy celem jest utrzymanie usługi AI w tym samym laboratorium domowym i udostępnienie jej kilku niezależnym projektom.

Zbuduj lokalne centrum AI do swojego laboratorium twórczego

Projekt JBlanked pokazuje interesujący kierunek rozwoju lokalnej sztucznej inteligencji: zamiast pytać, czy każde małe urządzenie może uruchomić model językowy, warto zapytać, czy te urządzenia mogą korzystać ze współdzielonego modelu działającego w miejscu lepiej dostosowanym do tego zadania.

Gdy ZimaOS hostuje Ollamę na urządzeniu ZimaBoard 2, Picoware zapewnia interfejs wspomagany przez AI dla urządzeń takich jak PicoCalc i Cardputer-ADV, a obsługujący sieć przepływ pracy włącza Flipper Zero do tego samego środowiska, cały system staje się elastycznym lokalnym centrum AI do eksperymentów z urządzeniami wbudowanymi.

Cztery demonstracje pokazują również, dlaczego serwer należy oceniać jako kompletny system. Urządzenia przenośne zapewniają interfejsy i funkcje specyficzne dla sprzętu, Ollama dostarcza warstwę obsługi modeli, a karta GPU widoczna w ZimaOS zapewnia dodatkowe zasoby obliczeniowe dla lokalnego obciążenia AI.

Jeśli chcesz zobaczyć inne możliwości lokalnych modeli na tej samej platformie, zapoznaj się z testem lokalnego asystenta AI na ZimaBoard 2, który analizuje zależności między kompaktowym sprzętem serwerowym, rozmiarem modelu, pamięcią masową i obciążeniami związanymi ze sztuczną inteligencją.

Obejrzyj pełny film JBlanked, aby bezpośrednio zobaczyć konfigurację i sposób działania urządzenia, albo poznaj projekt Picoware na GitHubie, jeśli chcesz zrozumieć, jak współdziałają Agent i obsługiwane urządzenia.

Chcesz zobaczyć, co inni twórcy robią z kompaktowymi serwerami, lokalną sztuczną inteligencją i nietypowym sprzętem? Dołącz do społeczności ZimaSpace na Discordzie, aby odkrywać kolejne projekty, porównywać konfiguracje i dzielić się własnymi eksperymentami.