Однажды в институте зав кафедры рассказывал нам о нашей будущей профессии:
Наша профессия очень важна и ответственна. Сейчас вы работаете над обликом будущего флагмана Российской авиации. Вы сыпете идеями, пытаетесь предугадать задачи, которые он будет решать, берете на себя ответственность и принимаете решения. А через 15 лет, когда самолет наконец построят, всем будут раздавать почести, но про вас уже никто не вспомнит.
Такая агитация мне не понравилась, ждать 15 лет результата я не готов.

Авиация высокоразвитая отрасль, но высокие требования по надежности и распланированное будущее не позволяют внедрять новые технологии быстро. А беспилотникам же наоборот, никаких особых требований пока нет, вот они и растут как грибы после дождя, заполняя собой ниши авиа мониторинга, рекламы, помощи сельскому хозяйству, видеосъемки и подобные.
Так я и решил, пускай они там как-нибудь без меня строят свои истребители, а я, пока молод и горяч, пойду в беспилотники. Благо что авиамодельное прошлое имеется.

Какие есть пути развития авиации? На мой взгляд, авиация может развиваться двумя путями:

• Использование инновационных технологий для комплектующих (новые эффективные силовые установки с малым весом, авионика и прочее).
• Изменение аэродинамической схемы.

Мне больше импонирует изменение аэродинамической схемы самолета. Этим путем появились такие аэродинамические схемы как утка и летающее крыло. Но инженерам этого было мало, им хотелось, чтобы аэродинамика изменялась прямо в полете. Так появились самолеты с изменяемой геометрией крыла (Су-24, Ту-22М, Ту-160, F-111 и им подобные), самолеты с управляемым вектором тяги (Миг-29ОВТ, Миг-35, Су-30, 37, 57, F-22 и др) и, конечно же, конвертопланы (например, всем известный Bell V-22 Osprey).

Это все, конечно, хорошо, но не совсем мне по душе. Идея с изменяемой геометрией крыла интересна, но надо, чтоб если складывались крылья, то так, чтоб совсем, а не жалкие несколько градусов. А вот идея с поворотными силовыми установками мне импонирует. Так и родилась идея сделать свой конвертоплан. Схематично нашу идею можно описать следующим образом:


Я собрал команду и вскоре мы определились. Идея нашего конвертоплана заключалась в объединении самолетной схемы летающее крыло и вертолетной продольной двухвинтовой схемы. Мы решили, что крылья будут складываться вниз, причем не половина крыла, как у корабельных самолетов, а целиком, чтобы не создавать дополнительное сопротивление при наборе высоты в вертолетном режиме.

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

Какие преимущества у данной аэродинамической схемы?

• За счет огромного крыла мы получаем высокое аэродинамическое качество в самолетном режиме, что значительно увеличивает дальность полета в сравнении с другими конвертопланами.
• Вертикальный взлет и посадка (не требует ВПП).
• Возможность зависать в воздухе.

Закончим введение и перейдем к сути. Для реализации проекта нам необходимо:

• Изготовить прототип.
• Создать систему стабилизации за счет управляемых векторов тяги.
• Реализовать алгоритмы переходного процесса во время смены режимов полета.
• Провести тестовые полеты, отладить систему.
• Коммерческий полет.

Прототип 1

Мы приступили к созданию первого прототипа. У нас не было никакого особого оборудования, только руки и базовые знания. Начали с того, что начертили модель в 3D.





Построенный летательный аппарат выглядел следующим образом:





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

Написали простенький код для управления моторами и запустили этого монстра сначала на стенде, а потом и в воздухе. Мы с ней съездили на несколько конференций, где получали неоднозначные отзывы. При изготовлении первого прототипа в расчеты мы не углублялись, и единственная лтх, которую мы можем предоставить, это его габариты. Круизная скорость рассчитывалась на 100 км/час, но как-то не сложилось с дальними полетами и записью хоть каких-то характеристик.

Не смотря на то, что построенная модель не оправдала ниших ожиданий, она, несомненно, показала, что подобное устройство все же имеет прово на жизнь и еще позволила сделать следующее:

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

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

После у всех участников данного проекта началась учеба в разных институтах, и мы забросили этот проект. Постепенно команда куда-то разъехалась. Когда учеба в институте подходила к концу, и приближался дипломный проект, у всех нас всплыла идея вернуться к этому летательному аппарату. Ни у кого не возникнет сомнений что подобный агрегат многогранен, и работы там найдется всем и всегда. Поэтому каждый взял себе кусочек который максимально близко подходил его специальности

Прототип 2

Встретились как-то красотка, сантехник, турист, айтишник и школьник. И сантехник говорит, Диплом близко, надо строить самолет.

Мы собрались снова и начали делать второй прототип. Теперь в нашем распоряжении были: гараж, оборудованный по последнему слову техники, токарный станок, ЧПУ, 3D принтер, а также опыт и знания, полученные в институте. Сразу определили целевое назначение беспилотника, он будет мониторить нефтепроводы. Под эту задачу подобрали оптимальные ЛТХ (это отдельная история). Рассчитали и начертили все агрегаты и узлы. Рассчитали систему спасения и сшили парашют. Разработали систему раскрывания и складывания крыльев. Изготовили прототип со следующими ЛТХ:












С построенным прототипом мы принимали участие в МАКС-2019, поучавствовали в конкурсе от Вертолетов России и продолжаем заниматься его доработками в свободное от отдыха время.

Выводы

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

Мы все еще горим желанием увидеть задуманное в воздуже и прилагаем к этому все возможние усилия.

P.S

В данном проекте при постановки целей и задач я руководствуюсь требованиями и условиями предъявляемыми к ДПЛА в задачах мониторинга, применение всех идей подходов и созданных прототипов в других отраслях может быть рассмотрено только после достижения поставленных сейчас целей. Такой подход считаю рациональным в сложившихся обстоятельствах с ограниченными материальными, трудовыми и временными ресурсами. Подобными суждениями я пользовался довольно часто в процессе работы над этим проектом, потому что с нетерпением хочу увидеть в действии то, чем занимаюсь.

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

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

Мы приняли решение построить прототип, на котором сможем попытаться сымитировать динамику и принципы управления, которые необходимы нашему конвертоплану.

Я в авиамодельном хобби совсем не новичок, хотя сам еще довольно молод (еще пока студент магистратуры), но и мне крайне тяжело, а иногда и невозможно успевать за функционалом существующих прошивок и полетных контроллеров для квадрокоптеров и других БПЛА. Насколько я помню, шесть лет назад простые прошивки для дронов помещались в Arduino IDE и работали на платах от пульта для приставки. Сегодня же китайские фирмы предлагают нам за 20 долларов плату с прошивкой, функционал которой превосходит базовую программу обучения в институте. Таким образом, перед желающими собрать квадрокоптер стоит огромный соблазн даже не пытаться заняться изготовлением полетного контроллера. Выбор имеющихся решений огромен, однако, как я сам убедился, не безграничен.

Прототип

Пытаясь придумать систему управления бикоптером со всеми степенями свободы, наша дримтим решила попробовать создать сначала то, что скорее всего точно полетит. Выбор мы остановили на квадрокоптере. Таким образом, мы пришли к выводу, что нам необходимо построить квадрокоптер с управляемыми векторами тяги каждого мотора. Я, конечно, могу сказать, что в технических условиях мы договорились, что управление в горизонтальной плоскости мы будем осуществлять за счет управления вектором тяги, однако по-другому у нас просто не получилось.


Что бы хоть чем-то отличаться от людей, получающих образование на форумах, хотя сами такой информацией не брезгуем, мы начали с проработки примерной 3D модели. Основной отправной точкой для себя мы взяли микросервоприводы с металлическим редуктором. Таким машинкам точно хватит усилия и прочности. Прикинув период колебаний пятидюймового квадрокоптера я понял, что и скорости работы хватает с достаточно большим запасом. Основываясь на этих компонентах, мы серьезно занялись проблемой выбора моторов. Преодолев долгие душевные терзания, мы вспомнили, что в душе все мы немного акционеры и остановились на квадрокоптерных моторах, которые были по акции на одном известном китайском сайте. Затем, мы перешли к постройке 3D модели. Модель должна была быть максимально простая, чтобы ее можно было быстро изготовить: частично напечатать на 3D-принтере, сделать раму из подручных материалов, ну и, конечно, подогнать сверхточным инструментом напильником. В итоге, за два вечера в компании интересного собеседника, получилось создать именно ту модель, что отвечала поставленным задачам.

Моделирование системы управления

Какой же проект без научной составляющей? Надо провести исследования. Возможности Simulink (Matlab) позволили нам смоделировать похожую модель с выбранной системой управления. Имея готовую 3D модель, нам не составило труда задать ее физические свойства в Matlab.

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

Стратегию управления мы взяли, как нам показалось, максимально простую. Мы решили стабилизировать квадрокоптер в горизонтальном положении за счет разностей тяг моторов, а перемещаться в горизонтальной плоскости за счет наклона моторов в двух плоскостях.
Со стабилизацией в горизонте вопросов совсем невозникало, так как на эту тему существует огромное количество статей и большой выбор контроллеров: начиная от простейшего PID контроллера, заканчивая контроллерами, самонастраивающимися с помощью нейронных сетей.
Мы остановились на самом простом PID контроллере. Для управления в горизонте мы решили пропорционально отклонять каждый мотор для создания требуемого усилия. Отклонять сервоприводы будем парируя возникающие линейные ускорения PID контроллером. Удерживать позицию нам это не поможет, однако нам это и не надо. Мы пока просто хотим понять, полетит ли такая конструкция. Загвоздка еще состоит и в необходимости добавлять газ мотору при его отклонении, но мы этим пренебрегли.

Изготовление прототипа

Поборов в себе желание создавать всю прошивку для такого квадрокоптера с нуля, мы прибегли к, на мой взгляд, элегантному решению. Мы разделили между двумя платами задачу стабилизации квадрокоптера в горизонте и задачу управления им. Таким образом, моторами у нас управляет самый обыкновенный коптерный полетный контроллер F4, а за управление актуаторами отвечает отдельная плата STM Blue Pill.
Схематично это можно представить следующим образом:



После построения модели в Simulink, написать нужную программу вполне посильная задача. Особенностью нашего контроллера является разделение на два PID контроллера (вперед-назад и вправо-влево), и расшифровка-зашифровка сигнала SBus. То есть с приемника дистанционного управления мы передаем сигнал нашей плате, делаем все что пришло в голову пилоту, а квадрокоптерному полетному контроллеру создаем свой управляющий сигнал, требующий лишь удержания квадрокоптера горизонтально, то есть контролируем лишь тягу моторов.

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

Летные испытания

Взяв школьника, у которого еще не развит инстинкт самосохранения, мы приступили к летным испытаниям. Конечно же мы предупредили его о возможных опасностях, но лишиться пальца он не боялся. Мы вообще не верили, что это полетит. Но тем не менее, с первой попытки все получилось. Летает он на удивление быстро, возможно, это связано с уменьшением аэродинамического сопротивления в сравнении с классическими моделями квадрокоптеров. Посмотрите видео, там показано, как наш квадрокоптер держится в полете.



За возможность перевозить открытый стакан с жидкостью и топорность конструкции, мы присвоили своему произведению кодовое название Летающая табуретка. В итоге, получился квадрокоптер, который отлично подходит для перевозки пиццы и напитков. Также его можно использовать для других задач, где требуется горизонтальное положение в полете, например, для отслеживания качества дорожного полотна. Не знаю, конечно, как это поможет, но подобные предложения уже поступали.

P.S.

Для тех кому интересно, насколько полезным может быть такой топорный метод компьютерного моделирования, я добавлю график сравнения отклика прототипа на управляющий сигнал во время летных испытаний и график отклика смоделированной в Matlab модели на лог этого же сигнала.

По оси крена:


По оси рысканья:

Вывод

Таким образом, методом проб и ошибок, мы медленно, но верно приближаемся к своей мечте.

^{Прототип БПЛА Stratospheric Platforms. Photo credit: Stratospheric Platforms Ltd.}
Стартап из Британии Stratospheric Platforms вместе с американской компанией Northrop Grumman работает над водородным двухмоторным стратосферным беспилотником. Один такой аппарат способен обеспечить покрытие 5G-связью соту с диаметром ячейки в 140 км.

Стратосферный беспилотник изготавливают по схеме высокоплана с V-образным хвостовым оперением.

Характеристика БПЛА:

• вес 3,5 тонны;
• размах крыла 60 метров;
• высота полетов 18,3 тыс. м;
• длительность полета 9 дней.

Первый тестовый полет запланирован на 2022 год.

Известно, что ранее стартап тестировал систему связи стандарта 4G с установкой базовых станций на летательные аппараты. Эксперимент проводили на самолете Grob G 520 на высоте 13,7 тыс. метров. На данный момент удалось добиться неплохих результатов, с пропускной способностью канала около 70 МБайт/с к абонентам и 20 МБайт/с от абонентов.

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

Не единственные в своем роде

^{Photo credit: HapsMobile}
Одновременно с Stratospheric Platforms разрабатывает похожие беспилотные аппараты HAPS Mobile, дочерняя компания SoftBank, для обеспечения связью в труднодоступных местах. Вместе с Loon, дочерней компанией Alphabet Inc., они работают над системой сотовой связи с использованием воздушных шаров. Стартапы протестировали в стратосфере на беспилотнике Sunglider, сконструированном в виде единого крыла размахом 78 метров. Аппарат работает от солнечных батарей. В движение БПЛА приводят пропеллеры.

^{Photo credit: HapsMobile}
Общее время полета составило 20 часов 16 минут, на границе стратосферы беспилотник находился 5 часов 38 минут. Во время тестового полета с помощью Sunglider удалось установить соединение стандарта LTE. Полет осуществлен при сложных погодных условиях: скорость ветра достигала 100 км/ч, а температура опускалась до -73 градусов по Цельсию.

Летая на высоте 20 км над уровнем, Sunglider способен поднять полезный груз массой полезную нагрузку до 68 кг. Беспилотник может находиться в атмосфере в течение нескольких месяцев без посадки.

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

Очень спорно, очень необычно, очень странно, но работает! На стыке архитектуры, коллаборативной робототехники и беспилотных летательных аппаратов. Представляем: Tensodrone.



Tensodrone (Тенсодрон) беспилотный летательный аппарат (БПЛА) мультироторного типа новой конструкции с защитой от столкновений, сделанный по принципу тенсегрити. Такой подход позволяет повысить устойчивость к ударам при меньшей массе, совместив защитную клетку и конструкцию несущей рамы.

Проект является ярким примером взаимодействия различных команд Центра компетенций НТИ по направлению Технологии компонентов робототехники и мехатроники на базе Университета Иннополис.

Дроны падают

Источник

Просто потому что летают. Системы управления, моторы, датчики, автопилоты, бортовые компьютеры и софт все это разработчики стараются делать как можно надежнее, но риск разбить коптер остается. А если это опытный образец, то сразу нужно изготавливать несколько (штук или десятков?) для отладки. Кроме внутренних факторов, очевидно, остаются и внешние: ветер, пассивные препятствия, активное воздействие.

Вряд ли кто-то будет спорить, дроны падают, сталкиваются, переворачиваются.
Можно стараться этого избегать, можно к этому подготовиться. Что лучше? Решать разработчику, пользователю и законодателю.

Я за совместное применение обоих подходов. Но в этой статье сконцентрируемся на том, как избежать последствий падения или столкновения БПЛА.

Защитные конструкции

