Экспертиза · Системы для роботов

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

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

Обсудить проект

Предложение с условиямиСегодня я прогнал всё, что можно прогнать. Контур управления существует и он серьёзный, но он офлайн: собственный модуль кинематики для шестикоординатной руки, который решил 8.400 из 8.400 точек траектории, и валидатор физики на MuJoCo 3.10.0 с 34 пройденными тестами, плюс 14 тестов по части визуализации. Оба в собственном исходном коде заявляют, что у них нет передачи на hardware и они не могут управлять реальным роботом. На виду у нас собственный прототип — детекция и отслеживание людей на фиксированной IP-камере — с одним коммитом и пустой директорией тестов. По аудио на роботе у нас ноль: всё, что есть на диске, — это голос колл-центра или сторонняя телефонная библиотека, а единственная собственная акустическая работа завершилась отрицательным результатом, записанным в приложении. ROS: ноль установлено, ноль написано. Правило требует минимум двух собственных реализаций для «сделал»; по контролю они у меня есть, но ни одна не касается hardware, а два других слоя услуги — ниже порога. Значит: предложение с условиями, с проведёнными границами.

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

То, что есть по части движения, — это проверка до движения. Собственный модуль вычисляет прямую кинематику, якобиан и обратную кинематику для шестикоординатной руки, с принудительным запасом относительно пределов каждой оси, и был использован для проверки целой траектории: 8.400 запрошенных точек, 8.400 решены, при этом максимальная скорость по оси осталась ниже 8% от каталожного предела. Отдельно валидатор физики работает на MuJoCo 3.10.0 на процессоре, с шагом расчета в одну миллисекунду, в шести сценариях, каждый по два раза, с одной и той же seed — и два прогона дают одинаковые отпечатки. Детерминизм — это не утверждение, а сравнение контрольных сумм.

В части зрения есть меньше, и честно сказать, сколько именно. Собственный прототип делает детекцию и отслеживание людей на потоках IP-камеры, с небольшим детектором из семейства YOLO, мультиобъектным трекером, оценкой позы для пяти состояний и управлением поворотом-наклоном-трансфокацией камеры. У него один коммит и пустой каталог тестов. И разница между этим и зрением робота реальна, а не формальна: камера на роботе движется вместе с ним, сцена близко, экспозиция меняется на каждом шаге, а бюджет задержки другой, потому что изображение должно дойти до решения о движении, а не до экрана. У нас нет камеры глубины, нет калибровки камеры, нет визуальной одометрии.

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

Что входит

Работа, по составляющим

Проверяем кинематику до того, как что-то двигать

Прямая кинематика, аналитический якобиан, построенный из векторных произведений, численная обратная кинематика с четырьмя стартовыми позициями и запасом, заданным 10° относительно предела каждой оси, с сходимостью до 0,05 мм по позиции. С ее помощью мы проверили размещение в 1.331 позиции сетки и полный маршрут из 8.400 точек, все решены. Результаты: максимальная скорость по оси на 7,86% от каталожного предела и минимальный запас до пределов 19,9°. Отчет сам описывает свою природу: дискретный офлайн-скрининг, без выхода к оборудованию.

Запускаем физику отдельно от изображения, и воспроизводимо

Валидатор физики — это отдельная программа от визуальной части, на MuJoCo 3.10.0, на процессоре, с шагом в одну миллисекунду и семплированием каждые 20 миллисекунд. Шесть сценариев, каждый запущен дважды с одной и той же зерном, с идентичными отпечатками между запусками. Допуски объявлены в коде, а не подразумеваются: дрейф энергии менее 1% относительно, проникновение в грунт менее 3 см, нарушение суставного предела менее 0,03 радиана. То, что измеряется при свободном падении, — это ускорение центра масс, сравниваемое с настроенной гравитацией — 9,80665, 1,62 и 3,72076 метра на секунду в квадрате.

Ставим блокирующие ворота, а не только помечающие

Журнал действий требует от каждого движения указать свое происхождение, и все 15 записанных действий помечены как кинематические, validated zero — потому что ни один из них не управляется контроллером с симулятором твердых тел, ограничениями актуаторов и проверкой контакта. Сверху над ним ворота выпуска читают файл доказательства и падают, если ключевая константа не откалибрована на оборудовании. Сегодня падают: одна единственная константа суставной остановки, 5 миллисекунд, в коде объявлена как временный параметр, а не измеренное значение — и этого достаточно, чтобы полная проверка завершилась ошибкой. Это правило, написанное нами против нас.

Читаем описание робота собственным парсером и говорим, что он оставляет за бортом

