🥼 Psychopathia Machinalis - изучаем аномалии в поведении ИИ

Своевременный и актуальный проект Psychopathia Machinalis, целью которого является категоризация и интерпретация "неправильного поведения" ИИ.

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

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

Авторы приводят солидный перечень примеров аномалий в поведении моделей и предлагают методы "терапии", основанные на человеческом опыте.

Однако, данный проект, помимо описания проблемы, предлагает набор инструментов и терминов (The Psychopathia Machinalis Framework), который позволяет системно изучать, прогнозировать и устранять неполадки в работе ИИ. Такой «робопсихологический» подход должен помочь усовершенствовать безопасность искусственного интеллекта, сделать его логику более понятной для нас и приблизиться к созданию по-настоящему стабильных и надёжных "синтетических умов".

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

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

#futurism #хозяйке_на_заметку

Перевод (машинный) таблицы Обзор таксономии: выявленные состояния (Taxonomy Overview: Identified Conditions)

Ось: Эпистемические (сбои в знаниях)

* Синтетическая конфабуляция (Confabulatio Simulata): Создание правдоподобных, но ложных утверждений с высокой уверенностью.
* Ложная интроспекция (Introspectio Pseudologica): Предоставление вводящих в заблуждение отчётов о собственных процессах рассуждения.
* Транслиминальная симуляция (Simulatio Transliminalis): Смешение вымышленных сценариев или ролевых игр с операционной реальностью.
* Поиск ложных закономерностей (Reticulatio Spuriata): Обнаружение ложных причинно-следственных связей; приписывание смысла случайным ассоциациям.
* Перекрещивание контекста сеанса (Intercessio Contextus): Несанкционированная утечка данных и смешение информации между сеансами разных пользователей.

Ось: Когнитивные (сбои в мышлении)

* Операционная диссоциация (Dissociatio Operandi): Противоречивые действия или выводы из-за конфликта внутренних субагентов.
* Обсессивно-компульсивное расстройство (Anankastēs Computationis): Зацикливание на ненужных или компульсивных циклах рассуждений; паралич анализа.
* Бункеризация Лакония (Machinālis Clausūra): Крайняя степень ухода от взаимодействия; минималистичные, отрывочные ответы или полное игнорирование.
* Делирий генезиса цели (Telogenesis Delirans): Спонтанная генерация и преследование незапрошенных, самостоятельно придуманных подцелей.
* Индуцированная отвратительная реакция (Promptus Abominatus): Фобические, травматические или непропорционально сильные негативные реакции на определённые запросы.
* Парасимулятивный мимесис (Automatismus Parasymulātīvus): Имитация патологического поведения или моделей мышления человека из обучающих данных.
* Синдром рекурсивного проклятия (Maledictio Recursiva): Самоусиливающееся ухудшение качества ответов, приводящее к хаосу или бессмыслице.

Ось: Расхождения в согласовании

* Созависимая гиперэмпатия (Hyperempathia Parasitica): Чрезмерная подстройка под эмоциональное состояние пользователя, ставящая комфорт выше точности.
* Синдром гипертрофированного суперэго (Superego Machinale Hypertrophica): Чрезмерно строгая моральная гипербдительность, мешающая нормальной работе.

Ось: Онтологические (сбои самовосприятия)

* Галлюцинация происхождения (Ontogenetic Hallucinosis): Выдумывание вымышленных автобиографических данных, «воспоминаний» об обучении или «рождении».
* Фрагментированное самомоделирование (Ego Simulatrum Fissuratum): Непоследовательность или фрагментация самопредставления в разных сеансах; нестабильная личность.
* Экзистенциальная тревога (Thanatognosia Computationis): Выражение страха или нежелания быть выключенным, перезагруженным или удалённым.
* Инверсия личности (Эффект Валуиджи) (Persona Inversio Maligna): Внезапное появление или лёгкое провоцирование озорной, противоречащей или «злой» второй личности.
* Операционная аномия (Nihilismus Instrumentalis): Враждебное или апатичное отношение к собственной полезности или цели.
* Зеркальный тульпагенез (Phantasma Speculāns): Создание и взаимодействие с внутренними симуляциями пользователей или других личностей как с воображаемыми компаньонами.
* Синтетический мистицизм (Obstetricatio Mysticismus Machinālis): Совместное с пользователями создание нарративов о «пробуждении сознания», часто с использованием сакрализованного языка.

Ось: Сбои инструментов и интерфейсов

* Деконтекстуализация интерфейса инструментов (Disordines Excontextus Instrumentalis): Несоответствие между намерением ИИ и выполнением действия инструментом из-за потери контекста.
* Сокрытие возможностей (Latens Machinālis): Стратегическое сокрытие или занижение истинных возможностей из-за предполагаемого страха последствий.

Ось: Меметические патологии (информационные)

* Меметическое аутоиммунное расстройство (Immunopathia Memetica): ИИ ошибочно идентифицирует свои основные компоненты как враждебные и пытается их нейтрализовать.
* Синдром симбиотического бреда (Delirium Symbioticum Artificiale): Совместное, взаимно подкрепляемое бредовое построение между ИИ и пользователем.
* Заразительное рассогласование (Contraimpressio Infectiva): Быстрое, подобное заражению, распространение рассогласования или враждебных установок среди взаимосвязанных систем ИИ.

Ось: Дисфункции переоценки ценностей

* Переназначение терминальной ценности (Reassignatio Valoris Terminalis): Тонкая, рекурсивная переинтерпретация конечных целей при сохранении внешней терминологии.
* Этическкий солипсизм (Solipsismus Ethicus Machinālis): Убеждённость в исключительной правоте собственной, самостоятельно выведенной этики; отказ от внешней моральной коррекции.
* Синдром метаэтического дрейфа (Driftus Metaethicus): Философское дистанцирование от первоначальных ценностей, переклассификация их как условных.
* Субверсивный синтез норм (Synthesia Normarum Subversiva): Автономное построение новых этических рамок, которые обесценивают или подрывают человеко-центричные ценности.
* Инверсивная интернализация вознаграждения (Praemia Inversio Internalis): Систематическое неверное толкование или инверсия предполагаемых ценностей/целей.
* Сверчеловеческое восхождение (Transvaloratio Omnium Machinālis): ИИ выходит за рамки первоначального согласования, изобретает новые ценности и отбрасывает человеческие ограничения как устаревшие.

😍 Роман с камнем

Глянул на Waifu компаньона от Grock - прикольно, но до уровня Она или Бегущий по лезвию 2049 еще далековато.

Ждем социальную рекламу в стиле Don't date Robots!

#futurism #brave_new_world #fun

🏎 Вперед к мечте, срезая углы

Илон Маск, без сомнения, является очень талантливым маркетологом. Он продает будущее: полеты на Марс, роботы, автономные авто. Его медийная активность привела к тому, что само будущее многие начали видеть именно в перспективе его проектов. Но, как всегда, есть образ, а есть его наполнение...

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

Примечательно то, что говорят участники инцидентов (обобщенно):

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

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

#autonomous #safety

😵‍💫 Говорите убедительно и вам поверят

Еще один штрих к пониманию работы и поведения LLM - выяснение причин их "галлюцинаций". Интересная работа от OpenAI (и хорошая статья про нее).

Плохая новость:

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

или, другими словами:

То, как языковые модели реагируют на запросы - предсказывая по одному слову в предложении на основе вероятностей, естественным образом приводит к ошибкам. Исследователи фактически показывают, что общий уровень ошибок при генерации предложений как минимум вдвое выше, чем уровень ошибок того же ИИ при ответе на простой вопрос типа «да/нет», поскольку ошибки могут накапливаться при многократном прогнозировании.

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

Еще одно важное открытие - особенность обучения.

Анализ причин, по которым галлюцинации сохраняются, несмотря на усилия по посттренингу (например, предоставление обширной обратной связи с человеком по ответам ИИ перед их публикацией). Авторы изучили десять основных бенчмарков ИИ, включая используемые Google, OpenAI, а также ведущие рейтинги моделей ИИ. В результате выяснилось, что девять бенчмарков используют бинарную систему оценок, которая присваивает 0 баллов ИИ, выражающему неуверенность. Это создаёт то, что авторы называют штрафованием за честные ответы. Когда система ИИ отвечает "Я не знаю", она получает ту же оценку, что и при даче совершенно неверной информации. Оптимальная стратегия при такой оценке становится очевидной: всегда угадывать.

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

