Розробка AI-системи керування роєм дронів Swarm AI

Рій з 50+ дронів, керований централізовано, впирається в обчислювальні обмеження — кожен кадр планування вимагає O(N²) операцій. Ми вирішуємо цю задачу децентралізованими алгоритмами MARL (Multi-Agent Reinforcement Learning). Кожен дрон приймає рішення на основі локальних спостережень та комунікації з сусідами, що забезпечує лінійне масштабування. Розберемо, як ми будуємо такі системи — від симуляції до реальних польотів.

Проблеми при масштабуванні

При N=10 централізований планувальник працює. При N=100 — обчислювально непідйомно. При N=1000 — неможливо. Децентралізований рій масштабується лінійно: кожен дрон обробляє тільки найближчих сусідів (K=5–8).

Надійність зв'язку: алгоритм повинен працювати при packet loss 20–30% та latency 50–200 мс. Ми використовуємо gossip-протокол для поширення інформації та communication-aware RL, де дрон вирішує, коли і кому надсилати повідомлення.

Sim-to-real gap — головна причина відмов. Ми застосовуємо domain randomization: випадкові параметри вітру, маси, тертя в симуляторі, щоб модель узагальнювала на реальні умови.

Як MARL вирішує проблему масштабування?

Базові правила Рейнольдса (Separation, Alignment, Cohesion) дають примітивну поведінку. Поверх них ми накладаємо навчання з підкріпленням для задачі-специфічної поведінки: покриття території, пошук цілей або транспортування вантажу.

Observation на кожен дрон:

obs_per_drone = {
    'own_state': [x, y, z, vx, vy, vz, battery],  # 7 значень
    'neighbors': [[rel_pos, rel_vel] for n in K_nearest_neighbors],  # K×6
    'goal': [dx, dy, dz],       # напрямок до цілі
    'obstacles': lidar_scan      # 16-ray LiDAR
}

Чому децентралізований підхід ефективніший?

MARL-рій демонструє на 40% вищий coverage rate порівняно з рішенням на основі лише Reynolds Flocking. Reward-інжиніринг дозволяє гнучко балансувати між покриттям, уникненням зіткнень та енергоспоживанням.

Centralized Training Decentralized Execution (CTDE):

• Навчання: critic бачить глобальний стан всього рою
• Виконання: кожен дрон використовує тільки локальне спостереження

QMIX (Multi-Agent Value Decomposition):

# QMIX: Q_tot = f(Q_1,...,Q_n, state)
# монотонічне змішування індивідуальних Q-функцій
# гарантує: argmax Q_tot = [argmax Q_i for each i]

class QMIXNet(nn.Module):
    def __init__(self, n_agents, state_dim):
        super().__init__()
        self.hyper_w1 = nn.Linear(state_dim, n_agents * 32)
        self.hyper_w2 = nn.Linear(state_dim, 32)
        self.hyper_b1 = nn.Linear(state_dim, 32)
        self.hyper_b2 = nn.Linear(state_dim, 1)

    def forward(self, q_agents, state):
        w1 = F.elu(self.hyper_w1(state)).view(-1, q_agents.size(1), 32)
        w2 = F.elu(self.hyper_w2(state)).unsqueeze(-1)
        return q_total

Технічна реалізація

Завдання рою

• Покриття території. N дронів рівномірно покривають область S за мінімальний час. Reward пропорційний покритій унікальній площі.
• Пошук та виявлення. Рій шукає цілі (люди в завалах, лісові пожежі). Інформація поширюється через mesh-мережу.
• Транспортування. Кілька дронів несуть вантаж спільно. Задача — синхронізувати тягу без центрального координатора.
• Захист від загроз (Counter-UAV). Частина рою — захисники, що відстежують та перехоплюють adversarial дрони.

Комунікація в рої

Кожен дрон знає тільки про K найближчих сусідів (K=5–8). Gossip-протокол: інформація поширюється хвилями. Дія включає рішення про комунікацію:

action_space = spaces.Dict({
    'motion': spaces.Box(-1, 1, (3,)),   # velocity
    'message': spaces.Box(-1, 1, (8,)),  # broadcast вектор сусідам
})
obs = concat([own_state, neighbor_messages, sensor_readings])

Уникнення зіткнень

Velocity Obstacle (VO) / Reciprocal VO (ORCA): класичний алгоритм, гарантує collision-free при відомих швидкостях всіх дронів. Використовується як safety layer поверх RL.

from rl_swarm.safety import ORCASafetyLayer

