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 для уразливих учасників руху: за ними видно, яких саме випадків моделі не вистачає.

Доопрацювання без зупинки системи — найчастіший шлях. Донавчаємо на розмітці рідкісних випадків, уточнюємо пороги спрацьовування, окремо перевіряємо частково перекритих пішоходів.

Сумісність із поточним контуром перевіряється швидко: той самий формат входу, той самий інтерфейс видачі — модель підміняється на ходу, а поведінку старої й нової версії порівнюємо на одному записі.

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

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

Сумніви щодо даних, погоди й рідкісних сценаріїв

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

Як поводиться детекція в дощ, сніг і вночі?

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

На етапі навчання додаємо керовані викривлення яскравості, контрасту, розмиття й шуму, а приймання рахуємо за підгрупами умов, а не однією загальною цифрою. Так деградація видна одразу й адресно закривається донавчанням на потрібному зрізі.

Що буде, коли ми донавчаємо модель самі після передачі проєкту?

Передаємо опис схеми розмітки, скрипти навчання й перевірки, чек-лист приймання нових даних і правила версіонування. Набір даних і модель фіксуються за версіями, попередня збірка зберігається — відкат можливий на будь-який крок.

Новий прогін порівнюється на тому самому валідаційному зрізі, що й попередній, тому видно, що саме покращилося, а що просіло. Якщо потрібно, супроводжуємо перші цикли донавчання й розбираємо спірні кадри разом із вашою командою.

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

Щоб повернутися з оцінкою проєкту, а не із загальними міркуваннями, потрібен мінімум ввідних за вашим сценарієм руху. Надішліть те, що вже є: на цьому кроці повнота важливіша за акуратність.

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

У відповідь надсилаємо документ, а не переписку: у ньому склад робіт, план робіт за етапами, строки етапів і точки приймання з метриками. Оцінка проєкту будується на ваших даних, тому спірні місця позначаємо окремо — одразу видно, де потрібен доступ до полігону.

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

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