К 30 сентября Tesla продемонстрирует работоспособный прототип человекоподобного робота

3d-модель робота в сапр

В теории 3D-модель робота можно создать в любом 3D-редакторе, но лучше использовать твердотельное моделирование.

Мы выбрали редактор SolidWorks 2023 для платформы Windows, потому что в нём есть отличный плагин для экспорта проекта в формат URDF.

Старайтесь не описывать сразу всего робота. Добавляйте различные части к модели постепенно. Это поможет вам освоить процесс описания. Мы начали с детализации шасси.

Всё наше шасси пришлось детализировать вручную. Вот почему так важны чертежи от производителя. Глядите, что у нас получилось:

На данный момент наша модель состоит из четырёх сегментов:

И трёх сочленений (joints):

• left_wheel_to_base
• right_wheel_to_base
• caster_wheel_to_base

Для правильного экспорта нужно выполнить несколько действий.

Добавьте системы координат и определите их для всех сегментов. Лучше всего указывать системы координат от исходных точек деталей модели. За начало системы координат лучше взять центр симметрии детали, точку на оси симметрии или центр масс.

ROS и URDF требуют правосторонних систем координат (Правило правой руки). Определите, где находится передняя, задняя и верхняя части вашего робота. Ось X должна указывать вперёд, ось Y — влево, а ось Z — вверх. По умолчанию стандартные виды SolidWorks и система координат повёрнуты на 90 градусов вокруг осей X и Z. Для удобства правильного размещения осей в SolidWorks можно разместить направляющие линии.

Каждый сегмент модели имеет свою систему координат:

• CS_BASE
• CS_RIGHT_WHEEL
• CS_LEFT_WHEEL
• CS_CASTER_WHEEL

Система координат CS_BASE условно расположена в центре нашего робота. CS_LEFT_WHEEL и CS_RIGHT_WHEEL находятся в центрах колёс. CS_CASTER_WHEEL находится в центре сферы всенаправленного опорного колеса.

Добавьте оси вращения для подвижных соединений и сочленений (joints). У нас есть три подвижных соединения: два вращающихся на осях колеса и одно всенаправленное колесо, которое вращается во все стороны и поэтому не нуждается в оси. Для колёс мы поместили оси AXIS_LEFT_WHEEL и AXIS_RIGHT_WHEEL.

Если вы планируете использовать описание вашего робота в симуляциях, вам также необходимо задать реальные материалы для всех деталей модели. Вы можете подобрать примерные аналоги из стандартной библиотеки материалов SolidWorks. Экспортёр использует материалы деталей для моделирования и расчёта инерционных параметров сегментов — массы, координат центра масс, а также тензора инерции.

Выход за пределы

Конечно же, один из самых популярных аниме-жанров не мог оставаться незамеченным на Западе, и речь идет не только о выпуске аниме в Европе и Америке. Мехи сумели найти свой путь на большие экраны: одним из первых примеров можно считать фильм «Робот Джокс», вышедший в 1989 году.

В центре сюжета — конфликт проамериканского Западного Рынка и Сибирской Конфедерации на фоне постапокалипсиса. Правда, конфликт не боевой, а скорее спортивный: войны упразднены, и споры решаются битвами огромных роботов. У фильма был менее удачный сиквел и что-то вроде ответвления, «Бей и жги».

Нельзя не вспомнить и «Могучих рейнджеров», американскую адаптацию японского шоу Super Sentai. Многие сцены из оригинала перекочевали в неизменном виде (речь в основном о боевых эпизодах), но немало материала было снято заново, с привлечением американских актеров.

В числе же удачных фильмов о пилотируемых людьми мехах можно также назвать «Живую сталь» – картину о боксерских поединках между огромных роботов и семейных ценностях. Фильм с Хью Джекманом и Эванджелин Лилли тепло приняли и критики, и зрители.

Не меньшего успеха добился фильм о противостоянии кайдзю и мехов за авторством Гильермо дель Торо – «Тихоокеанский рубеж». История о победе человечества над огромными монстрами из другого измерения в прошлом году обзавелась сиквелом, и если первый фильм был признанием в любви к монстрам, то в картине Стивена С. ДеНайта чувствуется детский восторг перед огромными роботами.

Нечто отдаленно напоминающее мехов можно увидеть и в «Аватаре» Джеймса Кэмерона: силы Земли пользуются особыми роботами для сражений, хотя, конечно, этот фильм к жанру меха можно отнести с большой натяжкой.

