Сортировочная ячейка Isaac Sim: CV-пайплайн и меши товаров

Замкнутый контур "поток -> CV -> механика": товары идут по конвейеру с шагом 700 мм,
класс определяется стереопайплайном во время движения, пушер и плуг реагируют физически.

Состав:
* control_test/ - ячейка и CV. run_sorting_cv.py + cv_worker.py (два процесса, потому что
  torch внутри Isaac роняет сцену), cell.py (физика лент, плуга, пушера), measure_plane.py
  (замер габаритов), README.md и .memory.md с замерами, проблемами и ловушками
* robozon_sorter/ - модули симуляции, scripts/ - утилиты, scene/ - сцены
* assets/ - меши товаров, плуг, объекты Objaverse

Бейзлайн CV: DEFOM-Stereo vitl, вход 480, iters 24, кроп зоны осмотра, без сегментации.
На потоке 700 мм - классы 8/9, габариты MAE 32.8 мм, 469 мс на товар при такте 700 мс.

Веса моделей (4.5 ГБ) и пропсы конвейера NVIDIA (274 МБ) не включены - источники и
команды скачивания в MODELS.md. Выход прогонов (captures/, runtime/) не включён:
воспроизводится.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

control_test/README.md

@@ -0,0 +1,493 @@
+# control_test — сортировочная ячейка с папкой объектов
+
+Автономный стенд: конвейер + пушер + плуг из `plow_cell_90_45_test.usd`, где **набор
+товаров берётся из папки `items/`**. Положили новый `.usd` — он попадает в следующий
+прогон. Ничего не зашито под конкретный объект.
+
+```
+control_test/
+├── scene/plow_cell_90_45_test.usd   сцена (ссылается на ../assets → симлинк на assets проекта)
+├── items/                            меши товаров: *.usd + textures/ + labels.json
+├── classify.py                       чтение разметки + правила B/C/D (для проверки)
+├── cell.py                           физика ячейки: ленты, плуг, пушер, стыки, свет, пол
+├── run_pipeline.py                   прогон сортировки: спавн из items/ по очереди, отчёт
+│
+│   ── стенд замера габаритов камерами (раздел 9) ──
+├── cam_configs.py                    расстановки камер; DEFAULT = "E60" — рабочая
+├── capture_roi.py                    ЭТАП 1 в Isaac: рендер L/R по всем ригам
+├── measure_roi.py                    ЭТАП 2 отдельным процессом: FastSAM + CREStereo
+├── captures/<CFG>/                   кадры, manifest.json, roi_compare.json
+│
+│   ── замкнутый контур: поток -> CV -> механика (раздел 10) ──
+├── run_sorting_cv.py                 прогон сцены: поток, ворота, пушер, плуг по классу от CV
+├── cv_worker.py                      процесс CV: DEFOM -> габариты -> k -> класс
+├── measure_plane.py                  сам замер; здесь зафиксирован бейзлайн
+├── runtime/                          обмен заявками и ответами, кадры, результат прогона
+├── .memory.md                        СОСТОЯНИЕ ПАЙПЛАЙНА: замеры, проблемы, ловушки
+│
+└── diag/                             одноразовые диагностики, не часть пайплайна
+```
+
+**Устаревшие файлы** помечены заголовком `SUPERSEDED` и оставлены только как история:
+`capture_cfg.py` (тихо снимал пустую ленту), `measure_cfg.py` (мерил ленту вместо
+товара), `reposition.py` (зашитые 600 мм). Использовать их нельзя.
+
+## 1. Запуск Isaac Sim
+
+Isaac Sim 6.0.1 стоит под пользователем `whatevenif`, запускается со стримингом WebRTC
+и включённым python-сервером (TCP 8226) — через него в симулятор шлётся код.
+
+```bash
+cd /home/whatevenif/isaacsim
+nohup ./kit/kit ./apps/isaacsim.exp.full.streaming.kit \
+    --no-window --no-ros-env \
+    --enable isaacsim.code_editor.python_server \
+    --/exts/omni.kit.livestream.app/primaryStream.publicIp=46.39.224.77 \
+    --/exts/omni.services.livestream.session/quitOnSessionEnded=false \
+    > /tmp/isaac.log 2>&1 &
+```
+
+Готовность:
+
+```bash
+grep -q "app ready" /tmp/isaac.log && ss -ltn | grep 8226   # порт должен слушать
+```
+
+С другой машины порт 8226 пробрасывается ssh-туннелем:
+
+```bash
+ssh -N -L 8226:127.0.0.1:8226 dasha@46.39.224.77 &
+```
+
+## 2. Открыть сцену
+
+```bash
+cd /home/dasha/robozon-sorter
+python3 isaacsim_send.py --timeout 120 \
+    --file ~/.claude/skills/isaac-sim-remote/scripts/open_stage.py \
+    --arg action=open \
+    --arg usd_path=/home/dasha/robozon-sorter/control_test/scene/plow_cell_90_45_test.usd
+```
+
+Должно ответить `Stage prims: 366`. Сцену надо открывать **заново перед каждым прогоном** —
+`run_pipeline.py` меняет состояние сцены (удаляет графы, снимает коллизии, спавнит тела).
+
+## 3. Прогон
+
+```bash
+cd /home/dasha/robozon-sorter
+python3 isaacsim_send.py --context ct --timeout 400 --execution-timeout 390 \
+    --file control_test/run_pipeline.py
+```
+
+Только часть объектов / другие параметры:
+
+```bash
+python3 isaacsim_send.py --context ct --timeout 400 --execution-timeout 390 \
+    --args-json '{"only": ["bag","lunchbox"], "pitch": 1.4, "plow_angle": 20}' \
+    --file control_test/run_pipeline.py
+```
+
+| аргумент | по умолчанию | что делает |
+|---|---|---|
+| `speed` | 1.0 | скорость лент, м/с |
+| `pitch` | 1.4 | расстояние между товарами, м |
+| `plow_angle` | 20 | угол плуга, град (B = −угол, C = +угол) |
+| `swing_margin` | 0.25 | доля T_pitch на поворот; меньше → быстрее плуг |
+| `plow_hold_max` | 4.0 | сколько плуг держит угол, с |
+| `only` | все | список имён объектов |
+| `limit` | 0 | взять первые N |
+
+## 4. Как добавить свой товар
+
+1. Положить `<имя>.usd` в `items/` (текстуры — в `items/textures/`).
+2. Дописать строку в `items/labels.json`:
+
+```json
+"my_part": { "zone": "D", "dims_mm": [220, 180, 175], "k": 0.91 }
+```
+
+3. Прогнать — товар подхватится сам.
+
+**Классы берутся из разметки, а не измеряются.** Меши обнаруживаются в папке и
+спавнятся из неё, но `zone`, `dims_mm` и `k` читаются из `labels.json` — это ground
+truth, относительно которого проверяется механика.
+
+Почему не автозамер: он был реализован и отброшен. Габариты мерились точно (сверено со
+всем каталогом: `pen` 148.5/13.2/9.0 против 148/13/9, `pouf` 488.9 против 489), но
+геометрическая оценка круглости систематически занижала тела с ручкой или полостью —
+`bucket` 0.737 против 0.995, `mug` 0.731 против 0.985, `cylinder` 0.749 против 0.867.
+Класс D тихо превращался в B, и это выглядело как отказ механики. Совпадение с каталогом
+было 20/25. Для стенда, где проверяется именно механика, надёжнее читать метку.
+
+**Товары без записи в `labels.json` пропускаются** — не угадываются. Прогон печатает их
+списком; сейчас это 12 мешей (`air_conditioner`, `briefcase_hard`, `carton_large`,
+`cleat_small`, `clothespin_flat`, `cooler_cube`, `duffel_round`, `nailfile_mini`,
+`printer_compact`, `safety_pin`, `toaster_compact`, `toaster_oven`).
+
+**Разметка проверяется на согласованность.** `classify.verify_labels()` прогоняет каждую
+запись через правила раздела 5, и прогон печатает `labels consistent with the documented
+B/C/D rules` либо перечисляет расхождения: ошибка в метке иначе всплыла бы как
+необъяснимый сбой механики.
+
+## 5. Правила классификации
+
+Порядок как в пайплайне — сначала D:
+
+* **D** «не подходит без доупаковки» → пушер → BinD.
+  Габариты в норме (как у B), но `k > 0.8` хотя бы в одном сечении.
+* **C** «не подходит по габаритам» → плуг `+angle` → ConveyorTrack_01 → контейнер C.
+  Хотя бы один размер `< 10 мм` **или** не влезает в `450×320×320 мм`. Форма не важна.
+* **B** «подходит для сортировки» → плуг `−angle` → ConveyorTrack_06 → контейнер B.
+  Все размеры в диапазоне `10×10×10 … 450×320×320 мм` и `k ≤ 0.8`.
+
+Влезаемость проверяется по отсортированным габаритам против отсортированной рамки —
+товар можно положить любой гранью.
+
+## 6. Ограничения, которые стоит знать
+
+* **Шаг 0.7 м из ТЗ: класс D работает, B/C — нет.** Замерено на 9 товарах:
+
+  | шаг | B | C | D | итого |
+  |---|---|---|---|---|
+  | 1.4 м | 3/3 | 3/3 | 3/3 | **9/9** |
+  | 0.7 м | 1/3 | 1/3 | 3/3 | 5/9 |
+
+  Причина чисто геометрическая: **лезвие плуга длиной 0.63 м**, и товар «занимает» его
+  0.63 м пути. При шаге 0.7 м на смену угла остаётся 0.7 − 0.63 = **0.07 м (10 % шага)** —
+  это ниже уровня шума физики (товары подрагивают, интервал плывёт), поэтому регулярно
+  два товара разных классов оказываются на лезвии одновременно и второй получает чужой
+  угол.
+
+  **Скорость ленты тут не поможет:** доля занятости = длина_лезвия / шаг = 0.63/0.70 = 90 %
+  и от скорости не зависит — время сокращается пропорционально и у товара, и у лезвия.
+  Реально помогает только шаг: нужен **> ~1.5 × длины лезвия ≈ 0.95 м**. При 1.4 м —
+  100 % по всем классам.
+
+  Укоротить лезвие нельзя «просто так»: его длина и есть вылет, которым он перекладывает
+  товар через ленту шириной 0.9 м. Чтобы держать 0.7 м, нужен другой отводящий орган
+  (второй плуг в шахматном порядке или толкатель вместо плуга).
+
+* **Очень тонкие товары не отрабатывают на плуге.** `watch` (4.2 мм) класса C
+  проехал мимо и остался на линии (x −7.64): лезвие плуга приподнято над полотном, и
+  такой товар проходит под ним. Класс определяется верно, механика — нет.
+* 12 мешей в `items/` не имеют записи в `labels.json` и потому пропускаются
+  (см. раздел 4). Часть из них ещё и обмерена в других единицах, так что
+  зашивать им класс наугад нельзя — нужна честная разметка.
+
+## 7. Что именно чинит `cell.py`
+
+Каждый пункт — отдельная найденная и замеренная проблема, все включены в `prepare()`:
+
+| функция | зачем |
+|---|---|
+| `_kill_stale_graphs` | авторские `ConveyorBeltGraph` / `DiverterAnimGraph` **удаляются**, а не деактивируются: `SetActive(False)` не останавливает уже собранный OmniGraph, и он обнуляет `surfaceVelocity` каждый тик |
+| `configure_belts` | все 7 лент + 4 плиты стыка; `ConveyorTrack_05` (вход линии) и ветка пушера `Belt_01` отсутствовали в списке проекта |
+| `drive_corner_belt` | `ConveyorTrack_06` — **криволинейный** угол (четверть кольца, центр (−8.005, +1.042), радиусы 0.517…1.018). Линейный привод уводил товар в пустую середину кольца, и он проваливался. Направление задано хордой, сохраняющей радиус, и **в мировых координатах** — у ленты неравномерный масштаб, и пересчёт в локальные искажает направление |
+| `add_transfer_bridge` | между краем `_04` (y = +0.45) и началом `_06` (x = −8.00) не было опоры ровно там, где плуг сталкивает товар |
+| `add_container_catchers` | лотки толщиной 40 мм пробивались товаром при падении с ленты (~3.4 м/с ≈ 57 мм за шаг) |
+| `open_junction` | у конвейерной «обшивки» есть коллайдер вместе с бортами — стена ровно там, где товар должен уходить вбок |
+| `regrip_decks` / `_ensure_grip_material` | `configure_plow` перебивает плиты скользким материалом; сам grip-материал проект создаёт только внутри своей `configure_belts`, которую этот модуль не вызывает |
+| `resize_pusher_blade` / `grip_pusher_blade` / `seat_pusher_blade` | нож 1200 → 500 мм; свой цепкий материал вместо скользкого «плужного»; посадка на 1 мм над полотном (было 14 мм — тонкие товары проходили под ним) |
+| `add_ground_and_light` / `add_side_rails` | пол и купольный свет; борта только на прямых участках — на стыках они блокируют штатный сход товара |
+
+## 8. Зависимости
+
+`cell.py` и `run_pipeline.py` импортируют `robozon_sorter` (константы `config.py`, класс
+`Plow`, помощники `sim/scene.py` и `sim/plow_cell.py`), поэтому `/home/dasha/robozon-sorter`
+должен быть в `sys.path` — `run_pipeline.py` добавляет его сам.
+
+`items/` и `scene/` — собственные копии, их правка проект не задевает. `assets` —
+симлинк на `../assets`, потому что сцена ссылается на ленты и плуг относительным путём.
+
+
+## 9. Стенд замера габаритов камерами
+
+Отдельная задача от сортировки: по стереопарам определить габариты **неизвестного**
+товара. Классы тут не читаются из разметки — они и есть то, что надо предсказать.
+
+### 9.1 Рабочая расстановка — E60
+
+| параметр | значение |
+|---|---|
+| высота над лентой | **700 мм** (все три рига) |
+| возвышение | **60°** |
+| рабочая дистанция | **808 мм** |
+| азимуты | **90° / 208.3° / 330°** (RealSense D435 / Gemini305 / Gemini345) |
+| точка осмотра | `(-0.750, 0.0, 1.781)` — поверхность `ConveyorTrack_04` |
+
+Зафиксирована в `cam_configs.DEFAULT` и записана в саму сцену. Применить заново:
+
+```bash
+python3 isaacsim_send.py --file /tmp/save_e60.py     # apply_config(stage, CC.DEFAULT)
+```
+
+Калибровка проверена: поворот левой и правой камеры в паре совпадает точно
+(отклонение 0.0e+00), база равна паспортной с нулевой поперечной составляющей,
+Δv между кадрами 0.000 px — то есть `depth = fx·B/disp` применим без ректификации.
+
+Цена глубины на 808 мм: Gemini345 8.0 мм/px, D435 13.2, Gemini305 37.2.
+
+### 9.2 Почему именно E60
+
+Развёртка по возвышению при фиксированной высоте 700 мм и, отдельно, попытка дать
+каждому ригу свою дистанцию под одинаковую цену глубины (EQ15/EQ20). Медиана MAE по
+9 товарам, слияние трёх ригов:
+
+| конфиг | возвыш. | дистанция | MAE медиана | D435 | Gemini305 | Gemini345 |
+|---|---|---|---|---|---|---|
+| A_original | 42° | 1051 мм | 30.0 | 29.3 | **109.5 (1/9)** | 67.4 (5/9) |
+| E45 | 45° | 991 мм | 25.5 | 29.9 | 50.8 (1/9) | 32.8 |
+| **E60** | **60°** | **808 мм** | **22.3** | **25.8** | **27.1** | **28.0** |
+| E75 | 75° | 726 мм | 23.6 | 27.8 | 26.3 | 29.4 |
+| EQ15 | 45° | 518/863/1146 | 29.8 | 42.2 | 31.3 | 30.9 |
+| EQ20 | 45° | 598/996/1323 | 24.6 | 33.4 | 28.2 | 32.7 |
+
+Два вывода, на которых всё держится:
+
+* **Gemini305 не нужна своя короткая дистанция.** На 1051 мм он давал облако один раз
+  из девяти, потому что диспаратность в точке осмотра была всего 17 px. На 808 мм она
+  21.7 px и риг работает наравне с остальными. Попытка подобрать каждому ригу свою
+  дистанцию (EQ15/EQ20) починила Gemini305, но испортила D435 (25.8 → 42.2) и сделала
+  слияние хуже любой общей дистанции.
+* **E60 — первая расстановка, где слияние трёх ригов выигрывает у лучшего одиночного**
+  (22.3 против 25.8). На 1051 мм слияние не давало ничего.
+
+E75 почти не хуже по точности, но его общая зона ленты на треть меньше
+(5756 против 7681 см²) — меньше запас на смещение товара.
+
+### 9.3 Как устроен замер
+
+Два этапа, потому что torch внутри Isaac роняет процесс:
+
+```bash
+# ЭТАП 1 — в Isaac, без torch: рендер L/R со всех шести камер
+python3 isaacsim_send.py --timeout 880 --file control_test/capture_roi.py
+python3 isaacsim_send.py --timeout 880 --file control_test/capture_roi.py --arg cfg=E75
+
+# ЭТАП 2 — отдельным процессом: FastSAM + CREStereo + обратная проекция
+/home/whatevenif/isaacsim/python.sh measure_roi.py            # E60, все 4 варианта ROI
+/home/whatevenif/isaacsim/python.sh measure_roi.py E60 objroi # только рабочая схема
+```
+
+Схема ROI (`objroi`), она же рабочая:
+
+```
+общая зона ленты, видимая всеми 6 камерами
+        ↓  ограничивает, где FastSAM ищет
+FastSAM segment-everything → маска, содержащая «воротный» пиксель
+        ↓  bbox + 48 px запаса
+ОДНО окно колонок на левый и правый кадр, левый край расширен на 1.35 × макс. диспаратности
+        ↓
+CREStereo → диспаратность → depth = fx·B/disp → обратная проекция по экстринсикам
+```
+
+Три правила, каждое подтверждено замером:
+
+* **RGB не маскируется до CREStereo.** Матчеру нужен фон вокруг предмета; маска
+  применяется только к глубине, с эрозией 2 × 3×3, иначе в облако попадает кайма фона.
+* **Левое и правое окно обязаны совпадать.** Контрольный вариант `objroi_bad`, где
+  правый кроп центрируется по своему bbox, разрушил **8 облаков из 9** — сдвиг окна
+  подменяет диспаратность.
+* **Слияние идёт только по калиброванным экстринсикам, без RANSAC/ICP.** Повторная
+  регистрация ухудшала результат в каждой проверке (11.9 → 40.5 мм): три ракурса видят
+  разные поверхности, и ICP совмещает несоответствующие участки.
+
+Общая зона ленты проецируется в 84–92 % кадра, поэтому сама по себе разрешения она не
+экономит — её роль в том, чтобы ограничить область поиска сегментации. Выигрыш даёт
+вторая ступень: `objroi` втрое быстрее полного кадра (519 против 1620 мс на товар) при
+той же точности и не теряет мелкие предметы (`lunchbox` полный кадр терял вовсе).
+
+### 9.4 Эталон габаритов — bbox меша в сцене, не каталог
+
+Меши в `items/` **в 2.0–2.8 раза мельче** своих паспортных размеров, и коэффициент у
+каждого свой (`bag` 2.05, `box_400x400x300` 2.41, `box_300x200x200` 2.79). Для сортировки
+по меткам это безразлично, но оценивать предсказание масштаба против `labels.json`
+нельзя. `capture_roi.py` пишет в манифест оба числа: `gt_scene_mm` (реальный bbox в
+сцене — эталон замера) и `gt_catalogue` (паспорт из `labels.json` — эталон сортировки).
+
+### 9.5 Что не решено
+
+* **Систематическое занижение.** На E60: `pillow` 223 → 138, `bucket` 136 → 101,
+  `backpack` 170 → 158. Подушка худшая во всех шести расстановках (66–77 мм) — плоский
+  мягкий силуэт; у ведра, похоже, снимается кромка, а не корпус. От расстановки камер
+  это не зависит.
+* **Сегментация иногда берёт ленту.** На EQ-расстановках `detergent` дал 157 мм вместо
+  108. Напрашивается отбраковка ракурса по 3D-центроиду: вид, чей центр дальше 6 см от
+  медианы по трём ригам, выбрасывать до слияния (в прошлом пайплайне это помогало).
+* Замерено на 9 товарах из 25 — полный набор ещё не прогонялся.
+
+### 9.6 Ловушки спавна, из-за которых стенд полгода мерил пустую ленту
+
+Обе тихие, обе дают правдоподобные кадры пустого конвейера:
+
+1. **`ClearXformOpOrder()` на приме, который несёт ссылку**, стирает собственное
+   размещение меша. Замер bbox до очистки и последующий перенос дают промах ровно на
+   этот сдвиг — товары уходили на 0.6 м под полотно. Ссылка должна жить на **дочернем**
+   приме, размещение — на родителе.
+2. **Слои товаров прописывают `visibility = invisible` на своём корне**, а
+   `MakeVisible()` на родителе авторское значение потомка не снимает. Нужно пройти
+   `Usd.PrimRange` и выставить `inherited` всем Imageable.
+
+Плюс: `BBoxCache.ComputeWorldBound()` на только что созданном родителе возвращает пустой
+диапазон даже при скомпонованном потомке — мерить надо сам прим со ссылкой; и ссылка не
+компонуется в том же тике, нужен цикл `await app_utils.update_app_async(steps=2)`.
+
+Поэтому `capture_roi.py` печатает **контраст**: разницу средней яркости внутри ожидаемого
+силуэта и в кольце вокруг него, по каждой камере. Меньше 3 — товар не отрендерился,
+строка помечается `<-- НЕ ВИДЕН`. Без этой проверки четыре круга «настройки сегментации»
+были потрачены на кадры, где предмета не было вовсе.
+
+---
+
+## 10. Замкнутый контур: поток → CV → механика
+
+Полный прогон, где класс товара приходит **от стереопайплайна во время движения**, а не из
+`labels.json`. Пушер и плуг реагируют физически на предсказанный класс. Разметка нужна
+только для подсчёта ошибки в конце.
+
+Прежний `run_pipeline.py` (классы из разметки) остаётся рабочим и служит контролем: он
+разделяет ошибки механики и ошибки распознавания.
+
+Подробное состояние пайплайна, все замеры и открытые проблемы — в `.memory.md`.
+
+### 10.1 Два процесса
+
+torch внутри Isaac роняет процесс, поэтому CV живёт отдельно, а обмен идёт через каталог
+`runtime/`:
+
+```
+run_sorting_cv.py  (в Isaac, без torch)        cv_worker.py  (отдельный процесс, torch+GPU)
+   поток 700 мм при 1 м/с
+   ворота x = -0.750 -> 6 кадров ──заявка──>   runtime/req/<товар>.json
+                                                  DEFOM vitl / вход 480 / iters 24
+                                                  облако -> габариты -> k -> класс
+   класс  <──ответ──  runtime/res/<товар>.json
+   пушер: класс D -> Cell.stroke()
+   плуг:  класс B/C -> Plow.target(-16 / +16)
+```
+
+Времени хватает с запасом: от ворот до пушера товар едет 3.15 с, до плуга 7.10 с, а полная
+задержка от ворот до класса замерена в **0.70 с** (медиана; инференс 631–1284 мс).
+
+### 10.2 Запуск
+
+```bash
+# 1. работник CV. Прогрев ~90 с - грузится vitl-энкодер
+cd /home/dasha/robozon-sorter/control_test
+nohup /home/whatevenif/isaacsim/python.sh cv_worker.py > /tmp/cvworker.log 2>&1 &
+
+# 2. проверить ПО PID, а не по файлу runtime/worker_ready:
+#    файл остаётся от прошлого запуска и даёт ложную готовность
+pgrep -af "python.*cv_worker.py"
+
+# 3. открыть сцену заново (cell.prepare меняет её состояние), затем прогон
+cd /home/dasha/robozon-sorter
+python3 isaacsim_send.py --context cvsort --timeout 2580 --execution-timeout 2560 \
+    --file control_test/run_sorting_cv.py
+```
+
+Результат прогона: `runtime/sorting_cv.json`, кадры товаров `runtime/frames/`,
+обзорный снимок `runtime/shots/overview.png`.
+
+### 10.3 Зафиксированный бейзлайн CV
+
+Значения по умолчанию в `measure_plane.py`:
+
+| параметр | значение |
+|---|---|
+| стереодвижок | **DEFOM-Stereo vitl** (`STEREO=defom`) |
+| вход сети | **480** px по ширине (`SW=480`) |
+| итерации | **24** + `scale_iters` 8 |
+| окно | **кроп зоны осмотра** (`CROP=1`) |
+| сегментация | **не используется** |
+
+Товар отделяется от полотна превышением над плоскостью (20 мм) плюс отсев по плотности:
+товар даёт сплошную поверхность, полотно — редкие выбросы диспаратности. Сегментация не
+участвует вовсе — она была источником и раздутых габаритов, и промахов по классу D.
+
+Веса: `/home/dasha/isaac_assets/cv/defom-stereo/checkpoints/`.
+
+**Замер на статичных кадрах потока 700 мм (9 товаров):** классы 8/9 = 89 %, габариты
+MAE медиана 32.8 мм, 469 мс на товар при такте 700 мс.
+
+**Замер замкнутого контура:** классов получено 7 из 9, верно 5 из 7.
+
+Полная таблица сравнения движков и конфигураций — в `.memory.md`, раздел 2.
+
+### 10.4 Кинематика
+
+* **Ленты 1.0 м/с.** `surfaceVelocity` задаётся в ЛОКАЛЬНОЙ системе тела; у `_04` и `_06`
+  локальный +X смотрит в мировой −X. `ConveyorTrack_06` — криволинейный угол на 90°,
+  направление задаётся хордой в мировых координатах. Проверено: товар 160 мм идёт 7.93 м
+  ровно на 1.00 м/с.
+* **Пушер** — нож двигается записью трансформа (`Cell.blade_to`), призматический сустав
+  выключен: иначе сустав и скрипт тянут нож в разные стороны и он дрожит весь прогон.
+* **Плуг** — лезвие кинематическое, шарнир выключен, угол пишется напрямую
+  (`Plow.target`). Силовой привод не держал: звенел на ±21.4°. Углы
+  `{"B": -16, "C": +16, "D": 0}`, лезвие ставится ЗАРАНЕЕ. Скольжение товара вдоль кромки
+  замерено: 315–350 мм.
+
+### 10.5 Открытые проблемы
+
+1. **Габариты в движении вдвое хуже статичных.** Кроп привязан к неподвижной точке осмотра
+   (−0.750), а товар пересекает её не точно: `detergent` попал на ворота уже на x = −1.708.
+   Товар в кадре смещён, в кроп попадает соседний. Самая вредная из открытых.
+2. **Класс D берётся неустойчиво.** `bucket` не определяется ни одной конфигурацией. На
+   эталонной геометрии меша та же функция даёт 0.934, на нашем облаке 0.66 — разрыв целиком
+   в качестве облака.
+3. **Товары могут не доехать до ворот.** `helmet` и `pillow`, выпущенные подряд, столкнулись
+   у входа: при габаритах 354 и 455 мм шаг 700 мм оставляет мало зазора.
+4. **Пушер выбрасывает товар с линии** при скорости ножа на пределе (`PUSHER_MAX_SAFE` 2.5 м/с).
+5. **Шаг 700 мм механически не даёт B/C** — лезвие плуга 0.63 м, на смену угла остаётся
+   0.07 м. При 1.4 м — 9/9, при 0.7 м — 5/9 (см. раздел 6).
+
+Что уже проверено и **не** помогло (сглаживание контура, проверка лево-право, цилиндр
+RANSAC, отбраковка по центроиду и другое) — перечислено в `.memory.md`, раздел 5.
+
+### 10.6 Сколько товаров доходит до контейнеров
+
+Замер последнего прогона замкнутого контура. Зоны лотков берутся из самой сцены
+(`B_Floor` x −9.26…−8.36 / y +1.07…+1.87; `C_Floor` x −10.90…−10.00 / y −0.63…+0.18;
+`BinD_Floor` x −6.21…−4.95 / y +1.59…+2.85), допуск 0.35 м — падая с ленты, товар может
+лечь у стенки, а не над серединой пола.
+
+**В контейнеры попало 5 из 9. В СВОЙ контейнер — 3 из 9.**
+
+| товар | эталон | CV | конец X, Y | куда попал |
+|---|---|---|---|---|
+| `backpack` | C | C | −10.44, −0.47 | контейнер C — **верно** |
+| `lunchbox` | B | B | −8.95, +1.55 | контейнер B — **верно** |
+| `bag` | D | D | −8.37, +1.03 | контейнер B — класс верный, доставка нет |
+| `bucket` | D | C | −10.64, +0.14 | контейнер C — ошибка CV |
+| `box_300x200x200` | B | C | −10.63, −0.28 | контейнер C — ошибка CV |
+| `box_400x400x300` | C | C | −9.39, −1.49 | остался на линии, за краем лотка |
+| `detergent` | B | B | +262.50, +2085.32 | улетел за пределы ячейки |
+| `helmet` | D | — | +4.02, +0.78 | не доехал до ворот |
+| `pillow` | C | — | +1.15, +0.91 | не доехал до ворот |
+
+### Разложение потерь по причинам
+
+Общая цифра здесь малополезна: причины разные и лечатся по-разному.
+
+| причина | сколько | что именно |
+|---|---|---|
+| ошибка CV | 2 | `bucket` (D→C), `box_300x200x200` (B→C) |
+| класс верный, механика не довела | 1 | `bag` — пушер сработал (есть в логе), но товар остался в лотке B вместо BinD |
+| столкновение на входе | 2 | `helmet` и `pillow` выпущены подряд; при габаритах 354 и 455 мм шаг 700 мм слишком тесен |
+| бросок пушера | 1 | `detergent` — скорость ножа на пределе `PUSHER_MAX_SAFE` = 2.5 м/с |
+| плуг сдвинул недостаточно | 1 | `box_400x400x300` закончил на y = −1.49, за краем лотка C |
+
+**Из четырёх потерь по механике ни одна не связана с распознаванием.** CV ошибся на двух
+товарах из семи, кому вообще выдал класс.
+
+### Фоновое ограничение
+
+При шаге 700 мм классы B и C механически не отрабатывают в принципе: лезвие плуга 0.63 м,
+на смену угла остаётся 0.07 м (10 % шага) — см. раздел 6. Прежний прогон с классами из
+разметки давал при шаге 1.4 м результат **9/9**. То есть значительная часть этих потерь —
+не про CV и не про настройку, а про геометрию плуга, и на шаге 0.7 м она не устраняется
+ни скоростью ленты, ни точностью классификации.
+
+Проверять сквозную доставку осмысленно **на шаге 1.4 м**, а шаг 0.7 м использовать для
+замера классификации и габаритов.