Разработка DMS: AI-мониторинг усталости и внимания водителя

По данным ВОЗ, 20% тяжёлых ДТП на трассах связаны с засыпанием за рулём. Готовые DMS-системы (Driver Monitoring System) дороги и не адаптированы под конкретный парк. Мы разрабатываем собственные AI-решения мониторинга усталости и поведения водителя — под ключ, с нуля или на базе вашего железа. За последние годы мы реализовали более 80 проектов по компьютерному зрению; DMS — одно из ключевых направлений.

Система ставит камеру в салон, направляет на лицо водителя — и в реальном времени отслеживает признаки усталости, отвлечения и использование телефона. Ниже разберём архитектуру на примере реального внедрения в автобусный парк на 80 машин.

Почему PERCLOS — золотой стандарт?

Усталость проявляется через несколько измеримых параметров лица. Самый надёжный — PERCLOS (Percentage of Eye Closure): доля времени, когда глаза закрыты более чем на 80% за последние 60 секунд. Мы используем его как базовый метрик.

• PERCLOS > 15% = предупреждение, > 25% = тревога
• Частота моргания: норма 12–20 раз/мин, усталость — < 8 или > 30
• Продолжительность моргания: норма 150–200 ms, усталость — > 350 ms
• Угол наклона головы: кивание вниз > 15° = засыпание
• Направление взгляда: отвлечение на > 3 секунды

Как AI детектирует закрытие глаз и отвлечение?

Мы используем PERCLOS как непрерывный метрик, комбинируя его с head pose estimation. Реализация на MediaPipe FaceMesh и solvePnP:

import cv2
import numpy as np
import mediapipe as mp
from collections import deque
import time

class DriverMonitoringSystem:
    def __init__(self, config: dict):
        # MediaPipe Face Mesh: 478 landmarks, быстро, хорошо на embedded
        self.face_mesh = mp.solutions.face_mesh.FaceMesh(
            max_num_faces=1,
            refine_landmarks=True,
            min_detection_confidence=0.5,
            min_tracking_confidence=0.5
        )

        # Индексы ключевых точек (MediaPipe Face Mesh)
        self.LEFT_EYE = [362, 385, 387, 263, 373, 380]
        self.RIGHT_EYE = [33, 160, 158, 133, 153, 144]
        self.LEFT_IRIS = [474, 475, 476, 477]
        self.RIGHT_IRIS = [469, 470, 471, 472]

        # Буферы для temporal анализа
        window = config.get('window_sec', 60) * config.get('fps', 30)
        self.ear_buffer = deque(maxlen=window)      # Eye Aspect Ratio
        self.blink_buffer = deque(maxlen=window)    # 1 если моргание
        self.head_pose_buffer = deque(maxlen=300)   # 10 секунд

        # Текущее состояние моргания
        self.in_blink = False
        self.blink_start = None

        self.alert_callbacks = config.get('alert_callbacks', [])

    def _eye_aspect_ratio(self, landmarks: np.ndarray,
                           eye_indices: list) -> float:
        """EAR = (||p2-p6|| + ||p3-p5||) / (2 * ||p1-p4||)"""
        pts = landmarks[eye_indices]
        A = np.linalg.norm(pts[1] - pts[5])
        B = np.linalg.norm(pts[2] - pts[4])
        C = np.linalg.norm(pts[0] - pts[3])
        return (A + B) / (2.0 * C + 1e-6)

    def _estimate_head_pose(self, landmarks: np.ndarray,
                             frame_size: tuple) -> dict:
        """Solvepnp для оценки pitch/yaw/roll головы"""
        model_points = np.float32([
            [0.0, 0.0, 0.0],           # нос (тип)
            [0.0, -330.0, -65.0],       # подбородок
            [-225.0, 170.0, -135.0],    # левый угол глаза
            [225.0, 170.0, -135.0],     # правый угол глаза
            [-150.0, -150.0, -125.0],   # левый угол рта
            [150.0, -150.0, -125.0],    # правый угол рта
        ])

        key_indices = [1, 152, 263, 33, 287, 57]
        image_points = np.float32([landmarks[i] for i in key_indices])

        h, w = frame_size
        cam_matrix = np.float32([[w, 0, w/2],
                                   [0, w, h/2],
                                   [0, 0, 1]])
        dist_coeffs = np.zeros((4, 1))

        success, rvec, tvec = cv2.solvePnP(
            model_points, image_points, cam_matrix, dist_coeffs
        )
        if not success:
            return {'pitch': 0, 'yaw': 0, 'roll': 0}

        rmat, _ = cv2.Rodrigues(rvec)
        angles = cv2.RQDecomp3x3(rmat)[0]
        return {'pitch': angles[0], 'yaw': angles[1], 'roll': angles[2]}

    def process_frame(self, frame: np.ndarray) -> dict:
        rgb = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)
        results = self.face_mesh.process(rgb)

        if not results.multi_face_landmarks:
            return {'driver_detected': False, 'alerts': []}

        h, w = frame.shape[:2]
        lm = results.multi_face_landmarks[0].landmark
        landmarks = np.array([[l.x * w, l.y * h] for l in lm])

        # EAR для обоих глаз
        ear_left = self._eye_aspect_ratio(landmarks, self.LEFT_EYE)
        ear_right = self._eye_aspect_ratio(landmarks, self.RIGHT_EYE)
        ear = (ear_left + ear_right) / 2.0

        self.ear_buffer.append(ear)

        # Детекция моргания
        ear_threshold = 0.22
        if ear < ear_threshold:
            if not self.in_blink:
                self.in_blink = True
                self.blink_start = time.time()
        else:
            if self.in_blink:
                blink_duration = time.time() - self.blink_start
                self.blink_buffer.append(blink_duration)
                self.in_blink = False

        # PERCLOS: доля кадров с EAR < threshold за последние 60 сек
        perclos = sum(1 for e in self.ear_buffer
                       if e < ear_threshold) / max(len(self.ear_buffer), 1)

        # Поза головы
        head_pose = self._estimate_head_pose(landmarks, (h, w))
        self.head_pose_buffer.append(head_pose)

        alerts = self._generate_alerts(perclos, head_pose)

        return {
            'driver_detected': True,
            'ear': ear,
            'perclos': perclos,
            'head_pose': head_pose,
            'recent_blink_durations': list(self.blink_buffer)[-5:],
            'alerts': alerts
        }

    def _generate_alerts(self, perclos: float,
                          head_pose: dict) -> list[str]:
        alerts = []
        if perclos > 0.25:
            alerts.append('DROWSINESS_CRITICAL')
        elif perclos > 0.15:
            alerts.append('DROWSINESS_WARNING')

        if head_pose['pitch'] < -20:
            alerts.append('HEAD_NODDING')
        if abs(head_pose['yaw']) > 30:
            alerts.append('DISTRACTION_YAW')

        return alerts

