Залипательное DIY роботостроение.
ПЕРВАЯ ЧАСТЬ
Как то мой друг на ДР подарил мне Ардуино-набор. Я посмотрел на набор, сказал ага, спасибо и полгода к нему на притрагивался. Но была пандемия, уже второй ее год, времени было много и я как то полулежа не диване с ноутбуком, я прицепил светодиод к пину ардуино (через резистор конечно) и помигал им. Пфф, блин, подумал, какая фигня, не понятно зачем все это нужно...
Но потом в течение года неверно, то тут, то там смотря на датчики, моторы, простоту управления всем этим я как то втянулся. Больше всего меня торкнули сервомоторы. Подключил три проводка, код в десять строк и мотор бодро жужа выставляет угол который ты ему задал. Помню как я выход гироскопа ADXL345, ну угол его относительно земли, подключил к углу сервомотора. Без всякого PID (системы с обратной связью) даже просто вот так: уголМотора = центрУголМотора + уголГироскопа. Конструктивно там был один сустав, гироскоп был прикреплен к серву верхнего сустава и получается “держал” его ровно относительно земли. Просто крутя эту конструкцию, которая быстро реагировала на поворот нижнего сустава и крутя её туда-сюда, я подумал, блин, а прикольно.
И Остапа понесло…
JAD
Это расшифровывается как “Just another dog”. Робо-собак в то время, не делал только ленивый. И я решил сделать свою конечно. Исходя из своего бюджета. Как то мониторя Авито по словам “серво, ардуино и вообще” и наткнулся на интересную объяву. Там кто-то пробовал такого “робота” полностью сделанного из сервов и П-образных соединений. Хочу сказать спасибо этим добрым людям, так как, для виду поторговавшись, я за 5 тысяч рублей купил кучу сервомоторов и конструктива для их соединения. Робот выглядел вот так (картинка слева), но уже через 15 минут уже так (картинка справа).
Так как я понимал что это совершенно не рабочая конструкция и оно никогда не будет ходить. А куча сервов очень пригодятся.Про собаку. Мне все приходилось делать на коленках и из подручных материалов. Я какое то время думал из чего сделать “тело” собаки чтобы к нему прикрепить суставы ног. Потом нашел в инете конструктив для квадрокоптера, это были две пластины из карбона с кучей отверстий. Они были очень легкие и прочные. Использовав их и стойки для квадрика я сделал корпус внутри которого был отсек для 4x16850 аккумов и место для ардуино с контроллерами для сервов. Суставы ”ног” были сделаны из этого алюминиевого же робо-конструктива.
Управление собакой осуществляется с помощью пульта по радиоуправления. На нем два джойстика и куча кнопок. Выкинув из пульта все что в нем было, я оставил там только джойстики, кнопки и корпус. Засунул туда Arduino Nano, модуль для RC (Radio controlled) и аккумулятор. На собаке соответственно тоже такой модуль. RC связь очень быстрая и у меня по квартире, например работает везде. Данных там правда много не передашь но для управления таким простым устройством хватает.
Сначала в ногах было по три сустава. Последней была такая пяточка которая, как потом оказалось, была совсем не нужной. Она только добавляла вес и кушала энергию.
Софт для управления я написал на основании найденного в интернете кода для управления хексаподом сильно переработав его. Там по сути нужно сделать довольно простой цикл походки: три ноги стоят на земле и они все двигаются вперед передвигая теsло, четвертая нога поднимается и делает шаг побольше, потом все повторяется с другой ногой и так по циклу. Ну и пару вариаций походок еще делается в зависимости от нужд. Для движения в право-лево, то есть в бок, нужно ногу которая поднимается ставить не вперед а в вбок. Сложнее было сделать плавный переход между движениями вперед- назад и вправо-лево, чтоб джойстиком плавно управлять. Но если грамотно совместить циклы подъема и опускания то все получится. Подробности про софт
В то же время я копал симуляторы физики. Остановился на MuJoCo это легковесный 3д симулятор на Python, который в последствии стала мантейнить DeepMind. Я засунул в нее .STL модели моторов и конструктива, описал где что стоит, как крутится и сделал модели ноги а потом и всей собаки.
В симуляторе и отрабатывал походку и плавность переходов. Плата Arduino соединенная с ноутом принимала сигнал с пульта и посылала данные в Python модуль который в зависимости от положения джойстиков менял углы поворотов сервов. Только не реальных сервов а их моделей в 3д симуляторе. Таким образом получилось отладить код управления без мучений собаки в реальности.
С такими короткими ножками собака ходила очень смешно, скорее семенила. Быстро стало понятно что у такой платформы нет развития. Ну то есть для нее бессмысленно делать ориентацию в пространстве, навигацию, навешивать камеры и пр. Так как собака за пару минут проходила только метр и её шатало из стороны в сторону.
Захотелось чего то побыстрее, помобильнее и с большими возможностями.
В процессе работы с сервомоторами начали вскрываться тонкости которые сразу были не видны, я понял что управление сервами довольно условное. То есть ты даешь угол на который должен повернутся вал сервы. Но в какой момент он реально повернулся и на этот угол неизвестно. И что самое плохое неизвестно в каком положении стоит вал при включении сервы. Это очень неприятный момент и я пытался решить его разными способами.
Подробности управления сервами на PWM (pulse-width modulation, ШИМ)
Сервомоторы управляются сигналом PWM.
Дело в том что каждая серва потребляет довольно много мощности и допустим когда крутятся все 12 серв, то ток потребления подскакивает до 9 ампер а то и больше. Аккумуляторы хоть и мощные и спокойно держат такую нагрузку все равно это стресс для всей системы, так как сервы рвут с места на полной мощности и скорость у них не регулируется, могут и палец зажать конкретно.
Когда собака выключена её “ноги” могут быть перемещены в любое положение. Когда она включается идеально каждая серва должна была бы сообщить что она в таком то положении и соответственно программа бы вычислила угол и скорость и мягко переместила бы сервы в некое “среднее” положение ног собаки, из которого она могла бы начать любое действие. Но сервы дешевые, в них есть только канал управления, а от себя данных никаких они не передают.
Так что этот рывок всей собаки при старте, во первых ужасно бесит, и говорит о том что ты не управляешь системой, что еще больше неприятно.
Перебрав несколько вариантов, я пришел к решению с линией задержки питания. Так как у сервов отдельное питание 6 вольт, то легко на с ключом на MOSFET транзисторе собрать блок который будет подавать на них питание, во первых с задержкой на то пока AVR и контроллер PWM загрузится и начнет работать и во вторых подавать это питание плавно, по нарастающей. Это и было сделано, что спасло много конечностей собаки и моих пальцев от зажима. Потом я еще добавил то что все 12 сервов включаются последовательно, друг за другом, что тоже снизило нагрузку на систему.
Знакомая, которой я показал это видео спросила меня: “А откуда ты знаешь какой проводок куда подключать?”. Я задумался. А действительно, откуда? И куда? Это как спросить художника почему он именно в этом месте холста нанес такой оттенок цвета. По ощущению.
Подробности про определение реально положения вала сервы
Нам неизвестно в каком реально положении в данный момент при работе находится вал сервы. Мне пришлось запросить помощь интернетов и она пришла. Внутри каждой сервы есть потенциометру который закреплен за ее вал и по показаниям которого внутренняя схема сервы работает. Припаиваем к центральному контакту этого потенциометра 1 проводок. Земля у нас одна, и получается что когда вал движется потенциометр крутится и на проводке меняется напряжение. Нам без разницы какое оно, важно то что оно пропорционально углу поворота вала. А нам это и нужно. Теперь напряжение на каждой серве и есть угол поворота в реальном времени. Так и делаем. Покупаем 4 трех-канальных вольтметр INA3221, подсоединяем к каждому каналу по серву, 12 сервов - 12 каналов и вуаля у нас сервы отдают угол. Ну там еще нужно мин макс подобрать, соотнести его с углом, но это уже детали.
Пыля
У знакомой сломался робот-пылесос и он достался мне. Разобрав его я там нашел много интересного. Все таки бытовые приборы довольно сильно развились благодаря прогрессу микроэлектроники. Там была основная плата, плата с камерой и вай-фай модулем, куча микровыключателей с разных сторон, ИК датчики, модуль аккумуляторов, ну и конечно начинка самого пылесоса.
Основная плата управления была бесполезна, так как она была на STM32 и выполняла свой определенный круг задач. А вот платформу, с двумя моторами которые крутили колеса и третьим колесом для равновесия я погонял какое то время. Установил на нее ардуину с драйвером для моторов и подсоединив к тому же пульту сделал таким образом подвижную платформу. С точностью хода у нее была беда конечно, так как всего два колеса. Если они крутятся одинаково, то едем вперед или назад. Если чуть по разному то уже поворачиваем.
Я пытался сделать чтобы платформа как то чувствовала пространство. Пробовал ИК датчики и сенсоры TOF. ИК датчики представляют собой светодиод и фотодиод в инфракрасном диапазоне, направленные под углом для того чтобы отражение луча светодиода от препятствия попадало на фотодиод. ИК датчики работали не очень уверенно, на небольшом расстоянии, где то до 10-15 см и их работа сильно зависела от поверхности которая перед ними, ну и они совсем не работали при солнечном свете.
А вот TOF были уже интереснее. TOF это “Time of fly”. В датчике стоит лазер и приемный модуль для отраженного луча. Датчик замеряет время между пуском пучка света и его прибытием, вычисляя таким образом расстояние до той точки куда он направлен. Датчик стоит относительно недорого и легко подключается к ардуино. Но проблема в том что он узко направлен, ну то есть это луч лазера и соответственно он определяет расстояние только до той микро точки куда он направлен. Я прикрепил датчик на небольшую конструкцию которую равномерно крутила серва. Таким образом получился радар, который крутился в плоскости и записывал в буфер координаты точек которые перед ним. Этот буфер графически отображался как линия, ну или набор точек, как срез пространства перед платформой.
То есть платформа уже могла останавливаться перед препятствиями и крутя “радаром” находить пространство куда можно было ехать.
Но катался этот пылесос очень неповоротливо. Хотелось чего то более подвижного.
OMNI
Как то в инернетах наткнулся на интересного вида колеса, платформа на которых ездила любую сторону не поворачивая колеса совсем. Мне показалось это интересным.
В то время я уже не покупал комплектующие и материалы для своих проектов у московских контор. Раз заглянув на Алиэкспресс я понял где счастье. Там как раз я и прикупил первые Mecanum колеса и моторы к ним. Пока они шли, эх да это не быстро, я делал платформу под них.
Платформа состоял из карбон пластины к которой крепились эти моторы и на которой стояло все остальное. 4 колеса, 4 мотора и все.
Изучив принципы управления, написал код. Тут уже хотелось сделать все с запасом и на управление я взял контроллер Arduino MEGA 2560 PRO. Там же на Алике взял плату BMS и аккумуляторы 16850. BMS (Battery Management System) это маленькая плата контроллер которая которая управляет зарядом каждого аккумулятора подсоединенного к ней также она защищает их от перезаряда.
Каталось все как то так:
Подробности про подбор PRM (обороты мотора в минуту) моторов и про параметры моторов вообще
Я не знал моторы каких оборотов нужно было под такую платформу. По этому пришлось делать все методом подбора. Сначала я взял 300 оборотов на них платформа очень медленно и тяжело стартовала но потом разгонялось очень сильно, мне так не нужно было. Я заказал новые моторы на 170 оборотов. Эти было получше хотя все равно разгон был долгим, нудным, с пищанием. Дела в том что моторы то щеточные, они стартуют только с определенного напряжения, ну то есть у них есть зазор, ступенька в управлении. Условно, когда драйвер им дает 8 вольт они еще не едут а пищат. А когда 9 уже крутят, но не сильно. А потом в 12 вольт уже гонят по полной. Короче неравномерно как то. Ну и зависит от нагрузки конечно, от веса самой платформы.
У щеточных мотор есть 4 важных параметра: скорость вращения вала, момент силы, ток потребления и напряжение питания. Все эти параметры подбираются в зависимости от нагрузки. Поэтому грамотные производители приводят эти параметры в табличках, там есть значения холостого хода (No load) без нагрузки, с номинальной нагрузкой (Nominal) и такой нагрузкой при которой мотор останавливается, пиковое значение (Stall).
Для примера даю табличку с характеристикой мотора установленного на моей платформе (он в красной рамочке). Как видно китайские товарищи выпускают большой модельный ряд моторов, можно легко подобрать нужный.
Для конкретной задачи нужно найти соотношение скорости вращения вала и момента силы. Ну и мощность блока питания должна обеспечивать необходимый ток потребления.
Сам корпус Mecanum колес которые я приобрел в первый раз был пластиковый. Маленькие прорезиненные ролики закреплены через пластиковые втулки. И когда платформа едет, колеса издают такой неприятный и довольно сильный звук. Наверно это вибрация этих пластиковых втулок. В описании колес про это конечно ничего не было, эффект неприятный, шуму очень много от движения. И эти сами прорезиненные ролики сделаны из какой то очень жесткой резины, они скорее тоже пластиковые чем резиновые.
Я к чему так подробно, к тому что например сделать такую платформу с голосовым управлением нереально. Когда она едет грохот такой что микрофоны на платформе кроме колес ничего не зафиксируют.
И у меня еще есть всенаправленный микрофон. Вот такой, довольно бюджетный вариант.
Это плата с микрофонами направленными по 6 сторонам и один по центру. Эта платка для определения направления на источника звука. Справа на картинке пример выхода с микрофона. Он выдает битмап 16х16 пиксеоей с “облаком” направлений на источник звука. В данном случае видно что звуки идут откуда то с юга, юго - запада и сверху, так как сигнал попадает на центральный микрофон в основном.
Ту от есть вы ее ставите на робота и он может определить с какой стороны источник звука и как то реагировать, повернутся например к нему. Так вот при таком грохоте от пластиковых колес все микрофоны реагируют на них. Хотя ради справедливости стоит сказать что когда сервы дешевые крутятся микрофоны тоже их слышат.
SLAM проблема
SLAM - (“Simultaneous localisation and mapping”, одновременное определение положения в пространстве и картирование).
Допустим робота включили в каком то помещении, ему нужно понять, где он находится, т. е. локализовать свое местоположение. Если у него есть карта помещения, ему нужно определить точку на карте, в которой он находится. Если у него нет карты, то нужно построить эту карту, и потом определить точку в которой он находится. Тут палка о двух концах или проблема яйца и курицы.
Это довольно сложная проблема, много кто ей занимается и она решается разными способами в зависимости от необходимой точности данных о местоположении и доступности данных о среде.
Простое готовое решение это данные с GPS (только координаты, без ориентации).
Но, GPS плохо ловит в помещениях и точность у него иногда сильно гуляет и измеряется метрами (в гражданском диапазоне). Нам это не подходит.
Для роботов один из способов - VSLAM это локализацию по видеопотоку (стерео видеопотоку или даже просто по одному видеопотоку) плюс информация с IMU датчиков, акселометров, гироскопов и магнитометров. (IMU - “Inertial measurement unit”, инерционный измерительный блок).
Для любых способов SLAM хорошо бы проверять данные, сравнивая их с реальностью. Данные которые берутся для проверки, которые более-менее точны называются Ground truth. Так как я пробовал разные способы SLAM мне пришлось сделал эту систему проверки положение робота, чтобы сравнивать разные системы SLAM.
Система Ground truth, которую я сделал, представляет собой камеру (ESP32-CAM в моем случае) прикрепленную на потолке, прикрытым полосовым ИК фильтром и отсылающую видеопоток по сети Wi-Fi.
И три инфракрасных светодиода закрепленных на роботе определенным образом. Один светодиод спереди платформы, посередине и два сзади по углам. Расстояние до переднего светодиода должно быть больше чем расстояние между угловыми, задними светодиодами. Светодиоды должны быть выше всего и не закрываться никакими частями робота, они должны светить вверх.
Подробности как работает система. Расчет
Система расчета координат простая, основаная на элементарной тригонометрии. На кадрах принятых с потолочной камеры, вида сверху, на черном фоне видно только три точки (так как камера через полосовой ИК фильтр видит только светящие в ИК диапазоне светодиоды). По расстоянию между точками, с довольно большой точность (которая зависит от разрешения видеопотока и диаметра светодиодов) можно определить координаты центра треугольника образуемого этими тремя точками в системе координат кадра с камеры. Это и есть центр вашего робота x,y. В добавок, так как это равнобедренный треугольник а основание его меньше боковых сторон, то можно определить и угол поворота платформы, что тоже очень важно.
При движении точки перемещается и после расчета вы получаете координаты центра x,y и угол поворота А. Это и есть Ground truth данные с которыми можно сравнивать точность работы разных SLAM систем. У меня в комнате с камерой на люстре эта система “ловила” координаты платформы, с довольно хорошей точностью, в пространстве размером где то 2х3 метра (2х3 потому что кадр у видео-камеры не квадратный).
Lidar (Light Detection And Ranging)
На проекте “Пыля” - платформы от робота пылесоса я испробовал простой радар на датчике TOF, который крутился в плоскости и выдавал линию из точек, дальности до предметов на которые он был направлен. Точность измерений не очень, серво жужжит, да и крутится не быстро. По этому я решил купить бюджетный лидар.
Нашел на Алике какое то предложение, проверил есть ли примеры кода для работы с этим лидаром. Код нашел, но на С. Купил лидар, где то в районе 1200 р. Код на С переписал на Python так как мне нужно было чтобы он работал на Jetson Nano с моими другими модулями на Python. Пришел лидар, после включения он шустро выдавал на серийный порт угол, дистанцию до точки куда попал луч и параметр уверенности в правильности данных. И так от 0 до 359 градусов, то есть по кругу. Модель конечно дешевая, какая то некондиция или просто старая модель от робота-пылесоса. Ну работает же, ок.
Карта. Лидар + Ground truth
Таким образом я получил возможность получить данные для построения карты препятствий вокруг робота. Почему данные а не сразу карту, потому что нужно еще сделать ряд преобразований.
Лидар закреплен на платформе примерно в её геометрическом центре. Графически данные лидара это неровная линия из точек вокруг центра. Карту я решил строить довольно грубую. Для того чтоб быстро работала и мне, по сути, нужно просто видеть препятствия в реальном времени для того чтобы объезжать их. Супер миллиметровая точность тут и не нужна.
Подробности про построение карты
По этому пространство разбивается на условные ячейки, размером в два раза меньше габарита самого робота. Итак мы получили сетку. В центре робот. Наложили данные лидара, это просто пока точки вокруг него. Далее применяем алгоритм Raycasting. Он просто метит все пространство расположенное за каждой точкой лидара как препятствие, ну или как неизвестное. То есть если луч лидара попал на ножку стула, то дальше этой ножки он уже не сможет “заглянут” по этому мы делаем из этой точки луч, некоторой ширины и метим этим лучом все ячейки на нашей карте, которые в него попадают.
Таким образом вырисовывается уже какое то пространство вокруг робота, где то замкнутое а где то с промежутками. Вот в эти промежутки мы и можем двигаться.
На видео бордовые ячейки - куда ехать нельзя, синие - слегка можно, зеленые можно. Крестики - данные с лидара. Абрис платформы с колесами иногда пропадает и превращается в прямоугольник, Grand truth данных нет, алгоритм не справился. С - образное препятствие слева, куда тычется робот это подвижное препятствие (коврик для йоги), он его легко сдвигает.
Плюсом того что у нас есть карта является еще то что мы можем тыкнуть в точку пространства этой карты и задать эту точку как цель движения робота. Это кажется так просто, но не все так очевидно.
Мы выбираем на карте точку, как цель. Так как робот знает, при помощи Grand truth, свои координаты и угол поворота относительно ноля карты, он может определить направление до указанной цели и вычислить траекторию движения до нее. Он должен развернутся по направлению к ней и поехать, пока его координаты не совпадут с координатами цели. Все просто.
По идее, если SLAM работает верно, то он должен просто заменить собой Grand truth и все будет работать точно так же. В теории. Этим серьезные люди занимаются уже лет 30.
Объезд препятствий
У нас есть карта с нанесенными на нее препятствиями. Мы можем отдать эту карту алгоритму который ищет путь прохождения в лабиринте и таким образом решим проблему обхода препятствий. Смотрим разные алгоритмы, берем D* (произносится Д-стар) например. Ему на вход как раз нужно только ячейки помеченные как препятствия, наше положение и положение цели. И все. Тестируем.
На видео в реальном времени тыкаем в любую точку на карте, это цель куда нам ехать. Центр, это откуда мы едем. Данные с лидара синтетические, просто крутятся по кругу, для теста алгоритма чтоб лидар не гонять зря.
Затем мы разбиваем этот вычисленный алгоритмом путь на отрезки, и по этим коротким отрезкам едем до нашей точки цели. В реальном времени, в зависимости от данных лидара или нашего указания новой цели, все перестраивается и маршрут меняется.
Собственно про SLAM
У себя в проектах я стараюсь использовать программные модули быстрые, легкие и желательно без большого количества депенденси. На Python ну или с Python wrapper.
Я пытался и до сих пор пытаюсь найти программные модули SLAM которые на моем оборудовании ( 2D лидар, IMU ) могли бы решить эту проблему.
Пока я нахожу только кучу модулей для ROS и какие то обрывки кода в качестве proof of concept от научных работ по SLAM, типа FAST-SLAM 2.0 десятилетней давности, все эти Particle filter, Extended Kalman filter и Iterative Closest Point.
ROS я трогал, она мне не подходит по ряду вышеизложенных причин. Так что буду искать дальше.
Кстати вопрос к специалистам. А как роботы пылесосы с одним 2D лидаром, IMU и может простейшей одометрией за пару минут строят карту комнаты в квартире?
Они строят карту комнаты, а потом и всей квартиры, и определяют свое местоположение в ней. То есть это решенная проблема SLAM. Как они это делают? Там что Unix стоит и ROS? Не верю.
3Д принтер
Пандемия кончилась, я гулял, много думал, и вернулся я как то из парка в полной уверенности что просто ну никак мне без 3д принтера не обойтись.
Приходилось делать все их подручных материалов и подножного корма. Это очень ограничивает в возможностях создания чего либо. Казалось бы, ну вот берешь эту штуку, она вот готовая есть, совмещаешь с этой и делов то. Но как это все будет держатся? Пластик? Металл? В домашних условиях, на кухне? Насмотревшись ютьюбов, как они там ловко пекут на 3д принтерах все эти суппорты, крепления, корпуса и прочее, я понял спасение он для меня, что без него мне никак, если я хочу двигаться вперед. С 3д моделированием я знаком, смогу сделать в 3д все что необходимо.
Повторюсь, я мягко говоря не очень богатый человек. Так что я открыл Алик начал смотреть предложения по 3д принтерам. Я по ним не знал ни одного бренда, ни технологий ни цен. Я думал что меньше чем за сотню тысяч ничего даже близко не купить. Но тут обнаружилось что прогресс не стоит на месте. Мне сразу попадается предложение за 15 т.р. Это конструктор, который нужно собрать из 5-7 деталей, просто скрутив их вместе. Да не вопрос.
Заказываю. Приезжает, оказывается со склада во Внуково, даже не из Китая. Правда по Москве добирался как из Китая, неделю.
Ок. Через 40 мин после того как я его принес их ПВЗ он уже был собран и работал. Что то там резво печатал быстрыми движениями.
Я офигел. И началась новая эра.
Эра электронного производства
Да я понимаю что это не супер принтер, есть гораздо лучше. Но он печатает. Не без проблем, с некоторыми я научился бороться по ходу. Но он печатает. 7 катушек PETG израсходовано на печать, десятки деталей сделаны, 5 сопл запорото. Много отходов с суппортами, тестовыми деталями из пластика, но это ок.
Технология производства изменилась, точнее она организовалась. Все нужно делать в 3д, это очевидно. Чтобы сделать какой то блок с аккумуляторами нужно сделать в 3д модели этих аккумов, плату BMS которая там внутри стоит, все винтики крепления, все отверстия под крепление, и пустые объемы под гаечки которые потом вставляются в пластик. Учесть как этот блок будет печататься, каким боком он будет лежать на столе 3д принтера.
Если это конструктивные детали, которые несут нагрузку, нужно понимать как проходят продольные/длинные нити пластика, чтобы обеспечить необходимую прочность детали.
Если это движущиеся детали (я печатал пару планетарных передач а также подшипники и все крутится), то нужно делать необходимые зазоры между движущимися деталями. Что бы вставлялась одна деталь в другую делаешь зазор 0.1 или 0.2 мм между ними. И принтер печатает эти 0.1 мм и детали вставляются.
Когда все сделано в 3д, в этом много плюсов. Допустим можно сразу взять какие то уже сделанные детали и использовать их в 3д симуляторе. Это же круто.
Захват-манипулятор
Как только у меня появилась возможность самому делать детали я попробовал сделать захват-манипулятор на основе серво-моторов.
Это были все еще дешевые сервы на PWM управлении но уже двух размеров, появились еще маленькие, на которых можно было сделать захват. Так как контроля угла в этих сервах нет, пришлось придумывать то как остановится когда объект захвачен. Как понять что мячик уже внутри захвата. Порыв инфу я нашел датчики давления. Они миниатюрные и меняют сопротивления от давления и легко подключаются к AVR. На картинке они под резиновыми накладками.
SOC
Что бы роботу понять что захватывать ему нужно “увидеть” цель, мячик например. Для этого я использовал плату “Sipeed Maix Bit” это SOC, “Система на чипе”, собраный на K210 Kendryte. Управляются MicroPython, это почти Python, закрытая среда, где можно использовать только то что есть, ну или просто стандартный, голый Python без библиотек. Там есть что то подобное CV2, упрощенное, но работает довольно быстро. У Maix Bit еще есть экран, что удобно, так как на нем сразу отображается видео, то что снимает камера и туда поверх можно дорисовывать свою инфу, текст, графику.
На этой картинке видно что в манипуляторе еще стоит сенсор TOF, дальномер и второй сенсор APDS-9960 (это однопиксельная камера, она определяет расстояние до объекта тоже по TOF и выдает еще цвет части объект, который видит).
На этом видео пример того как реализовать слежение за объектом.
На Maix Bit происходит захват видеокадра с камеры. На этом кадре находятся, аналогом CV2, часть изображения с определенной цветовой составляющей (LAB color и все такое), далее определяется положение этого Blob (то есть пучка пикселей в кадре). И мы получаем координаты центра мячика, допустим, в координатах видео кадра. Эти координаты поступают на PID управление моторами. Если мячик в центре то стоим, если смещается вправо, едем в право, если смещается влево то едем влево и т.д. Таким образом осуществляется слежение за объектом.
Это все в автономном режиме так же как захват мячика. По TOF определяем что к манипулятору что то приближается, если оно внутри (расстояние 5 см допустим) то смотрим на цветовую составляющую через APDS-9960, если там много желтого то это наш теннисный мяч, хватаем его. Когда датчики давления достигают определенно сопротивления, останавливаем захватные сервы. Значит мяч внутри захвата, держим его.
Заключение про захват-манипулятор. Он конечно теннисный мячик удержит, но все равно получился довольно слабым, так как конечные суставы держатся на оси маленьких сервов, а это очень тонкие конструктивные элементы и что то потяжелее ими будет сложно удержать. Нужно менять идею.
Робо-палец прототип
В фильмах и мультиках я давно обращал внимания на разные варианты кистей всяких роботов и других механических персонажей. Там выглядело все убедительно. Ну что, суставы размером как у человека, гнутся в тех же местах и движения соответственно получаются человекоподобные. Нужно попробовать сделать, благо свой 3д принтер под боком, платишь только за филамент да электричество.
Возникла идея того что в самих пальцах разместить только тросики которые тянут суставы и подшипники, для мягкого их вращения. А сами тросики провести выше по руке и оттуда уже их тянуть. Это к тому же облегчит конструкцию самой кисти.
Подробности про конструкцию пальцев кисти
Перепробовав разные варианты тросиков пришел к скрученному тросу диаметром 1.2 мм., он состоял из 9 жил тонких стальных тросов (найден на Алике). Он достаточно прочный но в то же время гибкий, так как ему в суставах необходимо было изгибаться на 90 градусов. Возникла проблема с обработкой концов, при обрезании они пушились и работать с ними было сложно. Помогла пайка с кислотой (Ф-38Р наше все).
Каждый палец это три сустава. Я решил что в указательном пальце и среднем пальце нужно управлять отдельно первой фалангой, а верхние две будут управляются одним тросом. Безымянный и мизинец, так как они в основном выполняют удержательные функции тоже ограничились одним тросом на все три сустава. В итоге получилось на всю кисть 8 тросов в одну сторону и 8 в другую. То есть 16 тросов вели к 8 сервам.
Еще отдельно сгибание всей кисти вверх вниз было заведено на отдельную, мощную 25 кг серву и сгибание первой фаланги большого пальца тоже управляла еще одна 25 кг серва, так как большой палец противопоставлен всем остальным и он несет большую нагрузку при захвате. Всего 10 сервов и 20 тросиков.
Внутри каждого пальца сверху есть отверстие где заходит тросик, затем на конечном суставе он закрепляется и по низу пальца выходит. В местах где он будет изгибаться вставлены трубки из полипропилена, это такой очень прочный и скользкий пластик, без него тросы бы протерли напечатанную 3д деталь. В итоге когда палец собран, если потянуть за один конец троса то палец будет сгибаться, если за другой то разгибаться. Делать это нужно одновременно с натягом, так сказать, а то будет люфт и палец будет просто болтаться.
По этому нужна была надежная система крепления тросиков к оси сервы. Это заняло какое то время, куча пластика была израсходована на варианты-прототипы. В итоге получилась такая большая, толстая шайбы с двумя кромками под тросы которая крепилась на капроновую крестовину сервы и в ней были сделаны крепления тросов на винтах М2.5.
На прототипе, одном пальце он вроде довольно бодро все хватал, если предмет был кругленный, то он он его огибал суставами и держал довольно крепко. Если кубический предмет, то он крючком хватался за грань и первая фаланга выпрямлялась. Я подумал что много плацев усилят этот эффект. И начал делать все кисть.
Но в итоге все очень плохо работало. Это я уже понял когда доделал все пальцы на кисти и попробовал что то хватать. Пальцы болтались как попало, точности никакой, выставить палец по всем суставам было нереально, даже с двойным управлением. Люфты были жуткими, так как если держать верхние фаланги то первые просто гнулись как угодно, там же подшипники и тросы, все это свободно ходит... Не знаю откуда у меня было столько упорства все это доделать.
Короче месяца два работы коту под хвост.
К тому же рука, то есть кисть и локтевой сустав получились очень тяжелыми из-за того что я делал сустав из алюминиевого П образного швеллера, который сам весил много, плюс весь крепежный пластик, сервы и куча винтов и подшипников. Килограмма полтора все это весило.
Эпик фэйл. Эта кисть вместе с серво-собакой теперь в моем личном Музее робототехники 8) Хотя опыт, даже отрицательный, лишним не бывает.
OMNI V4
Но с Алика пришли новые моторы и Mecanum колеса к ним. Моторы мощнее, на 70 PRM. А колеса с металлическим конструктивном. Под это дело я обзавелся драйвера моторов тоже помощнее и с тормозами и холостым ходом. Решено было сделать новое шасси немного побольше, тяжелее и массивней. Так как заранее предполагалось что сверху будет конструкция с робо-рукой.
Конструкция максимально простая и жесткая, 4 П образных алюминиевых швеллера 2 мм толщиной соединенные по углам и еще один швеллер поперек, для жесткости.
В углах моторы которые скрепляются пластиком зд печати. Получилось довольно крепко.
Первые тесты катания прошли отлично. Колесо металлические, сильно дороже первых пластиковых и под весом всей платформы вели себя уверенно и двигались довольно точно и плавно. Скорость новой платформы чуть поменьше чем старой, она так не разгоняется. Но это и не нужно, но тут скорее важна точность и способность нести нагрузку так как сверху рука и её нужно балансировать, чтоб вся платформа не перевернулась. Правда со звуком все осталось по прежнему, он немного мягче, но похоже его не избежать с таким типом колес.
Пришлось так же сильно доработать систему питания. Моторам на новой руке нужно 24 вольта. А это уже банка из 8 аккумов 18650. И вторая на питание мотором шасси на 2х4 аккумов еще на 12 вольт. Все заведено на отдельные BMS-ки и можно заряжать просто от внешнего блока зарядки не вынимая аккумуляторы.
BLDC моторы
BLDC - это бесщеточные моторы, которые состоят из статора и ротора. Они, обычно мощнее щеточных гораздо эффективнее но и сложнее в управлении. Для них нужен специальный контроллер. Эти моторы довольно свежее изобретение и очень часто используются в роботостроении. На всех современных робо-собаках стоят именно такие моторы, ну и в человекообразных роботах тоже.
Свое знакомство с BLDC моторами я начал с iPower GM5208-12, недорогого так называемого Gimbal мотора, который ставят на подвесах для камер. Эти подвесы для квадрокоптеров или для ручной съемки. Обычно это два или три таких мотора которые через контроллер позволяют осуществлять более плавную съемку или держать горизонт например.
Я купил его просто попробовать и разобраться с тем как он работает, так как раньше не имел дела с таким типом моторов.
С ним пришлось купить еще контроллер ODESC V4.2 (Brushless Motor Controller) все конечно на Алике. Оказалось это довольно интересное устройство.
Управляется, точнее конфигурируется он специальным софтом Odrivetool. Там в настройках наверно сотня параметров. Разобраться в этом поначалу было очень сложно. Но потом когда все настроено, мотор как айфон, просто работает. Включаешь его, задаешь ему режим работы POSITION CONTROL например и даешь угол на который ему повернуться, скорость и момент силы. И дальше всю работу делает контроллер на самом моторе. Он знает какое у него положение после включения. И просто поворачивается на нужный угол с нужной скоростью и, что самое главное, удерживает этот угол. GM5208 не очень мощный мотор и его можно сдвинуть рукой, с трудом, но он сразу же возвращается в целевую позицию и опять держит ее. Также у этих моторов есть режим колеса, это просто вращение в нужную сторону со с определенной скоростью и еще всякие режимы. Но для робо-руки, допустим режим POSITION CONTROL самой нужный.
Так же этот мотор отдает кучу данных о себе. Положение, скорость вращения, момент силы, температуру, потребляемый ток и еще много чего. И все это с жуткой скоростью и в реальном времени.
Все общение с этим мотором происходит по интерфейсу CAN (CAN interface). Это протокол связи для конечных устройств в реальном времени. Он довольно простой, на первый взгляд, широковещательный, всего два проводка, данных передает немного зато очень быстро.
У таких моторов обычно нет вала, крепление делает прямо за ротор с одной стороны и за и статор с другой, крепить их гораздо проще, на робо-суставах например.
Такие моторы бывают еще со встроенными редукторами. Там может быть планетарный редуктор или волновой редуктор. И получается что ротор крутит “вход” редукторы а на его “выходе” получается более медленное вращение 10:1 например или 36:1, что очень увеличивает момент силы и снижает скорость соответственно. Для суставов роботов это самое то.
Важный момент про энкодэры BLDC моторов
На вал мотора, или на его вращающуюся часть, крепится магнит. А рядом в паре миллиметрах должен стоять чип, который улавливает положение этого магнита и большой точность определяет угол/положние на котором находится вал (12 или 14 бит). Этот чип и есть энкодер, обычно там датчик Холла используется и хитрый магнит у которого полярности ни сверху и снизу а справа и слева.
Так вот, если BLDC мотор без редуктора и энкодер стоит на валу или на роторе, то все ок, его конроллер четко знает на какой угол повернут вал в любой момент.
Но, если мотор с редуктором то энкодер должен так же должен стоять на валу/роторе и на валу “выхода” редуктора. То есть их должно быть два. Второй так и называется “second encoder”. Первый энкодер нужен для самого контроллера мотора, чтобы понимать его положение и управлять им. А второй энкодер нужен скорее потребителю этого мотора, так как его показания это и есть угол на который отклонился сустав. Хотя контроллеру мотора он по идее тоже нужен, так как при включении он должен знать в каком положении находятся “выходной” вал/роторе редуктора, что бы выставлять угол задаваемый пользователем.
Бывает что BLDC моторы с редукторами идут сразу с двумя энкодерами, бывает но не всегда. И это нужно учитывать при покупке. Либо вам придется самому в процессе проектирования сустава учитывать где ставить второй энкодер и потом самому делать программно-аппаратный контроль угла сустава.
Это первая часть статьи. Вторая будет про 6-DOF робо-руку, которая на видео снизу, про ее сборку и управление. А так же про опыт работы с RGBD камерой, которая кроме цвета дает карту глубины. Ну и про тонкости работы с Jetson Orin NX.
Пишите в комментарии, поделитесь вашим опытом в бюджетном DIY роботостроении.
Автор: silenzio
