Лови FPV на Go: будуємо real-time детектор дронів на Raspberry Pi і Hailo

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

Привіт! Мене звати Роман Журавель, і я б хотів розповісти про свій експеримент з Golang та Computer Vision.

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

Моя мета — показати весь шлях від розмітки картинок до готового детектора на платі, і наочно пояснити, чому «мозком» цієї системи я обрав Go, а не звичні Python чи C++.

Що отримаємо в результаті

До кінця статті ми пройдемо повний цикл розробки:

• Зберемо базу: розмітимо датасет FPV-дронів у Label Studio й натренуємо модель YOLOv8n.
• Підготуємо залізо: скомпілюємо модель під Hailo-8L — компактний нейропроцесор на 13 TOPS, що підключається до Raspberry Pi 5.
• Напишемо софт: розберемо Go-застосунок, який через CGO-біндінг забирає кадри з камери, «годує» ними залізо.
• Розберемо фішки: по поличках розкладемо, чому скомпільований Go-бінарник на платі — це круто. Поговоримо про деплой без болю з Python-залежностями, залізне керування потоками (камера → інференс → мережа) та банальний захист коду від копіювання, адже бінарник реверсити куди складніше, ніж читати голий скрипт.

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

Конвеєр працює в чотири кроки: камера бере кадр → Hailo-8L проганяє його через нейромережу й повертає сирі дані → Go-застосунок збирає їх у bounding box-и й ідентифікує дрон → летить сповіщення по HTTP чи радіо. Жодних хмар і серверів — усе крутиться на одному шматку заліза.

Головна фішка тут — правильний розподіл ролей. Hailo-8L забирає на себе всю важку математику (а це 13 TOPS апаратного інференсу), повністю розвантажуючи процесор PI. Тобто ядра Raspberry Pi 5 взагалі не множать матриці — вони лише керують процесом: забрали кадр із камери, кинули в Hailo через PCIe, забрали результат і відправили в мережу.

А це якраз та робота, під яку заточували Go: швидкий конкурентний I/O та мережа, а не лінійна алгебра. Важка обчислювальна частина вже «в залізі», а Go дістається саме той шар, де він почувається як риба у воді.

Залізо:

Тепер, коли картина зрозуміла, можна розібратись, чому саме Go дістав роль «мозку» цього конвеєра.

Чому Go?

Логічна відповідь на питання «чим пишуть ML-інференс на edge» — Python або C++. Python — бо навколо нього весь ML-інструментарій: PyTorch, ONNX Runtime, ultralytics, pyhailo. C++ — бо HailoRT має нативний C++ API і максимальний контроль над пам’яттю. Go тут виглядає незвичайним гостем. Але є кілька причин, через які він виявився зручнішим.

Один бінарник — повний деплой. Go компілюється в єдиний статично прилінкований виконуваний файл. Щоб розгорнути застосунок на Pi, достатньо скопіювати один файл і запустити його. Не потрібно ні venv, ні pip install, ні боротьби з версіями numpy — а ця боротьба в Hailo-екосистемі цілком реальна: версії 1.x і 2.x numpy несумісні між собою, і частина пайплайнів на Python просто ламається після apt upgrade. З Go такої проблеми немає.

Конкурентність без callback-хаоса. Пайплайн «читати кадри → гнати інференс → слати HTTP-запит або писати радіоканал» — це кілька незалежних потоків роботи, які мають бути паралельними, але при цьому координованими. У Go це реалізується через goroutines і channels: кожна ланка конвеєра — окрема goroutine, дані між ними течуть через канали. Логіка залишається лінійною і читабельною, без callback-пірамід і async/await.

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

Низький overhead на ARM. Go runtime невеликий і стартує швидко. На Pi 5 застосунок виходить на робочий режим за секунди — без прогріву JVM і без завантаження важких Python-пакетів при старті.

Є нюанс: CGO. Єдиний компроміс — взаємодія з HailoRT C API відбувається через CGO. Це означає, що магія «один бінарник без зовнішніх залежностей» трохи ускладнюється: на хості при збірці потрібен C-компілятор і заголовні файли HailoRT, а фінальний бінарник динамічно прив’язаний до libhailort.so. Тобто на цільовому Pi ця бібліотека має бути встановлена. Але це одна системна залежність — і вона все одно потрібна для роботи HAT, незалежно від мови застосунку.

Розмітка датасету в Label Studio

