Истории успеха - Source Robotics

Пётр Черняк из Хорватии в своё время стал известен по открытому печатному 6-осевому манипулятору под названием Faze4, который он разработал в 2019 году в рамках своей бакалаврской дипломной работы. Чуть позднее, в 2021 году, в рамках магистерской диссертации он разработал экспериментальную платформу CM6 для отработки передовых концепций; этот робот-манипулятор стал финалистом престижного конкурса открытого железа Hackaday Prize.

В 2022 году он начал разрабатывать PAROL6 - робота, призванного стать новым стандартом в открытой образовательной робототехнике, более близкой по свойствам к промышленным решениям. Робот вышел в 2023 году и вызвал резонанс в мировом сообществе образовательной робототехники - PAROL6 был взят на вооружение ведущими институтами, включая MIT, Стэнфорд и ETH Zurich, для исследований и образования, а Robossembler написал про него отдельный пост. Всего на данный момент по миру было собрано уже более 250 роботов PAROL6.

В начале 2024 года Пётр официально основал коммерческую компанию Source Robotics под лозунгом "Robotics for Everyone" ("Роботы для всех"), которая продаёт как роботов целиком, так и компоненты для их производства - готовые напечатанные детали для сборки, захватные приспособления, программаторы, контроллеры, наборы для разработки, а также исходные файлы STEP. Из свежих разработок можно отметить Spectral-Micro-BLDC-controller - бюджетный контроллер бесщёточного двигателя на STM32F103 с открытой прошивкой, оригинальным GUI для дебага на Python API и поддержкой Simple FOC за 69 Евро.

Уже к октябрю 2024 года компания победила в двух стартап-акселераторах, а в январе 2025 года переехала в новый офис в Загребском стартап-инкубаторе ZICER.
Успехов коллегам!

Про многих других открытых роботов-манипуляторов можно почитать на нашем сайте:
https://robossembler.org/docs/technologies/open-source-robots-and-tools/

#hardware #open

​​ОП, ОП, Teleop - ч.1

Будем плавно подводить итоги года, паралелльно повествую о том, о чём по разным причинам не смогли оперативно рассказать.

Ещё в позапрошлом году в некоторых своих докладах я упоминал о выбранной нами стратегии - совершенствовать методы управления с помощью софта, снижая требования к железу (в том числе к нашему), чем способствовать достижению цели повышения доступности роботов. К примеру, можно оснащать роботов системами машинного зрения и, тем самым, иметь возможность корректировать ошибки, вызванные несовершеннством и точностью самих механизмов робота. Методы машинного обучения роботов (тогда это были в основном visual-action policy) неплохо сочетались с этим подходом и в полной мере соответствовали стратегии - мы можем не только обеспечить обратную связь через машинное зрение (ведь там тоже может накапливаться ошибка, а методы pose estimation не так совершенны как кажется), но и непрерывно корректировать поведение робота в ходе взаимодействия с объектами манипулирования, не занимаясь распознаванием позиционирования объектов в нашей системе координат и вычислением захватных поз.

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

Ещё в 2022 году в работе Offline Meta-Reinforcement Learning for Industrial Insertion была продемонстирована результативность выполнения (success rate) до 100% для некоторых задач вставки (разные штекеры в разъёмы), что представлялось немыслимым результатом для нейросеток. Это исследование продемонстрировало силу файнтюнинга предварительно обученной в Offline RL Policy на реальных демонстрациях, записанных людьми с помощью 3D-мыши. Ключевые авторы стали развивать направление - можно предполагать, что поняли значимость количества и качества данных, а также удобства их сбора для операторов.

Чуть позже, от тех же авторов, появлился проект Aloha (A Low-cost Open-source Hardware System for Bimanual Teleoperation), где подход был смещён от RL в сторону Имитационного обучения или Supervised Learning. Не предполагалось Offline RL-pretrain стадии, как в прошлой работе - сразу обучали сетку трасформерной архитектуры на демонстрациях с помощью специально разработанного фреймворка ACT - action chunk for transformers, предполагающую обновления движений с частотой 50 Гц. Вместо попытки сделать квази-универсальную policy для разнообразного спектра задач (вставка чего-угодно в соответствующие разъёмы) была поставлена задача выполнять одну конкретную задачу, но при этом устойчиво по отношению к изменению входных условий. Помимо этого были взяты бюджетные (относительно коботов, разумеется - от $5000-7500 за шт.) роботы от Trossen Robotics, зато два - стало понятно, что сложные кейсы одним манипулятором делать невозможно, а если уж совсем точно, то четыре - другие два использовались в качестве джойстиков.

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

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