Отдельно стоит упомянуть и франшизу Майкла Бэя «Трансформеры»: да, формально речь идет не о мехах, а о пришельцах, но корни все же можно проследить до японской анимации. Дело в том, что изначально трансформеры появились как серия игрушек американской компании Hasbro, и лишь после обретения популярности в виде пластмассовых изделий они обрели полноценный сюжет, собственный сериал и серию комиксов.

Что ждет меха в будущем — вопрос открытый, но они явно надолго останутся с нами. Сейчас мехи не пользуются столь большой популярностью, как пару десятилетий назад, но кто знает — может, в обозримом будущем появится новый «Мазингер», «Гандам» или «Евангелион», который переизобретет жанр и предложит нечто свежее и оригинальное?

Затишье перед бурей

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

А в 2007 году вышел «Гуррен-Лаганн», до сих пор считающийся одним из лучших образцов «супер-меха». В сюжете речь шла об остатках человечества, загнанных в далеком прошлом под землю. Но случайная находка простого подростка Симона, загадочный бур, подарила человечеству новую надежду в борьбе с Лордгеномом и его армией зверолюдей.

Одновременно пародируя и отдавая должное сериалам-предшественникам, «Гуррен-Лаганн» умело сочетал гротеск (здесь есть мехи размером с галактику) и интересный, захватывающий сюжет, полный остроумных шуток и тонко проработанных персонажей. Отсылки к шоу сегодня можно найти в самых неожиданных местах: к примеру, на проведенном в 2007 году конкурсе редизайна британского флага (на тот момент заходила речь о необходимости отразить на полотне также и валлийского дракона) победила именно версия с логотипом банды Гуррен, занимающей важное место в сериале.

В рамках же «реалистичного меха» в 2006 году появился главный конкурент франшизы «Гандам» — «Код Гиасс», сериал, также рассказывающий о политических передрягах больше, чем, собственно, о роботах. В альтернативной реальности мир разделился на три сверхдержавы: Священную Британскую империю, Китайскую федерацию и Европейский союз.

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

Лихие 1990-е

С приходом последнего десятилетия ХХ века жанр меха столкнулся с кризисом идентичности: «супер-меха» и «реалистичные меха» уже не казались такими интересными и свежими, как раньше, и студии ударились в эксперименты. В ход шло все: от смешения стандартных элементов («Ганбастер:

Дотянись до неба») до создания принципиально новых: например, «Мобильный воин Гандам: Восьмой взвод МС» «приземлил» историю до максимума, сделав ее предельно реалистичной, или «Видение Эскафлона», в котором мехи существуют в альтернативном средневековье.

Ключевым годом десятилетия можно считать 1995-й. Тогда вышли два важнейших для жанра сериала «Мобильный воин Гандам Дубль-вэ» и «Евангелион нового поколения». И если «Дубль-вэ» во многом просто стал сериалом, который пробил дорогу японской анимации на Запад и до сих пор считается одной из ключевых «классических» картин, то с «Евангелионом» совсем другая история.

Появление самого первого «Гандама» в свое время перевернуло жанр меха, а вот выход «Евангелиона», как считают многие, перевернуло мир аниме: в следующем году сериалу исполнится уже 25 лет, а его следы тут и там можно встретить до сих пор, не говоря о его невероятной популярности и произведенному эффекту.

Пожалуй, главное, что сделал сериал для массовой аудитории, — он показал: зритель вовсе не обязан любить роботов, чтобы с удовольствием смотреть шоу с их участием. Жанр меха больше не ограничивался политическими рамками или «монстром недели». Он даже не сталкивал привычные поджанры друг с другом.

«Евангелион» был куда больше, чем просто сериал об огромных роботах, — они здесь были лишь фоном для более сложной и глубокой истории. И если «Гандама» после выхода многие пытались копировать, то с «Евангелионом» не вышло — что, впрочем, не помешало ему стать знаковым.

О «Евангелионе» можно (и нужно) говорить больше, но в рамках разговора о жанре в целом стоит отметить необычный дизайн мехов, сочетающий биологическую и механическую составляющие, а также радикальный выход из рамок (к привычным политике и сражениям добавились психоанализ, религиозные мотивы и немало философских тем с отсылками к Кьеркегору, Гегелю и Хайдеггеру), что откроет последующим сериалам куда большую свободу в выборе тем.

Настройка wi-fi и графической оболочки

