Чому автономне водіння ламається на рідкісних сценаріях
Довгий хвіст рідкісних сценаріїв — не екзотика, а повсякденність: загублений попереду вантаж, об'їзд по узбіччю, розмітка під снігом, велосипедист, що виринає з-за припаркованого фургона.
Автономне водіння спирається на статистику навчальних даних, а такі ситуації до неї майже не потрапляють — і конвеєр сприйняття та планування втрачає стійкість саме на них.
Далі починаються відмови сприйняття. Злиття даних сенсорів зшиває кадри камери, хмару точок і показання далекомірів в одну картину, і варто розійтися часовим міткам або збитися калібруванню — об'єкт двоїться.
Мокрий асфальт, відблиск від низького сонця, відображення у вітрині дають перешкоду, якої на дорозі фізично немає.
Передбачення траєкторій додає другий шар помилки. Модель оцінює наміри сусідів по потоку, і на рідкісному сценарії розкид гіпотез розходиться так широко, що планувальник або завмирає в нерішучості, або обирає маневр, який за секунду перестає бути безпечним.
Ціна на дорозі різна, і обидві крайнощі погані. Хибне спрацювання — різке гальмування на порожній ділянці, у яке ззаду в'їжджає той, хто не чекав. Пропущений об'єкт — контакт. Надійність тут визначає не середня якість моделі, а поведінка на хвості розподілу.
Тому ми починаємо з реєстру сценаріїв і метрик для кожного шару — від відтворюваних перевірок рідкісних сцен до консервативної логіки планування; розбираємо, як це закривається на конкретному маршруті замовника.
Вимірюваний ефект від модульної архітектури сприйняття
Монолітний контур показує лише підсумок: система поїхала краще чи гірше, а яка частина це дала — невідомо.
Модульна архітектура знімає це питання: у сприйняття, планування та керування свої метрики якості, тому правка видна в конкретному числі, а не в загальному враженні від заїзду.
Сприйняття вимірюємо окремо — повнота виявлення, стійкість супроводу на перекриттях, частка хибних спрацювань у сутінках і на мокрій дорозі. Планування — за часткою маневрів із підстраховкою та за відхиленням від цільової траєкторії. Регрес ловиться по конкретному блоку і не розмазується по всьому контуру.
Клас відмов стає керованим. Раніше збій планування виглядав як помилка сприйняття, і розбір ішов по всій системі. Тепер у відмови є адреса, а отже й зрозумілий перелік перевірок, які її закривають.
Звідси ж стійкість моделі: оновлення одного блоку не потребує перенавчання решти та повної перевірки контуру. Втративши впевненість на незнайомій сцені, модуль переходить у консервативний режим, а не тягне за собою всю поведінку машини.
Час розбору інциденту скорочується завдяки наскрізному журналу: запис позначено версіями модулів, причину знаходять за фрагментом, а не відтворенням заїзду цілком. На практиці це години роботи замість днів, і правка стосується одного блоку, а не всього контуру.
Підходи до побудови: модульний, наскрізний, гібридний
Вибір схеми визначається маршрутом експлуатації та складом сенсорів, а не уподобаннями команди. Модульний конвеєр розділяє сприйняття, планування та керування на незалежні блоки: відмова локалізується в конкретному вузлі, блок можна замінити, не перезбираючи систему цілком.
Наскрізна навчувана модель навчається одразу на відео та телеметрії — впевненіша в складних сценах, але потребує великого обсягу розмітки і слабо пояснює рішення.
Гібридна схема поєднує навчуване сприйняття з формальним плануванням: поведінка залишається перевірюваною, якість розпізнавання зростає. Дообучення готового стеку під свій парк сенсорів дає результат швидше за інших, але залишається в межах вихідної архітектури.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Модульний конвеєр | Заданий маршрут, розбір інцидентів за вузлами, поетапне введення функцій | Помилки накопичуються на стиках блоків, нові сцени потребують ручного налаштування |
| Наскрізна навчувана модель | Різноманітне середовище, є потік даних і розмітка | Потрібні регулярні перенавчання, рішення слабо інтерпретовані |
| Гібридна схема | Потрібні і керована поведінка, і точне розпізнавання | Складніше в супроводі: дві підсистеми та правила їх узгодження |
| Дообучення готового стеку | Швидкий старт на своєму парку сенсорів | Упирається в межі базової моделі та її оновлення |
Розбір починаємо з трьох питань: які сенсори вже стоять, наскільки передбачуваний маршрут і хто буде розбирати інциденти після запуску. Відповіді на них і визначають, який варіант витримує ваші умови експлуатації.
Етапи розробки: від аудиту сценаріїв до приймання
Розробка системи автономного водіння — не один довгий спринт, а послідовність етапів, на кожному з яких є перевірюваний результат.
Процес будуємо так, щоб стан модулів сприйняття, планування та керування було видно за метриками на розмічених наборах сценаріїв, а не за презентаціями.
- Аудит сценаріїв. Фіксуємо умови експлуатації, класи об'єктів і маневри, які система зобов'язана відпрацьовувати, і те, що свідомо залишаємо за периметром. Підсумок — матриця сценаріїв із пріоритетами та перелік обмежень.
- Підготовка даних. Збираємо записи сенсорів, розмічаємо та балансуємо набір за рідкісними ситуаціями, окремо формуємо перевірні вибірки, що не перетинаються з навчальними.
- Налаштування модулів. Сприйняття, планування та керування налагоджуємо окремо, у кожного свої метрики: повнота виявлення, частка пропущених об'єктів, плавність траєкторії. У загальний контур збираємо лише після проходження порогу за кожним модулем.
- Випробування. Спочатку віртуальний пробіг у симуляторі на тисячах сценаріїв, потім закритий майданчик і дороги загального користування з водієм-випробувачем. Кожен інцидент розбираємо до причини, а не до симптому.
- Калібрування та регрес. Будь-яка зміна проходить повний регрес на закріпленому наборі: система не повинна вигравати на новому сценарії, втрачаючи на старому.
- Приймання системи. Здаємо за узгодженим протоколом: метрики безпеки, частка втручань водія, час відновлення після відмови сенсора, звіт про покриття сценаріїв і документація.
Контрольна точка кожного етапу — відтворюваний прогін, який можна повторити на вашій стороні. Спірні місця закриваємо до старту наступного етапу, а не після здачі.
Постачання з автономного водіння: моделі та регламенти
Результат проєкту — не показ на полігоні, а комплект, з яким ваша команда продовжує роботу без нас. Кожен артефакт версіонується у вашому репозиторії, перевіряється на прийманні та залишається у вас разом із правами на використання.
- Ваги навчених моделей сприйняття, планування та керування в експортованому форматі, з контрольними метриками якості на відкладеній вибірці.
- Конфігурації та скрипти відтворення навчання — від підготовки даних до вивантаження моделі, щоб повторний прогін давав зіставний результат.
- Схеми архітектури: потік даних від сенсорів до керуючих впливів, межі модулів, режими деградації при втраті сигналу.
- Регламенти випробувань: набори сценаріїв, критерії проходження, порядок прогонів на стенді та закритому майданчику, правила розбору розбіжностей.
- Документація: інтерфейси між модулями, формати даних, вимоги до розмітки, інструкції з розгортання контуру на вашому обладнанні.
- Навчання інженерів замовника — сесії на ваших даних і вашому стенді, щоб команда сама правила набори, дообучала моделі та читала звіти прогонів.
- Протоколи приймання, відомі обмеження та журнал рішень щодо спірних сценаріїв як основа для наступних ітерацій.
Приймання йде за узгодженими критеріями: сценарій закрито, коли відтворюється на вашому стенді та підтверджений протоколом. Що не проходить — залишається в роботі, а не переноситься в «відомі обмеження».
Кейс: скорочення відмов при щільному русі
Клієнт прийшов із працюючим прототипом: автомобіль проходив міський маршрут, але на щільному русі автоматичний режим доводилося переривати занадто часто — близько 12 втручань водія на кожні 100 км. Понад половина випадків — злиття потоків, вузькі смуги та перестроювання сусідів. Кожен такий заїзд обнулявся і не давав накопичити статистику для виведення системи в експлуатацію.
Де втрачалася надійність
Розбір записів показав, що причина не в окремій моделі, а на стику ланок. Сприйняття оновлювало сцену рідше, ніж потребував планувальник, а треки об'єктів рвалися при короткому перекритті — автобус закривав легкову, і вона з'являлася заново вже в небезпечній близькості.
Планувальник працював за єдиним варіантом траєкторії без оцінки ризику, тому замість плавного об'їзду обирав різке гальмування.
Що змінили і що отримали
Ми переробили конвеєр сприйняття та планування: зв'язали треки за історією руху, додали передбачення маневрів сусідів і перевели планувальник на порівняння кількох траєкторій з оцінкою ризику за кожною.
Сценарії проганяли в симуляторі CARLA і на закритому майданчику, потім — на тому ж міському маршруті.
Втручання на 100 км впали з 12 до 3, хибні гальмування — майже втричі, частка заїздів без жодного переривання зросла з 18% до 64%. Тестовий парк став проходити маршрут втричі швидше, бо перестав перезапускати заїзди.
Чим відрізняється модульний конвеєр від наскрізної моделі?
Різниця в тому, де проходять межі відповідальності. У модульному конвеєрі сприйняття, прогноз поведінки інших учасників, планування траєкторії та керування приводами — окремі блоки з явними контрактами на вході та виході.
Наскрізна модель навчається від сенсорів до команд керування напряму, і проміжні подання в ній не описані людиною, а виникають як побічний продукт навчання.
Розбірність помилок — головний вододіл. У конвеєрі збій локалізується: за записом і проміжними артефактами видно, що об'єкт загубився на етапі сприйняття, а не був знятий планувальником, а один блок можна замінити або посилити правилами, не перенавчаючи решту.
У наскрізної моделі такої прив'язки немає: причина невдачі шукається статистикою за великими вибірками, і відповідь «мережа не пояснює» — це не відповідь.
Вимоги до даних теж розходяться. Модулям достатньо своїх наборів: детекція — розмітка рамок, прогноз — треки, планування можна доводити на симуляції та геометрії.
Наскрізній моделі потрібні довгі узгоджені серії, де мітки станів і сигнали керування синхронні, інакше навчання йде в артефакти. Рідкісні, але критичні сценарії доводиться набирати окремо — інакше модель їх просто не побачить у загальній масі.
Супровід випливає з цього. Конвеєр релізиться частинами, версіонує інтерфейси між модулями та перевіряє регресію за метриками стиків — оновлення одного блоку не ламає решту.
Наскрізна модель при правці будь-якої ділянки перенавчається цілком, і перевіряти потрібно весь маршрут заново.
Тому на практиці частіше збирають гібрид: наскрізні блоки всередині модульної рами, де за інженером залишається контроль над стиками та можливість пояснити кожну відмову.
Часті технічні питання щодо впровадження та випробувань
До старту робіт замовник перевіряє не архітектуру, а ризики: як система поводитиметься в дощ і сніг, хто відповідає за інцидент, чи можна дообучати її на своїх даних і що робити з уже встановленим парком сенсорів.
Нижче — короткі відповіді щодо кожного сумніву; на розборі задачі проходимо їх на вашій конфігурації та маршрутах.
Як проходять випробування в складну погоду?
Сценарії з дощем, снігом, туманом, низьким сонцем і брудом на сенсорах виносимо в окремий набір перевірок і проганяємо регулярно, а не один раз перед здачею.
Окремо перевіряємо деградацію: якщо канал втрачає дані, система знижує швидкісний режим і передає керування оператору замість того, щоб рухатися на неповній картині світу. Саме такі перевірки найчастіше розкривають слабкі місця, які не видно на сухому асфальті.
Хто відповідає за інцидент?
Зони відповідальності фіксуємо в договорі та регламенті експлуатації — вони не маються на увазі, а описані. Ми відповідаємо за компоненти, які постачаємо, і за доказову базу: безперервні журнали подій, записи сенсорів і можливість відновити картину пригоди покроково. Без такого сліду розбір неможливий, тому запис ведеться з першого дня випробувань.
Чи можна дообучити систему на наших даних?
Дообучення на даних замовника — штатна частина роботи, а не окремий проєкт. Збираємо записи з ваших маршрутів, розмічаємо складні випадки, дообучаємо та перевіряємо на відкладеній вибірці плюс на закритому наборі сценаріїв, щоб не втратити вже досягнуту якість.
Кожен цикл оновлення проходить регресійні перевірки, інакше правка під одну дорогу ламає поведінку на іншій.
У нас частково встановлений парк сенсорів — доведеться міняти все?
Частково встановлений парк — нормальний старт. Спочатку описуємо, що вже стоїть і які ділянки маршруту покриті, потім добудовуємо лише прогалини: сліпі зони, відсутні ракурси, брак перекриття.
Наявні сенсори перевіряємо на калібрування та синхронізацію — часто їх достатньо, а заміна потрібна лише там, де покриття фізично не закривається.
Що залишилося за рамками — строки під ваш маршрут і склад робіт під поточне залізо. Опишіть задачу: повернемося з оцінкою та планом.Обговоримо задачу: які дані потрібні для оцінки
Оцінка задачі автономного водіння починається не з вибору моделі, а з інвентаризації того, що вже є: без вихідних даних будь-яка цифра щодо строків — здогад. Нижче — мінімум, після якого ми повертаємося з планом робіт і декомпозицією за етапами.
- Сценарії експлуатації — де рухається платформа: закрита територія, місто, траса; які маневри обов'язкові, а які неприпустимі.
- Записи сенсорів — сирі дані з камер, лідарів і радарів з мітками часу, синхронізацією та калібруванням між датчиками.
- Розмітка та її якість — чи є анотації об'єктів, смуг і вільного простору, хто їх робив і за якою інструкцією.
- Вимоги до поведінки — правила пріоритету, дистанції, реакції на пішоходів і нештатні ситуації, описані текстом, а не «на словах».
- Платформа та обмеження — обчислювальний модуль, доступна пам'ять, допустимий час реакції контуру керування, інтерфейси до приводів і гальм.
- Метрики приймання — за чим приймаємо результат: частка пройдених сценаріїв, число втручань оператора, перелік неприпустимих відмов.
- Інфраструктура — де навчаємо та відтворюємо експерименти: кластер, сховище, версіонування наборів даних і ваг моделей.
Обговорення вимог іде паралельно збору: ми фіксуємо, що входить в обсяг, а що виносимо за дужки, і де межа відповідальності між модулями сприйняття, планування та керування.
Якщо частина даних відсутня — це не зупинка, а окремий етап підготовки в плані, з зрозумілою вартістю за строками та ризиком. Надсилайте те, що є: повернемося з оцінкою, порядком робіт і переліком того, що потрібно добрати до старту.