#teleop #summary #aloha

​​ОП, ОП, Teleop - ч.2

Aloha был во всём хорош, но Low Cost его можно было назвать только в сравнении с принятыми в академическом мире решениями на коллаборативных роботах - UR, Franka Emika, грипперы Robotiq и т.п. Сами джойстики на WidowX (Leader) были немного дешевле основных манипуляторов Viper (Follower) - грузоподъёмностью 250 гр, но стоили также относительно недёшево - почти $10К за пару. Сей факт побудил других инженеров-исследователей придумывать альтернативы, среди которых особо выделился проект Gello.

Gello представляет собой open hardware устройство телеуправления из самых миниатюрных двигателях линейки Dynamixel известной корейской компании Robotis. Инженеры продемонстировали работу с промышленными коботами - UR5, xArm7, Franka Emika Panda, что даёт возможность попробовать телеоп в уже оснащённых исследовательских и учебных лабораториях. Джойстики Gello не представляют собой полноценные манипуляторы - в них не нет компенсации гравитации, устойчивость джойстика к падению обеспечивается натянутыми резинками и редукторами серво машинок. Последние де-факто используются как датчики угла, а не как полноценные двигатели. При всех своих минусах устройство существенно бюджетнее Aloha - в районе $400-500 за штуку, а основная часть конструкции может быть напечатана на 3D-принтере.

Другой важной заслугой авторов является публичное обоснование кинематической копии манипулятора в качестве наиболее предпочтительного устройства для сбора данных телеопом. Они сравнивали джойстик с другими популярными решениями - VR-контроллером и 3D-мышью. Привлекая к телеуправлению людей со стороны, не имеющих опыта работы, исследователи выяснили, что Gello-джойстик осваивается существенно быстрее. К слову, их репозиторий gello_mechanical с 3D-моделями по-прежнему развивается: энтузиасты со временем добавили собственные модели джойстиков для роботов AR4, YAM, xArm6.

Изучая данные проекты, мы заметили, что все они были довольно глубоко интегрированы с Dynamixel API, затрудняющих реализацию на других робо-платформах, страдали низким качеством поддержки ROS 2, а также не стремились сохранить возможность использовать другие устройства телеуправления - например, GamePad или те же VR-контроллер или 3D-мышь.

Так мы пришли к идее реализовать собственную библиотеку телеуправления Robossembler Teleoperation Library (rbs-teleop), которая представляет собой унифицированный интерфейс для любых устройств телеуправления и любых роботов, поддерживающих Hardware Interface ROS 2 Control. По нашей первоначальной гипотезе это позволило бы реализовать телеуправления любым роботом с ROS 2 Драйвером в кратчайшие сроки. Достигается это благодаря Virtual Frame Controller, через который мы можем отмапить IMU-сенсор или Энкодеры в соответствующие управляющие воздействия на шарнирах робота. Помимо этого, почти весь софт в Aloha/Gello был написан на Python, что не могло в перспективе не сказываться на быстродействии и гарантиях realtime, поэтому для основной runtime-части rbs-teleop был выбран C++.

Сперва работа библиотеки была проверена на геймпаде в симуляторе, а Gello оказался первым устройством, на котором мы проверили эту гипотезу в реальности вместе с китайским промышленным коботом Aubo i5, причём сразу на новом ROS Middleware Zenoh.

#gello #teleop #hardware

​​ОП, ОП, Teleop - ч.3

С изготовлением и пусконаладкой джойстика Gello проблем почти не возникло: BoM лист соответствовал реальности, все STL-ки замечательно распечатались, Dynamixel приятно порадовали качеством документации и удобным приложением для настройки идентификаторов серводвигателей на шине. Была небольшая загвоздка в том, что не оказалось соединительных проводов нужной длины; привезли 1.5-метровые, которые наспех, не имея инструмента для обжима, пришлось смотать как попало. В результате монтажа таких "длинных" линий шина отказалась работать на 4 Mbps, однако заработавших в итоге 2 Mbps нам хватило за глаза.

А вот с Aubo пришлось повозиться. Наша модель 2019 года работала с устаревшим софтом на контроллере. Китайцы старательно воспроизводят UR во всех отношениях - от кинематики до наименований релизов GUI, но, разумеется, с заметным опозданием, а потому на том громоздком стареньком контроллере, который нам достался, отсутствовала поддержка протокола RTDE. Последнее было для нас критично, потому что имеющиеся имплементации ROS 2 драйверов под данного робота были ориентированы именно под этот стандарт взаимодействия. Писать же драйвер под устаревший SDK очень не хотелось. Гипотеза про "библиотеку, способную работать на любом роботе с ros2-control драйвером" начала трещать по швам на первом же промышленном роботе! Идея обновить софт после некоторых предварительных исследований была отвергнута как несущая риски - техническая поддержка Aubo посоветовала не делать этого.