Теперь нам нужно подключиться к Интернету через Wi-Fi-адаптер на Raspberry. Предполагается, что у вас уже есть точка доступа Wi-Fi.

Первый шаг — определить имя вашего беспроводного сетевого интерфейса. Оно может быть разное, но обычно это wlan0:

ls /sys/class/net/

Затем перейдём в каталог /etc/netplan и найдём соответствующие файлы конфигурации Netplan. Файл конфигурации имеет имя типа 50-cloud-init.yaml:

ls /etc/netplan/

Отредактируем файл конфигурации Netplan:

nano /etc/netplan/50-cloud-init.yaml

Весь файл конфигурации должен выглядеть примерно так, как показано ниже. Убедитесь, что все блоки кода выровнены. Для выравнивания используйте пробелы вместо табуляции. Замените строки SSID и PASSWORD на имя и пароль вашей сети Wi-Fi.

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
	ethernets:
		eth0:
			dhcp4: true
			optional: true
	version: 2
	wifis:
		wlan0:
			optional: true
			access-points:
				"SSID":
					password: "PASSWORD"
			dhcp4: true

Запустим службу, перезагрузимся и войдём в систему:

systemctl start wpa_supplicant
reboot now

Применим изменения Netplan и подключимся к беспроводной сети:

sudo netplan generate
sudo netplan apply

Ещё раз перезагрузимся и снова войдём в систему. Теперь наша Raspberry в сети Wi-Fi, и мы можем пропинговать наш сетевой шлюз:

ip addr show
ping 192.168.88.1

Следующим шагом будет установка графического интерфейса для удобства работы с операционной системой. Обновим список пакетов из репозитория, обновим сами пакеты и установим любую понравившуюся графическую оболочку. Например, мы выбрали XFce:

sudo apt-get update && apt-get upgrade
sudo apt-get install xubuntu-desktop

Установка графической оболочки может занять некоторое время. После установки перезагрузимся и войдём в систему под ubuntu.

Привод с omni-колёсами

Этот тип привода использует особые Omni-колёса или поликолеса вместо обычных. Поликолесо — это всенаправленное колесо с небольшими роликами, расположенными по окружности. Оси роликов перпендикулярны оси вращения колеса. Контролируя скорость и направление вращения поликолёс, вы можете заставить робота двигаться в любом направлении — другими словами, сделать его движение голономным.

Обычно шасси с Omni-колёсами насчитывает ровно 3 или 4 колеса. Шасси с тремя колёсами обеспечивает большую тягу, поскольку любая реактивная сила распределяется только через три точки, и робот хорошо сбалансирован даже на неровной местности. Всенаправленные колёса имеют высокую стоимость, поэтому трёхколёсное шасси обходится заметно дешевле варианта с четырьмя.

Чаще всего для трёхколёсного шасси выбирают угол установки 120°. Иногда два колеса параллельны друг другу, а третье ставится перпендикулярно к ним. Последняя конструкция может быть более эффективной, потому что когда колёса расположены под углом 120°, только одно из них является ведущим, а два других по сути тормозят его, снижая общую скорость.

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

Пример определения векторов скоростей колёс для трёхколёсного шасси:

Четырёхколёсное шасси имеет четыре ведущих колеса, расположенных под углом 90° друг к другу. Эта конструкция удобнее для расчёта скоростей, так как два колеса параллельны друг другу, а два других перпендикулярны к ним. Как и в трёхколёсном шасси, КПД всех колёс также не используется на 100%.

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

Пример определения скорости вращения колёс для четырёхколёсного шасси:

Особенности шасси:

• Поскольку всенаправленные колёса представляют собой комбинацию из множества роликов, возникает сопротивление вращению, что приводит к повышенному трению и значительным потерям энергии.
• Не все колёса являются ведущими, в каждый момент времени эффективно работают лишь одно-два поликолеса.
• С помощью Omni-колёс достигается голономное движение робота.
• Работа поликолёс изначально строится на принципах проскальзывания. Невозможно поставить датчик вращения на каждый ролик Omni-колеса, поэтому полученная колёсная одометрия совсем неточная.
• Чаще всего роботы с таким шасси используются внутри помещений на ровных и гладких поверхностях.

Пришло время для фазы 3 — proof of concept

Необходимо сделать макет системы, опробовать в действии на поле, оценить применимость. По выработанным требованиям дело пошло гораздо веселее:

