Софт Дронопорта: что происходит, пока оператор пьёт кофе

Дисклеймер. Пишу от своего имени свое непопулярное мнение. Я работаю в индустрии автономных дронопортов, поэтому смотрю на тему изнутри и где-то наверняка пристрастен. В прошлой статье ^[1] я рассказал, что такое дронопорт вообще, и зачем он бизнесу. Теперь хочу поговорить про программную часть. Где увидите перекос — поправьте в комментариях (как обычно).

В прошлый раз я написал фразу, за которую теперь надо отвечать: “дрон сам взлетает, летит, снимает, возвращается, а человек в это время пьёт кофе за 2000 км”. Звучит как магия. На деле за этим “сам” стоит несколько сервисов, пара баз данных, медиасервер, гейтвей на станции и много часов разбора логов с вопросом “а почему он так сделал?”.

Сегодня разберём именно программную часть: как устроена, какие в ней тонкости и где нас било по рукам.

Зачем вообще своё ПО, если есть пульт от дрона

Конкретный вопрос, который мне задают постоянно. Дрон и так летает по миссиям из родного приложения производителя, зачем городить свою платформу?

Потому что родное приложение рассчитано на человека с пультом в руках, стоящего рядом с дроном. А у нас человека рядом нет. Совсем. Станция стоит на карьере на Сахалине, оператор сидит в Москве, и между ними — только канал связи. Всё, что обычно делает пилот глазами и пальцами, должен делать софт: проверить погоду, открыть крышку, запустить миссию, следить за полётом, посадить, зарядить, выгрузить данные, закрыть крышку. И не один раз, а по расписанию, каждый день, без выходных.

Плюс промышленному заказчику нужны вещи, о которых бытовое приложение даже не слышало: ролевая модель для филиалов и дочерних обществ, on-premise установка в закрытом контуре, интеграция с его ERP и передача сведений о полётах в ОРВД. Об этом ниже.

Как это устроено (чуть-чуть архитектуры)

Если разобрать платформу на крупные блоки, получается три уровня.

На станции живёт гейтвей — обычный промышленный компьютер под Linux, весь софт в контейнерах. Он общается с “железом” станции через ПЛК: открыть створки, зажать дрон, включить зарядку, снять показания метеодатчиков. Он же гонит видео с камер станции, чтобы оператор видел, что происходит внутри и снаружи бокса.

Рядом с дроном — пульт. Да, тот самый штатный пульт, только он лежит внутри станции, а вместо пальцев пилота на нём работает наше приложение поверх мобильного SDK производителя. Иногда вместо пульта мы используем на некоторых моделях дрона модем. Это важная тонкость: мы не “взламываем” дрон и не пишем свою прошивку, мы программно делаем то же самое, что делал бы пилот. Все штатные защиты дрона остаются на месте.

На сервере — два сервиса. Хаб — “диспетчер”, который держит связь со всеми станциями и дронами, принимает телеметрию, раздаёт команды и складывает всё в базу. И портал — то, что видит пользователь: дашборды, планировщик миссий, архив медиа. Между ними медиасервер, который принимает видеопотоки с дронов и станций и раздаёт их в браузер. Разворачивается всё это хоть в облаке, хоть на серверах заказчика в закрытом контуре. Для многих промышленных объектов это не пожелание, а условие входа на площадку.

Ничего космического, скажет бэкендер, и будет прав. Космос начинается в деталях.

Тонкость №1 . Видео с задержкой в секунду — это сложно

Казалось бы: ну видеопоток, ну RTMP, что тут такого. А теперь вводная: оператор в Москве может в любой момент перехватить управление дроном, который летит над карьером за пять тысяч километров. Джойстики прямо в браузере.

Если задержка видео — 10–15 секунд, как у классического HLS, перехват управления превращается в игру “посади дрон по памяти”. Ты жмёшь стик, а картинка показывает то, что было четверть минуты назад. Поэтому для диспетчерской мы отдаём поток через WebRTC с задержкой меньше секунды, а “тяжёлый” HLS оставляем там, где важна не скорость, а стабильность — например, для трансляции в ситуационный центр на большой экран.

Обратная сторона: канал связи на промышленных объектах — это отдельный жанр. Где-то оптика, где-то LTE-модем с одной палкой, где-то спутник. Софт должен переживать всё: рвать качество потока, но не рвать телеметрию — она важнее картинки.

Тонкость № 2. Что делает дрон, когда связь всё-таки пропала

Самый частый вопрос от служб безопасности заказчика: “А если связь оборвётся — он что, упадёт?”

Нет. Логика ^[2] такая: миссия целиком загружается в дрон ещё до взлёта, поэтому для полёта по маршруту постоянная связь ему не нужна, он продолжает работать автономно. Если связь пропала, дрон сначала пытается её восстановить. Не получилось — включается сценарий возврата домой: борт сам возвращается к станции и садится. Оператор при этом видит по последней телеметрии, что происходило, и может попытаться перехватить управление вручную, как только канал появится.

Забавный побочный эффект: пользователи поначалу нервничают, когда видят в логах “потеря связи”. Потом привыкают и перестают замечать — потому что миссии всё равно выполняются, а данные всё равно приходят. Это, наверное, лучший комплимент автономности: когда на аварийный сценарий никто не обращает внимания ^[3].

Тонкость № 3. Сплиттер, или почему “разбить миссию на части” — это не про арифметику

В прошлой статье я вскользь упомянул: если миссия не влезает в один вылет, софт сам разобьёт её на подмиссии. Звучит просто , поделил маршрут на куски по ёмкости батареи, и готово. На практике простое деление не работает.

