Кодирование с использованием ИИ и Arduino

Кодирование настроения стало популярным термином в области искусственного интеллекта, и в последнее время оно приобрело множество различных значений. В этой статье мы покажем вам, как работает кодирование настроения с реальным оборудованием, подключенным к вашему агенту ИИ. Чтобы избежать путаницы, мы определим кодирование настроения как «обмен сообщениями с вашим агентом ИИ для достижения определенного желаемого результата». Обычно это делается строго голосом, но для целей этой статьи мы распечатаем «произнесенный» запрос, предоставленный большой языковой модели (LLM). Мы будем использовать Visual Studio Code с Copilot в режиме агента и подключим Arduino Uno R4 к USB-порту нашего компьютера (в данном случае к MacBook).

Начало работы

Как и любой человек, начинающий проект, важно начать работу нашего агента ИИ с правильного контекста. На этом скриншоте вы заметите, что у меня запущен Visual Studio Code с моим Copilot прямо в центре экрана.

Обратите внимание на начальный запрос: «У меня подключен Arduino Uno R4 к моему MacBook здесь. Используя arduino-cli, мне нужно, чтобы вы установили связь и проверили, что Arduino подключен». Я выделил жирным некоторые важные ключевые слова, на которые стоит обратить внимание. Давайте разобьем это на две части.

У меня подключен Arduino Uno R4 к моему MacBook здесь: я начинаю с того, что точно указываю, какое устройство я использую, что оно подключено «здесь», и что я использую MacBook. Возможно, оно уже знает, что я работаю на MacOS, но дополнительный контекст никогда не помешает. Даже если оно может извлечь этот контекст из окружающей среды, скорее всего, потребуется дополнительный запрос — что можно избежать. Это важные сведения для начала работы.

Используя arduino-cli, мне нужно, чтобы вы связались и проверили, что Arduino подключен: я даю ему четкие инструкции о том, какой инструмент/команду использовать (пакет arduino-cli, установленный через brew). Это, вновь, создает ярлык, избегая, по крайней мере, (если не множество) запросов/вызовов для выяснения, какой инструмент использовать. Я также скептически отношусь к тому, может ли инструмент правильно настроить себя, если ему дать полное задание, поэтому я прошу его подтвердить, что он может связаться с Arduino. Это может показаться тривиальным, но это чрезвычайно полезно для отделения от самой задачи, так что мы можем быть уверены, что все готово к началу написания кода.

Его ответ - немедленно запустить команду arduino-cli (сначала ища местоположение), чтобы убедиться, что все с инструментом Arduino и связью с платой настроено правильно. Как только я подтверждаю, что все работает как надо, я готов дать следующий набор инструкций, но он опережает меня, создавая базовый скетч и убеждаясь, что может загрузить базовую программу на устройство:

Как вы можете видеть в журнале, агент Copilot сталкивается с некоторыми проблемами. Не беспокойтесь - одна из прекрасных особенностей агентского рабочего процесса заключается в том, что он может «самовосстанавливаться», анализируя вывод ошибок и исправляя их. В конечном итоге он это делает и успешно загружает скомпилированный скетч на устройство Arduino Uno R4.

Кодирование с обратной связью

Когда речь идет о создании общего функционала веб-приложений, агенту довольно легко получить обратную связь. Предполагая, что агент имеет доступ к командной строке (что и есть в нашем случае), он может заставить приложение предоставлять обратную связь после завершения скрипта. Возьмем простой пример, когда мы просим нашего агента написать приложение, которое считывает файл CSV, преобразует содержимое в таблицу markdown и затем записывает содержимое в файл .md. Существует несколько способов проверить, что скрипт работал. Самый распространенный подход - написание тестов (что агент может сделать без труда), или агент может просто проверить наличие нового файла и ознакомиться с его содержимым. Веб-приложение с фронтендом может работать аналогичным образом. Агент может выполнить операцию curl на веб-странице и прочитать HTML-содержимое. В примере, где мы написали только веб-бэкенд, агент может написать тесты или также выполнить запросы curl и проверить коды ответов, текст тела и т.д.

Когда речь заходит об встраиваемых системах, валидация (особенно при запуске платы) обычно происходит визуально или через серию ручных проверок. Рассмотрим самый примитивный способ валидации на примере мигающего светодиода, визуально наблюдая за светодиодом и проверяя его мигание. Подача сигналов на АЦП и наблюдение за выходящей телеметрией обычно не автоматизируется с самого начала - это обычно происходит позже, когда мы написали автоматизированные тесты. Когда мы занимаемся кодированием с агентским рабочим процессом для встраиваемых систем, нам нужно встроить телеметрию как механизм обратной связи. Агент не будет знать, работает ли код, поскольку он не может смотреть на светодиод (по крайней мере, не с сегодняшними агентскими технологиями). Вот где важно подчеркнуть, что он генерирует что-то, что мы можем прочитать через командную строку и проверить это:

На этом этапе он создает пример, который не только включает светодиод, но и предоставляет телеметрию через последовательный вывод, указывая «LED_ON» и «LED_OFF». Он автоматически знает, как получить эти ответы также:

Одна из общих проблем с таким типом запроса (также встречающаяся при запросах команды "SSH") заключается в том, что процесс никогда не завершится после того, как агент выполняет команду в терминале. Монитор Arduino CLI будет работать бесконечно, что означает, что агент будет висеть вечно. Вполне логично предположить, что в будущих обновлениях агентов будет введено некое время ожидания, но в данном примере, с этим рабочим процессом, его нет. Мне нужно сообщить агенту, что его терминал завис, и ему нужно это учесть:

И с этим команда исправлена, и теперь агент может продолжать работать над более сложными примерами кода. К этому моменту мы нашли способ, как агент может не только получать обратную связь о том, скомпилировался ли код и был ли загружен, но и о том, что он корректно работал на целевом устройстве.

Заключение

Начало работы с кодированием вибрации для встроенной системы может показаться неинтуитивным и иногда даже "черной магией". Ключ к успешной сессии кодирования вибрации с агентом и вашим встроенным устройством заключается в том, чтобы всегда обеспечивать агента достаточной обратной связью. Необходимо, чтобы агент не только знал, что код компилируется/загружается, но и корректно функционирует на целевом устройстве. Хотя некоторые из этих примеров были довольно элементарны, они являются основой для более сложной и изощренной разработки с использованием искусственного интеллекта и аппаратного обеспечения в цикле. Вооружившись этими примерами и пошаговыми инструкциями, теперь вы должны быть в состоянии начать писать, компилировать и запускать код для встроенных систем, генерируемый искусственным интеллектом, даже не прикладывая к этому усилий.