починил переносы в командах, раздельный запуск узла и проигрывания в EXPERIMENTS п. 17.6

README.md

@@ -149,8 +149,10 @@ python tools/compare_benchmark.py было.json стало.json   # правка
 
 ```bash
 python tools/make_training_set.py --new-data 0:110 --out data/cache/training_set_nd.npz
-python tools/train_mbon.py --device cuda --data data/cache/training_set.npz     --data data/cache/training_set_nd.npz --train-only new_data_ --out nd.npz
+python tools/train_mbon.py --device cuda --data data/cache/training_set.npz \
-python tools/eval_new_data.py --shards 110:     --readout было=artifacts/mbon_readout.npz --readout стало=nd.npz --out nd.json
+    --data data/cache/training_set_nd.npz --train-only new_data_ --out nd.npz
+python tools/eval_new_data.py --shards 110: \
+    --readout было=artifacts/mbon_readout.npz --readout стало=nd.npz --out nd.json
 ```
 
 Проверка на второй половине честная: вставки идут только в первую, а

docs/EXPERIMENTS.md

@@ -2524,8 +2524,11 @@ p ≥ 0.9 — 0.864 против 0.891), а уверенного фона на 6
 
 ```bash
 python tools/make_training_set.py --new-data 0:110 --out data/cache/training_set_nd.npz
-python tools/train_mbon.py --device cuda --data data/cache/training_set.npz     --data data/cache/training_set_nd.npz --train-only new_data_     --save-folds artifacts/mbon_folds_nd --out artifacts/mbon_readout_nd.npz
+python tools/train_mbon.py --device cuda --data data/cache/training_set.npz \
-python tools/eval_new_data.py --shards 110: --readout было=artifacts/mbon_readout.npz     --readout nd=artifacts/mbon_readout_nd.npz --out nd_eval.json
+    --data data/cache/training_set_nd.npz --train-only new_data_ \
+    --save-folds artifacts/mbon_folds_nd --out artifacts/mbon_readout_nd.npz
+python tools/eval_new_data.py --shards 110: --readout было=artifacts/mbon_readout.npz \
+    --readout nd=artifacts/mbon_readout_nd.npz --out nd_eval.json
 ```
 
 `--train-only new_data_` — куски `new_data` только учат и складок не
@@ -2598,3 +2601,40 @@ p^power. Все строки — с новой памятью (п. 17.1).
 молча работал на ручной формуле. Все цифры выше замерены со считыванием,
 образ теперь тоже с ним (`docker/Dockerfile`, `detect.launch.py`), а
 дымовой тест образа проверяет, что модель на месте.
+
+### 17.6. Раздельный запуск: узел в контейнере, проигрывание снаружи
+
+ТЗ описывает приёмку как `docker build → docker run → ros2 bag play`. Все
+прежние замеры шли внутри одного контейнера — узел и проигрыватель вместе.
+Раздельный запуск, как у инженера на стенде, проверен впервые (запись
+`roundT_doubleT`, 252 кадра):
+
+| узел | проигрыватель | принято кадров |
+|---|---|---:|
+| `--network host` | другой контейнер, наш профиль DDS | **0** |
+| `--network host`, умолчания Fast DDS | другой контейнер, умолчания Fast DDS | **0** |
+| `--network host --ipc host` | другой контейнер `--ipc host`, умолчания Fast DDS — как ROS на хосте | 252 |
+| `--network host --ipc host` | другой контейнер `--ipc host`, наш профиль | 252 |
+
+Причина: с `--network host` Fast DDS видит у собеседника тот же хост и шлёт
+кадры через `/dev/shm`, а без `--ipc host` у контейнера она своя — сегмент
+собеседника не виден, и кадры пропадают молча, без единой ошибки в журнале.
+Это общая ловушка ROS 2 в Docker, наш профиль ни при чём: на умолчаниях то же.
+
+Что сделано:
+
+* `--ipc host` — во всех командах README;
+* точка входа видит собственную `/dev/shm` (источник монтирования `shm`) и
+  переводит транспорт на UDP (`docker/fastdds_udp.xml`): проигрывание внутри
+  контейнера и второй контейнер из этого же образа тогда работают и без флага
+  (252 из 252). Проигрывателю на хосте со своими умолчаниями это не помогает —
+  он всё равно идёт через память (0 кадров), поэтому
+* узел следит за входом: если издатель на топике есть, а кадров нет пять
+  секунд, он пишет в журнал, что контейнер нужно запускать с `--ipc host`.
+
+Попутно: запуск одной командой (`bag:=`) проигрывал запись без
+`--read-ahead-queue-size 10`, и на кадрах по 24 МБ доходило 119 из 201. Флаг и
+задержка старта проигрывания на 4 с добавлены в launch — 201 из 201, с RViz и
+без. Сквозная проверка после всех правок, `doubleT_obstacle` в реальном
+времени: 201 кадр из 201, объект в 189 кадрах из 190 на 55.8 м, обработка кадра
+33.4 / 40.3 мс (медиана / p95).