Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ATEC2026 L0 Task E: правила, физическая конфигурация и текущая проблема захвата

Дата обновления: 04.06.2026 Рабочий каталог: $PROJECT_ROOT

1. Главное

  1. Мы отлаживали именно задачу ATEC-TaskE-Piper из официального симуляционного пакета ATEC2026 — захват со стола. Это не задача L1 с ногами или колёсно-ногим шасси и не пользовательский манипулятор.
  2. Локальная физическая конфигурация в основном взята из официального репозитория: Isaac Lab v2.3.2, манипулятор AgileX Piper, три объекта в духе YCB, стол, корзина, фиксированные RGB-D наблюдения и RGB-D наблюдения с концевого эффектора. Трение и параметры решателя для Piper, объектов и пола можно проверить в исходном коде.
  3. «Предмет сжат, но соскальзывает» нельзя свести к одной ошибке, которую можно отнести на Isaac Sim. Точнее: физическая конфигурация официального пакета чувствительна к захвату двухпалым захватом за счёт трения, а наш примитив захвата в стиле GraspGen/PCA в отправке по-прежнему полагается на удержание трением для такого не выпуклого изогнутого объекта, как банан. Поэтому любое отклонение точки между пальцами, высоты закрытия, раскрытия захвата, высоты переноса или скорости приводит к кратковременному подъёму и последующему соскальзыванию.
  4. Изменить физические параметры среды оценки нельзя для отправки. Повышение числа итераций решателя, трения и параметров контакта допустимо как локальная диагностика, но финальная отправка должна работать в официальной среде судьи через наблюдения и выходные действия demo/solution.py.
  5. Текущая самая сильная базовая линия для развёртывания — ACT/XSA в demo/solution.py. demo/solution_pca.py — экспериментальная ветка; её нельзя ставить вместо развёртывания, пока на нескольких seed для трёх объектов она стабильно не превосходит ACT/XSA.

2. Загруженные и сверенные официальные материалы

Мы загрузили снимок официального README на GitHub:

04.06.2026 мы дополнительно сверили свежий клон официального репозитория, временный каталог:

  • /tmp/ATEC2026_Simulation_Challenge_official_check
  • HEAD официального репозитория: dbe7c251f680b02f357a6db67430b18d3ba45ea1
  • последний коммит: dbe7c25 2026-06-04 10:10:16 +0800 Merge pull request #8 from atecup/fix/tron2a_joint_configuration

Итоги сверки:

  • Для файлов, которые сильно влияют на физику захвата в Task E, локальная и свежая официальная версии совпадают по SHA:
    • source/atec_rl_lab/atec_rl_lab/assets/robots/piper.py
    • source/atec_rl_lab/atec_rl_lab/assets/objects/task_b/object.py
    • source/atec_rl_lab/atec_rl_lab/tasks/task_e/terrain.py
    • source/atec_rl_lab/atec_rl_lab/tasks/task_e/mdp/rewards.py
    • source/atec_rl_lab/atec_rl_lab/tasks/task_e/mdp/terminations.py
  • В source/atec_rl_lab/atec_rl_lab/tasks/task_e/env_cfg.py различаются только имена полей группы действий: в свежей официальной версии joint_leg / joint_wheel / joint_arm, у нас joint_pos_leg / joint_vel_wheel / joint_pos_arm. Объекты Task E, корзина, камеры, случайный разброс по Y, логика награды и завершения, а также физический материал совпадают.
  • В source/atec_rl_lab/atec_rl_lab/tasks/task_base/envs_base_cfg.py есть два различия: имена полей группы действий и диапазон случайности сброса суставов базы — в официальной версии (1.0, 1.0), у нас (0.5, 1.5). Для Piper в Task E в TaskEEnvPiperCfg соответствующие события сброса отключены, поэтому эта разница не объясняет соскальзывание банана.
  • demo/server.py в свежей официальной версии добавил интерфейс /get_action_spec; в нашем сервере его пока нет. Он влияет лишь на то, может ли участник задать режим, масштаб и ограничение действий в сервисе отправки, но не меняет физику официальной симуляции.
  • demo/Dockerfile у нас переделан под шаблон отправки ACT/XSA, а в официальной версии по умолчанию используется пример solution_zero.py. Это наш выбор образа отправки, а не различие физической среды.

