Почему detector и tracker работают вместе в FPV

Detector и tracker решают разные части одной задачи сопровождения цели: detector периодически находит и подтверждает объект, а tracker поддерживает его положение между дорогими проверками. В этой статье ТРИЗ используется как инженерный слой: чтобы сформулировать конфликт, найти ресурсы системы и выбрать проверяемые архитектурные варианты.

Суть за 20 секунд

Запускать detector на каждом кадре не всегда выгодно: растут задержка, вычислительная нагрузка, энергопотребление и нагрев. Но если проверять цель слишком редко, tracker может накопить ошибку или потерять объект. Поэтому полезнее не искать одну «правильную частоту», а менять частоту проверки по состоянию системы.

Проблема: точность против вычислительного бюджета

В FPV цель может быть маленькой, быстро двигаться, частично перекрываться, менять масштаб и попадать в кадры с motion blur, компрессией или низким контрастом. Частый detector даёт больше внешних проверок, но стоит дороже. Редкий detector разгружает систему, но оставляет tracker дольше без коррекции.

Инженерное противоречие

Хотим чаще запускать detector, чтобы быстрее подтверждать и возвращать цель. Одновременно хотим запускать его реже, чтобы снизить compute cost, latency, power и thermal load.

Физическое противоречие

Detector должен работать часто, когда система не уверена в цели, и редко, когда TRACK устойчив.

ИКР и ресурсы

Идеальный результат: тяжёлая проверка выполняется только тогда и там, где она действительно нужна. Между проверками сопровождение поддерживается уже имеющимися ресурсами: предыдущим bbox, временной непрерывностью движения, ROI, историей масштаба, confidence detector, качеством tracker и состояниями TRACK / UNCERTAIN / LOST.

Ключевой принцип: использовать информацию между кадрами

Новый кадр не существует изолированно. Предыдущее положение цели уже является информационным ресурсом. Tracker использует эту связь и берёт на себя часть функции detector между проверками.

DETECT → TRACK → TRACK → TRACK → VERIFY → TRACK → …

При устойчивом TRACK detector можно вызывать реже. При падении качества — чаще. В LOST — переходить к full-frame re-detection/reacquisition.

Архитектурные варианты

1. Detector every frame — простая контрольная конфигурация с максимальной стоимостью вычислений.
2. Periodic detector + tracker — detector запускается раз в N кадров, tracker работает между вызовами.
3. State-driven cadence — TRACK: редко; UNCERTAIN: чаще; LOST: полный поиск.
4. Quality gate + Appearance Memory — память обновляется только при достаточном качестве текущего трека.
5. Full-frame + ROI — широкий поиск выполняется дешевле, локальная область проверяется подробнее.

Что уже подтверждено

В существующем baseline FPV AI архитектурно подтверждена цепочка FastestDet через NCNN → TargetBox → OpenCV CSRT с периодической detector verification/correction/re-init. То есть сам принцип совместной работы detector и tracker уже присутствует в реальной архитектуре проекта.

Это не доказывает, что конкретная cadence, tracker или memory-конфигурация оптимальны.

Как проверять честно

Нужен один и тот же golden replay, одно устройство и максимально одинаковые настройки. В причинном A/B меняется один фактор.

Пример сравнения: A — detector every frame; B — detector раз в N кадров + тот же tracker; C — state-driven cadence + тот же detector и tracker.

Нельзя одновременно менять detector model, input resolution, tracker и thresholds — иначе причина результата становится неразличима.

Какие метрики нужны

Track continuity, LOST events, reacquisition success rate и время возврата цели, bbox IoU или center error при наличии ground truth, end-to-end latency, detector duty cycle, FPS, CPU/GPU/NPU load, RAM, power и температура.

Статус измерений: NOT TESTED для сравнения A/B/C в рамках этой статьи. До matched benchmark любые утверждения о превосходстве конкретного варианта остаются гипотезой.

Как специально сломать решение

Проверять нужно не только удобные сцены. В failure test полезно включить маленькую цель, motion blur, перекрытие, похожий объект, резкий scale jump, выход из ROI, низкий контраст, сильную компрессию, dropped frames, длительный интервал без detector correction и thermal throttling.

Ограничения

Нельзя заранее утверждать, что state-driven cadence лучше fixed cadence, NCC лучше CSRT или Appearance Memory обязательно повышает итоговое качество. Архитектурная логика объясняет, почему такие варианты стоит проверить, но не заменяет измерения.

Источники и evidence

Внутренние источники FPV Club: «02_Case_Detector_Tracker_через_ТРИЗ», «06_Единый_Benchmark_Protocol_FPV_AI», «07_Failure_Test_Matrix_FPV_AI», «00_README_Golden_Replay_Dataset_FPV_AI».

Технический reference: OpenCV TrackerCSRT documentation и исходные материалы FPV AI по FastestDet/NCNN/CSRT/NCC.

Главный вывод

Detector и tracker работают вместе потому, что выполняют разные части одной функции при разных затратах. ТРИЗ здесь полезна не как ярлык, а как способ увидеть противоречие и разделить требования во времени, пространстве и по условию.

Следующий шаг

Зафиксировать Baseline Replica на одном golden replay и выполнить matched A/B: detector every frame → periodic detector + tracker → state-driven cadence. Только после этого переводить архитектурную гипотезу в утверждение о преимуществе конкретной конфигурации.