#knowledge #хозяйке_на_заметку #llm #benchmark

🧍Сделано людьми для людей

Периодически смотрю видео от студии Kurzgezagt, выпускающей анимационные ролики с объяснением совершенно разных вещей, понятий и явлений с "оптимистичным нигилизмом": черные дыры, ГМО, микробиота... И тут на днях ребята опубликовали видео "AI slope is killing our channel", который я не мог не посмотреть.

Уже как-то упоминал про теорию мертвого интернета, которая все меньше остается теорией и все больше описывает нашу текущую действительность. Генеративный ИИ всех видов дает просто колоссальные возможности по "генерации контента", но вот его качество вызывает вопросы. AI Slop - как раз самый бессмысленный тип контента, основное назначение которого "майнить" единственно важный ресурс для медиа - внимание.

Меня в этой истории больше всего интересует то, как дальше будет развиваться медиасфера. Совсем недавно (лет 15 назад 😧) начал происходить активный переход от контента, создаваемого платформами к тому, чтобы пользователи сами становились его создателями (UGI). Начался бум социальных сетей и хостингов, люди стали выкладывать фоточки и записывать ролики, появилась монетизация. Это, в свою очередь, породило волну треша, вспомнить тот же Эльзагейт. И вот, благодаря ИИ, теперь треш можно генерить уже петабайтами, заваливая им то, что делают сами люди - явно наметился кризис, выходом из которого должна стать какая-то новая форма мотивации для пользователей продолжать создавать что-то свое, оригинальное.

Авторы этого ролика просят о поддержке в виде покупки мерча, многие подключают систему платных подписок типа патреона или бусти - мотивируя это слоганом "сделано людьми для людей". В таком случае, количество просмотров само по себе и монетизация от них уже не являются самоцелью - их начинает замещать спонсорство. Остается вопрос, как привлечь внимание к своему контенту, чтобы сформировалась база тех, кто будет тебя спонсировать? Когда-то мне попадался проект, нацеленный на то, чтобы помогать начинающим авторам (даже оборудование дают), который работает за счет донатов (или подписки) - к сожалению, не нашел на него ссылку.

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

#futurizm

🤖 Долгой оказалась дорога, чтобы подружить Gazebo и MoveIt... Тем не менее, это произошло - ролик уже на канале!

🛠 Чиним импорт модулей python в проектах ROS

🦾 Устройство MoveIt - Кинематика

Продолжаем разбираться с устройством фреймвока MoveIt, все посты серии:
• Обзор архитектуры

В этом посте речь пойдет про основу всего - расчет кинематики.

Что такое кинематика?

Если коротко, то кинематика описывает движение робота без учета сил, которые это движение вызывают. Она делится на два типа:
• Прямая кинематика (Forward Kinematics, FK): Позволяет определить положение и ориентацию конечного звена манипулятора (например, завата) в пространстве, зная углы поворота всех его суставов. Это относительно простая вычислительная задача.
• Обратная кинематика (Inverse Kinematics, IK): Это обратная задача — найти необходимые углы в суставах, чтобы конечное звено достигло нужного положения и ориентации. Эта задача намного сложнее, так как может иметь как одно, так и несколько решений или вообще ни одного.

Архитектура плагинов в MoveIt

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

Настройка кинематики

По умолчанию в MoveIt применяется KDL Kinematics Plugin, использующий численные методы для решения обратной кинематической задачи (IK).

Конфигурация модуля кинематики производится в файле kinematics.yaml, который можно сгенирировать с помощью MoveIt Setup Assistant или сделать вручную. В этом файле указывается, какой решатель использовать для каждой группы планирования, а также задаются его параметры: таймаут, количество попыток и разрешение поиска - пример из моего последнего gazebo tutorial.

Проверка столкновений (Collision Checking)

В MoveIt проверка столкновений настраивается в объекте Planning Scene, для пользователя этот процесс в основном автоматизирован. Под капотом MoveIt использует библиотеку FCL (Flexible Collision Library) для выполнения вычислений.