Тем же днём мы повторно проверили официальные обновления и issues/PR:

  • После git fetch origin origin/main по-прежнему указывает на dbe7c251f680b02f357a6db67430b18d3ba45ea1; более новых коммитов после 04.06.2026 10:10:16 нет.
  • Поиск по issues/PR на GitHub не нашёл открытых issues о Task E / Piper / захвате / физике / трении / соскальзывании банана.
  • По запросу Piper находится PR #2: конфигурация камеры eye-in-hand для B2Piper/B2WPiper/G1; это не фиксированный Piper из Task E и не про соскальзывание захвата.
  • PR #5 — спецификация действий для участника; PR #8 — ошибка конфигурации суставов Tron2A при сбросе, к физике захвата в Task E отношения не имеет.
  • Мы синхронизировали единственную безопасную правку совместимости: в локальный demo/server.py добавлен официальный endpoint /get_action_spec. Если решение его не реализует, возвращается {}, то есть используется стандартная конфигурация действий.

Локальный readme.md немного отличается от официального raw README: в новой версии официального README описан необязательный интерфейс AlgSolution.get_action_spec(). Текущий локальный файл по-прежнему подходит для запуска кода, но перед отправкой нужно проверить, не включил ли организатор новый интерфейс.

Кроме того, в материалах, которые ранее предоставил пользователь, указано:

  • L0 Task E: на столе случайно раскладываются три разных типа предметов, стол-манипулятор выполняет распознавание, захват и укладку в указанную зону.
  • Основной процесс: распознавание, планирование, захват, укладка.
  • Проверка кода: образ с лучшим результатом должен быть воспроизводимым и соответствовать правилам; технический отчёт должен описывать идею реализации, структуру кода и порядок выполнения; при использовании открытых моделей нужна ссылка на загрузку, при обучении собственных моделей — код обучения и источники данных.
  • На этапе предсказания разрешено использовать только код и модели из загруженного образа; поиск по тестовому набору и внешние сведения запрещены.

3. Что официальный README требует для Task E

Официальный README указывает, что репозиторий содержит симуляционные ассеты, определения задач и скрипты отправки, а среда основана на Isaac Lab. Для Task E в таблице окружений указан ATEC-TaskE-Piper. Источники:

  • readme.md / официальный README: Task E использует ATEC-TaskE-Piper.
  • readme.md: версия, на которой разрабатывалась и тестировалась среда, — Isaac Lab v2.3.2.
  • readme.md: участник обязан реализовать demo/solution.py с классом AlgSolution, основная функция — predicts(obs, current_score), возвращает {"action": action, "giveup": False}.

Текущий набор файлов отправки в локальном demo/Dockerfile:

  • demo/Dockerfile копирует solution_act.py в образе как solution.py и добавляет policy_act.pt.
  • Это значит, что образ отправки по умолчанию по-прежнему ACT/XSA, а не PCA/AnyGrasp.
  • Если позже переключаться на GraspGen-style/PCA, сначала нужно изменить целевой файл копирования в Dockerfile и провести стабильную оценку на нескольких seed.

4. Локальная оценочная логика Task E

Исходный код: source/atec_rl_lab/atec_rl_lab/tasks/task_e/env_cfg.py и source/atec_rl_lab/atec_rl_lab/tasks/task_e/mdp/rewards.py.

В локальной Task E есть два вида награды:

  1. grasped_objects_once: предмет подведён концевым эффектором и поднят над столом на определённую высоту; за каждый предмет выдаётся единоразово около 3 баллов.
  2. objects_in_basket: предмет попал в зону успеха корзины; за каждый предмет выдаётся единоразово около 3 баллов.

Поэтому теоретический максимум для трёх предметов обычно такой:

  • каждый из 3 предметов один раз «захвачен/поднят»: около 9 баллов;
  • все 3 предмета в итоге в корзине: около 9 баллов;
  • всего около 18 баллов.

Зона успеха корзины в исходном коде задана так:

  • центр успеха: BASKET_SUCCESS_CENTER = (1.08, -0.30, TABLE_TOP_Z + 0.15)
  • полуширины по XY: half_x = 0.20, half_y = 0.11
  • диапазон по Z: TABLE_TOP_Z <= object_z <= TABLE_TOP_Z + 0.15

Это объясняет важный факт: если на видео видно, что предмет «однажды был схвачен», это приносит только баллы за захват и подъём; чтобы получить максимум, все три предмета должны стабильно оказаться внутри зоны успеха корзины.

5. Официальные и локальные физические параметры

5.1 Конфигурация манипулятора Piper

Исходный код: source/atec_rl_lab/atec_rl_lab/assets/robots/piper.py.

Ключевые параметры:

  • ассет робота: robot/piper/piper.usd
  • суставы: joint1 … joint8, где joint7/joint8 — два пальца захвата.
  • сенсоры контакта: activate_contact_sensors=True
  • неявный актуатор суставов: effort_limit=100.0, velocity_limit=100.0, stiffness=800.0, damping=80.0
  • решатель сочленений: solver_position_iteration_count=4, solver_velocity_iteration_count=0

