​​Yet Another State MachINe

Помимо новомодных Деревьев поведения, о которых я уже много раз тут писал, есть и более классические методы программирования отказоустойчивых автоматизированных систем - например, FSM или конечные автоматы. В отличие от деревьев поведения, над теоретической базой которых работает штучное количество учёных в мире, конечные автоматы имеют гораздо более серьёзную теоретическую базу и изучаются с середины 20 века. В том числе и в России - см. научную школу автоматного программирования Анатолия Абрамовича Шалыто в ИТМО, где ведутся исследования по части формальной верификации автоматных программ или по их генерации с помощью генетических алгоритмов.

В мире ROS долгое время была популярна библиотека SMACC, но появляются и относительно новые проекты. Среди них YASMIN - проект, ориентированный на реализацию поведения роботов с использованием конечных автоматов.

Особенности

- Интеграция с ROS 2 для упрощения развертывания и взаимодействия
- Поддержка Python и C++
- Предназначена для разработки прототипов, позволяющих быстро изменять поведение конечного автомата.
- Включает предопределенные состояния для взаимодействия с ROS 2 - action-клиентами, сервис-клиентами и топиками
- Использует blackboards для обмена данными между состояниями и конечными автоматами
- Управление состоянием: поддерживает отмену и остановку автоматов состояний, включая остановку текущего состояния выполнения
- Встроенный веб-просмотрщик (YASMIN Viewer) для мониторинга выполнения автоматов состояний в режиме реального времени.

В научной работе авторов приводится пример применения иерархических конечных автоматов (т.е. с вложенными друг в друга состояниями) в рамках архитектуры программного фреймворка MERLIN2 совместно с планировщиками PDDL и ROS 2 нодами.

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

#fsm #ros #library

В полку DIY-намотчиков прибывает!

Автор 𝚢𝚞𝚌𝚑𝚒 на одноимённом youtube-канале выкладывает демонстрации своих результатов в области разработки контроллеров BLDC и намоточного оборудования.

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

Конкретно данная работа интересна тем, что используются те же самые BLDC, которые мотает сам станок (привет самовоспроизводство). Это решение имеет и свои недостатки: относительная дороговизна BLDC по сравнению с шаговыми двигателями и недостаточная жёсткость в режиме удержания (это заметно по колебаниям осей).

#diy #winder #bldc

Конвертнули в mp4, чтобы смотреть без загрузки файла. Спасибо подписчикам за бдительность)

​​Основные подходы к использованию машинного обучения в Robotics Manipulation

Imitation Learning - симуляция не нужна, записываются демонстрации движений, на базе которых производится обучение и дальнейший инференс. Получил популярность, благодаря таким проектам как Aloha и LeRobot. Этот метод мы в Robossembler сейчас испытываем, используя промышленного коллаборативного робота и его уменьшенную кинематическую копию.

Reinforcement Learning - делится на Online (сбор данных и обучение происходят одновременно) и Offline (сбор данных отдельно, обучение отдельно); требует более сложной настройки - функции наград, условий начала и конца эпизодов в симуляции, параметров рандомизации сцены. На этот метод мы рассчитывали, разрабатав env-manager (менеджер виртуальных сред); он более сложный из-за Sim2Real Gap, сложности настройки сред и их быстродействия.

Foundation Model - берётся pre-trained модель, производится опциональный её тюнинг и инференс. Пока не пробовали, но выглядит перспективно. Тем более, при наличии общедоступных foundation VLA моделей весов типа π0.

#learning #robotics #manipulation

Разработчики САПР KiCad раскритиковали Wayland и рекомендовали использовать X11
Разработчики свободной системы автоматизированного проектирования печатных плат KiCad рассказали о состоянии реализации поддержки Wayland и обобщили проблемы, мешающие полноценному использованию данного протокола. Пользователям, профессионально проектирующим печатные платы в KiCad или желающим получить стабильное и полнофункциональное окружение, рекомендовано запускать KiCad в средах рабочего стола на базе протокола X11, таких как Xfce, MATE или X11-сеанс KDE Plasma.

OpenNews

Все диаграммы ros2_control в одном файле - архитектура, сценарии интеграции и многое другое.

https://github.com/ros-controls/control.ros.org/blob/rolling/doc/resources/diagrams/ros2_control.drawio

Открывать в draw.io

​​Интеграция нейросетей в ПО робота на примере ROS 2

Обобщённый конвейер инференса включает в себя:

1. Сбор данных (Observations)