Смотрите, что реально учитывает сплиттер, когда режет большую площадную съёмку:

— текущее состояние конкретного дрона и его батареи, а не паспортные цифры из брошюры;

— ветер: против ветра борт жрёт заряд заметно быстрее, и кусок, который “влезал” вчера, сегодня может не влезть;

— запас на возврат: дрону нужно не просто долететь до конца галса, а вернуться на станцию с резервом;

— и главное — перекрытие снимков. Ортофотоплан склеивается из сотен кадров с поперечным и продольным перекрытием, и если следующая подмиссия начнётся “примерно там, где закончилась предыдущая”, на сшивке вылезет шов. Поэтому продолжение начинается ровно с того места, где остановились, с сохранением геометрии галсов.

Итог для пользователя выглядит буднично: растянул на карте полигон в пару квадратных километров, нажал кнопку — система сама посчитала галсы, поделила работу на несколько вылетов с зарядками между ними и в конце отдала цельный ортофотоплан без швов. Всю эту кухню пользователь не видит. И это правильно: хорошая автоматизация — та, о которой не думаешь.

Тонкость № 4. Платформа — не остров

Первое время мы думали, что пользователю нужен наш красивый интерфейс. Оказалось многим крупным компаниям нужен его собственный интерфейс, в котором он работает уже десять лет, а от нас нужны данные.

Поэтому вокруг платформы постепенно вырос слой интеграций:

— ОРВД и «Небосвод» — сведения о полётах уходят автоматически. Для тех, кто не в теме: полёты БВС в России надо согласовывать, и делать это руками на каждый ежедневный вылет — отдельная работа, которую никто не хочет делать.

— ГИС заказчика — снимки и ортофотопланы с геопривязкой забираются по API или простой выгрузкой на FTP сервер и ложатся в привычные заказчику карты.

— Отраслевой софт — например, “Лесохранитель” для мониторинга возгораний или Metashape для фотограмметрии: мы отдаём сырьё в том виде, в котором его ждут эти системы.

— ERP и MES — сюда уходят события и факты выполнения миссий, чтобы облёты жили в общем производственном контуре, а не в отдельной программке для дронов.

Вывод, который дался не бесплатно: в промышленности выигрывает не тот софт, который красивее, а тот, который лучше встраивается, более функциональный, надежный.

Тонкость № 5. Нейросети — да, но без фанатизма

В прошлой статье я честно писал, что идеальной ИИ-аналитики не видел. Позиция не изменилась, но рабочие сценарии есть, и они скучнее, чем в презентациях про искусственный интеллект ^[4], зато работают.

Распознавание в реальном времени прямо на видеопотоке: дым и огонь на лесных массивах, техника и люди на площадке, каски и жилеты на стройке. Сработал триггер — уведомление улетает в ситуационный центр, в мессенджер или на почту, с кадром и точкой на карте.

Главная честность здесь такая: нейросеть не принимает решений. Она подсвечивает “посмотри здесь”, а смотрит и решает всё равно человек. Зато человек теперь не пялится в четыре монитора восемь часов подряд. Ровно та рутина, которую и надо было снять.

Тонкость № 6. Защита от человека

Парадокс ^[5] автономной системы: чем меньше в ней участвует человек, тем опаснее каждое его участие. Оператор, который раз в месяц берёт ручное управление, ошибается чаще, чем пилот, летающий каждый день.

Поэтому в платформе многоуровневая система проверок и подсказок. Нельзя запустить миссию, если станция сообщает про ветер выше лимита. Нельзя открыть створки, пока дрон не зафиксирован. Планировщик выстраивает маршрут оптимально затрачиваемому времени и особенностям площадки. Если оператору всё-таки нужно вмешаться, интерфейс ведёт его за руку: перейти в ручной режим, подготовить к посадке, экстренная остановка.

Один диспетчер в таком режиме спокойно ведёт до десяти бортов одновременно. Не потому что так минимально выгодно, а потому что 95% времени система не требует от него вообще ничего.

И небольшая честная оговорка

Чтобы вы не подумали, что я продаю волшебную таблетку — традиционная ложка дёгтя.

ПО дронопорта живёт в зависимостях, которые мы контролируем не полностью. Самая большая — SDK производителя дрона. К сожалению, не все методы в нём открыты, и некоторые моменты нам приходится решать долго и упорно, подбирая костыли. Снаружи это выглядит как “маленькая фича”, внутри как недели реверс-инжиниринга и обходных путей.

Канал связи на объекте — всегда лотерея. Погода вносит правки в любое расписание, и никакой сплиттер не заставит дрон лететь в метель.

А ещё регуляторика, это вообще отдельный пласт, о котором в презентациях обычно молчат: обязательная передача в ОРВД данных о местонахождении дрона, запреты на полёты, работа в условиях РЭБ, передача файлов в органы исполнительной власти и многое другое. Софт может забрать на себя эту рутину и автоматизировать её, но отменить — нет.

Вместо заключения

Дронопорт без софта — это действительно просто гараж, пусть и умный. Вся ценность — “смотрим часто, регулярно, по одной траектории, без людей на точке” — рождается в программной части: в планировщике, который сам режет миссии, в телеметрии, которая не рвётся вместе с видео, в интеграциях, которые доносят данные до тех систем, где их ждут.

Готов поразбирать вопросы в комментариях: про архитектуру, про сценарии потери связи, про интеграции с ГИС и отраслевым софтом. Присылайте свои предложения по ИИ. Если интересно — следующей статьёй могу разобрать какой-нибудь кейс целиком, от постановки миссии до готового ортофотоплана.