Зачем эта статья
В первую очередь статья (или статьи) написана ради комментариев, чтобы развлечь себя и читателя, но с надеждой получить какие‑то дельные советы и мнения по теме проекта.
Как это началось
Точкой старта работы над проектом можно считать день, когда Дедушка Мороз положил мне под ёлку набор «Робот‑автомобиль для Raspberry Pi 4B» от Keyestudio.
Уже не помню, почему у меня за условные два часа не получилось с первого раза запустить эту машинку по дому. Пролистывая документацию я не понял идею создателей работать с камерой через VNC. Этап обучения компьютерному зрению выбивается из идеи управления машинкой. Может изображение с камеры и передается на телефон, но информацию в инструкции я не нашел. Также не понимаю, почему органы управления имеют такой вид во многих подобных проектах.
Информации о том, какая плата нужна для работы с набором на коробке не видно. На момент подарка у меня были только Raspberry Pi 1B и Raspberry Zero. Но Дедушка Мороз позаботился и об этом, узнав, что для работы с OpenCV нужен минимум Raspberry Pi 4B (4Gb). Без этого одноплатника собирать машинку не имеет смысла. Но держим в голове, что авторы проекта ориентируются на наличие малинки с 64-х битной разрядностью.
По итогу, субъективное отношение к набору подтолкнуло меня попробовать сделать что‑то своё с оглядкой на:
-
Удобное расположение органов управления;
-
Наличие видеопотока в приложении;
-
Вариативность компонентов сборки с поддержкой простых плат;
-
Дешевизна конечного устройства.
С чего начал
Идея была простая: взять минимальный набор компонентов, чтобы покрутить колесо и иметь небольшой запас pin'ов на дополнительные датчики. Если представления о том, какое устройство будет основным не было, то за место устройства, отвечающего за связь, боролись ESP8266 и NRF24L01. Устройство NRF24L01 было в списке только по той причине, что на просторах интернета для управления чего‑либо чаще все используют какой‑то огромный пульт. Поскольку у этого способа связи есть ограничения, критичные для моей идеи, в итоге список компонентов у меня остался таким:
На момент первой пробы уже выпустили Pico W, но у меня его не было, а бежать за ним я не спешил по причине, о которой скажу чуть позже. Задача у Raspberry Pico была простая: крутить колеса, а за связь с пользователем теперь отвечало ESP8266 с Wi‑Fi на борту. Протокол общения пользователя с машинкой был выбран UDP (по понятным причинам), а между устройствами — UART, о котором я вычитал в тот же вечер.
Соединить проводами два устройства проблем не составило, но была другая проблема в проекте на этом этапе. В комьюнити Arduino проекты пишутся на C, Python или Arduino C (в названии могу ошибаться), а у меня навыки только с языком PHP. И проект встал 🙂.
На чём писать и как работать
У PHP нет аналога MicroPython, по крайней мере я не нашел, да и погружаться в Python мне не хотелось. Для ESP8266 я нашел выход из ситуации. Под данную плату есть прошивка от Espressif, которая позволяет работать с устройством через AT‑команды, что не привязывает к языку. В ней оказалось всё необходимое на тот момент: включение и выключение Wi‑Fi, работа с UDP и запуск HTTP сервера. Но для Pico ничего подобного я не нашёл.
Встречал обзоры, в которых на замену Arduino IDE используют CLion, но к C душа не лежала. Для нового места работы мне нужно было познакомиться с Go. У Go есть прекрасный проект TinyGo, имеющий поддержку Raspberry Pico. По этой причине я не спешил обзаводиться платой Pico W или ESP32 DevKit v1, так как на тот момент поддержки Wi‑Fi/Bluetooth в TinyGo не было.
Таким образом, определившись с инструментами, я начал думать над тем, как работать с UART и что нужно для отправки AT‑команд в ESP8266. Пришлось прикупить USB‑TTL для написания первого кода.
Спустя неделю вечеров, установив GoLand, настроив плагин для работы с TinyGo и ознакомившись с синтаксисом языка, я добрался до работы с Serial. Получить понятный текст удалось не сразу, так как знаний про baud rate и понимания, что именно он виноват в этом, не было. И первые 10–15 минут я сражался с этой проблемой. Спустя некоторое время, удалось включить/выключить Wi‑Fi и принять собственную команду по UDP, отправляя её через программу UDP — Sender/Reciever.
Итог (промежуточный)
Только закончив работу над получением команд на Pico через UDP, я понял, что проект в такой компоновке устройств закончился. Перспектива такой машинки — ездить только по комнатам, а у меня — следовать за ней по пятам, словно с пультом управления на проводе. Поэтому на следующем этапе я начал сначала, но уже с другими компонентами и расскажу об этом дальше.
Автор: eleimt