safety = ORCASafetyLayer(max_speed=5.0, safety_radius=1.5)
raw_velocity = rl_policy.predict(obs)
safe_velocity = safety.compute_safe_velocity(
    raw_velocity, drone_position, neighbor_positions, neighbor_velocities
)

Симуляція: Gazebo + PX4

# запуск 10 екземплярів PX4 + один Gazebo
./Tools/simulation/gazebo-classic/sitl_multiple_run.sh -n 10 -m iris
# кожен дрон на окремому MAVLink порту: 14540+i

import asyncio
from mavsdk import System

async def control_swarm(n_drones):
    drones = [System() for _ in range(n_drones)]
    await asyncio.gather(*[
        drone.connect(f"udp://:1454{i}") for i, drone in enumerate(drones)
    ])
    await asyncio.gather(*[drone.action.takeoff() for drone in drones])

Порівняння підходів до керування роєм

Оцінка та метрики

• Coverage rate: % цільової площі покритої за T хвилин
• Formation error: середньоквадратичне відхилення від цільового формування
• Collision rate: зіткнень на 100 польотних годин
• Communication load: середня кількість повідомлень/сек на дрон
• Resilience: % завдань виконаних при відмові 20% дронів

Reynolds, C. W. (1987). Flocks, herds, and schools: A distributed behavioral model.

Процес розробки та терміни

1. Аналіз задачі та підбір алгоритму — визначаємо цілі (покриття, пошук, транспортування), обираємо MARL-алгоритм (QMIX, MADDPG та ін.)
2. Симуляція та тренування — будуємо середовище в Gazebo, налаштовуємо reward, запускаємо distributed training на кластері GPU
3. Safety layer та тестування — інтегруємо ORCA, перевіряємо відмовостійкість в симуляції
4. Sim-to-real перенос — калібруємо модель на реальних даних, проводимо польотні тести на полігоні
5. Розгортання та підтримка — налаштовуємо систему керування, документуємо API, передаємо замовнику

Терміни орієнтовно: прототип на 5–10 дронів в симуляції — від 12 тижнів. Повноцінна MARL-система з safety, sim-to-real та реальними польотами на 20+ дронах — від 28 до 36 тижнів. Вартість розраховується індивідуально залежно від складності завдань та необхідного стеку.

Що входить в роботу

• Архітектура MARL (QMIX / MADDPG) з CTDE
• Симулятор Gazebo + PX4 з domain randomization
• Safety layer на базі ORCA
• Інтеграція з реальними дронами (PX4, MAVLink)
• Документація з навчання та експлуатації
• Навчання команди замовника
• Підтримка 3 місяці після впровадження

У нас 5+ років досвіду в ML для робототехніки та 15+ завершених проектів з керування БПЛА. Для оцінки вашої задачі зв'яжіться з нами — ми підготуємо технічну пропозицію з метриками та термінами.

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

Навчання з підкріпленням: PPO, SAC, DQN та промислове застосування

Ми щодня бачимо проєкти, які гинуть не через слабкий алгоритм, а через неправильну винагороду. Інженер пише reward = +1 за правильну дію, запускає навчання, а через 10 млн кроків агент знаходить спосіб отримати максимум, не вирішивши завдання. Це reward hacking — системний біль промислового RL. Наш досвід показує: правильний reward займає 70% успіху.

Чому RL складніше, ніж supervised learning?

У supervised learning є датасет з правильними відповідями. У RL правильної відповіді немає — є скалярний сигнал «краще/гірше», який надходить із затримкою в сотні кроків. Агент сам досліджує простір і знаходить стратегію.

Наслідки: нестабільність навчання, висока чутливість до гіперпараметрів, повільна збіжність. PPO (Proximal Policy Optimization) на Atari сходиться за 10 млн кроків — це години. На роботизованих завданнях з реальною фізикою — дні або тижні в симуляторі.

Чому reward engineering вирішальний для RL?

Без якісної reward-функції навчання перетворюється на лотерею. Reward hacking — класична пастка: агент знаходить неочевидний спосіб максимізувати винагороду, ігноруючи справжню ціль. Один із проєктів — сортування компонентів на PCB — demand: ми витратили 2 тижні на формалізацію reward: штраф за зіткнення, бонус за швидкість, penalty за неправильне розташування. Без цього агент навчився скидати деталі з конвеєра, отримуючи +1 за кожну скинуту, а не за відсортовану.

Як обрати алгоритм під задачу?

Як налаштувати PPO та уникнути типових проблем?

PPO — робоча конячка RL. Основна ідея: обмежуємо оновлення політики через кліпування ratio clip_range=0.2. Це дає стабільність порівняно з vanilla policy gradient. Але без грамотного налаштування агент не сходиться.