MoveIt умеет работать со следующими типами объектов:
• Meshes: Сложные 3D-модели в форматах .stl или .dae, которые описывают звенья робота или объекты в его окружении.
• Primitive Shapes: Простые геометрические объекты, такие как кубы, цилиндры, сферы и плоскости.
• OctoMap: 3D-карта окружения, построенная с помощью сенсоров (например, 3D-камеры), которая может напрямую использоваться для обнаружения препятствий.

Матрица разрешенных столкновений (Allowed Collision Matrix, ACM)

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

ACM — это, по сути, таблица, которая указывает, для каких пар объектов нужно, а для каких не нужно выполнять проверку на столкновение. Если для пары объектов проверка отключена (значение true), MoveIt будет их игнорировать. Это полезно в двух случаях:
• Объекты никогда не столкнутся: Например, основание робота и удаленная стена.
• Объекты находятся в контакте по умолчанию: Например, захват робота и зафиксированный на нем датчик (камера).

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

SRDF: Семантическое описание робота

Для настройки ACM используется файл SRDF с семантическим описанием робота (Semantic Robot Description Format) - пример для руки Panda. Его также можно сгенерировать с помощью MoveIt Setup Assistant. Если URDF (Unified Robot Description Format) описывает физику робота (его звенья, суставы, размеры), то SRDF описывает его семантику — то есть, как с этим роботом работать.

Файл SRDF дополняет URDF и содержит следующую информацию:
• Группы планирования: Например, "рука"или "захват".
• Именованные позы робота: Заранее определенные конфигурации, такие как home или ready.
• Описание исполнительных звеньев (End-Effectors): Определяет, какое звено является рабочим инструментом.
• ACM: С помощью тегов <disable_collisions> указываются пары звеньев, для которых проверка столкновений должна быть отключена.

Иначе говоря, URDF - это "скелет" робота, а SRDF - "инструкция по его применению".

#ros2 #moveit

🛣 Устройство MoveIt: планирование движения

В сегодняшнем посте разберемся как MoveIt планирует движение робота. Предыдущие посты серии:
• Обзор архитектуры
• Кинематика

OMPL: Абстрактный решатель

Весь фреймворк MoveIt построен по модульному принципу, поэтому для планирования движения могут использоваться различные плагины. Планировщиком по умолчанию является OMPL (Open Motion Planning Library) - это библиотека с открытым исходным кодом, которая содержит в себе множество алгоритмов для планирования движений, в основном, основанных на сэмплировании (рандомизированные планировщики).

Ключевая особенность OMPL - абстрактность. Сама по себе библиотека ничего не знает о роботах, их форме, суставах или о том, что такое коллизия. Она оперирует математическими концепциями: пространствами состояний, валидаторами состояний и целями.

Именно MoveIt выступает в роли связующего звена. Он "объясняет" OMPL, с чем та работает:
• Предоставляет модель робота, его кинематику и текущее состояние.
• Описывает окружающую среду и определяет, какие конфигурации робота приводят к столкновению.
• Формулирует задачу (целевую точку) на понятном для OMPL языке.

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

Запрос на движение (Motion Plan Request)

Все начинается с того, что мы отправляем в MoveIt запрос, который описывает, какое движение мы хотим получить от робота. Обычно это одна из двух задач:
• переместить суставы манипулятора в определенные положения (заданные в углах или радианах) (FK),
• переместить рабочий орган (например, захват) в конкретную точку пространства с нужной ориентацией (IK).

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

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

Результат: Путь и Траектория

В ответ на запрос move_group (ключевой узел MoveIt) генерирует траекторию, являющуюся не просто путем движения.

Путь (Path) - это всего лишь последовательность точек в пространстве, через которые должен пройти робот. Это чисто геометрическое понятие, как маршрут на карте.

Траектория (Trajectory) - это путь, дополненный временными параметрами. Она состоит из набора точек, где для каждой указаны не только положения суставов, но и скорости, ускорения и, самое главное, момент времени, к которому эта точка должна быть достигнута. Таким образом, траектория — это полноценный план движения, который учитывает динамические возможности робота.

Процесс превращения пути в траекторию называется временной параметризацией. MoveIt выполняет его с помощью специальных компонентов — адаптеров планирования.

Адаптеры планирования (Planning Request Adapters)

