Авторы проектов: Ethan (@ethochal5) — коммуникации роевых БПЛА; Izzy Barr — управление роем и доработка веб-панели телеметрии.
Университет: Durham University (выпускные диссертационные проекты, MEng).
Научный руководитель: Dr Oliver Vogt.
Дата публикации исходного поста:
Ниже — подробный разбор и «приземлённое» описание того, что именно сделали авторы, зачем это нужно, как это складывается в единую систему, и как повторить подход у себя (в симуляции SITL и на недорогом железе).
Источник: ArduPilot Discuss — “Low-Cost Drone Swarm Communication and Management Projects”
О чём эти проекты и почему они важны
Роевые системы часто «упираются» не в автопилот как таковой, а в две практические проблемы: (1) как организовать надёжный обмен данными между несколькими бортами в реальном времени и (2) как оператору/разработчику одновременно наблюдать несколько аппаратов и не утонуть в телеметрии.
Ethan и Izzy разделили задачу ровно по этой границе: один проект отвечает за коммуникационную основу (обмен данными и координация), второй — за управляемость и наблюдаемость (мульти‑аппаратная панель телеметрии и удобства оператора).
Проект 1. Swarm Communication (Ethan): связь и обмен данными между двумя дронами
Цель
Цель проекта — собрать воспроизводимую, недорогую и open-source систему коммуникации для роя, которую можно одинаково применять в:
- симуляциях SITL (Software In The Loop),
- и на реальном низкобюджетном оборудовании (в духе “companion computer” уровня Raspberry Pi и т.п.).
Что именно делает система
По описанию авторов, система обеспечивает двум аппаратам:
- обмен данными в реальном времени по сети Wi‑Fi,
- использование «разделяемых» данных для координации движений,
- и тем самым создаёт основу для более сложных роевых сценариев (formation, следование, распределение ролей и т.д.).
Как это обычно выглядит в архитектуре ArduPilot (понятная “картинка”)
Хотя исходный пост не углубляется в сетевые параметры и протоколы обмена, логика стека обычно такая:
- ArduPilot на каждом борту публикует телеметрию и принимает команды через MAVLink (серийно/UDP/TCP — зависит от стенда).
- Скрипты на Python получают телеметрию (через MAVLink‑библиотеки/мосты) и формируют данные для “swarm‑логики”.
- Дроны (или их companion‑компьютеры) обмениваются «роевыми» сообщениями по Wi‑Fi (общая сеть/точка доступа).
- Далее либо:
- каждый борт принимает решения локально (децентрализованно), либо
- решения принимает наземный/центральный узел (централизованно), а борта исполняют.
Важная практическая деталь: такие проекты почти всегда начинают с двух аппаратов. Это минимальный масштаб, на котором уже появляются ключевые “роевые” эффекты (рассинхронизация, конфликт команд, различия задержек, потеря пакетов), но при этом систему ещё реально отлаживать.
Проект 2. Swarm Management (Izzy): мульти‑аппаратное управление и телеметрия
Исследовательская часть: сравнение инструментов управления
Izzy начала с изучения того, как симуляции и многомашинные сценарии чувствуют себя в популярных GCS/инструментах: Mission Planner, MAVProxy и QGroundControl (QGC). Цель — понять, что «есть из коробки» и где именно можно расширить функциональность для нескольких аппаратов.
В документации ArduPilot отдельно отмечается, что Mission Planner поддерживает ограниченное «swarming» / полёт строем (formation flying) для нескольких UAV. Это полезная точка опоры для тех, кто хочет начинать с готовых функций, а не писать всё с нуля.
-->Практическая часть: расширение ArduPilot WebTools Telemetry Dashboard под несколько бортов
Ключевой результат проекта управления — доработка ArduPilot WebTools → TelemetryDashboard (веб‑панель телеметрии), чтобы она стала удобной именно для нескольких аппаратов, сохранив при этом базовую философию инструмента: гибкость и кастомизацию.
Важно понимать назначение TelemetryDashboard: в официальном README он описан как инструмент только для отображения входящей MAVLink‑телеметрии; это не GCS, и он предполагается как дополнение к полноценной наземной станции. Упор — на гибкость и пользовательскую настройку.
-->По описанию Izzy, были реализованы/добавлены:
- класс “vehicle” (структурирование данных по каждому аппарату),
- всплывающее окно (popup) с информацией об аппарате,
- цветовая система (чтобы визуально различать борта),
- выбор “primary vehicle” (основного аппарата) — удобно, когда нужно быстро переключать фокус,
- и всё это — без потери «врождённой» кастомизируемости TelemetryDashboard.
Почему это реально полезно на практике
Как только у вас не один дрон, а два и более, операторская «боль» обычно такая:
- вы перестаёте понимать, какой маркер/график относится к какому борту;
- становится сложно быстро увидеть отличия по батарее, GPS, режимам полёта;
- растёт риск ошибочно отправить команду не тому аппарату.
Что получилось в итоге: SITL + реальный мир
Авторы сообщают, что оба проекта используют стандартную конфигурацию ArduPilot и оказались успешными:
- в SITL (для повторяемой отладки и быстрых экспериментов),
- и в реальной среде с двумя настоящими дронами (как минимально жизнеспособный «рой»).
Как повторить подход (в общих чертах)
Ниже — «скелет» воспроизведения, который обычно совпадает с тем, как такие стенды строятся в экосистеме ArduPilot:
- Симуляция: развернуть SITL для нескольких аппаратов, чтобы отладить коммуникации и логику без риска. Документация ArduPilot по SITL — хорошая стартовая точка, а также там упоминаются материалы по управлению несколькими аппаратами через MAVProxy. Документация: Using SITL
- GCS/прокси: выбрать наземный инструмент (Mission Planner / QGC) и при необходимости использовать MAVProxy как «клей» между несколькими потоками телеметрии/каналами связи. MAVProxy исторически развивался как инструмент для companion computing и нескольких datalink’ов. Документация: MAVProxy
- Сеть Wi‑Fi: поднять общую Wi‑Fi сеть (точка доступа/роутер) для узлов роя, чтобы дроны могли обмениваться сообщениями.
- Скрипты: запустить Python‑скрипты роевой коммуникации/координации (логика — поверх стандартной MAVLink‑телеметрии).
- Визуализация: параллельно открыть TelemetryDashboard, чтобы видеть телеметрию по нескольким бортам на одном экране (особенно полезно при отладке расхождений и задержек).
Внешние ссылки (репозитории и документация)
1) ArduPilot WebTools и TelemetryDashboard (база, которую расширяли в проекте управления)
- GitHub: ArduPilot/WebTools — набор веб‑инструментов ArduPilot; репозиторий можно поднять локально через простой python http.server.
2) Документация по swarming/строю и базовые материалы
-->3) Репозитории авторов проектов (Ethan / Izzy)
В исходном посте на ArduPilot Discuss указаны отдельные репозитории: “Low Cost Drone Swarm Communication” и “Low Cost Drone Swarm Management”. В предоставленном фрагменте текста ссылки присутствуют только как названия, без URL, а автоматический доступ к странице форума временно ограничен (ошибка 429 “Too Many Requests”), поэтому здесь я не могу корректно вставить точные адреса репозиториев без риска ошибиться.
Чтобы статья на вашем сайте всё равно содержала полезные внешние переходы, ниже добавлены:
- ссылка на исходный пост (где эти два репозитория кликабельны);
- и безопасные ссылки на поиск GitHub по точным названиям репозиториев.
Куда развивать дальше (идеи, которые логично следуют из сделанного)
- От 2 к N аппаратам: добавить масштабирование (идентификация бортов, адресация сообщений, контроль частоты обмена).
- Надёжность связи: сценарии потерь пакетов/разрыва Wi‑Fi и понятные деградации поведения (например, “hold”, “RTL”, “land”).
- Безопасность: минимальная аутентификация/шифрование роевых сообщений (особенно если Wi‑Fi общий/полевой).
- Операторский интерфейс: расширение TelemetryDashboard до “роевых” виджетов (например, расстояния между бортами, предупреждения о сближении, статусы ролей “leader/follower” и т.п.), оставаясь в парадигме “display-only”.