VRU-детекция для автономного транспорта: пешеходы, велосипедисты

Детекция пешеходов: где ломается модель в потоке

Плотный поток ломает детекцию пешеходов не потому, что модель «не видит человека», а потому, что в кадре одновременно 15-20 объектов и большинство перекрыты. Пешеход, закрытый припаркованным авто, кустом или другим пешеходом, распознаётся по фрагменту силуэта — и уверенность падает ниже рабочего порога. В итоге пропуски объектов концентрируются не где-то на периферии, а именно там, где цена ошибки максимальна: на перекрёстках, у остановок, на выездах с парковок.

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

Отдельная категория — нестандартные сценарии: человек на самокате или с велосипедом рядом, ребёнок ниже уровня капота, группа, сливающаяся в одно пятно, сидящий или лежащий человек. На обучающих данных такие случаи представлены доли процента, и модель ведёт себя на них непредсказуемо — не «ошибается», а именно непредсказуемо, что для эксплуатации хуже.

Корень проблемы — единый порог уверенности. Понижаешь его, чтобы не пропускать людей — получаешь ложные торможения на тенях и дорожной разметке; повышаешь, чтобы убрать ложные — растут пропуски объектов. Один кадр не даёт контекста, чтобы разрешить это противоречие, поэтому узкое место модели лежит не в распознавании, а в том, как решение принимается во времени — по последовательности кадров, с учётом трека и направления движения.

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

Измеримый эффект: меньше пропусков и ложных срабатываний

До доработки полнота распознавания проседала на конкретных сценах: ночь, дождь, контровой свет, пешеход за припаркованным транспортом, велосипедист на перекрёстке. Именно они давали основную часть пропусков, а на дневных сценах метрика выглядела благополучно и маскировала проблему. Мы разметили слабые сцены отдельно, добавили их в обучение с повышенным весом редких классов, а проверку вели на отложенном наборе, не участвовавшем в обучении — по методологии, близкой к nuScenes. Полнота распознавания пешеходов на сложных сценах выросла с ~0,82 до ~0,94 при том же пороге срабатывания.

Вторая половина задачи — ложные срабатывания: если модель реагирует на блик или отражение в луже, транспорт тормозит без причины, едет график и падает доверие оператора. Такие случаи мы разметили отдельным классом ошибок и добавили проверку гипотезы по последовательности кадров — одиночная аномалия больше не считается объектом. Частота ложных срабатываний на час движения снизилась с 6–8 до 1–2.

Время исправления ошибки стало управляемым: инцидент разбирается по логам и записям сенсоров, размеченный случай попадает в дообучение, ночная сборка прогоняет регрессионный набор и выкатывает обновление сначала на часть парка. Раньше до исправления проходили недели, теперь типовой дефект закрывается за 2–3 дня.

Вместе это сокращает простой транспорта на разбор: большинство срабатываний снимается удалённо, без вывода машины из работы. Метрики — полнота распознавания, ложные срабатывания, время до исправления — сведены в одну панель и видны по каждому маршруту.

Режимы работы и варианты интеграции на транспорте

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

Отдельная история — интеграция с бортовым контуром, который уже стоит на машине. Здесь важнее не наш стек, а запас по нагрузке у установленного вычислителя, доступ к видеопотокам и то, как система отдаёт сигнал в шину управления. Мы начинаем с инвентаризации: половина проектов ломается не на детекции пешеходов, а на несовместимости с тем, что уже смонтировано.

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

Как идёт проект: от аудита данных до передачи

Работа идёт не как «обучение модели», а как управляемая последовательность, где у каждого этапа есть проверяемый артефакт. Этапы не переставляются: пропущенный аудит данных всплывает на приёмке, когда переделка стоит дороже всего.

1. Аудит данных и сценариев. Разбираем записи по условиям: освещённость, погода, плотность потока, типы дорог. Фиксируем редкие и опасные случаи — пешеход в тёмной одежде ночью, велосипедист за крупным транспортом, — и составляем карту пробелов с планом их закрытия.

2. Схема решения. Определяем, где детекция встраивается в общий контур восприятия, что приходит на вход и что уходит наружу. Здесь же задаём целевые метрики: допустимая доля пропусков и допустимая частота ложных срабатываний.

3. Разметка и обучение. Согласуем единые правила разметки, чтобы границы классов не «плыли» между исполнителями, и учим модель на наборе, который покрывает карту сценариев, а не только частые случаи.

4. Проверка на отложенной выборке. Отложенная выборка собирается по сценариям, а не случайно: в неё попадают те же ночные, дождливые и плотные участки. Смотрим не среднюю метрику, а разброс по условиям — именно он показывает, где решение посыпется.

5. Приёмка результата. Прогоняем решение на согласованном наборе сценариев и сверяем с порогами из второго этапа. Приёмка идёт по протоколу, который заказчик может воспроизвести самостоятельно.

6. Передача и сопровождение. Отдаём конфигурации, порядок воспроизведения проверок и отчёт о поведении на сложных случаях. Дальше — регламент дообучения на новых данных.

Артефакты проекта: разметка, схемы, регламенты

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