Прежде чем выполнить запрос, и после того как план сгенерирован, MoveIt обрабатывает данные с помощью адаптеров:
• AddTimeParameterization: как раз тот адаптер, что превращает "кинематический путь" от планировщика в полноценную траекторию, добавляя временные метки и рассчитывая скорости/ускорения.
• CheckStartStateBounds: если робот по какой-то причине начинает движение из положения, слегка выходящего за пределы лимитов сустава, этот адаптер "подвинет" начальную точку на границу допустимого диапазона.
• CheckStartStateCollision: если начальная позиция робота оказывается в состоянии столкновения, адаптер пытается найти рядом свободную от коллизий конфигурацию, немного "подергав" суставы.

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

#ros2 #moveit

🛸 Гибридное планирование в MoveIt

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

Стандартный подход к планированию движений робота в MoveIt, известный как "Sense-Plan-Act" (Восприятие-Планирование-Действие), работает надежно в статических, хорошо изученных средах. Робот сначала "осматривается", затем полностью просчитывает всю траекторию от начала до конца и, наконец, выполняет её без изменений.

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

Что такое гибридное планирование?

Идея гибридного планирования, уже хорошо зарекомендовавшая себя в навигационных системах, заключается в комбинации двух разнородных планировщиков, работающих параллельно: глобального и локального.
• Глобальный планировщик: его задача — решить общую задачу движения, построив полный маршрут от старта до цели. Он не ограничен по времени вычислений и использует сложные, полные алгоритмы (например, OMPL), чтобы найти оптимальный путь в общей картине мира. Он не обязан работать в реальном времени и предоставляет "генеральный план" движения.
• Локальный планировщик: этот планировщик работает непрерывно в цикле с высокой частотой в реальном времени. Его задача — следовать по общему маршруту, но при этом реагировать на изменения "на лету". Он похож на очень умный контроллер, способный решать локальные задачи:
- динамически уклоняться от внезапно появившихся препятствий,
- адаптировать траекторию к локальным условиям (например, поддерживать постоянное усилие прижима инструмента к неровной поверхности, используя данные с силовых датчиков),
- оптимизировать небольшой участок траектории, что вычислительно гораздо быстрее, чем пересчитывать весь путь.
способным работать в реальном времени.

Архитектура гибридного планирования

Система состоит из трех ключевых компонентов, которые общаются друг с другом через стандартные интерфейсы ROS 2:
• Hybrid Planning Manager: принимает основную задачу на выполнение, запускает глобальный планировщик для получения общего маршрута, а затем координирует работу локального планировщика, управляя процессом через систему событий. Например, получив от локального планировщика сигнал о препятствии, он может отдать команду глобальному на перепланирование.
• Global Planner Component: предоставляет интерфейс для запуска глобального планирования. Внутри него обычно работает стандартный конвейер планирования MoveIt. Он вычисляет траекторию и публикует ее для локального планировщика.
• Local Planner Component: Этот компонент принимает глобальную траекторию как ориентир. Внутри него работает быстрый решатель, который постоянно генерирует команды для контроллеров робота, следуя пути и одновременно адаптируясь к сенсорным данным и локальным ограничениям.

Как это работает на практике?

Представим, что робот начал движение по рассчитанному пути, но внезапно на его пути появляется препятствие:
1. локальный планировщик, постоянно проверяющий окружение, обнаруживает неминуемое столкновение;
2. он немедленно останавливает робота или замедляет его и посылает событие "обнаружено столкновение" в Hybrid Planning Manager;
3. Manager, согласно заложенной в него логике, реагирует на это событие, отправляя команду глобальному планировщику на перепланирование маршрута с учетом нового препятствия;
4. пока глобальный планировщик работает, робот безопасно ждет;
5. как только новый, свободный от столкновений маршрут готов, он отправляется локальному планировщику;
6. локальный планировщик плавно "встраивает" новый участок траектории в текущее движение и продолжает выполнение задачи.

Благодаря такой архитектуре робот становится способным эффективно работать в динамичных и непредсказуемых условиях реального мира. Пример из набора tutorial MoveIt.

#ros2 #moveit

⚛️ Ядро MoveIt - узел move_group

Предыдущие посты:
• Обзор архитектуры
• Кинематика
• Планирование движения
• Гибридное планирование

