Коли 0,1° має значення: як ми вирішували задачу автономного зчеплення там, де пасували стандартні бібліотеки

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

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

На відміну від класичного autonomous driving на дорогах загального користування, ця задача має іншу природу: обмежений простір, велика кількість об’єктів (трейлерів), складна кінематика та високі вимоги до точності. Американські масштаби вражають: на одному складі ми нарахували 64 трейлери, запарковані для завантаження. У такому хаосі тягач («трактор», що підчіпляє причепи) має маневрувати з ювелірною точністю.

Ключовим елементом цього процесу є зчеплення: шкворень (king-pin), розташований під причепом, має точно увійти в так зване «п’яте колесо» тягача. Саме ця вимога визначає жорсткі обмеження на точність оцінки положення та прогнозування траєкторії руху. При цьому сам шкворень зазвичай не потрапляє в поле зору сенсорів — його положення доводиться відновлювати непрямо, на основі геометрії причепа та спостереження за його видимими частинами.

Додаткову складність створюють можливі великі кути між тягачем і причепом. Коли кут перевищує 90°, звичне уявлення про «передню» частину причепа втрачає сенс: вона фактично переходить у бокову площину відносно тягача, а бічні поверхні стають основою для оцінки орієнтації. Це вимагає від алгоритмів адаптивної інтерпретації геометрії об’єкта залежно від конфігурації системи. Нас цікавили і інші маневри, такі як docking (підведення до позиції) та parking.

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

Великі компанії рідко делегують повноцінний автономний проєкт «від і до». Найчастіше аутсорс-команді передають або рутинні блоки, або те, що R&D-центр намагався зробити самотужки, але не досяг результату. Ми не знали заздалегідь, де саме у замовника стався збій — це стало зрозуміло вже пізніше, під час нашої імплементації.

Глобальна система керування тягачем, розроблена замовником, реалізує високорівневу логіку поведінки на базі ROS2. Вона відповідає за навігацію машини територією складу та підведення її до цільової точки з точністю приблизно 10 метрів. Після входу в цю зону система перемикається в режим зчеплення (hitching), у якому починає працювати вже наша підсистема.

Перед командою постали такі завдання:

• Визначити потрібний трейлер серед, інколи десятків, аналогічних. На великому складі ми нарахували понад 60 паркомісць. Система отримує від замовника конкретний ID — напис на борту, який ми маємо розпізнати, щоб підтвердити: це саме той об’єкт, до якого треба під’єднатися.
• Оцінка в реальному часі:
• відносний кут θ,
• положення трейлера (координати king-pin) відносно тягача (x,y).
• Забезпечити видачу результатів з частотою не менше 5 Гц.

Фактично йдеться про побудову віртуального сенсора, який замінює класичні вимірювальні системи та передає в навігаційну підсистему X-Y відстань і кут. Це базовий набір параметрів, необхідний для розрахунку траєкторії та її уточнення в режимі реального часу.

Найцікавіший момент у цій задачі — це саме точність. У замовника була окрема математична команда, яка розробляла вимоги до системи. Вимоги до цієї «віртуальної» точності були граничними:

• До 2 см по координатах.
• До 0.1–0.2° по куту.

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

Сенсорний стек

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

Камери та таргет-платформа

В апаратному сетапі, з яким замовник намагався реалізувати задачу до нашого залучення, використовувалися камери Luxonis OAK-D. Це стереокамери з парою монохромних сенсорів (лівого та правого) і центральним RGB-сенсором. Початково замовник намагався визначати необхідні координати за допомогою стереозору (оцінка глибини та побудова point cloud). У нашому рішенні ми свідомо обмежилися використанням лише RGB-каналу, відмовившись від повторення експериментів зі стерео.

Практика показала, що для фінального рішення ML-частина на базі RGB є стабільнішою, оскільки:

• Деградація точності в стерео з відстанню суттєва і не вкладається в вимоги.
• Більшість ML моделей навчені на RGB-зображеннях (3 канали).

Щодо обчислювальної частини, перший прототип був реалізований на звичайному ПК з GPU (перша ревізія). Однак замовник справедливо зазначив, що такий підхід не відповідає automotive-вимогам — рішення має базуватися на вбудованій платформі. У підсумку ми вирішили залишитися з NVIDIA, але на Jetson Orin NX (неоптимально, але вже краще). Це також дало змогу використати наявні інструменти та напрацювання екосистеми NVIDIA для оптимізації моделей.

LiDAR

LiDAR у цій системі відповідає за отримання точної геометрії, визначення площини трейлера.

Спочатку ми використовували LiDAR із кутом огляду 120°, направлений назад на трейлер. Згодом ми замінили його на круговий лідар. Це було зроблено не стільки через технічну необхідність, скільки заради уніфікації hardware у різних компонентах системи замовника.

Важливою особливістю стало використання інтенсивності сигналу лідара:

• Інтенсивність дає додаткову інформацію, що критично важливо для Camera-LiDAR calibration. Ми могли чітко бачити, чи збігаються точки лідара з відповідним зображенням на камері.
• Це значно спростило візуальну перевірку суміщення даних («ф’южну»).

Перехід до ML-підходу

Замовник будував рішення на основі стереокамер, використовуючи класичний pipeline: оцінку глибини, побудову point cloud і подальшу геометричну обробку. Проте навіть із застосуванням спеціалізованих камер із вбудованими AI-функціями система не забезпечила необхідної точності та стабільності.

Ми базувалися на ML-підході з початку дискавері-фази. Рішення формувалося як складний багатокомпонентний pipeline:

• Детекція об’єктів.
• Оцінка геометрії (keypoints).
• OCR (розпізнавання номерів).
• Трекінг.
• Сенсор ф’южн.
• постобробка.

Крім основного завдання, замовник додав ще кілька запитів. Наприклад, наша модель мала розпізнавати лінії розмітки та місця, де паркуватися заборонено. Ще одним доповненням став базовий Safety.

У межах цього ML-пайплайну ми додали детекцію перешкод. Під час маневрування ми маємо бути впевнені, що на шляху немає людини, яка випадково опинилася між тягачем і трейлером. Або щоб не зачепити інший автомобіль. Для цього ми інтегрували швидку модель на базі MobileNet — вона легка, працює швидко, для об’єктів типу pedestrians чи vehicle більш ніж достатньо.

Фактично, перехід на ML дозволив нам не просто «бачити» залізо трейлера, а розуміти контекст усього, що відбувається навколо машини під час маневру.

Архітектура рішення

Щоб забезпечити точність у 2 см, нам знадобився багаторівневий підхід, де ML-моделі працюють у синергії з класичними методами комп’ютерного зору.

Детекція фронтальної частини (Detectron2)

Для пошуку трейлерів ми використали модифікований, донавчений Detectron2 від Facebook. Звичайні моделі, які просто повертають Bounding Boxes, нам не підходили. Нам потрібно було витягнути максимум інформації про обʼєкт. Тому ми адаптували модель так, щоб вона повертала Keypoints — такий собі «скелет» фронтальної частини трейлера, оптимізований до чотирьох ключових точок.

Ці точки дозволяли:

• Визначити центр фронтальної частини трейлера (базуючись на вертикальних лініях, межах трейлера).
• Підготувати дані для LiDAR-ф’южн.

Таким чином, виходом моделі є набір полігонів (кожен описаний чотирма точками), що відповідають окремим трейлерам. Наступним кроком було виділення з повного зображення області фронтальної частини трейлера (crop) та подальший пошук на ній тексту, який відповідає ідентифікатору трейлера (text detection).

OCR: Битва з вертикальним текстом

Коли трейлер знайдено, система має підтвердити його ID. Для цього ми обрали PaddleOCR, але стандартна бібліотека «з коробки» стала нашим найбільшим головним болем.

По-перше, номер може бути частково перекритим. По-друге, якість зображення є нестабільною. І найцікавіше — у США номери на трейлерах нанесені вертикально на бічній стійці (існують випадки горизонтального ID разом з вертикальним). Виявилося, що більшість сучасних детекторів і рекогнайзерів просто не вміє працювати з вертикальним текстом — вони або ігнорують його, або видають лише частину. Наші спроби, напрацювання щодо розвʼязання цієї проблеми розрослися на 12 сторінок презентації замовнику.

Просте повернення картинки на 90° не спрацьовувало, чи спрацьовувало частково на різних датасетах. Що реально довелося випробовувати:

• Сегментація тексту на частини.
• Агресивний preprocessing.
• зміна контрасту,
• нормалізація,
• фільтрація шуму.
• Запуск кількох варіантів inference.
• Агрегація і фільтрація результатів.

Цей блок вимагав значного обсягу експериментів і фактично став окремим R&D напрямком. Ключовий висновок: OCR у реальному production — це не підключення бібліотеки, а складна система евристик.

Як тільки ID підтверджено, система переходить у режим трекінгу вибраного трейлеру, а OCR повністю вимикається. Це дозволяє нам економити ресурси Jetson Orin і суттєво зменшити Latency.

Sensor Fusion: LiDAR + Camera

Після ідентифікації ми поєднуємо дані. Полігон, отриманий з камери, накладається на дані LiDARу.

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

Робота при деградації даних (Lucas—Kanade)

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

