Unitree G1: инференс на устройстве или в облаке?

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

Эта статья для инженеров, которые размещают на Unitree G1 зрение, планирование и модели действий.
Руководителям лабораторий она поможет оценить затраты на вычисления и поддержку.
Интеграторам — спроектировать режим, в котором сетевой сбой не лишает систему безопасного поведения.

Сначала разделите задачи по цене задержки

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

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

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

Можно ли использовать облачную обработку для модели зрения G1?
Да, если задача не требует немедленного воздействия на движение и локальная система способна безопасно пережить задержку, отсутствие результата или обрыв сети. Камеры могут передавать кадры или производные признаки, но прежде оцените объём данных, приватность и влияние отправки на рабочую сеть. Фиксированное число миллисекунд здесь было бы вводящим в заблуждение: фактическое время зависит от модели, кодирования, канала, очередей и способа возврата команды.

Сравните задержку по всей цепочке, а не только по модели

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

Разделите измерения по этапам. Записывайте время обработки внутри модели отдельно от полного времени «сенсор — решение — исполнительный механизм». Затем повторите тест при обычной нагрузке лабораторной сети и при её ухудшении. Среднее значение недостаточно: оно скрывает редкие, но опасные задержки. Смотрите распределение, включая верхние процентили, колебания времени ответа и случаи, когда ответ не пришёл вовсе.

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

Важно: проверяйте не только «обычную» задержку. Искусственно внесите потерю пакетов, рост джиттера и временное отключение сети. Если робот ждёт удалённый ответ, испытание должно показать, как он прекращает или ограничивает действие.

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

Оцените вычисления, обновления и стоимость владения

На устройстве вычисления доступны рядом с сенсорами и не требуют передачи каждого входа наружу. Обратная сторона — ограниченный набор аппаратных ресурсов и необходимость проверять, помещается ли конкретная модель вместе с остальными процессами. Замеряйте потребление памяти и вычислительной мощности под реальной нагрузкой, а не только на изолированном примере. Учитывайте конкуренцию с уже работающими компонентами, перегрев, перезапуск процесса и возможность восстановить систему после сбоя.

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

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

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

Защитите данные и предусмотрите отказ

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

Разделите полномочия для оператора, разработчика и сервиса мониторинга. Храните секреты вне исходного кода, ограничьте доступ к журналам и проверяйте, не попали ли в них изображения или токены доступа. Для защищённого транспортного соединения сверяйте настройки с рекомендациями RFC 9325 по использованию TLS и DTLS; сам факт включённого шифрования не решает вопросы авторизации и контроля хранения.

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

Публикацию NIST из предоставленного технического материала можно использовать как дополнительный источник при формировании анализа рисков. Не считайте её подтверждением совместимости с G1 или готовым проектом безопасности: архитектуру, угрозы и меры защиты должна проверить ваша команда в контексте площадки.

Выберите схему по условиям испытаний

Используйте следующие условия как развилку, а не как обещание совместимости:

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

Отметьте условия перед выбором

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

[ ] Я определил, влияет ли вывод модели на движение здесь и сейчас, а не только на план следующего действия.
[ ] Я измерил полный путь от сенсора до исполнения результата, а не только время работы модели.
[ ] Облачный вариант проверен при джиттере, потере пакетов, временном обрыве и восстановлении сети.
[ ] При недоступности сервиса робот переходит в заранее определённое безопасное локальное состояние.
[ ] Для передаваемых изображений, телеметрии и журналов определены цель, права доступа и срок хранения.
[ ] Проверены совместимость модели, интерфейсов и программной среды с фактической конфигурацией G1.
[ ] Локальный вариант или другой проверенный откат можно включить без возврата к непроверенной конфигурации.

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

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

Проведите сравнительный тест и сохраните откат

Порядок проверки для команды:

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

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

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

Итоговая схема может быть локальной, облачной для отдельных операций или двухконтурной. Выбирайте её после тестов, а не по обещанию «более мощного» удалённого оборудования. Если нынешняя лабораторная схема опирается только на локальную рабочую станцию, у неё могут быть ограничены совместный доступ, централизованное управление экспериментами и расширение ресурсов; если всё вынесено в облако — появляются зависимость от канала, передача данных и дополнительные требования к безопасному отказу. Аренда удалённого Mac через Hashvps может быть удобна для совместимой разработки и вспомогательных тестов, но не заменяет вычисления на G1 и не должна управлять реальным движением. Сначала распределите задачи по критичности, затем проверьте совместимость среды и только после этого оценивайте удалённый ресурс.