Первый этап заключается в получении данных от различных датчиков и устройств, которые будут использоваться для обучения или применения ML-модели. В него входят обычно Драйверы ROS 2 , которые обычно реализуют доступ к robot state publishers, камерам, датчикам силы/крутящего момента (F/T sensors) и другим устройствам сбора данных. Также важно проработвать вопрос Синхронизации времени, особенно при работе с несколькими источниками данных. Для этого используются такие механизмы, как фильтры сообщений и трансформации TF (Transforms) для получения гарантий согласованности временных меток.

2. Вывод модели (Inference)

На этом этапе происходит обработка полученных данных с помощью обученной ML-модели.

в случае с Python: Обёртка над PyTorch в виде узла ROS 2. При этом важно быть осторожным с проблемами синхронизации между CPU и GPU, особенно при работе с многопоточными executors.
в случае с C++ : Использование ONNX Runtime для выполнения инференса. Дополнительным преимуществом является возможность обернуть модель в контроллер ROS 2, что позволяет более гибко интегрировать её в существующую систему.

3. Управление аппаратным обеспечением (Commanding Hardware)

Для управления различными типами устройств используются специальные драйверы, такие как контроллеры ROS 2. Важно определиться с тем, какие системы координат использовать — пространство суставов (Joint space) или декартово пространство (Cartesian). Также стоит учитывать вопросы импеданса (Impedance/admittance). Также на этом этапе возможно добавление опциональных слоёв поверх контроллеров, таких как проверка столкновений (collision checking) или решение обратной задачи кинематики (IK) для обеспечения надёжности/предсказуемости исполнения. Например, можно использовать MoveIt Servo (ограниченный функционал) или создать пользовательский узел ROS 2 с полностью настраиваемыми параметрами.

Автор - Sebastian Castro

#ros #model #inference

​​Open Source: По ту сторону кода. Учимся создавать сообщества - ч.1

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

Первым в ряду литературы с описанием успешного опыта релевантного задаче стоит "Just for fun" Линуса Торвальдса, но в нёй фигурируют скорее личные аспекты мировоззрения автора и его хардкорная молодость с круглосуточным кодингом, а не конкретная методология работы с людьми. Изложенный в мемуарах опыт Линуса отражает ту стадию развития Open Source, когда многое осуществлялось по наитию, за счёт личного энтузиазма и харизмы, а успешный результат был обусловлен скорее первопроходческой новизной, нежели правильно исполненной технологией. Иными словами, когда-то для стремительного взлёта открытого проекта было достаточно опубликовать его код и всё. Собственно, именно так и сделал всё в своё время Линус. И понеслось...

Однако, приходит время, и этого становится недостаточно. Уже сейчас на Github порядка 100 миллионов репозиториев и теперь, чтобы ворваться с Open source проектом, нужно изрядно пошевелить локтями, чтобы как-то выделиться в столь насыщенной среде. Для того, чтобы это делать наиболее эффективно, нужно применять определённые практики работы - как и в любой другой деятельности, стадия искусства и интуитивного поиска в предметной области заменяется вполне чёткой формализованной методологией достижения конечного результата.

В этом отношении книга Джона Мертика "Open Source: Beyond the Code" более сбалансирована - она содержит как личный опыт работы в позициях от начинающего разработчика в SugarCRM до директора по управлению программами Linux Foundation, так и большое количество обобщённых полезных практик в проектах отрытого ПО, часто формализованных до состояния приспособленных для работы чек-листов. Она обобщает опыт такого перехода. Именно поэтому её вполне можно советовать в качестве практического руководства для начинающих создателей сообществ и предприятий в сфере Open Source.
Этой теме я посвящу серию постов, где поделюсь мыслями по некоторым наиболее интересным с моей точки зрения разделам книги и их значению в развитии сообщества Robossembler.

#community #linux #foundation

TAMSViz - RViz на максималках

Пока многие пытаются внедрить в ROS веб-технологии и Rust, эти ребята выжимают максимум из имеющихся в экосистеме инструментов визуализации.

Проект TAMSViz дополняет всем знакомый RViz новыми фичами:

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

Для работы с rosbag: загрузка rosbag-файлов, их визуализация, аннотирование; возможность перемотки с несколькими TF-издателями без разрыва TF

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

Кликайте по ссылке на документацию, там много скриншотов.
https://tams-group.github.io/tamsviz/index.html

Проект не то чтобы активно разрабатываемый, но и не совсем мёртвый - последний коммит 8 месяцев назад. Поддерживается TAMS - департаментом информатики Университета Гамбурга.

#rviz #extention #ros

Рубрика "Проекты Подписчиков"

Сергей Акимов aka Akiman DIY на своём канале делится опытом: разнообразные инструменты и приспособления, электроника (ШИМ, терморегуляторы), переделка и ремонт техники, эксперименты с материалами (добыча цинка в домашних условиях, пайка медью), обзоры техники, лайфхаки.

Есть и ролики по нашей предметной области:

