Общие идеи

Динамика робототехнических систем: Лекция 1, Лекция 2, Лекция 3, Лекция 4, Лекция 5

Книги: Handbook of Robotics, Robot Modeling and Control

Моделирование

Существует несколько open-source решений для моделирования физических систем.

Самый популярное для роботов - это Gazebo. Он может быть использован как самостоятельное решение и как часть фреймворка ROS (Robotic Operation System).

Почитать про ROS можно здесь.

Самый распространённый формат для хранения физических моделей роботов - это URDF. Статья о том, как устроен urdf

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

Планирование движения роботов

У меня есть программа для планирования одновременных траекторий для четырёх роботов с учётом коллизий (пересечений моделей или упрощённых оболочек вокруг моделей их звеньев).

Репозиторий на гитхаб

На видео показана работа нового алгоритма. Алгоритм представляет собой улучшенный A*. Использовано две сцены: один робот и два препятствия, четыре робота. Для ускорения работы изменение координат текущей точки на сетке планирования возможно только по одному измерению.

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

Эта программа писалась под linux, в нём нужно просто установить несколько пакетов (boost, tinyxml и ещё несколько).

Под Windows собрать этот проект довольно сложно. Установку зависимостей через cmake у меня пока не дошли руки прописать.

Архитектура

Приложение состоит из четырёх модулей:

• Сайт. На сайте должна быть система авторизации. У каждого пользователя должны храниться сцены и urdf-модели роботов. Авторизованный пользователь может перемещать камеру по сцене, а также запускать моделирование. При моделировании поднимается REST-сервер, который транслирует управляющие команды в управляющее воздействие на роботов.
• Модель робота. Модель робота должна собираться как библиотека. Модель должна иметь возможность создавать условно неограниченное число параметризованных экземпляров. Каждый такой экземпляр должен иметь команды приёма управляющего воздействия, обработки внутреннего состояния, а также команды, возвращающие то или иное выходное состояние модели
• Black Board. Т.к. экземпляры моделей должны порождаться во время работы программы, то нужна некоторая надсистема, которая будет следить за всеми экземплярами и транслировать команды конкретного пользователя самому экземпляру модели. Сайт должен обращаться только к одной сущности - Black Board, а она уже эту команду преобразует в набор команд для конкретной сцены.
• REST-сервер. Чтобы передавать управляющие воздействия запущенной модели с помощью программы на удалённом компьютере, проще всего поднять REST сервер и транслировать его запросы в команды администратору моделей.

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

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

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

Подробнее о можно прочитать здесь.

Когда пользователей неопределённое число, то лучше использовать микросервисную архитектуру:

Идея такой архитектуры в том, что под каждого пользователя запускается мини-программа (микросервис), обсчитывающая именно его сцену, а к этой программе через BlackBoard уже обращаются web-клиент или rest-клиент.

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

Сайт

Сайт должен состоять из двух основных блоков: блок управления и блок отрисовки сцены:

Панель управления должна содержать следующие блоки:

• построение сцены (интерфейс по загрузке urdf-моделей), позиционирование роботов на сцене (положение, ориентация, масштаб), дерево сцены
• запуск, остановка симуляции
• информация для подключения к REST серверу
• блок отображения данных о сцене (обобщённые координаты, обобщённые скорости и обобщённые силы).

Обобщённые - это объединённые векторы положений и углов поворота, линейных и угловых скоростей, сил и моментов соответственно.

Перемещение по сцене должно быть организовано, как в Unreal Engine.

Сцена

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

Общая идея модели заключается в том, что у неё есть команды установки желаемых обобщённых координат:

Внутри модели хранится последнее заданное значение и по внутреннему циклу это значение задаётся внутренняя логика отработки задания. На схеме этот блок обозначен буквой M.

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

В более сложном варианте управление реализуется не напрямую, а с помощью регуляторов по скорости или по моменту. О них будет написано ниже.

Также модель должна управляться с помощью вектора моментов и вектора скоростей.

Black Board

Блекборд должен работать как сервер на сокетах. Каждый клиент может работать с двумя видами операций. Первая называется топиками (topics), вторая - сервисами (services).

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

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

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

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

REST сервер

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

План работы

Разрабатывать такой объёмный проект лучше по этапам. Каждый этап стоит формировать под конкретное рабочее приложение. Такой подход называется Agile. Подробнее о нём написано в разделе Разработка ПО.

Проект стоит разделить на два этапа: двумерное и трёхмерное моделирование механики.

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

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

Двумерная задача

Для начала нужно написать приложение, которое будет рассчитывать движение математического маятника, т.е. маятника, имеющего идеальное звено, а на его конце расположена точечная масса $m$.

Требуется реализовать не только моделирование поведения маятника в свободном движении, но также и при воздействии на его звено момента $M$. Должна быть возможность задавать этот момент как через сайт, так и через REST-клиент.

Потом следует добавить два режима управления: по положению и по скорости. Также REST-сервер должен иметь команду запроса всех значений, т.е. угла, угловой скорости, ускорения и действующего на звено суммарного момента.

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

Второе звено

В этом приложении нужно добавить второе звено маятнику

Теперь REST-сервер должен работать с векторами(массивами значений), а не просто со значениями

Также следует добавить в расчёт массу сочленения, считая его идеальной сферой, радиуса r с равномерным распределением плотности.

Произвольный маятник

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

В предыдущих этапах модели маятников были частью кода, теперь нужно написать универсальную программу для произвольного $n$-звенного маятника.

Для хранения параметров таких маятников, нужно разработать свой формат.

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

Параметризация маятника своим форматом файла, решение задачи в плоскости для n-звенного маятника с учётом коллизий.

Регуляторы

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

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

Когда управление по скорости с помощью регулятора заработает плавно, следует добавить второй контур регулирования - по положению.

Его тоже следует сделать пропорциональным, правда, ошибка по положению должна формировать задание по скорости, а уже из него при помощи уже написанного регулятора следует построить задание по моменту.

Существуют и более сложные регуляторы. Подробнее о них можно почитать здесь.

Трёхмерная задача

В трёхмерной задаче нужно продумать, как будет удобно перемещаться по ней с помощью сайта. За основу можно взять механику перемещения камеры из UnrealEngine.

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

Трёхзвенный робот

В качестве первой модели можно взять urdf-файл отсюда. Подробности смотрите в readme репозитория.

Шестизвенный робот

Во второй версии приложения следует добавить шестизвенного робота. URDF-файлов таких роботов в сети довольно много.

Здесь лежит urdf робота Kuka LWR.

Четыре робота

В этой версии приложения нужно добавить возможность размещения на сцене нескольких роботов. В моей программе для этого использовались файлы формата murdf.

Общая идея формата заключалась в том, что с помощью json для каждого робота указывался путь к urdf-модели, а также параметры позиционирования на сцене

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

Все векторы при этом будут объединением обобщённых величин каждого из роботов

Точно также должно быть устроено управление по скорости и по моменту

Что дальше

Реакция опоры

Модификации с реакцией опоры:

• робопес
• шагающий бипедальный робот

Поступательные звенья

Добавление поступательных звеньев и их обсчет