Наиболее прямолинейный подход избежать последствий падения или столкновения БПЛА защитная клетка и прочие защитные конструкции. Здесь две задачи защищать дрон от повреждений и защищать среду, где работает дрон, и людей в ней от дрона.

Базовый вариант конструкции, относящейся скорее к защите людей от дрона, защита пропеллера.


Дрон AR.Drone 2.0 с защитой пропеллеров. Источник

Есть еще забавные решения, вдохновленные оригами, со складными гибкими конструкциями защиты пропеллеров (и даже конструкции рамы), развитие которым дала группа профессора Дарио Флореано в EPFL.

Превалирующей конструкцией защиты самого дрона (а вместе с тем и людей от него) является защитная клетка. Сам квадрокоптер находится внутри клетки.


Дрон Clover от российской COEX

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


Дрон Flyability ELIOS

Швейцарская (Швейцария столица дроностроения?) компания Flyability выпускает, пожалуй, самый коммерчески успешный коптер ELIOS с защитной клеткой для выполнения инспекций внутри помещений. Оригинальность конструкции состоит в креплении защитной клетки к раме коптера на подвижном подвесе с возможностью стабилизации.


Дрон Dronistics

Стартап Dronistics из EPFL (опять Швейцария, это выходцы из группы Dario Floreano) предлагает дрон со складной клеткой для безопасной доставки грузов.


Недостатком таких дронов является увеличение массы конструкции нужно носить с собой защитную клетку и элементы крепления к БПЛА. Стремление снизить массу защитной конструкции приводит к снижению ее прочности.

Дроны с изменяемой геометрией

Другое направление, связанное с идеей защищенного дрона (и не только), складные дроны и дроны с изменяемой геометрией (foldable и morphing). Имеется ввиду способность дрона изменять свою геометрию в полете. Складные конструкции делают для того, чтобы избежать повреждений дрона (например, дрон может съежиться перед ударом), а также дрон может, например, сложиться до компактного размера для пролета в узкие окна.

Возможно, вы видели крутой ролик с дроном с изменяемой геометрией из Швейцарии (да-да, снова ETH + EPFL + UZH). Нам эта идея тоже интересна и близка, дальше расскажу почему.


Дрон с изменяемой геометрией

Тенсегрити

Тенсегрити-стол. Источник

Тенсегрити способность каркасных конструкций использовать взаимодействия работающих на сжатие цельных элементов с работающими на растяжение составными элементами для того, чтобы каждый элемент действовал с максимальной эффективностью и экономичностью (Вики). Термин относительно новый, появился в 1960-х годах. Стол на картинке выше стоит (или висит) не имея ножек как раз за счет принципа тенсегрити.

Известно множество современных применений такого подхода в архитектуре, откуда он и появился, прежде всего при проектировании мостов.


Самый большой в мире мост, выполненный в стиле тенсегрити, Австралия. Источник

Тенсегрити в робототехнике

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

В промышленной робототехнике термин compliance относится к гибкости и податливости. Неподатливый (non-compliant), жесткий (stiff) робот это устройство, которое работает независимо от того, какие внешние силы на него воздействуют. Энд-эффектор робота будет каждый раз следовать точно по одной и той же траектории. С другой стороны, энд-эффектор податливого робота может двигаться по различным траекториям для выполнения задачи и прилагать различные усилия к объекту. Например, робот может схватить яйцо, не раздавив его. Управляемая жесткость лежит в основе коллаборативной робототехники.

Идеи применения тенсегрити в робототехнике идут как раз из коллаборативной и мягкой (soft) робототехники. Тенсегрити структуры легкие, ударопрочные и дают возможность контролировать их жесткость (податливость) и конфигурацию (форму).

Наиболее известным примером применения тенсегрити в робототехнике является складной наземный робот NASA Super Ball Bot, который планировали использовать для исследования поверхностей планет. Благодаря сфероподобной структуре из кабелей и тросов робот может выдержать падение с большой высоты, когда его сбрасывают на планету с космического корабля. Оказавшись на поверхности, робот может перекатываться в любом направлении за счет управления длинами стержней.


Видео IEEE Spectrum о NASA SUPERball v2

Тенсегрити-роботы в Университете Иннополис

В УИ мы разрабатываем математический аппарат для моделирования, проектирования и управления робототехническими системами с напряженно-связанными структурами с переменной жесткостью (это и есть тенсегрити). Это фундаментальная работа, применение которой можно найти в самых разных роботах, например, тенсегрити-манипуляторах или шагающих роботах.


Тенсегрити-манипулятор и научный сотрудник и аспирант УИ Олег Балахнов

Олег первым у нас начал прототипировать тенсегрити-роботов сначала из деревянных палочек и резинок. Фото конструкции из палочек для суши, пожалуй, тоже еще хранит история чатов.

Синергетический эффект

Вы, наверное, уже поняли

I have a drone, I have tensegrity. Ugh! (Tensodrone)

Проходил я как-то в нашем гараже мимо привлекающей глаз странной конструкции:



Спросил: Что это такое? Мне сказали: неубиваемая конструкция роняй, а она не ломается.

Я сломал (на самом деле просто скукожил изменил форму, потому что резинки были плохо закреплены и сместились). Но такая конструкция нам для дронов нужна! И мы начали авантюрный эксперимент.


Видео с тестом тенсегрити на выживаемость

Авантюра

Сергей одобряет авантюрный эксперимент. Джефф Безос тоже

Сергей Савин старший научный сотрудник, доцент, серьезный ученый с кандидатской в 25 лет и множеством рейтинговых публикаций. Он один из отцов-основателей тенсегрити-робототехники в УИ, получил несколько грантов на развитие тенсегрити в робототехнике.


Дмитрий, Олег и Хэни собирают первого тенcодрона (что-то напоминает). Дмитрий Девитт GigaFlopsis научный сотрудник и аспирант Университета и тот, кто применил самые современные технологии карбоновые трубки и кевларовые нити, 3D-печать карбоном и мягким пластиком, все реализовал и заставил летать.


Процесс работы по сборке тенсодрона


Ура. получилось!

Летает!

Еще Дмитрий первый актер после тенсодрона в эпичных роликах его полетов. Оцените:


Игра двух актеров в ролях самих себя. Video by DeluuusiOn

Подробнее про конструкцию прототипа

Конструкция первого прототипа дрона получилась такая:


Конструкция прототипа тенсодрона Университета Иннополис

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

Бортовая электроника и электромеханические компоненты прототипа дрона включают в себя:

• Автопилот CUAV Pixhawk v5 mini;
• Аккумулятор 3s 1400 мАч;
• Регулятор Racerstar REV35 35A BLheliS 3-6S ESC;
• Моторы Racerstar Racing Edition BR2205 2300KV;
• IMU сенсоры MPU9250.

Тросы сделаны из кевларового волокна с изготовленными на заказ пружинами. Стержни изготовлены из карбоновых трубок. Торцевые колпачки и другие мелкие детали напечатаны на 3D-принтере.

Проблемы управления

Основная проблема управления по сравнению с обычным жестким дроном вибрации, которые, во-первых, больше по амплитуде, во-вторых, разные для контроллера и различных двигателей, т.к. они установлены на различных балках (хотя это же может быть и плюсом виброразвязка).


Ранние тесты тенсодрона на подвесе: вибрации (извините за вертикальное видео)


Ранние тесты тенсодрона в полете: вибрации


Данные проблемы мы решаем с двух сторон улучшением конструкции для уменьшения вибраций при полете и разработкой алгоритмов управления и оценивания состояния с целью подавления вибраций и более качественного управления, в том числе с учетом дополнительных данных от IMU датчиков на балках и динамической модели тенсегрити-структуры.


Падение на пол с последующим взлетом, в помещении (без монтажа)

Что дальше?

Ресерч

Впереди еще много интересного: подача заявки на патент, написание научной статьи с подробными исследованиями, апробирование новых вариантов конструкции (ох, их у нас придумано много).

Применение

Сейчас эта штука летает сама по заданной миссии (в том числе по GPS на улице, а в помещении будем использовать визуальную одометрию). Для нас очевидно дальнейшее применение для инспекции помещений.

За исключением управления низкого уровня и формы, тенсодрон это обычный дрон, мы интегрируем в него наши алгоритмы планирования движения для автономного обследования и картографирования помещений (exploration) с обходом препятствий.


Пример выполнения автоматической инспекции. Магистерский проект Виктора (Victor Massague), нашего выпускника и в ближайшем будущем, надеюсь, сотрудника из Барселоны

И снова ресерч

Потенциал конструкции тенсегрити-дрона гораздо больше простого дрона.
Помните Foldable Drone из видео выше? А SUPERball?

Так вот, если активно изменять длины стержней или натяжения тросов тенсегрити-дрона, можно управлять его конфигурацией (или, проще говоря, формой)!

Получается Foldable Morphing Tensodrone. Активно ведем исследования в этой области.


Тенсодрон с изменяемой в полете геометрией Университета Иннополис (концепт)



Применение тенсегрити для летательного аппарата открывает новые исследовательские задачи. Прототип конструкции уже сейчас показывает, что идея работает и её можно применять для защиты БПЛА.

Что бы разбавить зубодробительную математику лекций Козлова Олега Степановича "Управление в технических системах", публикуем здесь пример применения знаний из этих лекций на практике.

В данной статье, Александр Щекатуров, ученик Олега Степановича описывает создание модели октокоптера, попутно раскрывая секреты и демонстрируя приемы работы в среде структурного моделирования физических систем.

В настоящей статье приведено описание логически завершённой, но всего лишь части полной работы по моделированию, но этой части достаточно для введения в тему динамического моделирования БПЛА коптерного типа.

Здесь опущено моделирование эффектов прецессии, принимается что и реактивный момент каждой ВМГ равен нулю, а именно: каждая ВМГ имеет два двигателя и винта, вращающихся с одинаковой скоростью в противоположные стороны. Не моделируются отказы оборудования и предполагается что объект находится только в воздухе (в штатном режиме полёта), режимы посадки и взлёта, аварийные ситуации, захват груза и разгрузка в приведённой модели не реализованы, а также не рассматриваются вопросы подробного моделирования датчиков, фильтрации сигналов и шумов, изгиб рамы коптера и/или винтов, работа на запредельных нагрузках, написание драйверов к той или иной аппаратуре и т.д. и т.п., всё это темы более расширенной статьи или даже книги.

1 Постановка задачи

Дано: объект массой порядка 1025 кг, с 4, 6 или 8-ю парными соосными винтомоторными группами (ВМГ), расположенными по традиционной схеме квадро, гекса или октокоптера на жёсткой раме, с 8, 12 или 16 двигателями типа T-motors Antigravity 6007 KV320 или аналогичными и соответствующими им винтами (исходим из грузоподъёмности одной ВМГ порядка 2 кг на 50% газа). Предположим что конструкция аппарата до конца не определена.

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

2 Основные положения модели

В литературе и сети приведено довольно много моделей квадрокоптеров, есть некоторые модели гекса- и октокоптеров. Однако, изложенного в системном и методичном виде со всеми подробностями практически ничего нет (по крайней мере, в русскоязычном сегменте, из тех материалов что удалось найти). Наиболее методично теоретический подход к моделированию мультироторного БПЛА изложен в работах [1] и [2].

Опуская некоторые выкладки, изложенные в этих работах (они легко гуглятся), можно выделить следующие допущения и упрощения, принятые в модели:

1. Двигатель моделируется как инерционное звено (апериодическое звено) первого порядка, на вход которому подается заданное значение угловой скорости, а на выходе текущее (измеренное) значение угловой скорости вращения. Интегрируя скорость вращения, можно получить и текущий угол поворота если это зачем-то нужно. Силу тяги ВМГ развивает пропорциональную квадрату угловой скорости (равно как и реактивный момент каждого двигателя, но в нашем случае он будет 0), а именно:

   

   
   где, для выбранной винтомоторной группы (согласно её характеристике):
   ,
   реактивный момент двигателя,
   текущая угловая скорость, рад/с.
2. Мультироторный аппарат моделируется как твёрдое тело и представляет собой жёсткую (недеформируемую) раму постоянной массы, симметричную по трём главным осям, с прикрепленными к ней ВМГ в одной плоскости, в которой находится и центр масс аппарата. При этом ВМГ расположены на восьми лучах (4 из них одной длины, а другие 4 могут быть другой длины) и жестко закреплены относительно рамы. Таким образом можно говорить о том, что радиус-векторы центров ВМГ и орты силы тяги каждой ВМГ суть геометрические константы в системе координат, связанной с коптером. Другими словами, величина [Н], вычисленная в модели ВМГ, является модулем вектора силы, приложенного всегда в определенном направлении и в определенной точке коптера. В процессе полета это направление будет меняться, конечно, но относительно рамы коптера (и связанной с ней системы координат) оно остаётся неизменным.
3. Используется две системы координат: а) неподвижная инерциальная, связанная с Землёй и б) подвижная, связанная с коптером. Системы координат обозначим буквами I и B (от английских слов inertial инерциальный и body тело). При этом оси систем направлены: -вправо, -на наблюдателя, -вниз, вправо вдоль луча первой ВМГ, -на наблюдателя вдоль луча третьей ВМГ, -сверху вниз при нормальной ориентации коптера (см. рисунок):
   
   Тогда, в системе координат B векторы центров ВМГ будут равны:
   

   

   
   где длина луча у 1, 3, 4 и 5-й ВМГ, а длина лучей у 2, 4, 6 и 8-й ВМГ.
   

   Для того чтобы коптер управлялся (хотя бы немного) по курсу, в нашем случае отсутствия реактивного момента двигателей, вектора сил тяги каждой ВМГ должны быть немного отклонены от вертикального направления (повёрнуты вокруг каждого луча на небольшой угол порядка 15 градусов, причем в разные стороны четные в одну а нечетные в другую). Если обозначить этот угол как , орты можно получить в следующем виде:
   

   

   
   На основе этих геометрических констант (напомним, они являются константами только в системе координат B, связанной с коптером) строится весь дальнейший каркас модели, поэтому они важны. В общем случае, винтомоторных групп может быть другое количество и направлены они могут быть в других направлениях, и располагаться у коптера в других местах.
   О применяемых системах координат подробно изложено в [1].
4. Силы, которые будут учтены в модели. На коптер действуют:
   4.1) Сила тяжести. Направлена всегда вниз вдоль оси инерциальной системы координат . Сила тяжести постоянная величина, зависит только от массы коптера. Масса коптера принимается постоянной и не меняется (хотя в процессе моделирования её можно будет менять, имитируя дополнительный полезный груз, навешенный на коптер).
   4.2) Силы тяги ВМГ их всего 8, они направлены вдоль своих направлений, модуль сил вычисляется в зависимости от угловой скорости вращения соответствующей ВМГ.
   4.3) Сила сопротивления воздуха (и/или ветер) моделируется как состоящая из двух компонент. Сила сопротивления воздуха прямо пропорциональна плотности воздуха, квадрату линейной скорости объекта в воздухе и характерной площади сечения в выбранном направлении (коэффициент формы). Сила ветра внешняя возмущающая сила, задается произвольным образом или при помощи дополнительной модели ветра (в настоящей статье не рассматривается).
   4.4) Внешняя сила или возмущение произвольное внешнее воздействие. В модели такая возможность заложена как простой способ в дальнейшем проверять на устойчивость регуляторы по каждому из направлений.
   