Перш ніж запускати будь-яке тренування, потрібен датасет — бажано 1500–2000 зображень FPV-дронів у різних умовах: різна відстань, різне освітлення, різний фон. Частина зображень має бути взагалі без дронів — негативні приклади, яких модель навчиться не плутати з ціллю. Орієнтовна пропорція: ~15—20% від загальної вибірки.

Правила розмітки

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

• Bounding box — якомога щільніше навколо дрона, мінімум порожнього простору
• Розмічаємо всі дрони на кожному кадрі, навіть частково захований дрон
• Розмиті та ледь помітні — теж розмічаємо
• Зображення без дронів не чіпаємо — вони так і залишаються негативними прикладами

Після розмітки: Export → YOLO. Архів матиме папки images/ і labels/, де кожен .txt — це рядок у форматі:

<class_id> <x_center> <y_center> <width> <height>

Увага: Label Studio іноді експортує полігони замість bbox (9 значень замість 5 на рядок). Якщо це трапилось — конвертуємо скриптом, який зводить polygon до YOLO-формату через min/max координат. Перевірити формат просто: якщо у .txt-файлі 5 чисел на рядок — все гаразд, якщо 9 — потрібна конвертація.

Останній крок підготовки — розбити датасет на три частини: 80% train, 15% val, 5% test — і покласти їх у структуру, яку очікує YOLOv8. Можете скористатись скриптом.

dataset.yaml:

path: <path_to/drone_dataset>
train: images/train
val: images/val
test: images/test
nc: 1
names:
  0: fpv_drone

path замініть на абсолютний шлях

Тренування YOLOv8n і компіляція для Hailo

Для тренування використовуємо yolov8n — найлегшу версію архітектури, яка без проблем вкладається в 13 TOPS Hailo-8L і дає достатню точність для детекції одного класу. Можна тренувати модель локально або на Google Colab

from ultralytics import YOLO
model = YOLO("yolov8n.pt")
model.train(
    data="drone_dataset/dataset.yaml",
    epochs=120,
    imgsz=512,
    batch=8,
    device="cpu",
    optimizer="AdamW",
    lr0=0.001,
    patience=30,
    augment=True,
    mosaic=1.0,
    mixup=0.1,
    fliplr=0.5,
    hsv_h=0.015, 
    hsv_s=0.7, 
    hsv_v=0.4,
    project="runs/detect",
    name="fpv_drone",
)

Експорт в ONNX

model = YOLO("runs/detect/fpv_drone/weights/best.pt")
model.export(
    format="onnx",
    imgsz=512,
    opset=11,        # Hailo DFC opset 11
    simplify=True, 
)

opset=11 і simplify=True — не опціональні. Без спрощення Hailo Dataflow Compiler часто не може розпарсити граф і падає на операціях, які ONNX-runtime обробляє без проблем, але DFC — ні.

Компіляція ONNX → HEF

Hailo використовує власний бінарний формат .hef (Hailo Executable Format). Компіляція відбувається через Hailo AI SW Suite — Docker-образ, який треба завантажити з developer zone після реєстрації.

Попередньо створіть папку hailo_workspace та скопіюйте ваш best.onnx. Також свторіть папку hailo_workspace/calib_images та помістіть в неї ~100—200 зображень з валідаційної вибірки для INT8-квантизації. Hailo стискає вагові коефіцієнти з float32 до int8, і калібрувальні зображення дозволяють зробити це з мінімальною втратою точності.

Важливий нюанс зі скриптом .alls. Стандартний скрипт з Model Zoo намагається додати NMS прямо на чіп — і для кастомних моделей це ламається з помилкою expected conv but found activation layer. Тому замість стандартного — мінімальний скрипт тільки з нормалізацією:

cat > /workspace/yolov8n_drone.alls << 'EOF'
normalization1 = normalization([0.0, 0.0, 0.0], [255.0, 255.0, 255.0])
EOF

NMS у такому разі виконується на CPU в Go-застосунку — і це насправді зручніше: повний контроль над порогами confidence і IoU без перекомпіляції HEF.

Запускаємо контейнер, монтуємо робочу папку

docker run -it --rm \
    -v $(pwd)/hailo_workspace:/workspace \
    hailo8_ai_sw_suite_2025-10:1

Усередині контейнера — компіляція через hailomz compile:

hailomz compile \
    --ckpt /workspace/best.onnx \
    --hw-arch hailo8l \
    --calib-path /workspace/calib_images \
    --yaml /local/workspace/hailo_model_zoo/hailo_model_zoo/cfg/networks/yolov8n.yaml \
    --classes 1 \
    --model-script /workspace/yolov8n_drone.alls

Маємо yolov8n.hef — тепер потрібна плата, яка його запустить.

Підготовка Raspberry Pi 5

Raspberry Pi Imager → Raspberry Pi OS (64-bit, Bookworm). Обов’язково 64-bit: Hailo драйвер не збирається під 32-бітне ядро. У налаштуваннях одразу вмикаємо SSH і прописуємо WiFi.

ssh @<ip-адреса>
sudo apt update && sudo apt full-upgrade -y
sudo rpi-eeprom-update -a
sudo reboot</ip-адреса>

Фізичне підключення HAT+

Pi 5 повинен бути повністю вимкнений. Два критичних місця:

FPC-кабель — тонкий плаский кабель між Pi і HAT+ іде через PCIe роз’єм. Обидва кінці мають вставлятись до клацання, коричневі фіксатори — защіпнуті. Це найчастіша причина lspci не бачить Hailo взагалі.

Живлення — блок на 5V/5A (27W) є обов’язковим. Зі звичайним 15W-зарядником Hailo просто не ініціалізується: HAT+ потребує пікового струму під час завантаження прошивки.

PCIe Gen3

За замовчуванням Pi 5 спілкується з HAT по PCIe Gen2. Gen3 вмикається одним рядком у /boot/firmware/config.txt:

sudo raspi-config

6 Advanced Options

A9 PCIe Speed

Yes (Gen 3)

Далі потрібно перезавантажити PI та перевірити чи з’єднання і конфігурація працює:

lspci

Встановлення Hailo

sudo apt install hailo-all -y
sudo reboot

Перевіряємо:

hailortcli fw-control identify

Типова граблі: HAILO_DRIVER_NOT_INSTALLED після оновлення ядра

hailo-all встановлює DKMS-модуль — він автоматично перебирається під нове ядро під час apt upgrade. На практиці це іноді не спрацьовує: ядро оновилось, а модуль залишився зібраним під стару версію. Симптом — hailortcli повертає HAILO_DRIVER_NOT_INSTALLED одразу після системного оновлення.

Діагностика:

uname -r                        # поточне ядро
sudo dkms status | grep hailo   # для яких ядер є зібраний модуль
lsmod | grep hailo              # чи завантажений зараз

Якщо версії не збігаються — збираємо вручну:

sudo apt install linux-headers-$(uname -r) -y
sudo dkms build hailo_pci/4.20.0 -k $(uname -r) --force
sudo dkms install hailo_pci/4.20.0 -k $(uname -r) --force
sudo modprobe hailo_pci

Щоб завантажувалось автоматично після кожного ребуту:

echo "hailo_pci" | sudo tee /etc/modules-load.d/hailo.conf

Перевіряємо камеру

rpicam-hello --list-cameras

Бенчмарк HEF прямо на платі

Для початку копіюємо файл .hef на PI

scp yolov8n_drone.hef [email protected]:/home/roman/

Запускаєм бенчмарк

hailortcli benchmark ~/yolov8n_drone.hef

Go + Hailo: як влаштований go-hailort

HailoRT має офіційний C/C++ API і Python-обгортку. Go там немає. Щоб з’єднати Go-застосунок із нейропроцесором, довелось написати go-hailort — CGO-біндинг, який транслює Go-виклики в C API HailoRT.

Структура CGO-шару

CGO дозволяє Go-коду безпосередньо викликати C-функції — достатньо оголосити їх у спеціальному блоці коментаря над import «C»:

/*
#cgo CFLAGS:  -I/usr/include/hailo
#cgo LDFLAGS: -lhailort
#include <hailo/hailort.h>
#include <stdlib.h>
#include <string.h>
// hailo_go_true is a helper because Go cannot take the address of a C literal.
static inline _Bool hailo_go_true(void) { return (_Bool)1; }
*/
import "C"

Після цього C.hailo_create_vdevice(...) — звичайний виклик у Go-коді, який під час компіляції перетворюється на виклик до libhailort.so. Уся магія відбувається на етапі go build: CGO генерує C-обгортку, gcc компілює її, лінкер зшиває все разом.

Публічний API go-hailort

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

