2. Список проблем соревнования и решения

Этот список делит проблемы на четыре колонки: наблюдение, реальная причина, способ решения и границы проверки. Так мы не принимаем случайный одиночный успешный запуск за устойчивое решение.

2.1 Проблемы с пониманием задачи

Наблюдение: всё время ищем мусор, а в сцене яма, платформа и ящик

Причина: загружена Task D. Основа оценки Task D — переход через препятствия и толкание ящика, а не распознавание, захват и сброс мусора.

Решение: сначала зафиксируйте ID задачи, ID робота, размерность действий и события оценки, и только потом решайте, какой код смотреть. Логика целей-мусора, корзины и сброса входит в Task B.

Границы проверки: увиденный ящик ещё не означает, что Task D выполнена полностью. Нужно проверить положение по x, прохождение ямы, подъём на платформу, финиш и приращение оценки.

2.2 Проблемы с видом и «ничего не видно»

Наблюдение: viewer чёрный или на картинке нет ни робота, ни цели

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

Решение:

сначала воспроизвести одно окружение
потом включить cameras / viewer
потом сохранить один кадр RGB-D
потом проверить сцену глобальным viewer
и только затем смотреть поведение policy

При официальной отправке нужно разделять отладочный глобальный вид и камеры, которые policy разрешено использовать. Глобальный вид подходит, чтобы ответить на вопрос «создана ли цель», но не доказывает, что её можно подавать на вход policy.

2.3 Проблемы с оценкой

Наблюдение: робот двигается, но баллов всего 2.0

Причина: выполнение действия и событие оценки — разные вещи. Низкая оценка в Task D может означать лишь то, что робот пересёк первый порог по x, но этапы толкания, платформы или финиша ещё не выполнены.

Решение: при каждом rollout сохраняйте одновременно:

• временной ряд current_score;
• root pose робота;
• положение ящика и относительную дистанцию;
• состояние стадии;
• видео последних 5 секунд перед провалом.

Смотреть нужно не на то, «двигался ли робот», а на то, после какого события оценка растёт и почему следующее событие не срабатывает.

2.4 Проблемы с размерностями наблюдений и действий

Наблюдение: policy обучается, но при отправке ошибка shape или странные движения робота

Причина: размерность выхода policy при обучении, размерность действий официального интерфейса отправки и конфигурация робота не совпадают. B2Piper и B2wPiper нельзя смешивать, а 16D locomotion action нельзя передавать как 24D official action.

Решение: поставьте на границе развёртывания явный адаптер и проверяйте shape до входа в симуляцию:

assert action16.shape[-1] == 16
action24 = adapt_taskd_16d_to_official(action16)
assert action24.shape[-1] == 24

Небольшая референсная реализация — code/taskd_reference_adapter.py. Она показывает интерфейс и логику стадий, но не утверждает, что может заменить полноценную policy.

2.5 Проблемы контакта при толкании ящика

Наблюдение: робот подходит к ящику, но ящик сдвигается не туда, теряется или застревает

Причина: одна только команда прямой скорости не справляется с отклонением курса, меняющейся поверхностью контакта, замедлением у края ямы и выходом ящика из поля зрения LiDAR.

Решение: разбейте Task D на явные состояния:

approach_box
push_box
nav_platform
climb_finish
recover

Для каждого состояния задайте свои пределы скорости, блокировку курса, пороги расстояния до ящика и условия выхода. LiDAR нужен для оценки bearing/distance ящика, оценка по очкам подтверждает, действительно ли стадия завершена, а восстановление при застревании отступает назад, поворачивает или смещается боком, если оценка долго не растёт.

2.6 Проблемы обучения

Наблюдение: reward в обучении растёт, а официальная оценка не растёт

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

Решение: введите три уровня оценки:

1. Уровень элемента: shape наблюдений, адаптер действий, загрузка модели.
2. Уровень rollout: воспроизведение одного окружения, переключение стадий, видео и трасса оценки.
3. Уровень benchmark: фиксированные seed, несколько запусков, официальный оценщик или эквивалентная локальная оценка.

Меняйте за раз только одну переменную, сохраняйте лучший checkpoint и соответствующее видео. Не перезаписывайте известную отправляемую версию только потому, что у нового checkpoint меньше loss обучения.

2.7 Проблемы переноса публичных решений

Наблюдение: скопировали solution.py из другого репозитория, программа запускается, но ведёт себя неверно

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

Решение: переносите в таком порядке:

лицензия и upstream commit
  -> задача / робот / размерность действий
  -> ключи наблюдений и нормализация
  -> масштаб действий и порядок суставов
  -> регистрация окружения и checkpoint
  -> модульные тесты и smoke rollout
  -> сравнение нескольких запусков оценки

2.8 Разрыв между восприятием и манипуляцией в Task B

Наблюдение: YOLO узнаёт мусор, но робот не умеет его поднять или сбросить

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

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

perception_output
  -> target / objects_remaining / obstacles / bin / robot
  -> approach controller
  -> grasp controller
  -> carry controller
  -> release verifier

README восприятия у yma867 полезен как справка по интерфейсу, но его solution.py — явный заглушечный zero-action. Поэтому успешный тест зрения нельзя принимать за выполненный сбор мусора.

2.9 Проблемы публикации

Наблюдение: хочется целиком отправить в GitHub все тренировочные каталоги и внешние репозитории

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

Решение:

• GitHub: учебные материалы, лёгкий исходный код, шаблоны конфигураций, разбор проблем, лицензии и ссылки на зафиксированные версии;
• Hugging Face: веса моделей, отфильтрованные данные, полные снимки исходного кода, архивы логов и SHA256;
• Локально или на сервере: Isaac Sim, conda-окружения, кеши и необработанные промежуточные артефакты.

2.10 Шаблон записи проверки

Каждая официальная запись проверки должна содержать как минимум:

задача / робот / ID окружения
commit кода
SHA256 checkpoint
размерность наблюдений / размерность действий
версия GPU и Isaac Lab
num_envs / seed / iteration
трасса оценки (score trace)
путь к видео
достигнутая стадия
сбойная стадия и следующее изменение