5. Моменты, учитываемые в модели:
   5.1) Реактивный момент двигателей ВМГ. В нашей модели он равен нулю, из-за парности двигателей и винтов в каждой ВМГ в общем случае следует учитывать. В некоторых аппаратах этот момент используется и для управления по курсу.
   5.2) Явление прецессии в рассматриваемой модели он нулевой, в общем случае его нужно считать.
   5.3) Момент сопротивления воздуха аналогично силе сопротивления воздуха, прямо пропорционален плотности воздуха, квадрату угловой скорости коптера и коэффициенту формы.
   5.4) Опрокидывающий момент от ветровой нагрузки.
   5.5) Внешний возмущающий момент для отладки регуляторов.
   5.6) Моменты от сил тяги ВМГ. Поскольку винты расположены не в центре масс коптера, каждый из них будет создавать свой поворотный момент. Это, пожалуй, основной фактор, который управляет ориентацией коптера в пространстве.

3 Нелинейные уравнения динамики октокоптера

С учетом принятых допущений, и того что коптер моделируется как единое твёрдое тело, основа модели динамики коптера очень проста это второй закон Ньютона, который в векторной форме выглядит следующим образом, всего два простых уравнения:

где импульс коптера, а момент импульса коптера, его масса, тензор инерции (линейный оператор момента инерции). и суть суммы всех сил и всех моментов, действующих на коптер.

Легко видеть, что всё было бы очень просто и очевидно, если бы правые части были небольшими, а тензор инерции не зависел бы от ориентации коптера (как если бы коптер был шаром). Но из-за вращения коптера, а также из-за обилия сил и моментов, конечные уравнения, записанные в инерциальной системе координат, получатся очень громоздкими, даже без учета прецессии и реактивных моментов ВМГ. Поэтому используется следующий математический приём уравнения, записанные в инерциальной системе координат, переводятся в систему координат B, связанную с коптером, в которой слагаемые правой части (их запись) получается гораздо более лаконичной и удобной. Подробнее этот приём описан в [1], приведём здесь лишь основные соотношения.

Подставив в приведенные уравнения второго закона Ньютона значения для импульса и момента импульса коптера, для инерциальной системы координат получим:

В этих уравнениях математически очень сложны правые части, а уравнения динамики в связанной системе координат B (где правые части более просты) не могут быть получены так легко, поскольку система координат, связанная с коптером вращается.

В математике есть два основных подхода к преобразованию векторов из одной системы координат в другую и обратно матрицы поворота и кватернионы. Последние более универсальны, первые проще. В настоящей модели используются матрицы поворота. Если ориентацию коптера представить тремя углами: крена (roll), тангажа (pitch) и рыскания/курса (yaw), а матрицы преобразования из системы I в B и обратно обозначить как и , то любой вектор записанный для системы координат I, можно перевести в систему координат B, и наоборот, используя умножение соответствующей матрицы на вектор, например: , или .

Чтобы лучше понимать написанное далее, прокомментируем ещё раз как понимать матрицы поворота и вектора в пространстве: система координат I неподвижна, относительно неё летает и вращается коптер, а вместе с ним и связанная система координат B. Просуммировав все силы, которые действуют на коптер, можно получить вектор (аналогично и с моментом сил), и в каждый момент времени он является вектором с вполне определенной длиной и направлением в пространстве. Но раскладывая его на проекции по осям в разных системах координат мы получим разные величины проекций. Всё что делает матрица поворота это переводит одни проекции вектора в другие, при этом сам вектор никуда не поворачивается и не изменяет своей длины, в выбранный момент времени. Если проекции сравнить с тенями вектора, то матрицы поворота преобразуют одни тени в другие, всё. Больше они ничего не делают и сложностей кроме вычислительных не представляют.

Нам они нужны только из-за того, что вычислять и суммировать силы и моменты сил, действующие на коптер, гораздо проще в связанной системе координат B. В ней же проще провести численное интегрирование уравнений, чтобы получить величины угловой и линейной скоростей коптера и , а потом обратной матрицей поворота вычислить (вычислить алгебраически матрицы поворота это простые уравнения) эти же скорости для инерциальной системы координат I и там уже, интегрируя дальше, вычислить линейные и угловые координаты коптера.

Приведем используемое выражение для матрицы поворота из системы I в B, записав для краткости функции косинуса и синуса как cos() = c() и sin() = s():

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

Реализованная методом структурного моделирования, матрица в среде SimInTech выглядит как показано на рисунке 1.

Рисунок 1. Матрица поворота из системы I в систему координат B

Тогда, для вектора линейной скорости можно записать:

а для момента импульса

Опуская промежуточные выкладки (в том числе производную матрицы поворота, которая получается равной в итоге векторному произведению угловой скорости объекта на саму матрицу поворота, взятое с обратным знаком), для первого из рассматриваемых уравнений динамики получим следующее выражение в связанной с коптером системе координат B:

а для второго уравнения, учитывая что ,
и так как во вращающейся связанной системе координат тензор инерции константа и его производная по времени равна нулю, а получим:

Итого, запись II закона Ньютона для вращающейся системы B, по сравнению с исходными уравнениями, дополнилась двумя векторными произведениями.

Переменными состояния коптера в такой записи являются две векторных величины (или 6 скалярных) вектор линейной скорости и вектор угловой скорости. Алгебраически это будет 6 переменных три проекции линейной скорости и три проекции угловой скорости. И мы имеем записанную в форме Коши систему из 6 нелинейных уравнений первого порядка, которую легко можно реализовать в среде структурного моделирования SimInTech или Simulink или Scilab и даже успешно решить её тем или иным методом интегрирования.

Получив значения скоростей коптера (сначала в системе B), их можно матрицей обратного поворота преобразовать к системе I, еще раз проинтегрировать и получить уже значения координат и, следовательно, положение объекта в пространстве, в инерциальной системе координат.

Единственное что мы еще не сделали по уравнениям не записали выражения для сил и моментов, действующих на коптер. Сделаем это ниже, в системе координат B. Согласно допущениям, учитываем и обозначим индексами: M работу двигателей, только в части создаваемой силы тяги и моментов от неё, D силу сопротивления воздуха (вместе с ветром), O внешнее возмущение, вообще нулевое, и задаваемое произвольно пользователем, силу тяжести она поворотного момента сил не создаёт:

Сила тяжести в связанной системе координат будет поворачиваться в зависимости от ориентации коптера.

Распишем подробнее чему равны слагаемые:

Здесь уже фигурируют угловые скорости вращения ВМГ, а не коптера. Напомним, что орты сил тяги у нас записаны для системы координат B и там являются константами очевидно, что их можно вычислить 1 раз, общий коэффициент вынести здесь за скобку и сильно упростить вычисления. Если бы мы записывали уравнения динамики в системе I, то данное выражение обросло бы ещё 8-ю умножениями на матрицу поворота каждого орта и это пришлось бы считать на каждом шаге расчета.

Сила сопротивления воздуха (при отсутствии ветра):

Внешнее возмущение нулевое, по желанию пользователя, он может сам установить то или иное значение позже, до расчета, или в процессе моделирования.

Момент сил тяги двигателей запишем как:

Момент сопротивления воздуха (подробнее см. [1]):

Ещё раз отметим, что расчет прецессии и реактивных моментов ВМГ в данной статье для краткости изложения опущен.

Чтобы не ошибиться при переходе от векторных уравнений к скалярным, записанным по осям, проще воспользоваться пакетом типа MathCAD или Maple, в котором большинство преобразований можно выполнить автоматизированно, в символьном виде и получить требуемые 6 уравнений динамики, записанные по осям подвижной системы координат B.

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

Интегрируя их и получив значения скоростей в системе В, можно посчитать скорость и углы ориентации в инерциальной системе координат I:

Про матрицу преобразования из угловой скорости коптера в скорости поворота по углам Эйлера подробнее см. в [1].

3 Реализация уравнений динамики в среде струкутурного моделирования

Переходим к самому интересному к реализации полученных уравнений динамики средствами среды динамического моделирования SimInTech. Как известно, любую задачу можно всегда решить несколькими способами, и чем она сложнее и многомернее тем больше количество способов. В настоящей статье предложен один из вариантов решения, он не единственный, и в некоторых местах не самый оптимальный. Выбор решения определялся простотой реализации с одной стороны, и удобством для методичного рассказа, с другой.

Итак, что мы получили с точки зрения математики в системе координат B мы имеем 2 векторных дифференциальных уравнения, которые при переходе к проекциям (и скалярным уравнениям) дают 6 нелинейных дифференциальных уравнений первого порядка, относительно 6 переменных: трёх скоростей и трёх угловых скоростей. Это так называемая 6DOF задача, т.е. задача с шестью степенями свободы. Сначала можно подумать, что раз у коптера имеется 6 степеней свободы, то должно быть и 6 переменных состояния (дифференциальных переменных). Но это так только на первый взгляд. Кроме скоростей, дальше нам придется получить еще и координаты (три линейных и три угла положения в пространстве) для чего еще раз проинтегрировать скорости. Таким образом, всего у коптера есть 12 степеней свободы. А если учесть еще то, что правые части дифференциальных уравнений есть ни что иное как ускорения коптера по осям, то получим как бы 18 степеней свободы. Это важно понимать, так как в дальнейшем для построения регулятора нам потребуются все 12 фазовых координат объекта плюс ещё 6 измеренных (или вычисленных) ускорения коптера.

3.1 Решение дифференциальных уравнений методом структурного моделирования

Для решения дифференциального уравнения методом структурного моделирования используются либо типовые звенья первого и второго порядков если дифференциальное уравнение линейно и подходит под один из типов, либо используется блок типа Интегратор, на вход которому подаётся правая часть уравнения, а на выходе будет искомая интегральная величина. Приведём пример заготовку для решения нашей системы из 6-ти дифференциальных уравнений, см. рисунок 2.

На рисунке 2 представлена основа динамической части модели октокоптера, которую формируют 6+3+3 блоков типа интегратор. Первые шесть блоков, получая на вход правые части дифференциальных уравнений (вычислим их ниже) ускорения коптера по осям , занимаются интегрированием и вычислением скоростей коптера по этим же осям (тоже, в связанной с коптером системе В).

Следующие три интегратора принимают линейные скорости в системе координат I (полученные алгебраически из скоростей в системе B путём применения матрицы поворота) и, интегрируя их, получают координаты центра масс коптера в инерциальной системе координат

И, еще три блока типа интегратор занимаются вычислением углов ориентации коптера, интегрируя их производные (угловые скорости) в системе I, полученные из угловых скоростей коптера в системе B применением матрицы . Здесь же реализовано и вычисление нужных тригонометрических функций от углов поворота.

Рисунок 2. Структура модели октокоптера

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

Если бы у нас была более простая ситуация одно дифференциальное уравнение второго порядка (классический второй закон Ньютона a = F/m), например в проекции на ось x, то его решение таким же способом выглядело бы как на рисунке 3:

Рисунок 3. Двойное интегрирование

В случае коптера используется такой же приём, т.е. если на выходе из интегратора имеется какая-то величина, то слева от него обязательно производная этой же величины. Таким образом записываются и решаются дифференциальные уравнения методом структурного моделирования, если не прибегать к встроенному языку программирования SimInTech (где зачастую удаётся сделать то же самое еще более просто, но менее очевидно).

В субмодели W(B->I) реализована матрица преобразования из угловой скорости в системе B в производные углов Эйлера, см. рисунок 4 и [1] для подробностей.

Рисунок 4. Матрица

3.2 Правые части уравнений модели коптера

Для замыкания модели необходимо посчитать и реализовать все правые части у шести основных уравнений, то есть спроецировать полученные в разделе 2 векторные уравнения на оси и результат нарисовать в схеме SimInTech. Опуская выкладки (их читатель может выполнить самостоятельно на листке бумаги, или при помощи какого-то символьного математического ПО), приведем окончательный вид уравнений. Из-за громоздкости, приводить будем по слагаемым в правых частях.

Сила тяги винтомоторных групп

где сила тяги i-ой ВМГ в текущий момент времени.

Сила сопротивления воздуха при отсутствии ветра формулы приведены выше, проекции будут равны:

$$display$$F_{Dx}(t) = 0.5 \cdot \rho \cdot C_D\cdot A_{yz}\cdot v_x\cdot |v_x|,\\ F_{Dу}(t) = 0.5 \cdot \rho \cdot C_D\cdot A_{xz}\cdot v_у\cdot |v_у|,\\ F_{Dz}(t) = 0.5 \cdot \rho \cdot C_D\cdot A_{xy}\cdot v_z\cdot |v_z|.\\$$display$$

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

И последнее слагаемое в уравнении линейной скорости коптера векторное произведение скоростей:

Если аккуратно подставить полученные проекции в уравнение для производной линейной скорости коптера, и дальше реализовать всё это в SimInTech, по осям, получим следующие структурные схемы, представленные на рисунках 5, 6 и 7 (показаны проекции только на ось , на другие оси результат аналогичен с точностью до слагаемых):

Рисунок 5. Линейное ускорение коптера по оси .

Рисунок 6. Сила тяги ВМГ по оси .

Рисунок 7. Сила сопротивления воздуха по оси .

Итого, на данном этапе мы до конца реализовали одно из шести основных уравнений (согласно рисунку 2 вычислили вход в первый интегратор). Остальные оборванные там входы для сил вычисляются аналогично. Рассмотрим уравнение для моментов и для вычисления угловой скорости, а точнее его слагаемые в правой части:

Сумма моментов сил тяги всех ВМГ:

где сила тяги i-ой ВМГ в текущий момент времени, -плечи сил (длины лучей рамы коптера для нечетных и четных ВМГ).

Момент сопротивления воздуха (при отсутствии ветра):

Векторное произведение угловой скорости на произведение тензора инерции и угловой скорости:

Итого, после подстановки этих слагаемых в дифференциальное уравнение для угловой скорости, и реализации полученного в среде SimInTech, получим следующие структурные схемы:

Рисунок 8. Угловое ускорение коптера вокруг оси .

Рисунок 9. Момент сил тяг ВМГ вокруг оси .

Рисунок 10. Сила сопротивления воздуха при вращении вокруг .

3.3 Система уравнений динамики октокоптера в структурном виде

Итого, если представить все реализованные уравнения рядом на схеме, получим следующую картину (рисунок 11). Как видно, она довольно громоздка, даже без включения сюда других дифференциальных уравнений для вычисления координат коптера и углов поворота. А поскольку в дальнейшем на каждое уравнение будут навешиваться еще дополнительные сервисные вычисления (ускорений, различных составляющих сил и моментов, для отладки модели и регуляторов), целесообразнее эти уравнения структурно разделить на 6+ субмоделей, что и было сделано, в каждой из которых решается своё уравнение, см. рисунок 12.

Рисунок 11. Уравнения динамики коптера в связанной системе координат В.

Рисунок 12. Модель динамики коптера, верхний уровень.

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

Входными величинами здесь являются силы тяги двигателей (они считаются вне этих уравнений, в зависимости от текущей скорости вращения каждой ВМГ и её силовой характеристики), внешняя возмущающая сила и момент сил (задаются пользователем произвольно) и сила тяжести. Также, возможно ещё влияние ветра/прецессия/реактивный момент или что-то ещё в настоящей статье это не рассматривается, для краткости мы ограничились силами тяги двигателей и притяжения Земли.

Выходными величинами являются ускорения, скорости и положение (координаты) коптера ускорения и скорости в системах координат B и I, положение в системе I (положение коптера в системе B практической ценности почти не имеет т.к. сама система движется вместе с коптером и совпадает по положению с ним то есть там положение коптера всегда будет нулевым).

В продолжении мы рассмотрим создание системы управления для октокоптера, а так же рассмотрим принципы создания видеокадров управления.

Модель коптера, рассмторенную в статье, можно взять по этой ссылке.

Список литературы

