Робот "оглох" и молчит об этом: как мы научили гуманоида замечать отказ микрофона
В предыдущем материале мы рассказывали, как создавали русскоязычный голосовой стек для китайского гуманоида Walker Tienkung TK2301 в лаборатории 361.Robotics: собственное распознавание речи, синтез голоса и логика диалога. Теперь разберём менее заметную, но не менее важную часть системы - получение аудио и контроль исправности микрофона.
Штатный микрофонный массив встроен в корпус робота. В документации производитель рекомендует оператору находиться примерно в полутора метрах перед машиной и обращаться к ней лицом. В реальной эксплуатации это неудобно: человек должен стоять почти вплотную, а робот может не услышать команду или неправильно её распознать. Кроме того, при работе с подвижной машиной такое положение не всегда безопасно.
Поэтому мы решили использовать внешний беспроводной микрофон. Оператор может закрепить его на одежде или держать в руке, свободно перемещаясь вокруг робота. На бумаге задача выглядела элементарно: подключить USB-приёмник, выбрать устройство ввода и передать аудио в существующий пайплайн. На практике замена источника заняла два полноценных дня и потребовала разобраться не только с подключением, но и с многочисленными промежуточными состояниями: устройство могло исчезнуть, зависнуть, продолжить отображаться в системе или восстановиться с другим именем.
Как устроена аппаратная схема
В Walker Tienkung TK2301 используются три бортовых компьютера. Первый, построенный на x86, отвечает за основные движения и выполняет роль периферийного хаба. Именно у него есть доступные снаружи USB-порты. Второй - плата Jetson, на которой работают зрение, языковая модель и голосовой контур. Третий компьютер занят навигацией и захватом объектов и в этой задаче не участвовал.
Наш голосовой пайплайн запускается на Jetson. На вход он принимает поток PCM-аудио, разбитый на небольшие чанки. Дальнейшие этапы - распознавание речи, генерация ответа и синтез - уже были готовы. Требовалось сохранить существующий интерфейс и заменить только источник аудиоданных: вместо встроенного микрофонного массива передавать звук с внешней радиосистемы.
Дополнительную роль играл пульт управления роботом. Один из его рычажков, условно обозначенный как E, мы назначили переключателем голосового режима. Когда оператор поднимал рычажок, робот начинал слушать; после опускания приём речи отключался. Заодно этот элемент управления запускал предусмотренные производителем движения, что оказалось полезным во время демонстраций.
Изначально мы хотели просто заменить штатный микрофон физически. Однако свободные USB-порты обнаружились только на компьютере, отвечающем за движение. Jetson, где работает голосовой код, не имеет выведенных наружу разъёмов. Получить к нему доступ можно было лишь после разборки корпуса, а рисковать рабочей машиной ради эксперимента не хотелось.
Так появилась распределённая схема: USB-приёмник подключается к x86-компьютеру, а аудиопоток затем передаётся по сети на Jetson. В качестве оборудования мы выбрали беспроводную петличную систему с USB-приёмником. Для операционной системы она выглядит как обычная USB-звуковая карта, поэтому отдельный SDK не требовался.
Подробное описание архитектуры голосовой части и практических особенностей интеграции доступно в материале о русскоязычном голосовом стеке для гуманоида. Здесь сосредоточимся на диагностике и отказоустойчивости аудиоканала.
Почему простое подключение не сработало
После подключения USB-приёмника устройство действительно появлялось в Linux. Однако его имя и индекс не были постоянными. При перезагрузке, переподключении или кратковременном сбое система могла назначить ему другой номер. Если программа открывала, например, `hw:2,0`, это не означало, что после следующего запуска под тем же индексом останется нужная звуковая карта.
Надёжнее оказалось использовать стабильные идентификаторы ALSA и проверять характеристики устройства: число каналов, частоту дискретизации и доступность записи. Но и этого было недостаточно. В ряде случаев устройство продолжало отображаться в списке, хотя реального аудио уже не выдавало.
Именно здесь возникла основная проблема: отсутствие ошибки ещё не означало наличие звука. Аудиопоток мог состоять из нулей, повторяющихся фрагментов или формально корректных, но бесполезных данных. С точки зрения операционной системы микрофон был "подключён", а с точки зрения робота - фактически оглох.
Мы добавили контроль самого сигнала. Периодически анализировались амплитуда, среднеквадратичный уровень и наличие изменений между последовательными блоками. Полная тишина в течение заданного интервала считалась подозрительной, но не всегда означала отказ: оператор мог действительно молчать. Поэтому диагностика стала многоуровневой и учитывала состояние голосового режима, активность петлички и факт недавнего переподключения.
Где появилась задержка
Отдельная сложность возникла при восстановлении соединения. Наивная реализация закрывала аудиопоток, заново искала устройство и создавала новый объект записи. Иногда весь процесс занимал около десяти секунд, хотя ожидалось не более двух. Для человека это воспринималось как зависание: рычажок уже поднят, а робот ещё не реагирует на обращение.
Причина скрывалась в нескольких тайм-аутах. Один относился к открытию устройства, другой - к сетевому каналу, третий возникал из-за попытки дождаться корректного завершения предыдущего потока. Последовательный запуск всех процедур многократно увеличивал суммарную задержку.
Мы разделили состояния "микрофон временно не отвечает" и "устройство действительно исчезло". При кратковременном сбое поток не пересоздавался полностью: система продолжала проверять восстановление и возвращалась к нормальной работе без перезапуска всего голосового контура. Полная инициализация выполнялась только после подтверждённого исчезновения устройства.
Полезно было также заранее ограничить длительность операций и вынести восстановление в отдельный управляющий цикл. Основной обработчик аудио больше не блокировался ожиданием USB или сети. Благодаря этому робот мог сообщить о проблеме, продолжить остальные действия и не зависать в неопределённом состоянии.
Почему робот путался в собственных подсказках
Сначала мы добавили голосовые сообщения вроде "микрофон отключён" и "ожидаю восстановления". Но вскоре выяснилось, что робот может сам отправить такую фразу в тот же звуковой тракт, который использовался для анализа активности. В результате собственная реплика воспринималась как внешний звук, а состояние системы менялось повторно.
Пришлось разделить внутренние события и пользовательскую речь. Синтезированный голос помечался как служебный, а проверка входного сигнала на время воспроизведения учитывала это состояние. Иначе система могла решить, что оператор что-то сказал, хотя в действительности робот просто озвучивал собственную диагностику.
Этот случай хорошо показывает, почему голосовой стек для робота нельзя строить как набор независимых функций. Распознавание, синтез, управление режимами и диагностика должны обмениваться состояниями. Иначе каждая подсистема формально работает правильно, но их комбинация создаёт неожиданные циклы.
Практические выводы
Внешний микрофон оказался полезен не только для повышения качества распознавания. Он увеличил дистанцию до робота, сделал демонстрации безопаснее и позволил оператору перемещаться без потери контакта. Но сама радиосистема не решила задачу автоматически: потребовались контроль сигнала, обработка переподключений и понятная модель состояний.
Тем, кто планирует купить гуманоидного робота или интегрировать в существующую платформу собственный робот с голосовым управлением, стоит заранее проверить, где физически подключается микрофон, на каком компьютере работает распознавание и как устройства идентифицируются после перезапуска.
На практике важны не только характеристики оборудования. Микрофон для робота должен стабильно определяться системой, а система распознавания речи для робота - уметь отличать тишину, временный сбой и полное исчезновение аудиоканала. Иначе даже дорогая периферия превращается в источник труднообъяснимых зависаний.
Ещё один вывод касается архитектуры. Голосовой интерфейс следует проектировать с учётом отказов с самого начала: предусматривать тайм-ауты, повторные попытки, резервные сценарии и понятные уведомления оператору. Чем сложнее робот, тем опаснее предположение, что USB-устройство либо работает, либо выдаёт ошибку.
В нашем случае именно одна беспроводная петличка заставила пересмотреть всю цепочку обмена аудио. Но результат оказался шире простой замены источника: робот научился замечать, что "оглох", не путать собственные подсказки с командами человека и восстанавливаться без длительной остановки голосового режима.