Исходный код: source/atec_rl_lab/atec_rl_lab/tasks/task_e/env_cfg.py.

Начальное состояние Piper в Task E:

  • манипулятор закреплён с правой стороны стола: pos=(TABLE_CENTER_X + TABLE_HALF_X, TABLE_CENTER_Y, TABLE_TOP_Z)
  • в Task E для piper_cfg.spawn.rigid_props.disable_gravity = True
  • пальцы захвата в начальном состоянии раскрыты: joint7=0.035, joint8=-0.035

Низкое число итераций решателя, особенно velocity_iteration_count=0, не очень благоприятно для устойчивости контакта. Это не результат нашего кода захвата, а штатная конфигурация Piper в репозитории.

5.2 Конфигурация трёх объектов

Исходный код: source/atec_rl_lab/atec_rl_lab/assets/objects/task_b/object.py.

Три типа объектов:

  • object_1: 004_sugar_box.usd
  • object_2: 006_mustard_bottle.usd
  • object_3: 011_banana.usd

Общие физические параметры:

  • rigid_body_enabled=True
  • kinematic_enabled=False
  • linear_damping=2.0
  • angular_damping=4.0
  • max_depenetration_velocity=0.5
  • mass=0.5
  • contact_offset=0.01
  • rest_offset=0.0

Единая масса 0.5 кг для небольшого банана или коробки довольно велика, и это усложняет захват двухпальцевым захватом, который удерживает предмет трением.

5.3 Физический материал пола и стола

Исходный код: source/atec_rl_lab/atec_rl_lab/tasks/task_e/terrain.py.

Физический материал Task E:

  • friction_combine_mode="multiply"
  • restitution_combine_mode="multiply"
  • static_friction=1.0
  • dynamic_friction=1.0
  • restitution=0.0

Исходный код: source/atec_rl_lab/atec_rl_lab/tasks/task_e/env_cfg.py.

В __post_init__() Task E выполняет:

  • self.scene.terrain = TASK_E_TERRAIN_CFG
  • self.sim.physics_material = self.scene.terrain.physics_material
  • self.events.physics_material = None

Это значит, что в Task E отключена стандартная случайная рандомизация физического материала: трение фиксировано. Для отправки это хорошо: трение не меняется от запуска к запуску. Но для такой геометрии, как банан, фиксированное трение не гарантирует надёжного захвата.

5.4 Случайное расположение предметов

Исходный код: source/atec_rl_lab/atec_rl_lab/tasks/task_e/env_cfg.py.

Три предмета случайно размещаются в разных полосах по Y на столе:

  • object_1: Y в [0.25, 0.29]
  • object_2: Y в [0.14, 0.20]
  • object_3: Y в [0.03, 0.09]
  • X в [0.90, 1.10]

Это согласуется с нашей последующей работой с маской полос RGB-D и сегментацией по областям предметов; но в итоговой отправке нельзя читать корень объекта, позицию можно только оценивать по наблюдениям.

6. Почему банан «зажимается и соскальзывает»

Наиболее разумная текущая гипотеза — не «совсем нет модели захвата» и не «Isaac Sim полностью сломан», а совпадение нескольких факторов:

  1. Банан — изогнутый невыпуклый предмет с узкой локальной зоной контакта; если двухпальцевый захват касается только локальной кривой поверхности, возникает скольжение и перекатывание.
  2. Масса всех объектов установлена 0.5 кг; банан, таким образом, весит как коробка, и для захвата только трением это очень неудобно.
  3. Параметры решателя Piper position=4, velocity=0 не слишком сильно стабилизируют контакт. В документации NVIDIA/Isaac Sim и на форумах часто обсуждается, что двухпальцевый захват может соскальзывать и что приходится подбирать параметры контакта, решателя, трения или способ управления.
  4. Наш примитив отправки в стиле PCA работает только с RGB-D и проприоцепцией и не читает корень реального объекта. Если центр захвата, угол поворота или высота закрытия, оцененные по одноракурсному облаку точек, немного неверны, может возникнуть ситуация «пальцы сильно зашли, но нормаль контакта на пальцах недостаточна».
  5. Старые runner / сборщики иногда срабатывали успешно, потому что ближе к официальному скриптованному примитиву: использовали более точное состояние объекта, динамическое сервоуправление и реальную трассу центра пальцев. Эта возможность при переносе в наблюдение-только управление demo/solution_pca.py теряется.

Короче: дело не в том, что «усилие захвата недостаточно», а в совместном действии геометрии контакта, высоты закрытия, раскрытия захвата, траектории переноса и физических параметров контакта PhysX.

7. Можно ли менять физическую конфигурацию

Что допустимо