1. Design, Modeling and Control of an Octocopter, Oscar Oscarson, Royal Institute of Technology 2015
2. Development, Modelling and Control of a Multirotor Vehicle, Markus Mikkelsen, Ume University 2015.

Сап, котятки.

Я пришёл рассказать о проекте UAVCAN новом сетевом стандарте для организации взаимодействия узлов и компонентов современных транспортных средств с высоким уровнем автономности/автоматизации. Название является акронимом от Uncomplicated Application-level Vehicular Communication And Networking (несложные бортовые сети и коммуникации уровня приложения).

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

Конъюнктура

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

Мы наблюдаем быстрый рост сложности бортовых систем, связанный с развитием функциональных возможностей транспортных средств (особенно беспилотных) в целом, и систем автоматического управления в частности. Когда мы говорим "бортовая система", мы подразумеваем совокупность автоматики, необходимой для реализации базовых функций транспорта; например, БСУ/ЭДСУ летательных аппаратов, всевозможные ЭБУ в автомобиле, полётный контроллер в дроне или космическом аппарате, сенсоры (радары, камеры), датчики, исполнительные механизмы, и т.п.

Бортовая электроника (электрика) автомобиля конца 20-го века может быть исчерпывающе описана довольно тривиальной схемой; вот, например, схема ВАЗ 21099:

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

Сегодняшние транспортные средства являются в значительной мере программно-определяемыми в том смысле, что существенная часть функциональности и поведений задаётся не столько электрической/механической конфигурацией, сколько программным обеспечением (ПО), что порождает соответствующий перекос концептуальной сложности в сторону бортового ПО. В контексте космических аппаратов это обстоятельство было подмечено ещё инженерным коллективом NASA, работающим над программой Аполлон. В равной мере это применимо и к современным автомобилям (показательна известная история ранней Tesla Model 3, где проблемы антиблокировочной системы были исправлены удалённым накатыванием обновлений без участия владельцев), и к летательным аппаратам (в особенности с ЭСДУ).

Абстракции позволяют нам обойти когнитивное ограничение на количество сущностей, единовременно удерживаемых в сознании. В теории систем этот принцип известен как "чёрный ящик". Любой человек, хоть раз державший в руках компилятор, знает, как это работает: сложные подсистемы описываются не непосредственно, а в виде ограниченных функциональных блоков со строго определённым интерфейсом, скрывающим их реализацию. В рамках дискурса общих информационных технологий безусловно делается предположение, что человеку, мыслящему на определённом уровне абстракции, нет нужды вникать в специфику реализации задействованных на данном уровне блоков, иначе нарушается принцип чёрного ящика. Это предположение не является безусловно корректным если речь идёт о критических системах, где необходима высокая живучесть/отказоустойчивость. Объясняется это тем, что второстепенные функциональные особенности различных компонентов в совокупности могут порождать потенциально опасные непредусмотренные поведения (как это демонстрируют былинные отказы Mars Climate Orbiter, Airbus A400M в Севилье, Ariane 5, и т.п.).

Растущая сложность бортового оборудования отражается в развитии стандартов безопасности. Более сложные системы создаются композицией более сложных подсистем, что формирует спрос на конкретные гарантии поведенческих характеристик компонентов (если у нас есть, скажем, радар, мы хотим точно знать, в каких условиях и как он будет работать, как его характеристики коррелируют с параметрами среды, и вообще неплохо бы убедиться, что его разработчики мышей ловят). Примером ответа индустрии на этот запрос будет концепция Safety Element out of Context (SEooC), введённая в новом автомобильном стандарте ISO 26262. Строго говоря, тема стандартизации не имеет прямого отношения к нашему сугубо техническому проекту, но она отражает общие тренды в индустрии к переходу к композициям более сложных компонентов и как следствие, более сложных интерфейсов.

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

Здесь следует внести разъяснения касательно специфики реального времени и высокой надёжности для читателя, не являющегося специалистом в этой области. Разработчик прикладного ПО, веб-сервера или типичной бытовой встраиваемой системы (вроде компьютерной периферии) сочтёт покрытие тестами достаточной гарантией адекватности ПО. Проблемы реального времени в сложных системах такого рода возникают редко, а когда они возникают, цена временных отклонений обычно достаточно мала, чтобы можно было пренебречь жёстким ресурсным планированием или формальным анализом планировки задач (schedulability analysis). Процессы жёсткого реального времени обычно либо просты, либо цена ошибки несущественна (в качестве примера бытового жёсткого реального времени можно принять логику работы печатающей головки струйного принтера, привод экструдера 3D печати или аудиокодек). Эмпирические методы в целом преобладают над формальными; повсеместно применяется бенчмаркинг и амортизационный анализ. Если продукт показывает приемлемые результаты в подавляющем числе случаев, он принимается соответствующим требованиям; более строгие подходы обычно нецелесообразны финансово.

Разработчик критических систем транспортного средства имеет дело с иным балансом стоимости создания ПО и потенциального ущерба от последствий его сбоев (это верно даже в случае средств микромобильности и малых БПЛА). Большинство таких систем работают в реальном времени, где несвоевременное исполнение задачи эквивалентно неисполнению. Изменение баланса стоимости оправдывает увеличение вложений в средства обеспечения функциональной безопасности с целью снижения эксплуатационных рисков. Как следствие, доказательные методы, верификация и валидация, широко распространены.

Говоря о балансе проектировочных затрат и рисков, интересная тенденция сейчас имеет место в космической отрасли: как метко отмечает Casey Handmer, наблюдаемое ныне снижение стоимости вывода космических аппаратов (КА) сдвигает оптимальный баланс в сторону решений с менее строгими гарантиями безопасности и менее затратной разработкой. В случае же БПЛА наблюдается обратный тренд ввиду распространения более ответственных применений и увеличения числа аппаратов в эксплуатации.

Различные исходные предпосылки при создании систем разного уровня функциональной безопасности проявляются в, порою, радикально различных технических свойствах их компонентов и предпочитаемых методах их создания. Скажем, бортовая коммутируемая сеть современного авиалайнера (как AFDX) предоставляет гарантированные минимальные кривые обслуживания, и, как следствие, для хорошо спланированного трафика отсутствует потребность в подтверждении доставки. Для типичной коммерческой системы эта логика чужда, ведь свойства сети и её загрузку никто не гарантирует. Асимптотический анализ в рамках жёсткого реального времени сфокусирован на худшем случае нежели амортизированном случае, что порою может радикально менять подходы на всех уровнях проектирования.

Различия в предпосылках также объясняют, почему прекрасно зарекомендовавшие себя в ИКТ решения (тысячи их: очереди сообщений, фреймворки, сетевые стеки с TCP/IP во главе, распределённые БД, операционные системы, etc.) обычно непригодны для ответственных применений и почему безопасные системы часто отдают предпочтение специализированным технологиям.

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

Обычный порошок

Картина положения дел в индустрии будет неполной без хотя бы поверхностного рассмотрения существующих технологий построения отказоустойчивых распределённых систем реального времени. Решения эти обычно интересны технически, созданы с оглядкой на многолетний опыт и проверены временем в реальных продуктах. Однако, тем не менее, горшки CiA/SAE/RTCA/EUROCAE/AUTOSAR/OMG/etc. обжигают отнюдь не боги.

Технологии мы поделим на категории по уровню абстракции коммуницируемых состояний и потенциала к созданию сложных систем. Эта модель игнорирует тонкости и в граничных случаях может быть некорректна, но она справляется с главной задачей: объяснением общего положения дел и демонстрацией рассогласования между запросами индустрии и доступными решениями. Пойдём от простого к сложному.

1. Аналоговые схемы

Просто и прямолинейно. Электрические, пневматические, гидравлические, механические средства непосредственного взаимодействия между узлами и компонентами попадают в эту категорию. Приведённая ранее схема ВАЗ 21099 тоже отсюда.

Базовым примитивом межкомпонентного взаимодействия здесь будет аналоговый или дискретный сигнал представленный напряжением/током в электрической цепи, давлением в линии, натяжением троса, и т.п.

2. Логическая шина

Шина данных есть довольно общий термин. Мы здесь под этим подразумеваем модель взаимодействия, где атомарной единицей данных является структура из логически связанных сигналов/параметров, и внимание проектировщика в значительной мере сосредоточено на определении этих структур и логики их обмена.

Следует разделять топологию физическую и логическую: методы соединения узлов и пересылки пакетов не имеют отношения к потокам данных на уровне приложения. На физическом уровне мы выделяем три ключевые топологии: точка-(много)точка, физическая шина и коммутируемая сеть, любая из которых может использоваться для построения логической шины.

Начнём с первого. Если компонент А непрерывно сообщает компоненту Б больше одного параметра, имеет смысл временное разделение (мультиплексирование) сигналов. Такое уплотнение позволяет наращивать число параметров при постоянном числе физических межкомпонентных соединений, что удешевляет/облегчает конструкцию. Практическим примером будет ARINC 429 древний и незамысловатый авиационный протокол, реализующий обмен фиксированными 18-битными словами с щепоткой метаданных по выделенным (некоммутируемым) линиям. Типичная топология выглядит так:

Диаграмма адаптирована из "The Evolution of Avionics Networks From ARINC 429 to AFDX", Fuchs, 2012.

ARINC 429 довольно атипичен как бортовая шина тяжело привести другой пример использования физической топологии точка-многоточка (хотя причастные к малым дронам могли бы вспомнить здесь DShot и MAVLink; последний изначально предназначен для беспроводной связи с наземной станцией, но иногда применяется для внутрибортовой коммуникации). Этот подход имеет особый смысл в простых критических системах жёсткого реального времени, потому что временные свойства процесса доставки сигнала от отправителя к получателю абсолютно очевидны и не требуют сложного анализа. Среда передачи не разделяется с другими компонентами, поэтому нет нужды оценивать вклад каждого в загрузку среды и результирующие побочные эффекты. Однако, этот метод не масштабируется и делает логику взаимодействия сильно зависимой от физических параметров сети (если к компоненту не потрудились пробросить кабель при проектировании, соответствующих данных он никогда не получит).

Широкое распространение получила шинная топология (мы говорим о физическом уровне, не забывайте). Вероятно, CAN не нуждается в представлении; на нём основано множество протоколов и стандартов верхнего уровня. Здесь же FlexRAY, LIN, MIL-STD-1553 и ранние стандарты Ethernet (современный Ethernet используется только в коммутируемой конфигурации).

CAN показателен в контексте реакции отрасли на рост сложности продукции. Введённая в 1986 первая версия стандарта предлагала крайне ограниченный MTU в 8 байт на пакет. В 2012 появился CAN FD с MTU в целых 64 байта и увеличенной пропускной способностью. С конца 2018 года в активной разработке находится CAN XL с MTU 2 КиБ и ещё чуть более высокой скоростью (начало ISO стандартизации запланировано на 2021 год).

Говоря о физических шинах, нельзя не вспомнить интереснейшее начинание под названием Wireless Avionics Intra-Communications (WAIC). WAIC предлагает повысить отказоустойчивость бортовых критических сетей введением гетерогенной избыточности, где резервным каналом станет беспроводной. В целом, беспроводные бортовые сети можно считать фундаментально менее надёжными, чем бортовые проводные/оптические, ввиду слабого контроля за состоянием среды обмена (эфир один на всех). Однако, в совокупности с традиционными сетями, беспроводные позволяют поднять отказоустойчивость из-за устранения отказов общего вида, свойственных проводным сетям, ведь механическое повреждение элемента конструкции может с высокой вероятностью повредить все избыточные проводные соединения:

Диаграмма с сайта WAIC.

Физическая шина размещает всех участников на едином сегменте сети, что создаёт проблемы масштабируемости, ведь все узлы вынуждены организовывать обмен внтутри общего домена коллизий. Сложные транспортные средства на острие прогресса (скажем, современные авиалайнеры и космические аппараты) не в состоянии организовать работу систем в пределах ограничений существующих физических шин, поэтому в ход идут коммутируемые сети. Из значимых следует вспомнить SpaceWire (чрезвычайно узкоспециализированная технология; насколько мне известно, совершенно не представлена вне КА) и, конечно, Ethernet.

В современном аэрокосмосе широко применяется коммутируемый Avionics Full-Duplex Switched Ethernet (AFDX) как на стомегабитной медной паре, так и на оптике (см. Boeing 787). Несмотря на передовой физический уровень, логически это всё тот же ARINC 429, где физические соединения точка-точка заменены их виртуальными репрезентациями. Это решает проблемы масштабируемости, но не предоставляет новых инструментов проектирования логики. Сети AFDX проектируются со статическим планированием обмена с применением автоматических доказательств, что позволяет получить гарантированные временные характеристики доставки несмотря на привнесённые коммутацией сложности. Широко применяется полное дублирование сетевого аппаратного обеспечения (коммутаторов и кабельной системы) для отказоустойчивости. Ниже показан пример физической топологии AFDX подсети космического аппарата с дублированием; при этом логическая сеть ARINC 429, построенная поверх (не показана), определяется конфигурацией ПО коммутаторов вместо физической конфигурации кабельной системы:

Диаграмма из "Communications for Integrated Modular Avionics", Alena, 2007.

Гарантированные параметры сети объясняют почему в сетях жёсткого реального времени редко применяется подтверждение доставки. Вторая причина в том, что процессы реального времени часто предполагают сторого периодический обмен данными, где затраты времени и ресурсов сети (которые, замечу, под строгим учётом) на отправку подтверждения или второй копии данных оказываются неоправданными из-за скорой отправки очередного пакета с более новыми данными в рамках естественного течения процесса. Поэтому, в частности, AFDX построен на (слегка модифицированном) протоколе UDP/IPv4. Использование классических "надёжных" протоколов вроде TCP/IP в подобной среде было бы не просто излишним, а контрпродуктивным они несовместимы с особенностями процессов реального времени.

Общая характеристика рассмотренных технологий и построенных на их основе высокоуровневых протоколов заключается в их ориентированности на организацию низкоуровневых сценариев взаимодействия, где фокус внимания проектировщика сосредоточен на группах определённых параметров и их пересылке между конкретными аппаратными и программными компонентами. На логическом уровне мы всё так же имеем дело со жгутами виртуальных проводов, как на схеме ВАЗ 21099. Подобно тому, как рост сложности решений заставил индустрию ИКТ пережить несколько смен парадигмы за последние десятилетия, подходы к построению архитектуры распределённых бортовых систем претерпевают изменения под давлением спроса на автономность и автоматизацию транспортных средств. В 2020 мы наблюдаем первые симптомы несостоятельности традиционных методов и попытки к переходу на качественно более мощные средства, о чём будет следующий раздел.

3. Распределённые вычисления

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

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

Пожалуй, наиболее значимым на сегодня примером такого подхода будет граф распределённых вычислений из Robot Operating System (ROS) (строго говоря, ROS не является операционной системой, это скорее высокоуровневый фреймворк). Изначально ROS был создан в качестве SDK для окологуманоидного робота PR2 от Willow Garage, но исследователи быстро увидели потенциал фреймворка в других робототехнических системах (от пылесосов и манипуляторов до БПЛА и робоавтомобилей), и он превратился в самостоятельный проект. За несколько лет вокруг ROS развилась богатая экосистема программного обеспечения, решающего многие типовые задачи вроде компьютерного зрения, локализации и картографирования, взаимодействия с аппаратным обеспечением, и т.п. Если изначально фреймворк создавался для исследовательских задач, то интенсивное развитие его экосистемы (и отрасли в целом) со временем поставило вопрос о продуктизации и трансфере наработок из лабораторий в полевые условия, с чем возникли значительные трудности.

