За прошедшие годы мы привыкли ко многим типам шагающих роботов, однако есть один любопытный тип, который до сих пор вызывает эмоции и, в первую очередь потому, что сама концепция такой платформы позволяет любому желающему изготовить даже достаточно габаритного робота, служащего для переноски больших тяжестей, по пересечённой местности, причём, что особенно интересно, — роботы подобного типа могут быть созданы на базе относительно слабых* микроконтроллеров наподобие esp32 — и речь сейчас пойдёт о двуногих роботах на колёсах…

*Да, все мы знаем, что микроконтроллер esp32 никак нельзя назвать «слабым» — собственно благодаря своей мощи, доступности и беспроводным интерфейсам он открыл совершенно новую главу, когда появился, перевернув рынок. 

Здесь мы просто отметим то, что «шагающая» робототехника, разработанная на основе последних алгоритмов и тенденций, зачастую требует наличия на борту высокопроизводительных компьютерных платформ, и, поэтому, мне кажется особо привлекательным, когда появляются варианты, где всё это не нужно, — соответственно, такие варианты по объективным причинам являются очень доступными для широкого круга энтузиастов, желающих попробовать свои силы в этом направлении. 

Совсем недавно мы рассматривали самый простой способ создания искусственных шагающих систем, где мы узнали, что разработать подобное устройство весьма легко, так как для его работы не требуется даже никакая стабилизация — на мой взгляд, удивительно интересный пример, как можно добиться хороших результатов, весьма скромными средствами!  

Однако, робототехника имеет в арсенале ещё множество интересных примеров «шагающих» систем, — например, около 9 лет назад, компания Boston Dynamics представила своего складского робота, имеющего несколько необычную кинематическую схему — двуногость, в сочетании с колёсами:

Подобный робот получил невиданные до этого преимущества: возможность быстрого передвижения (за счёт наличия колёс), в сочетании с “человеческого типа” обходом препятствий, где одна нога может находиться на препятствии, проезжая через него ( например, по кочке), а другая находиться вне преграды, где при этом, сама платформа может сохранять горизонтальное положение (одна нога для этого сгибается в колене) — что выгодно отличает систему от, например, тех же автомобилей, которые накреняются, проезжая по преграде одним боком. 

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

С момента появления первой конструкции прошло достаточно много лет и, на сегодняшний день, можно констатировать, что подобный подход сочетания колёсного и шагающего варианта передвижения одновременно — в полной мере оценили многие, так как массово начали появляться различные гибридные системы, бывшие изначально просто шагающими, но, которые обзавелись колёсами, и, как показывает практика, начали получаться весьма впечатляющие своей проходимостью платформы, как, например, колёсная версия робособаки: 

Или, например, охранная робоплатформа для патрулирования территории — «Ascento»:

Таким образом, явно заметно наличие повышенного интереса разработчиков к роботам подобного (колёсно-шагающего) типа, так как они начали появляться как грибы после дождя, и количество примеров на данный момент не исчерпывается только этими.

Для нас очевидным плюсом подобной ситуации является то, что к настоящему времени, имеется целый ряд решений для изучения (если бы мы хотели построить нечто подобное самостоятельно), однако, как мы понимаем, не все разработчики горят желанием, выкладывать свои наработки в открытый доступ ;-)

Тем не менее, в результате достаточно долгих поисков, мне удалось найти весьма интересную платформу, на которой реализован подобный функционал! 

Самое привлекательное, что строится она на основе самых доступных* компонентов, в частности, на базе микроконтроллера esp32! 

Кроме того, выложен целый ряд иных исходников, например, 3Dмодели для печати компонентов робота.

*Правда, тут есть маленькая ложка дёгтя: разработчик этой системы построил её на базе кастомной печатной платы, в которую впаян как чип esp32, так и сопутствующие компоненты. 

Впрочем, это не является проблемой: мы же понимаем, что, если захотели бы строить аналогичную систему, на базе готовых плат разработки, наподобие esp32 wroom 32, где на плату выведены (на определённые пины) выводы чипа, то нам просто пришлось бы проделать всего пару шагов:

• Посмотреть в прошивке этого робота — какие выводы и для чего использованы;

• Подключить к этим выводам платы всю необходимую периферию (драйверы двигателей, плату акселерометра/гироскопа и т.д.) — обыкновенными проводками-перемычками типа DuPont.

Таким образом, несмотря на использование кастомной платы, в этом нет ничего страшного, и изучение этого решения имеет практический смысл… Посмотрим, что оно из себя представляет! 

Выглядит робот следующим образом:

Как мы видим, в такой маленькой платформе реализовано всё лучшее: езда, прыжки, наклоны (сгибанием одной ноги, больше, чем другой). 

Как уже было выше сказано, система построена на базе кастомной платы, с установленным чипом esp32 и выглядит следующим образом:

Чтобы понять, какие выводы задействовал разработчик, обратимся к основному блоку кода, лежащему по адресу (это адрес файла, после разархивации скачанного комплекта кода и документов с github — ссылка на него будет в конце): \navbot-en01-main\navbot-en01-main\src\wl_pro_robot\wl_pro_robot.ino 