• Эталонная разметка — валидированный набор кадров с пешеходами, велосипедистами и пограничными случаями: частичное перекрытие, ночь, дождь, блики фар, низкий контраст. С правилами атрибуции и инструкцией для разметчиков, чтобы новые данные ложились в тот же формат без пересборки выборки.
• Схемы сценариев — матрица ситуаций: переход вне разметки, группа людей, ребёнок за препятствием, самокатчик на скорости. По каждой — покрыта ли она проверками, на каких данных подтверждена и где проходит граница применимости.
• Конфигурации контура детекции — пороги срабатывания, зоны интереса, частота обработки кадров и логика объединения результатов по времени. С пояснением, почему выбраны именно эти значения и что меняется при их сдвиге.
• Схема стыка с бортовым контуром — форматы обмена, задержки, поведение при потере сигнала, требования к вычислителю и порядок деградации, если данных не хватает.
• Регламент разбора сбоев — что фиксировать при инциденте, какой минимум данных сохранять для воспроизведения и как классифицировать ошибку: пропуск, ложное срабатывание или запаздывание реакции.
• Документация по модели — область применимости, метрики на отложенной выборке, известные ограничения и условия, при которых нужна дообучение на новых данных.
• Контрольный список воспроизведения — окружение, порядок запуска, шаги переобучения и приёмки, чтобы результат повторил не только автор модели.

Комплект делает качество проверяемым: метрики привязаны к конкретным сценариям, у каждого ограничения указан источник, а разбор нового сбоя идёт по одному регламенту, а не по памяти разработчика.

Кейс: сократили пропуски на ночных маршрутах

Заказчик — поставщик систем автономного вождения. Днём детекция пешеходов держалась на приемлемом уровне, а на ночных маршрутах начинались пропуски: на неосвещённых переходах, при контровом свете фар и в дождь полнота распознавания проседала до 0.78 по пешеходам и 0.69 по велосипедистам, ложные срабатывания доходили до 41 на тысячу кадров — система реагировала на блики, отражения и придорожные кусты.

Аудит разметки объяснил причину: тёмные силуэты шли одним классом «пешеход», частично перекрытые и граничные объекты не размечались вовсе, ночных фрагментов в контрольном наборе было меньше десятой доли. Схему классов переработали — отдельные категории для людей в тёмной одежде, силуэтов на переходе и велосипедистов за транспортом; добрали ночные записи и добавили тепловизионный канал FLIR, где силуэт читается независимо от освещения.

После переразметки и переобучения полнота по пешеходам поднялась до 0.94, по велосипедистам — до 0.92, ложные срабатывания упали до 8 на тысячу кадров. Доля ночных сценариев в контрольном наборе выросла до 40%: метрики стали считаться там, где отказ раньше просто не замечали. Откат на предыдущую сборку доступен по контрольным точкам — просадку на отдельном участке снимают без остановки испытаний.

Что переносится на другие проекты

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

Что делать, если детекция пешеходов уже развёрнута?

Если детекция уже развёрнута, перезапуск нужен не всегда. Разделяем три сценария: доработка существующей модели на собственных данных, перенос её в новый вычислительный контур и пересборка конвейера обработки, когда меняется состав сенсоров или логика срабатывания. Ориентир для оценки — сценарии Euro NCAP для уязвимых участников движения: по ним видно, каких именно случаев модели не хватает.

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

Пересобирать приходится, когда меняется порядок обработки: калибровка, синхронизация каналов, правила совмещения данных камеры и лидара. Это уже не замена весов, а новый конвейер с отдельной валидацией.

Выбор делаем по ограничениям и срокам: сравниваем варианты на своей выборке — доля пропущенных пешеходов, ложные торможения, объём разметки под каждый.

Сомнения по данным, погоде и редким сценариям

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

Как ведёт себя детекция в дождь, снег и ночью?

Каждое условие проверяется своей подгруппой: мокрый асфальт даёт блики и отражения, которые модель принимает за объекты; снег размывает границы и меняет силуэт; ночью падает контраст и растёт доля засветки от фар. На этапе обучения добавляем управляемые искажения яркости, контраста, размытия и шума, а приёмку считаем по подгруппам условий, а не одной общей цифрой. Так деградация видна сразу и адресно закрывается дообучением на нужном срезе.

Что будет, когда мы дообучаем модель сами после передачи проекта?

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

Обсудим задачу и вернёмся с оценкой и планом

Чтобы вернуться с оценкой проекта, а не с общими соображениями, нужен минимум вводных по вашему сценарию движения. Пришлите то, что уже есть: на этом шаге полнота важнее аккуратности.

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

В ответ присылаем документ, а не переписку: в нём состав работ, план работ по этапам, сроки этапов и точки приёмки с метриками. Оценка проекта строится на ваших данных, поэтому спорные места помечаем отдельно — сразу видно, где нужен доступ к полигону.

• какие классы объектов детектируем и на каких дистанциях;
• как проверяем результат: сценарии приёмки и пороги по метрикам;
• что делаем с редкими классами и разметкой под них;
• как устроено дообучение, когда в потоке появляются новые типы участников.

Опишите задачу — вернёмся с оценкой и планом.