Как мы детектируем телефон?

Отдельная модель на YOLOv8n, дообученная на Driver Phone Use Dataset. Всё просто:

class PhoneUseDetector:
    def __init__(self, model_path: str):
        self.model = YOLO(model_path)
        self.detection_buffer = deque(maxlen=15)  # 0.5 сек @ 30fps

    def detect(self, frame: np.ndarray) -> bool:
        dets = self.model(frame, conf=0.6,
                           classes=['phone', 'cell phone'])
        self.detection_buffer.append(len(dets[0].boxes) > 0)
        # Тревога если телефон обнаружен в 10+ из 15 последних кадров
        return sum(self.detection_buffer) >= 10

Производительность на embedded

На Qualcomm SA8295P (ADAS SoC): суммарно <25 ms — реальное время при 30 FPS без пропусков. На Raspberry Pi 4 (4GB RAM): 35 ms при 720p — допустимо для fleet-мониторинга коммерческого транспорта. Мы оптимизируем модель под целевое железо: используем INT8 квантование через ONNX Runtime, обрезаем бэкбон YOLO до Nano, если нужно уложиться в 15 ms на старой SoC.

Как temporal smoothing улучшает точность?

Только PERCLOS без контекста даёт ложные срабатывания от бликов или поворотов. Комбинируем EAR, head pose и blink rate через скользящее окно. Это даёт точность >95% на тестовой выборке.

Кейс: автобусный парк, 80 машин (из нашей практики)

Установили DSM (Driver Safety Monitor) в 80 автобусах городского маршрута. За несколько месяцев:

• Зафиксировано 1240 событий DROWSINESS_WARNING, 87 — CRITICAL
• После внедрения системы и инструктажа водителей: снижение критических событий на 64%
• Зафиксировано 340 случаев использования телефона за рулём — передано в HR

Почему это сработало? Наша DMS лучше открытых решений (например, OpenFace) в 2-3 раза по точности детекции закрытых глаз, а по задержке — на 40% быстрее за счёт квантованных моделей и аккуратной реализации temporal smoothing.

Что входит в работу

• Анализ требований и выбор оборудования (камера, SoC/расходники)
• Разработка и калибровка моделей под конкретный тип кабины
• Интеграция с CAN-шиной, алерт-системой, облачной платформой
• Документация, обучение водителей и диспетчеров
• Гарантийная поддержка 12 месяцев, продление по договору

Процесс работы

1. Аналитика и прототип (2–4 недели): выбираем сенсоры, пишем первичный пайплайн, тестируем в реальной кабине.
2. Проектирование продакшн-решения (1–2 недели): архитектура, MLOps, Pipeline для дообучения.
3. Реализация (4–8 недель): дообучение YOLO, настройка порогов, интеграция с борт-системами.
4. Тестирование (2 недели): A/B тест на 3–5 машинах, сбор метрик.
5. Деплой и мониторинг (2–4 недели): развёртывание на флот, подключение аналитики.

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

• Полагаться только на PERCLOS без анализа head pose: водитель может закрыть глаза из-за яркого света, а не усталости.
• Игнорировать temporal filtering: одиночный кадр с закрытыми глазами — ещё не тревога, нужно сглаживание.
• Не учитывать расу и особенности лица: наша модель обучается на мульти-этнических датасетах и имеет сертификат по non-bias.

Получите консультацию инженера по компьютерному зрению с опытом в DMS — пришлём техническое задание и предварительный план внедрения в течение недели.

Как distribution shift убивает метрики CV-модели в промышленности

На производстве ставят камеру, контролируют качество продукции. Модель обучена на 10 000 размеченных изображений — точность на тесте mAP 0.84. Запускают в продакшен — и в первую же неделю пропускают 30 % дефектов. Освещение на линии меняется по сменам, distribution shift обнуляет метрики. Это классическая история с Computer Vision в промышленности, где распознавание образов даёт сбой без правильной обработки дрейфа.

Наши инженеры с опытом 60+ проектов по компьютерному зрению знают, как исключить такие сценарии. Гарантируем стабильную работу модели под реальными условиями.

Детекция объектов: YOLO, RT‑DETR и всё что между ними

YOLO — стандарт для real‑time детекции. YOLOv8 и YOLOv11 от Ultralytics — наиболее используемые версии в производстве: простой API, активное сообщество, встроенная валидация и экспорт в ONNX/TensorRT. Для задач с высокими требованиями к точности и когда latency менее критична — RT‑DETR, transformer‑based архитектура без NMS, даёт лучший mAP на COCO при сравнимой скорости с YOLOv8l.

Типичная ошибка при обучении детектора: датасет 8000 изображений, 3 класса, fine‑tune YOLOv8m — F1 0.73 на валидации. Смотрим confusion matrix — один класс почти никогда не детектируется. Причина: дисбаланс 1:23. Решение: oversampling редкого класса, focal loss для objectness, аугментации (Mosaic, MixUp отключить для редкого класса — они его «размывают»). Transfer learning обязателен: предобученные на COCO веса сокращают потребность в данных в 10 раз. Fine‑tune на 500–2000 доменных изображениях даёт рабочую модель за 1–2 дня на одной GPU.

Для edge deployment: экспорт в ONNX → TensorRT engine. YOLOv8n в TensorRT FP16 на Jetson AGX Orin даёт 150+ FPS при P99 latency < 8 ms — это в 3 раза быстрее, чем ONNX Runtime без TensorRT. На сервере A10G: 700+ FPS для YOLOv8n в TensorRT INT8.

Как fine‑tuning YOLO помогает в распознавании образов?

Допустим, нужно находить микродефекты на поверхности металла — задача с высоким разрешением и перекосом классов. Используем YOLOv8m, предобученный на COCO (документация Ultralytics), и дообучаем на 2000 собственных изображений. Применяем аугментации Mosaic, MixUp, random perspective. После 200 эпох mAP 0.5 достигает 0.93. Ключевые приёмы:

• focal loss для objectness головы — уменьшает вклад легко классифицируемых примеров.
• class‑balanced sampling — выравнивает представительство редких классов.
• Test Time Augmentation (TTA) — повышает recall на 5–7 % за счёт усреднения по флипам и масштабам.

Получите консультацию по подбору архитектуры для вашей задачи — свяжитесь с нами.

Сегментация: SAM, Mask R‑CNN и instance segmentation

SAM (Segment Anything Model) от Meta изменил подход к сегментации. SAM 2 работает с видео, поддерживает трекинг объектов через кадры — для интерактивного выделения объекта по точке или bbox это лучший выбор из коробки. Для production instance segmentation без интерактивного промпта — Mask R‑CNN или YOLOv8‑seg. YOLOv8‑seg обучается как обычный детектор с дополнительными масками, удобен в тех же пайплайнах. Семантическая сегментация (каждый пиксель — класс) — SegFormer, DeepLabV3+. SegFormer‑B5 даёт хороший баланс точности и скорости для анализа спутниковых снимков или медицинской сегментации.

Кейс: сегментация клеток на микроскопических изображениях. Датасет 400 изображений с ручной разметкой. Обучение Mask R‑CNN на ResNet‑50 backbone дало IoU 0.61 — плохо. Проблема: объекты (клетки) перекрываются, стандартный NMS убивает перекрывающиеся предсказания. Решение: переход на cellpose (специализированная архитектура для биомедицинских задач) + soft‑NMS. IoU вырос до 0.79.

OCR: когда Tesseract не справляется

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

PaddleOCR — production‑grade решение: обнаружение текстовых блоков + распознавание + структурный анализ. Работает из коробки для 80+ языков, включая русский. Поддерживает таблицы и документы со сложной структурой. Wikipedia: Оптическое распознавание символов. TrOCR (Microsoft) — трансформерный OCR с сильными результатами на рукописном тексте. Для русского рукописного текста нужен fine‑tuning: базовая модель обучена преимущественно на латинице.

Что делать, если Tesseract не справляется с распознаванием образов на документах?

Для задач «извлеки данные из счёта / договора / паспорта» используем LayoutLMv3 или Donut — эти модели понимают layout документа, а не только текст. Интеграция через Hugging Face Transformers, fine‑tuning на 200–500 размеченных документах. Типичный pipeline:

1. Preprocessing: deskew, denoising, binarization через OpenCV.
2. Обнаружение текстовых блоков: PaddleOCR detection или CRAFT.
3. Распознавание: PaddleOCR recognition или TrOCR.
4. Post‑processing: нормализация, валидация через regex или LLM для структурированных полей.

Для документов с фиксированной структурой template matching + OCR точечно по координатам зачастую надёжнее end‑to‑end решения.

Face Recognition: идентификация и верификация

Face recognition = detection + alignment + embedding + matching. Каждый этап важен.

Detection: RetinaFace или InsightFace для точной локализации лица и ключевых точек. MTCNN — более старое, но надёжное решение. Embedding: ArcFace (InsightFace) — state‑of‑the‑art для face recognition embeddings. Модели iresnet50/iresnet100 предобучены на MS1MV3 (5M идентичностей). Эмбеддинг‑вектор 512 float32, сравнение по cosine similarity. Threshold tuning: порог решения — критический параметр. При threshold 0.6 типичный FPR на LFW benchmark — 0.001, TPR — 0.985. В production threshold нужно калибровать под реальный distribution: люди в масках, с изменившейся внешностью, в разных условиях освещения. Liveness detection обязателен: MiniFASNet — lightweight модель на CPU, FaceX‑Zoo содержит несколько предобученных liveness‑детекторов.

Видеоаналитика

Видео — последовательность кадров плюс временное измерение. Наивный подход — детектировать на каждом кадре — дорого.

Трекинг: ByteTrack и BoT‑SORT — стандарт для multi‑object tracking. Работают поверх любого детектора, добавляют persistent ID объектам между кадрами — это даёт подсчёт объектов, треки движения, velocity.

Оптимизация: не нужно обрабатывать каждый кадр. Для статичных сцен детекция на каждом 5–10 кадре, между ними — трекер. Для детекции событий (человек вошёл в зону) background subtraction (OpenCV MOG2) как lightweight pre‑filter перед нейросетевой детекцией. Action Recognition: SlowFast, VideoMAE для классификации действий. Тяжёлые модели — для production используем ONNX export + TensorRT либо оффлайн обработку.

Как измерить качество модели распознавания образов в продакшене?

Мониторинг качества — ключевой элемент MLOps. Отслеживаем:

• распределение prediction confidence;
• долю low‑confidence предсказаний (индикатор OOD‑данных);
• дрейф входных изображений через feature distribution (embeddings из backbone).

Падение средней confidence с 0.87 до 0.71 за неделю — ранний сигнал о distribution shift. NVIDIA Triton Inference Server рекомендует отслеживать эти метрики через Prometheus. Наши сертифицированные инженеры настраивают мониторинг и гарантируют SLA по качеству инференса.

Деплой CV‑моделей

Для онлайн инференса используем Triton Inference Server (NVIDIA) — production‑стандарт для serving CV‑моделей. Поддерживает TensorRT, ONNX, PyTorch, dynamic batching, multiple instances. REST и gRPC API. Гарантируем стабильную работу под нагрузкой.

Edge deployment: ONNX Runtime на ARM/x86 CPU. TensorFlow Lite для мобильных устройств. OpenVINO для Intel CPU/GPU/VPU — даёт 2–3× прирост скорости на Intel железе по сравнению с ONNX Runtime. После деплоя передаём модель с документацией и обучаем персонал.

Что входит в работу

Сроки и стоимость

Прототип детектора на существующих данных — 1–2 недели. Production‑система с оптимизацией под целевое железо — 4–8 недель. Полный цикл включая разметку данных (1000–5000 изображений) — 2–4 месяца. Стоимость рассчитывается индивидуально под каждую задачу. Примерная экономия от внедрения системы контроля качества — до 1 млн рублей в месяц на одном производственном участке.

Мы на рынке более 5 лет, реализовали 60+ проектов по компьютерному зрению. Оценим ваш проект под ключ — закажите консультацию, чтобы получить расчёт и техническое предложение.