Щоб не втратити оцінку положення та кута, ми перемикаємося з геометрично-орієнтованого підходу на трекінг локальних ознак із використанням методу Лукаса—Канаде (Lucas—Kanade optical flow). Замість роботи з формою об’єкта алгоритм відстежує зміщення окремих характерних точок на поверхні трейлера — наприклад, заклепок або текстурних неоднорідностей.

Це дозволяє стабільно оцінювати відносне зміщення (зокрема по горизонталі) навіть у разі, коли глобальна геометрія об’єкта вже не спостерігається. Такий підхід демонструє, що класичні методи комп’ютерного зору залишаються критично важливими навіть у системах, побудованих навколо ML.

Особливості docking та parking

Хоча маневр зчеплення (hitching) є найбільш технологічно складним, система також охоплює сценарії docking (підведення тягача до позиції) та parking (розміщення самого трейлера у визначеній зоні). У цих випадках наш підхід суттєво змінюється.

Коли ми говоримо про паркування чи докінг, нам вже не потрібно розпізнавати ID чи шукати конкретні вертикальні лінії фронтфейсу. Тут основна роль переходить від камери до LiDAR. Алгоритм для цих сценаріїв базується на чистій геометрії:

• Кластеризація точок.
• Оцінка площини.
• Обчислення кута: розрахунок орієнтації об’єкта відносно тягача.

Така зміна пріоритетів у сенсорному стеку дає кілька важливих переваг:

• Вища стабільність: геометричні розрахунки за хмарою точок менш схильні до «тремтіння», ніж результати ML-детекції.
• Економія ресурсів: Ми витрачаємо менше обчислювальної потужності Jetson Orin, оскільки вимикаємо важкі нейронні мережі для OCR та детекції об’єктів.

ML незамінний для розуміння семантики, але задачі чистої геометрії часто значно швидше та точніше вирішуються за допомогою лідара.

Виклики, валідація та результати

Коли ми перейшли до фінальних тестів, теорія зіткнулася з жорстокою реальністю заліза та фізики. Найбільші складнощі виникли не стільки з нейромережами, скільки з «примхами» заліза та середовища.

— Калібрування сенсорів

Camera—LiDAR alignment був критичним для кінцевої точності. Найменша помилка в суміщенні призводила до того, що на відстані 10 метрів похибка в пару пікселів перетворювалася на дециметри в реальності.

— Часткова видимість

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

— Дані та валідація

Для оцінки точності ми використовували RTK GNSS із двома антенами для визначення heading. При цьому виникла типова ситуація: оцінки нашої системи розходилися з даними GNSS. Це одразу підняло питання коректності часової синхронізації між сенсорами.

З’ясувалося, що проблема полягала в затримках та розсинхронізації таймстемпів (latency та timestamp drift) між різними джерелами даних. Оскільки GNSS використовувався лише для валідації, ці аспекти спочатку не були достатньо точно налаштовані.

Особливо чітко це проявилося під час руху разом з еталонним трейлером, оснащеним GNSS-антенами: замість стаціонарної цілі ми мали рухому систему відліку, що дозволило краще виявити накопичення помилок синхронізації у часі.

— Точність

Ми боролися за кожен міліметр. Як показала практика, похибка у кілька пікселів на зображенні призводить до сантиметрових помилок у кінцевих координатах.

— Performance (Jetson Orin NX)

Нам потрібно було запустити кілька важких моделей одночасно (trailer detector, text detector, OCR), забезпечивши стабільну частоту 5 Гц. Для цього ми використали INT8-квантизацію. Це дозволило знайти баланс між швидкістю та точністю, не «перегріваючи» embedded-платформу.

Досягнуті результати

Завдяки поєднанню ML та геометричних методів ми вийшли на цільові показники:

• Точність координат: ~1.1—2 см.
• Точність кута: ~0.2°.
• Стабільна робота на частоті 5 Гц.

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

Ми вирішили це через введення точки «фіксації» на відстані близько 3 метрів. До цієї межі система безперервно оновлює оцінку положення (з допустимою похибкою), а тягач виконує підрулювання.

На відстані приблизно 3 метрів ми робимо коротку паузу (близько 20 кадрів), щоб кабіна стабілізувалася і зникли паразитичні коливання підвіски. Після цього фіксуються фінальні значення відстаней і кута. На цьому етапі (за цієї відстані) точність, що не відповідає вимогам, є критичною для правильного завершення маневру.

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

Невирішені питання та висновки

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

Для вирішення цієї проблеми ми запропонували окремий ML-підхід, який базується на даних лідару та референтних вимірюваннях GNSS.

Підсумовуючи проєкт, можна сказати:

• ML необхідний, але недостатній. Він дає розуміння об’єктів, але точність забезпечують математика та Sensor Fusion.
• Інтеграція — це головне. Найбільша складність не в моделях, а в тому, як «підняти» їх на реальному залізі та забезпечити достатню швидкодію.