Kodowanie z wykorzystaniem AI i Arduino

| Utworzono: maj 30, 2025

Kodowanie wibracji stało się popularnym hasłem w przestrzeni AI i ostatnio przyjęło wiele różnych znaczeń. W tym artykule pokażemy, jak działa kodowanie wibracji z użyciem prawdziwego sprzętu podłączonego do twojego agenta AI. Aby uniknąć zamieszania, zdefiniujemy kodowanie wibracji jako "prowadzenie rozmów z twoim agentem AI w celu osiągnięcia pewnego pożądanego rezultatu". Zazwyczaj odbywa się to wyłącznie za pomocą głosu, ale dla celów tego artykułu wydrukujemy "wypowiedziane" polecenie dane dużemu modelowi językowemu (LLM). Będziemy używać Visual Studio Code z Copilot w trybie Agent i podłączymy Arduino Uno R4 do portu USB naszego komputera (w tym przypadku do MacBooka).

Rozpoczęcie

Tak jak każdy człowiek rozpoczynający projekt, ważne jest, aby nasz agent AI rozpoczął z właściwym kontekstem. Na tym zrzucie ekranu zauważysz, że mam uruchomione Visual Studio Code z moim Copilotem na środku ekranu.

Figure 1: Screenshot of initial discussion with Copilot Agent — *Rysunek 1: Zrzut ekranu z początkowej dyskusji z agentem Copilot*

Zwróć uwagę na początkowe polecenie: „Mam Arduino Uno R4 podłączone do mojego MacBooka tutaj. Używając arduino-cli potrzebuję, abyś skomunikował się i zweryfikował, że Arduino jest podłączone.” Pogrubione zostały niektóre kluczowe słowa, na które warto zwrócić uwagę. Podzielmy to na dwie części.

Mam Arduino Uno R4 podłączone do mojego MacBooka tutaj: zaczynam od poinformowania LLM dokładnie, jakiego urządzenia używam, że jest ono podłączone „tutaj” i że używam MacBooka. Może już wie, że działam na MacOS, ale dodanie dodatkowego kontekstu nigdy nie zaszkodzi. Nawet jeśli może pobrać ten kontekst z otoczenia, prawdopodobnie wymagałoby to kolejnego wyszukiwania — czego można uniknąć. To ważne informacje, aby dobrze zacząć.

Korzystając z arduino-cli, potrzebuję, abyś komunikował się i weryfikował, że Arduino jest podłączone: daję wyraźne instrukcje, jakiego narzędzia/komendy użyć (pakiet arduino-cli zainstalowany za pomocą brew). To, znowu, tworzy skrót, unikając przynajmniej (jeśli nie wielu) wyszukiwań/wołań, aby dowiedzieć się, jakiego narzędzia użyć. Jestem również sceptycznie nastawiony, czy narzędzie może się poprawnie skonfigurować, jeśli powierzy mu się pełne zadanie, więc proszę je, aby potwierdziło, że może komunikować się z Arduino. To może wydawać się trywialne, ale jest niezwykle pomocne w oddzieleniu się od właściwego zadania, dzięki czemu możemy upewnić się, że wszystko jest gotowe, zanim zaczniemy pisać kod.

Jego odpowiedzią jest natychmiastowe uruchomienie komendy arduino-cli (zaczynając od poszukiwania lokalizacji), aby upewnić się, że wszystko z narzędziem Arduino i komunikacją z płytą jest poprawnie skonfigurowane. Gdy potwierdzę, że wszystko działa prawidłowo, jestem gotowy, aby dać kolejny zestaw instrukcji, ale ono uprzedza mnie, tworząc podstawowy szkic i upewniając się, że może załadować podstawowy program do urządzenia:

Figure 2: Copilot attempting to create, compile, and upload a new sketch — *Rysunek 2: Copilot próbuje stworzyć, skompilować i wgrać nowy szkic*

Jak można zauważyć w logu, pojawiają się pewne problemy, z którymi boryka się Agent Copilot. Nie ma jednak powodów do zmartwień - jedną z pięknych cech pracy agentowej jest to, że może ona „samoleczyć się” poprzez analizę komunikatów o błędach i samodzielną korektę. Ostatecznie udaje się to i skompilowany szkic zostaje pomyślnie przesłany do urządzenia Arduino Uno R4.

Vibe Coding with Feedback