Одна з частих пасток — entropy collapse: агент занадто швидко стає детермінованим, перестає досліджувати. Симптом — entropy coefficient падає до нуля. Лікування — ent_coef=0.01–0.05 і не знижувати нижче 0.001. Інша проблема — value function розходиться, коли vf_loss_coef високий, а explained_variance від'ємний. Рекомендуємо vf_coef=0.5 і gradient clipping max_grad_norm=0.5.

Неправильний n_steps також ламає навчання. n_steps=2048 — дефолт Stable‑Baselines3. Для завдань з довгим горизонтом (>500 кроків) потрібно збільшувати, для швидких (10–50 кроків) — зменшувати до 256–512.

Для швидкого старту використовуємо stable‑baselines3 + sb3‑contrib. Для research і кастомних алгоритмів — tianshou або CleanRL.

SAC для безперервного керування

SAC (Soft Actor‑Critic) додає в objective максимізацію ентропії — агент вчиться бути і ефективним, і різноманітним. Це дає відмінну sample efficiency та стійкість до шуму в reward. На задачах керування техпроцесами SAC зазвичай обходить PPO за збіжністю: потребує на 30–40% менше взаємодій для досягнення тієї ж якості. Ключовий параметр — target_entropy. Стандартне значення ‑dim(action_space) часто підходить, але для специфічних завдань краще налаштовувати вручну.

Як перенести навченого агента на реальний пристрій?

Навчати RL на реальному роботі — дорого та небезпечно. Стандартний підхід: навчання в симуляторі → трансфер на реальне залізо. Основна проблема — reality gap: симулятор не відтворює фізику, тертя, шум датчиків.

Головний інструмент — domain randomization. Під час навчання випадково варіюємо параметри середовища: маса об'єктів ±30%, коефіцієнт тертя ±50%, затримка дій 0–100 мс, шум спостережень σ=0.01–0.1. Агент навчається бути робастним до варіацій, і реальний світ стає лише ще однією варіацією.

Порівняння популярних симуляторів:

RLHF: навчання LLM з людського зворотного зв'язку

RLHF став стандартом після InstructGPT. Класична схема: supervised fine‑tuning → reward model → PPO.

Проблеми класичного PPO: нестабільність (KL‑дивергенція може вибухнути), повільна збіжність, складність налаштування. Тому популярні альтернативи:

• DPO — обходить reward model, вчиться на парах уподобань. Простіше, стабільніше, але менш гнучкий.
• GRPO — використовується в DeepSeek‑R1, хороший для reasoning tasks.
• ORPO — об'єднує SFT та alignment в одну стадію.

Бібліотека trl від Hugging Face — стандарт. Підтримує PPO, DPO, ORPO, GRPO з коробки, працює з PEFT/LoRA для memory‑efficient fine‑tuning.

Reward hacking залишається однією з головних причин провалів у RL, поряд з неправильно обраною архітектурою середовища. Це підтверджують дослідження з відкритих джерел (Reward hacking in reinforcement learning, Wikipedia).

Що входить в роботу

• Архітектурне рішення та обґрунтування вибору алгоритму
• Розробка та документування reward‑функції
• Створення симулятора або налаштування існуючого
• Навчання, hyper‑parameter sweep (Optuna / Ray Tune)
• Трансфер на реальне залізо або інтеграція в продукт
• Документація, доступи до коду та симуляторів
• Навчання команди та 3‑місячна підтримка після деплою

Процес роботи

1. Аудит завдання — фіксуємо цілі, ресурси, обмеження.
2. Reward engineering — формалізація бажаної поведінки, перевірка на reward hacking.
3. Вибір середовища та алгоритму — baseline, перші прогони.
4. Систематичний hyperparameter sweep — використовуємо Optuna.
5. Навчання в симуляторі з domain randomization.
6. Тестування на реальному обладнанні (за потреби).
7. Деплой, моніторинг, підтримка.

Терміни: proof of concept — 2–4 тижні; production‑система з sim‑to‑real — 3–8 місяців; RLHF для LLM — 4–10 тижнів. Вартість розраховується індивідуально — оцінимо ваш проєкт за 2 дні. Замовте консультацію, щоб уникнути типових пасток RL.

Наша команда — понад п’ять років досвіду в RL, 30+ успішних проєктів у роботиці, оптимізації ланцюгів постачання та LLM alignment. Гарантуємо прозору архітектуру та повну технічну документацію. Зв'яжіться з нами для отримання детальної оцінки вашого проєкту.