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

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

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

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

Предложение с условиямиAm rulat azi tot ce se poate rula. Stratul de control există și e serios, dar e offline: un modul propriu de cinematică pentru un braț cu șase axe, care a rezolvat 8.400 din 8.400 de puncte de traseu, și un validator de fizică pe MuJoCo 3.10.0 cu 34 de teste trecute, plus 14 teste pe partea de vizualizare. Amândouă declară în propria sursă că nu au transport către hardware și nu pot comanda un robot real. La vedere avem un prototip propriu — detecție și urmărire de persoane pe cameră IP fixă — cu un singur comit și cu directorul de teste gol. La audio pe robot avem zero: tot ce e pe disc e voce de call-center sau bibliotecă terță de telefonie, iar singura lucrare acustică proprie s-a încheiat cu un rezultat negativ, scris în aplicație. ROS: zero instalat, zero scris. Regula cere minimum două implementări proprii pentru „am făcut”; pe control le am, dar niciuna nu atinge hardware, iar celelalte două straturi ale serviciului sunt sub prag. Deci: ofertă cu condiții, cu granițele desenate.

Программное обеспечение робота имеет три слоя, которые ломаются по-разному: то, что видит и слышит, то, что решает, и то, что отправляется к моторам. По первым двум у нас есть собственные работы с тестами, которые запускаются. По третьему — мосту к 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, повторные прогоны, сравнение отпечатков, допуски, записанные в коде. Мы также сдаем список вещей, которые симуляция НЕ доказывает — у нас, например, валидатор, который подтверждает свободное падение и удержание позиции на испытательной плоскости, не подтверждает ходьбу, сложный контакт или динамику привода, и пишет это сам.

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

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

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

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

Lanțul unui robot, de la stânga la dreapta, cu starea reală a fiecărei verigi. Vedere: prototip pe cameră fixă, un singur comit, fără teste. Auz: gol — nimic construit pentru un microfon pe o mașină care se mișcă. Decizie și cinematică: verificat, cu 8.400 de puncte rezolvate și cu o poartă care blochează atunci când o constantă nu e calibrată. Ultima săgeată, cea către motoare, e întreruptă: niciun cod al nostru nu are transport către hardware. Desenul e făcut ca să se vadă unde se oprește serviciul, nu ca să pară complet.

Данные

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

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

Камера робота снимает людей, и это меняет все: Модуль зрения, который обнаруживает и отслеживает людей, производит персональные данные в прямом смысле этого слова, даже если никто не идентифицируется по имени. Вопросы задаются до первой строки кода: сохраняется ли изображение или только результат, где оно обрабатывается, у кого есть доступ к записям, как долго они хранятся, что показывается тем, кого снимают. Наш прототип был построен как технический эксперимент, а не как введенная в эксплуатацию система, и мы не предлагаем его как таковой.
На устройстве или на сервере — решение по задержке, а не по предпочтению: Если изображение должно дойти до решения о движении, путь до сервера и обратно напрямую входит в бюджет реакции. Если результат только отображается или записывается, сервер приемлем. Решение принимается по бюджету задержки, измеренному на вашем случае, и записывается. Наш прототип принудительно работает на процессоре, что является реальным ограничением по скорости, отмеченным в коде.
Симуляции сохраняются с 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` nu e un sistem de vederehttps://vision.megapromoting.com · 2026-09-06

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

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

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

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

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