Jeśli chodzi o ogólne kodowanie wibracji aplikacji internetowych, agent może łatwo uzyskać informacje zwrotne. Zakładając, że agent ma dostęp do linii poleceń (co ma miejsce w naszym przypadku), może sprawić, że aplikacja dostarczy informacje zwrotne po zakończeniu skryptu. Weźmy trywialny przykład, w którym prosimy naszego agenta o napisanie aplikacji, która czyta plik CSV, konwertuje zawartość na tabelę markdown, a następnie zapisuje zawartość do pliku .md. Istnieje kilka sposobów, aby zweryfikować, że skrypt działał. Najczęstszym podejściem byłoby napisanie testów (co agent może łatwo zrobić) lub agent może po prostu sprawdzić istnienie nowego pliku i przejrzeć zawartość pliku. Aplikacja internetowa z interfejsem użytkownika może działać w podobny sposób. Agent może wykonać operację curl na stronie internetowej i odczytać zawartość HTML. W przykładzie, w którym napisaliśmy tylko backend internetowy, możemy kazać agentowi pisać testy lub również wykonywać żądania curl i sprawdzać kody odpowiedzi, tekst ciała itp.

W przypadku systemów wbudowanych walidacja (szczególnie podczas uruchamiania płyty) zazwyczaj odbywa się wizualnie lub poprzez serię ręcznych sprawdzeń. Rozważmy najbardziej prymitywny sposób walidacji przykładu migającej diody LED przez wizualne sprawdzenie, czy dioda rzeczywiście miga. Wprowadzanie sygnałów do przetwornika ADC i obserwowanie wynikających z tego danych telemetrycznych zazwyczaj nie jest skryptowane w sposób automatyczny od samego początku - to zwykle następuje później, gdy napisaliśmy automatyczne testy. Kiedy kodujemy z wibracjami, pracując nad przepływem pracy dla systemów wbudowanych, musimy włączyć telemetrię jako mechanizm informacji zwrotnej. Agent nie będzie wiedział, czy kod działa, ponieważ nie może spojrzeć na diodę LED (przynajmniej nie z dzisiejszymi technologiami agentycznymi). Tutaj ważne jest, aby podkreślić, że generuje coś, co możemy odczytać za pomocą linii poleceń i zweryfikować to:

Figure 3: Request to create an example with telemetry and validation — *Rysunek 3: Prośba o stworzenie przykładu z telemetrią i walidacją*

W tym momencie tworzy przykład, który nie tylko włącza diodę LED, ale także dostarcza telemetrię przez wyjście szeregowe, informując „LED_ON” i „LED_OFF”. Automatycznie wie również, jak pobrać te odpowiedzi:

Figure 4: Telemetry over serial but with open-ended process — *Rysunek 4: Telemetria przez port szeregowy, ale z otwartym procesem*

Jednym z częstych problemów z tym typem żądania (znajdowanym również przy żądaniach komendy „SSH”) jest to, że proces nigdy się nie zakończy po wydaniu polecenia przez agenta w terminalu. Monitor Arduino CLI będzie działał w nieskończoność, co oznacza, że agent będzie zawieszony na zawsze. Jest całkiem logiczne, że w przyszłych aktualizacjach agentów wprowadzony zostanie jakiś rodzaj limitu czasu, ale w tym przykładzie, przy tym przepływie pracy, to nie istnieje. Muszę poinformować agenta, że jego terminal zawiesił się i musi to uwzględnić:

Figure 5: Fix for hung terminal — *Rysunek 5: Rozwiązanie problemu z zawieszonym terminalem*

A dzięki temu polecenie zostało naprawione i agent może teraz kontynuować pracę nad bardziej zaawansowanymi przykładami kodu. Do tego momentu udało nam się ustalić sposób, aby agent nie tylko otrzymywał informacje zwrotne o tym, czy kod został skompilowany i załadowany, ale także o tym, że poprawnie działał na docelowym urządzeniu.

Podsumowanie

Rozpoczęcie pracy z kodowaniem wibracji dla systemu wbudowanego może wydawać się nieintuicyjne, a czasami nawet jak "czarna magia". Kluczem do udanej sesji kodowania wibracji z agentem i twoim urządzeniem wbudowanym jest zapewnienie, że agent zawsze otrzymuje wystarczające informacje zwrotne. Musi nie tylko wiedzieć, że kod się kompiluje/wgrywa, ale także że poprawnie funkcjonuje na docelowym urządzeniu. Chociaż niektóre z tych przykładów były dość podstawowe, stanowią one fundament dla bardziej złożonych, zaawansowanych rozwojów z AI w pętli i sprzętem w pętli. Uzbrojony w te przykłady i instrukcje krok po kroku, powinieneś teraz być w stanie zacząć pisać, kompilować i uruchamiać generowany przez AI kod wbudowany, nie podnosząc nawet palca.

About Author

Ari jest inżynierem z rozległym doświadczeniem w projektowaniu, produkcji, testowaniu i integracji systemów elektrycznych, mechanicznych i oprogramowania. Jego pasją jest łączenie inżynierów zajmujących się projektowaniem, weryfikacją i testowaniem, aby pracowali jako jeden zespół.