Детекция людей, трекинг и аналитика зон: техническое описание

TL;DR

Задача — детекция людей в видеопотоке, назначение уникальных ID (трекинг) и аналитика поведения: пересечение линий, время в зоне, подсчёт.

YOLOv26 для детекции + ByteTrack/BoT-SORT для трекинга. ONNX/TensorRT для realtime inference на GPU.

Line Crossing — детекция пересечения виртуальной линии с определением направления (вход/выход).

Zone Dwell Time — точный подсчёт времени нахождения каждого человека в зоне (полезно для retail: время на кассе, в очереди, у полки).

Система логирует все события в CSV/БД и отправляет realtime-алерты через webhook/Telegram при нарушениях.

Постановка задачи

Система должна в реальном времени обрабатывать видеопоток с IP-камер, детектировать людей, назначать им уникальные ID и формировать структурированную аналитику: кто вошёл, кто вышел, сколько времени провёл в зоне, были ли нарушения периметра.

Ключевой сценарий: retail-магазин: подсчёт входящих/выходящих, время на кассе, аналитика очередей, тепловые карты плотности — всё автоматически из видеопотока.

Architecture Pipeline

Camera (RTSP)
    ↓
Frame Reader (OpenCV / ffmpeg)
    ↓
YOLOv26 Inference (ONNX / TensorRT)
    ↓
Tracking (ByteTrack / BoT-SORT)
    ↓
Zone Engine (line crossing + dwell time)
    ↓
Event Logger (CSV / DB / webhook / Telegram)
    ↓
Dashboard / API

Каждый этап пайплайна независим: модель можно заменить, трекер переключить, аналитику зон настроить через конфиг — без изменения кода.

YOLOv26: детекция людей

YOLOv26 (Ultralytics) — основа системы. Модель принимает кадр (RGB, 640×640) и возвращает набор bounding box с confidence score и классом (person = class 0 в COCO).

Выбор модели зависит от железа и требований к FPS:

Inference: PyTorch для разработки и отладки. ONNX или TensorRT для production — ускорение до 2–5x на GPU. Для edge-устройств (NVIDIA Jetson) — TensorRT обязателен.

Фильтрация: confidence threshold (по умолчанию 0.5), NMS IoU threshold (0.45), фильтрация по классу (только person), минимальный размер bbox (убирает ложные срабатывания на дальних планах).

Трекинг: ByteTrack / BoT-SORT

Трекинг превращает набор разрозненных bbox в связную историю перемещения каждого человека. Без трекинга невозможно считать входы/выходы или время в зоне.

ByteTrack — ассоциирует bbox между кадрами по IoU (Intersection over Union) и визуальному сходству. Каждый человек получает track_id, который сохраняется пока он в кадре.

BoT-SORT — улучшенная альтернатива: учитывает движение камеры и лучше работает при частичных перекрытиях. Рекомендуется для плотных сцен.

Параметры трекинга:

1) track_buffer — сколько кадров хранить потерянный трек (default: 30). При значении 30 при 15 FPS — трек «держится» 2 секунды после пропадания.

2) match_thresh — порог IoU для ассоциации (default: 0.8). Выше = строже matching.

3) Новый ID назначается при появлении нового объекта. Старые треки удаляются по истечении track_buffer.

Line Crossing: детекция пересечения линии

Line Crossing — определение момента, когда центр bbox человека пересекает виртуальную линию. Это основа для подсчёта входов и выходов.

Как работает:

1) На изображении задаётся виртуальная линия двумя точками: (x1, y1) и (x2, y2). Линия может быть любой ориентации — горизонтальная, вертикальная, диагональная.

2) Для каждого трека на каждом кадре проверяется положение центра bbox относительно линии. Используется cross product векторного произведения: если знак меняется между двумя кадрами — было пересечение.

3) Направление определяется по знаку cross product: положительный = пересечение слева направо (вход), отрицательный = справа налево (выход). Направления настраиваются через конфиг.

4) Каждое пересечение логируется: track_id, направление (in/out), таймстемп, координата пересечения, confidence bbox.

def check_line_crossing(prev_pos, curr_pos, line_start, line_end):
    d1 = cross_product(prev_pos, line_start, line_end)
    d2 = cross_product(curr_pos, line_start, line_end)
    
    if d1 * d2 < 0:  # знак изменился → пересечение
        direction = 'in' if d2 > 0 else 'out'
        return True, direction
    return False, None

Поддерживается несколько независимых линий на одном кадре — для разных входов/выходов, ворот и проходов.

Zone Dwell Time: время нахождения в зоне

Zone Dwell Time — подсчёт суммарного времени, которое каждый человек провёл внутри заданной области. Ключевая метрика для retail (время на кассе, у полки, в очереди) и производства (время в опасной зоне).

Как считается:

1) Зона задаётся как полигон (массив точек) или прямоугольник на кадре. Одна камера может иметь несколько зон.

2) На каждом кадре проверяется: находится ли центр bbox трека внутри полигона (point-in-polygon test).

3) Если трек в зоне — добавляется delta_time (1/FPS секунд) к аккумулятору dwell_time для данного track_id в данной зоне.

4) При выходе из зоны или потере трека — событие «dwell complete» логируется с track_id, zone_id, total_dwell_time.

if point_in_polygon(center, zone_polygon):
    dwell_tracker[track_id][zone_id] += 1.0 / fps
else:
    if track_id in dwell_tracker:
        total = dwell_tracker[track_id].pop(zone_id)
        log_event('dwell_complete', track_id, zone_id, total)

Практические применения:

Retail: время на кассе — среднее dwell time у касс = среднее время обслуживания. Рост dwell time = нехватка кассиров.

Retail: аналитика очередей — dwell time в зоне очереди + количество людей в зоне = предсказание времени ожидания.

Производство: опасные зоны — превышение dwell_time порога = alert. Человек находится в опасной зоне дольше допустимого.

Склады: время погрузки — dwell time в зоне ворот = время загрузки/разгрузки машины. Аналитика эффективности.

Алертинг и логирование

Система генерирует структурированные события четырёх типов:

Каналы доставки: CSV (по умолчанию) — для аналитики и отчётов. PostgreSQL / SQLite — для production. Webhook (HTTP POST) — для интеграции с ERP/helpdesk. Telegram Bot API — realtime-уведомления ответственному лицу. MQTT — для IoT/edge-интеграций.

Технологический стек

Типичные ошибки внедрения

1) Считать входы/выходы без трекинга — каждый новый bbox = новый «человек», счёт задваивается при перекрытиях.

2) Не настраивать confidence threshold под освещение — слишком много false positives ночью или false negatives при контровом свете.

3) Использовать одну линию для двунаправленного прохода без учёта направления — вход и выход складываются в одну цифру.

4) Не учитывать «пропадания» трека при перекрытиях — человек за колонной теряет ID и получает новый, dwell time сбрасывается.

5) Считать dwell time без привязки к FPS — при переменном FPS accumulator даёт неточное время.

6) Не фильтровать мелкие bbox на дальнем плане — детекция на заднем фоне создаёт шум в статистике.

FAQ

Key Takeaways

1) YOLOv26 + ByteTrack = надёжная связка для people detection и трекинга в realtime.

2) Line Crossing через cross product — простой и точный метод подсчёта входов/выходов.

3) Zone Dwell Time — аккумулятор по FPS, привязанный к track_id и zone_id. Ключевая метрика для retail.

4) TensorRT обязателен для production: 2–5x ускорение inference без потери точности.

5) Правильная фильтрация (confidence, min bbox, track_buffer) критичнее, чем выбор модели.