Как софт ровера был выбран Ardurover — активно развивающийся софт, начинающийся как прошивка для квадрокоптеров на Ардуино. Однако, к нынешнему моменту он поддерживает и платы на Линуксе с RTL ядром, причем открыт для доработок. Допиливать в дальнейшем пришлось к слову, но скорее для ускорения работ, чем по нужде.

Как мозги ровера был выбран BeagleBone Blue — высокоинтегрированная система для робототехники.

Отличительной особенностью является использование чипов TI Sitara/Octavo, по сравнению с теми-же Raspberry там стоят Programmable Realtime Unit — PRU. Это два отдельных 200 МГц ядра, которые могут в реальном времени управлять железом, не отвлекая основное ядро прерываниями, нитками и прочей техномагией.

Кроме этого на платформе сразу есть WiFi, Bluetooth, распаянный разъем для балансировочного кабеля, контроллер зарядки Li-Po батарей, USB разъемы для подключения телеметрии и компьютера, разъемы для серводвигателей, стабилизаторы питания 5 и 3.3 вольта, АЦП сразу заведенный одним каналом на батарею, несколько UART. В общем бери и делай робота.

Ardurover туда встал не без проблем — использовать PRU из софта на текущий момент можно только с ядром 4.4 LTS. В более новых ядрах программирование PRU из пользовательского софта приводит к SIGBUS fault, после общения с разработчиками ardublue ветки я заказал JTAG адаптер, буду смотреть в чем причина. Самому роверу это жить совсем не мешает, но хочется четкого понимания в чем проблема.

Софт позволяет делать практически все из требований, кроме позиционирования на заезд в базу, тут я использую камеру JeVois-A33. Аварийный сигнал по части событий он тоже не пошлет, но это задача для отдельного модуль с раздельным питанием, т.к. аварии по питанию или хорошего переворота управляющий модуль может и не пережить.

Осталось прикупить GPS приемник, телеметрический радиопередатчик, УЗ датчик расстояния и подключить камеру машинного зрения. После пайки, соединения разъемов и тестового запуска получилось вот так:

Как центр управления использован

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

адаптеров и прикладного софта под Java/JS написано достаточно много. В протоколе хотелось бы конечно иметь пакеты поменьше размером, и вести стандартный справочник параметров, но это было бы слишком хорошо.

Как база ровера — использована модельная машинка масштаба 1/18 с отдельными приемником и контроллером двигателей.

Приемник был выкинут, разъемы сервоприводов и контроллера двигателя заведены непосредственно на BeagleBone Blue, как и батарея.

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

На текущий момент стенд выглядит так:

Как видно — контроллер без корпуса и крепежа. К сожалению псевдогермобокс я заказал распечатать на SLS 3D принтере нейлоном, и его еще не успели сделать. Выводить же ровер в чисто поле без корпуса — ходу такому викингу полчаса на свежем воздухе. Потом или электрохимическая коррозия доест, или после переворота-удара вовсе в выброс. Так что ждем корпус, герморазъемы и и крепежи по всем правилам демпфирования ударов и вибрации.

На видео обнаружение ровером Aruco Code

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

Следующие действия — откатать маршрут 5-7 раз, снять логи телеметрии и GPS треки маршрутов. Я нашел футбольный стадион с отапливаемым полем, так что если пойдет снег — не страшно. Ровер явно не будет буровить сугробы, иначе Фаине Раневской стоило бы добавить в список извращений кроме хоккея на траве и балета на льду еще и гольф по сугробам.

Не самое дешевое развлечение, конечно, но где еще в России, да в ноябре можно найти зеленую травку. Так же начаты работы по реализации гусеничных шасси, там скорости сильно ниже (текущая модель разгоняется до 20 км/ч за 15 секунд) и есть разворот на месте, а не заезды треугольником на пятачке.

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

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

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

Программирование для робототехники: на каких языках программируют роботов

Разработка по

В этой статье не будет описываться код узлов, будут представлены только их общая структура и назначение. Подробнее про написание кода — в следующей статье.

Итак, общая схема структуры узлов ROS на BBB (в эллипсах — название узлов, в прямоугольниках — название топиков):

joy_node — готовый пакет, позволяет преобразовывать данные из файла стандартного устройства Linux (/dev/input/js) в сообщения «Joy» и транслировать их в топики ROS. Полезным будет посмотреть в tutorial пакета. Почти всегда в них кроются многие ответы на вопросы.

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