Можно выполнять локальную диагностику:

  • временно повысить число итераций решателя сочленений Piper, например position с 4 до 16, velocity с 0 до 4;
  • временно повысить трение объектов и захвата, проверить contact offset и rest offset;
  • такими экспериментами определить, связано ли соскальзывание в основном с чувствительностью решения контакта в PhysX.

Что не рекомендуется делать зависимостью отправки

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

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

8. Текущий статус решений

8.1 ACT/XSA

Текущая базовая линия для развёртывания — ACT/XSA:

  • Dockerfile сейчас копирует solution_act.py в solution.py отправки.
  • В прошлых оценках XSA final на seed 11/12/13 давала высокие баллы, но были и недетерминированные колебания.
  • Это самый зрелый маршрут образа, но пока нельзя сказать, что он стабильно даёт максимум.

8.2 pi0.5

pi0.5 пробовали в ветках на 20 и на 100 демонстрациях; сейчас результат слабый:

  • ветка на 20 демонстрациях: на seed 11/12/13 всё по 0.
  • ветка на 100 демонстрациях: на seed 11/12/13 примерно 0/0/6, среднее около 2.
  • основная проблема больше похожа на несоответствие адаптера или представления данных, чем на слабость самой модели pi0.5.

8.3 AnyGrasp

SDK AnyGrasp подключён и выполняет вывод, но есть ограничения лицензии и запрет на распространение:

  • как локальный генератор кандидатов захвата он очень полезен;
  • но если финальный образ отправки включает SDK или веса без права распространения, риск при проверке кода высок;
  • его идею кандидатов захвата можно перенять, но в итоге лучше получить воспроизводимый и распространяемый метод — геометрический / PCA / в духе GraspNet, — либо в техническом отчёте полностью описать законный источник и лицензию.

8.4 Геометрический захват PCA/AABB в стиле GraspGen

Это тот маршрут планирования захвата, который пользователь попросил сделать приоритетным:

  • object_1: в demo/solution_pca.py уже есть подтверждение успешного одиночного захвата на seed 11/12/13.
  • object_2: в runner есть подтверждение одиночного успешного захвата, но перенос в отправку в стиле submit ещё не завершён.
  • object_3: сейчас в отдельных сценах удаётся кратко поднять предмет, но на этапах середины, переноса и освобождения он всё равно соскальзывает, поэтому пока не достигнута стабильность для отправки.

Нельзя утверждать, что PCA/AABB уже даёт максимум. Это правильное направление, но проблему удержания банана при переносе и перенос object_2 в отправку нужно полностью решить.

9. Рекомендуемый дальнейший технический маршрут

  1. Не возвращаться к «только обучить ACT/pi0.5» как к чёрному ящику; сохранить ACT/XSA как нижнюю границу отправки и параллельно развивать GraspGen-style/PCA как путь к более высокому баллу.
  2. Для object_3 вести две ветки:
    • локальная диагностика с физическим усилением: повысить число итераций решателя и проверить, перестаёт ли предмет сразу соскальзывать, чтобы подтвердить чувствительность контакта к решателю;
    • исправление, допустимое для отправки в официальной физике: низкий перенос, подгребание снизу, сокращение чисто вертикального подъёма над высотой, медленное удержание контакта при движении к центру корзины, раскрытие пальцев только после стабилизации над центром корзины.
  3. Для object_2 отдельно перенести успешные параметры runner и не применять компенсации, предназначенные для object_1 / object_3.
  4. Все подтверждения успеха записывать по нескольким seed: как минимум 11/12/13, лучше ещё 21/22/23.
  5. Перед переключением Dockerfile на новый маршрут должны выполняться условия:
    • три предмета в одном эпизоде стабильно дают около 18 баллов или 18 баллов;
    • есть видеодоказательство;
    • решение не читает состояние корня среды или объекта;
    • не зависит от весов AnyGrasp SDK, которые нельзя распространять, либо юридическая сторона полностью описана;
    • в техническом отчёте объяснены модель, алгоритм, открытые ссылки, а также обучение или отсутствие обучения.

10. Ссылки

11. Памятка для команды

  1. Не отправляйте demo/solution_pca.py как итоговое решение: это экспериментальный контроллер.
  2. Не включайте SDK AnyGrasp в финальный образ, пока лицензия, технический отчёт и проверка воспроизводимости не подтверждены.
  3. Не меняйте официальные физические параметры и не утверждайте, что результат воспроизводим в онлайне: изменения физики нужны только для поиска причин.
  4. Настоящий путь к максимальному баллу — связать в одну стабильную траекторию: оценку центра по наблюдениям → управление по центру пальцев → закрытие → низкий перенос → стабильное раскрытие над центром корзины.
  5. Сейчас главная задача — соскальзывание банана при переносе, а не замена крупной модели.