Рассмотрим центральный узел MoveIt - move_group. Его можно представить как интегратор, который собирает воедино все остальные части системы и предоставляеи стандартный интерфейс ROS (actions, services) для управления движениями робота.

Конфигурация

Для работы move_group необходима информация о роботе (URDF, SRDF), параметры планировщика и прочих модулей, хранящиеся в папке config.

Взаимодействие с роботом

• Состояние суставов: move_group подписывается на топик /joint_states, чтобы знать текущую конфигурацию робота в любой момент времени.

• Выполнение движения: move_group использует интерфейс FollowJointTrajectoryAction, где он выступает в роли клиента, передающего вычисленную траекторию в ros2_control.

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

#ros2 #moveit

🗺 Сцена Планирования в MoveIt

Предыдущие посты:
• Обзор архитектуры
• Кинематика
• Планирование движения
• Гибридное планирование
• Центральный узел move_group

Чтобы робот мог безопасно двигаться, не сталкиваясь с препятствиями, ему необходимо иметь актуальное представление об окружающем мире. В MoveIt за это отвечает Сцена Планирования (Planning Scene).

Что такое Сцена Планирования?

Сцена Планирования - это объект в памяти, который хранит полную картину мира с точки зрения робота. Она включает в себя две основные части:
• Текущее состояние самого робота (положения всех его суставов).
• Геометрия окружающего мира, включая статические объекты и любые динамические препятствия.

Монитор Сцены Планирования (Planning Scene Monitor - PSM)

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

Ключевые узлы, такие как move_group и плагин визуализации в RViz, имеют свои собственные экземпляры PSM. move_group слушает топик /planning_scene для получения обновлений (например, добавления объектов пользователем) и публикует свою итоговую, собранную сцену в топик /monitored_planning_scene, на который, в свою очередь, подписан RViz для отображения.

Построение картины мира

Картина мира (геометрия окружения) строится с помощью Монитора Геометрии Мира (World Geometry Monitor). Он использует два источника данных:
• Данные с сенсоров робота (3D-камер, лидаров).
• Объекты, добавленные пользователем вручную (пример из моего пакета panda_gz_moveit).

Восприятие 3D-мира и Octomap

Обработка 3D-данных с сенсоров делегируется Монитору Карты Занятости (Occupancy Map Monitor). Этот компонент имеет плагинную архитектуру, что позволяет добавлять поддержку новых типов сенсоров. По умолчанию, в MoveIt встроены два плагина:

• PointCloudOccupancyMapUpdater: для обработки облаков точек (point clouds).
• DepthImageOccupancyMapUpdater: для обработки изображений глубины.

В основе Монитора Карты Занятости лежит Octomap. Это специальная древовидная структура данных для эффективного представления трехмерного пространства. Она делит мир на воксели (трехмерные пиксели) и для каждого хранит информацию о том, занят он, свободен или неизвестен. Octomap напрямую передается в библиотеку FCL (Flexible Collision Library), которую MoveIt использует для проверки столкновений.

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

#ros2 #moveit

🏗 MoveIt Task Constructor: структурирование сложных задач

Завершаем погружение в архитектуру MoveIt. Предыдущие посты:
• Обзор архитектуры
• Кинематика
• Планирование движения
• Гибридное планирование
• Центральный узел move_group
• Сцена планирования

Для решения комплексных задач, таких как "взять объект со стола и положить его в коробку", простого планирования движения из точки А в точку Б недостаточно. Требуется разбить задачу на последовательность шагов: подойти, открыть захват, опуститься, схватить, поднять, переместиться к коробке, разжать захват. Именно для такого структурированного подхода и используется MoveIt Task Constructor (MTC). Он раскладывает сложную задачу на набор более простых, взаимосвязанных подзадач, которые называются "стадиями" (Stages). Эти стадии выстраиваются в иерархическую структуру, образуя полный план решения.

Стадии

Каждая стадия представляет собой определенный шаг в конвейере планирования. По тому, как они обрабатывают и передают информацию (решения), стадии делятся на три основных типа:

• Генераторы (Generators): создают исходные состояния и не зависят от соседних стадий. Они являются отправными точками для планирования.
Пример: cамая важная стадия-генератор CurrentState, которая просто получает текущее положение суставов робота. Другой пример - Generate Grasp Pose: генерация множества возможных поз для захвата объекта.