crab_leg_kinematics — узел-сервис. Его назначение — решение задачи инверсной кинематики, то есть на основе координат end-effector’а (в моем случае — это кончики ножек) вычислять углы положения суставов (углы сервоприводов). Запрос сервису формируется в виде шести векторов целевого положения кончиков ног, а ответ приходит в виде 18’ти углов сервоприводов.

crab_body_kinematics — вычисляет векторы положения концов ног на основе модели робота URDF и данных из сообщения, которое содержит желаемые линейные и угловые отклонения рамы от начального положения, а также радиус раскрытия ног. Также реализованы команды подъема из стартового положения (когда робот лежит на раме, а ноги сложены) и возврат в стартовое положение.

crab_gait — узел, генерирующий векторы положения концов ног для реализации двух типов походки. На входе — сообщения, содержащие команды о типе и состоянии походки (идти/стоять) и величины управления: углы курса и рыска и размер шага. Типы походки следующие — tripod и ripple:

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

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

crab_imu — драйвер MinIMU-9, собран из частей Arduino скетча. Содержит алгоритм расчета углов Эйлера на основе данных с MEMS датчиков. Также содержит простой П-регулятор, формирующий воздействия, компенсирующие отклонения по тангажу и крену. Эти воздействия передаются через топик move_body в crab_body_kinematics для задания нужного положения ног.

crab_maestro_controller — последний узел-драйвер для Mini Maestro. На входе у него 18 угловых положений сервоприводов, которые он преобразует в протокол общения сервоконтроллера по UART.

Типы приводов

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

Роботы могут передвигаться в 2D- или 3D-пространстве. Очевидно, что только летающие роботы способны маневрировать во всех плоскостях, и они чрезвычано сложны. Например, летающие дроны ориентируются в помещении или на местности, используя трёхмерные камеры глубины.

Если роботу нужно передвигаться только в двухмерном пространстве, всё становится уже проще. Мы можем рассмотреть движение робота как движение материальной точки в плоскости (X, Y) в прямоугольной или Декартовой системе координат (X, Y, Z).

Движение робота в плоскости может быть голономным (Holonomic) или неголономным (Non-holonomic). Что это значит? При голономном движении робот способен свободно двигаться по любому вектору XY, не меняя при этом своей ориентации. При неголономном движении робот может передвигаться только в нескольких ограниченных направлениях.

Например, обычный автомобиль не может взять и подвинуться строго вправо или влево с места — значит, его движение неголономно. С другой стороны, если бы у автомобиля вместо обычных колёс стояли всенаправленные, то он смог бы двигаться голономно.

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

Ещё одиним важным фактором при выборе привода робота является сложность получения одометрии и её точность.

Одометрия — это использование данных с установленных на роботе сенсоров и датчиков для расчёта его текущего положения и ориентации в пространстве. С некоторых приводов получить качественную одометрию очень легко — например, с двухколёсного дифференциального привода (2WD differential drive).

Мы попробовали собрать самые популярные способы передвижения для хобби-роботов.

Фаза 1. постановка задачи

Задача:

Необходим максимально непрерывный объезд тренировочного гольф поля в сложных климатических условиях для сбора шаров.

Проблема: Необходим Unmanned Ground Vehicle (UGV) для выполнения циклических миссий по объезду пространства, заданного периметром с координатами точек в WGS-84 нотации.

Миссии должны включать следующие операции:

1. Нормальный старт с известной домашней позиции
2. Аварийный старт с неизвестной заранее позиции (запуск после срабатывания WD, защиты по питанию и т.д.)
3. Объезд площади с покрытием не менее 98% пространства за 1 или несколько заездов (начать объезд поля заново после заполнения бункера через 15 минут излишне)
4. Возврат на домашнюю позицию по заполнению бункера, истощению батареи, окончанию объезда
5. Заезд на платформу старта для сброса шаров, заряда батарей

Упрощенная версия алгоритма

Кроме этого UGV должна выполнять следующие требования:

1. Не покидать указанного периметра при объезде заданного периметра
2. Домашняя позиция может находиться вне заданного периметра
3. Выполнять мониторинг расхода заряда батарей и планировать возврат с учетом израсходованной мощности. Перемещение заполненного бункера требует больше мощности от батарей, чем пустого.
4. Вести логи телеметрии включающие, но не исчерпывающиеся координатами на плоскости, значениями 6 осей вращения, уровень сигнала телеметрии и внешних датчиков.
5. Иметь три системы позиционирования — GPS для получения грубых координат, IMU для верификации и коррекции координат на плоскости, оптическая для точного позиционирования по маркерам.
6. Иметь две системы Watch Dog — программная и аппаратная. Программная верифицирует состояние
7. Иметь дальнобойный аварийный канал связи с отдельным питанием, использующийся при выходе параметров миссии за заданные параметры (координаты, авария, авария по питанию, отказ оборудования)
8. Иметь возможность изменять параметры миссии при нахождении на домашней позиции
9. Иметь два канала связи  – низкоскоростной телеметрический и высокоскоростной для передачи аудиовизуальной информации. Высокоскоростной должен иметь возможность включения/отключения по телеметрической команде.

