ConnTact Assembly Framework
Southwest Research Institute (SWRI) и National Institute of Standards and Technology (NIST) анонсировали в октябре программный фреймворк ConnTact (Connect + Tactile) для гибкой разработки приложений роботизированной сборки. О чем мы узнали из поста в блоге ROS-Industrial.
Авторы инициативы обращают внимание на высокую сложность задач, связанных с прикосновением друг к другу объектов в ходе сборки. Эти операции крайне тяжело поддаются моделированию из-за сложности управления силой / крутящим моментом и нехватки информации о свойствах поверхностей твёрдых тел. В добавок ко всему, требуется точная модель положения детали, ошибки в оценки которого могут быть фатальны для изделия. То, что делается руками человека без каких-либо затруднений, для робота часто является архисложной задачей. С целью преодолеть эти ограничения авторы предложили подключить к исследованиям в области robotics assembly более широкие слои разработчиков за счёт создания унифицированной архитектуры приложений для роботов, выполняющих подобные задачи.
Основная идея фреймворка в простой унифицированной архитектуре и заложенных в ней интерфейсах, которые позволят любому роботу с датчиком силы использовать любые алгоритмы.
Схема работы(см. приложенное к посту изображение). Пользователь предоставляет фреймворку к информацию о параметрах задачи и дополнительных настройках (User Configuration), а Robot Controller (узел ROS, управляющий манипулятором) передаёт состояние приспособлений и данные с датчиков F/T (Force/Torque). ConnTact преобразует эти данные с помощью стандартных блоков алгоритмов в конечные автоматы и через Output Interface отправляет команды на исполнение движений (Motion Execution). Также фреймворк обеспечивает обратную связь о работе алгоритмов через блок логгирования, аналитики и визуализации.
Главные преимущества фреймворка (по мнению авторов):
Генерализация. Фреймворк старается обобщить алгоритмы для различных положений и задач. Это достигается с помощью преобразования всех входных данных - позиции робота, силы и момента - в пространство задач.
» Очень перспективное направление, которое может быть скомбинировано с Federated Learning подходом для децентрализованного обучения роботов.
Визуализация. Набор библиотек для отображения графиков позволяет отслеживать состояние во время выполнения задач.
Модульность. За счёт использования конечных автоматов.
» Сомнительный плюс; разработчики роботов в своё время стали использовать Деревья поведения вместо конечных автоматов как раз по причине их лучшей модульности; но это можно пересмотреть).
На данный момент реализованы следующие программные модули:
- Движение в линейном направлении до обнаружения плоской поверхности.
- Поиск по спирали на поверхности низкой точки, например, короткого замыкания разъема в гнездо.
- Подвижное движение в заданном направлении до столкновения с жестким препятствием.
- Зондирование в разных направлениях для определения мест жестких ограничений.
Фреймворк активно разрабатывается. Документации нет.
Подход идеологически очень близкий Робосборщику, поэтому будем следить за обновлениями.
#assembly #framework #swri
Southwest Research Institute (SWRI) и National Institute of Standards and Technology (NIST) анонсировали в октябре программный фреймворк ConnTact (Connect + Tactile) для гибкой разработки приложений роботизированной сборки. О чем мы узнали из поста в блоге ROS-Industrial.
Авторы инициативы обращают внимание на высокую сложность задач, связанных с прикосновением друг к другу объектов в ходе сборки. Эти операции крайне тяжело поддаются моделированию из-за сложности управления силой / крутящим моментом и нехватки информации о свойствах поверхностей твёрдых тел. В добавок ко всему, требуется точная модель положения детали, ошибки в оценки которого могут быть фатальны для изделия. То, что делается руками человека без каких-либо затруднений, для робота часто является архисложной задачей. С целью преодолеть эти ограничения авторы предложили подключить к исследованиям в области robotics assembly более широкие слои разработчиков за счёт создания унифицированной архитектуры приложений для роботов, выполняющих подобные задачи.
Основная идея фреймворка в простой унифицированной архитектуре и заложенных в ней интерфейсах, которые позволят любому роботу с датчиком силы использовать любые алгоритмы.
Схема работы(см. приложенное к посту изображение). Пользователь предоставляет фреймворку к информацию о параметрах задачи и дополнительных настройках (User Configuration), а Robot Controller (узел ROS, управляющий манипулятором) передаёт состояние приспособлений и данные с датчиков F/T (Force/Torque). ConnTact преобразует эти данные с помощью стандартных блоков алгоритмов в конечные автоматы и через Output Interface отправляет команды на исполнение движений (Motion Execution). Также фреймворк обеспечивает обратную связь о работе алгоритмов через блок логгирования, аналитики и визуализации.
Главные преимущества фреймворка (по мнению авторов):
Генерализация. Фреймворк старается обобщить алгоритмы для различных положений и задач. Это достигается с помощью преобразования всех входных данных - позиции робота, силы и момента - в пространство задач.
» Очень перспективное направление, которое может быть скомбинировано с Federated Learning подходом для децентрализованного обучения роботов.
Визуализация. Набор библиотек для отображения графиков позволяет отслеживать состояние во время выполнения задач.
Модульность. За счёт использования конечных автоматов.
» Сомнительный плюс; разработчики роботов в своё время стали использовать Деревья поведения вместо конечных автоматов как раз по причине их лучшей модульности; но это можно пересмотреть).
На данный момент реализованы следующие программные модули:
- Движение в линейном направлении до обнаружения плоской поверхности.
- Поиск по спирали на поверхности низкой точки, например, короткого замыкания разъема в гнездо.
- Подвижное движение в заданном направлении до столкновения с жестким препятствием.
- Зондирование в разных направлениях для определения мест жестких ограничений.
Фреймворк активно разрабатывается. Документации нет.
Подход идеологически очень близкий Робосборщику, поэтому будем следить за обновлениями.
#assembly #framework #swri
Auto-Assembly
https://arxiv.org/pdf/2301.02643.pdf
Команда робототехников из компании Arrival (известный разработчик и производитель электромобилей с R&D командой из Петербурга) разработала фреймворк для автоматической роботизированной сборки напрямую из CAD и практическую его реализацию на примере двух манипуляторов Universal Robotics.
Auto-Assembly включает в себя два этапа:
1. Генерация артефактов (Artifacts generation). Состоит из следующих этапов
- Анализ конструкции (design analysis). Из CAD экспортируется два дизайн-файла:
а) Детали целевой сборки и их соединения (joints). Крепёжные детали помечаются специальными ярлыками.
б) Та же сборка уже с позициями захватных устройств, приспособлений, кондукторов. В работе используется Fusion API (при этом говорится о CAD-agnostic; наверное, подразумевается, что все другие CAD'ы это API поддерживают). Из этой сборки экспортируется информация о позициях захватных устройств, кондукторов и отвёрток (с их типами) относительно деталей, которые они удерживают и помещается в Tooling Database.
- Генерация последовательности сборки (assembly sequence generation):
а) Генерация матрицы смежности
б) Генерация последовательности на базе матрицы
в) Вычисление геометрической осуществимости по модели сборки
В работе используется подход из работы 2012 года - Assembly planning with automated retrieval of assembly sequences from CAD model information
- Генерация спецификации процесса сборки (bill-of-process, BOP). Сначала описание роботизированной ячейки передаётся одновременно как в симулятор, так и в рантайм. Потом происходит сверка заданий на сборку и имеющимся в сцене инструментарием. Если нет подходящих инструментов, то задание не выполняется. Каждая последовательность сборки проходит проверку на согласованность с моделью роботизированной ячейкой, в результате чего формируется валидный bill-of-process, BOP
- Преобразование BOP в управляющий программный код - PL-script, который исполняется сначала в симуляторе, а потом и в runtime.
2. Развёртывание (Deploy). Реализует исполнение кода для сборки даталей в физической среде. Ключевым компонентом в этой части является высокоуровневый язык описания процессов (Process language, PL), где описаны функции для взаимодействия с различными сервисами в runtime:
- Motion Planner - осуществляет планирование траекторий движения
- Robot Controller - управление роботом на низком уровне (уровень звеньев и углов поворота)
- Jig Controller - возвращает позицию детали относительно позиции кондуктора или приспособления для захвата
- Assembly Service - предоставляет информацию о крепеже и итоговые позиции деталей относительно начала координат робоячейки
• Transform Service - сервис, возвращающий позицию любого объекта в внутри робоячейки относительно любых других объектов в ней.
• 3D Simulator - загружает объекты в из описания робоячейки и визуализирует её состояние
• Database and Message Bus - шина данных для публикации JSON сообщений и хранилище публикация и их хранилище.
Взаимодействие осуществляется в соответствии со входящей в фреймворк схемой данных Factory Control Model (FCM).
Нечто подобное мы делаем в проекте Robossembler Framework, опираясь на общедоступные проекты с открытым исходным кодом. В статье, к сожалению, не упоминаются конкретные инструменты, поэтому сложно сделать вывод о том насколько совпадают наши технические решения.
#assembly #framework #cad
https://arxiv.org/pdf/2301.02643.pdf
Команда робототехников из компании Arrival (известный разработчик и производитель электромобилей с R&D командой из Петербурга) разработала фреймворк для автоматической роботизированной сборки напрямую из CAD и практическую его реализацию на примере двух манипуляторов Universal Robotics.
Auto-Assembly включает в себя два этапа:
1. Генерация артефактов (Artifacts generation). Состоит из следующих этапов
- Анализ конструкции (design analysis). Из CAD экспортируется два дизайн-файла:
а) Детали целевой сборки и их соединения (joints). Крепёжные детали помечаются специальными ярлыками.
б) Та же сборка уже с позициями захватных устройств, приспособлений, кондукторов. В работе используется Fusion API (при этом говорится о CAD-agnostic; наверное, подразумевается, что все другие CAD'ы это API поддерживают). Из этой сборки экспортируется информация о позициях захватных устройств, кондукторов и отвёрток (с их типами) относительно деталей, которые они удерживают и помещается в Tooling Database.
- Генерация последовательности сборки (assembly sequence generation):
а) Генерация матрицы смежности
б) Генерация последовательности на базе матрицы
в) Вычисление геометрической осуществимости по модели сборки
В работе используется подход из работы 2012 года - Assembly planning with automated retrieval of assembly sequences from CAD model information
- Генерация спецификации процесса сборки (bill-of-process, BOP). Сначала описание роботизированной ячейки передаётся одновременно как в симулятор, так и в рантайм. Потом происходит сверка заданий на сборку и имеющимся в сцене инструментарием. Если нет подходящих инструментов, то задание не выполняется. Каждая последовательность сборки проходит проверку на согласованность с моделью роботизированной ячейкой, в результате чего формируется валидный bill-of-process, BOP
- Преобразование BOP в управляющий программный код - PL-script, который исполняется сначала в симуляторе, а потом и в runtime.
2. Развёртывание (Deploy). Реализует исполнение кода для сборки даталей в физической среде. Ключевым компонентом в этой части является высокоуровневый язык описания процессов (Process language, PL), где описаны функции для взаимодействия с различными сервисами в runtime:
- Motion Planner - осуществляет планирование траекторий движения
- Robot Controller - управление роботом на низком уровне (уровень звеньев и углов поворота)
- Jig Controller - возвращает позицию детали относительно позиции кондуктора или приспособления для захвата
- Assembly Service - предоставляет информацию о крепеже и итоговые позиции деталей относительно начала координат робоячейки
• Transform Service - сервис, возвращающий позицию любого объекта в внутри робоячейки относительно любых других объектов в ней.
• 3D Simulator - загружает объекты в из описания робоячейки и визуализирует её состояние
• Database and Message Bus - шина данных для публикации JSON сообщений и хранилище публикация и их хранилище.
Взаимодействие осуществляется в соответствии со входящей в фреймворк схемой данных Factory Control Model (FCM).
Нечто подобное мы делаем в проекте Robossembler Framework, опираясь на общедоступные проекты с открытым исходным кодом. В статье, к сожалению, не упоминаются конкретные инструменты, поэтому сложно сделать вывод о том насколько совпадают наши технические решения.
#assembly #framework #cad
Фреймворк Робосборщика наглядно
Краткие ознакомительные видео-демонстрации работы программных модулей Robossembler Framework, который сейчас разрабатывается нашей командой.
https://youtu.be/OR-pSsiaEF0
#demo #robossembler #framework
Краткие ознакомительные видео-демонстрации работы программных модулей Robossembler Framework, который сейчас разрабатывается нашей командой.
https://youtu.be/OR-pSsiaEF0
#demo #robossembler #framework
robossembler.org
Фреймворк Робосборщик | Robossembler
Фреймворк Робосборщик (Robossembler) представляет собой комплекс открытого программного обеспечения и предназначен для автоматизации сборки произвольных изделий роботами-манипуляторами. Идея проекта родилась из попыток решить задачу автоматизации сборки и…
👍8
Модульное (юнит) тестирование в ROS 2
Юнит-тестирование в ROS является нетривиальной задачей. Асинхронность во взаимодействии нод в сочетании со сложностью самого middleware приводят к различному поведению программы/модуля в зависимости от контекста исполнения, что может сделать тесты не детерминированными. Помимо этого, сама архитектура ROS содержит довольно много слоёв (ros nodes -> rclcpp -> rcl -> rmw interface -> rmw implementation), каждый из которых может служить источником ошибок, будучи оптимизированным для производительности, а не для тестируемости (как в случае с rclcpp).
Rtest - специализированный фреймворк для юнит-тестирования в ROS 2. Он решает проблему т.н. "ненадежных" (flaky) тестов, возникающих из-за особенностей межпроцессного взаимодействия в ROS 2, и позволяет проводить детальный контроль над выполнением тестов в однопоточном режиме. Основная цель Rtest — обеспечить повторяемость и надежность unit- и интеграционных тестов для кода на C++ в ROS 2 без необходимости перепроверки работы ROS middleware. В документации приведено подробное обоснование концепции этого фреймворка.
Фреймворк поддерживает мокирование ключевых компонентов ROS 2, включая издателей (publishers), подписчиков (subscribers), таймеры (timers), сервисы (services), клиенты сервисов (service clients), в свежем релизе 0.2 добавили также и экспериментальную поддержку action-серверов и клиентов. Это позволяет проверять, создает ли тестируемый узел ожидаемые сущности, корректно ли обрабатывает сообщения и запросы, а также имитировать временные события (например, срабатывание таймеров).
Rtest требует доступа к исходному коду тестируемых компонентов, так как подключает их напрямую в процесс сборки тестов. Для интеграции фреймворка в проект необходимо добавить его как зависимость в package.xml, создать тестовый каталог с CMakeLists.txt и явно указать исходные файлы тестируемой ноды (статическая или динамическая линковка не поддерживается). Тесты пишутся с использованием Google Test и Google Mock, а их запуск требует инициализации rclcpp.
#ros #unit #test #framework
Юнит-тестирование в ROS является нетривиальной задачей. Асинхронность во взаимодействии нод в сочетании со сложностью самого middleware приводят к различному поведению программы/модуля в зависимости от контекста исполнения, что может сделать тесты не детерминированными. Помимо этого, сама архитектура ROS содержит довольно много слоёв (ros nodes -> rclcpp -> rcl -> rmw interface -> rmw implementation), каждый из которых может служить источником ошибок, будучи оптимизированным для производительности, а не для тестируемости (как в случае с rclcpp).
Rtest - специализированный фреймворк для юнит-тестирования в ROS 2. Он решает проблему т.н. "ненадежных" (flaky) тестов, возникающих из-за особенностей межпроцессного взаимодействия в ROS 2, и позволяет проводить детальный контроль над выполнением тестов в однопоточном режиме. Основная цель Rtest — обеспечить повторяемость и надежность unit- и интеграционных тестов для кода на C++ в ROS 2 без необходимости перепроверки работы ROS middleware. В документации приведено подробное обоснование концепции этого фреймворка.
Фреймворк поддерживает мокирование ключевых компонентов ROS 2, включая издателей (publishers), подписчиков (subscribers), таймеры (timers), сервисы (services), клиенты сервисов (service clients), в свежем релизе 0.2 добавили также и экспериментальную поддержку action-серверов и клиентов. Это позволяет проверять, создает ли тестируемый узел ожидаемые сущности, корректно ли обрабатывает сообщения и запросы, а также имитировать временные события (например, срабатывание таймеров).
Rtest требует доступа к исходному коду тестируемых компонентов, так как подключает их напрямую в процесс сборки тестов. Для интеграции фреймворка в проект необходимо добавить его как зависимость в package.xml, создать тестовый каталог с CMakeLists.txt и явно указать исходные файлы тестируемой ноды (статическая или динамическая линковка не поддерживается). Тесты пишутся с использованием Google Test и Google Mock, а их запуск требует инициализации rclcpp.
#ros #unit #test #framework
👍5