Но мы не отчаились и начали ковыряться во внутренностях Control Box, находя по лоскуткам остатки API и документации для их самописной динамической библиотеки из SDK, потому как официальная документация этому SDK на тот момент уже не соответствовала. К счастью, мозги были на патченом под Realtime Xubuntu и мы с лёгкостью всё там откопали. RTDE там не оказалось, а оказался TCP socket-сервер, который позволял худо бедно реализовывать управление роботом и синхронизировать его с джойстиком. Скорость отклика была неважнецкая, для записи сотен датасетов никуда не годилась, но позволила нам поуправлять в реалтайме и записать демо. MVP состоялся и позволил ощутить в полной мере UX нашей библиотеки, чтобы повысить её удобство в будущих имплементациях.

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

#aubo #gello #teleop

​​ОП, ОП, Teleop - ч.4

Опыт Aubo был полезен с точки зрения нашей способности решать возникающие проблемы по ходу проекта, однако это не совсем то, чего нам хотелось. А именно - попробовать подключить к телеуправлению ROS 2 Control Hardware Interface совместимый драйвер и таки попробовать имитационное обучение, чтобы убедиться в работоспособности подхода. Уже тогда, по ходу завершения работ с Aubo, мы понимали ограничения и сложности настройки такой системы - особенно в части синхронизации положения робота и джойстика. Правда тогда мы ещё не совсем понимали риски, потому что Aubo был довольно таки тормознутый и относительно медленно реагировал на изменения положения джойстика.

Риски стали понятны, когда мы попробовали развернуть наш стек на UR3, который любезно предоставила для экспериментов Лаборатория волновых процессов и систем управления. Поддержка ROS 2 у UR шикарная, поэтому проблем с пусконаладкой драйвера практически не возникло. Робот очень быстро реагировал на движения, иногда даже через чур быстро - если джойстик находился в положении, сильно отличающемся от фактического положения манипулятора, то манипулятор на максимально возможных скоростях старался принять требуемое положение, что приводило у раздражающему дёрганью. Это заставило нас задуматься об улучшении UX. Так родилась идея с фантомной URDF-моделью и RViz панелью с калибровкой офсетов робота и джойстика.

Фантомная модель - это фактически копия URDF робота, управляемая джойстиком и позволяющая понять заблаговременно каким образом его движения будут соответствовать движению робота. Мы тренируемся на фантомной модели, наблюдаем за движениями робота и, уже убедившись в том, что они соответствуют действительности, включаем соединение через Virtual Frame Controller с реальным роботом. На видео ниже можно наблюдать за тем как робот "следует" за фантомной моделью в панельке RViz. Как мы убедились позднее, это действительно удобная фича при пусконаладке в реальных условиях, особенно на тех роботах, у которых нет коллаборативности и одно неаккуратное движение может привести к аварийной ситуации.

#teleop #ur #rviz

​​ОП, ОП, Teleop - ч.5

UR3, не смотря на отличную поддержку в ROS 2, заставил нас потрудиться в настройке контроллеров оригинального аппаратного интерфейса. Робот иногда двигался очень резко и постоянно вибрировал. Вопрос решили настройкой PD-регулятора - немного понизили отзывчивость системы, после чего робот заработал как часы с оптимальной скоростью реакции.

Наладив телеуправление, мы перешли к тестированию модуля записи эпизодов и имитационного обучения. Управление записью эпизодов осуществлялось с помощью клавиатуры; в случае с одной роборукой это не доставляло неудобств, хотя если переходить к двуручному телеуправлению, то неизбежно нужно будет переходить к голосовым командам. Сами эпизоды писались в каноничный rosbag2 (это своеобразная фича библиотеки для сохранения возможности дебага средствами ROS) с последующей конвертацией в формат lerobot.

В качестве пробной задачи взяли примитивный pick&place на имевшихся в лаборатории образцах - нужно было захватить синий цилиндр и поставить его на белый кубик. Мы экспериментировали с количеством камер (2-3), с количеством эпизодов (старались уложиться в заявленные Aloha ~50 эпизодов, но потом проводили эксперименты с записью до 250), рандомизацией, обучением своей сетки и дообучением Small VLA. Был испытан первый прототип нашего веб-сервиса, который принимает записанные эпизоды, агрегирует на сервере и запускает обучение. Навык заработал, но стабильного воспроизводства добиться не получилось на 200 эпизодах, однако мы приобрели ценный опыт и знания о многих ньюансах процесса, сделали выводы.