Для отображения и проверки моделей мы написали собственный анализатор формата MJCF: тела, шарнирные, свободные, скользящие и сферические суставы, геометрии, материалы и загрузку мешей, с кэшем геометрии. Он намеренно оставляет за бортом геометрии столкновений, потому что это визуальный анализатор, а не анализатор контактов — написано в коде, а не обнаружено позже. Используемые модели — официальные, с 29 степенями свободы для гуманоида и 12 для четвероногого.

Не путаем заданные значения с измеренными

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

Зрение: детекция и отслеживание людей, на стационарной камере

Собственный прототип, который берет потоки IP-камеры, обнаруживает людей с помощью небольшой модели из семейства YOLO, отслеживает их между кадрами с мультиобъектным трекером при пороге уверенности 0,5, оценивает позу в пяти состояниях — неизвестно, сидит, стоит, идет, наклонен — и может вращать камеру через стандартный протокол управления. Работает принудительно на процессоре из-за несовместимости, отмеченной в коде. Его реальное состояние: один коммит и пустой каталог тестов. Это прототип, а не производственный модуль, и он никогда не был на роботе.

Аудио на роботе: говорим, чего не хватает, вместо того чтобы заимствовать из телефонии

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

ROS: у нас нет, и мы не притворяемся

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

Что мы бы приняли и чего не приняли бы

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

Как это выглядит

Путь, шаг за шагом.

Определяем задачу и физические ограничения, затем проверяем, помещается ли это

Что робот должен достигать, в каком объеме, с какой скоростью и с какой нагрузкой. Затем проверка: покрытие объема, запас относительно пределов каждой оси, скорость и ускорение по траектории, коллизии по реальной геометрии как скрининг. Мы сдаем отчет с изложенными в нем ограничениями. У этого этапа хорошее соотношение между затратами и предотвращенным ущербом, потому что он выполняется до покупки.

Мы моделируем с заявленными допусками и с проверенной детерминированностью

Сценарии, фиксированный seed, повторные прогоны, сравнение отпечатков, допуски, записанные в коде. Мы также сдаем список вещей, которые симуляция НЕ доказывает — у нас, например, валидатор, который подтверждает свободное падение и удержание позиции на испытательной плоскости, не подтверждает ходьбу, сложный контакт или динамику привода, и пишет это сам.

Мы строим восприятие на ваших данных, а не на публичном наборе

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

Мост к аппаратной части — этап, который мы никогда не делали

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

Цепочка робота, слева направо, с реальным состоянием каждого звена. Зрение: прототип на стационарной камере, один коммит, без тестов. Слух: пусто — ничего не построено для микрофона на движущейся машине. Решение и кинематика: проверены, с 8.400 решенными точками и с воротами, которые блокируют, когда константа не откалибрована. Последняя стрелка, к моторам, прервана: ни один наш код не имеет передачи к hardware. Схема сделана затем, чтобы было видно, где останавливается сервис, а не чтобы выглядеть полной.

Данные

К чему прикасаемся, где оно лежит и сколько остаётся

Вопросы, которые задаёт всякий, у кого есть ответственный за защиту данных, — заданы здесь раньше, чем их задаст он.

Камера робота снимает людей, и это меняет все: Модуль зрения, который обнаруживает и отслеживает людей, производит персональные данные в прямом смысле этого слова, даже если никто не идентифицируется по имени. Вопросы задаются до первой строки кода: сохраняется ли изображение или только результат, где оно обрабатывается, у кого есть доступ к записям, как долго они хранятся, что показывается тем, кого снимают. Наш прототип был построен как технический эксперимент, а не как введенная в эксплуатацию система, и мы не предлагаем его как таковой.
На устройстве или на сервере — решение по задержке, а не по предпочтению: Если изображение должно дойти до решения о движении, путь до сервера и обратно напрямую входит в бюджет реакции. Если результат только отображается или записывается, сервер приемлем. Решение принимается по бюджету задержки, измеренному на вашем случае, и записывается. Наш прототип принудительно работает на процессоре, что является реальным ограничением по скорости, отмеченным в коде.
Симуляции сохраняются с seed и отпечатком: Результат моделирования без зерна генератора и без контрольной суммы входных данных — не доказательство, а история. В наших отчётах по физике указываются зерно, число прогонов на сценарий, версия движка и состояние детерминизма; в отчётах по кинематике — отпечаток входных файлов. Так можно проверить, спустя месяцы, остаётся ли цитируемая цифра в силе.
Аудио означает запись помещения: Микрофон на роботе слышит всё, что происходит вокруг, а не только поданную ему команду. Правило, которое мы бы применили, состоит в том, что непрерывная запись не должна существовать по умолчанию, а только окно, необходимое для решения, и то, что сохраняется для улучшения, должно быть явным выбором с ограничением по сроку. У нас пока нет такой системы, так что это заявленная позиция, а не доказанная практика.
У моделей и описаний роботов есть свои лицензии: Модели роботов, которые мы используем в моделировании, происходят из публичных коллекций, под разрешительными лицензиями, а описания промышленных роботов — это публичные файлы производителей. Они не наши, и мы на них не претендуем; в вашем проекте лицензия каждого внешнего источника проверяется до включения в поставляемый результат.