Нас интересует достаточно малое количество периферии:

• Энкодеры бесколлекторных двигателей:
  судя по строкам:
  I2Cone.begin(19, 18, 400000UL)
I2Ctwo.begin(23, 5, 400000UL)
  мы видим, что i2c пины левого энкодера такие:
  SDA — GPIO 19;
  SCL — GPIO 18;
  а правого энкодера такие:
  SDA — GPIO 23;
  SCL — GPIO 5.

• Даже на страничке самого проекта написано, что правый энкодер использует ту же шину i2c, что и акселерометр-гироскоп MPU6050, таким образом, мы понимаем, что
  пины MPU6050 следующие:
  SDA — GPIO 23;
  SCL — GPIO 5.

• Для подключения сервоприводов используется UART2, который находится на 16 ,17 пинах GPIO — в явном виде это видно, например, по строкам:
  Serial2.begin(1000000);
sms_sts.pSerial = &Serial2;
  (где имя «Serial2» зарезервировано системой для UART2 и это не пользовательская переменная).

• Пины бесколлекторных двигателей:
  видно по строкам:
  BLDCDriver3PWM driver1 = BLDCDriver3PWM(32, 33, 25, 22);
BLDCDriver3PWM driver2 = BLDCDriver3PWM(26, 27, 14, 12);
  
  мы видим, что, один из двигателей (по всей вероятности, левый),
  использует следующие пины:
  32, 33, 25 — пины фаз двигателя, 22 — enable пин;
  а правый, соответственно, следующие пины:
  26, 27, 14 — пины фаз двигателя, 12 — enable пин.

• В проекте, кроме приводных устройств, используется ещё и дисплей, но его пины я предлагаю поискать вам самостоятельно. :-)

Насколько можно судить по официальному описанию проекта, в качестве основных приводных устройств использованы бесколлекторные двигатели, положение вала которых отслеживается с помощью цифровых энкодеров, на базе микросхемы AS5600, связанных с esp32 по i2c интерфейсу, где каждая микросхема содержит четыре аналоговых датчика Холла, соответственно, всё это вместе позволяет получить 4096 шагов на полный оборот или ~0,088° на один шаг.

Таким образом, получается, что на сам вал каждого из двух двигателей установлен магнит, где аналоговые датчики микросхемы отслеживают величину изменения поля. 

Как выглядит примерно похожий энкодер, можно посмотреть здесь — кстати говоря, подобного типа готовую плату энкодера можно попробовать использовать и для своего проекта! ;-)

Вкратце скажу, если кто-то не сталкивался: энкодеры нужны для точного отслеживания положения вала двигателя.

Для управления двигателями используется трёхфазный драйвер двигателей.

Если не ошибаюсь, судя по даташиту микросхемы, для подключения двигателей к ней потребуется некоторый обвес.

Если не хочется паять, есть и другие варианты, например, одноканальные DRV8313 (т.е. только на 1 двигатель) драйверы, соответственно, их потребуется 2 штуки.

Кроме двигателя, по основной плате мы можем видеть, что используется ещё и пара сервоприводов, довольно примечательных — судя по той библиотеке, которую я нашёл в подключаемом коде (servo_sts3032.h), здесь использованы два сервопривода для сгибаемых «коленей», с UART-управлением, что-то вроде такого.

Причём, подобный класс оборудования весьма интересен хотя бы тем, что очень редко встречается в хобби-творчестве — обычно, мы привыкли, что используются недорогие сервомашинки, с управлением углом поворота с помощью ШИМ-сигнала: всевозможное руление радиоуправляемыми машинками, углами поворота закрылков, хвоста самолёта и т.д. 

Однако тут, совершенно другое дело: 

• Во-первых, главным принципиальным отличием является отсутствие физического износа датчика — если в обычных сервах переменный резистор начинает достаточно быстро шуметь, что приводит к постоянному дрожанию вала, то в случае вот этих более продвинутых сервоприводов — используется магнитный энкодер, износ которого практически отсутствует;

• Также, если в случае обычных серв, можно только посылать* данные серве, чтобы она повернулась на определённый угол, то здесь можно как посылать, так и запрашивать данные по линии UART, узнавая в реальном времени
  положение вала.

*Да, я знаю, что вы скажете: «ну как же так, я использовал библиотеку servo.h (для обычных дешёвых серв), в ходе чего запрашивал текущее положение вала и она мне возвращала!» — да, я знаю, я сам так делал:-), только там это программно реализовано и библиотека, по сути, возвращает последнее ваше задание, относительно угла поворота, а не реально запрашивает эти данные у сервы…

