2. Список проблем соревнования и решения
Этот список собирает типичные проблемы, с которыми мы столкнулись при понимании, отладке и публикации, в виде повторяемых путей диагностики.
2.1 Задача Task B ошибочно понималась как «просто подобрать мусор»
Наблюдение: поначалу задачу понимали как поиск координат объекта и переход в эту точку.
Причина: подзадачу навигации приняли за замкнутый цикл задачи; не было различия между «обнаружить цель», «подойти к цели», «захват успешен» и «размещение успешно».
Решение: использовать явный конечный автомат стадий: SEARCH -> LOCALIZE -> APPROACH -> REACH -> CLOSE -> LIFT_VERIFY -> CARRY -> PLACE_VERIFY. Каждая стадия фиксирует входы, действие, условие выхода и причину сбоя.
2.2 Предположение, что в симуляции есть глобальные координаты для прямого чтения
Наблюдение: навигация строилась на позах объектов из среды, списках объектов или истинных координатах.
Причина: внутри симулятора такие состояния действительно могут существовать, но это не значит, что они допустимы как observation для настоящей политики.
Решение: разделить истинную информацию на два канала:
debug_only: разрешено выводить истинное расстояние до цели, высоту объекта и состояние захвата для поиска причин сбоев;policy_input: только изображения, глубина, LiDAR и proprioception из официального observation.
Каждое поле, которое попадает в policy, регистрируется в configs/observation_contract.yaml. При официальных прогонах чтение истинных значений выключается, а интерфейс проверяется на обезличенном observation.
2.3 Добавление камеры окружения делает результат наглядным
Наблюдение: сторонний вид, с которого видна вся сцена, помогает понять, не отклонился ли робот от курса.
Причина: камера окружения — инструмент визуализации, а не официальный датчик робота. Если добавить её в observation, граница задачи меняется.
Решение: оставить камеру окружения третьей дорожкой для локального видео отладки, но не регистрировать её в observation policy, не записывать её изображения в обучающие данные и не использовать для вычисления целевых координат во время работы. Подробности — в разделе Камера окружения и отладочный вид.
2.4 Близко к цели, высокий показатель, но объект не унесён
Наблюдение: локальные показатели расстояния или касания улучшаются, на видео робот касается цели; но при перемещении к корзине объект не следует за захватом.
Причина: показатель контакта не равен успешному захвату. Касание может происходить корпусом, ногой, основанием захвата или полом.
Решение: добавить три независимых подтверждения:
- После закрытия захвата относительное расстояние между объектом и концевым эффектором стабильно сохраняется в течение некоторого времени.
- После поднятия концевого эффектора или основания высота объекта растёт вместе с ним, а не остаётся на полу.
- После выхода робота из зоны цели объект остаётся с захватом до момента освобождения над корзиной.
В журнале оценки одновременно сохраняются состояния контакта, удержания, подъёма и размещения; отчитываться одной только дистанцией запрещено.
2.5 Манипулятор исполняет команды, но поза нестабильна
Наблюдение: ходьба в норме, но рука дрожит, концевой эффектор смещён, захват задевает цель, или размерности действий перепутаны.
Причина: порядок суставов, масштабирование действий, нулевые положения, системы координат и определение концевого эффектора у разных проектов не совпадают, поэтому их нельзя переносить напрямую.
Решение: сначала провести аудит интерфейса действий, затем калибровку отдельных суставов и концевого эффектора:
- считать из официального окружения порядок и диапазон пространства действий;
- поочерёдно подавать малые воздействия на каждый сустав и проверять отклик в журнале;
- при неподвижной базе проверять, как меняется положение концевого эффектора;
- зафиксировать ноги и калибровать только манипулятор и захват, а потом подключать полное тело;
- переносить глубину цели из системы координат камеры в систему координат базы манипулятора и записывать версию внешних параметров.
2.6 Ошибочные выводы о политике из-за ошибок GPU или PhysX
Наблюдение: при параллельном запуске нескольких симуляций появляются сообщения PhysX kernel, CUDA context или early-state; результат потом считают провалом политики.
Причина: нехватка ресурсов, оставшиеся процессы, нехватка видеопамяти и поведение политики могут проявляться одновременно, и по последним строкам лога нельзя определить, что является причиной.
Решение: для каждого эксперимента записывать GPU, процессы, версии окружения, seed, runner и каталог вывода; сначала проводить smoke-тест одного процесса, и только потом увеличивать параллелизм. При аномалиях трогать только процессы, принадлежащие данному эксперименту, без общей «очистки». Ошибки запуска окружения и ошибки исполнения политики считать отдельно.
2.7 Можно ли напрямую переносить внешние проекты
Вывод: переносить структуру алгоритма, но не скрытые допущения.
Можно позаимствовать: визуальный поиск, сканирование на 360 градусов, иерархическую навигацию, фиксацию по концевой камере, полнотелую обратную кинематику, конечный автомат после захвата и журналирование результатов.
Нельзя копировать напрямую: URDF/USD робота, порядок суставов, внутренние и внешние параметры камер, размерности действий, категории целей, координаты карты, пороги награды и поля оценщика.
Для каждого переносимого элемента нужна таблица соответствия «интерфейс исходного проекта → интерфейс Task B», и она должна проходить проверку границ сенсоров.