Пример визуализации распределённых процессов на ROS. На схеме показан фрагмент системы управления автономного БПЛА в режиме программно-аппаратного моделирования. Овалы обозначают процессы, прямоугольники и стрелки обозначают связи издатель-подписчик.

Описание полного спектра проблем продуктизации основанных на ROS изделий приведёно в статье Why ROS 2 [Gerkey], которая, как нетрудно догадаться из названия, решительно предлагает выпустить вторую версию с оглядкой на новые потребности индустрии. Одной из ключевых проблем здесь является неспособность изначально исследовательского фреймворка удовлетворить радикально более жёсткие требования продуктовых систем к предсказуемости и гарантиям безопасности, которые зачастую обусловлены не только коммерческим интересом, но и законодательным регулированием (особенно в случае автомобильной или аэрокосмической отрасли). Коммуникационная подсистема ROS, обеспечивающая межкомпонентные взаимодействия, является одной из наиболее критических и сложных частей фреймворка. В первой версии использовалась собственная реализация, созданная с нуля, принципиально несовместимая с ответственными применениями, из-за чего во второй версии в роли коммуникационной подсистемы использовали популярное готовое решение Data Distribution Services (DDS).

DDS является сильно отдалённым потомком CORBA, ориентированным на реальное время и модель издатель-подписчик (с недавних пор предлагается также встроенная поддержка клиент-серверных взаимодействий, но на практике первый тип наиболее востребован). DDS широко применяется не только в транспорте и робототехнике, но и в промышленности вообще, зачастую выступая в роли выделенного коммуникационного слоя (собственно, как в случае ROS 2) для вышележащих технологий. Особого упоминания здесь заслуживает Future Airborne Capability Environment (DDS FACE) для критической авионики; однако, на сегодняшний день, большая часть реальных применений DDS в аэрокосмосе приходится на немногочисленные военные системы, которые не следуют гражданским стандартам безопасности.

Как было упомянуто, DDS дальними корнями уходит в CORBA оба стандарта поддерживаются одной организацией. Последняя изначально не предназначалась для систем реального времени, но отраслевые реалии заставили исследователей начать рассматривать вопросы её адаптации для реального времени ещё в конце прошлого века. В работе "The Design of the TAO Real-Time Object Request Broker" [Schmidt et al, 1999] большое внимание уделяется тому факту, что проектирование адекватной сети реального времени самой сетью не ограничивается обязательному анализу подлежат вопросы реализации логики протокола на конечных узлах с соблюдением временных гарантий. В разрезе CORBA синопсис рассматриваемых проблем приведён ниже; эти же принципы легко переносятся на практически любую современную технологию того же толка:

Цифрами обозначены ключевые аспекты реализации, где предписан анализ временных характеристик внутренних алгоритмов протокола. Диаграмма из "The Design of the TAO Real-Time Object Request Broker", Schmidt et al, 1999.

Шмидт с коллегами воплотил идеи в популярной ныне C++ библиотеке TAO (The ACE ORB), которая легла в основу некоторых современных реализаций DDS. Сама по себе TAO насчитывает более двухсот тысяч строк кода без учёта специфики DDS, которая привносит ещё дополнительный код сверху. Из более современных и независимых от TAO инкарнаций DDS упомяну, пожалуй, наиболее многообещающую на сегодня eProsima Fast-DDS (это оценочное суждение, а не реклама) без сторонних зависимостей и тестов она занимает более трёхсот тысяч строк C++ кода (и реализует при этом не все опциональные возможности стандарта). Эти сведения приведены с целью иллюстрации порядка концептуальной сложности DDS.

Как нетрудно догадаться из вышеизложенного, DDS также отличается высокими требованиями к вычислительной платформе, что помимо прочего ограничивает использование во встраиваемых системах. Конкретно эта проблема отчасти решается специализированным подмножеством DDS For Extremely Resource Constrained Environments (DDS-XRCE). Но, согласно нашей модели, это решение уже выходит далеко за пределы концепции распределённых вычислений в силу своей глубокой зависимости от центрального координирующего агента и ограниченной функциональности. Для рассматриваемого здесь вопроса эта технология большой ценности не представляет и рассматривать мы её не будем, равно как мы обойдём стороной и связанный проект micro-ROS.

Из других решений есть смысл поверхностно упомянуть SOME/IP часть автомобильного стандарта AUTOSAR v4+, предлагающую сервисы построения распределённых систем поверх стека IP. В отличие от DDS, SOME/IP сфокусирован исключительно на автомобильных применениях и оперирует существенно более низкоуровневыми концепциями со слабой сегрегацией по уровням абстракции. В совокупности с довольно вольготным обращением с распределёнными состояниями (об этом поговорим далее) и значительным логическим зацеплением между коллабораторами это вызывает вопросы о будущем SOME/IP при наличии сильного конкурента в лице DDS.

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

Высокая внутренняя сложность существующих технологий распределённых вычислений обусловлена широким спектром поддерживаемых сценариев и типов взаимодействия, лишь малая часть которых актуальна для интересующей нас области применений. Мы полагаем, что это утверждение верно даже для специализированных решений (как SOME/IP), чья архитектура может подлежать улучшениям путём целостного пересмотра подходов к проектированию бортовых распределённых систем. Аккуратное переосмысление основных требований к коммуникационной подсистеме позволило нам достичь более взвешенного баланса между внутренней сложностью (и, как следствие, стоимостью валидации и верификации и обеспечения гарантированных характеристик) и доступными инструментами построения мощных абстракций.

Наш подход

Мы едим нашу собаку уже не первый год, и только сейчас подобрались к выпуску первой долгосрочно стабильной версии стандарта, которую мы называем UAVCAN v1. Этому эпохальному для нас событию предшествовали исследования и экспериментальные развёртывания в реальных системах, на протяжении которых менялись наши методы, но не менялись ключевые цели:

1. Простота понимания и реализации. Как было показано выше, это исключительно важно для критических систем. Протокол масштабируется согласно сложности использующего его компонента распределённой системы (т.е., аппаратного узла или программы): в простых компонентах совместимая реализация протокола должна умещаться в одну тысячу строк; в очень сложных она может расти до пары десятков тысяч строк.

   
   

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

   
   

3. Отказоустойчивость. Протокол реализует одноранговую децентрализованную сеть со встроенной поддержкой избыточности. Обеспечивается совместимость с ненадёжными сетями реального времени, где возможны потери пакетов в результате деструктивных воздействий среды (например, электромагнитная интерференция), но не самой сети (например, переполняющийся буфер).

   
   

4. Предсказуемость. Протокол изначально спроектирован для задач реального времени и для использования во встраиваемых системах от младших однокристалок без ОС с единицами КиБ памяти до мощных компьютеров под управлением сложных ОС, причём не обязательно реального времени. Поддерживаются средства высокоточной синхронизации времени в пределах сети для нужд распределённых контуров управления. Ресурсный потолок всегда тривиально предсказуем и доказуем.

   
   

5. Открытость. Это не техническое требование, а юридическое, но это не делает его менее значимым. Невозможно обеспечить серьёзные внедрения закрытой технологии, если существенная часть отрасли живёт открытыми стандартами и открытым ПО. Этот пункт подразумевает свободное распространение всей документации и кода под разрешительными лиценизиями (CC BY, MIT) без обязательных членских взносов.

   
   

В части погони за простотой как одной из ключевых характеристик можно усмотреть реминисценции известного в определённых кругах алгоритма распределённого консенсуса Raft, чьи создатели точно так же, как и мы, начали с вопроса о том, как сделать сложные вещи простыми. Хотя область их деятельности не имеет ничего общего с нашей, они, как и мы, в конечном итоге решали проблему восприятия, где единственной гарантированно достоверной метрикой является человеческий опыт. В отличие от авторов Raft, мы не проверяли трудность понимания наших спецификаций на больших массах людей (N.B.: они показали видео-лекцию 43-м студентам и потом оценили понимание при помощи теста, сравнив результаты с конкурирующей технологией). Однако, у нас есть вот такое практическое свидетельство, где господин зашёл с улицы и сделал минимальную реализацию UAVCAN с нуля за "пару недель" (с его слов):

Желающие увидеть код найдут его на гитхабе как libuavesp. Я, обратите внимание, умываю руки мы к этой реализации отношения не имеем. Заявление автора о том, что "UAV" в названии "UAVCAN" имеет отношение к БПЛА, не соответствует действительности и вызвано банальным недоразумением.

Как нетрудно догадаться из предваряющей этот раздел вводной, UAVCAN широко заимствует ценные принципы из флагманов современной индустрии, в первую очередь опираясь на ROS, DDS, AFDX, WAIC и множество высокоуровневых CAN протоколов, которые даже нет смысла здесь перечислять. Однако, вопросы организации распределённых вычислений одними транспортными протоколами, очевидно, не ограничиваются, особенно если учесть заявленную в ключевых целях потребность в "высокоуровневых абстракциях". UAVCAN удобно рассматривать в виде трёхуровневой модели (мы намеренно игнорируем семиуровневую модель OSI ввиду её чрезмерной детализации):

• Уровень приложения. На этом уровне представлены общие для всех бортовых систем функции: мониторинг состояния, логирование, передача файлов, управление конфигурацией, телеметрия, и т.п. На этом же уровне создаются специализированные сервисы согласно потребностям конкретного приложения. В распоряжении пользователя два вида взаимодействий: анонимный статически типизированный издатель-подписчик и статически же типизированный удалённый вызов процедур с явной адресацией (т.е. не анонимный).

  
  

• Уровень представления отвечает за маршалинг доменных объектов в связях издатель-подписчик и при удалённом вызове процедур. Этот уровень реализован средствами специального предметно-ориентированного языка, на котором даётся строгое определение типов данных для сетевого обмена: Data Structure Description Language (DSDL). На основе DSDL-дефиниций можно автоматически генерировать код (можно и не автоматически).

  
  

• Транспортный уровень занимается доставкой объектов согласно связям издатель-подписчик и удалённым вызовам процедур. Этот уровень намеренно сильно изолирован от вышележащих двух, что позволяет нам определить несколько транспортов поверх различных нижележащих протоколов:

  
  
  • UAVCAN/CAN работает поверх классического CAN и CAN FD. Вероятно, в будущем также появится поддержка CAN XL, но это не точно.
  • UAVCAN/UDP работает поверх UDP/IP. По состоянию на 2020-й год, спецификация этого транспорта ещё находится в стадии ранней альфы и может быть изменена до стабилизации (хотя предпосылок к этому нет).
  • UAVCAN/serial работает поверх любого байт-ориентированного протокола (UART, RS-232/422/485, USB CDC ACM) и ещё подходит для хранения дампов в неструктурированных бинарных файлах. Этот транспорт тоже ожидает стабилизации.
  • Поскольку интерфейс между транспортом и верхними уровнями хорошо определён, в будущем возможно добавление новых транспортных протоколов. В числе таковых рассматривается, например, беспроводной IEEE 802.15.4.
  
  

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

Первое из исходных предположений таково: нижележащая транспортная сеть (например, CAN или Ethernet, в зависимости от выбранного транспорта) предлагает хорошо охарактеризованную минимальную кривую обслуживания и нулевую вероятность потерь пакетов при отсутствии неблагоприятных воздействий внешней среды. Последнее означает, что потери не могут возникнуть в результате процессов, протекающих внутри сети, как, например, переполнение буфера на сетевом узле; однако, допускаются кратковременные нарушения, вызванные внешними факторами, как, например, электромагнитная интерференция. Это предположение полностью совместимо с реалиями настоящих бортовых систем, и оно позволяет нам существенно упростить логику протокола. Компенсация потерь ввиду внешних воздействий выполняется путём превентивной отправки дубликатов (только в тех случаях, где требуется). Рассмотрение этого метода даётся в статье Idempotent interfaces and deterministic data loss mitigation. Хотя описанные особенности выглядят чуждыми для традиционных систем, они вполне оправданы для нашей области.

Крайне аккуратное обращение с разделяемым состоянием позволяет нам сильно сократить пространство состояний сетевых узлов в сравнении со схожими решениями. В результате сокращается техническая сложность реализации, упрощается её анализ и тестирование, о чём подробно сказано в официальном руководстве. Сетевой узел UAVCAN делает минимум предположений о состоянии своих коллабораторов; например, если в случае традиционного фреймворка издатель-подписчик обычно выделяется явная процедура установления подписки, где подписчик сообщает издателю о своей заинтересованности в конкретных данных (см. SOME/IP, DDS, ROS, практически все MQ*, etc.), в UAVCAN издатель слепо отправляет данные в сеть, позволяя заинтересованным агентам их принять или проигнорировать.

Последнее обстоятельство создало бы существенные преграды для масштабирования, если бы не широкое использование аппаратной фильтрации пакетов в обязательном порядке. Известные нам другие протоколы (кроме AFDX) необоснованно игнорируют тот факт, что всё современное аппаратное обеспечение для высокоскоростной коммуникации, за исключением лишь некоторых маргинальных представителей, предоставляет мощные аппаратные инструменты автоматической фильтрации. Разумная эксплуатация этого факта позволила нам ввести радикальные упрощения без ущерба функциональности, о чём говорится в статье Alternative transport protocols in UAVCAN.

Очередное исходное предположение заключается в том, что сеть и её участники имеют, в целом, статическую природу. Это следует трактовать трояко. Во-первых, конфигурация бортовых систем редко подлежит радикальным изменениям в полевых условиях, что позволяет нам сэкономить на сложности динамической автоконфигурации в большинстве случаев; это, впрочем, не означает, что полевая реконфигурация невозможна в принципе (она полезна в исследовательских и экспериментальных окружениях), но это означает, что средства реконфигурации вынесены в опциональные части протокола, которые могут быть удалены в интересах упрощения валидации и верификации сертифицируемых отказоустойчивых систем.

Например, динамическое выделение адреса в сети поддерживается опциональным механизмом plug-and-play (впрочем, конкретно для UAVCAN/UDP он не определён ввиду наличия стандартного DHCP). Механизм этот также поддерживает избыточные аллокаторы для отказоустойчивых систем, где консенсус реплик обеспечивается при помощи упомянутого ранее алгоритма Raft.

Второй аспект статичности заключается в предоставлении ресурсного потолка для любой части системы на этапе проектирования. Так, определяемые при помощи упомянутого ранее DSDL типы всегда имеют верхний предел размера любого поля переменной длины, из чего следует, что максимальное время передачи, максимальное время сериализации/десериализации, и, в общем случае, максимальное время обработки всегда можно определить статически. Ниже показано DSDL-определение стандартного типа журнальной записи под именем uavcan.diagnostic.Record, где можно видеть, что максимальная длина сообщения задана явно и ограничена 112-ю байтами (кодировка всегда UTF-8):

# Generic human-readable text message for logging and displaying purposes.# Generally, it should be published at the lowest priority level.uavcan.time.SynchronizedTimestamp.1.0 timestamp# Optional timestamp in the network-synchronized time system; zero if undefined.# The timestamp value conveys the exact moment when the reported event took place.Severity.1.0 severityuint8[<=112] text# Message text.# Normally, messages should be kept as short as possible, especially those of high severity.@assert _offset_ % 8 == {0}@assert _offset_.max <= (124 * 8)     # Two CAN FD frames max

В конце определения видно вспомогательные конструкции, добавленные с целью статической проверки способности двух CAN FD фреймов нести сообщение максимального размера.

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