Чуть позже я общался с одним из разработчиков робота-пикера от Yandex Robotics (одна из немногих команд в России, которая делает Imitation Learning для производственных задач на пром-роботах), что позволило как-то дополнительно переосмыслить пережитое:

1. Джойстики в целом оправдали себя. Для сбора данных на Пикере применяют VR-контроллеры и, в среднем, на обучение с нуля оператора уходит от 1 месяца, чтобы его навык был сопоставим с производительностью текущей модели. Джойстики-манипуляторы явно выигрывают по этому параметру - обучиться им действительно можно за 2-3 дня. Однако, если вы можете себе позволить постоянного оператора на долгий срок, то VR в целом тоже выглядит привлекательным вариантом. VR позволяет не быть привязанным к конкретному рабочему месту - оператор может находиться в разных позициях. У нас в rbs-teleop есть в этом расширяемость.

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

3. Железо имеет значение.
У нас был довольно скудный расклад по Computer Vision - три веб-камеры Logitech C920 с постоянно слетающими настройками в условиях непрерывно меняющихся в течение дня условиями освещённости (солнечная сторона), что снижало общее качество данных записей. Да, это был осознанный выбор - мы стремились обеспечить низкий порог по бюджету робототехнического комплекса, однако в будущих проектах мы уже ориентировались на RGBD - как минимум двух - на запястье D405, на штатив для обзора D435.
Инференс мы запускали на геймерском лаптопе с GTX 1070 и в целом он справлялся. Для сравнения Пикер запускается на RTX 3090 и выше. В целом вполне может быть работоспособным сценарий с инференсом на сервере (как бы дико для интеграторов это не звучало).

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

#teleop #ur #yandex

​​Феномен Мейнтейнерства

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

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

Этим обусловлен и специфический набор навыков, которым должен обладать такого рода специалист. Должна присутствовать экспертиза в конкретном языке программирования, ведь нередко приходится писать патчи к исходному коду, потому что в upstream'е слишком заняты, чтобы исправлять или принимать патч для твоего конкретного бага. Например, в исследовании Upstream bug management in Linux distributions. An empirical study of Debian and Fedora practices приводится статистика, что порядка 13.3% исправлений осуществляется непосредственно мейнтейнерами на уровне дистрибутива, а не в Upstream. Помимо этого, требуется понимание пакетных менеджеров, линкеров, конфигураторов, скриптовых языков и т.п.. Тем не менее, эта деятельность довольно неплохо масштабируется - на поддержку одного пакета уходит относительно немного времени и обычно мейнтейнеры умудряются поддерживать множество пакетов.

Роль мейнтейнеров огромна - именно они являются связующим звеном между разнообразными авторами отворённых разработок и системами более высокого порядка. Благодаря им программа становится частью обширной экосистемы и может быть встроена в другие, более сложные продукты без конфликтов. С появлением ИИ-агентов мейнтейнеры могут уйти от ручного написания сборочных скриптов/рецептов к полуавтоматическим программам-конвейерам, генерирующим эти скрипты для сотен пакетов разом (как, например, сделал в своё до-ИИ-шное время автор nix-ros-overlay, опакетив все разом все дистрибутивы ROS), тем самым обеспечить поддержку большого количества проектов ограниченным количеством людей.

Миру Open Hardware ещё предстоит обрести/создать многочисленные институты мейнтейнеров. Наблюдая за отраслью, я уже давно понял, что заставить всех разработчиков сесть за один и тот же станок - задача совершенно безнадёжная, а вот создать институт мейнтейнеров, оборачивающих проекты свободных аппаратных платформ в готовые к интеграции модули на базе системно-инженерной метамодели в децентрализованную PLM, вполне по силам даже относительно небольшой команде инициативных разработчиков. Это может приоткрыть дверцу для свободных разработчиков из мира хобби проектов на ардуинке к чему-то действительно сложному и масштабному. Примерно в этом направлении мы работаем совместно с метод-советом сообщества @ntstg.

#maintainter #linux #nix

Ключевое мероприятие российской робототехники, которое организовывает Консорциум Робототехники. Представлены практически все организации, занимающиеся разработкой и внедрением роботов, регулированием отрасли.

Планирую посетить. Если кто-то ещё из подписчиков соберётся, пишите - пересечёмся.

