Робот SO-101 достиг 90% точности: качество данных важнее сложности алгоритма

Разработчик Шерри Чен (Sherry Chen) за три недели прошла путь от неудачных попыток заставить робота SO-101 стучать по столу до успешного выполнения задачи «взять и положить» с точностью 90%. Ключевым фактором успеха стало не улучшение алгоритма Action Chunking Transformer (ACT), а радикальное изменение подхода к сбору данных и стабилизация аппаратного обеспечения. Опыт показывает, что в робототехнике качество обучающей выборки и надежность «железа» важнее сложности модели: при использовании 50 эпизодов обучения успех был невозможен, а после расширения датасета до 72 эпизодов с вариациями поворотов и позиций робот начал справляться с новыми условиями.

Аппаратные ловушки и ошибки настройки

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

Основные технические сбои, остановившие прогресс:

• Нестабильность USB-соединения: Две одинаковые веб-камеры постоянно отключались, так как система Ubuntu перепутывала их адреса. Это приводило к обрыву записи данных каждые 5 эпизодов.
• Сдвиг камер: Даже минимальное смещение положения камер между сессиями обучения и тестирования делало модель неспособной распознавать объекты, так как она «запомнила» конкретный ракурс.
• Потеря калибровки: Файлы калибровки манипулятора были сохранены во временной папке и утеряны после перезагрузки. Повторная калибровка без соблюдения нейтрального положения суставов привела к ошибочным командам сервоприводов.
• Конфликт драйверов: При высокой частоте опроса (30 Гц) мотор захвата не успевал отвечать, блокируя всю шину управления. Причина — чрезмерное усилие сжатия при ручном управлении, которое привело к износу мотора.

Важный нюанс: Проблемы с USB-адресацией идентичных устройств — это системный сбой, а не баг конкретного ПО. Решение требует настройки правил на уровне ядра (udev rules), привязывающих устройства к физическим портам, иначе автоматизация сбора данных невозможна.

Инженерия данных: как превратить хаос в результат

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

Ключевые изменения в процессе:

• Фиксация геометрии: Камеры и манипулятор были жестко закреплены скотчем и маркерами. Углы обзора изменены на «сверху и спереди» для лучшего контроля захвата.
• Стандартизация условий: Введены фиксированные параметры экспозиции и баланса белого, чтобы исключить влияние изменения освещения от дня к ночи.
• Формальное описание задачи: Введено понятие task_config, где явно прописаны типы блока, контейнера и стартовые координаты. Это позволило создать воспроизводимые тестовые сценарии.
• Стратифицированная выборка: Вместо случайного размещения блока использовались 6 зон (бинов). Для обучения использовались данные из 5 зон, а одна зона оставалась для проверки обобщающей способности модели (out-of-distribution).
• Оценка прогресса: Внедрена система баллов, оценивающая выполнение этапов (подход, захват, перенос, отпускание), а не просто факт успеха или неудачи.

Операционные последствия и тренды

На основе описанного опыта можно выделить практические выводы для внедрения подобных систем в реальные задачи.

• Зависимость от качества датасета: Модель ACT с весом 52 млн параметров не может компенсировать плохие данные. При обучении на 50 эпизодах без учета вариативности точность на новых позициях падала до 10%. Увеличение количества эпизодов до 72 с добавлением поворотов блока (от -45 до 45 градусов) подняло точность на неизвестных позициях до 75%.
• Риск аппаратных отказов: Высокая частота коммуникации (30 Гц) создает нагрузку на шину управления. Слабое звено (в данном случае мотор захвата) может блокировать работу всей системы. Это требует наличия запасных сервоприводов и ограничения максимального усилия в программном коде.
• Необходимость отладочной инфраструктуры: Стандартные инструменты визуализации часто не позволяют отследить синхронизацию кадров и позиций суставов. Разработка собственных скриптов для визуализации «сырых» данных критична для выявления причин сбоев.
• Человеческий фактор в обучении: Записи, сделанные с подглядыванием на манипулятор, содержат информацию, недоступную камерам. Это вводит модель в заблуждение. Обучение должно строиться исключительно на данных, доступных сенсорам робота.

Итоговые показатели и перспективы

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

• Точность на известных позициях (in-distribution): 90% успешных выполнений.
• Точность на неизвестных позициях (out-of-distribution): 75% успешных выполнений.
• Средний балл прогресса: 0.92 для известных и 0.8 для неизвестных сценариев.

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

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

Дальнейшие шаги включают установку камеры на запястье манипулятора для лучшего контроля захвата, расширение рабочей зоны и тестирование мультимодальных моделей (Vision-Language-Action) для повышения способности к обобщению.