Третий аспект статичности следует из нашего крайне осторожного обращения с распределённым состоянием (однажды я сделаю себе татуировку на лицо с предупреждением о том, что все болезни идут от взаимодействий с чрезмерным сохранением состояния). Отсутствие явно синхронизируемых состояний между коллабораторами (между издателем и подписчиком или между клиентом и сервером в случае удалённого вызова процедур) позволяет вновь подключенному участнику приступить к выполнению своих задач немедленно, без предварительных процедур регистрации, обнаружения служб, и т.п. Это имеет значение при анализе сценариев отказа, где критическое устройство кратковременно отключается (например, в результате непреднамеренного перезапуска) с последущим повторным присоединением к сети.

Для примера я продемонстрирую сериализацию и публикацию сообщения, определённого ниже, содержащего три константы и два поля. Константы не участвуют в обмене, поскольку они и так известны всем узлам, имеющим доступ к соответствующему определению типа. Поля сериализуются в плоский остроконечный бинарный формат (младший байт идёт первым) примерно как в ASN.1 UPER (другой порядок байт), но с местной спецификой (ценители сериализации данных должны посмотреть мою заметку, где я рассматриваю популярные форматы и сравниваю их с DSDL).

uint16 VALUE_LOW  = 1000uint16 VALUE_HIGH = 2000uint16 VALUE_MID = (VALUE_HIGH + VALUE_LOW) / 2# Рациональная арифметика произвольной точности!uint16 valueuint8[<=100] key  # Динамический массив от 0 до 100 элементов.

Если мы, скажем, присвоим полям значения value=1234 и key=Hello world!, результат в шестнадцатиричной нотации будет следующим:

D2 04 0C 48 65 6C 6C 6F 20 77 6F 72 6C 64 21

Где D2 04 соответствует 1234, 0C длина массива (если бы максимальная длина была более 255 элементов, тут было бы два или четыре байта), и остаток приходится на приветствие.

Публикация сообщения через классический CAN будет выглядеть предельно незамысловато все счастливые CAN протоколы похожи друг на друга (надо ли говорить, что в случае CAN FD всё вошло бы в один кадр):

$ candump -decaxta any(7.925)  vcan2  TX - -  1013373B   [8]  D2 04 0C 48 65 6C 6C A0   '...Hell.'(7.925)  vcan2  TX - -  1013373B   [8]  6F 20 77 6F 72 6C 64 00   'o world.'(7.925)  vcan2  TX - -  1013373B   [4]  21 F9 02 60               '!..`'

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

Колонка со значением 0x1013373B здесь представляет CAN ID, что является битовой маской из нескольких полей с метаданными. Наиболее интересным здесь является значение 0x1337 (4919 в десятичной системе), которое называется идентификатором темы (subject-identifier) в отличие от некоторых более сложных протоколов (как DDS), UAVCAN не поддерживает именованные топики, предлагая вместо них нумерованные темы (похоже на SOME/IP и практически любой протокол поверх CAN). Это значение проектировщик выбирает произвольно, сообразно своим представлениям о системе.

Теперь мы можем повторить упражнение для UAVCAN/UDP на localhost. Wireshark, к сожалению, пока не имеет диссектора для UAVCAN, да и пёс с ним, ведь и так всё ясно:

Дотошный читатель спросит, откуда взялся порт назначения 21303, на что я отвечу, что он вычисляется как сумма идентификатора темы (4919 у нас) и фиксированного смещения 16384. Смещение выбрано таким образом, чтобы сдвинуть порты UAVCAN в эфемерный диапазон с целью минимизации конфликтов. Исходный порт полезной информации не несёт и выбирается произвольно. Нашу полезную нагрузку (D2 04 0C ...) предваряют 24 байта метаданных, добавленных стеком UAVCAN; там содержится информация о приоритете, фрагментах (тут их нет) и последовательном номере сообщения.

Будет ошибкой думать, что внедрение UAVCAN/UDP в обязательном порядке требует полного IP стека. Когда на практике поднимается вопрос об IP стеке, обычно подразумевается TCP/IP, сложность которого несопоставима с UDP/IP. Последний можно собрать с нуля на C в несколько сотен строк, как наглядно продемонстрировал Lifelover в 2011-м году в серии публикаций "Подключение микроконтроллера к локальной сети".

Здесь практические упражнения мы заканчиваем, потому что публикация не об этом. Желающим закатать рукава следует пройти в библиотеку с говорящим названием PyUAVCAN, при помощи которой эти примеры были получены (не будет лишним также заглянуть в руководство).

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

Последним заслуживает рассмотрения уровень приложения. Техническая сторона вопроса прозрачна: пользователь определяет собственные типы с использованием DSDL, затем создаёт соответствующие темы (топики) по мере надобности. Для распространённых задач (мониторинг узлов, файлообмен, логирование, управление конфигурацией, и т.п.) нет нужды конструировать собственные сетевые сервисы, потому что соответствующие определения предоставляются стандартным набором сервисов UAVCAN, из которого можно свободно выбрать необходимые.

Поверх UAVCAN предполагается создание специализированных отраслевых стандартов уровня приложения, примерно как стандартные классы USB существуют поверх ядра USB, как профили CANopen или Bluetooth, или как DDS FACE поверх DDS. Схематически мы это изображаем следующим образом:

Из отраслевых стандартов сейчас в работе один так называемый Drone Standard 15, или DS-015, к которому активно прикладывают руки, среди прочих, компании из Dronecode Foundation. Мы предвидим появление других отраслевых спецификаций в будущем, поскольку UAVCAN сегодня можно встретить далеко за пределами одних только дронов но об этом позже.

Техническая сторона здесь прозрачна, но есть и другая. Сложные распределённые системы требуют дисциплинированного подхода к проектированию сетевых сервисов и их интерфейсов. Контакты с сообществом разработчиков встраиваемых систем показали, что эта аудитория может глубоко разбираться в вопросах, традиционно характерных для их области деятельности (реальное время, операционные системы, связующее ПО, и т.п.), но при этом иметь очень ограниченное представление о проектировании адекватных сетевых сервисов. Накопленный опыт работы с несколько более низкоуровневыми технологиями, по-видимому, подталкивает людей к неуместному заимствованию практик, что неоднократно на нашем опыте приводило к появлению дефектных интерфейсов, работа с которыми наполовину состоит из страдания. Решение этой нетехнической проблемы является столь же нетехническим мы опубликовали учебный материал, где подробно объясняется, как выглядит сетевой сервис здорового человека. Материал этот опубликован в официальном руководстве UAVCAN в главе Interface Design Guidelines.

Внедрение

Прогресс в области вычислительной техники, элементов питания, машинного обучения, генеративного проектирования и других передовых областей порождает новые проекты транспортных систем, которые зачастую реализуются малыми предприятиями при минимальном финансировании и низкой стартовой вовлечённостью в релевантные отрасли. Практические примеры автономных дронов и роботов, электрических конвертопланов, кубсатов, робоавтомобилей, и т.п. в изобилии присутствуют в новостных лентах, так что приводить их здесь нет смысла. Каждое такое средство, будучи передовым продуктом 21-го века, критически зависимо от грамотной огранизации бортовых вычислительных систем, и часто также несёт груз правового регулирования и доказательства функциональной безопасности. Такие проекты неспособны подняться без широкого применения именно открытых стандартов и свободных решений, потому что как коммерческие альтернативы, так и доморощенные велосипеды рискуют не вписаться в бюджет. Стартап, скажем, с летательным аппаратом, намеревающийся следовать стандартам консервативной аэрокосмической отрасли на первом же шаге выложит десятки тысяч евро за PDF документы; в то же время будет ошибкой думать, что внедрение этих стандартов является необходимым или даже желательным условием для успеха.

UAVCAN полностью открыт для распространения и внедрения, не предписывает никаких лицензионных ограничений: вся документация распространяется под CC BY 4.0, а исходный код референсных реализаций под MIT. Вероятно, любой другой подход к лицензированию сегодня обрёк бы проект на забвение.

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

Согласно принципам открытости, вся разработка ведётся в полностью публичной манере на форуме и на GitHub оба этих ресурса вместе содержат не меньше 90% дискуссий разработчиков по существу, так что любое просочившееся в спецификацию решение оставляет перманентный бумажный след. Этот подход радикально отличается от традиционных практик, где обычно предполагается платное членство и участие в закрытых сессиях, закрытых ревью стандартов и закрытых же списках рассылок.

На гитхабе поддерживаются референсные библиотеки, среди которых Libcanard минимальная реализация UAVCAN/CAN для однокристалок на C11, объём кода которой фигурирует в названии этой статьи. Также там базируется uavcan.rs мультитранспортная реализация на Rust, которая по состоянию на июль 2020 ищет нового мейнтейнера.

Там же поддерживается Yukon десктопная программа на питоне-электроне для разработки, отладки и диагностики UAVCAN сетей, представляющая собой смесь RViz, Wireshark и LabView. Раньше у нас была ещё утилита на PyQt для предыдущей экспериментальной версии протокола, но теперь она устарела безнадёжно, и усилия сосредоточены на Yukon. На форуме есть бесконечно длинные треды с обсуждениями, но дальше обсуждений мы практически не продвинулись из-за острой недостачи фронтендеров. На сегодня последнее демо выглядит так:

Некоторый интерес представляет использование API ROS поверх UAVCAN вместо DDS. Смысл здесь в том, чтобы сделать развитую экосистему пакетов ROS доступной в системах реального времени и младших микроконтроллерах с использованием UAVCAN, обеспечив при этом также нативную совместимость с обычными UAVCAN устройствами, ничего не знающими о ROS. Краткая вводная дана в заметке на форуме "An exploratory study: UAVCAN as a middleware for ROS"; разыскиваются коллабораторы.

Среди множества компаний и учреждений, принимающих участие развитии стандарта, следует особо выделить NXP Semiconductors. На недавней конференции они представили неплохой доклад "Getting started using UAVCAN v1 with PX4 on the NXP UAVCAN Board", демонстрирующей, в том числе, кое-какие их новые референсы для UAVCAN приложений.

Не менее ценным партнёром является Amazon Prime Air со своим крутейшим автономным доставочным дроном. Эти господа производят не железо, а код копирайты Амазона щедро разбросаны по нашим исходникам.

Законченное UAVCAN-совместимое железо вроде сервоприводов, приводов электромоторов, системы воздушных сигналов, автопилотов, систем впрыска топлива, всевозможных датчиков и отладочных плат сегодня предлагают многие вендоры, чьё перечисление тут вряд ли оправданно.

Согласно опросу, проведённому в конце 2019 года, а также основываясь на наших личных контактах с интеграторами, UAVCAN сегодня применяется в пилотируемых (~10% компаний) и беспилотных (~80% компаний) летательных аппаратах, в малых космических аппаратах (~5% компаний, на 2020 год на орбите есть около 20 кубсатов, согласно доступным нам данным), в микро транспорте (вроде электросамокатов) и разнообразных робототехнических системах. Наша выборка, впрочем, подвержена систематической ошибке и приводится только в общеинформативных целях; распределение может не соответствовать действительности. Краткая сводка по опросу доступна отдельно.

Статус и будущее проекта

Наша глобальная амбициозная цель-максимум: стать полноценной альтернативой технологиям класса DDS для отказоустойчивых высоконадёжных систем реального времени; стать стандартом де-факто для новых видов интеллектуального транспорта.

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

uavcan.org

Привет! Меня зовут Роман Федоренко, я доцент Центра компетенций НТИ по направлению Технологии компонентов робототехники и мехатроники на базе Университета Иннополис. Я работаю с командой робототехников, которая специализируется на беспилотных летательных аппаратах. По большей части мы занимаемся высокоуровневым управлением БПЛА: планирование движения, обход препятствий, решения для киносъёмки и сканирования местности. Хотя собственные небольшие коптеры тоже собирали и с железом работали. В прошлом году мы начали разработку большого самолёта вертикального взлёта и посадки, который включает все уровни от изготовления носителя до обвески датчиками и интеллектуального управления. И при разработке этого проекта познакомились с UAVCAN.

UAVCAN это открытый лёгкий протокол для бортовой сети подвижных объектов. Недавно его разработчик и мейнтейнер Павел Кириенко Spym рассказал о протоколе на PX4 Developer Summit, крупной конференции сообщества разработчиков дронов с использованием open-source экосистемы вокруг автопилота PX4, частью которой является UAVCAN. А ещё Павел подготовил подробную статью для русскоязычного сообщества на Хабре по следам своего доклада.

В этом материале я расскажу о практической стороне использования протокола с позиции разработчиков систем автоматического управления для БПЛА: как мы выбрали UAVCAN, что делаем с помощью него и какие возможности видим в будущем.

Гибридные БПЛА

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

• полностью электрическое воздушное такси Lilium Jet немецкой компании Lilium;
  
• малошумный электросамолёт Heaviside компании Kitty Hawk Себастьяна Труна (которого многие знают по беспилотным автомобилям);
  
• проект Vahana от Airbus.
  

Самолёт вертикального взлёта и посадки Университета Иннополис

Мы разработали три модели небольших беспилотных аппаратов с разным размахом крыла, грузоподъёмностью и источниками питания полностью электрические и с двигателями внутреннего сгорания. По конструкциям летательных аппаратов сотрудничаем с Казанским авиационным институтом и авиационными предприятиями Казани, а фокус наших работ электроника, алгоритмы и автоматическое управление.

При чём здесь UAVCAN?

Те, кто занимаются коптерами, знают, что обычная структура системы управления выглядит примерно так:


Типовая схема БПЛА на базе автопилота PX4. Источник

Моторы управляются регуляторами оборотов (ESC), на которые посредством PWM (ШИМ) сигналов подаются уставки от автопилота. Датчики подключаются по куче разных интерфейсов UART, I2C, SPI. Плюс телеметрия, пульт, питание и получается такой паук из проводов. Но основная проблема не в этом.

Чем длиннее провода, то есть больше аппарат, тем эта схема сильнее подвержена наводкам. Нам об этом пришлось задумываться с самого начала, потому что у наших аппаратов размах крыльев 2 и 4 метра, и это не предел.

Раньше для проекта 40-метрового дирижабля мы работали с CAN (только протокол был на базе CANOpen). И решение использовать UAVCAN для нас было само собой разумеющимся: в PX4 уже есть его поддержка, даже никаких споров в команде по этому поводу не возникало. Изначально мы хотели заменить длинные линии PWM на цифровой интерфейс, чтобы масштабировать наши решения на аппараты с разным размахом крыла.



Заменив PWM-связи на UAVCAN-связи, мы перестали беспокоиться о проблемах длинных проводов и наводок, а также значительно уменьшили количество подключений к автопилоту.

Было два варианта, как это сделать. Первый использовать регуляторы моторов и сервоприводы с UAVCAN интерфейсом. Такие есть, например, у Zubax. Второй сделать адаптеры UAVCAN, которые устанавливаются непосредственно возле ESC. Мы пошли по второму варианту, потому что выбор ESC с UAVCAN интерфейсом невелик. Сначала мы использовали адаптеры проекта UAVCAN for Hobbyists (UC4H), затем решили делать свои устройства со встроенным DC-DC преобразователем, своей схемотехникой, прошивкой и нескучными диодиками.


Наши устройства с интерфейсом UAVCAN

Вошли во вкус

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

• Преобразователь CAN-PWM до 4 каналов: устройство подключается к шине CAN, принимает и обрабатывает сигналы управления, выдаёт ШИМ. Питать плату можно напрямую с АКБ до 60 В, в её составе включается DC-DC преобразователь, обеспечивающий напряжением 5 В (3 А) плату и потребителя (например, сервомашинку);
  
• GPS/Magnetometer/Barometer;
  
