forked from Dan4ick/Lidar_Muxa
EXPERIMENTS п. 17.7: почему тормозил просмотр, прогон всех записей в контейнере
This commit is contained in:
parent
f5f433b96c
commit
2051da2399
1 changed files with 69 additions and 0 deletions
|
|
@ -2638,3 +2638,72 @@ p^power. Все строки — с новой памятью (п. 17.1).
|
||||||
без. Сквозная проверка после всех правок, `doubleT_obstacle` в реальном
|
без. Сквозная проверка после всех правок, `doubleT_obstacle` в реальном
|
||||||
времени: 201 кадр из 201, объект в 189 кадрах из 190 на 55.8 м, обработка кадра
|
времени: 201 кадр из 201, объект в 189 кадрах из 190 на 55.8 м, обработка кадра
|
||||||
33.4 / 40.3 мс (медиана / p95).
|
33.4 / 40.3 мс (медиана / p95).
|
||||||
|
|
||||||
|
### 17.7. RViz: почему тормозило и где пропадало облако
|
||||||
|
|
||||||
|
При просмотре в RViz на записи с препятствием облака не было вовсе, а со
|
||||||
|
схемой мозга всё заметно тормозило. Обе причины — в обвязке, не в конвейере.
|
||||||
|
|
||||||
|
* **Топик.** RViz слушал `/lidar_points`, а `doubleT_obstacle` пишет в
|
||||||
|
`/sensing/lidar/hesai128/pointcloud` (остальные пять записей — в
|
||||||
|
`/lidar_points`). Узел подписан на оба, поэтому рамка «55 м» была, а точек —
|
||||||
|
нет.
|
||||||
|
* **Цена сообщений в rclpy.** Присваивание `bytes` полю `data` rclpy
|
||||||
|
проверяет поэлементно на Python: картинка мозга в 2.8 МБ — 142 мс, против
|
||||||
|
2.4 мс у `array('B')`. Обработка идёт в колбэке, и узел со схемой мозга
|
||||||
|
успевал около трёх кадров в секунду.
|
||||||
|
|
||||||
|
| RViz | схема мозга | принято кадров из 201: до | после |
|
||||||
|
|---|---|---:|---:|
|
||||||
|
| есть | нет | 183 | 201 |
|
||||||
|
| нет | есть | 135 | 201 |
|
||||||
|
| есть | есть | 80 | 201 |
|
||||||
|
|
||||||
|
Сделано: облако обзора `/flyguard/view_cloud` — сектор обработки из самого
|
||||||
|
конвейера, до 77 тысяч точек вместо 900 тысяч, в координатах пути (пол на
|
||||||
|
сетке, рамки препятствий на полу); оно есть при любом входном топике и
|
||||||
|
публикуется, только когда на него подписаны. В обоих местах — `array('B')`.
|
||||||
|
Для схемы мозга — отдельный конфиг RViz, где она справа во всю высоту:
|
||||||
|
раскладку панелей Qt хранит сериализацией, и строка для конфига собирается
|
||||||
|
`tools/rviz_layout.py` по исходникам Qt 5.15, без самого Qt.
|
||||||
|
|
||||||
|
Раз уж топик у записей разный, у контрольной записи он может оказаться
|
||||||
|
третьим. Сторож входа теперь и это закрывает: если наши топики молчат, а в
|
||||||
|
системе есть другой топик с облаком точек, узел через секунду подписывается на
|
||||||
|
него сам и пишет об этом в журнал. Проверено переименованием топика при
|
||||||
|
проигрывании (`--remap /lidar_points:=/my/cloud`): 248 кадров из 252 — четыре
|
||||||
|
первых ушли, пока узел искал.
|
||||||
|
|
||||||
|
И ещё одна находка в самой проверке. `docker/check_all.sh` гоняет записи
|
||||||
|
подряд в одном контейнере через `demo_test.sh`, а тот гасил launch сигналом
|
||||||
|
SIGTERM — узел его переживал. Узлы копились: на шестой записи их работало пять,
|
||||||
|
«принятых» кадров выходило 2287 при 877 в записи, а время кадра росло от записи
|
||||||
|
к записи с 37 до 82 мс. Теперь SIGINT и ожидание, пока детектор не выйдет.
|
||||||
|
|
||||||
|
Все шесть записей в контейнере после правок (`docker/check_all.sh`; память и
|
||||||
|
считывание из образа, так что все записи им знакомы):
|
||||||
|
|
||||||
|
| запись | кадров | кадров с тревогой | кадр, медиана / p95, мс |
|
||||||
|
|---|---:|---:|---:|
|
||||||
|
| `doubleT_obstacle` | 201 | 189 (99.5 %) — настоящий объект, 55.7 м | 37.3 / 44.8 |
|
||||||
|
| `doubleT_platform` | 345 | 0 | 40.8 / 49.2 |
|
||||||
|
| `roundT_doubleT` | 252 | 0 | 43.4 / 58.8 |
|
||||||
|
| `roundT_pressureGate_roundT` | 268 | 0 | 51.2 / 62.1 |
|
||||||
|
| `roundT_squareT_pressureGate_squareT` | 545 | 28 (5.2 %) | 56.0 / 68.5 |
|
||||||
|
| `squareT_platform_squareT_switch` | 877 | 50 (5.8 %) | 47.9 / 65.8 |
|
||||||
|
|
||||||
|
Записи читались с диска Windows через WSL, медленнее реального времени, и узел
|
||||||
|
обработал все кадры до одного. Тревоги на двух последних записях — три трека,
|
||||||
|
неподвижных в координатах пути (точка держится с точностью до 1.2 м):
|
||||||
|
|
||||||
|
| запись | когда | дальность | что видит узел | уверенность |
|
||||||
|
|---|---|---|---|---:|
|
||||||
|
| `roundT_squareT_pressureGate_squareT` | 28–31 с | 65 → 30 м | плоская полоса 1.3 м × 3 см на 0.19 м над рельсом, по оси | ≤ 0.26 |
|
||||||
|
| `squareT_platform_squareT_switch` | 21–23 с | 103 → 92 м | 0.2 × 0.4 м, низ на 0.48 м над рельсом, по оси | ≤ 0.34 |
|
||||||
|
| `squareT_platform_squareT_switch` | 70–74 с | 147 → 136 м | 2.5 × 1.0 м на высоте 0.8–1.8 м, в 0.8 м левее оси | ≤ 0.36 |
|
||||||
|
|
||||||
|
Первая — почти наверняка порог гермозатвора: пол в колее опущен до 0.16 м
|
||||||
|
(п. 16.3), и полоса на 0.19 м над рельсом оказывается над ним. Две другие
|
||||||
|
нужно смотреть глазами: по словам организаторов, препятствий в данных «не
|
||||||
|
больше двух», и одно из них в `doubleT_obstacle` — второе может оказаться
|
||||||
|
здесь.
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue