1. Определение задач и границы наблюдений

1.1 Сначала выравниваем названия задач

Публичный симуляционный репозиторий ATEC2026 объединяет несколько возможностей в одной рамке соревнования. Чаще всего путают задачи: увидев «робособаку, предметы и камеру», все начинают считать, что речь идёт о сборе мусора. На практике сначала нужно проверить ID задачи, конфигурацию робота и оценщик.

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

1.2 Управление в Task B и Task D устроено по-разному

Сбор мусора — это длинная последовательность loco-manipulation:

восприятие RGB-D
  -> класс цели, глубина и мировые координаты
  -> выбор ближайшей цели
  -> подход шасси и корректировка позы
  -> захват или толкание манипулятором / захватом
  -> перенос к мусорной корзине
  -> отпускание, подтверждение попадания в корзину, обновление прогресса

Толкание ящика ближе к «locomotion с событиями контакта»:

наблюдение за ямой, ящиком и платформой
  -> подход к ящику
  -> удержание курса и установление устойчивого контакта
  -> толчок или боковое воздействие, меняющее окружение
  -> преодоление ямы и платформы
  -> выход к финишу и переключение политики по стадиям оценки

Обе задачи могут использовать RGB-D и LiDAR, но события оценки, акценты в действиях и восстановление после сбоя полностью различаются. Политика ходьбы из Task A не превращается напрямую в контроллер захвата Task B, а конечный автомат толкания из Task D не решает ни распознавание цели, ни сброс мусора.

1.3 Границы наблюдений, заданные организаторами

Публичный официальный репозиторий организует наблюдения для A/B/D в основном так:

• состояние корпуса робота и состояние суставов;
• LiDAR height scan или эквивалентная наблюдаемая высота рельефа;
• головная RGB-D камера;
• RGB-D камера на концевом эффекторе;
• команды, история действий или информация о стадии, если они нужны задаче.

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

observation keys
observation shape
camera name
image resolution
depth scale
action dimension
action meaning
current_score semantics

Можно ли использовать глобальную камеру

Глобальную камеру можно использовать для офлайн-отладки, записи видео сверху, генерации разметки и проверки, действительно ли существует объект. Можно ли подавать её как официальный вход policy, зависит от того, разрешил ли регламент отправки этот сенсор в число допустимых наблюдений.

Если интерфейс отправки предоставляет только proprio, height scan, головную RGB-D камеру и RGB-D камеру на концевом эффекторе, то чтение мировых координат симуляции или дополнительной глобальной камеры внутри policy создаёт две проблемы:

1. Локальный rollout может проходить успешно, а в онлайн-отправке такого поля с тем же именем не окажется.
2. Размерность наблюдений при обучении не совпадёт с размерностью при развёртывании, и экспортированная policy не загрузится или будет вести себя неверно.

Рекомендуется разделить глобальную камеру по назначению:

• разрешённое использование: viewer, запись, офлайн-оценка, отладка генерации целей и проверка компоновки сцены;
• официальный вход: только те сенсоры, которые явно предоставляет официальный контракт наблюдений.

1.4 Порядок проверки сцены и камеры

Если после запуска симуляции ничего не видно, проверяйте по такому порядку:

1. Убедитесь, что загружена Task A, Task B или Task D, а не просто смотрите на название папки.
2. Проверьте, следует ли камера viewer за роботом или всё ещё стоит в начале координат мира.
3. Выясните, работает ли симуляция в режиме headless: в нём может быть только лог и видеозапись без интерактивного окна.
4. Проверьте начальную позицию робота и координаты целевой зоны, чтобы камера не оказалась за пределами целевой области.
5. Убедитесь, что сенсор RGB-D включён и что в наблюдениях действительно есть ключи image/depth.
6. Через глобальный viewer или офлайн-рендер подтвердите, что объекты созданы; не принимайте «не вижу» за «не создано».
7. Только после этого проверяйте материалы объектов, освещение, диапазон отсечения камеры и валидность значений глубины.

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

Типичный контракт действий выглядит так:

Реализация Task D в Logic-TARS использует 61D observation и 16D locomotion action, а затем через адаптер получает официальное 24D action. Суть такой конструкции в том, что обучение ходьбе отделяется от интерфейса официальной отправки, а размерности не подгоняются насильно.