​​Кибер-физические системы в Робономике

Робономика, пионеры в области применения блокчейн-технологий в робототехнике, продолжают своё развитие. В прошлом году команда проекта приступила к реализации нового модуля своей сетевой платформы - Cyber Physical System Pallet и пару недель назад инновация была добавлена в основную ветку репозитория, что я воспринял с большим воодушевлением! Долгое время я пытался найти нишу для данной технологии в робототехнике и одним из ключевых сценариев рассматривал управление доступом как альтернативу сложившимся исторически механизмам, предоставляемых операционной системой. Новый CPS Pallet воплощает эту идею на практике. Попробую пояснить каким именно образом.

Обычно для обеспечения безопасного доступа к компьютеру или роботу по SSH Вы можете использовать несколько подходов по степени увеличения надёжности: пароль, публичный ключ, сертификат публичного ключа (Public Key Infrastructure из доверенных центров, выдающих сертификаты, и тех кто им доверяет). Во всех этих случаях есть общая проблема: доступ ассоциируется с конкретным пользователем, компрометация которого даёт злоумышленнику все предусмотренные политикой безопасности возможности. В большинстве случаев проблема решается организационно - с сотрудником или системным администратором (если пользователь - root) существует трудовой договор, у него есть юридическая ответственность, что смещает спектр возможных уязвимостей от технической к социальной области, где защитой служит бюрократия с её сложными процессами согласования тех или иных решений.

Так родилась идея полного исключения доступа по SSH и использования блокчейна в качестве безопасной bootstrap-инфраструктуры как исходного источника данных для обновлений системы. Мы полностью отключаем доступ к системе извне; разворачиваем на системе блокчейн ноду (не переживайте - лёгкую, без майнинга), инициализируем ключи и подключаем её к сети, после чего все обновления в конфигурации осуществляем посредством отслеживания изменений состояния двойника в блокчейне. Причём это обновление может быть привязано не к обычному, а multi-signature акаунту, где для проведения какой-то операции требуется не одна единственная, а, например, 4 из 7 подписей ключевых разработчиков, администраторов, менеджеров. Мы вводим бюрократию как защитную функцию на техническую уровень. Взлом одновременно N аккаунтов, находящихся зачастую в аппаратных хранилищах и в разных юрисдикциях - задача практически нерешаемая. Все крупные активы в блокчейнах хранятся именно таким образом.

Модуль CPS Робономики реализует этот принцип для сложных иерархических систем, которые можно декомпозировать и управлять доступом к отдельным частям. Мы можем, например, представить нашу робофабрику как сложную систему из цехов, производственных линий, роботизированных ячеек и отдельного оборудования от разных поставщиков, после чего давать доступ эксплуатационной службе и разработчикам без необходимости впускать их в производственную локальную сеть. Корневые узлы, отвечающие за глобальные настройки, при этом могут быть привязаны к наиболее защищённым multisig-аккаунтам. При этом CPS-Pallet позволяет обновлять даже самую сложную конфигурацию за постоянное время - O(1), что экономит вычислительные ресурсы узлов сети.

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

Более подробную техническую информацию по реализации модуля можно получить в github: https://github.com/airalab/robonomics/issues/405

#robonomics #blockchain #cps

​​Prometheus - устройство для телеуправления с силовой обратной связью

Команда из лаборатории Дзмитрия Цецерюкоу (Dzmitry Tsetserukou, Сколтех, Москва) разработала приспособление для телеуправления на базе HTC Vive Trackers 2.0. Устройство включает в себя оригинальные пальцы и контроллер, обрабатывающий данные о силе сжатия в реальном времени, благодаря чему оператор может ощущать силу захвата, прикладываемую к объектам. Все исходники железа, ПО, инструкции по изготовлению и инструкции по настройке и запуску опубликованы в github.

В одноимённой статье выделяется два основных метода телеуправления:
1. Копирование кинематики манипулятора (GELLO, AirExo, Aloha, Echo). Обеспечивает максимально быстрое обучения оператора.
2. Применение обратной кинематики для воспроизведения положения end-эффектора (отпадает необходимость в копировании). Наиболее популярные устройства - VR-контроллер, отслеживание движений кистей оператора или устройство с IMU-датчиком. Метод является более универсальным, но и кривая обучения чуть более крутая; есть риски задержек на решение задачи обратной кинематики.