По этим требованиям была выбрана следующая архитектура решения:

В состав роботизированного комплекса входят: один центр управления (Ground Station Control) — далее GSC.

Позволяет пользователю выполнять следующие действия:

Софт GSC должен заниматься планированием действий гольф-роботов, сами роботы же должны быть достаточно простыми. Решение не очень гибкое, конечно, но самосогласованные решения и меш-сети это не то, что можно решить в краткие сроки, да еще и дешево. Плюс — это типовой подход, а значит и известные проблемы. Один или несколько гольф-роботов (Golf rover) — далее

GR

Выполняет следующие типовые действия:

Т.к. наземных станций может быть 1, а GR много — заполнение бункера шаров отнесено к экстренной ситуации. Это решает сразу две проблемы — GSC с высокой степенью достоверности знает, что робот поехал на станцию и частое тестирование резервного канала.

Также предполагается, что заполнение шаров должно происходить в течении миссии и если это не так — GSC где-то ошиблась в планировании и это стоит исправить. Интуитивно хочется выпустить робота в чисто поле, а когда соберет шары — вернется. Но тут вступает в дело экономика, если занимается 1-2 человека — лучше роботу постоять на станции, а начать движение когда шаров уже поднакопится. Меньше расход ресурс и энергии.

Одна или несколько наземных станций (Ground Station) — далее GS.

Схема всего комплекса вот такая:

Энкодеры

Для колёсной одометрии нам понадобятся датчики угла поворота или энкодеры. Готовые шасси часто уже оснащены энкодерами, но платформа Turtle поставляется без них. По типу отдаваемых данных энкодеры могут быть абсолютными или инкрементальными.

Абсолютный энкодер выдаёт сигнал, который однозначно соответствует углу поворота вала. Энкодеры этого типа не требуют привязки системы отсчёта к какому-либо нулевому положению.

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

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

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

В основном в хобби-робототехнике используются оптические и магнитные инкрементальные энкодеры или магнитные абсолютные энкодеры. Не критично, какой тип энкодера вы будете применять. При выборе энкодера основными параметрами являются количество каналов передачи данных, количество импульсов на оборот (PPR) и максимально допустимая скорость вращения вала.

Наиболее популярны квадратурные энкодеры с двумя каналами А и В. Реже у энкодеров в хобби-сегменте есть канал с нулевой отметкой — Z. Чем выше значение PPR, тем меньше угол поворота вала, который может зафиксировать датчик. Чем точнее энкодер, тем точнее одометрия робота, поэтому не пренебрегайте высококачественными энкодерами и не используйте энкодеры с низким значением PPR.

Максимальная скорость вращения может быть любой, так как большинство энкодеров способно работать на очень высоких скоростях. Скорее всего, скорость вращения, которую вы будете измерять, будет в несколько раз меньше максимальной. Даже если вы планируете использовать высокоскоростные BLDC двигатели с высоким значением kv, то существуют энкодеры, которые работают с максимальными скоростями 28000 об/мин, 60000 об/мин или даже больше.

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

Мы обзавелись двумя такими двигателями с энкодерами — мотор-редуктор TT с энкодером (160 об/мин, 6 В, 120:1).

Почему мы выбрали именно эти моторы?

• Во-первых, их конструкция специально разработана для нашего шасси Turtle, и нам не придётся придумывать крепление.
• Во-вторых, производитель исправил существенные недостатки, заменил пластиковые шестерни металлическими и добавил схеме двигателя обвязку.
• Эта сборка имеет квадратурный магнитный энкодер с разрешением 16 PPR, установленный на валу двигателя. Передаточное отношение редуктора 120:1 даёт полное разрешение в 1920 импульсов на оборот колеса с минимальным измеряемым шагом в 0°11’15″. Для поставленной нам задачи такой точности более чем достаточно.

Заменив моторы и убрав всё лишнее, мы получили вот такое шасси: