Як ми будували систему виявлення дронів I-SEE на основі комп’ютерного зору: від ідеї до MVP

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

Вітаю усіх читачів DOU, мене звати Віктор. Через ситуацію в нашій країні я займався тим, що допомагав хлопцям на фронті. І от в один момент мене попросили «придумати» якусь протидію дронам. Для початку, звісно, щоб просто їх бачити і встигати реагувати та продидіяти.

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

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

Ключові вимоги до системи:

• Автономна робота без інтернету.
• Обробка відео в реальному часі.
• Робота на обладнанні споживчого класу.
• Мінімум хибних спрацювань.

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

Формалізація задачі: визначення цілей виявлення

Перед початком розробки важливо було чітко визначити, що саме система повинна виявляти.

Класифікація об’єктів

Система розроблялася для виявлення двох основних категорій БПЛА:

• Мультикоптери — квадрокоптери та подібні багатороторні платформи.
• Літаки-крила — безпілотники типу «літаюче крило».

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

• Спеціалізувати детектор під специфічні візуальні ознаки кожного класу.
• Перемикатися між режимами залежно від ситуації.
• Тренувати моделі незалежно на різних датасетах.

Технічні параметри

Система повинна була:

• Обробляти відеопотік в режимі реального часу.
• Працювати на GPU середнього класу.
• Забезпечувати стабільні показники продуктивності.
• Мінімізувати хибні спрацювання.

Обмеження MVP

Свідомо виключили:

• Нічне виявлення (потребує thermal imaging).
• Складні погодні умови (туман, сильний дощ).
• Автоматичні контрзаходи (фокус на детекції).

Ці обмеження дозволили сконцентруватися на ядрі функціональності.

Вибір підходу: аналіз альтернатив

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

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

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

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

Архітектура системи: головні компоненти

Ми обрали модульну архітектуру, де кожен компонент відповідає за конкретну задачу:

Ключові рішення

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

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

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

Збір навчальних даних: найскладніша частина

Найбільший виклик — це не архітектура чи алгоритми, а навчальні дані.

Чому готові датасети не підходили

Загальні датасети (COCO/ImageNet): містять категорії «літак» та «птах», але зовсім не те, що потрібно для виявлення БПЛА в реальних бойових умовах. Масштаб об’єктів, контекст, умови зйомки — все інакше.

Публічні drone datasets: переважно це фотографії З дронів (aerial photography), а не дронів ЯК цілей виявлення. Зовсім інша задача.

Як збирали власні дані

• Реальні відеозаписи: найцінніші, але найскладніші в отриманні. Потрібні різні умови: час доби, погода, фон, відстань до об’єкта.
• Публічні відеоматеріали: знайшли частину матеріалів у відкритих джерелах, але якість варіювалася, багато артефактів через стиснення.
• Синтетичні дані: експериментували з генерацією, але sim-to-real gap був помітним. Використали лише як доповнення.
• Hard negative mining: В продакшн-режимі система зберігала всі хибні спрацювання. Це дало найцінніші приклади: пташки, бруд на лінзі, бліки. Після додавання цих прикладів до датасету точність значно зросла.

Розмітка

Використовували стандартні інструменти для анотування. Спочатку помилково розмічали лише «ідеальні» кадри — модель не справлялася з реальністю. Довелося додати багато складних сценаріїв: часткова оклюзія, об’єкти на фоні дерев, далекі цілі.

Головний урок: якість та різноманітність даних важливіша за їх кількість. Краще мати менше, але покриваючи всі edge cases.

Вибір та оптимізація моделей

Пошук балансу

Процес селекції архітектури нейромережі вимагав глибокого розуміння залежності між структурною складністю моделі та її продуктивністю в реальному часі. Ключовим викликом став пошук балансу, де кількість параметрів та глибина мережі (кількість шарів) забезпечують достатню роздільну здатність для детекції малих об’єктів, але не призводять до критичного зростання затримок (latency) під час інференсу.

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

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

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

Ключові оптимізації

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

Паралельно з цим для підвищення узагальнюючої здатності моделі та запобігання перенавчанню було впроваджено пайплайн агресивної аугментації даних. Ми застосували комплекс геометричних та фотометричних трансформацій, включаючи варіації масштабу, змішування зображень та емуляцію складних умов освітлення, що зробило детектор стійким до широкого спектра реальних сценаріїв. Також було вирішено проблему дисбалансу класів у навчальній вибірці: замість простого дублювання даних рідкісних категорій БПЛА ми застосували механізм зважування функції втрат (loss weighting), що змусило нейромережу приділяти пріоритетну увагу менш представленим класам під час градієнтного спуску.

Що не спрацювало

Двостадійні детектори: теоретично точніші, але на практиці занадто повільні для real-time.

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

Мультимасштабна обробка: ідея обробляти кадр в кількох масштабах виглядала привабливо, але каралася швидкістю.

Практичні результати

Після численних експериментів досягли таких результатів:

• Стабільна швидкість обробки 45-50 FPS на одній камері.
• Прийнятна точність виявлення в реальних умовах.
• Робота на GPU середнього класу без проблем.

Головний висновок: не існує «ідеальної» моделі. Потрібен баланс під конкретну задачу та обмеження системи.

Проблеми реального світу

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

Проблема 1. Хибні спрацювання

Симптом: система видавала сповіщення занадто часто. При аналізі виявилось — пташки, особливо великі, схожі за розміром на малі БПЛА на відстані.

Рішення:

Використали комбінацію підходів:

• Фільтрація за поведінкою (стабільні треки vs хаотичні рухи).
• Аналіз форми об’єкта.
• Накопичення прикладів для покращення моделі.

Проблема 2. Втрата треку при оклюзії

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

Рішення:
Реалізували механізм збереження «загублених» треків з предикцією очікуваної позиції. При появі нового об’єкта перевіряємо, чи може він бути одним із загублених треків.

Проблема 3. Нестабільна продуктивність

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

Рішення після профілювання:

• Оптимізували попередню обробку (робили її опціональною).
• Додали буферизацію кадрів.
• Розділили обчислювальні потоки для різних завдань.

Проблема 4. Витоки пам’яті

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

Причина: необмежене накопичення історії всіх треків з моменту запуску.

Рішення: обмежили розмір історії фіксованою кількістю останніх точок.

Оптимізація під реальний час

Апаратні вимоги

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

Ключові оптимізації

Апаратне прискорення. Використання апаратних можливостей GPU для прискорення inference. Це дало значний приріст швидкості без втрати точності.

Багатокамерна обробка. При роботі з кількома камерами важливо організувати паралельну обробку. Наївний послідовний підхід призводить до лінійного зростання навантаження.

Рішення — concurrent processing та batch inference, що дозволяє майже лінійно масштабувати кількість камер без пропорційного падіння швидкості.

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

Оптимізація preprocessing. Перенесення підготовки зображень на GPU значно зменшує час обробки кожного кадру.

Результати. Система стабільно обробляє 45-55 FPS на одній камері та підтримує кілька камер одночасно на обладнанні середнього класу.

Межі MVP та практичні результати

Свідомі обмеження

Для першої версії системи ми чітко визначили межі функціональності:

Нічне виявлення. Потребує thermal imaging камер та окремого ML pipeline. Це окремий напрям розвитку.

Класифікація типу дрону. Детальна ідентифікація конкретних моделей на великій відстані — технічно складна задача. Базова категоризація (мультикоптер/літак-крило) достатня для більшості сценаріїв.

Що працює

Система успішно справляється з:

• Real-time обробкою відео на швидкості 45-55 FPS.
• Багатоб’єктним трекінгом зі збереженням ідентифікаторів.
• Обчисленням координат та траєкторій.
• Предикцією руху об’єктів.
• Багатокамерною обробкою.
• Системою оповіщень через різні канали.

Практичні обмеження

• Погодні умови: густий туман та сильний дощ суттєво знижують видимість (фізичне обмеження оптики).
• Оклюзія: тривале перекриття (>5 секунд) може призвести до втрати треку.
• Швидкі маневри: різка зміна траєкторії може тимчасово знизити точність предикції.

Ми свідомо документували ці обмеження для користувачів.

Головні уроки та помилки

Урок 1. Датасет важливіший за архітектуру моделі

