Зайнятість парковки по камері: синтетика перевіряє ідею, реальні кадри дають точність

Найдорожча частина комп'ютерного зору з'являється до моделі

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

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

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

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

Тривимірна сцена сама знає, де стоїть машина

Паркувальні майданчики та автомобілі не моделювали з нуля. Готові 3D-об'єкти взяли з платних наборів, зібрали в Blender і керували ними Python-скриптом. Генератор розставляв машини, змінював умови й рендерив кадр за кадром.

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

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

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

Перша модель довела ідею, але не замінила реальну камеру

Синтетичний кадр усе одно залишається зображенням із 3D-редактора. У справжньому відео з'являються фактура асфальту, відблиски, шум камери, несподівані тіні, частково закриті машини та безліч дрібниць, які генератор не відтворює точно.

Тому після перевірки ідеї зібрали реальні знімки з відкритих датасетів. Їх знімали й публікували інші люди; власний неіснуючий об'єкт для статті не вигадувався. З великого набору відібрали репрезентативні кадри й приблизно за п'ять робочих днів підготували розмітку.

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

На реальних зображеннях модель донавчили, тобто виконали fine-tune. За кілька місяців експериментів її довели до робочого стану. Після донавчання автомобілі на справжніх знімках розпізнавалися помітно точніше, ніж універсальною моделлю без адаптації до задачі.

Синтетика тут заощадила не всю майбутню роботу, а найризикованіший перший внесок. Реальні дані все одно знадобилися, але до їх розмітки перейшли вже після підтвердження підходу.

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

Один кадр перетворюється на статуси місць і потік машин

У робочому контурі використовується YOLO - детектор об'єктів, який знаходить автомобілі в кадрі. Система отримує відеопотік, веде виявлені машини між кадрами й зіставляє їх із заздалегідь розміченими паркувальними місцями.

Загальні можливості YOLO ширші. На його основі можна оцінювати швидкість, будувати траєкторії та теплові карти активності. У цьому проєкті такі функції не реалізовувалися: завдання обмежене детекцією автомобілів, зайнятістю місць, потоком і тривалістю стоянки.

Ця межа важлива, тому що опис готової бібліотеки легко прийняти за функції конкретної системи. Тут перелічено лише те, що було зібрано й перевірено в проєкті.

Нова камера починається зі стоп-кадру

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

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

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

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

Експерименти версіонували, синтетику вирішили перегенерувати

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

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

Це не загальне правило проти версіонування даних. Коли з'являється цінна робоча модель і кілька реальних наборів, можливість точно відновити навчання стає важливішою. І навіть у дослідницькій фазі відтворюваність нікуди не поділася: сценарій генерації залишався джерелом синтетики, а MLflow зберігав параметри й результат навчання. Ми прибрали шар, який не окуповувався, а не можливість зрозуміти, як була отримана модель.

Межа проходить там, де починається справжня камера

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

Тонкого налаштування потребували обидві сторони. Генератор сцен у Blender потрібно калібрувати, щоб різноманіття умов залишалося осмисленим. Fine-tune на реальних даних теж не виконується однією кнопкою: необхідно підбирати набір, параметри й порівнювати експерименти.

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

Парковка показує підхід, а не межу застосування

Зв'язка "камера, детектор, зони" підходить і для інших завдань, де об'єкт можна побачити й порахувати. У логістиці це техніка та зайняті майданчики, на дорозі - потік на вулиці чи перехресті, у виробничому сценарії - кількість об'єктів у зоні або виконаних дій.

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

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