Рій з 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]) Порівняння підходів до керування роєм
| Характеристика | Централізований | Децентралізований (MARL) | Гібридний |
|---|---|---|---|
| Масштабованість | O(N²) ✗ | O(N) ✓ | O(N log N) |
| Collision avoidance | Потребує повної карти | Локальне ORCA | Safety layer + RL |
| Стійкість до відмов | Єдина точка відмови | Висока (відмова одного не впливає) | Середня |
| Quality of training | Висока (повна інформація) | Середня (часткові спостереження) | Висока |
Порівняння алгоритмів MARL
| Алгоритм | Тип задач | Переваги | Недоліки |
|---|---|---|---|
| QMIX | Кооперативні | Монотонне змішування, гарантія узгодженості | Не підходить для конкурентних сценаріїв |
| MADDPG | Кооперативні/конкурентні | CTDE, проста реалізація | Висока варіативність навчання |
| MAPPO | Кооперативні | Висока ефективність з PPO | Чутливість до гіперпараметрів |
Оцінка та метрики
- Coverage rate: % цільової площі покритої за T хвилин
- Formation error: середньоквадратичне відхилення від цільового формування
- Collision rate: зіткнень на 100 польотних годин
- Communication load: середня кількість повідомлень/сек на дрон
- Resilience: % завдань виконаних при відмові 20% дронів
Reynolds, C. W. (1987). Flocks, herds, and schools: A distributed behavioral model.
Процес розробки та терміни
- Аналіз задачі та підбір алгоритму — визначаємо цілі (покриття, пошук, транспортування), обираємо MARL-алгоритм (QMIX, MADDPG та ін.)
- Симуляція та тренування — будуємо середовище в Gazebo, налаштовуємо reward, запускаємо distributed training на кластері GPU
- Safety layer та тестування — інтегруємо ORCA, перевіряємо відмовостійкість в симуляції
- Sim-to-real перенос — калібруємо модель на реальних даних, проводимо польотні тести на полігоні
- Розгортання та підтримка — налаштовуємо систему керування, документуємо 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+ завершених проектів з керування БПЛА. Для оцінки вашої задачі зв'яжіться з нами — ми підготуємо технічну пропозицію з метриками та термінами.
Отримайте консультацію — розкажіть нам про вашу задачу, і ми запропонуємо оптимальне рішення.