СОЗДАНИЕ КОНФИГУРИРУЕМОЙ СИСТЕМЫ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ В СОСТАВЕ УНИФИЦИРОВАННОГО КОМПЛЕКСА УПРАВЛЕНИЯ БЕСПИЛОТНЫМИ ЛЕТАТЕЛЬНЫМИ АППАРАТАМИ
А.Ю. Хорошко, И.В. Макаров
ООО НПП «Автономные аэрокосмические системы – ГеоСервис»
Институт инженерной физики и радиоэлектроники ФГАОУ ВПО «Сибирский федеральный университет», г. Красноярск
Статья посвящена созданию конфигурируемой системы автоматического управления в составе унифицированного комплекса управления беспилотными летательными аппаратами (БПЛА). Сформулирован перечень задач, решение которых позволит в полной мере реализовать идею конфигурируемости системы автоматического управления без непосредственного участия разработчика комплекса. Проведен анализ возможных решений и выработаны конкретные рекомендации, а также приведено подробное описание, как данная задача была решена авторским коллективом.
В настоящее время на российском рынке представлен целый ряд автопилотов как отечественного, так и зарубежного производства. Большинство из них имеют существенный недостаток — отсутствие возможности интеграции потребителями в свои летательные аппараты самостоятельно. Пользователь, как правило, не может изменять структуру системы автоматического управления (САУ), реализованной в составе автопилота, имеются только опции настройки ограниченного числа параметров уже существующей САУ.Отсутствие возможности полностью конфигурировать САУ на базе автопилота является неприемлемым в ряде случаев:
- требуется адаптивно изменять полетное задание по событиям или данным, получаемым в ходе полета на борту летательного аппарата (ЛА), например, по данным от полезной нагрузки;
- полезная нагрузка является одним из источников управления положением ЛА в пространстве, как например при необходимости точной видеофотосъемки наземного объекта, либо при наведении вооружения (ЛА должен быть ориентирован заданным образом относительно объекта, включенного в перечень объектов полетного задания);
- управление ЛА должно изменяться в течение полета, например в случае если динамические параметры ЛА существенно меняются в течение полетного задания (снижение количества топлива, сброс полезной нагрузки).
Такой подход к проектированию существенно усложняет, а в некоторых случаях, делает невозможным интеграцию автопилота в аппараты с нестандартным количеством органов управления и/или законом их перемещения. Например, в этом случае невозможно организовать управление ЛА при использовании резервирования аэродинамических поверхностей, в экранопланах, нестандартных конфигурациях мультироторов и других.
В целях обеспечения настройки структуры и параметров САУ пользователем, необходимо решить следующий перечень задач:
- помимо инерциальной навигационной системы, встроенной в автопилот, должна быть предоставлена возможность использования внешних источников сигналов управления для САУ, без необходимости внесения изменений в конструкцию и программное обеспечение автопилота;
- должна быть предусмотрена гибкая система настройки ручного управления – количества входов, масштабов и допустимых диапазонов сигналов для каждого из них, а также должна быть предусмотрена возможность обработки одновременно нескольких устройств ручного управления;
- должна быть обеспечена возможность настройки исполнительных устройств, их количества и типа допустимого диапазона управляющего воздействия, без внесения каких-либо изменений в конструкцию автопилота;
- должна быть реализована возможность изменения структуры САУ, параметров каждого её структурного элемента, при этом, в соответствии с требованиями выше, число входов и выходов САУ может быть различным в зависимости от типа ЛА.
Следует отметить, что все перечисленные требования относятся только к части САУ, отвечающей за обеспечение положения летательного аппарата в связанной системе координат в соответствии с текущим полетным заданием. При этом задачи навигации, как правило, решаются стандартным образом для всех типов ЛА.
По крайней мере, на настоящий момент, авторскому коллективу не поступало запросов на обеспечение возможности настройки потребителем этой части системы управления ЛА.
Таким образом, в рамках настоящей статьи, вся система управления ЛА будет разделена на два уровня управления – навигационный и пилотажный. Навигационный уровень отвечает за перемещение ЛА в пространстве в соответствии с текущим полетным заданием (определяет положение ЛА в заданной точке земных координат и/или направление и скорость движения в земных координатах). Пилотажный уровень, в свою очередь, на основании выходного сигнала от навигационного уровня управления, рассчитывает и поддерживает все остальные значения вектора состояния объекта управления. Такому разделению способствует не только разный характер решаемых задач управления, но также и разный способ их реализации.
Пилотажный уровень, как правило, представляет собой дискретную систему автоматического управления (при этом структура и коэффициенты регуляторов могут изменяться во времени), а навигационный уровень, как правило, реализуется в виде конечного автомата.
Под САУ, для краткости, в дальнейшем будет подразумеваться только пилотажный уровень управления.
Связь автопилота авторского коллектива с источниками сигналов для САУ, исполнительными устройствами и прочим оборудованием осуществляется по дублированной шине RS485. В частности, для примера, на рис. 1 показана структурная схема электронной аппаратуры БПЛА DELTA—M.
Рис. 1. Структурная схема БПЛА DELTA-M
По мнению авторов, использование многоточечной линии связи типа «общая шина», как показано на рис. 1, является наиболее перспективным вариантом организации взаимодействия между частями комплекса управления БПЛА с полетной массой свыше 1кг, поскольку позволяет избежать проблем с помехозащищенностью, характерных для авиамодельных решений (в которых положение органов управления определяется длительностью импульса управляющего сигнала), а также подключать все бортовые устройства к одной шине вне зависимости от типа передаваемых данных. Поскольку все внешние относительно автопилота устройства подключены по одной шине и имеют индивидуальные адреса, передача данных к каждому конкретному устройству может быть сконфигурирована исключительно программным способом.
Рассмотрим подход авторского коллектива к решению каждой из сформулированных выше задач по обеспечению возможности настройки структуры и параметров САУ пользователем.
Рис. 2. Структурная схема БПЛА DELTA-M
На рис. 2 каждая из составных частей автопилота, с точки зрения программного исполнения, представлена отдельным программным процессом, исполняемым под управлением операционной системы QNX [1]. Помимо показанных на рис. 2, в составе АП выполняется большое число других процессов, решающих прочие задачи (коммуникация с наземным комплексом управления, телеметрия и т.п.) [1,2].
Процесс fnav отвечает за измерение вектора состояния ЛА q и его передачу всем процессам, которые эти данные запрашивают (на структурной схеме показано два потребителя данных, однако существуют и другие, находящиеся вне темы настоящей статьи, например служба аварийного спасения БПЛА, служба телеметрии и т.п.). Данные с датчиков, размещенных в составе автопилота (гироскопы, акселерометры, спутниковая глобальная навигационная система и система воздушных сигналов), а также внешних датчиков, таких как магнитный компас, согласно рис. 1, переводятся в формат единиц измерения «СИ» и комплексируются (набор данных от датчиков является избыточным), что позволяет увеличить точность и надежность результирующего навигационного решения.
Навигационный уровень управления на рис. 2 представлен процессом fcont-nav (от англ. слов flight control navigation – навигационный уровень управления полетом). Как было упомянуто ранее, на текущем этапе развития системы отсутствует необходимость в опции изменения пользователем логики принятия решений навигационным уровнем управления. По этой причине, алгоритм функционирования данного процесса является строго запрограммированным, пользователь имеет возможность модифицировать только параметры полетного задания (положение путевых точек и прочие) с помощью наземного комплекса управления БПЛА как до старта, так и во время полета.
Пилотажный уровень управления на рис. 2 представлен процессом fcont-reg (от англ. слов flight control regulation – управление полетом, регулирование).
Задача конфигурируемости источников сигнала для САУ потребителем является самой сложной из перечисленных – каждый источник сигнала, как правило, имеет свой формат, который необходимо интерпретировать и транслировать в формат данных, использованный в автопилоте. В некоторых случаях источник сигнала для САУ требует свою индивидуальную процедуру инициализации и верификации нормального функционирования в ходе подготовки БПЛА к взлету, что дополнительно усложняет задачу унификации программного обеспечения для работы с такими источниками. По этим причинам, на настоящий момент, требования к универсальному программному решению, которое позволит работать с широким спектром источников сигналов, авторским коллективом сформулированы не были - для каждого источника сигнала пишется индивидуальная часть программного кода. В случае если источник сигнала является сравнительно простым – не требует инициализации и верификации нормального функционирования, за исключением проверки принадлежности выходных сигналов заданным диапазонам – его можно «подключить» к САУ в составе автопилота с помощью службы ручного управления, как это будет показано ниже.
Задача ручного управления решается с помощью средств операционной системы QNX – каждое физическое устройство ручного управления регистрируется как «устройство» в терминах операционной системы (подробное описание подхода приведено в [2], fig. 4). Из каждого такого устройства индивидуальный программный поток в составе процесса fcont-reg считывает значения положений органов ручного управления, проверят их на соответствие заданным ограничениям и, с учетом заданного масштаба, транслирует во входные сигналы регуляторов. Каждое такое «устройство» в случае запроса данных возвращает массив шестнадцатирязрядных знаковых переменных.
Настройка программного потока ручного управления пользователем осуществляется с помощью документов в формате XML (расширенный язык разметки).
Ниже приведен пример содержимого конфигурационного файла для двухканального устройства ручного управления:
<mancont>
<manc_device name="joystick" path="/dev/joystick">
<fsignal channel="1" scale="0.0001" max="1.0"
min=
"-1.0">joystick_x</fsignal>
<fsignal channel="2" scale="0.0001" max="1.0"
min=
"-1.0">joystick_y</fsignal>
</manc_device>
</mancont>
Каждый параметр такого формата начинается с открывающего тэга, например (от англ. слов manual control – ручное управление) и закрывающего, где к названию поля добавляется косая черта. Тэг c названием «mancont» уведомляет программу-разборщик документа, что указанные внутри него данные относятся к одному устройству ручного управления. Поле «manc_device» задает название органа ручного управления, которое будет использоваться для его идентификации (например, при выдаче ошибок).
Атрибут «path» задает адрес устройства, с которого требуется считывать данные ручного управления.
Для каждого органа управления указывается поле с названием «fsignal» и атрибутами:
«channel» – порядковый номер переменной (введен во избежание непреднамеренного удаления одного из описания каналов управления и облегчения отладки – в случае отсутствия описания какого-либо из каналов управления, разборщик XML-документа выдаст ошибку с указанием номера неуказанного канала);
«scale» – масштаб переменной - поскольку данные передаются в целочисленном виде, для задания положения органа управления в диапазоне [0;1]или [-1;1], необходимо масштабирование переменной перед передачей в АП и обратный пересчет при трансляции переменной регуляторам;
«max» и «min» – максимальные и минимальные допустимые значения сигнала управления после обратного масштабирования.
Для каждого поля «fsignal» разборщик XML документа создает в составе процесса fcont-reg сигнал с соответствующим именем.
Как было упомянуто выше, службу ручного управления возможно использовать для обработки данных с устройств, установленных на борт БПЛА потребителем – для этого достаточно, чтобы устройство потребителя свои выходные данные передавало в соответствующем формате (массив 16-разрядных целых чисел) и было зарегистрировано как устройство в операционной системе QNX.
Задача конфигурируемости исполнительных устройств решена аналогично задаче ручного управления – отдельный программный поток, сконфигурированный по составленному пользователем XML-документу, передает выходные величины САУ в исполнительные устройства с помощью средств ОС QNX.
Реализация задачи конфигурируемости САУ была сведена к тому, что пользователю предоставляется набор готовых блоков, которые изначально запрограммированы в составе автопилота, и пользователь имеет возможность скомпоновать из них требуемую ему систему автоматического управления. «Сборка» САУ осуществляется путем введения индивидуального описания для каждого блока САУ, по аналогии с конфигурацией устройства ручного управления: для каждого блока указываются названия всех его входных и выходных сигналов, значения всех параметров каждого блока.
Такое решение задачи затрудняет задачу программной реализации с точки зрения скорости вычисления каждого блока САУ – поиск сигналов по имени каждую итерацию регулятора увеличивает время вычисления до недопустимых величин. Поэтому максимально возможное количество программных процедур было выведено в начальную инициализацию процесса – процесс инициализации находит сигнал по его имени и регистрирует в данных каждого регулятора указатель на соответствующий сигнал. Такой подход позволил избежать дополнительных накладных расходов, в результате чего производительность системы осталась на прежнем уровне по сравнением с прежней, не конфигурируемой, реализацией регуляторов САУ.
Помимо расходов процессорного времени на итерацию регуляторов САУ, важным параметром является задержка распространения сигналов через все программные потоки, а также джиттер (фазовое дрожание цифрового сигнала). Для того, чтобы оценить величину задержек, рассмотрим подробно структуру каждого процессас точки зрения действий, совершаемых над сигналами.
Рис. 3. Структура процессов fnav и fcont-reg с точки зрения последовательности обработки сигналов
Каждый элемент, входящий в состав процессов на рис. 3 программно реализован в виде отдельного программного потока в целях упрощения программирования, сопровождения, а также для повышения надежности.
Процесс fnav. Задача «измерение и передача» включается в себя измерение и, в случае наличия, обработку части вектора состояния ЛА каждым имеющимся датчиком, а также передача этих данных потоку обработки данных. Под задачей «обработка данных» понимается преобразование данных в формат данных системы единиц измерения «СИ» и комплексирование. Задача «передача данных потребителям» включает в себя передачу навигационного решения всем процессам, которые в данный момент его запрашивают.
Процесс fcont-reg получает данные о текущем векторе состоянии БПЛА от fnav, а также данные о положении и состоянии устройств ручного управления, транслирует навигационное решение в формат fsignal, который используется всеми регуляторами САУ. Этот формат включает себя как численное значение самого сигнала, так и вспомогательную информацию – является ли этот сигнал активным в настоящий момент («включен» или «выключен»), флаг, сигнализирующий об обновлении сигнала и другие. Как было описано выше, итерация регуляторов осуществляется последовательно от входа к выходу системы, в результате чего выходные сигналы системы устанавливаются в значения, соответствующие результатам итерации. Список сигналов, передаваемых органам управления, транслируется в соответствующий формат и передается исполнительным устройствам посредством интерфейса RS485.
В целях минимизации задержек передачи данных между потоками, синхронизация осуществляется с помощью мутексов – поток-клиент (получатель данных) запрашивает данные у потока-сервера. Если данные к настоящему моменту обработаны не были, поток-клиент средствами операционной системы удерживается в блокированном состоянии, пока поток-сервер не передаст ему свои выходные данные. Таким образом, поток-клиент начинает обрабатывать данные сразу после их выдачи потоком-сервером с точностью до времени переключения потоков операционной системой. Передача данных между процессами осуществляется через менеджер ресурсов [2]. Организации синхронизации между процессами осуществляется посредством системы приоритетов – после выдачи данных процессом fnav, процесс fcont-reg первым получает право на их обработку. Такая организация, хотя не гарантирует точного времени передачи сигнала между рассмотренными процессами, параметрически обеспечивает допустимое время задержки, так как в памяти автопилота не выполняется процессов с более высоким приоритетом.
Авторским коллективом был написан программный код, построенный с учетом подхода, изложенного выше. Анализ производительности показал, что система автоматического управления вертолетом, состоящая из двенадцати PID-регуляторов и двадцати трех вспомогательных блоков (компараторы, ограничители скорости нарастания сигналов и другие) полностью итерируется за интервал времени не превышающий период тактирования системы в целом (20 миллисекунд).
Следует отметить, что разработанная система не лишена ограничений – все предоставляемые пользователю регуляторы пишутся производителем, что ограничивает возможности пользователя в создании нестандартных систем, в особенности с применением нелинейных регуляторов, не четкой логики и подобных. Такое же ограничение накладывается на САУ, в которых требуется применять сложные вычисления, непосредственно не связанные с регуляторами, такие как триногометрические и сложные математические функции. По мнению авторского коллектива, единственным способом устранения перечисленных ограничений является предоставление пользователю самостоятельно внедрять программный код в состав автопилота.
Это возможно осуществить двумя способами.
Первый способ заключается в том, что для пользователя создается библиотека на языке программирования «C», которая решает задачу получения всех требуемых данных от существующих процессов автопилота и передачу результатов вычисления органам управления. Пользователь самостоятельно дописывает код, генерирует бинарный исполняемый файл, загружает его в автопилот и запускает. Такое решение является наиболее универсальным и позволяет пользователю реализовать любые регуляторы. Недостатком такого решения является необходимость в высокой квалификации пользователя, умение самостоятельно писать и отлаживать программный код.
Второй способ основан на генерации кода какой-либо программой. Наиболее перспективным решением является синтез кода посредством пакета Matlab. Это решение эффективно с точки зрения требований к квалификации пользователя – достаточно «собрать» систему автоматического управления в графическом языке программирования Simulink, сгенерировать код с помощью средств Matlab, сгенерировать исполняемый файл и загрузить в автопилот. С другой стороны, физическая реализация такого способа генерации кода непосредственно для автопилота требует проведения большого объема работ по интеграции со средой Matlab, а также решения вопросов надежности генерации кода (отсутствия ошибок при «переводе» проекта из графического языка в конечный исполняемый файл).
Оба перечисленных способа решения задачи полной конфигурируемости САУ в настоящий момент прорабатываются авторским коллективом.
Сформулированный в статье перечень задач был решен успешно, в результате чего была создана система автоматического управления БПЛА с возможностью полной настройки структуры САУ и параметров регуляторов пользователем, без ухудшения характеристик системы с точки зрения затрат процессорного времени в ходе итерации регуляторов. Дальнейшим направлением работ является расширение возможностей пользователя вплоть до синтеза самих регуляторов пользователем на языке «C» или графическом языке Simulink.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Макаров И.В., Кокорин В.И. Комплекс управления беспилотными летательными аппаратами для дистанционного зондирования Земли. //Современные проблемы радиоэлектроники : сб. науч.тр. / под ред.: А.И.Громыко, Г.С.Патрина; отв. за вып. А.А.Левицкий; Сиб. Федер. ун-т – Красноярск, 2010. - 424 с. – стр. 6 – 10
2. Makarov I. Flexible Telemetry Parameters Management System for Research and Development ofUnmanned Platforms, Control and Communications (SIBCON), 2011 International Siberian Conference IEEE, p. 152-154.
660079, Россия, г. Красноярск,
ул. Электриков, 156/1