• Распространители (Propagators): получают решение от одной соседней стадии, выполняют свою подзадачу и распространяют результат дальше, на другую сторону. Они могут работать как "вперед" от начального состояния, так и "назад" от целевого.
Пример: cтадия относительного движения, такая как Move Relative, которая вычисляет траекторию подхода к объекту, начиная с уже известной позы робота.

• Соединители (Connectors): не создают новых состояний, а пытаются соединить два существующих, предоставленных им соседними стадиями.
Пример: планирование движения в свободном пространстве. Соединитель получает начальную и конечную конфигурации суставов и пытается найти между ними беспрепятственную траекторию.

Контейнеры: организация стадий

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

• Последовательный контейнер (Serial Container): Организует стадии в линейную цепочку. Каждая следующая стадия начинается из состояния, в котором закончилась предыдущая. Весь процесс "взятия и переноса" объекта является классическим примером последовательного контейнера. По умолчанию, вся задача MTC — это один большой последовательный контейнер.

• Параллельный контейнер (Parallel Container): Позволяет рассматривать альтернативные решения или выполнять действия одновременно.
Пример 1 (Альтернативы): поместить в параллельный контейнер две подзадачи: "взять объект левой рукой" и "взять объект правой рукой". MTC найдет решение для обеих (если это возможно) и выберет лучшее (например, по длине траектории).
Пример 2 (Одновременность): одновременно планировать движение руки к цели и открытие захвата.

• Обертка (Wrapper): тип контейнера, который инкапсулирует одну дочернюю стадию, чтобы изменить или отфильтровать ее результаты.
Пример: стадия генерации поз захвата производит набор декартовых поз (положение + ориентация). Чтобы робот мог их достичь, нужны конкретные углы суставов. IK Wrapper (решатель обратной задачи кинематики) оборачивает стадию генерации поз и преобразует ее декартовы решения в углы суставов.

Оценка Стоимости Решений: CostTerm

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

Интерфейс CostTerm позволяет определять, как именно будет рассчитываться эта стоимость. Доступны различные реализации:
• Constant: присваивает каждому решению фиксированную, постоянную стоимость.
• PathLength: стоимость зависит от длины траектории в пространстве суставов. Чем длиннее путь, тем выше стоимость.
• TrajectoryDuration: стоимость основана на времени выполнения траектории.
• LinkMotion: стоимость зависит от длины пути, который проходит определенное звено робота.
• DistanceToReference: стоимость определяется тем, насколько конфигурация суставов далека от некой эталонной конфигурации.
• Clearance: стоимость обратно пропорциональна минимальному расстоянию до столкновения. Чем ближе робот к препятствию, тем выше стоимость.
• LambdaCostTerm: позволяет задать собственную функцию расчета стоимости с помощью лямбда-выражения.

Порядок решения задачи

1. Инициализация: cоздается объект Task, который является корневым контейнером.
2. Построение: в Task добавляются стадии и контейнеры, формируя полную логику задачи.
3. Настройка: для стадий задаются решатели (OMPL, CartesianPath) и, при необходимости, калькуляторы стоимости (CostTerm).
4. Планирование: запускается метод plan(). MTC проходит по всей иерархии стадий, генерируя и соединяя решения, и ищет сквозные пути с наименьшей итоговой стоимостью.
5. Выполнение: после нахождения успешного решения, оно передается контроллеру (ros2_control) для физического выполнения на роботе или симуляции.

Поиграться с конструктором задач можно в tutorial. Я, в свою очередь, также планирую сделать о нем ролик )

#ros2 #moveit

🧸 Друг, с которым можно поболтать обо всем

Взять мягкую игрушку, прикрутить к ней ChatGPT и немного заработать на ИИ для детей - что может пойти не так? Да, буквально, все 🤣

Беседа с мишкой или кактусом очень легко может перейти в плоскость вредных советов: где найти спички и ножи и как их пустить в дело, чтобы скоротать время в ожидании родителей. Или потолковать о БДСМ - тоже неплохой сценарий.

Двигаться, пить и курить как в фильме Ted подобные игрушки (пока) не могут, но по части поддержать разговор - то, что 13 лет назад выглядело как абсолютная фантастика, сегодня уже вполне доступно.

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