Магнитные муфты на неодимовых магнитах
https://www.youtube.com/watch?v=XvL29mdsqyQ

Подключение бесколлекторного двигателя через регулятор
https://www.youtube.com/watch?v=InIqnP2Bqf8

Будет ли работать двигатель под водой в масле на большой глубине? Проверим!
https://www.youtube.com/watch?v=6V0ZejU2xSc

Если из всего многообразия тем Робоссемблера Вам близка именно DIY, то смело подписываемся!

#diy #community

​​Модульное (юнит) тестирование в 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

​​Topic Keys в ROS 2 Kilted

Одним из главных нововведений в новом промежуточном релизе ROS 2 Kilted стали ключи для топиков, которые удостоились аж двух дополнительных страниц в документации. Наиболее мотивированные разработчики могут ознакомиться ними в исходнике на английском языке (см. Topic Keys Tutorial, Topic Keys Subscription Filtering Tutorial), для занятых кратко изложу суть идеи.

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

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

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

Ключевые топики объявляются в спецификациях сообщений в нотации OMG IDL (Interface Definition Language), где поддерживаются аннотации с @. В .msg и .srv такие аннотации не поддерживаются.

Пример: KeyedMsgName.idl

 package_name {
  module msg {
    struct KeyedMsgName {
      @key long key;
      string data;
    };
  };
};

Фича работает пока только в DDS реализаций rmw_fastrtps и rmw_connextdds. rmw_cyclonedds и rmw_zenoh_cpp не поддерживаются.

#ros #kilted #feature

​​Шекспир, Китай и Роботы

В нашей стране китайский разработчик и производитель промышленных роботов Estun не очень на слуху, их роботы не так популярны среди российских интеграторов. Тем не менее, это один из ключевых игроков на китайском рынке, входящий в тройку лидеров по количеству инсталляций. Блестящие показатели Китая по роботизации - во многом их заслуга.

Помимо этого, компания также примечательна полным игнорированием ROS, что довольно необычно для топового производителя. До сих пор ни для одного робота из линейки Estun не существует ни одной реализации аппаратного драйвера ROS - как со стороны самой компании, у которой нет аккаунта на Github, так и со стороны сообщества. Вопрос как-то поднимался на answers.ros.org, но энтузиастов имплементировать драйвер не нашлось.

Тем не менее, интерес у Estun к Open Source имеется с другой стороны - в сотрудничестве с Шведской Cognibotics Estun компания поучаствовала в создании фреймворка для разработки приложений робототехники на базе языка программирования Julia, ориентированного на научные вычисления. Фреймворк называется Juliet & Romeo по наименованиям ключевых его компонентов.

Juliet — это язык программирования, основанный на принципах Julia, но специально адаптированный для задач реального времени: управления движением и обработки данных с жёсткими временными ограничениями, которые критически важны для промышленной автоматизации. В отличие от Julia, Juliet сознательно жертвует динамичностью ради детерминизма и гарантий реального времени. Достигается это в том числе за счёт статической типизации и компиляции в байт-код.

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

Несмотря на то, что проприетарные языки программирования и виртуальные машины благополучно вымерли и являются non-sense в мире IT, репутация Estun вряд ли даёт нам большие надежды увидеть данные инструменты в Open Source. Однако, тут важно понимать общий технологический тренд. В рекламных материалах и презентациях по Juliet&Romeo это доходчиво обосновывается. Промышленность конвергирует с остальным IT и постепенно заимствует оттуда лучшие практики и решения. Возможно, в скором будущем, мы увидим и открытые фреймворки для роботов на Julia, которые можно будет более предметно обсуждать и тестировать.

#julia #estun #cognibotics

rosidpcpp - оптимизация сборки интерфейсных пакетов

В ROS 2 сборка интерфейсов работает довольно медленно и пакеты с большим количеством сообщений могут компилироваться очень много времени (например, на машине с AMD Ryzen 9 9900X 12-Core (24 threads) с 32 Гб ОЗУ ublox-msgs собирается 72 сек., px4-msgs - 42 сек.). Это происходит в связи с тем, что скрипты вроде rosidl generator или rosidl typesupport не оптимизированы для многопоточного исполнения. Другая проблема заключается в том, что изменение даже одного idl-файла запускает пересборку всего пакета, что в сочетании с долгой сборкой усложняет разработку. Автор rosidlcpp ставит целью переписать стоковый Python-пакет rosidl на C++ для оптимизации времени исполнения скриптов сборки. Даже без использования многопоточности он даёт значительное ускорение - она работает в среднем в 3-15 раз быстрее. Если в вашем проекте большая и регулярно пополняемая коллекция интерфейсов в одном пакете, то имеет смысл следить за данным проектом.

Github

#ros #ci #idl