Ми витратили 2 тижні, підбираючи «ідеальну» архітектуру, перебирали усі доступні, навчали та порівнювали. Але під такі задачі немає ідеальної архітектури, потрібно «допилювати».

Потім витратили тиждень на збір 2000 додаткових «складних» прикладів (малі об’єкти, фони, оклюзії).

Урок 2: Real-time — це не лише швидкість inference

Наївне розуміння: «якщо модель робить 30 FPS → система real-time».

Реальність:

• Декодування кадру (RTSP): 8-15мс.
• Preprocessing: 5-10мс.
• Inference: 30-40мс.
• Tracking: 10-15мс.
• Coordinate calculation: 5мс.
• UI rendering: 16мс (60 FPS UI).

Total latency: 74-96мс в оптимальному випадку.

Висновок: оптимізувати треба весь pipeline, не лише модель. Ми витратили більше часу на оптимізацію деталей (CUDA streams, threading, memory management), ніж на саму модель.

Урок 3. Edge cases — це не 5% випадків

На папері: «пташки — rare edge case, 2% detections».

У продакшні: в парку біля озера пташок буває 50-100 на годину. Система спамила alerting, потрібно було калібрувати рівень впевненності та налаштовувати трекінг. Але в бойових умовах, у військових, ситуація геть інша, ніж в простому житті.

Урок 4. Багатокамерна система — не лінійне масштабування складності

Ми думали: 1 камера працює → 4 камери = 4x той самий код.

Реальність:

• Track ID conflicts: CAM1_ID5 vs CAM2_ID5 — один дрон чи два?
• Координатна фузія: якщо 2 камери бачать один об’єкт, як зводити координати?
• Threading: race conditions, deadlocks, memory corruption при неправильній синхронізації.

Висновок: multi-camera — це якісно інший рівень складності. Довелося переписати 40% коду для thread-safe архітектури.

Наш досвід будування MVP

Підсумовуючи результати кількох місяців інтенсивної розробки, нам вдалося реалізувати автономний комплекс виявлення БПЛА, здатний стабільно обробляти відеопотік з частотою 45–55 кадрів на секунду при одночасному підключенні кількох камер. Важливо, що це досягнуто на базі доступного споживчого обладнання без залежності від зовнішньої інфраструктури чи інтернет-з’єднання. Архітектурним фундаментом системи став перехід до локальних обчислень на edge-пристроях з GPU, використання спеціалізованих моделей для різних класів цілей та глибока оптимізація паралельних потоків даних.

Проте найскладнішою частиною шляху виявився не підбір алгоритмів, а побудова надійного інженерного процесу. Ключові виклики лежали у площині збору специфічних датасетів, боротьби з нетиповими сценаріями (edge cases) у польових умовах та забезпеченні стабільної синхронізації мультисенсорної мережі. Безумовно, поточна версія системи має фізичні обмеження, продиктовані оптичним спектром роботи — зокрема, залежність від освітлення та погодних умов, а також фокус на узагальненій класифікації загроз.

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

Але найголовніше — що після MVP та як його будувати, щоб воно було актуальним і мало попит.

Відкриті питання для обговорення

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

Sensor fusion для BVLOS: як ефективно поєднувати дані з оптичних камер, RF-детекторів та акустичних сенсорів для tracking за межами прямої видимості? Які архітектурні патерни краще працюють для реального часу?

Adaptive confidence thresholds: як автоматично адаптувати поріг впевненості детекції залежно від context (час доби, щільність об’єктів, історія false positives на конкретній локації)? Чи варто використовувати reinforcement learning для цього?

Multi-site track correlation: при розгортанні на кількох географічно розподілених точках — як визначити, що track_A з Site_1 та track_B з Site_2 це один і той самий об’єкт? Які метрики схожості треків працюють найкраще в реальних умовах?

Dataset drift detection: як автоматично виявляти, що модель починає гірше працювати через зміну умов експлуатації (нова камера, нова місцевість, сезонні зміни)? Які метрики використовувати для мониторингу деградації?

Якщо у вас є досвід вирішення схожих задач — буду радий обговорити підходи та обмінятися досвідом.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.