device, err := hailort.Open("/path/to/yolov8n.hef")
if err != nil {
    log.Fatal(err)
}
defer device.Close()

Open під капотом викликає hailo_create_vdevice → hailo_hef_create → hailo_configure_vdevice → активує network group. Все це синхронно і відбувається один раз при старті.

Архітектура застосунка розпізнавання FPV

Маємо go-hailort, який вміє запускати інференс. Тепер потрібен застосунок, який скріплює всі частини разом: читає кадри з камери, готує їх для моделі, декодує вихід YOLO, вирішує що робити з результатом і надсилає сповіщення. У Go це природно лягає на конвеєр із goroutines і channels.

Структура пакетів

.
├── cmd
│   └── detect
│       └── main.go # точка входу, ініціалізація, запуск
├── internal
│   ├── action
│   │   ├── action.go
│   │   ├── action_test.go
│   │   ├── http.go
│   │   ├── http_test.go
│   │   ├── log.go
│   │   ├── log_test.go
│   │   └── save.go
│   ├── camera
│   │   └── camera.go # читання кадрів з Camera Module 3
│   ├── display
│   │   └── display.go # робота з екраном, якщо є
│   ├── event
│   │   └── event.go # результат детекції в просторі оригінального кадру
│   ├── inference
│   │   └── inference.go # виконує інференс на Hailo-8L
│   ├── overlay
│   │   └── overlay.go # малює анотації детекцій
│   ├── pipeline
│   │   └── pipeline.go # оркеструє головний цикл обробки відео в реальному часі
│   └── yolo
│       └── decode.go # пост-обробка виходів YOLOv8 після Hailo-інференсу

Конвеєр

Весь пайплайн — це три goroutines, з’єднані двома каналами:

frames     := make(chan camera.Frame, 2)
detections := make(chan []postprocess.Detection, 2)
go camera.Capture(ctx, frames)
go inference.Run(ctx, device, frames, detections)
go notify.Dispatch(ctx, notifiers, detections)

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

Ознайомитись з кодом можна в репозиторії на github. Ще раз хочу наголосити, що це експерименти, а не production-ready рішення.

Компілювати варто на PI, щоб в системі вже були всі бібліотеки, до прикладу hailo/hailort.h.

CGO_ENABLED=1 go build -o fpv-detect .

Висновки

Коли я починав цей проект, головне питання було не «чи може Raspberry Pi тягнути YOLO» — може, якщо правильно вибрати залізо. Питання було в тому, чи Go справді підходить для цієї ролі, чи це просто цікавий експеримент.

Підходить — і в конкретних місцях краще за очевидні альтернативи. Не тому що «Go крутий», а через прагматичні причини, які відчуваються саме на edge:

Один бінарник — і застосунок на платі. Жодного venv, жодного pip install, жодних конфліктів numpy між пакетами. Скопіював файл, запустив, він працює. Це важливо, коли плата стоїть фізично десь на місці і до неї не завжди є зручний доступ.

Goroutines і channels природно описують конвеєр «читай кадри / женемо інференс / слати сповіщення» — код залишається лінійним і читабельним, не перетворюється на callback-пастку.

CGO-міст виявився менш болючим, ніж здавалось. Так, крос-компіляція з CGO нетривіальна, але збірка нативно на Pi — 30 секунд і нуль проблем. Для edge-пристрою, де деплой рідкий, це прийнятний компроміс.

Скомпільований бінарник складніше реверсувати, ніж Python-скрипт, який лежить відкритим текстом. Для автономного польового пристрою це не параноя, а просте здорового глузду рішення.

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

Код обох бібліотек відкритий:

• go-hailort — CGO-біндинг до HailoRT C API
• go-fpv-detect — застосунок детекції

Що з цим робити?

Якщо ви виконаєте всі інструкції, та запустите застосунок на своєму PI, то на екрані, або в збереженому відео ви зможете побачити щось таке

Схожі девайси можна використовувати в боротьбі з «ждунами». Наприклад розвішувати в сіткових тунелях/дорогах і повідомляти «Біля стовпа 33 зафіксований дрон».

Знаючи розташування FPV на зображенні (кадрі з відео), можна рухати пристроєм (сервоприводи, Pan-Tilt) і протидіяти активно — викидати сітку, робити постріл. Можна робити розумні приціли, для гвинтівок.

Допомагай ЗСУ. Слава Україні!!!

Підписуйтеся на WhatsApp-канал DefTech спільноти!