Разработанное устройство реализует второй подход b состоит из рамы, рукоятки и крышки с прикрепленным HTC Vive трекером (в самой статье много картинок, проще посмотреть). Электронный блок представляет собой две платы: плата датчика силы на STM32F303CBT6 и плата управления двигателем (она же основной контроллер приспособления, на STM32F401RET6TR). Принцип действия:
- плата датчика силы измеряет усилие захвата, линеаризует сигнал и передает его на плату управления мотором по протоколу RS-485;
- плата управления мотором вычисляет необходимое усилие для двигателя, обрабатывает данные с энкодера о положении и передает всю релевантную информацию на компьютер через гальванически изолированный USB-интерфейс.

Особо следует отметить специально разработанные сило-чувствительные пальцы для механического захвата Robotiq 2F-85, в которые встроены датчики силы RP-C7.6-LT. Пальцы обеспечивают силовую обратную связь со всей поверхности энд-эффектора и защиту датчика силы от повреждения. Мягкая анти-скользящая силиконовая накладка (Soft-Touch Anti-Slip Silicone Pad), отлитая из двухкомпонентного силикона, предотвращает проскальзывание, обеспечивает более равномерное распределение усилия и, тем самым, позволяет осуществлять мягкий захват объектов.

Сбор данных и инференс были проверены на испытательном стенде с роботом UR3. Техническое зрение обеспечивалось камерами Logitech C920 HD Pro на запястье и установленной сбоку Realsense D455. Обратная кинематика в ходе сбора данных вычислялась через встроенные механизмы UR на базе Real-Time Data Exchange. Для манипулирования были выбраны чувствительные к усилию объекты: куриные яица, помидоры, зубная паста, бутылка шампуня (было записано по сто эпизодов на каждый объект).

Для обучения использовалась предварительно обученная трансформер-модель Octo-Small, которая (как утверждают авторы) "обеспечивает баланс между производительностью и эффективностью инференса, сохраняя при этом компактную архитектуру". Полный процесс дообучения занял 2,5 часа: 50k эпох с размером пакета (batch size) 32 на GPU NVIDIA RTX 4090 с 24 ГБ видеопамяти (также утверждается, что для выхода на плато достаточно 20k эпох).

Экспериментальные результаты:
- Операторы прикладывали в среднем на 35,77% меньше силы, когда обратная связь была включена, что показывает повышенную точность при обращении с хрупкими объектами
- Policy, обученные с использованием входных данных о положении и силе(P+F), достигли уровня успешности до 90% в таких задачах как захват помидора.

Да, в настоящее время система жёстко оптимизирована для руки UR3 и захвата Robotiq 2F-85, что ограничивает её применение к другим РТК без модификаций, но репозиторий в Github определённо повышает шансы на их появление.

#hardware #open #teleop

Предыдущая работа той же команды:

Echo: An Open-Source, Low-Cost Teleoperation System with Force Feedback for Dataset Collection in Robot Learning

Artem Bazhenov, Sergei Satsevich, Sergei Egorov, Farit Khabibullin, Dzmitry Tsetserukou

​​ROS - 2025 год в цифрах

Коллеги из Open Robotics подготовили отчёт за 2025 год. Коротко пройдёмся по ключевым цифрам.

Загрузка. Количество скачанных пакетов с официальных серверов увеличилось на 85%. Если в данную статистику включить пакеты, загруженные в июле (почему-то выпали из отчёта), а также загружаемые через альтернативные системы дистрибьюции вроде RoboStack/Pixi/Nix Cache, то можно смело говорить о двукратном росте!
На ROS 2 теперь приходится 91,2% от общего количества загружаемых пакетов, что скорее всего обусловлено притоком новых разработчиков, которые сразу выбирают вторую версию фреймворка. Их них половина приходится на ROS Humble, на Jazzy - 24,45%.

Разработка. Количество контрибьюторов на Github увеличилось на 11,2%, количество pull-реквестов на 37,59%. Общее количество пакетов в репозиториях apt увеличилось на 9,15%. При этом разработчики ROS написали на 118.33% больше строк кода, чем в 2024 году.

Рост сообщества вокруг кода. ROS Discourse: за год количество новых топиков на выросло на 40%, общее количество сообщений увеличилось на 24%, общее количество просмотров Discourse выросло почти на 30%. Единственным заметным снижением среди всех метрик ROS стало уменьшение количества задаваемых вопросов на Robotics Stack Exchange на -42,49% (привет большим языковым моделям).

Внутренний список Open Robotics из компаний, использующих ROS, вырос в этом году на 26% - до 1579 компаний, что говорит о росте популярность в Enterprise.

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