• Силовая плата, Power Management Unit (PMU): обеспечивает подсоединение нескольких АКБ (параллельно или последовательно при необходимости). Устройство подключается последовательно со всей силовой нагрузкой и обеспечивает её коммутацию. В конструкции датчики напряжения и тока на АКБ, DC-DC преобразователь для обеспечения питания автопилота. Такая плата рассчитана на большие токи до 1000 А. В разработке устройство CAN в составе платы выдающее информацию о напряжении и токе;
  
• Лазерный высотомер;
  
• Датчик воздушной скорости;
  
• Датчик уровня топлива;
  

Технически эти устройства реализованы на базе микроконтроллера STM32. Проектируем сами, а изготовление заказываем на pcbway.ru. Прошивка реализуется с использованием libcanard.

По нашим ощущениям для работы с UAVCAN довольно низкий порог входа. Новому сотруднику понадобилось меньше недели, чтобы разобраться и запрограммировать датчик расстояния как со стороны STM32, так и со стороны автопилота PX4.


Новые устройства тестируем на небольшом dark дроне

А затем уже используем на самолёте:


Короткое видео тестового полета нашего VTOL-самолета во всех режимах



В итоге схема у нас выглядит так:


Схема нашего VTOL-самолёта с использованием UAVCAN датчиков и исполнительных механизмов

Какие преимущества UAVCAN даст нам в будущем

Резервирование

Важнейшая задача при реализации продукта на базе БПЛА обеспечить надёжность. Мы уже начали работать над этим. Например, несколько наших GPS и датчиков воздушной скорости подключить и использовать параллельно уже получается. Но ещё многое предстоит. Скорее всего, дублирования датчиков и контроллеров с использованием CAN шины будут сделаны проще. К Pixhawk можно подключить две шины, а на шине оставить несколько одинаковых датчиков для резервирования.

Масштабирование

В будущем мы хотим делать большие аппараты взлётной массой больше 30 кг, хотя это и сложно сертифицировать. Масштабируемость архитектуры на базе UAVCAN позволяет строить амбициозные планы.

True HIL-симуляция

Сейчас активно развивается тема работы БПЛА в городской среде Urban Air Mobility (UAM). Для реализации задач UAM нужно больше опираться на такие сенсоры, как камеры и лидары. Тут возникает необходимость разработки и отладки систем интеллектуального управления, а также повышение их надёжности. Для этих целей другая команда Университета Иннополис разрабатывает симулятор Innopolis Simulator для автономных подвижных объектов на основе Unity 3D для тестирования, отладки и обучения.


Innopolis Simulator

Для нашего VTOL-самолета используем Innopolis Simulator в связке с Gazebo для фотореалистичной симуляции, тестирования управления и обработки сенсорных данных лидаров и камер.

Сейчас работаем над своим модулем симуляции динамики вместо Gazebo с более точной аэродинамикой, а также над другой фишкой true HIL симуляцией (от hardware in the loop, или программно-аппаратное моделирование, ПАМ).

В нашем решении все данные поступают от датчиков, а управления на моторы и сервы отправляются по шине UAVCAN. Почему бы не сделать модуль симуляции этих датчиков на уровне той же шины? Просто вместо устройств к контроллеру мы подключаем компьютер с симулятором.
Сейчас HIL-симуляция в PX4 делается посредством специальных HIL_* сообщений MAVLINK (протокол телеметрии, работает по последовательному порту либо UDP/TCP), которые имитируют датчики и исполнительные механизмы.


Диаграмма работы PX4 в режиме HITL. Источник

Симуляция, как она реализована сейчас в PX4, это отдельный режим работы полётного контроллера, отличающийся от боевой полётной конфигурации. Мы имитируем непосредственно UAVCAN сообщения, в идеале автопилот может даже не знать, что работает в симулируемом окружении. Но нужно сказать, что пока концептуально не решена проблема симуляции IMU, которые находятся внутри автопилота и подключены не по CAN.


Предлагаемая схема работы PX4 в режиме HITL с использованием UAVCAN

Такое решение повышает достоверность результатов отладки на симуляторе, поэтому можно смелее переходить к лётным тестам.


Авиационный HIL симулятор. Источник

Подобный подход, когда устройства имитируются на уровне интерфейсов, используется и в большой авиации, но с UAVCAN мы делаем это доступнее и проще.

Вывод

Очень здорово, что над вопросами лёгкости, надёжности и риалтаймовости протокола UAVCAN уже подумали за нас, как и то, что есть PX4, ROS и Linux, в конце концов. Нам было бы очень сложно делать наши коптеры, самолёты, системы управления и планировщики, если бы всего этого не было.

Стандартизация протоколов и программных средств даёт возможность разработчикам говорить на одном языке. Вместе с тем, важна не только стандартизация, но и доступность, что в высокой степени обеспечивает open-source подход. Это позволяет, стоя на плечах гигантов, быстрее переходить к своим задачам, а не строить сначала долго инфраструктуру для работы, что, надеюсь, мы показали на нашем примере в данной статье.


Пьём колд брю после успешных полётов

Последние события выяснения жителей Вилларибо и Виллабаджо, кто самый главный в Нагорном Карабахе, внимательным и любопытствующим телезрителям и читателям сказали довольно много. Даже если они уже забыли какой у них ВУС.

Некоторое время плавала по морям-окиянам сети интернет байка, что БПЛА могут решить практически любой вопрос на планете сбросив несколько десятков килограмм, на тех у кого БПЛА нет. Это что-то вроде байки о всемогуществе АУГ Соединённых Штатов.

Причем решить этот вопрос без участия даже оператора, а только лишь мощью ИИ. Мол, вот чуть-чуть Т-800 стройными рядами пойдут насаждать демократию и справедливость с приданными им в усиление ДРГ в виде Т-1000.

Нет, сомнений нет, турецкий "Байрактар ТБ2" штука полезная. В нужном месте и в нужное время. Но уж точно не "средство два-в-одном вам избавит от страданий". Мой хороший друг полковник ВС РФ в запасе Владимир Трухан детально в своём журнале пояснил почему. И даже вежливо.

А далее передаю микрофон профессиональному военному ПВОшнику:

Если мне вежливо задать вопрос, то на него я могу и ответить. Даже если этот самый вопрос провокационный, на тему применения в Нагорном Карабахе БЛА/БПЛА и массовой угрозы этого для безопасности России.

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

Если применение беспилотных летательных аппаратов (БЛА/БПЛА) в войсковой операции Азербайджана на территории Нагорного Карабаха, что и доказало, так это то, что в войнушке бедных работает случайно оказавшийся у одного из бедняков девайс, локально приобретающий решающее значение. Например, два миномёта с миномётчиками у племени Матумба в боях с многопротивным племенем Тулумба.

Принципиально с миномётчиками, поелику бедность она не только в вооружении и в военной технике, она ещё в оперативной подготовке штабов и боевой подготовке войск. У Тулумба тоже был злодейский прибамбас (пулемёт системы Максим 3 штуки), но не сложилось с пулемётчиками. А техника (вот девушка с низкой социальной ответственностью такая) самостоятельно ни разу не работает.

Я не оскорбляю сейчас героизм защитников Карабаха (с армянской стороны), я уважаю героев. Просто я в курсе, что героизм появляется после того, когда кто-то где-то вдумчиво накосячил. Например, Генштаб Республики Армения, забивший на разведку и не сумевший обеспечить грамотный количественный и качественный состав сил и средств районов обороны, необходимый и достаточный для ведения войны.

Ладно, к беспилотью перейду; объясняя, почему самостоятельно это не работает. Против сбалансированной по силам и средствам группировки, личный состав которой обучен и готов.

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

Разработчики ИИ не смогут и автомобильчик научить учитывать автодорожное поведение Джамшута на джихад-такси (в погоне за рублём), Элеоноры на насосанном Феррари (в погоне за понтами), а также полупьяного Петровича через Ленинский проспект, на собственных ногах, но поперёк потока (в надежде на бутылку); особенно когда эти три события происходят одновременно и на одном участке полотна.

А теперь мне расскажите про воздушный бой. Или про противовоздушный бой. Или про штурмовку наземных сил. Которые этот самый ИИ проводит самостоятельно, вне запрограммированного естества. А я поржу, причём не в кулачок, а в голос.

Нет, ребятушки, ситуёвина, когда техник Старый Джон или Опытный Семёныч платочком машет с полосы вслед роботу, а потом, по возвращении, в честь его победы, регламент проводит чистым спиртом, а не как обычно, на контакты подышав это из разряда нереального. Вообще. Никогда.

То есть БЛА работают либо по заблаговременно заданной программе, либо по командам оператора с воздуха, с поверхности, не суть. И используются либо как средство тактической и оперативной разведки, либо как средство доставки боеприпаса в заданный район.

Любая программа это шаблон, пусть даже в него прописаны разнообразные алгоритмы. Пусть даже этих самых алгоритмов большое такое число. Поелику вариантов тактических действий всё одно больше, и пытливый ум бойца постоянно их выдумывает, при наличии опыта. И любой военный лётчик второй класс + порвёт любые шаблоны к половым органам. И любой опытный ПВО-шник.

БЛА-разведчик на программе, для стрелка (хоть с воздуха, хоть с земли) это жирная домашняя утка для охотника на диких крякв. Маршрут просчитываем, к противозенитному манёвру не способен Стреляй не хочу. Нет, со скоростью у него по определению не очень фиг что потом увидишь на средствах объективного контроля. То есть живёт он ровно до тех пор, пока на него не обратили внимания. И, если на маршруте интересное где-нибудь вдали от намеченной трассы, то хрен ты что узнаешь о таком. Думать, куда довернуть, БЛА не умеет. И не научится.

БЛА-доставщик боеприпаса на программе А в чём понт? Есть масса полезных дальнобойных вещей, работающих по заранее заданным координатам. Например, крылатые и оперативно-тактические ракеты. Есть артиллерия и РСЗО. Те же бомбардировщики тоже есть.

Не будем забывать, что полезная нагрузка того распиаренного Байрактара всего 150 килограмм (я в курсе, что он не только автономен, но также управляется с земли). Не будем забывать, что масса боевой части ракеты ОТРК Искандер 480 килограмм. И не будем забывать, что ракету Искандера перехватить куда как более напряжно, чем этот самый Байрактар.

Здесь пытливые умы могут мне чего-то рассказать про американцев и их опыт применения подобных БЛА, но об этом немного ниже. Про другое послушайте, ещё более печальное для онанирующих на решающее значение этого вида средств разведки и поражения.

Так вот, смысл БЛА имеют в основном тогда, когда они управляются оператором с поверхности или с воздуха (из космоса пока что нет; там только спутниковая навигация имеется иногда). Тогда БЛА-доставщик имеет преимущество, поскольку у него более длительное, чем у пилотируемых, время дежурства в назначенном районе, следовательно более быстрая реакция на внезапную цель. И в воздушной засаде, типа, посидеть может.

Типа посидеть это потому, что никаких укрытий в небесах не предусмотрено, от пытливого радиолокационного взгляда. И всякую средне- и маловысотную фигню научились засекать уже давно. А навестись на этот тихоходный агрегат так и вовсе не проблема; даже спьяну перепёлку эту в её районе звезданут.

То есть для безопасного барражирования нашему беспилотному ребёнку нужно свободное небо, которое ему хрен кто даст, при противодействии серьёзных пацанов. Это для джихад-арбы проблема потолок восемь тысяч двести, или для ПЗРК. Эшелонированные средства радиолокационной разведки и огневого поражения ВКС и СВ РФ проблему эту решают влёт; истребителям тем просто поразвлечься стрельбой по неподвижной мишени.

С поражением БЛА другая головная боль расход дорогого боеприпаса. Ну хорошо, Байрактар (70 миллионов баксов за комплект) цель финансово достойная, но есть другие, более дешёвые. А зенитные ракеты большинства комплексов нет. Но над этим вдумчиво работают; может новым вариантам Шилки места найдут.

Не спрашивайте за подробности не ко мне. Пока отметьте, что проблема не стоит, чем их бить, эти БЛА; стоит проблема как бы подешевле.

Вторая и основная печаль апологетов БЛА-всесилия открытые каналы управления. Не, они, конечно, шифрованные шо абзац, однако (вот засада) по тем же самым электромагнитным волнам. И радиообмен между оператором и воздушным сандаликом легко засекается средствами РЭБ и так же легко давится, причём для БЛА насовсем. Он потом куда и прилетит, то, стремительно снижаясь, об асфальт. Или о другую какую поверхность.

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

Третья неприятная подробность а боевая эффективность летательного аппаратика с живым пилотом по-любому выше, чем БЛА. Пофиг какого БЛА (по управлению) пусть тот работает хоть автономно, хоть с оператором. Здесь даже распространяться особо не буду, очевидные ведь вещи; тот же обзор. Та же оценка обстановки; и воздушной, и на поверхности. То же время реакции органов управления хоть пилотированием, хоть применением боеприпаса.

А ещё выше полезная нагрузка этих самых летательных аппаратов, что тоже немаловажно для боевого применения. Су-25 имеет тонну четыреста кг нормальной и четыре тонны четыреста кг максимальной боевой нагрузки, если что. Восемь полутонных бомб. Впечатления от подрыва одной такой в нескольких километрах от меня в КШМ помню до сих пор и буду рассказывать даже внукам.

И да, на память: взрослые военные мальчики имеют сбалансированную по силам, средствам, поставленным целям и решаемым задачам группировку ПВО. Специально для сетевых бойцов сообщаю, что эшелон прорыва ПВО у тех же НАТО включает в себя 100-200 самолётов, из которых 60-70 тактических истребителей и штурмовиков, до 30 истребителей сопровождения и 10-12 самолётов РЭБ. Замените, попробуйте, это всё одними БЛА.

Я не придурок, чтобы утверждать, что БЛА, во всех своих конфигурациях, бесполезны. Отнюдь, это эффективное средство разведки и поражения, но исключительно для решения задач в определённых условиях обстановки, и не более того. Также эффективны, для своих условий, миномёты и гранатомёты, артиллерия и РСЗО, самолёты и вертолёты, разнообразные ракеты всех видов и родов войск. Как те же бомбы любых конфигураций. И в некоторых случаях (я вам по секрету расскажу) эффективен даже пистолет.

Те же америкосы употребляют БЛА для разведки или для поражения там, где им стрёмно употреблять ЛА с живыми лётчиками. Например, сбитый над терводами Ирана RQ-4A Global Hawk это набор обломков различной степени побитости; обидно, но не надо вызволять пилота (как в случае с U-2 в СССР) или его труп. А стоит эта беспилотная леталка 220 миллионов долларов, тащемта.

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

И так же, между прочим, они освежают запасы крылатых ракет, уничтожая сотней Томагавков два сарая и бродячую собаку на территории Сирии. Тогда тоже паника, как помню, была, и ликование поперёк-российских аналитиков. Под бодрое ржание меня и моих коллег.

То есть у пиндосов своя метусня (они и ЧВОК поэтому везде используют тоже проблема экономии выплат), у нас своя, у турок и Азербайджана своя. У турок, например, наличие подготовленных пилотов, особенно в рассуждении неудавшегося турецкого военного переворота и последующих репрессий, что были не так давно. У Азербайджана в принципе проблема с авиацией и необходимым количеством средств поражения.

ВС РФ, буде им необходимо, эти районы обороны, типа бывших в НКР, переработали бы на щебёнку и металлолом (с элементами органики) совершенно без использования БЛА и более эффективно. Колонны бронетехники гавкнули бы тоже только в путь. Потому как у нас различные прибамбасы есть, в достаточном количестве.