Случай

Собственное акустическое измерение, которое завершилось «нет», и почему мы его публикуем

Ситуация

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

Что мы построили

Мы построили полный конвейер, а не набросок: 12-миллисекундный свип-сигнал от 2 до 8 килогерц, с оконной обработкой, передаваемый с низкой амплитудой; взаимная корреляция между излучённым и записанным сигналом; обнаружение прямого прихода с защитным окном 1,5 миллисекунды, чтобы боковые лепестки автокорреляции не приняли за эхо; поиск эха в окне до 60 миллисекунд, с отдельными порогами по корреляции и по относительному усилению; скорость звука, скорректированная по температуре воздуха. Почти 800 строк Swift, с обнаружением аудиотрассы — если передатчик и приёмник на разных устройствах, геометрия бистатическая, и одно время задержки задаёт эллипс, а не точку.

Что получилось

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

Чего этот случай не говорит

Результат касается потребительского оборудования через беспроводное соединение, а не робота с установленными и подключёнными микрофонами. Переносится не вывод, а метод: канал измеряется до того, как обещать функцию. Для робота такое же исследование началось бы с собственного шума машины в движении — и только результат этого измерения сказал бы, что возможно.

Вопросы

О чём нас спрашивают перед тем, как позвонить

Вы когда-нибудь ставили ваше программное обеспечение на физического робота?

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

Тогда что именно у вас есть, конкретно?

Три вещи, и все можно запустить у вас на глазах. Модуль кинематики для шестикоординатной руки, который проверил траекторию из 8.400 точек без единого сбоя, с минимальным запасом 19,9° до пределов осей. Валидатор физики на MuJoCo 3.10.0, с 34 тестами, которые проходят, и с детерминизмом, подтверждённым идентичными отпечатками при повторных прогонах. И демонстратор в браузере с 14 тестами, чья квалификационная проверка сегодня намеренно падает. Плюс прототип зрения, о котором мы открыто говорим, что у него один коммит и ни одного теста.

Вы работаете с ROS?

Нет. У нас он не установлен, мы не писали ни одного узла, ни одного файла запуска и ни одного пакета. Единственный пакет типа ROS на наших дисках — это публичное описание промышленного робота, скачанное как файл модели для расчётов кинематики — использованное как данные, а не построенное. Если ваша команда уже работает в ROS 2 и это требование, мы начинаем там с нуля, и это нужно учитывать.

Можете сделать модуль зрения для нашего робота?

С этапом измерения до этого, а не на основе того прототипа, который у нас есть. Из него переносится способ работы — детектор, трекер между кадрами, порог уверенности, где выполняется вычисление. Не переносится ситуация: камера на роботе движется, объект рядом, освещение меняется на каждом шаге, а результат должен приводить к решению о движении, а не к экрану. Кроме того, у нас нет ни камеры глубины, ни калибровки камеры, ни визуальной одометрии ни в одном собственном проекте. Первым этапом был бы захват из вашей среды и эталонное измерение.

У вас есть голосовые агенты. Разве это не то же самое, что слышать робота?

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

Почему вы публикуете падающий квалификационный шлюз?

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

Что не доказывают ваши симуляции?

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

Нам нужна сертификация безопасности. Вы её делаете?

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

Почему на этой странице написано «оферта»?

Потому что у услуги три слоя, и ни один не проходит полностью тот порог, который мы себе поставили. По управлению у нас две собственные работы с проходящими тестами, но ни одна не доходит до оборудования. По зрению у нас прототип с одним коммитом и без тестов. По аудио для роботов у нас ноль. Мы могли бы написать страницу, которая звучит как опыт, используя слова вроде «восприятие» и «управление» без цифр. Она бы выдержала до первого вопроса инженера.

На чём основаны утверждения выше (17 источников)

`vision.megapromoting.com` — не система зренияhttps://vision.megapromoting.com · 2026-09-06

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

Как мы работаем Все услуги

Что вы хотели бы наладить?

Расскажите о своём процессе. Вместе определим, что стоит построить, что можно подключить и как проверим результат.

Давайте обсудим