Разработчики из России, судя по данным статистики обращений к ресурсам Open Robotics, не являются основными пользователями экосистемы - по трафику мы примерно на 11 месте между UK и Францией (первая тройка - США, Китай, Индия).
И, тем не менее, ROS сообщество развивается - о чём свидетельствует всё возрастающий масштаб ROS Meetup, который пройдёт на этот раз в Главном Корпусе МФТИ г.Долгопрудный 20-22 марта 2026 года.

Регистрируйтесь!

#ros #stats #meetup

Коллеги организовывают туры в Китай для разработчиков и производителей роботов. Внизу поста контакты для связи.

Вы видели уже много робо-собак и гуманоидов. Но как создают передовых роботов? Где и из каких компонентов их собирают?

Их делают в Шэньчжэне! Мировой столице электроники и компонентов, где сосредоточены главные исследовательские центры и крупнейшие производства. Большинство современной электроники и передовых девайсов создается здесь.

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

За 7 дней мы посетим выставку и конференцию компонентов для роботов FAIR  Plus, рынок электроники Шэньчжэня, hardware-коворкинг для разработчиков и более 10 компаний, которые производят компоненты для роботов:
🤖JWIPC, производитель промышленных и AI компьютеров для разного типа роботов;
🤖Wabony, OEM и ODM-производитель роботов и электроники;
🤖Sino Dynamics, производитель компонентов и систем автоматизации;
🤖XJC Sensor, разработчик высокоточных сенсоров;
🤖Direct Drive, производитель двигателей для роботов;
🤖 и других производителей компонентов.

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

Поездка пройдет с 19 по 25 апреля 2026.
До 10 марта действует скидка для участников по ранней стоимости. Забронировать участие можно на сайте RoboJobs.

Если у вас есть вопросы по участию в поездке, пишите Анне Прозоровой @AnnaProRobo

#пишу_каждый_день
День 483

​​SysML v2

Известная компания-разработчик открытых стандартов OMG в сентябре 2025 года выпустила вторую версию языка для MBSE (системно-инженерного моделирования) SysML.

Первая версия языка выглядела как попытка натянуть программистский UML на не-только-программистскую предметную область. Вторая версия куда более самобытна - в качестве основного синтаксического слоя представлен KerML (Kernel Modeling Language) - текстовый язык, разработанный специально для системной инженерии, то есть включающий в себя мета-модель системной инженерии, которая, в свою очередь базируется формальной семантике. Всего в языке выделяется четыре архитектурных слоя:
- Root (элемент, импорт, комментарий, отношение, аннотация ...),
- Core (тип, классификатор, свойство, ...),
- Kernel (класс, тип данных, поведение, ...),
- Systems (как раз системно-инженерный домен: части, аттрибуты, функции с портами/ролями, потоки, модули с интерфейсами, сценарии использования, ...).

Важная веха: SysMLv2 уходит от графической нотации в сторону текста, что даёт возможность работать с моделью как с кодом (system-model-as-a-code), то есть версионировать его в git, использовать текстовые редакторы, использовать LLM и другие удобные инструменты автоматизации, накопленные софтверной индустрией. Однако, стандарт сохранил графическую нотацию - каждая сущность в спецификации приводится в обоих вариантах. Введено жёсткое разграничение классов/дефиниций/типов и экземпляров/объектов/значений.

Вводится 4D-экстенсионализм (вероятно влияние ISO 15926 и подхода Мэтью Веста HQDM) - подход в онтологической инженерии, представляющий объекты не только как 3D (имеющих пространственное измерение), но и как 4D, имеющих протяжённость во времени. Реализуется с помощью т.н. Occurrences (Событий). Событие сохраняет свою идентичность на протяжении всего своего времени жизни, в то время как значения его характеристик могут изменяться.

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

Интероперабельность. SysML v2 включает формальный интерфейс программирования (API) и спецификацию сервисов для совместимости с другими инструментами. Модели теперь могут беспрепятственно взаимодействовать с инструментами моделирования и управления продуктовой разработкой (PLM).

В разработке стандарта приняли участие такие компании как Lockheed Martin, IBM, Siemens, Airbus, SAF. О поддержке SysMLv2 уже заявили ведущие разработчики инженерных инструментов - Ansys, PTC, Dassault Systèms.

#systems #plm #cad

KiCad version 10.0.0

Если вы ждали когда дозреет KiCad 9, то можете смело на него переходить, потому что вышел KiCad 10. Фундаментальных изменений немного, но коллеги поддерживают ежегодный темп выпуска новых версий. Русскоязычный обзор уже есть на Habr.