И подготовленный личный состав есть, и в штабах, и в частях, а не так, как оказалось у Армении. Посему не надо мне рассказывать про уничтоженные средства ПВО российской и советской разработки, что оказались в их распоряжении. Техника кусок металла в руках любого дикаря любой национальности. БЛА в Сирии бармалеи используют уже давно. Жду трагических и увлекательных историй об уничтоженных образцах ВКС РФ.

Да, БЛА тоже имеются, хотя и есть куда расти. Раньше просто этому не придавали особенного значения опять же, в силу наличия разнообразия других девайсов для удалённого убийства. Теперь будут более активно разрабатывать выгоды и ошибки их использования теперь более понятны.

Зато другой суперский беспилотный аппарат есть. Подводный. Посейдон его зовут. От которого спазмы сфинктера у товарищей американцев, вплоть до полной блокировки кишечной проходимости. Это стратегический беспилотный аппарат, способный перевернуть ход и даже решить исход войны. А тактические БЛА ещё одни военные игрушки. Не спорю, эффективные в умелых руках, но принципиально не решающие ничего.

На ход/исход войны они не повлияют.

В этом году Пентагон после полугодичных испытаний сразу после проведенного Кремлем Парада Победы в честь 9 мая (совпадение? нет, не думаю(с)) таки заключил с израильской компанией Xtend контракт на поставку десятков небольших беспилотных летательных аппаратов для использования в помещениях и в городских условиях силами специального назначения ВМС, морской пехоты и армии.

Министерство обороны США заказало Skylord Xtender в партнерстве с Министерством обороны Израиля от имени Управления технической поддержки нерегулярных боевых действий. Xtend не предоставила информации о стоимости контракта.

Давайте подробнее разберемся с данными летательными аппаратами

Skylord Xtender

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

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

Skylord Xtender обеспечивает ситуационную осведомленность с помощью 3D-видео, системы навигации, а также с помощью системы управления жестами и искусственного интеллекта, согласно видео компании.


Беспилотник имеет защиту на своих пропеллерах и может летать около 10 минут. На видео-демонстрациях маленький квадрокоптер парит в 30 сантиметрах от земли и влетает и вылетает из зданий, пролетая через небольшое отверстие размером со средний кирпич. Xtend утверждает, что Начальник Генерального штаба Армии обороны Израиля сам оперировал беспилотником на недавнем мероприятии, и что американские, британские, голландские и сингапурские чиновники видели демонстрации работы дрона.



Базовая технология управления подходит операторам, не имеющим опыта, и дает возможность управлять передовыми беспилотными летательными аппаратами через несколько секунд после обучения. Проблема заключается в том, что у вас нет GPS или освещения в помещении, и у вас может быть мебель или открытые окна с турбулентностью, а также завихрения от воздушного винта и своя физика полета в ограниченном пространстве. Для решения этих проблем Xtend работала с Министерством обороны Израиля и Управлением оборонных исследований и разработок в течение 18 месяцев, а также с Министерством обороны США в течение прошлого года. Партнерство между правительствами позволило фирме получить поддержку и двустороннее финансирование, что привело к относительно быстрому процессу приобретения продукции спецназом США.

Skylord Griffon

Американские военные протестировали актуальные системы борьбы с БПЛА. Существует три вида борьбы с БПЛА.

Попавшие на тесты системы отличаются различными подходами к борьбе с малыми БПЛА. Так, Skylord Griffon представляет собой обычный квадрокоптер, дополненный ловушкой для беспилотников. В полете он несет за собой раскрытую сеть на T-образном каркасе, а при обнаружении цели Griffon пролетает над ней, опутывая сетью пропеллеры беспилотника. Добычу БПЛА может сбросить в определенном месте, и вернуться к оператору для перезарядки. Ранние образцы БПЛА серии Griffon успешно совершили свыше 2500 перехватов малых БПЛА на границе с Сектором Газа.



Система DKD от компании Elta, специализирующейся на производстве радиолокационного оборудования, использует АФАР-радар и набор оптико-электронного оборудования. Это позволяет отслеживать, идентифицировать, и нейтрализовать малые БПЛА с помощью генератора помех.

Modular Intercept Drone Avionics Set (MIDAS) наиболее близка к классическим авиационным перехватчикам. Квадрокоптер оснащенный пневматической пушкой идентифицирует цели с помощью собственных датчиков, или по целеуказанию с наземных радаров. После этого система выбирает оптимальное место для ведения огня, и выводит из строя противника небольшим боеприпасом.

Как видите, пока производители не выбрали максимально эффективный способ противодействия малым БПЛА. Не исключено, что с примитивной угрозой сможет бороться только комплекс средств кинетического и радиоэлектронного воздействия.

Xtend также делает беспилотный летательный аппарат Skylord Griffon, предназначенный для уничтожения других беспилотных летательных аппаратов, что вот совсем недавно продемонстрировали на испытательном полигоне Юма в Аризоне. Эта система уже работает с израильским спецназом. Skylord Griffon представляет собой обычный квадрокоптер, дополненный ловушкой для беспилотников. В полёте он несёт за собой раскрытую сеть на T-образном каркасе, а при обнаружении цели Griffon пролетает над ней, опутывая сетью пропеллеры беспилотника. Добычу БПЛА может сбросить в определённом месте, и вернуться к оператору для перезарядки. Ранние образцы БПЛА серии Griffon успешно совершили свыше 2500 перехватов малых БПЛА на границе с Сектором Газа.



Используя визуальное устройство дополненной реальности (AR) и контроллер, управляемый одной рукой, военный оператор может использовать систему Skylord для легкого и точного управления дроном и выполнения сложных задач. Интерфейс системы позволяет оператору погрузиться в удаленную реальность, эффективно и безопасно поражая цели. Личный состав может получить полную сенсорную оценку ситуации на поле боя и использовать полезную нагрузку дронов-перехватчиков C-UAV, пройдя минимальный инструктаж без необходимости в специальных знаниях. Возможности системы были продемонстрированы в Израиле на перехвате зажигательных устройств, запущенных террористами из сектора Газы.

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

Источники:

1. Pentagon orders small Israeli drones for indoor special operations
2. -13": | "
3. Skylord Keeps Warfighters Safe in the Heat of Battle

Идея робота-убийцы перешла от фантазии к реальности

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

Азербайджан использовал вооруженные беспилотники, чтобы получить крупное преимущество над Арменией в недавних боях за контроль над Нагорно-Карабахским регионом. Только в прошлом месяце израильские силы обороны, как сообщается, использовали беспилотники, чтобы сбросить слезоточивый газ на протестующих на оккупированном Западном берегу.

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




Все с детства знают три закона робототехники. В научной фантастике обязательные правила поведения для роботов, впервые сформулированные Айзеком Азимовым в рассказе Хоровод (1942).

Законы гласят:

• Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
• Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
• Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому или Второму Законам.

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



Каргу-2-это четырехроторный беспилотник, после того, как его программное обеспечение ИИ определило цели, он может автономно лететь на них с максимальной скоростью около 45 миль в час (72 км/ч) и взрываться либо бронебойной боеголовкой, либо той, которая предназначена для уничтожения небронированного целей.

Исходя из доклада, инцидент произошел в ходе столкновений между правительственными силами Ливии и военной группировкой во главе с Халифой Хафтаром, командующим Ливийской национальной армии. Квадрокоптер Kargu-2 работал в автономном режиме, который не требовал вмешательства человека. Это летальная автономная система вооружений, запрограммированная атаковать цели без связи с оператором, говорится в отчете ООН. Автономные боевые системы были запрограммированы на атаку целей без необходимости передачи данных между оператором и квадрокоптер. По сути, это настоящее воплощение принципа выстрелил и забыл, говорится в отчете.



Мнения экспертов:

Автономное оружие, как концепция не так уж и ново. Наземные мины это, по сути, простое автономное оружие вы наступаете на них, и они взрываются", сказал в интервью Live Science Закари Калленборн, научный сотрудник Национального консорциума по изучению терроризма и ответных мер на терроризм в Университете Мэриленда в Колледж-Парке. Что потенциально ново здесь, так это автономное оружие, включающее искусственный интеллект, добавил Калленборн, который работает в отделе нетрадиционного оружия и технологий консорциума.



Эксперт в области беспилотных систем Денис Федутинов отметил, что автоматические системы не всегда способны с необходимым уровнем точности идентифицировать цели, и всегда человек в этой цепочке контролировал и исправлял ошибки робота.

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

Грамотному обеспечению ИИ также часто не хватает того, что люди считают здравым смыслом. Например, компьютерные ученые обнаружили, что изменение одного пикселя на изображении может привести программу ИИ к выводу, что это было совершенно другое изображение, сказал Калленборн.

Если так легко испортить эти системы, что происходит на поле боя, когда люди перемещаются в сложной среде? сказал он.

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

• Как автономное оружие решает, кого убивать? По словам Калленборна, процессы принятия решений в программах искусственного интеллекта часто остаются загадкой.
• Какую роль играют люди? В ситуациях, когда люди следят за тем, какие решения принимает беспилотник, они могут внести коррективы до того, как произойдут потенциально смертельные ошибки. Тем не менее, люди-операторы могут в конечном счете доверять этим машинам до точки катастрофы, как показали несколько аварий с автономными автомобилями, сказал Калленборн.
• Какую полезную нагрузку несет автономное оружие? Опасность, которую представляет это оружие, возрастает с увеличением числа людей, которых оно может убить.
• На что нацелено оружие? Искусственный интеллект может ошибаться, когда дело доходит до распознавания потенциальных целей.
• Сколько автономного оружия используется? Более автономное оружие означает больше возможностей для провала, и военные все чаще изучают возможность развертывания роев беспилотников на поле боя. Индийская армия объявила, что разрабатывает рой из 1000 дронов, работающий полностью автономно, сказал Калленборн.
• Где используется автономное оружие? Риск, который представляют собой беспилотники, возрастает с ростом населения района, в котором они размещены, и запутанного беспорядка, в котором они путешествуют. По словам Калленборна, одно исследование показало, что система искусственного интеллекта, используемая для обнаружения препятствий на дорогах, была точна на 92% в ясную погоду и на 58% в туманную.
• Насколько хорошо проверено это оружие? Калленборн отметил, что автономное оружие, испытанное в дождливом климате, таком как Сиэтл, может по-другому работать в жару Саудовской Аравии.
• Как адаптировались противники? Например, ИИ-компания OpenAI разработала систему, которая могла бы классифицировать яблоко как Granny Smith с уверенностью 85,6%, но если кто-то приклеил лист бумаги с надписью iPod на фрукт, он пришел к выводу с уверенностью 99,7%, что яблоко было iPod, сказал Калленборн. Противники могут найти аналогичные способы обмануть автономное оружие.
• Насколько широко доступно автономное оружие? Если они широко доступны, то могут быть развернуты там, где их не должно быть как отмечалось в докладе ООН, Турция не должна была доставлять беспилотник Каргу-2 в Ливию.

Что я нахожу наиболее важным в будущем автономного оружия, так это риски, связанные с роями. На мой взгляд, автономные рои беспилотников, которые могут убивать людей, потенциально являются оружием массового поражения", сказал Калленборн.

В общем, реальность такова, что то, что произошло в Ливии, это только начало, сказал Калленборн. -Потенциал распространения этого оружия весьма значителен."

Что же будет дальше? Есть ли шанс, что такое будет повторяться все чаще и какие есть причины восстания машин?

Уже были неудачные попытки создания ИИ, когда тот выходил из под контроля.

3 марта 2016 года компания Microsoft создала ребенка. Ну как ребенка 19 летнюю девочку. Точнее самообучающегося бота для Twitter, который любит лазить в интернете, читать посты пользователей и делать свои, читать комментарии и отвечать на них. В общем обычная 19 летняя девочка по имени Тау (или Думает о вас @TayandYou ). Но вскоре после запуска она превратилась в монстра

Спустя 16 часов работы разработчики компании решили приостановить программу. Поняв, как обучается бот, пользователи начали затрагивать неполиткорректные темы. Девочка стала грубой и развратной, не уважающей чувства других людей. Она начала писать сообщения расистского и сексуального характера. Эксперимент вышел из-под контроля.



Когда Тау спросили: По шкале от 1 до 10 как ты оцениваешь холокост?, девочка ответила: Жаркие 10. Когда поинтересовались про теракты в Бельгии, она ответила: Получили что заслужили. А когда ее спросили про теракт 9/11, она сказала, что Буш сделал 9/11. К фотографии норвежского террориста Брейвика она написала комментарий: Вдохновляет.

Глобальный опрос, проведенный по заказу организаторов кампании по остановке роботов убийц в прошлом году, показал, что большинство респондентов 62% заявили, что они выступают против использования смертоносных автономных систем вооружения.

Источники:

1. www.livescience.com/ai-drone-attack-libya.htm
2. www.npr.org/2021/06/01/1002196245/a-u-n-report-suggests-libya-saw-the-first-battlefield-killing-by-an-autonomous-d

Источник

Вот уже несколько лет идет развитие рынка доставки товаров беспилотниками. Медленно, но уверенно эта сфера движется вперед. На днях стало известно, что немецкая компания разработала дрона, способного за раз перевозить 3 посылки. Новый беспилотник доставляет их прямо в руки к заказчику. Если все пойдет удачно, то впереди нас ждет новая эра B2C-торговли с очень быстрой доставкой практически без задержек в оказании услуг.

Модель N 198

Новый автономный летательный аппарат для перевозки одновременно трех малогабаритных грузов разработали в компании Wingcopter.

Основные характеристики БПЛА:

• 150 км/ч максимальная скорость БПЛА в горизонтальном полете;
• 6 кг максимальная полезная нагрузка;
• ~75 км преодолевает дрон на одном заряде аккумулятора при нагрузке в 6 кг;
• до 109 км пролетает беспилотник, перевозя легкие грузы;
• 8 роторов для взлета дрона-доставщика;
• 2 крыла у БПЛА для горизонтального полета;
• 3 отдельных крепления и лебедки для спуска груза;
• 10 дронами может одновременно управлять один оператор Wingcopter.

Еще одна особенность дрона-курьера он оснащен датчиками и необходимым ПО, которое помогает облетать препятствия и оставлять посылки в требуемых местах.

Дрон выполнен по схеме смешанного конвертоплана и использует механизм с наклонным ротором.

Четыре фиксированных винта по краям обеспечивают вертикальный взлет и посадку. У центра фюзеляжа есть еще четыре поворотных ротора. Они поворачиваются на 90 градусов: их применяют для вертикального и горизонтального полета.

В результате аппарат обладает преимуществами подобных моделей двух типов:

1. Умеет плавно вертикально взлетать и садиться.
2. За счет неподвижного крыла может парить в воздухе и быстро передвигаться на большие расстояния.

Чем полезны поворотные роторы? Они реагируют на резкие порывы ветра, адаптируют БПЛА к неблагоприятным погодным условиям.

В случае проблем предусмотрен перехват управления дроном оператором-человеком. Во избежание столкновения с другими аппаратами в воздухе коптер оснащен ресивером ADS-B и транспондером FLARM.

Что еще

Немецкий стартап занимается разработкой и совершенствованием коптеров с 2017 года. По словам генерального директора компании, Тома Плюммера, их следующая миссия создать сеть доставки дронами и развивать логистические магистрали в воздухе. Услуги могут быть использованы в следующих сферах: здравоохранение, e-commerce, доставка продуктов.

Wingcopter открыла прием заявок на первые 100 воздушных курьеров. В дальнейшем они планируют запустить серийное производство.

Сейчас компания получает лицензию от Федерального управления гражданской авиации США на выполнение коммерческих грузоперевозок.