• Кроме угла, у подобных серв можно запрашивать: скорость вращения, нагрузку (крутящий момент), потребляемый ток, напряжение питания, температуру.

  Причём, насколько я понимаю, здесь есть любопытный момент касательно
  разницы между потребляемым током и нагрузкой — по идее, логично было бы предположить, что серва могла бы передавать микроконтроллеру только величину потребляемого тока, а микроконтроллер сам бы уже вычислял величину нагрузки на валу, однако здесь это всё реализуется не на стороне микроконтроллера, например, с помощью библиотеки, которая работает с сервой — а реализовано сразу аппаратно, в самой серве и, получение двух величин сразу, позволяет производить диагностику: например, если величина тока относительно велика, даже в состоянии покоя, а нагрузка на валу отсутствует — значит какие-то аппаратные проблемы и надо разбираться… 

• Ну и ещё из приятного — такие сервоприводы имеют возможность настройки параметров PID-регулятора, что позволяет настроить серву для перемещения с нужной скоростью (агрессивно, плавно и т.д.), для достижения и удержания нужного угла, робо-манипулятором определённого веса.

Так что, как видим, штука крайне интересная…

Один нюанс, который я заметил при изучении официальных доков, заключается в том, что, насколько можно судить, разраб этого робота подключил две сервы через аппаратный мультиплексор, чтобы сэкономить количество UART выводов, и принимать/посылать данные через один и тот же. 

Обычно, в подобного рода решениях программно (с esp32 в нашем случае) посылается 0 или 1 (или ещё какая-то комбинация) на физическое аппаратное устройство, которое, в зависимости от сигнала подключает/отключает определённый комплект выводов к одному и тому же комплекту линий — в нашем случае, это шина UART, к которой коммутируется серва1 или серва2. 

Однако здесь всё это выполнено гораздо более элегантно: в основном файле прошивки (wl_pro_robot.ino) можно увидеть строки вида ID[0] = 1; ID[0] = 2, где 1 и 2 это адресные байты каждой сервы, то есть, грубо говоря, просто адрес, вшитый на заводе!  

Адрес вшит не «наглухо» и может меняться при желании, с помощью специальной сервисной программы (FEETECH Debug Software) — эта сервисная программа, насколько можно понять, позволяет не только менять адрес, но и настраивать множество других параметров для серв, в частности, значения PID-регуляторов. 

При отправке определённого запроса на исполнение/получение данных — в пакете будет присутствовать этот адрес, а все сервы подключены к одной и той же шине UART, — таким образом, все сервы кроме адресата проигнорируют это задание и только адресат его исполнит! Красота! :-)  

Таким образом, подытоживая этот момент, можно условно говоря сказать, что аппаратный мультиплексор встроен на уровне каждой сервы (хотя, тут это и некорректно — тут адресация в чистом виде; просто я тут оставался в рамках терминологии автора разработки («...multiplexing for data transmission and reception») :-) 

И значение с датчика сервы устанавливается на значение 2048 для полностью согнутой ноги (видимо, насколько я понимаю, когда робот днищем лежит на плоскости (например, на столе) и ноги полностью согнуты).

Для ориентирования в пространстве роботом используется широко известный датчик акселерометра-гироскопа MPU6050, подключенный к esp32 по i2c.

Для быстрой реакции на управляющие команды, а также, чтобы происходила реакция не только на факт «нажатия» кнопки, но и на факт «отжатия», — управление ведётся через протокол websocket, где сам робот выступает как точка доступа wi-fi, к которой подключается пользователь через смартфон (вводя в адресной строке: 192.168.1.11), после чего робот отдаёт пользователю в браузер веб-страничку, с кнопками управления, которая и представляет собой интерактивный пульт. 

Поддержание равновесия работает таким образом, что в основе своей используются алгоритмы PID, позволяющие за минимальное время, с минимальной раскачкой «туда-сюда», привести к нужному углу колёса, где для осуществления такой регуляции считываются предварительно данные с датчика MPU6050, после чего, происходит вычисление, в каком направлении, и с каким крутящим моментом необходимо повернуть колёса, чтобы устранить падение, с учётом текущего положения колёс.

Насколько можно понять, хотя бы по специфическим функциям вида (xTaskCreatePinnedToCore), в работе робота задействована операционная система реального времени FreeRTOS, которая и управляет всеми функциями, разнося логику таким образом, чтобы вся основная логика крутилась на 1 ядре, тогда как анимация «лица», отображающаяся на дисплее, крутится на 0 ядре (похоже, что так сделано для отделения ресурсоёмкой операции анимации от служебной логики, чтобы система не «тормозила»).

Подытоживая, хочется сказать, что, с моей точки зрения, это довольно интересная затея в целом, так как, если один раз разобраться, то можно строить весьма интересные штуки, например, не только настольные небольшие игрушки вроде этого робота, но и достаточно габаритные устройства, пример которого мы уже видели выше, наподобие того же самого патрульного робота «Ascento» — которого если снабдить тем же самым бензогенератором небольшого размера, то можно создать весьма «долгоиграющую» машину, высокой грузоподъёмности и высокой проходимости (в теории)…:-)

Проект, со всеми исходниками, который здесь рассматривался, находится тут.

Размещайте облачную инфраструктуру и масштабируйте сервисы с надежным облачным провайдером Beget.

Эксклюзивно для читателей Хабра мы даем бонус 10% при первом пополнении.