Из наиболее интересного/важного на мой взгляд:
- поддержка вариантов проекта: способ отслеживания различных версий одного проекта, которые используют одну и ту же схему, но имеют изменения свойств (например, другую спецификацию материалов);
- новые импортеры: KiCad может импортировать проекты из Allegro, PADS и gEDA / Lepton PCB. Для получения более подробной информации о возможностях и ограничениях импортера, пожалуйста, ознакомьтесь с публикацией в блоге проекта.

#kicad #eda #pcb

Rust в ROS 2 официально

Проект ros2_rust с 2017 года развивался как инициатива сообщества и лично Стивом Фернандесом, одним из авторов ROS 2, при поддержке Робономики. Однако, теперь поддержка Rust включена в ROS 2 Rolling и будет доступна в следующих дистрибутивах, начиная с Lyrical Luth, который выйдет в мае, в качестве официальной клиентской библиотеки rclrs в одном ряду с rclcpp, rclpy и rclc. Теперь это полноценная часть экосистемы.

В rclrs есть почти весь базовый функционал ROS 2: паблишеры/подписчики, сервисы, actions, QoS, параметры, таймеры, introspection и async-модель. Работает всё поверх стандартного rcl, без изменений транспорта и остального стека.

В докладе на последнем FOSDEM Стив делает акцент не столько на фичах, сколько на мотивации. Rust хорошо ложится на задачи робототехники: производительность уровня C/C++, но при этом строгий компилятор, который не пропускает потенциальные ошибки, и модель “fearless concurrency”, где отсутствие гонок данных гарантируется на этапе компиляции. Отдельно он проводит параллель со стандартом MISRA C, значительная часть рекомендаций которого уже зашита в сам язык.

Если альтернативные библиотеки вроде r2r идут со стороны Rust, то rclrs — это именно ROS-проект, цель которого встроить Rust в существующий пайплайн, что обуславливает архитектурные решения: явный context вместо глобального состояния, жесткая связка node-executor и более безопасная модель выполнения колбэков через async workers. Также он отмечает, что ROS уже давно используется в продакшене (логистика, индустриальные роботы, даже космические миссии), и задача rclrs — не заменить C++, а дать более безопасную альтернативу в рамках той же экосистемы.

Генерация сообщений на Rust уже добавлена в официальные сборки и будет доступна «из коробки» в новых дистрибутивах ROS 2. При этом проект всё ещё активно развивается: API нестабилен, документации немного, часть функционала в работе. Но по ощущениям это уже не pet-проект, а серьёзное направление развития ROS 2.

Итого Rust в ROS 2 из маргинальной штуки становится частью мейнстрима, т.е. стандартного инструментария. Поздравляю!)

Доклад автора (FOSDEM 2026):
https://fosdempwa.com/event/8924?year=2026
Слайды

#ros2 #rust #robotics

Выпуск свободных САПР FreeCAD 1.1 и SolveSpace 3.2
После года разработки опубликован релиз открытой системы параметрического 3D-моделирования FreeCAD 1.1, которая отличается гибкими возможностями кастомизации и наращивания функциональности через подключение дополнений. Интерфейс построен с использованием библиотеки Qt. Дополнения могут создаваться на языке Python. Поддерживается сохранение и загрузка моделей в различных форматах, в том числе в STEP, IGES и STL. Код FreeCAD распространяется под лицензией LGPLv2, в качестве моделирующего ядра используется Open CASCADE. Готовые сборки подготовлены для Linux (AppImage), macOS и Windows.

OpenNews

Ржавый FOC

Давайте проверим дееспособность нашего микросообщества и накидаем звёзд в Github Даниле @okhsunrog из Rust-комьюнити:
https://github.com/okhsunrog/oxifoc
Там сейчас всего 6 звёзд, что я считаю недостойным такого проекта! выше видео-пруф работы библиотеки.

Если коротко, это аналог SimpleFOC на чистом Rust, который использует все самые новые и крутые фичи языка и его экосистемы: например, асинхронный фреймворк embassy.

Embassy позволяет обходиться без RTOS (Real-Time Operating System, сидит почти в любом MCU) за счёт использования асинхронной модели (async-await) языка и кооперативной многозадачности, что обеспечивает меньшие накладные расходы по памяти и времени. В oxifoc нет жесткого реалтайма в рамках планировщика, поэтому цикл управления мотором работает в отдельном прерывании.

В библиотеке уже поддерживаются STM32G431CB, STM32F405RG, STM32G474RE.

По утверждению автора, ни один мосфет не сгорел!)

#rust #embedded #motor #control