Текущий приоритет — задача L0 Task E «Уборка стола» в $PROJECT_ROOT; не переключаться на L1, если пользователь не попросит.
2026-06-07 отправка через загрузку файла на сайт соревнования: XSA-ACT загружена, онлайн-балл 6.00, номер сборки BUILD2001385_2038204482147323904_20260607142442_bae481, задача «Уборка стола / Piper», время около 00:11:22.62. Предупреждение get_action_spec not found не было причиной снижения баллов; чтобы убрать его, в demo/solution_act.py и submissions/task_e_xsa_act_20260607_upload/solution.py добавлен метод get_action_spec(self): return None. Обновлённый solution.py, SHA256 a08790e7512c914e5b78132303e1c6098c8aba3b01a373933e6ddc617fa3a485.
2026-06-07 повторная проверка ветки PCA / захвата в стиле GraspGen для отправки: ATEC_PCA_OBJECTS=3,2,1, seed 11, demo/solution_pca.py отработал полные 5200 шагов и получил 0.00; журнал logs/pca_submit_eval/pca_submit_seed11_20260607.log, видео logs/videos/task_e_pca_submit_eval/pca_submit_seed11_20260607.mp4. Наблюдаемый сбой: центр захвата по RGB-D/PCA вычисляется, но IK и положение пальцев на стороне отправки длительно не успевают за желаемым центром пальцев; все три объекта (object3, object2, object1) в корзину не попали. Пока не использовать solution_pca.py как кандидат для гонки за рейтингом.
2026-06-07/08 подготовлены два пакета ACT seed2 для пробных отправок; оба сокращены до инференс-checkpoint (около 64 МБ) и проверены инициализацией AlgSolution(). submissions/task_e_act_seed2_45000_20260607_upload, SHA256 zip 4b5d1178db3060883db4400f24eaa04b11b259a5179a220a7a622d7347ea2895, SHA256 policy_act.ptd9badbf17b0f29000c4fb21c3a2a89f66f7450e3ec1cb7362e733f4a4a7a0cb2; историческая локальная оценка на seed11 — 18, на seed12 — 0; онлайн, по сообщению пользователя, 12.00. submissions/task_e_act_seed2_50000_20260607_upload, SHA256 zip 1d777cfa95ee40d92afafd70f5e3cbfd3ee6477f0b036ed9d459c94237858118, SHA256 policy_act.pt8ac243e8427c54704a0445fa8f0321450618fa6c2d2d7296db027c9c5fe1e2c9; историческая локальная оценка на seed11 — 15, на seed12 — 6; онлайн, по сообщению пользователя, 6.00. В обоих пакетах использован обновлённый solution.py с SHA a08790e... и act/detr/transformer.py без IPython, SHA fa290d.... Вывод: у checkpoint seed2 большой разброс, их нельзя считать стабильным решением на 18 баллов.
2026-06-08 подготовлен пакет-«лотерейный кандидат» из старого ACT seed1 best: submissions/task_e_act_seed1_best_20260608_upload, zip submissions/task_e_act_seed1_best_20260608_upload.zip, SHA256 zip e265ebe77b989a968cf4607ea70d4f3adc2322902538828b37fe84877f5b1391, SHA256 policy_act.pt282614de9673dc01e229557448e380b6a02c196b5c3953cec77b2aebd2305a8e, SHA256 solution.pya08790e7512c914e5b78132303e1c6098c8aba3b01a373933e6ddc617fa3a485. Источник — старый seed1 best (SHA резервной копии 76bbef2c81c85fc6cc60448476ff09075ec8bc97217c2d2fb70a3253fd3e307d); из него оставлены только norm_stats, model_args, ema_agent, проверена инициализация через AlgSolution(). Историческая локальная независимая оценка: run1 — 18, run2/run3 — 6; онлайн на тот момент ещё не отправлялся. Если пользователь сможет сделать ещё несколько попыток, это наиболее перспективный из уже собранных пакетов для следующей отправки.
2026-07-19 открытый архив после соревнования: репозиторий моделей https://huggingface.co/Datawhale/atec2026-task-e-act-seed1-best, загружены policy_act.pt и полный zip отправки; репозиторий данных и журналов https://huggingface.co/datasets/Datawhale/atec2026-task-e-reproducibility. Для воспроизведения обучения используются отфильтрованные HDF5: datasets/atec_task_e_obj321_servo_100demos/trajectory_filtered.hdf5, размер около 33 ГиБ, SHA256 4b85980e72b8e76261ad037bfba97b4795210e3f77cdb5b71479846b9230ac02; на HF файл разбит по 100 МиБ: data/final_100demos_filtered_split_100m/trajectory_filtered.hdf5.part-0000..0336, сопутствующие RESTORE_FILTERED_DATASET.sh, SHA256_FILTERED_ORIGINAL.txt, SHA256SUMS_FILTERED_SPLIT.txt. Загрузка шла через промежуточный каталог $DATA_ROOT/ATEC2026/hf_task_e_filtered_100m и пользовательскую службу atec-task-e-hf-filtered-100m-upload.service; скрипт $DATA_ROOT/ATEC2026/upload_task_e_filtered_100m_large_folder.py, HF_HUB_DISABLE_XET=1 и upload_large_folder(num_workers=8) с докачкой. 2026-07-19 удалённая проверка пройдена: 337 из 337 фрагментов на месте, есть README.md, RESTORE_FILTERED_DATASET.sh, два манифеста SHA256 и архив журналов logs/task_e_logs_20260520_20260609.tar.zst. Промежуточный каталог загрузки можно очистить, но исходный trajectory_filtered.hdf5 сохраняется, если пользователь отдельно не подтвердит удаление.
2026-06-08 пользователь отправил task_e_act_seed1_best_20260608_upload/policy_act.pt на сайт соревнования, онлайн-балл 15.00; в тот день с отправками и баллами было напряжённо, пользователь сообщил, что осталась только одна попытка. Результат выше, чем у XSA онлайн (6), seed2_45000 онлайн (12) и seed2_50000 онлайн (6), и на данный момент это лучший онлайн-результат. Последняя отправка должна опираться на явное локальное свидетельство, что результат строго выше 15; иначе попытку не тратить.
Оценка рисков последней попытки, 2026-06-08: исторические логи показывают, что XSA final и seed2_50000 обычно укладывают object_2/object_3 в корзину, object_1 срывается; seed2_45000 на локальном seed11 укладывает все три объекта, но на seed12 все три срываются, а онлайн 12 говорит, что на скрытой оценке потерян как минимум один предмет. Ветка PCA / GraspGen-style для отправки на seed11 даёт 0; полный GraspNet/AnyGrasp не соответствует условиям стабильной отправки одним файлом в ближайшее время. Не использовать для последней попытки PCA/GraspNet, не прошедшие локальную оценку в стиле отправки.
Пробный гибридный вариант для последней попытки, 2026-06-08: собран submissions/task_e_act_seed1_hybrid_obj1_pca_20260608_upload; идея — сначала ACT seed1 / XSA выполняют первые два объекта, затем переключение на solution_pca.py с геометрической помощью только для object_1. Исправления инициализации: в каталог отправки скопирован solution_pca.py, добавлен URDF Piper third_party/Agilex-College/piper/handpose_det/models/modified_piper_without_camera.urdf, а поиск URDF в solution_pca.py переписан так, чтобы сначала смотреть в текущем каталоге отправки. Результат неудачный: гибрид на базе seed1-best, seed11, score=6.00, только object_3 в корзине, видео logs/videos/task_e_hybrid_eval/hybrid_obj1_pca_seed11_20260608.mp4; гибрид на базе XSA final с переключением на PCA после фиксированного шага ACT 1320, seed11 score=3.00, object_1/2/3 ни один не в корзине, видео logs/videos/task_e_hybrid_eval/hybrid_xsa_fixed1320_obj1_pca_seed11_20260608.mp4. В каталоге добавлен DO_NOT_SUBMIT.md; гибридный пакет не использовать для последней онлайн-отправки.
2026-06-08 вторая половина дня, отрицательные результаты при попытке поднять балл: созданы экспериментальные файлы demo/solution_hybrid_obj1_pca.py (переключение на PCA только для object_1 при current_score>=15) и demo/solution_dual_act.py (два ACT с синхронными наблюдениями, переключение на вспомогательную политику после порога score); оба пока не являются вариантами для отправки. logs/eval_task_e_hybrid_xsa_score15_obj1_pca_seed11_20260608.log — 0.00; logs/eval_task_e_hybrid_seed1best_score15_obj1_pca_seed12_20260608.log — 0.00; logs/eval_task_e_hybrid_seed1_95000_score15_obj1_pca_seed11_20260608.log — 0.00, видео logs/videos/task_e_hybrid_eval/hybrid_seed1_95000_score15_obj1_pca_seed11_20260608.mp4. Два ACT: logs/eval_task_e_dualact_seed1best_seed2_45000_switch12_seed11_20260608.log — 0.00; logs/eval_task_e_dualact_seed1_95000_seed2_45000_switch12_seed11_20260608.log при score=15, primary_steps=900 переключил на вспомогательную политику, но итог остался 15.00: object_1 вне корзины, object_2/3 внутри. Вывод: эстафета PCA / двух ACT после score=15 не довела object_1 до корзины; тратить на это последнюю попытку нельзя.
2026-06-08 дальнейшие границы гибрида для цели 18: trace seed11 для runs/.../seed1/checkpoints/95000.pt показывает: на шаге 300 score=6, на шаге 600 score=12, object_2/object_3 уже в корзине, object_1 всё ещё на столе; лог logs/trace_task_e_seed1_95000_seed11_20260608.log. На этом основании проверено score=12 + min_act_policy_steps=600 с переключением на PCA для object_1: logs/eval_task_e_hybrid_seed1_95000_score12_step600_obj1_pca_seed11_20260608.log всё равно 15.00, object_1 в итоге (0.988,0.336,0.872) — вне корзины, object_2/3 внутри; с включённым старым rescue для object_1 logs/eval_task_e_hybrid_seed1_95000_score12_step600_obj1_pca_rescue_seed11_20260608.log откатился до 12.00 и переключения hybrid не произошло. В demo/solution_hybrid_obj1_pca.py добавлен явный подсчёт шагов окружения ATEC_HYBRID_FORCE_ENV_STEPS и печать причины переключения, чтобы не зависеть только от внутренних _ts / callback score у ACT; в demo/solution_pca.py добавлена экспериментальная точка входа ATEC_PCA_OBJ1_DIRECT_RESCUE=1 и исправлена явная ошибка в _build_object1_drag_rescue(): старое start_y=TABLE_CENTER_Y+0.085 при расположении object_1 в y≈0.26..0.34 давало пропуск со стороны передней части кубика; теперь дорожка строится динамически от текущего центра кубика с положительной стороной по y, а x дорожки тоже центрируется по текущему детектированию. Из-за очень высокой нагрузки на GPU / Isaac на машине в 16:15–16:45 2026-06-08 несколько eval с force-env не доходили до осмысленных шагов после запуска Isaac, поэтому их остановили вручную. Новые патчи direct-rescue не дали локального подтверждения выше 15 и не должны отправляться.
Развёртка checkpoint seed1, 2026-06-08: для runs/act-task-e-rgb-obj321-servo-100demos-seed1/checkpoints выполнен грубый отбор на seed11. Результаты: 35000=0, 45000=12, 50000=0, 55000=6, 65000=0, 70000=0, 75000=6, 80000=6, 90000=9, 95000=15, best_loss=0; логи logs/eval_task_e_seed1_*_20260608_sweep*.log. Расширенная проверка 95000.pt: seed12 — 6, seed13 — 6. Значит, 95000 не является более стабильной заменой, чем текущая онлайн-версия seed1-best с 15. Лучший вариант по-прежнему уже загруженный онлайн task_e_act_seed1_best_20260608_upload с 15.00; 95000, dual или hybrid не отправлять.
2026-06-04 подготовлен документ для передачи дел: docs/atec2026-taske-rules-physical-configuration-and-submission-instructions-20260604.md; снимок официального README скачан в docs/sources/ATEC2026_Simulation_Challenge_official_readme_20260604.md. Вывод документа: текущая среда — официальная ATEC-TaskE-Piper / Isaac Lab v2.3.2; параметры solver Piper, масса объектов, трение и contact взяты из локального официального исходного кода; соскальзывание банана больше похоже на проблему удержания двухпальцевым захватом и примитива отправки, а не на что-то, что можно исправить изменением физики у судьи; физические усиления годятся только для диагностики.
2026-06-04 fresh clone официального репозитория в /tmp/ATEC2026_Simulation_Challenge_official_check, HEAD dbe7c251f680b02f357a6db67430b18d3ba45ea1. Итог сверки: piper.py, object.py, terrain.py Task E, rewards.py, terminations.py совпадают с локальными по SHA; в task_e/env_cfg.py различаются только имена полей групп действий; логика объектов, корзины, камер, полос Y и physics material совпадает. Свежая официальная версия добавила в demo/server.py интерфейс /get_action_spec и пример пользовательского action; это опциональная настройка интерфейса действий, а не разрешение менять физику судьи.
2026-06-04 повторный git fetch origin официального репозитория: origin/main по-прежнему dbe7c25, новых коммитов нет. Проверка GitHub issues/PR: не найдено открытых issues про Task E / Piper / захват / физику / трение / соскальзывание банана; по запросу Piper найден PR #2 — eye-in-hand camera для B2Piper/B2WPiper/G1, не Piper из Task E; PR #5 — спецификация действий для участников; PR #8 — конфигурация суставов Tron2A. Синхронизировано единственное безопасное совместимое исправление: в локальный demo/server.py добавлен официальный endpoint /get_action_spec; если у решения нет этого метода, возвращается {}, то есть используется конфигурация действий по умолчанию.
Официальный робот для Task E — ATEC-TaskE-Piper; новые модели Tron2AWheel / Tron2ALegged к этой задаче стола не относятся.
Сводка разбора, 2026-05-30:
Текущий вывод: развёртываемая база по-прежнему XSA-ACT demo/policy_act.pt, SHA256 c3eacae3f1b0ec8ccde9fdc05d680fff119cc2ca70e1f79e4ddd5610c4bbfa93. Это не стабильное решение на максимум, но локальные свидетельства всё равно сильнее, чем у ACT seed2, GraspNet/SAM3 с прямым управлением и веток pi0.5/OpenPI. Не заменять demo/policy_act.pt текущим checkpoint pi0.5.
Идентификация робота и задачи: Task E использует ATEC-TaskE-Piper; среда зарегистрирована в source/atec_rl_lab/atec_rl_lab/tasks/task_e/__init__.py, конфигурация Piper — TaskEEnvPiperCfg / PIPER_CFG. Piper — линейка манипуляторов AgileX (Songling); эта задача — настольный стационарный Piper, а не колёсно-ногий или ногоходящий робот Tron/Unitree из L1.
Основная линия генерации данных: официальный / исходный скриптованный оракул для object_3 работает относительно неплохо, а для object_1 / object_2 не работает. Корень не в камерах, а в несоответствии геометрии USD / корня (центра), TCP захвата Piper, реальной геометрии контакта пальцев и примитивов переноса и сброса. В итоге с калиброванными примитивами по каждому объекту и замкнутым сервоуправлением получены успешные данные по всем трём объектам 3 2 1. Основной каталог данных — datasets/atec_task_e_obj321_servo_100demos, отфильтрованный HDF5 — datasets/atec_task_e_obj321_servo_100demos/trajectory_filtered.hdf5.
Основная линия ACT seed1: после обучения обычного ACT на этих 100 демонстрациях первая оценка провалилась из-за ошибки понимания действия в фазе home в demo/solution_act.py: действие Task E равно (joint_target - default_joint_pos) / 0.5, а не скорость или дельта PD. После исправления действия home обычный ACT даёт частичные успехи, но best_loss.pt / final.pt нестабильны, loss обучения слабо связан с успешностью задачи. Старый seed1 best сохранён как demo/policy_act.seed1_best_backup_20260522_012719.pt.
Основная линия XSA-ACT: xsa_update_20260520/lerobot_policy_act_xsa.zip, который предоставил пользователь, — плагин LeRobot act_xsa; исходный пример не запускается напрямую на ATEC 8D Piper. В source/atec_rl_lab/atec_rl_lab/train/act/act/detr/transformer.py и demo/act/detr/transformer.py добавлена адаптация --use_xsa; scripts/act/train_task_e.py сохраняет model_args, а demo/solution_act.py может автоматически загрузить use_xsa из checkpoint. Прямая независимая оценка XSA final по seeds 11/12/13 дала 15/15/15; логи logs/eval_task_e_xsa_final_seed11_recheck.log, logs/eval_task_e_xsa_final_seed12_recheck.log, logs/eval_task_e_xsa_final_seed13_recheck.log; однако при повторной проверке после развёртывания были колебания: seed11 — 9, seed12 — 0 (контакт и недетерминизм). Всё равно это самая сильная развёртываемая база.
Основная линия ACT seed2 / resume: seed2 обучен с нуля и с поддержкой возобновления; изменения в scripts/act/train_task_e.py и scripts/act/run_task_e_pipeline.sh, поддерживаются --resume_checkpoint / --resume_iter, RESUME_CHECKPOINT / RESUME_ITER, сохраняются optimizer / scheduler / EMA. Во время seed2 отдельные промежуточные snapshot выглядели сильными, например 45000.pt на seed11 — 18, а на seed12 — 0; final.pt на seed11 — 0, best_loss.pt на seed11 — 9. Вывод: seed2 не развёртываем, и одиночный высокий результат на одном seed нельзя считать надёжным доказательством.
Основная линия GraspNet / TunTunClaw: референс TunTunClaw от OpenClaw / Datawhale, предоставленный пользователем, подключён в third_party/tuntunclaw/; checkpoint GraspNet — third_party/tuntunclaw/temp/logs/log_rs/checkpoint-rs.tar; мостовые скрипты scripts/graspnet_task_e/tuntun_adapter.py и scripts/graspnet_task_e/run_graspnet_pick.py. Зависимости настроены в $HOME/envs/genmanip-isaac5-py311/bin/python, включая open3d==0.19.0, локальный graspnetAPI, transforms3d==0.4.2, расширение CUDA pointnet2 с TORCH_CUDA_ARCH_LIST=12.0 для Blackwell. GraspNet даёт кандидатов, но исходные кандидаты не решают контакт в реальном Isaac: object_3 удаётся взять при помощи SAM3 / GraspNet, реального пальца и поэтапного переноса; object_1 / object_2 на этапе переноса соскальзывают или смещаются. Как окончательный контроллер это не годится.
Основная линия SAM3: контрольная точка SAM3 находится в $HOME/Documents/01Proj/sam3d_gs/submodule/Prompt-Inpaint/checkpoints/sam3.pt, отдельный Python — $HOME/Documents/01Proj/sam3d_gs/.venv/bin/python; нельзя ставить его в окружение Isaac. Добавлен scripts/graspnet_task_e/sam3_segment_image.py для сегментации по текстовой подсказке RGB; run_graspnet_pick.py поддерживает --mask_provider sam3, --sam3_prompt, --basket_center_release. Важный вывод: сегментация SAM3 не главный узкий места — маски object_1/2/3 получаются правильно; ранние сбои были из-за выбора неверной маски среди нескольких кандидатов, позже это исправлено фильтрацией по мировой полосе и числу точек RGB-D. Настоящее узкое место — контакт захвата Piper и удержание при переносе.
Правила размещения GraspNet / SAM3: предложение пользователя «отпускать захват после стабилизации над центром целевой точки» — правильное направление. Добавлены логирование конца переноса, короткая выдержка для стабилизации, параметры --release_z, --basket_xy_tol, --basket_hold_steps, --basket_stable_steps, --basket_recovery_steps, --staged_transport, --transport_servo_fraction. Опыт: не держать долго в воздухе на большой высоте — предмет начинает проскальзывать и подпрыгивать; для object_3 лучше короткая стабилизационная выдержка. Для object_1 / object_2 всё ещё нестабильно: одной синхронизацией момента раскрытия не решить, нужно переделать примитив захвата и контакта.
Основная линия pi0.5 / OpenPI: репозиторий OpenPI — $HOME/src/openpi-ebench-clean, окружение — $HOME/envs/openpi-pi05, общая контрольная точка — $HOME/projects/robotics_shared/checkpoints/openpi/pi05-ebench-generalist/pi05_generalist/params. Обязательно задать HF_LEROBOT_HOME=$HOME/projects/robotics_shared/datasets/lerobot, HF_HOME=$HOME/projects/robotics_shared/hf_cache, PYTHONPATH=$HOME/src/openpi-ebench-clean/src:$HOME/src/openpi-ebench-clean/packages/openpi-client/src. Не запускать uv run внутри репозитория OpenPI: создастся огромный .venv и повторная загрузка.
Конвертация данных pi0.5: scripts/pi05/convert_task_e_hdf5_to_lerobot.py переводит 8D qpos/action из HDF5 ATEC в формат OpenPI с фиксированной базой 16D с дополнением: state/action.joints[:6] соответствует 6 суставам руки Piper, state/action.gripper[:2] — двум суставам захвата, остальное заполнено нулями; три камеры overlook/left/right пока записываются одним и тем же RGB-изображением 224x224. Основной набор данных: $HOME/projects/robotics_shared/datasets/lerobot/atec/task_e_obj321_servo_100demos_s5_224, около 4.7 ГБ, stride=5, fps=10.
Ключевое ограничение действий pi0.5: действия в HDF5 ATEC уже являются env action (joint_target - default_joint_pos) / 0.5, а не абсолютными qpos. Поэтому все конфигурации OpenPI для ATEC должны иметь extra_delta_transform=False. Если оставить стандартное преобразование дельты OpenPI, из состояния вычитается ещё раз, и цель обучения становится неверной.
Результаты обучения pi0.5: ветка на 20 демонстрациях pi05_atec_task_e_20demos_s5_224, 2k шагов, на seeds 11/12/13 все 0; checkpoint удалён, сохранены logs/pi05_eval_20260522074137 и видео logs/videos/task_e_pi05_eval/pi05_pi05_atec_task_e_20demos_s5_224_seed11_20260522074137.mp4. Основная ветка на 100 демонстрациях pi05_atec_task_e_s5_224, обучено 29999 шагов, checkpoint .../pi05_atec_task_e_s5_224/atec_task_e_pi05_s5_224_30k_20260522065716/29999 около 42 ГБ; оценка logs/pi05_eval_20260522112701: seed11 0, seed12 0, seed13 6, среднее 2.0; видео logs/videos/task_e_pi05_eval/pi05_pi05_atec_task_e_s5_224_seed11_20260522112701.mp4. Вывод: текущая ветка pi0.5 не развёртывается.
Вывод о причинах сбоя pi0.5: это не прямое доказательство «слабости модели pi0.5», скорее адаптер почти наверняка неверен. Текущий мост вставляет 8D действия ATEC Piper в фиксированную базу EBench 16D, все три камеры используют одно и то же изображение, подсказка грубая, данные только в стиле скриптованного оракула, а параметры оценки max_steps=1500 / action_repeat=5 не полностью эквивалентны траекториям ACT длиной 1800 шагов. Ещё одно сильное подозрение: в журнале загрузчика OpenPI discrete_state_input=True, а в открытом опыте посттренировки pi0.5 для Piper упоминается, что discrete_state_input=False помогает избежать насыщения токенов состояния при z-score нормализации. Если продолжать pi0.5, сначала нужна нативная конфигурация OpenPI / Piper, проверка q01/q99/norm stats, опробовать discrete_state_input=False, и рассмотреть сначала pi0, а не pi0.5.
Ветка pi0.5 — повторная проверка старой линии, 2026-06-08: перепроверены scripts/pi05/convert_task_e_hdf5_to_lerobot.py, demo/solution_pi05.py, config.py OpenPI и журнал обучения logs/pi05_train_task_e_s5_224_20260522065716.log. Старый конвертер дополнял 8D Piper до 12 суставов + 4 захвата в фиксированной базе EBench, где реальная рука в 0:6, реальный захват в 12:14, а остальные 8 действующих измерений EBench равны нулю; затем PadStatesAndActions(model_action_dim=32) дополняет до 32D. Журнал обучения подтверждает TokenizePrompt(... discrete_state_input=True), а три камеры head/hand_left/hand_right — одно и то же RGB-изображение 224. В исходных данных HDF5 нет NaN/Inf, действия действительно env action, а не абсолютный qpos; extra_delta_transform=False — верная настройка. Оценка logs/pi05_eval_20260522112701 показала: на seeds 11/12 все три объекта остаются примерно в исходной полосе по y, на seed13 в корзину попадает только object_1; значит, основной сбой похож на несоответствие моста воплощения / времени действия и входного распределения, а не на простое «соскальзывание при захвате». Рекомендации к перезапуску: сохранить action_dim=32 у generalist pi0.5 ради совместимости с предобученными весами, но добавить трансформацию, нативную для ATEC: реальные 8D state/action в первых 8 измерениях и выход только первых 8 измерений; задать Pi0Config(pi05=True, action_horizon=50, discrete_state_input=False); использовать одну реальную камеру с маской или реальные несколько камер, не подставлять одно изображение как три; сначала stride=1 или action_repeat=1/2; сохранять контрольные точки 1k/2k/5k/10k/15k и оценивать на фиксированных seed, и только потом решать, стоит ли долго обучать.
Ветка pi0.5 native8, 2026-06-08: добавлены scripts/pi05/convert_task_e_hdf5_to_lerobot_native8.py, demo/solution_pi05_native8.py, трансформация OpenPI $HOME/src/openpi-ebench-clean/src/openpi/policies/atec_piper_policy.py, а также конфигурации pi05_atec_task_e_native8_20demos_s1_224 / pi05_atec_task_e_native8_100demos_s1_224. Замысел: вход — реальный 8D qpos, выход — реальное 8D env action; внутри модели по-прежнему дополнение до 32D для совместимости с весами pi0.5; используется только одна реальная камера video.base_camera_view, левая и правая камеры запястий заменяются нулевыми изображениями с image_mask=False; discrete_state_input=False; stride=1 и action_repeat=1, чтобы старый stride=5 не портил временную структуру захвата. Скрипты: scripts/pi05/run_pi05_native8_20demos_smoke.sh, scripts/pi05/run_pi05_native8_100demos_prepare.sh, scripts/pi05/run_pi05_native8_eval_checkpoint.sh. Так как корневой раздел / остался примерно с 68 ГБ свободного места, данные LeRobot для native8 и активы / checkpoint OpenPI нужно писать в $DATA4_ROOT/01Proj/13atec/...; новые checkpoint по 42 ГБ больше не писать в $HOME/projects/....
Текущий запуск pi0.5 native8, 2026-06-08 22:30 CST: старый сервис atec-pi05-native8-20demo-smoke-20260608222155.service остановлен вручную из-за слишком медленной записи изображений при синхронизации; сервис atec-pi05-native8-20demo-smoke-20260608222519.service тоже остановлен, поскольку конвертация при stride=1 занимает примерно 1,5–2 часа и не подходит для предварительной проверки адаптера. Значения по умолчанию конвертера уже изменены на image_writer_processes=5, image_writer_threads=10. Сейчас запущен быстрый контрольный пользовательский юнит atec-pi05-native8-20demo-s2-smoke-20260608223030.service, который выполняет smoke на 20 демонстрациях native8 со stride=2: конвертация → статистики нормализации → обучение на 3k шагов → автоматическая оценка seeds 11/12/13; префиксы журналов logs/pi05_native8_convert_20demos_s2_224_*, logs/pi05_native8_norm_20demos_s2_224_*, logs/pi05_native8_train_20demos_s2_224_*, logs/pi05_native8_eval_20demos_s2_224_*; каталог данных $DATA4_ROOT/01Proj/13atec/robotics_shared/datasets/lerobot/atec/task_e_obj321_servo_20demos_native8_s2_224. Эта ветка — проверка адаптера, а не кандидат для отправки; оценка выполняется командой CONFIG=pi05_atec_task_e_native8_20demos_s2_224 ACTION_REPEAT=2 scripts/pi05/run_pi05_native8_eval_checkpoint.sh <checkpoint>. Чтобы потратить последнюю попытку на сайте соревнования, нужно, чтобы на seeds 11/12/13 локальная оценка заметно превосходила уже полученные онлайн 15.00.
Быстрая проверка pi0.5 native8, 2026-06-08 22:39 CST: конвертация 20 демонстраций со stride=2 всё ещё занимает около 50 минут, поэтому сначала вручную остановлен atec-pi05-native8-20demo-s2-smoke-20260608223030.service, добавлены pi05_atec_task_e_native8_4demos_s2_224 и scripts/pi05/run_pi05_native8_4demos_s2_sanity.sh, запущен atec-pi05-native8-4demo-s2-sanity-20260608223911.service. Эта ветка использует всего 4 демонстрации, stride=2, 1k шагов, затем автоматически оценивает seeds 11/12/13 с ACTION_REPEAT=2. Цель — быстро понять, работает ли мост действий native8, websocket OpenPI и rollout в Isaac так, что манипулятор движется к цели. Это не итоговый результат. Если видео полностью неподвижно или хаотично, сначала исправляем мост и нормализацию; если направление движений верное — возвращаем 20 и 100 демонстраций.
Результат sanity pi0.5 native8, 2026-06-08 23:15 CST: обучение 4-demo s2 завершено, loss снизился с 0.5766 до примерно 0.0405, но оценка на seeds 11/12/13 дала 0.00 во всех случаях; видео logs/videos/task_e_pi05_native8_eval/pi05_native8_pi05_atec_task_e_native8_4demos_s2_224_seed11_20260608231046.mp4, монтаж logs/videos/task_e_pi05_native8_eval/pi05_native8_4demo_s2_seed11_montage_20260608231046.jpg. На видео манипулятор в основном стоит у home. Офлайн-проверка действий: checkpoint 999 предсказывает действия на кадрах обучения; выходы не нулевые (амплитуда по многим измерениям около 1–3), значит websocket и денормализация в основном работают, но 4 примера слишком мало и траектории не обобщаются, поэтому это не основание для отправки. Этот checkpoint на 83 ГБ бесполезен и удалён; журналы, данные и видео сохранены.
Текущая контрольная проверка pi0.5 native8, 2026-06-08 23:19 CST: в конфигурациях native8 save_interval/keep_period изменены так, чтобы сохранялся только финальный checkpoint, чтобы промежуточные файлы по 40 ГБ не замедляли обучение. Заново запущен пользовательский юнит 20-demo s2 atec-pi05-native8-20demo-s2-smoke-20260608231948.service; скрипт scripts/pi05/run_pi05_native8_20demos_s2_smoke.sh выполняет: конвертацию 20 демонстраций stride=2 → статистику нормализации → 3k шагов обучения → автоматическую оценку seeds 11/12/13 с ACTION_REPEAT=2. Если результат всё ещё 0/0/0 или видео по-прежнему застревает у home, сначала не добавлять данные, а исправлять временную привязку действий / гейт home / мост; если есть явное движение и ненулевые баллы, тогда запускать 100-demo native8.
Результат pi0.5 native8 на 20 демонстрациях s2, 2026-06-09 00:42 CST: pi05_atec_task_e_native8_20demos_s2_224 обучен на 3k, минимальный loss около 0.0188; checkpoint $DATA4_ROOT/01Proj/13atec/openpi_atec_runs/checkpoints/pi05_atec_task_e_native8_20demos_s2_224/atec_task_e_pi05_native8_20demos_s2_224_3k_20260608231948/2999. Журнал оценки logs/pi05_native8_eval_20260609003633, сводка logs/pi05_native8_eval_20demos_s2_224_20260608231948.log; баллы на seeds 11/12/13: 6/0/0, среднее 2.00; на seed11 в корзину попал только object_3; видео logs/videos/task_e_pi05_native8_eval/pi05_native8_pi05_atec_task_e_native8_20demos_s2_224_seed11_20260609003633.mp4. Вывод: мост native8 уже даёт частично рабочую политику, но 20 примеров недостаточно, чтобы превзойти онлайн 15.00; отправлять нельзя.
Контрольный запуск pi0.5 native8 на 100 демонстрациях s2, 2026-06-09 00:46 CST: добавлена конфигурация OpenPI pi05_atec_task_e_native8_100demos_s2_224 (100 демонстраций, stride=2 / fps=25, discrete_state_input=False, 10k шагов, только финальный checkpoint, assets/checkpoints в $DATA4_ROOT/01Proj/13atec/openpi_atec_runs) и скрипт scripts/pi05/run_pi05_native8_100demos_s2_gate.sh. Запущен пользовательский юнит atec-pi05-native8-100demo-s2-gate-20260609004546.service; порядок: конвертация trajectory_filtered.hdf5 → статистика нормализации → 10k обучения → оценка seeds 11/12/13 с ACTION_REPEAT=2 PORT=8023. Префиксы журналов: logs/pi05_native8_convert_100demos_s2_224_20260609004546.log, logs/pi05_native8_norm_100demos_s2_224_20260609004546.log, logs/pi05_native8_train_100demos_s2_224_20260609004546.log, logs/pi05_native8_eval_100demos_s2_224_20260609004546.log. Последнюю попытку на сайте рассматривать только если локальные оценки по нескольким seed заметно превосходят онлайн 15.00.
Результат pi0.5 native8 на 100 демонстрациях s2, 2026-06-09 05:49 CST: конвертация завершена, 100 эпизодов / 84877 кадров; каталог данных $DATA4_ROOT/01Proj/13atec/robotics_shared/datasets/lerobot/atec/task_e_obj321_servo_100demos_native8_s2_224, около 3.9G; статистики нормализации записаны в $DATA4_ROOT/01Proj/13atec/openpi_atec_runs/assets/pi05_atec_task_e_native8_100demos_s2_224/atec/task_e_obj321_servo_100demos_native8_s2_224. Обучение на 10k завершено; checkpoint $DATA4_ROOT/01Proj/13atec/openpi_atec_runs/checkpoints/pi05_atec_task_e_native8_100demos_s2_224/atec_task_e_pi05_native8_100demos_s2_224_10k_20260609004546/9999 около 42G; loss снизился с 0.4456 до 0.009–0.013 к концу, но результат на задаче очень слабый. Журнал оценки logs/pi05_native8_eval_20260609054339, сводка logs/pi05_native8_eval_100demos_s2_224_20260609004546.log; баллы на seeds 11/12/13: 3/0/0, среднее 1.00; ни один объект в корзину не попал; видео seed11 logs/videos/task_e_pi05_native8_eval/pi05_native8_pi05_atec_task_e_native8_100demos_s2_224_seed11_20260609054339.mp4. Вывод: эта полная ветка native8-s2 на 100 демонстрациях не подлежит отправке и не должна тратить последнюю попытку на сайте; защищённый лучший результат — ACT seed1 best с 15.00 онлайн.
Вход и запуск LoRA для pi0.5 native8, 2026-06-09 09:51 CST: опираясь на опыт стороннего LoRA для Piper pi0.5 (Pantheon: 119 эпизодов одной руки Piper, discrete_state_input=False, 7500 шагов, пиковая LR 5e-5, LoRA сохраняет априорные знания), конфигурация OpenPI pi05_atec_task_e_native8_100demos_s2_224_lora исправлена до настоящего LoRA-гейта: paligemma_variant="gemma_2b_lora", action_expert_variant="gemma_300m_lora", явный freeze_filter=Pi0Config(...).get_freeze_filter(), num_train_steps=7500, peak_lr=5e-5, ema_decay=None, discrete_state_input=False. Пока в качестве загрузчика весов используется уже имеющийся $HOME/projects/robotics_shared/checkpoints/openpi/pi05-ebench-generalist/pi05_generalist/params, потому что локальный каталог pi05_base на машине не найден; это не полностью совпадает с режимом Pantheon «pi05_base без warm-start». Если ветка провалится, следующий шаг — скачать / проверить ветку gs://openpi-assets/checkpoints/pi05_base/params. Новый скрипт scripts/pi05/run_pi05_native8_100demos_s2_lora_gate.sh использует уже сконвертированные данные $DATA4_ROOT/01Proj/13atec/robotics_shared/datasets/lerobot/atec/task_e_obj321_servo_100demos_native8_s2_224 и готовые статистики нормализации, повторной конвертации нет; запущен пользовательский юнит atec-pi05-native8-100demo-s2-lora-gate-20260609095114.service; журнал обучения logs/pi05_native8_lora_train_100demos_s2_224_20260609095114.log, внешний журнал службы logs/atec-pi05-native8-100demo-s2-lora-gate-20260609095114.service.log, корень checkpoint $DATA4_ROOT/01Proj/13atec/openpi_atec_runs/checkpoints/pi05_atec_task_e_native8_100demos_s2_224_lora; после обучения автоматически выполняется оценка seeds 11/12/13 с ACTION_REPEAT=2 PORT=8024. Критерии не меняются: последнюю попытку на сайте тратить только при явном превосходстве локальных результатов по нескольким seed над онлайн 15.00; иначе защищаем ACT seed1 best.
Результат LoRA для pi0.5 native8, 2026-06-09 10:16 CST: atec-pi05-native8-100demo-s2-lora-gate-20260609095114.service завершён. Обучение на 7500 шагах прошло штатно, loss снизился с 0.4452 до примерно 0.013–0.019 к концу; финальный checkpoint $DATA4_ROOT/01Proj/13atec/openpi_atec_runs/checkpoints/pi05_atec_task_e_native8_100demos_s2_224_lora/atec_task_e_pi05_native8_100demos_s2_224_lora_7500_20260609095114/7499, около 8.6G. Автоматическая оценка с ACTION_REPEAT=2; журналы logs/pi05_native8_lora_eval_100demos_s2_224_20260609095114.log и logs/pi05_native8_eval_20260609101354; на seeds 11/12/13 все 0.00, ни один объект не попал в корзину; видео seed11 logs/videos/task_e_pi05_native8_eval/pi05_native8_pi05_atec_task_e_native8_100demos_s2_224_lora_seed11_20260609101354.mp4. Вывод: даже с параметрами Pantheon (скорость обучения / число шагов / discrete_state_input=False / заморозка LoRA) провал сохраняется; значит, текущая проблема в мосту native8, распределении данных или временной структуре действий, а не в LoRA. Эту ветку не отправлять и не тратить на неё последнюю попытку. Временный монитор-напоминание atec-pi0-5-native8-lora-gate-monitor удалён.
Диагностика провала LoRA pi0.5, 2026-06-09 10:30 CST: после проверки issue OpenPI #672 и карточки Pantheon конфигурация LoRA в части freeze_filter, ema_decay=None и discrete_state_input=False выглядит корректной; выборка офлайн с num_steps=10/25/50 существенно не улучшает ошибку на обучающих кадрах, значит дело не только в малом числе шагов ODE. Добавлена переменная окружения ATEC_PI05_CHUNK_EXEC_STEPS в demo/solution_pi05_native8.py (по умолчанию по-прежнему 50, старое поведение не меняется). Тест ATEC_PI05_CHUNK_EXEC_STEPS=5 на seed11 дал по-прежнему 0.00; видео logs/videos/task_e_pi05_native8_eval/pi05_native8_lora_chunk5_seed11.mp4; значит, дело не просто в длинном открытом цикле из 50 шагов. Более вероятная первопричина: обучающие данные pi0.5 взяты из trajectory_filtered.hdf5, в котором scripts/act/filter_demos.py удаляет статичные / удерживаемые шаги; для 100 демонстраций число кадров снизилось с 749560 до 169700, то есть удалено примерно 77%. У необработанных данных медиана разности qpos 1.5e-5, у отфильтрованных — медиана 0.00936, максимум 0.419; это ломает временную семантику 50-шагового action chunk в OpenPI / pi0.5. Есть и второе подозрение: state — абсолютный qpos, а action — env action ATEC (target-default)/0.5, что не совпадает с распространённой в открытых Piper-данных LeRobot семантикой joint-position action. Поэтому для pi0.5 приоритет — необработанные данные + абсолютная цель суставов в качестве action, а на выходе преобразование обратно в env action.
Проверка pi0.5 rawabs / expert действий, 2026-06-09 12:30 CST: по предыдущему выводу реализована проверка на необработанных данных с абсолютной целью действия. Ключевые изменения: scripts/pi05/convert_task_e_hdf5_to_lerobot_native8.py поддерживает --action_mode absolute_target и --max_frames_per_episode; $HOME/src/openpi-ebench-clean/src/openpi/policies/atec_piper_policy.py поддерживает AtecPiperOutputs(action_mode="absolute_target"), при выводе переводит абсолютную цель суставов модели обратно в env action ATEC; demo/solution_pi05_native8.py по умолчанию использует ATEC_PI05_CHUNK_EXEC_STEPS=10, добавлены необязательные ATEC_PI05_ZERO_NOISE=1 и ATEC_PI05_ACTION_HORIZON. Набор из одной демонстрации: $DATA4_ROOT/01Proj/13atec/robotics_shared/datasets/lerobot/atec/task_e_obj321_servo_rawabs_1demo_native8_s10_224 (сырой trajectory.hdf5, 1 эпизод, stride=10, 250 кадров, абсолютная цель действия).
Результаты pi0.5 rawabs, 2026-06-09: добавлены конфигурации pi05_atec_task_e_native8_rawabs_1demo_s10_224_lora_base_h10_2k, ..._aefull_h10_2k, ..._aefull_h10_10k_lr5 и скрипт scripts/pi05/run_pi05_native8_rawabs_1demo_s10_aefull_h10_10k_lr5.sh. aefull_h10_10k_lr5 стартует из локального pi05_base/params, обучает только action expert / action heads / time MLP, discrete_state_input=False, horizon=10, LR 5e-5, EMA выключена; checkpoint $DATA4_ROOT/01Proj/13atec/openpi_atec_runs/checkpoints/pi05_atec_task_e_native8_rawabs_1demo_s10_224_aefull_h10_10k_lr5/atec_task_e_pi05_native8_rawabs_1demo_s10_224_aefull_h10_10k_lr5_202606091220_aefull_h10_10k_lr5/9999 около 8.8G. Офлайн-проверка: средняя L2-ошибка первого действия и всего chunk у 2k — 1.51/1.65, у 10k улучшилась до 0.28/1.10; при фиксированном нулевом шуме примерно 0.22/0.87, но chunk всё ещё нестабилен. Реальный прогон Isaac, seed11: CHUNK_EXEC_STEPS=1 дал 0.00 (видео logs/videos/task_e_pi05_native8_eval/pi05_native8_pi05_atec_task_e_native8_rawabs_1demo_s10_224_aefull_h10_10k_lr5_seed11_20260609122037.mp4); CHUNK_EXEC_STEPS=10 дал 0.00 (видео ..._20260609122341.mp4, монтаж ..._20260609122341.montage.jpg); CHUNK_EXEC_STEPS=10 + ATEC_PI05_ZERO_NOISE=1 по-прежнему 0.00 (журнал logs/pi05_native8_eval_20260609122748). Вывод: сервер OpenPI, денормализация и масштаб env action проверены как работающие, но политика не имеет непрерывной фазы вблизи домашней позы и наблюдений в высоком положении: действия колеблются между home и средней частью траектории, эффективного pick/place не возникает. Эта ветка rawabs тоже не годится как кандидат на последнюю отправку.
Стратегия данных pi0.5, 2026-06-08/09: пока не добавлять данные GraspGen/PCA. Причина: главная гипотеза по старому pi0.5 — рассогласование воплощения / временной привязки действий; если видео native8 полностью неподвижно, добавление данных только усилит ошибку. 20-demo native8 s2 уже дал на seed11 балл 6, поэтому сейчас проверяется 100-demo со stride=2 — это быстрее, чем stride=1, и сохраняет временную структуру захвата. Только если 100-demo native8 s2 останется ниже 15, добавлять данные: для LoRA / малого адаптера цель — 50–150 качественных демонстраций реальных наблюдений и действий; для полной / продолжающей донастройки — 300–500 демонстраций, покрывающих object_1/2/3, разные начальные позиции и порядок захвата. GraspGen/PCA можно использовать только как генератор данных-оракула или кандидатов; итоговые обучающие данные должны состоять из наблюдений соревнования и корректных 8D env action; при инференсе для отправки нельзя опираться на позу объекта оракула.
Инструменты оценки pi0.5: demo/solution_pi05.py — мост websocket; scripts/pi05/eval_task_e_pi05.py — точка входа оценки в Isaac; scripts/pi05/run_pi05_eval_checkpoint.sh <checkpoint> запускает scripts/serve_policy.py, прогоняет seeds 11/12/13, записывает видео для seed11; scripts/pi05/summarize_pi05_eval.py — сводка баллов; scripts/pi05/compare_pi05_vs_act_baseline.py сравнивает с базой XSA и выводит HOLD_ACT_XSA или REVIEW_FOR_DEPLOY. Для 100-demo ветки уже автоматически выводится HOLD_ACT_XSA.
Рекомендация по AnyGrasp на ближайший шаг: AnyGrasp / AnyGrasp SDK стоит попробовать как краткосрочное инженерное решение, но он не является «решением в одну кнопку» для всей политики. Рекомендуемая схема: маска SAM3 / априорная маска задачи ограничивает область облака точек цели; AnyGrasp выдаёт 6D-позу захвата и кандидатов без коллизий; затем IK и планирование траектории для Piper ATEC, контакт по реальному центру пальцев, короткая стабилизация с освобождением над центром корзины. Сначала проверить object_3, затем object_1 и object_2; запрещено использовать oracle-позу объекта или маску для итогового решения. Нужно дополнительно проверить лицензию AnyGrasp, источник весов модели и материалы для проверки воспроизводимости соревнования.
Попытка настройки AnyGrasp, 2026-05-30: официальный SDK клонирован в third_party/anygrasp_sdk; двоичные Python 3.11 файлы размещены в third_party/anygrasp_sdk/grasp_detection/gsnet.so и third_party/anygrasp_sdk/grasp_detection/lib_cxx.so. Python Isaac / обучения — $HOME/envs/genmanip-isaac5-py311/bin/python; наблюдаемое окружение: Python 3.11.15, torch 2.7.0+cu128, CUDA runtime 12.8, GPU NVIDIA RTX PRO 6000 Blackwell Workstation; работают open3d==0.19.0, graspnetAPI==1.2.11; pointnet2._ext импортируется только после import torch. SDK требует libcrypto.so.1.1; временно решено через OpenSSL 1.1 из комплекта ROS2 bridge Isaac: $HOME/projects/manipdojo2026/micromamba/envs/genmanip-sim/lib/python3.10/site-packages/isaacsim/exts/omni.isaac.ros2_bridge/humble/lib, при запуске этот путь добавляется в LD_LIBRARY_PATH.
Блокировка по лицензии / весам AnyGrasp, 2026-05-30, снята 2026-06-03: официальный SDK — лицензированный двоичный пакет, license_checker -f требует ifconfig; в системе нет ifconfig, добавлена совместимая обёртка tools/anygrasp/ifconfig. Текущий feature id машины 9024425463046318996. На 2026-05-30 не было ни licenseCfg.json, ни checkpoint_detection.tar, поэтому нельзя было утверждать, что AnyGrasp уже работает для захвата ATEC; 2026-06-03 лицензия и веса установлены, см. запись ниже.
MinkowskiEngine для AnyGrasp установлен, 2026-05-30: модифицированный MinkowskiEngine клонирован в third_party/anygrasp_sdk/dependencies/MinkowskiEngine, ветка cuda-12-1. В системе только GCC/G++ 13.3.0, а это вызывает неоднозначность std::__to_address при CUDA 12.8; создан изолированный префикс компилятора $HOME/envs/anygrasp-gcc11 с GCC/G++ 11.4.0 из conda-forge, и исправлен только приватный заголовок этого префикса $HOME/envs/anygrasp-gcc11/lib/gcc/x86_64-conda-linux-gnu/11.4.0/include/c++/bits/shared_ptr_base.h: две строки auto __raw = __to_address(__r.get()); заменены на auto __raw = std::__to_address(__r.get());; системный /usr/include не менялся. В системе не хватало символической ссылки на BLAS, поэтому создана ссылка внутри проекта third_party/anygrasp_sdk/dependencies/blas_lib/libblas.so -> /usr/lib/x86_64-linux-gnu/blas/libblas.so.3 и взят локальный заголовок third_party/anygrasp_sdk/dependencies/blas_include/cblas.h. Основные параметры успешной сборки: CUDA_HOME=/usr/local/cuda-12.8, TORCH_CUDA_ARCH_LIST=12.0, MAX_JOBS=4, CC/CXX/CUDAHOSTCXX указывают на $HOME/envs/anygrasp-gcc11/bin/x86_64-conda-linux-gnu-gcc/g++, --blas_include_dirs=third_party/anygrasp_sdk/dependencies/blas_include, --blas_library_dirs=third_party/anygrasp_sdk/dependencies/blas_lib. После установки $HOME/envs/genmanip-isaac5-py311/bin/python импортирует MinkowskiEngine 0.5.4.
Локальная проверка AnyGrasp, точка входа: tools/anygrasp/check_anygrasp_env.sh задаёт PATH / LD_LIBRARY_PATH, проверяет файлы SDK, torch/CUDA, Open3D, GraspNetAPI, pointnet2, MinkowskiEngine, feature id и пробелы в checkpoint. Результат проверки 2026-05-30: gsnet.so, lib_cxx.so, open3d 0.19.0, graspnetAPI 1.2.11, pointnet2._ext, MinkowskiEngine 0.5.4 — всё в порядке; не хватает официальных licenseCfg.json и checkpoint_detection.tar / весов AnyGrasp.
Скрипт установки лицензии и весов AnyGrasp, 2026-05-30: после получения официального zip с лицензией и checkpoint_detection.tar запускается tools/anygrasp/install_license_and_checkpoint.sh <license_zip_or_dir> <checkpoint_detection.tar>; он устанавливает лицензию в third_party/anygrasp_sdk/grasp_detection/license и third_party/anygrasp_sdk/grasp_tracking/license, кладёт веса в third_party/anygrasp_sdk/grasp_detection/log/checkpoint_detection.tar и вызывает license_checker -c для проверки. После установки tools/anygrasp/run_detection_demo.sh запускает официальную демонстрацию детекции на example data; сейчас проверено, что при отсутствии лицензии скрипт быстро сообщает об ошибке и не запускает полу-рабочий процесс.
Лицензия и веса AnyGrasp установлены и работают, 2026-06-03: пользователь получил письмо с лицензией AnyGrasp SDK от Chenxi Wang; вложение находится в $HOME/Downloads/license_KeweiChen.zip; веса детекции скачаны с официального Google Drive в $HOME/Downloads/anygrasp_weights/checkpoint_detection.tar, размер около 283M. Запущен tools/anygrasp/install_license_and_checkpoint.sh $HOME/Downloads/license_KeweiChen.zip $HOME/Downloads/anygrasp_weights/checkpoint_detection.tar, установка в third_party/anygrasp_sdk/grasp_detection/license, third_party/anygrasp_sdk/grasp_tracking/license и third_party/anygrasp_sdk/grasp_detection/log/checkpoint_detection.tar. license_checker выводит KeweiChen.lic check passed; код возврата проверки иногда ненулевой, но при реальной загрузке SDK license passed: True, state: FvrLicenseState.PASSED.
Smoke-тест детекции AnyGrasp, 2026-06-03: после исправления состояния установки pointnet2$HOME/envs/genmanip-isaac5-py311/bin/python импортирует pointnet2._ext, pointnet2.pointnet2_utils, pointnet2.pointnet2_modules. Запуск tools/anygrasp/run_detection_demo.sh успешно завершил инференс на официальных grasp_detection/example_data; выведено 20 оценок захвата, максимальная около 0.47641015. Это подтверждает, что детекция SDK AnyGrasp работает на этой машине; следующий шаг — написать мост ATEC, который из RGB-D / облака точек Isaac вырезает область цели, вызывает AnyGrasp для получения позы захвата и передаёт её в IK Piper / примитив исполнения.
Мост AnyGrasp для ATEC подключён, 2026-06-03: добавлен scripts/graspnet_task_e/anygrasp_adapter.py; scripts/graspnet_task_e/run_graspnet_pick.py поддерживает --grasp_provider anygrasp; обёртка запуска — scripts/graspnet_task_e/run_anygrasp_pick.sh <object> <seed>. Адаптер внутри процесса Isaac заранее подгружает libcrypto.so.1.1 / libssl.so.1.1 из ROS2 bridge и подставляет tools/anygrasp/ifconfig в PATH, иначе SDK даёт ошибки OpenSSL или проверки machine-id / лицензии. Тест загрузки детектора без запуска сцены: $HOME/envs/genmanip-isaac5-py311/bin/python -c 'from scripts.graspnet_task_e.anygrasp_adapter import _load_anygrasp_detector; _load_anygrasp_detector()'; в выводе должно быть license passed: True.
Smoke-тест AnyGrasp для Task E, 2026-06-03: object_3 успешно взят с параметрами --use_task_quat --tcp_z_offset 0.040 --close_z_offset -0.020, inside=True, z_gain_lift=0.137; видео logs/videos/task_e_anygrasp/anygrasp_obj3_seed11_taskquat_lowclose.mp4. object_2 с теми же параметрами тоже успешен: inside=True; видео logs/videos/task_e_anygrasp/anygrasp_obj2_seed11_taskquat_lowclose.mp4. object_1 не удался в двух попытках: anygrasp_obj1_seed11_taskquat_lowclose_retry.mp4 и anygrasp_obj1_seed11_defaultquat_nooffset_lowclose.mp4; общий признак — SDK выдаёт только кандидатов с низкой оценкой и очень узкой шириной (около 0.006–0.008 м), захват смыкается, но предмет не поднимается вместе с подъёмом. Не принимать текущий мост AnyGrasp за стратегию на максимум для трёх объектов; интеграция проверена, но для object_1 нужно продолжать подстройку по уже проверенному шаблону Task E.
Практическое правило использования AnyGrasp, 2026-06-03: сейчас самый устойчивый способ — использовать AnyGrasp как априорную информацию о кандидатах / центре / рыскании по RGB-D, но обязательно подставлять уже проверенные параметры исполнения Task E (--use_task_quat, низкий close z, finger-center / поэтапный перенос, устойчивое освобождение над корзиной). Не применять сырую 6D-позу запястья AnyGrasp напрямую: поза object_3 из сырого вывода не работала, а с кватернионом Task E получилась. Для object_1 дальнейшая работа — повторно использовать шаблон управления из успешных доказательств GraspNet: медиану верхней поверхности как центр исполнения, добавление OBJ_GRASP_CENTER_OFFSETS[1], --close_z_offset -0.020, сохранение кватерниона захвата через перенос / размещение / открытие, длинный перенос и настоящий сервоконтроль по центру пальцев.
Маршрут GraspGen / AgileX у сторонних проектов, пересмотр 2026-06-03: найдено, что AgileX рекомендует для PiPER маршрут GraspGen; ссылка AgilexRobotics/GraspGen сейчас недоступна, но доступно зеркало / репозиторий автора vanstrong12138/GraspGen с веткой ros2_jazzy_version; поверхностно склонирован в third_party/GraspGen. Официальный учебный репозиторий AgileX agilexrobotics/Agilex-College тоже склонирован поверхностно в third_party/Agilex-College; README в piper/GraspGen описывает поток PiPER + YOLOv8-Pose/TensorRT + PCA/AABB + IK / управление захватом. Основной код в third_party/GraspGen/sam3/realsense-sam.py::compute_grasp_from_pca_aabb(): 3D-PCA → AABB в главной системе осей → самая короткая сторона как направление захвата.
Интеграция GraspGen-style PCA/AABB в ATEC, 2026-06-03: добавлен scripts/graspnet_task_e/pca_aabb_adapter.py; run_graspnet_pick.py поддерживает --grasp_provider pca. Команда smoke для object_1: --grasp_provider pca --object 1 --seed 11 --mask_provider oracle --use_task_quat --tcp_z_offset 0.040 --close_z_offset -0.020 --close_steps 160 --move_steps 200 --transport_steps 1400 --place_steps 260; вывод [PCA_AABB] points=5231 extents=(0.140,0.122,0.056) axis=2 width=0.056, то есть геометрический метод даёт разумную ширину захвата, существенно отличающуюся от аномально узких 0.006–0.008 м у AnyGrasp. Но этот прогон всё равно провалился: pick=(0.950,0.261), z_gain_lift=-0.024, inside=False; видео logs/videos/task_e_pca/pca_obj1_seed11_taskquat_lowclose.mp4. Причина по предположению: одноракурсная маска RGB-D видит только боковую поверхность object_1, медиана верхней поверхности / PCA смещает центр исполнения влево; нужно дополнить центр по известным размерам объекта, мультиракурсно, learned completion или по успешному центру старой модели GraspNet.
Исправление «тычка в бок без вхождения в захват» для object_1, 2026-06-03: по видео пользователь указал, что когда кубик находится слева, захват Piper только тычет в кубик и не заводит его между пальцами перед закрытием. Повторная проверка: PCA/AABB с --preclose_insert_dx 0.040 --close_z_offset -0.020 всё равно не удалась, z_gain_lift=-0.025; в trace на этапе close min_finger_dist≈0.058 м, то есть кончики пальцев слишком далеко от цели; провалившееся видео logs/videos/task_e_pca/pca_obj1_seed11_insert_dx004.mp4. Реально работающее исправление — не занижать высоту закрытия вручную, а выровнять параметры object_1 со сборщиком Task E: OBJ_GRASP_CENTER_OFFSETS[1]=(0.025,0,0), OBJ_GRASP_Z_OFFSETS[1]=0.072, OBJ_CLOSE_Z_OFFSETS[1]=0.020, и использовать реальный сервоконтроль центра пальцев по link7/link8. Успешная команда: OMNI_KIT_ACCEPT_EULA=YES PYTHONUNBUFFERED=1 $HOME/envs/genmanip-isaac5-py311/bin/python scripts/graspnet_task_e/run_graspnet_pick.py --grasp_provider pca --object 1 --seed 11 --mask_provider oracle --use_task_quat --tcp_z_offset 0.072 --close_steps 180 --move_steps 200 --transport_steps 1400 --place_steps 260 --video_path logs/videos/task_e_pca/pca_obj1_seed11_cfgclose.mp4 --save_debug_npz logs/pca_task_e/obj1_seed11_cfgclose_debug.npz --headless; результат inside=True, z_gain_lift=0.144, на этапе reach min_finger_dist≈0.006 м, на close ≈0.024 м. Вывод: провал object_1 вызван не «недостаточной силой захвата» и не требует смены AnyGrasp, а ошибкой калибровки TCP / центра пальцев / высоты закрытия, из-за которой происходит столкновение до закрытия. В run_graspnet_pick.py статистика preclose_insert теперь входит в [TRACE]; если продолжать подбирать параметры, сначала смотреть ошибку центра пальцев на этапах reach / insert / close / lift, и только потом делать выводы.
Исправление object_1 для demo/solution_pca.py в стиле отправки, ход работ, 2026-06-04: не перезаписывать demo/solution.py / ACT-базу, solution_pca.py остаётся экспериментальной веткой. Последние проверки одиночного объекта на seeds 11/12/13 завершились успешной укладкой в корзину: seed11 ранее дал score=6.00, начальная позиция (1.0945,0.2979,0.8833), конечная (1.0582,-0.3256,0.8820); с последними жёсткими параметрами seed12 дал score=6.00, конечная (1.0338,-0.2790,0.8584); seed13 дал score=6.00, конечная (1.0257,-0.2567,0.8871). Команда проверки: ATEC_PCA_OBJECTS=1 OMNI_KIT_ACCEPT_EULA=YES PYTHONUNBUFFERED=1 $HOME/envs/genmanip-isaac5-py311/bin/python scripts/graspnet_task_e/debug_solution_pca_execution.py --seed <11|12|13> --object 1 --max_steps 4800 --headless. Ключевые параметры: для object_1 отключён центр облака точек с заполнением дыр в ROI; компенсация центра по видимой грани OBJ_CENTER_COMPLETION_OFFSETS[1]=(0.020,0.0); OBJ_GRASP_CENTER_OFFSETS[1]=(0,0); на этапе reach не использовать низкий сервоконтроль по z пальцев; высоты release / open для object_1 берутся из калибровки runner TABLE_TOP_Z+0.32/+0.24; OBJ1_HOLD_GAP=0.0415, OBJ_LIFT_STEPS[1]=300; при первом достижении порога зазора на close / lift / mid записывается _obj1_hold_grip, и затем на lift / mid / release / settle раскрытие захвата сохраняется, чтобы не сжимать до нуля и не выбивать кубик. Ошибочный опыт: OBJ_PLACE_XY_OFFSETS[1]=(0,-0.250) делает цель release равной y=-0.55 и предмет падает перед корзиной; rescue object_1 с широким ROI / белой сеткой легко даёт ложные срабатывания, по умолчанию его выключать, пока не будет надёжной сегментации переднего плана.
Состояние object_2/3 в demo/solution_pca.py, 2026-06-04: object_2/3 пока не достигли стабильности для отправки, не утверждать, что PCA-решение дошло до максимума. В сравнении с runner object_3 на seed11 однажды успешно сработал, но повторная проверка того же набора параметров 2026-06-04 провалилась, значит прошлый успех не был устойчивым состоянием. Журналы сборщика obj321_servo от 20 мая подтверждают, что в официальном state_machine с реальным корнем объекта все три предмета могут дать максимум; у успешных trace object_3 обычно z_gain≈0.42, gap_close≈0.063–0.069, finger_close≈0.016–0.030, finger_vec_close.x≈-0.01~-0.03, basket_inside=True. Ключевой новый результат для submit-style object_3: низкое и высокое положение по умолчанию нестабильны; проблема сместилась от «совсем нет контакта» к «можно сильно поднять, но при переносе предмет соскальзывает»; текущие экспериментальные значения по умолчанию OBJ_CLOSE_Z_OFFSETS[3]=0.030, OBJ3_HOLD_GAP=0.055, OBJ_FINGER_XY_OFFSETS[3].x=-0.030, OBJ_LIFT_STEPS[3]=40 дают в некоторых прогонах seed11 сильный подъём, например logs/pca_solution_obj3_fxneg003_full_seed11_20260604.log выдаёт score=3.00, max_z_gain=0.195; короткий лог подъёма logs/pca_solution_obj3_shortlift_seed11_20260604.log выдаёт max_z_gain=0.236; но стадии mid / release возвращают предмет на стол, в корзину не попадает. Граница неудач: hold_gap=0/0.045/0.060/0.065, close_z=-0.020/0/0.020/0.050/0.070/0.090, yaw PCA, ATEC_PCA_USE_FULL_IK=1, ATEC_PCA_OBJ3_OBJECT_SERVO=1 — ни одна комбинация стабильно не решила задачу. Дальше не спорить о том, «захватили ли вообще»; сосредоточиться на удержании при переносе / низком переносе: сразу после захвата двигать горизонтально, сокращать чисто вертикальный подъём или делать перенос закрытым волочением / подгребанием снизу. Object_2 нужно перенастроить отдельно, не применяя компенсации object_1 / object_3.
demo/solution_pca.py, добавка по устранению соскальзывания object_3, 2026-06-04 18:20 CST: по предложению пользователя в экспериментальной ветке реализовано направление «короткий подъём + динамический визуальный object-servo + fallback в низком положении», но seed11 всё ещё не проходит, не развёртывать. Текущие изменения файла: OBJ3_HOLD_GAP=0.066, OBJ3_HOLD_GRIP_DEFAULT=(0.032,-0.034), OBJ3_CLOSE_MIN_STEPS=160, OBJ3_LOW_HOLD_STEPS=140, OBJ3_APPROACH_FINGER_Z=TABLE_TOP_Z+0.090, OBJ3_CLOSE_FINGER_Z=TABLE_TOP_Z+0.010, OBJ3_LIFT_FINGER_Z=TABLE_TOP_Z+0.080, OBJ3_OBJECT_SERVO_GAIN=0.12, OBJ3_OBJECT_SERVO_MAX_XY=0.040, OBJ3_FINGER_SERVO_MAX_XY=0.080; fallback для object_3 теперь срабатывает раньше, при застревании на obj3_mid, OBJ3_FALLBACK_DRAG_Z=TABLE_TOP_Z+0.035, шаги fallback 60/260/260/100. Важно: не «замораживать» фактическую позицию qpos как удерживающий захват object_3 — раньше это блокировало асимметричное раскрытие, например (0.035,-0.026); использовать стандартный откалиброванный захват. Не полагаться только на z у gripper_base: для reach / close / lift object_3 нужен явный z центра пальцев.
Граница object_3 по последнему trace, 2026-06-04: logs/pca_solution_fix/obj3_seed11_runner_vec_match_debug_20260604_181342.log показывает, что старое значение по умолчанию OBJ_FINGER_Y_OFFSET=+0.003 ставило центр пальцев при закрытии на +0.024 м от центра банана по y, и банан отталкивался в сторону; значение по умолчанию изменено на -0.020. logs/pca_solution_fix/obj3_seed11_yoffset_neg020_debug_20260604_181533.log показывает, что y выровнено, но по x значение может стать слишком отрицательным; временное переопределение ATEC_PCA_OBJ3_FINGER_X_OFFSET=-0.004 ATEC_PCA_OBJ3_FINGER_Y_OFFSET=-0.020 в logs/pca_solution_fix/obj3_seed11_xyoffset_xneg004_yneg020_debug_20260604_181706.log даёт вектор закрытия, ближе к runner: фактический палец около (x=+0.002,y=-0.015,z=-0.014) относительно текущего визуального центра, но score=0. Значит, проблема уже не в том, что пальцы не дошли, а в том, что после закрытия не образуется переносимый контакт, и, возможно, визуальный центр искажён захватом. Ранний fallback с низким положением logs/pca_solution_fix/obj3_seed11_early_low_fallback_20260604_181908.log сдвинул object_3 только до (1.083,0.055,0.841): по x он близко к корзине, но по y остаётся в +0.355 м от центра корзины; текущая высота closed-drag и направление контакта всё ещё не сдвигают банан.
Рекомендации по object_3 на следующий шаг, 2026-06-04: продолжать искать решение в submit-style планировании захвата, не возвращаясь к ACT / обучению и не меняя физику судьи. В первую очередь реализовать и проверить настоящий under-scoop / sweep на уровне стола: заход со стороны +y от текущего визуального центра или по дуге снаружи, затем шаговое движение пальцев по z ниже TABLE_TOP_Z+0.035 к BASKET_CENTER_Y, с сохранением пересчёта текущего центра object_3; fallback срабатывает раньше на obj3_mid и гарантированно завершается за 1500 шагов. Если продолжать подбирать захват, эталоном остаётся успешный лог runner logs/graspnet_task_e_obj3_sam3_closed_drag.log: inside=True, z_gain_lift=0.207, вектор минимального расстояния пальцев на reach / close / lift около (-0.007~-0.010, -0.002~+0.002, -0.014~-0.011), gap≈0.066-0.068. Любые новые параметры проверять через ATEC_PCA_DEBUG_TARGET=1 или debug_solution_pca_execution.py, смотреть численные значения центра пальцев и центра объекта, а не судить только по видео.
Вариант object_3 «короткий подъём + низкий cradle/servo + стабильный релиз над корзиной» по указанию пользователя, реализация 2026-06-04 20:35 CST: в экспериментальной ветке demo/solution_pca.py реализовано, но до уровня развёртывания ещё не доведено. Ключевые изменения: OBJ3_HOLD_GAP=0.0675, OBJ3_CLOSE_STEPS=90, OBJ3_LIFT_STEPS=35, OBJ3_LOW_HOLD_STEPS=0, OBJ3_LIFT_FINGER_Z=TABLE_TOP_Z+0.045, OBJ3_FINGER_X_OFFSET=-0.010; удерживающий захват теперь фиксируется только на obj3_lift, когда зазор достиг порога, чтобы не заклинивать раскрытие уже на стадии закрытия; исправлена явная ошибка в obj3_basket_hold: dynamic_finger_xy не должен быть текущим центром банана c_now, нужно сохранять object_target_xy + carry_offset, иначе рука тянется обратно к старой позиции. Журналы проверки: logs/pca_solution_fix/obj3_seed11_eval_close90_shortlift_fasttransport_20260604_201931.log — фиксация захвата прошла, но желаемая позиция в basket_hold задана неверно, объект остался около y≈0.068; после исправления logs/pca_solution_fix/obj3_seed11_eval_fixservo_transport440_20260604_202219.log и ...fingerik_20260604_202355.log всё равно застряли при finger y≈-0.09; вариант closed-drag с низкой высотой logs/pca_solution_fix/obj3_seed11_eval_low_closed_drag_20260604_202611.log тоже дошёл лишь до finger y≈-0.09, объект в корзину не попал; вариант DLS только по положению logs/pca_solution_fix/obj3_seed11_eval_lowdrag_positiononly_*.log подвёл gripper_base ближе к корзине, но z пальцев ушёл вверх до ≈1.0 м, контакт потерян. Вывод: захват object_3 и короткий подъём теперь достижимы, главный блокер — submit-side управление переносом по Pinocchio DLS не повторяет поведение CartesianController Isaac из runner / сборщика с реальным якобианом PhysX, особенно движение по y к корзине и удержание z пальцев; не объяснять основную проблему моделью кандидатов GraspNet / AnyGrasp.
Кратчайший путь по object_3, 2026-06-04 20:35 CST: в первую очередь воспроизвести детали генерации действий CartesianController из IsaacLab, а не менять модель захвата. Подтверждено: официальный get_action_spec() позволяет менять только mode/scale/clip групп действий, но не отправлять Cartesian action напрямую; через него можно только диагностировать скорость / масштаб руки и нельзя исправить позиционный контроль. Следующие шаги: 1) в scripts/graspnet_task_e/debug_solution_pca_execution.py печатать q6 и пределы суставов на застрявшей стадии, чтобы понять, это предел сустава или ошибка DLS / вращения; 2) привести _rot_error, затухание DLS и ограничение шага в demo/solution_pca.py к source/atec_rl_lab/atec_rl_lab/utils/cartesian_controller.py, сначала с позицией и текущим кватернионом запястья вместо принудительно вертикальной ориентации; 3) если не поможет, сделать небольшую библиотеку переноса в суставном пространстве: runner генерирует относительные точки маршрута по суставам для нескольких начальных положений object_3 в полосе y, а submit выбирает их по визуальному центру и интерполирует, вместо пошагового онлайн-решения обратной кинематики в декартовых координатах. Конфигурацию demo/solution.py / demo/policy_act.pt ACT/XSA не трогать, solution_pca.py оставить экспериментальной веткой.
PCA/AABB + маска полосы RGB-D, одиночный smoke по трём объектам, 2026-06-03: цель — обойти ограничение лицензии AnyGrasp SDK и получить воспроизводимый геометрический вариант захвата. В scripts/act/task_e/config.py значения OBJ_SPAWN_Y_BANDS выровнены с официальным source/atec_rl_lab/atec_rl_lab/tasks/task_e/env_cfg.py: object_1 [+0.25,+0.29], object_2 [+0.14,+0.20], object_3 [+0.03,+0.09]; в scripts/graspnet_task_e/tuntun_adapter.py в rgbd_band_object_mask() добавлен фильтр по высоте z для конкретного объекта, чтобы точки стола, руки и корзины не попадали в маску. Успешная команда для object_1 по полосе: ... run_graspnet_pick.py --grasp_provider pca --object 1 --seed 11 --mask_provider band --use_task_quat --tcp_z_offset 0.072 --close_steps 180 --move_steps 200 --transport_steps 1400 --place_steps 260 --video_path logs/videos/task_e_pca/pca_obj1_seed11_band_cfgclose_yband_zfilter.mp4 ..., результат inside=True, z_gain_lift=0.144. Для object_2 после сужения полосы по y повторная проверка прошла: ... --object 2 --seed 11 --mask_provider band --use_task_quat --tcp_z_offset 0.040 --close_z_offset -0.020 --transport_steps 1400 --place_steps 260 --video_path logs/videos/task_e_pca/pca_obj2_seed11_band_yalign_taskquat_lowclose.mp4 ..., результат inside=True, z_gain_lift=0.119. Для object_3 начальный PCA по полосе позволяет поднять предмет, но при высоком релизе над корзиной он соскальзывает. Исправление: в scripts/graspnet_task_e/pca_aabb_adapter.py для object_index==3 использовать центр ориентированного AABB вместо медианы верхней поверхности, а в run_graspnet_pick.py добавить --open_release_z, то есть «высокий перенос — низкое раскрытие». Для object_3 seed11 с центром AABB и высоким релизом получилось однажды: logs/videos/task_e_pca/pca_obj3_seed11_band_aabbcenter_taskquat_lowclose.mp4, результат inside=True, z_gain_lift=0.161; для seed12 высокий релиз соскальзывал, а после перехода на --release_z 0.32 --open_release_z 0.24 --place_steps 220 стал успешным: видео logs/videos/task_e_pca/pca_obj3_seed12_band_aabbcenter_highcarry_lowopen.mp4, результат inside=True, итоговое смещение относительно корзины около (-0.031,-0.049). Важно: это проверки одиночных объектов в runner; их нужно собрать в трёхобъектный непрерывный эпизод и перенести на логику управления demo/solution.py только по наблюдениям. Текущий run_graspnet_pick.py всё ещё читает состояние объектов среды для проверки и динамического сервоконтроля, поэтому напрямую как итоговую отправку его использовать нельзя.
Отладка контроллера PCA в стиле отправки, 2026-06-04: demo/solution_pca.py — экспериментальная ветка, не развёрнута; demo/solution.py остаётся базой ACT/XSA. scripts/act/eval_task_e_act.py уже поддерживает --solution_module solution_pca; scripts/graspnet_task_e/debug_solution_pca_execution.py может через внутренние данные Isaac измерять finger_dist/max_z_gain/pin_mean_err. Подтверждено: FK Pinocchio совпадает с link7 / link8 / gripper_base Isaac, pin_mean_err finger=0.0000 gb=0.0000, значит главная причина «не доходит до захвата / не поднимает» — не ошибка системы координат FK, а то, что IK / контроллер в стиле отправки не воспроизводит низкий контакт CartesianController из run_graspnet_pick.py.
Текущее состояние object_1 в стиле отправки, 2026-06-04: попытка перенести успешный шаблон object_1 из run_graspnet_pick.py в demo/solution_pca.py: восстановление AABB центра в мировых координатах по RGB-D, OBJ_CENTER_COMPLETION_OFFSETS[1]=(0,+0.018), уменьшение смещения исполнения по x для object_1 с +0.025 до +0.010, низкая плоскость закрытия TABLE_TOP_Z+0.030 и прямой IK по центру пальцев. Вывод: восприятие центра достигает точности сантиметров, но текущий IK Pinocchio на этапе закрытия часто застревает, и центр пальцев link7 / link8 остаётся примерно на +0.05 м над предметом; max_z_gain≈0, object_1 не поднимается. Прямой IK по центру пальцев и принудительная task-кватернион object_1 (0,0.707,0.707,0) оказались хуже; вернулись к маршруту компенсации gripper_base. Не считать, что сами захват GraspNet / PCA / AnyGrasp провалены. Следующий шаг — воспроизвести математику и параметры differential IK из Isaac CartesianController или реализовать в политике отправки более надёжный шаг DLS с разрешением по скорости, а не менять модели захвата.
Вставка перед закрытием (preclose insert) для object_1 в стиле отправки, обновление 2026-06-04: в demo/solution_pca.py добавлены _PiperIK.step_dls(), коррекция XY центра пальцев как в runner, task-кватернион object_1 [0,0.709,0.705,0], коррекция z относительно объекта, preclose insert и перелёт при release для object_1. Видео logs/videos/task_e_pca_solution/pca_solution_obj1_seed11_best_trace_20260604_114715.mp4 ясно показывает: без insert носик захвата упирается в боковую сторону кубика, при подъёме кубик остаётся на столе. С insert вариант OBJ_PRECLOSE_INSERT_OFFSETS[1]=(0,-0.040) однажды дал score=3, max_z_gain=0.137 м, но при переносе соскользнул к y≈-0.047; вариант (0,+0.025) дал max_z_gain=0.193 м, конечный y≈-0.083, в корзину не попал; в одном случайном положении не поднялся. Вывод: направление и величина insert — ключ к успешному подъёму, но object_1 пока не стабилен; demo/solution_pca.py остаётся debug-only, не перезаписывать demo/solution.py или demo/policy_act.pt.
Сравнение object_1 с GraspNet, 2026-06-03: попытка повторить старую успешную команду, видео logs/videos/task_e_graspnet/graspnet_pick_obj1_seed11_recheck_20260603.mp4; процесс более 3 минут не выводил [GRASP] на стадии инференса / генерации кандидатов GraspNet, занимал около 6.6 ГБ GPU и держал высокую нагрузку CPU; остановлен вручную. Этот прогон не является доказательством ни успеха, ни провала захвата; если продолжать сравнение с GraspNet, сначала разобраться, почему текущая проверка на инференсе замедлилась / зависла.
Сторонний референс AnyGrasp, вывод 2026-05-30: официального проекта AnyGrasp для Piper от Songling / AgileX не найдено; AgileX в основном публикует стек управления PiPER для Python / ROS / ROS2 / URDF / симуляции. Сторонние и научные маршруты подтверждают схему «AnyGrasp как prior pre-contact / contact-pose, затем IK / планирование траектории робота»: в работе DKT по прозрачным объектам сообщалось о связке RealSense D435 + PiPER Arm + AnyGrasp + CuRobo; BayesVLA разделяет политику на априорную визуальную модель действий и языковое правдоподобие и передаёт фазу pre-contact замороженной модели контактной позы типа AnyGrasp. Для нашего проекта вывод: AnyGrasp сначала используется как генератор кандидатов захвата и их ранжирования, а Piper ATEC по-прежнему требует отдельной работы с TCP-калибровкой, IK / траекторией, удержанием при закрытии / переносе и стабильным релизом над центром корзины на высоте.
Текущий порядок работ, рекомендация: 1) сохранить базу ACT/XSA demo/policy_act.pt без изменений; 2) если нужен краткосрочный рост баллов, сначала подключить AnyGrasp / SAM3 как генератор кандидатов захвата к уже откалиброванному примитиву Piper, а не продолжать слепо обучать pi0.5; 3) если продолжать VLA, перестроить адаптер воплощения OpenPI / Piper (нативные размерности Piper, камеры, нормализация, discrete_state_input) и не использовать как официальный вывод фиксированный 16D с дополнением базы; 4) перед каждым развёртыванием отдельным процессом оценивать seeds 11/12/13, сохранять минимум одно видео и журнал [BASKET], где видно, попадает ли предмет в корзину.
Последний статус, 2026-05-20 20:55 CST:
Заменяет более ранние заметки «объекты 1/2 не решены» ниже; сохранить их только как исторический контекст отладки.
Генерация данных скриптованным оракулом для трёх объектов в L0 Task E теперь работает достаточно хорошо, чтобы собирать демонстрации. Проверен полный порядок 3 2 1 с --only_success --trace --abort_failed_lift.
Проверен успех только для object_1: datasets/atec_task_e_probe_obj1_graspoffset_servo/trajectory.hdf5, 3 из 3 успешных демонстраций; z-gain в trace около 0.387–0.417, basket_inside=True.
Проверен успех только для object_2: datasets/atec_task_e_probe_obj2_original_rootservo/trajectory.hdf5, 3 из 3 успешных демонстраций; z-gain в trace около 0.302–0.304, basket_inside=True.
Проверен трёхобъектный успех: datasets/atec_task_e_probe_obj321_final_servo/trajectory.hdf5, 3 успешные демонстрации из 4 попыток; в успешных trace у object_1/2/3 basket_inside=True.
Видео для проверки: logs/videos/task_e_obj321_final_servo/demo_0000.mp4; сводка ключевых кадров: logs/videos/task_e_obj321_final_servo/summary_5s.jpg.
Первопричина и исправление: ошибка была в генерации данных, а не в обучении ACT. Для object_1 цель сервоконтроля центра пальцев должна быть obj_pos + OBJ_GRASP_CENTER_OFFSETS[1]; для object_2 нужно следовать за положением USD / корня объекта, а не за смещённым центром. Обоим нужен замкнутый сервоконтроль центра пальцев на стадиях REACH/CLOSE/LIFT/TRANSPORT/PLACE.
Стабильные константы в scripts/act/task_e/config.py: смещение object_1 (0.025,0,0), высота захвата 0.072, высота закрытия 0.020, шаги переноса / укладки 2200/300; смещение object_2 (0.060,0,0), высота захвата 0.135, шаги переноса / укладки 2200/300; по умолчанию PICK_OBJECTS="3 2 1".
В scripts/act/task_e/collector.py важно различие сервоконтроля по объектам: для object_1 цель сервоконтроля и trace берётся как obj_pos + OBJ_GRASP_CENTER_OFFSETS, для object_2 и object_3 — obj_pos. Не «упрощать» обратно до одной формулы.
scripts/act/train_task_e.py использует lr_drop = max(int(2/3 * total_iters), 1), поэтому очень короткие smoke-тесты больше не падают на StepLR(step_size=0).
Урок из CAP-X / RoboTwin: сначала использовать кандидатов захвата, откалиброванных по контакту и TCP, и замкнутую логику укладки. GraspNet / ContactGraspNet можно подключить позже как генератор кандидатов, но для исправления текущей ошибки оракульных данных он не обязателен.
Длительный запуск выполнялся как пользовательский юнит systemd, потому что обычный фоновый запуск через nohup мог быть убит вместе с командой Codex: юнит atec-task-e-obj321-servo-20260520211650.service, журнал logs/task_e_obj321_servo_pipeline_20260520_211650.log, символическая ссылка на последний журнал logs/task_e_obj321_servo_pipeline.latest.
На 2026-05-20 21:22 CST длительный запуск шёл: Demo 1/100 успешно завершён и записан в datasets/atec_task_e_obj321_servo_100demos/trajectory.hdf5 (около 1,3 ГБ), затем начался Demo 2/100.
Последний статус обучения и оценки, 2026-05-21 14:55 CST:
Юнит atec-task-e-obj321-servo-20260520211650.service завершился штатно; сырой набор данных datasets/atec_task_e_obj321_servo_100demos/trajectory.hdf5 (около 130 ГБ), отфильтрованный набор trajectory_filtered.hdf5 (около 35 ГБ), запуск runs/act-task-e-rgb-obj321-servo-100demos-seed1.
Checkpoint включают best_loss.pt и final.pt; обучение дошло до 100000 итераций, финальный loss в журнале около 0.0100.
Первая оценка ACT для best_loss.pt дала 0/3 эпизодов; видео logs/videos/task_e_act_eval/obj321_best_loss_100demos_20260521_145104.mp4 показывает, что рука остаётся около корзины / домашней позы и не начинает захват объекта.
Найдена первопричина в demo/solution_act.py: на стадии home среда трактовала действие как PD / скорость, тогда как действие Task E равно (joint_target - default_joint_pos) / 0.5. Исправление — подавать статичное целевое действие телеуправления в home, пока не стабилизируется, и только потом переключаться на ACT. Оценку повторить после исправления, и только потом судить о качестве модели.
После исправления home оценка best_loss.pt улучшилась: балл одного эпизода 9.00, видео logs/videos/task_e_act_eval/obj321_best_loss_homefix_1ep_20260521_145529.mp4; в трёхэпизодной оценке в одном процессе первый эпизод дал корректный балл 18.00, видео logs/videos/task_e_act_eval/obj321_best_loss_homefix_3ep_20260521_145652.mp4, но следующие эпизоды сбрасывались с done=True уже на шаге 1, поэтому среднее значение нельзя считать независимым.
Оценка final.pt по одному эпизоду дала 6.00, поэтому для развёртывания выбран best_loss.pt.
Развёртывание: прежний demo/policy_act.pt сохранён как demo/policy_act.prev_20260521_145951.pt; текущий demo/policy_act.pt скопирован из runs/act-task-e-rgb-obj321-servo-100demos-seed1/checkpoints/best_loss.pt, SHA256 совпадает: 76bbef2c81c85fc6cc60448476ff09075ec8bc97217c2d2fb70a3253fd3e307d.
Эксперимент XSA-ACT, 2026-05-21:
Локальный источник пакета XSA: $HOME/Documents/01Proj/13atec/xsa_update_20260520/lerobot_policy_act_xsa.zip; это плагин LeRobot act_xsa с примером конфигурации на 12 измерений, он не запускается напрямую для 8D-конфигурации Piper в Task E ATEC.
Добавлена минимальная адаптация XSA за флагом --use_xsa: source/atec_rl_lab/atec_rl_lab/train/act/act/detr/transformer.py и demo/act/detr/transformer.py поддерживают XSATransformerEncoderLayer / XSATransformerDecoderLayer; обычный ACT не меняется.
scripts/act/train_task_e.py теперь сохраняет model_args в checkpoint; demo/solution_act.py читает model_args, включая use_xsa, поэтому обычные checkpoint ACT и XSA загружаются оба.
Smoke-тест пройден: runs/act-task-e-rgb-xsa-smoke-10demos-seed7/checkpoints/final.pt загружается как XSATransformerEncoderLayer.
Активный сравнительный запуск XSA: пользовательский юнит systemd atec-task-e-xsa-30k-20260521165009.service, журнал logs/task_e_xsa_30k_20260521_165009.log, имя запуска act-task-e-rgb-xsa-100demos-30k-seed11, команда с --use_xsa --total_iters 30000 --batch_size 256 --num_demos 100.
Промежуточные оценки шумные и пока не вдохновляют: снимок около 19k дал 9/18, видео logs/videos/task_e_act_eval/xsa_mid_best_1ep_20260521_174124.mp4; более поздний текущий лучший снимок 20260521_175038 дал 0/18, видео logs/videos/task_e_act_eval/xsa_current_best_1ep_20260521_175038.mp4. Не выводить рейтинг только по loss обучения; запускать независимые процессы по одному эпизоду, потому что многоэпизодный сброс в одном процессе после успеха может быть некорректным.
Интеграция GraspNet / TunTunClaw, 2026-05-21:
Референс пользователя клонирован в third_party/tuntunclaw/ из материалов Datawhale / OpenClaw home assistant. Официальный checkpoint GraspNet: third_party/tuntunclaw/temp/logs/log_rs/checkpoint-rs.tar.
Локальные файлы моста: scripts/graspnet_task_e/tuntun_adapter.py и тестовый запуск scripts/graspnet_task_e/run_graspnet_pick.py.
Зависимости настроены в $HOME/envs/genmanip-isaac5-py311/bin/python: open3d==0.19.0, локальный graspnetAPI, transforms3d==0.4.2, расширение CUDA pointnet2 GraspNet, собранное под Blackwell с TORCH_CUDA_ARCH_LIST=12.0.
Важный урок: одни только сырые точки и ориентация GraspNet не подняли object_1. Первый успешный smoke для object_1 использовал GraspNet / TunTunClaw для генерации кандидатов, но исполнение шло по калиброванным управлениям Task E: медиана верхней поверхности по надёжной маске как центр исполнения, добавлено OBJ_GRASP_CENTER_OFFSETS для object_1, --close_z_offset -0.020, сервоконтроль центра пальцев, сохранение кватерниона захвата через перенос / укладку / раскрытие и длинный перенос.
Подтверждённый результат этой команды: inside=True, z_gain_lift=0.164, итоговая позиция object_1 около (1.043,-0.247,0.934), смещение относительно корзины (-0.037,+0.053). Видео: logs/videos/task_e_graspnet/graspnet_pick_obj1_seed11_keepquat_slow.mp4.
Smoke GraspNet для object_3 также удался с уточнённой оракульной маской AABB и более низкой высотой закрытия: команда --object 3 --tcp_z_offset 0.055 --close_z_offset 0.015 --use_task_quat --place_x_offset 0.04 --place_y_offset 0.05; результат inside=True, z_gain_lift=0.188, видео logs/videos/task_e_graspnet/graspnet_pick_obj3_seed11_lowclose.mp4.
Smoke GraspNet для object_2 пока не решён. Лучшие попытки немного сдвигают и поднимают предмет (z_gain_lift≈0.07–0.10), но итоговое значение y остаётся вне корзины; простой --post_push сдвинул его только до примерно y=-0.056. Для object_2 пока использовать существующий путь конечного автомата с калибровкой Task E / ACT, пока не найден лучший контактный примитив GraspNet.
Добавлен «допустимый» провайдер маски полосы RGB-D rgbd_band_object_mask() и флаг запуска --mask_provider band: он не использует состояние объектов симуляции, а опирается на внутренние параметры камеры, глубину, высоту стола и официальные полосы по y для размещения. Тест маски полосы для object_3 пока не поднял объект, поэтому успешные видео GraspNet выше всё ещё опираются на oracle_object_mask() / отладочные маски AABB. Оракульные маски в итоговой отправке не использовать без замены.
Трёхобъектная стабильная проверка оракула / конечного автомата после изменений GraspNet: scripts/act/collect_demos_task_e.py --pick_objects 3 2 1 --num_demos 1 --max_attempts 3 --only_success --trace --abort_failed_lift --save_video ... успешно прошёл на второй попытке; у object_1/2/3 basket_inside=True. Видео: logs/videos/task_e_obj321_current_verify/demo_0000.mp4.
Сегментация SAM3 / освобождение над центром корзины, 2026-05-21:
Локальный checkpoint SAM3 находится в $HOME/Documents/01Proj/sam3d_gs/submodule/Prompt-Inpaint/checkpoints/sam3.pt; SAM3 установлен в $HOME/Documents/01Proj/sam3d_gs/.venv/bin/python, а не в окружении Isaac. SAM3 держать изолированно как отдельный подпроцесс и не ставить в $HOME/envs/genmanip-isaac5-py311.
Добавлен scripts/graspnet_task_e/sam3_segment_image.py: отдельный конвертор RGB-изображения в бинарную маску SAM3. Использует локальный SAM3Predictor из Prompt-Inpaint, пишет маску .npy и необязательные метаданные JSON.
scripts/graspnet_task_e/run_graspnet_pick.py теперь поддерживает --mask_provider sam3, --sam3_prompt, --sam3_threshold и --sam3_python. По умолчанию включён --basket_center_release: на стадиях transport / place / open ошибка текущего центра объекта корректирует цель концевого эффектора, так что центр объекта приводится к (BASKET_CENTER_X, BASKET_CENTER_Y) до раскрытия.
Проверка SAM3 на сохранённых кадрах прошла для всех трёх подсказок: object_1 — лучшая подсказка box, оценка 0.863, маска 31206 пикселей; object_2 — yellow bottle, оценка 0.961, маска 2509 пикселей; object_3 — banana, оценка 0.953, маска 1311 пикселей. Наложения: logs/graspnet_task_e/sam3_smoke_obj{1,2,3}_overlay.png.
Первый живой smoke SAM3+GraspNet для object_3 был заблокирован до создания окружения ошибкой ModuleNotFoundError: scripts.act; исправлено явным добавлением корня репозитория в sys.path в начале run_graspnet_pick.py. Живой smoke нужно повторить после исправления.
Живой SAM3+GraspNet для object_3 с высоким закрытием по умолчанию провалился (z_gain_lift=0.000). Понижение смещения закрытия исправило контакт: команда --mask_provider sam3 --object 3 --seed 11 --tcp_z_offset 0.055 --close_z_offset -0.005 --use_task_quat --basket_center_release; результат inside=True, z_gain_lift=0.211, итоговая позиция (0.995,-0.254,0.852), смещение относительно корзины (-0.085,+0.046). Видео: logs/videos/task_e_graspnet/graspnet_pick_obj3_sam3_basket_center_lowclose.mp4.
В run_graspnet_pick.py теперь есть локальное для GraspNet значение по умолчанию для смещения закрытия object_3 (GRASPNET_CLOSE_Z_DEFAULTS[3] = -0.005), без изменения глобальных констант скриптованного сборщика Task E.
Отладка после того, как пользователь настоял, что правило «центр SAM → корзина» верное: первый сбой SAM3 для object_1 был вызван не возможностями SAM, а тем, что sam3_segment_image.py возвращал несколько масок, а run_graspnet_pick.py сначала выбирал наиболее уверенного «отвлекающего» кандидата около корзины / стола (y≈-0.316), а не сахарницу (y≈+0.261). Исправление: sam3_segment_image.py теперь может записывать все кандидаты, а run_graspnet_pick.py выбирает и уточняет кандидата с наибольшим числом точек RGB-D внутри официальной полосы x/y появления объекта и диапазона высоты стола.
После выбора кандидатов по мировой полосе восприятие SAM3 для object_1 корректно (selected_candidate=1 prompt=box, маска 3327 пикселей, цель облака точек / GraspNet около (1.020,0.261,0.917)). Объект частично поднимается (z_gain_lift=0.120), но мимо корзины: итоговое y -0.051; более сильный сервоконтроль корзины ухудшил захват, поэтому текущий блокер — стабильность захвата и соскальзывание при переносе, а не сегментация.
Восприятие SAM3 для object_2 тоже корректно (band_ratio≈0.98–0.99, маска около 2500–2700 пикселей). При смещении по умолчанию объект частично поднимается (z_gain_lift≈0.098–0.112), но останавливается около y -0.08…-0.10; без смещения хуже, а при меньшей высоте закрытия всё равно промах. Текущий блокер — стабильность захвата бутылки и соскальзывание при переносе, а не SAM3 / SAM2.
Не переходить на SAM2 как основное решение, пока задержки SAM3 не станут неприемлемыми. Доказательства указывают на фильтрацию кандидатов (исправлена) и настройку исполнения / контакта (ещё не сделана), а маски SAM3 хороши, если выбраны ограничениями по мировой полосе.
Пользователь верно указал на преждевременный релиз: в run_graspnet_pick.py добавлены явное журналирование конца переноса, короткая стабилизация перед раскрытием и правило «не открывать, пока не стабильно». Новые аргументы: --release_z, --basket_xy_tol, --basket_hold_steps, --basket_stable_steps, --basket_recovery_steps, --auto_table_push_on_slip, --drag_recovery_steps.
Важная тонкость: длительная выдержка в высоком положении может вызывать соскальзывание и подпрыгивание. Тест object_3 с высокой выдержкой достиг min_xy_err≈0.055, но провалился, потому что ждал слишком долго, а затем уронил предмет с подскоком. Использовать короткую стабилизацию (basket_stable_steps около 6–12, basket_xy_tol около 0.09), а не сотни шагов удержания.
Проверен успешный short-stable релиз object_3 с SAM3 после добавления TRANSPORT_END: команда --object 3 --mask_provider sam3 --close_z_offset -0.005 --release_z 0.18 --basket_xy_tol 0.09 --basket_hold_steps 40 --basket_stable_steps 6 --transport_steps 220; результат inside=True, TRANSPORT_END xy_err=0.006, итог (1.077,-0.313,0.852). Видео: logs/videos/task_e_graspnet/graspnet_pick_obj3_sam3_closed_drag.mp4.
object_1 и object_2 по-прежнему не работают в SAM3+GraspNet, несмотря на корректные маски. На TRANSPORT_END оба соскользнули или упали до релиза: пример object_1 — итоговый перенос (0.885,-0.056,0.872), xy_err=0.313; пример object_2 — (0.978,0.034,0.882), xy_err=0.349. Восстановление волочением / толканием на столе в текущей реализации их не сдвигает, вероятно, потому что низкая цель gripper_base для толчка на самом деле не касается боковой поверхности объекта. Следующий шаг: перейти на откалиброванный примитив переноса / контакта конечного автомата Task E или перепроектировать толкатель, используя реальную геометрию контакта пальцев / звеньев, а не только z-цель gripper_base.
Продолжение, ночь 2026-05-21: пользователь прямо потребовал, чтобы метод был реалистичным для соревнования, поэтому scripts/graspnet_task_e/run_graspnet_pick.py переведён на реальные центры пальцев link7/link8 для переноса и восстановления, а не на ложные допущения о контакте через gripper_base. Добавлен поэтапный перенос (--staged_transport, --transport_servo_fraction): рука сначала плавно несёт предмет, и только на последнем участке применяется сервоконтроль объекта к центру корзины.
Проверено: SAM3+GraspNet object_3 с реальным переносом пальцами и поэтапным переносом; команда --object 3 --mask_provider sam3 --close_z_offset -0.005 --transport_steps 700 --transport_servo_fraction 0.20 --basket_servo_gain 0.75 --basket_servo_max_xy 0.18; результат inside=True, итоговая позиция около (0.995,-0.220,0.853); видео logs/videos/task_e_graspnet/graspnet_pick_obj3_sam3_staged_transport.mp4.
SAM3+GraspNet для object_1 и object_2 пока недостаточно устойчивы для отправки. Тест object_1 без смещения может частично поднять (z_gain_lift≈0.130), но соскальзывает около y≈-0.055; тест object_2 со смещением может частично поднять (z_gain_lift≈0.120–0.137), но соскальзывает около y≈-0.10. Нативные рыскание / кватернион GraspNet ухудшили object_2. Блокер — реальная стабильность контакта при переносе, а не сегментация SAM3.
Обучение и оценка ACT obj321 servo, 2026-05-21:
Набор данных есть: datasets/atec_task_e_obj321_servo_100demos/trajectory.hdf5 (около 122 ГБ) и trajectory_filtered.hdf5 (около 33 ГБ).
Обучение завершено: запуск runs/act-task-e-rgb-obj321-servo-100demos-seed1, checkpoint вплоть до final.pt; символическая ссылка на журнал обучения logs/task_e_obj321_servo_pipeline.latest.
Контрольный checkpoint для отправки уже установлен: SHA256 demo/policy_act.pt совпадает с runs/act-task-e-rgb-obj321-servo-100demos-seed1/checkpoints/best_loss.pt (76bbef2c81c85fc6cc60448476ff09075ec8bc97217c2d2fb70a3253fd3e307d).
Оценка с реальными наблюдениями: один эпизод final.pt дал 6.00, видео logs/videos/task_e_act_eval/obj321_servo_final_1ep_20260521_realobs.mp4. Для best_loss.pt один эпизод дал успешные 18.00, видео logs/videos/task_e_act_eval/obj321_servo_bestloss_3ep_20260521_realobs.mp4, но независимые повторы в отдельных процессах дали 6/12/12; поэтому ожидаемый балл оценивать примерно в 10–12 с редкими 18, пока не устойчиво.
Известная ловушка оценки: многоэпизодный сброс в одном процессе может давать некорректные последующие эпизоды с steps=1; для надёжных оценок по эпизодам использовать отдельные процессы Python.
Настройка инференса, ночь 2026-05-21: demo/solution_act.py теперь поддерживает переменные окружения ATEC_ACT_TEMPORAL_AGG=0, ATEC_ACT_PREFER_NEW=1 и ATEC_ACT_TEMPORAL_K=<float> без изменения поведения по умолчанию. scripts/act/eval_task_e_act.py теперь поддерживает --seed и печатает в конце статус объектов [BASKET].
Быстрые проверки с фиксированными seed для best_loss.pt: prefer-new (ATEC_ACT_PREFER_NEW=1 ATEC_ACT_TEMPORAL_K=0.05) дал 6/15/0 на seeds 11/12/13; no-agg (ATEC_ACT_TEMPORAL_AGG=0) сначала дал 6/9/15 без отладки корзины, но повторный прогон seed13 с отладкой дал 0 и показал, что все объекты по-прежнему вне корзины. Нужны более контролируемые перебор seed, прежде чем менять значения по умолчанию при инференсе отправки.
Запущено обучение ACT seed2 с существующего отфильтрованного набора данных, без нового сбора: пользовательский юнит systemd atec-task-e-act-seed2-20260521225511.service, журнал logs/task_e_act_seed2_20260521225511.log, имя запуска act-task-e-rgb-obj321-servo-100demos-seed2.
Промежуточные оценки seed2: 5000.pt на фиксированном seed 11 дал 0.00 (все объекты вне корзины); тогдашний best_loss.pt дал 6.00, только object_3 внутри. 10000.pt на seed 11 дал 0.00. 15000.pt на seed 11 тоже 0.00; видео logs/videos/task_e_act_eval/seed2_15000_seed11.mp4. 20000.pt на seed 11 дал 6.00, только object_3 внутри; видео logs/videos/task_e_act_eval/seed2_20000_seed11.mp4. Не заменять demo/policy_act.pt на seed2, пока последующие checkpoint не докажут превосходство. Обучение продолжилось после Iter 20000, последний логированный loss около 0.020.
2026-05-22 01:12 CST: seed2 дошёл до 30000.pt; loss около 0.0158, best_loss.pt обновлён. Попытка оценки на фиксированном seed 11 logs/eval_task_e_seed2_30000_seed11.log недействительна: GPU уже был занят примерно на 91/98 ГБ из-за посторонних процессов Ray/FSDP, которые использовали около 76 ГБ; Isaac/Warp получил CUDA OOM и перешёл на программную физику. Процесс оценки был убит до завершения; не считать это ни успехом, ни провалом модели. Следующую надёжную оценку seed2 делать, когда будет достаточно свободной CUDA-памяти или когда стороннее задание Ray закончится; не останавливать seed2, потому что в scripts/act/train_task_e.py тогда не было аргумента возобновления.
2026-05-22 01:19 CST: корректная оценка на CUDA 30000.pt seed2 с фиксированным seed 11 дала 0.00; все объекты вне корзины. Видео: logs/videos/task_e_act_eval/seed2_30000_seed11_valid.mp4. Исходный сервис seed2 затем завершился с кодом статуса 143 примерно на итерации 30400, поэтому последним полным checkpoint остался 30000.pt.
Добавлена поддержка возобновления в scripts/act/train_task_e.py и scripts/act/run_task_e_pipeline.sh: --resume_checkpoint, --resume_iter и переменные окружения RESUME_CHECKPOINT / RESUME_ITER. Новые checkpoint сохраняют train_iter, состояние оптимизатора, планировщика и EMA; старые checkpoint могут возобновить веса со свежим оптимизатором. Smoke-тест пройден: logs/train_task_e_resume_smoke_seed2_30000.log, запуск runs/act-task-e-resume-smoke-seed2-30000.
Запущено продолжение seed2 с возобновлением: юнит systemd atec-task-e-act-seed2-resume-20260522013429.service, журнал logs/task_e_act_seed2_resume_20260522013429.log; команда возобновляет с runs/act-task-e-rgb-obj321-servo-100demos-seed2/checkpoints/30000.pt с RESUME_ITER=30000 и TOTAL_ITERS=100000.
Статус возобновления 2026-05-22 01:52 CST: сервис загрузил 100 траекторий (169700 шагов по времени), возобновился с итерации 30000 и дошёл примерно до Iter 31000; загрузка GPU 100%, процесс 722380 занимал около 13 ГБ видеопамяти. Новые 30000.pt / best_loss.pt занимают около 333 МБ, потому что теперь включают состояние оптимизатора / планировщика / EMA.
Оценка возобновлённого seed2: 35000.pt существует, корректная оценка на seed 11 дала 0.00 (logs/eval_task_e_seed2_35000_seed11_valid.log); все object_1/2/3 вне корзины. Seed2 на 35k не развёртывать. Продолжать обучение к 50k/100k, а более поздние checkpoint или best_loss оценивать, когда GPU не перегружен.
Снимок best_loss seed2 от 2026-05-22 02:22 (runs/act-task-e-rgb-obj321-servo-100demos-seed2/checkpoints/best_loss_snapshot_20260522_022223.pt, sha256 5e52307e84684a98429273102e136f0398e458ab1bd02a0dc6efc025493d4f02) дал 12.00 на seed 11 (logs/eval_task_e_seed2_bestloss_snapshot_20260522_022223_seed11.log): object_2 и object_3 внутри, object_1 вне. Это лучше, чем 35000.pt, но всё ещё недостаточно, чтобы заменить XSA; перед развёртыванием оценить более поздние best_loss / 50k по нескольким seed.
Статус возобновления 2026-05-22 02:32 CST: обучение достигло примерно Iter 41200; 40000.pt существует (runs/act-task-e-rgb-obj321-servo-100demos-seed2/checkpoints/40000.pt). Оценки 40k ещё не было, потому что GPU была загружена другим заданием Ray/FSDP (около 70 ГБ) плюс обучением seed2; ждать 50k или явного окна GPU.
Снимок best_loss seed2 от 2026-05-22 02:35 (runs/act-task-e-rgb-obj321-servo-100demos-seed2/checkpoints/best_loss_snapshot_20260522_023530.pt, sha256 4048a27189b6539e9c5a699ae39eb4e2ea9496e197649d5fa5434141b5495ad7) дал лишь 6.00 на seed 11 (logs/eval_task_e_seed2_bestloss_snapshot_20260522_023530_seed11.log): только object_3 внутри. Более низкий loss обучения не коррелировал с лучшим баллом задачи; этот снимок не развёртывать.
Оценки пронумерованных checkpoint seed2 после возобновления: 45000.pt дал 18.00 на seed11, но 0.00 на seed12; 50000.pt дал 15.00 на seed11 и 6.00 на seed12. Это всё ещё слишком нестабильно, чтобы заменить текущий XSA-кандидат. Продолжать обучение и оценивать более поздние checkpoint; object_1 остаётся главным недостающим звеном.
Статус возобновления 2026-05-22 03:24 CST: 55000.pt существует, одновременно обновился best_loss.pt, но оценки 55k не проводилось, поскольку 45k и 50k уже показали нестабильность. Следующий плановый гейт оценки — 75k или финальный / 100k, если обучение не упадёт.
Статус возобновления 2026-05-22 04:00 CST: обучение дошло примерно до Iter 64300; 60000.pt существует, best_loss.pt обновлён около 03:58:59. Оценки 60k не было; продолжать до гейта 75k.
Оценка 75000.pt seed2 на seed 11 дала лишь 6.00 (logs/eval_task_e_seed2_75000_seed11.log): только object_3 внутри. Не тратить больше оценок seed12/13 на 75k; ждать финальный / 100k или конкретный перспективный снимок.
Проверки seed2 в середине и конце, 2026-05-22: 85000.pt на seed11 дал 0.00 (logs/eval_task_e_seed2_85000_seed11.log), а тогдашний best_loss.pt примерно на итерации 87300 дал 15.00 (logs/eval_task_e_seed2_bestloss_87300_seed11.log): object_2 и object_3 внутри, object_1 вне. Это подтверждает, что loss обучения и балл задачи слабо связаны; object_1 остаётся главным блокером, а одного ACT пока недостаточно для стабильного полного балла.
Seed2 завершил 100k 2026-05-22: final.pt, SHA256 36493deefaf05694351db776435c2d53d9fe4a274c4f95febfe0fe8b36fea652, на seed11 дал 0.00 (logs/eval_task_e_seed2_final_seed11.log); последний best_loss.pt, SHA256 f14c9d7c536c1d4156a8603064ec65cc593d8659147da175212fd8d7cbad2950, дал 9.00 на seed11 (logs/eval_task_e_seed2_bestloss_96900_seed11.log, только object_3 внутри). Не развёртывать seed2 вместо текущего кандидата XSA.
Стратегическое решение на 2026-05-22: оставить ACT/XSA как лучшую развёртываемую базу и довести seed2 до 100k ради доказательств, но не считать, что дополнительные итерации ACT дадут стабильные 18. Подготовить ветку дообучения pi0.5 / OpenPI на уже имеющихся демонстрациях HDF5, сконвертированных в формат LeRobot; использовать GraspNet / SAM3 в основном как вспомогательное средство для захвата и генерации данных, если стабильность контакта object_1/2 в ATEC Isaac на реальных наблюдениях / действиях не доказана.
Рабочий вариант XSA final имел лучшие текущие доказательства, но не стабилен на полный балл. Прямая оценка runs/act-task-e-rgb-xsa-100demos-30k-seed11/checkpoints/final.pt дала 15/15/15 на seeds 11/12/13 (object_2 и object_3 внутри, object_1 вне); видео seed11 logs/videos/task_e_act_eval/xsa_final_seed11_recheck.mp4. Тот же checkpoint, позже развёрнутый как demo/policy_act.pt, дал 9 на seed11 и 0 на seed12, значит, есть остаточный недетерминизм / нестабильность контакта. Текущий demo/policy_act.pt: SHA256 XSA final c3eacae3f1b0ec8ccde9fdc05d680fff119cc2ca70e1f79e4ddd5610c4bbfa93; прежний лучший seed1 сохранён как demo/policy_act.seed1_best_backup_20260522_012719.pt.
Ветка pi0.5 / OpenPI для Task E, 2026-05-22:
Репозиторий и окружение OpenPI: $HOME/src/openpi-ebench-clean, окружение Python $HOME/envs/openpi-pi05; запуск с PYTHONPATH=$HOME/src/openpi-ebench-clean/src:$HOME/src/openpi-ebench-clean/packages/openpi-client/src, HF_LEROBOT_HOME=$HOME/projects/robotics_shared/datasets/lerobot, HF_HOME=$HOME/projects/robotics_shared/hf_cache.
Нежелательно: не использовать uv run в репозитории OpenPI; он пытается создать большой локальный .venv и скачать дублирующие пакеты.
Конвертер: scripts/pi05/convert_task_e_hdf5_to_lerobot.py переводит 8D qpos / action ATEC Piper в дополненные до фиксированной базы 16D state/action.{joints,gripper} в OpenPI и пишет три одинаковых потока камер 224x224. Набор для быстрого smoke atec/task_e_obj321_servo_smoke2_stride10_224 записал 343 кадра примерно за 70 секунд и занимает 48 МБ.
Конфигурации OpenPI добавлены в $HOME/src/openpi-ebench-clean/src/openpi/training/config.py: pi05_atec_task_e_smoke_224 и pi05_atec_task_e_s5_224. Основная конфигурация s5_224 использует репозиторий atec/task_e_obj321_servo_100demos_s5_224, размер батча 1, 30k шагов, интервал сохранения 30k, чтобы не плодить checkpoint по 42 ГБ.
Важное исправление: actions в HDF5 ATEC — это env actions (joint_target-default)/0.5, а не абсолютные цели суставов, поэтому все конфигурации OpenPI для ATEC должны сохранять extra_delta_transform=False. Если использовать здесь стандартное преобразование дельты OpenPI, из состояния снова вычитается значение, и обучение идёт на неверной цели.
Smoke-проверка пройдена: статистики нормализации pi05_atec_task_e_smoke_224 записаны в $HOME/projects/robotics_shared/checkpoints/openpi/atec_runs/assets/pi05_atec_task_e_smoke_224/...; обучение на 10 шагов один раз успешно сохранило checkpoint, но временный checkpoint 42 ГБ удалён для экономии диска. Журнал: logs/pi05_atec_task_e_smoke_224_10step_20260522.log.
Добавлен мост инференса: demo/solution_pi05.py общается с сервером websocket OpenPI и переводит наблюдения и действия ATEC в формат 16D с фиксированной базой и обратно. Точка входа оценки: scripts/pi05/eval_task_e_pi05.py. По умолчанию ATEC_PI05_ACTION_REPEAT=5, что соответствует текущему набору для обучения со stride 5 и fps 10. Когда checkpoint уже есть, запускать scripts/pi05/run_pi05_eval_checkpoint.sh <каталог_шага_checkpoint>: он стартует scripts/serve_policy.py policy:checkpoint ..., прогоняет seeds 11/12/13 и записывает видео для seed11.
Вспомогательный сводщик оценок: scripts/pi05/summarize_pi05_eval.py <logs/pi05_eval_*> разбирает логи по seed, выводит баллы и статус корзины по объектам и вызывается автоматически в конце run_pi05_eval_checkpoint.sh.
Запущен формальный сервис конвертации s5: юнит из logs/pi05_convert_task_e_s5_224.latest_unit, журнал из logs/pi05_convert_task_e_s5_224.latest; автоматическое продолжение logs/pi05_s5_train_after_convert.latest_unit ждёт конвертации, затем считает статистики нормализации и обучает pi05_atec_task_e_s5_224. Наблюдатель оценки logs/pi05_100demos_eval_after_train.latest_unit ждёт обучения, затем вызывает CONFIG=pi05_atec_task_e_s5_224 PORT=8017 scripts/pi05/run_pi05_eval_checkpoint.sh <последний_checkpoint>.
Ветка раннего сигнала: конфигурация pi05_atec_task_e_20demos_s5_224 использует репозиторий atec/task_e_obj321_servo_20demos_s5_224, 2k шагов, размер батча 1, без преобразования дельты. Сервис и журнал конвертации: logs/pi05_convert_task_e_s5_224_20demos.latest_unit и .latest; автоматическое продолжение logs/pi05_20demos_train_after_convert.latest_unit ждёт, считает нормализацию и затем обучает; наблюдатель оценки logs/pi05_20demos_eval_after_train.latest_unit ждёт обучения и вызывает CONFIG=pi05_atec_task_e_20demos_s5_224 PORT=8016 scripts/pi05/run_pi05_eval_checkpoint.sh <последний_checkpoint>. Использовать для быстрой проверки жизнеспособности pi0.5 до окончания 100-demo запуска.
Замечание: первый запуск обучения на 20 демонстрациях стартовал под старым именем скрипта atec_task_e_pi05_20demos_s5_224_10k_20260522070624, но загруженная конфигурация уже была исправлена на num_train_steps=2000; имя — косметическое. Позже скрипт исправили, и в будущих именах запусков используется _2k_.
Результат 20 демонстраций: checkpoint .../pi05_atec_task_e_20demos_s5_224/atec_task_e_pi05_20demos_s5_224_10k_20260522070624/1999 дал 0/0/0 на seeds 11/12/13. Журналы: logs/pi05_eval_20260522074137; видео: logs/videos/task_e_pi05_eval/pi05_pi05_atec_task_e_20demos_s5_224_seed11_20260522074137.mp4. Каталог checkpoint 20 демонстраций размером 42 ГБ удалён после оценки для экономии диска; набор данных и журналы сохранены.
Статус формального запуска на 100 демонстрациях, 2026-05-22 08:56 CST: конвертация и статистики нормализации завершены; юнит обучения atec-pi05-s5-train-after-convert-20260522065716.service активно выполняет scripts/train.py pi05_atec_task_e_s5_224 --exp-name atec_task_e_pi05_s5_224_30k_20260522065716 --overwrite. Последний наблюдаемый прогресс около 731/30000 шагов при примерно 3.3–3.6 it/s, загрузка GPU 100%, около 80 ГБ видеопамяти. Журнал: logs/pi05_train_task_e_s5_224_20260522065716.log.
Гейт checkpoint / оценки для 100 демонстраций: конфигурация pi05_atec_task_e_s5_224 сохраняет только на шаге 30000 (save_interval=30000), ожидаемый финальный каталог .../checkpoints/pi05_atec_task_e_s5_224/atec_task_e_pi05_s5_224_30k_20260522065716/30000. Юнит-наблюдатель atec-pi05-100demos-eval-after-train-20260522070900.service ждёт юнит обучения, затем запускает CONFIG=pi05_atec_task_e_s5_224 PORT=8017 scripts/pi05/run_pi05_eval_checkpoint.sh <checkpoint> для seeds 11/12/13 и записывает видео seed11.
Гейт решения о развёртывании: текущая развёрнутая база ACT/XSA — demo/policy_act.pt, SHA256 c3eacae3f1b0ec8ccde9fdc05d680fff119cc2ca70e1f79e4ddd5610c4bbfa93. Не заменять её pi0.5, если checkpoint pi0.5 на 100 демонстрациях не имеет реальных оценок в ATEC Isaac на seeds 11/12/13 и явно лучше. Обязательные артефакты завершения этой ветки: каталог финального checkpoint, logs/pi05_eval_* с [RESULT] и [BASKET] для seeds 11/12/13 и logs/videos/task_e_pi05_eval/pi05_pi05_atec_task_e_s5_224_seed11_*.mp4.
Вспомогательный сравнитель после оценки: scripts/pi05/compare_pi05_vs_act_baseline.py <logs/pi05_eval_*> --repo <repo> сравнивает логи seed pi0.5 с текущими доказательствами ACT/XSA (eval_task_e_xsa_final_seed11/12/13_recheck.log и повторная проверка развёрнутого seed11) и выводит HOLD_ACT_XSA, если pi0.5 явно не лучше. scripts/pi05/run_pi05_eval_checkpoint.sh вызывает его автоматически после summarize_pi05_eval.py. Проверено на неудачной оценке 20 демонстраций: корректно выдал HOLD_ACT_XSA.
Результат 100 демонстраций, 2026-05-22 11:27 CST: checkpoint .../pi05_atec_task_e_s5_224/atec_task_e_pi05_s5_224_30k_20260522065716/29999 (около 42 ГБ) оценён в logs/pi05_eval_20260522112701: seed11 — 0.00, seed12 — 0.00, seed13 — 6.00 (среднее 2.00). Видео seed11: logs/videos/task_e_pi05_eval/pi05_pi05_atec_task_e_s5_224_seed11_20260522112701.mp4. Сравнительный помощник вывел HOLD_ACT_XSA; не развёртывать pi0.5 вместо текущего XSA.
Мониторинг: старая автоматизация-«сердцебиение» atec-task-e-seed2-resume-monitor удалена после завершения обучения и оценки pi0.5 на 100 демонстрациях, поскольку отслеживаемая ветка завершена. Создавать новый монитор только при запуске другого длительного обучения.
Обязательный PYTHONPATH: каталоги исходного кода IsaacLab в $HOME/envs/genmanip-isaac5-py311/lib/python3.11/site-packages/isaaclab/source/*, а также source/atec_rl_lab и scripts/act этого репозитория.
Текущая базовая линия ACT:
Объект 3 работает только с набором datasets/atec_task_e, запуском runs/act-task-e-rgb-100demos-seed1, наблюдаемый балл оценки около 6.
Видео базовой оценки: logs/videos/task_e_act_eval/current_single_object_6pt.mp4.
Состояние скриптованного оракула:
Комментарий официального / локального сборщика Task E говорил, что объект 3 работает, а для объектов 1/2 нужны изменения дистанции.
Пределы суставов захвата Piper, наблюдённые 2026-05-20: joint7 — [0.0, 0.035], joint8 — [-0.035, 0.0]. Использовать допустимую цель закрытия [0.0, 0.0], а не [-0.015, 0.015].
Для объекта 2 ранее наблюдался кандидат корзины: смещение (dx=0.006, dy=0.046), z=0.045, carry_z=TABLE_TOP_Z+0.075, place_z=TABLE_TOP_Z+0.075, target_y=-0.24, yaw=-pi/2, захват держать закрытым во время переноса. Считать это непрочным и вероятно скорее толканием / скольжением, чем настоящим подъёмом: 2026-05-20 повторный trace показал, что ранний поиск использовал RNG, зависящий от индекса кандидата, поэтому успех мог быть привязан к конкретному положению.
2026-05-20 13:47 поиск кандидатов для object_2: первые 20 не удались при фиксированном seed пробы. Лучший — cand 011 (dx=0.030, dy=0.026, z=0.045, carry_z=TABLE_TOP_Z+0.075, target_y=-0.24, yaw=+pi/2), итог (1.224,-0.009,1.213), reward_lifted=True, вне корзины на dy=+0.291. Object_2 ещё не готов для сбора демонстраций / обучения.
Object_1 на 2026-05-20 не решён. Прежние кандидаты поиска в основном толкали / скользили объект; один лишь провал корзины был слишком слабым доказательством настоящего захвата. Добавлять и сохранять диагностику по стадиям, прежде чем доверять любому кандидату object_1.
Важные локальные изменения:
scripts/act/eval_task_e_act.py оценивает ACT и может записывать видео.
demo/solution_act.py поддерживает ATEC_ACT_POLICY_PATH и reset_episode().
scripts/act/cli_args.py добавляет --max_attempts; scripts/act/collect_demos_task_e.py использует его и печатает статус корзины по объектам.
scripts/act/task_e/collector.py использует _BASKET_MAX_Z = TABLE_TOP_Z + 0.15, имеет basket_status_lines и при trace=True может возвращать численные диагностики trace: изменение z объекта, расстояние до gripper_base, метрики центра тела пальцев link7/link8 и зазора.
scripts/act/search_task_e_grasps.py — точка входа для банка кандидатов и поиска по каждому объекту.
scripts/act/search_task_e_grasps.py должен держать seed испытаний независимыми от индекса кандидата, чтобы кандидаты сравнивались на одинаковых положениях объекта.
scripts/act/search_task_e_grasps.py печатает [BEST] даже тогда, когда ни один кандидат не успешен, используя как отладочную оценку расстояние до корзины плюс изменение z.
scripts/act/search_task_e_grasps.py поддерживает --start_candidate, чтобы возобновлять долгий поиск без повторной проверки уже пройденных кандидатов.
scripts/act/search_task_e_grasps.py теперь поддерживает переопределения push_x/push_y/push_z для каждого кандидата и переопределения числа шагов close/lift/transport/place/open. Используется для проверки времени траектории без правки глобальной конфигурации в каждом испытании.
scripts/act/task_e/state_machine.py теперь поддерживает сервоконтроль объекта при переносе / укладке / раскрытии для object 1/2: OBJ_SERVO_TO_BASKET_STATES, OBJ_SERVO_XY_GAINS и OBJ_SERVO_MAX_XY в scripts/act/task_e/config.py. Коррекция на стадии TRANSPORT нарастает по прогрессу состояния, чтобы не вырвать объект из захвата.
scripts/act/collect_demos_task_e.py теперь отключает камеры по умолчанию и cfg.observations.image, если need_camera=False; это исправляет сбор без графического интерфейса без --enable_cameras.
Последний trace для object 1:
2026-05-20 13:19: кандидаты переднего поиска 1–12 все провалились: lifted=False, reward_lifted=False, z_gain около 0.000–0.003 м; лучший кандидат — 004, но итоговое y=0.210, далеко от корзины. Следующий поиск возобновить с кандидата 13, чтобы проверить резервные кандидаты толкания / подметания.
2026-05-20 13:24: кандидаты переднего поиска 13–24 проверяли резервное толкание / подметание. Успеха по корзине пока нет, но контакт реален: кандидат 019 (dx=0.040, dy=0.140, z=-0.020, carry_z=TABLE_TOP_Z+0.035, target_y=-0.240, yaw=0, push_y=-0.18) дал lifted=True, reward_lifted=True, z_gain=0.388, итоговая позиция около (1.276, -0.072, 1.260). Он уходит вверх и за пределы корзины, поэтому следующий поиск нужно уточнить вокруг push_y -0.14..-0.18, понизить поведение переноса / укладки и, возможно, попробовать статичный релиз над корзиной.
2026-05-20 13:36: сфокусированные кандидаты 25–34 вокруг кандидата 019 все провалились. Лучший — кандидат 034: dx=0.040, dy=0.140, z=-0.020, carry_z=TABLE_TOP_Z+0.035, target_x=-0.17, target_y=0.0, push_y=-0.18, итог (1.280,-0.064,1.257), reward_lifted=True, но всё равно вне корзины на dy=+0.236.
2026-05-20 13:42: проверки времени с более длинными / низкими переопределениями TRANSPORT и PLACE/OPEN все провалились. Лучший — кандидат 002 с transport_steps=900, итог (1.280,-0.042,1.257), вне корзины на dy=+0.258. Это показывает, что простое удлинение толкания / подметания не решает object 1: геометрия контакта проскальзывает и сбрасывает коробку до укладки в корзину.
2026-05-20 14:15: сервоконтроль объекта с нарастанием не сработал для первых 8 кандидатов object 1. Лучший — кандидат 003 (push_y=-0.14, transport_steps=1200), итог (1.294,-0.020,1.270), reward_lifted=True, вне корзины на dx=+0.214, dy=+0.280. Object 1 по-прежнему нужен другой примитив контакта / захвата, а не более сильный глобальный сервоконтроль.
Последний trace для object 2:
2026-05-20 14:14: сервоконтроль с нарастанием сделал успешным кандидата 001 при поиске с фиксированным seed для object 2: итог (1.050,-0.272,0.865), inside=True, z_gain=0.102, кандидат {dx=0.006, dy=0.046, z=0.045, carry_z=TABLE_TOP_Z+0.075, target_y=-0.24, yaw=-pi/2}.
2026-05-20 14:20: случайный сбор only_success для object 2 всё ещё провалился 0/4 попыток: ошибки конечного y оставались около +0.206..+0.310, одно раннее завершение. Object 2 перспективен, но пока недостаточно устойчив для набора данных / обучения.
2026-05-20 14:26: добавление удержания стадии PLACE до приближения к корзине всё ещё дало провал случайного сбора object 2: 0/4; ошибки конечного y около +0.206..+0.334.
2026-05-20 14:28: более сильный сервоконтроль object 2 (gain=1.15, max_xy=0.36, TRANSPORT=480) тоже дал 0/4 и ухудшил дрейф по x; вернулись к более мягким значениям сервоконтроля, на которых был успех при фиксированном seed (gain=0.85, max_xy=0.24, без переопределения transport). Дальнейшая работа с object 2 должна идти по устойчивости захвата / контакта до переноса, а не по более сильному сервоконтролю корзины.
2026-05-20 14:41: проверка кандидатов object 2 с несколькими seed (--trials 3 --max_candidates 12) не нашла ни одного устойчивого кандидата (0/12). Кандидат, успешный при фиксированном seed, провалился сразу при более строгой проверке (result=0/3, ошибка конечного y около +0.262). Лучший — yaw 0.0 с z_gain=0.355, но итог (1.197,-0.001,1.277), вне корзины на dy=+0.299. Считать object 2 нестабильным по контакту / захвату, а не ограниченным сервоконтролем переноса.
Текущее диагностическое суждение:
Сначала не интегрировать GraspNet. Для этой маленькой трёхобъектной симуляционной задачи воспроизводимый скриптованный банк кандидатов с явной диагностикой подъёма / захвата быстрее и легче проходит проверку воспроизводимости при код-ревью.
Если object 1 остаётся заблокированным, сначала собрать / обучить object 2+3 ради практического прироста балла, затем вернуться к object 1. Дальнейшая работа с object 1 должна менять примитив движения / режим контакта, а не просто перебирать статичные смещения или увеличивать время переноса.
Полезные команды проверки:
Отладочное видео для одного object 1: python scripts/act/collect_demos_task_e.py --pick_objects 1 --num_demos 1 --max_attempts 3 --headless --enable_cameras --only_success --save_video --video_dir logs/videos/task_e_oracle_obj1_fixed --output_dir logs/debug_task_e_obj1_fixed.
https://github.com/fiveages-sim/lerobot_ros2 — публичный репозиторий интеграции ROS2 / LeRobot. Предоставляет общие обёртки ROS2 для роботов и камер и примеры с YAML-навыками single_arm.pick/place, но не даёт готового планировщика захвата, совместимого с ATEC Piper. Его подмодуль robot_action_composer приватный и недоступен по клонированию через HTTPS в этом окружении.