Полётный контроллер — Википедия с видео // WIKI 2

Smartport telemetry via softserial (betaflight)

Smart port telemetry requires an inverted serial signal, but many flight controllers only include hardware inversion on the SBUS connector.  So if you want to use SmartPort telemetry on your Frsky receiver it can sometimes be a pain.  The easiest way to overcome this is to simply use soft serial which emulates the inverter via software.  This guide will show you how to do this on just about any flight controller.

In this guide we will be using the omnibus F4 V6 as the flight controller, but this article can be applied to just about any flight controller.  We have a Frsky XSR-M receiver connected to it.  And we have connected the smartport telemetry to a spare TX pad on UART1.  A diagram of this is shown below.  Lets get started.

• Assuming you are connecting it as per the diagram above, we will need to enable softserial on TX1 (since we have connected it to UART1). The first thing we need to do is to find what pin the TX1 is connected to so we can enable softserial on that pin.
• The first thing to do is to enable the softserial feature on the configuration tab

• Now we need to tell the flight controller what pins we want to use for softserial
• In the CLI and type resource to get a list of pins, look for TX1

Смотрите про коптеры:  Как не потерять квадрокоптер: 6 советов как найти улетевший дрон

• In this example, TX1 is assigned to A09. This is the case for most flight controllers, but sometimes it can be different.
• Now we will enable softserial 1 on pin A09. In the CLI type the following command:

resource SERIAL_TX 11 A09
save

💡 Port 11 is for softserial 1, and port 12 is for softserial 2. So if you wanted to assign softserial 2 to another pin (such as UART6, or the LED pin), you could assign port 12 to the corresponding pin you got from the resource command. If you wanted to assign A09 to softserial 2, you would use the command resource SERIAL_TX 12 A09

• Now when you go back to the ports tab in BetaFlight (after your FC reboots), you will now see a new line called SOFTSERIAL 1

• Simply enable SmartPort telemetry on this port and you should now have Frsky telemetry working on your receiver.
• If you cant get it working, you may need to try using the CLI again to turn inversion on and off using the following commands.

set tlm_halfduplex = on
set tlm_inverted = off
save

• If off does not work, try again with tlm_inverted = on.

Thanks for reading and I hope this helps.  If you have any questions be sure to ask on our friendly forums, dronetrest.com

А теперь – о самом полетном контроллере

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

Структурная схема управляющего ПО показана на рисунке

Как видно из рисунка, ПО состоит из двух частей:

Так как тратить много времени не хотелось, то драйвер для USB в STM32 был взят прямо нативный и при помощи Interop был слинкован с оберткой на Ada.

Плата оказалась оснащена минимальным количеством периферийных устройств: 

Полетный контроллер реализован по простой схеме и «крутит» 2 цикла:

1. внешний

2. внутренний

Внешний цикл это цикл опроса периферии (CMD task на рисунке) в ожидании команд с радиопередатчика. Если команды нет, он передает признаки «сохраняем высоту, держим горизонт». Если команда с пульта есть, передаем ее – целевой угол наклона, целевую мощность на пропеллеры. Частота внешнего цикла 20 Гц.

Внутренний цикл – цикл опроса гиро-акселерометра и распределения мощности на двигатели. Цикл оборудован 3 PID-регуляторами, и математикой Махони для расчета текущего положения по сигналам с гироскопов. В расчетах внутри используем кватернионы, для генерации управляющего сигнала – углы Эйлера. Частота размыкания внутреннего цикла – 200 Гц. Да, Ада без проблем успевает диспетчеризировать с такой скоростью.

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

Внутренний цикл реализует опрос PID и стабилизацию аппарата:

Забавно, что большинство опен-сорсных реализаций Махони (для Arduino и не только) – на Cи и Wiring оказались содержащими разнообразные баги. Это мешало системе заработать. После того, как было выпито пол-ящика лимонада и съедена корзина круассанов, алгоритм воссоздали с нуля по описанию из [MHN], и система тут же заработала.

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

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

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

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

Итог на текущий момент

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

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

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

Для себя мы сделали вывод, что для embedded будем стараться писать только на Ada.

Базовые понятия

Квадрокоптеры бывают разные, но всех их объединяют четыре несущих винта:

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

Это таит в себе опасность: новичкам бывает трудно вернуть к себе подхваченный ветром аппарат, развернутый как-нибудь боком (мы, конечно, не говорим про полеты по камере от первого лица и про «умные» режимы полета с использованием компаса и GPS.) Решению этой проблемы частично могут помочь передние винты или лучи другого цвета, какой-нибудь шарик спереди или разноцветные светодиоды. Но все это оказывается бесполезным, когда пепелац стремительно превращается в точку над горизонтом.

Мы будем летать на раме квадрокоптера формы «X», потому что она мне больше нравится внешне. У каждой конструкции свои плюсы и свое предназначение. Кроме квадрокоптеров есть и другие мультикоптеры. Даже если не считать экзотические варианты, все равно их видов — целая куча!

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

Углы тангажа, крена и рыскания (pitch, roll, yaw) — углы, которыми принято определять и задавать ориентацию квадрокоптера в пространстве.
Википедии это не совсем точно. Полет квадрокоптера в необходимом направлении достигается изменением этих трех углов. Например, чтобы полететь вперед квадрокоптер должен наклониться за счет того, что задние моторы закрутятся чуть сильнее передних:

Газ квадрокоптера — среднее арифметическое между скоростями вращения всех моторов. Чем больше газ, тем больше суммарная тяга моторов, тем сильнее они тащат квадрокоптер вверх (НЕ ВПЕРЕД!!! «Тапок в пол» здесь означает наискорейший подъем). Обычно измеряется в процентах: 0% — моторы остановлены, 100% — вращаются с максимальной скоростью. Газ висения — минимальный уровень газа, который необходим, чтобы квадрокоптер не терял высоту.

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

Режимов полета существует много. Используется и GPS, и барометр, и дальномер. Но мы хотим реализовать базовый — режим стабилизации (stab, stabilize, летать в «стабе»), в котором квадрокоптер держит те углы, которые ему задаются с пульта не зависимо от внешних факторов. В этом режиме при отсутствии ветра квадрокоптер может висеть почти на месте. Ветер же придется компенсировать пилоту.

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

Скоростью вращения моторов управляет

полетный контроллер (контроллер, мозги)

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

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

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

Благодаря им полетный контроллер узнает текущие углы тангажа, крена и рыскания. Эти датчики бывают встроенными в полетный контроллер, а бывают внешними. Процесс вычисления трех углов по показаниям датчиков — тема для отдельной статьи. Но нам этого здесь знать не надо: за нас все сделает MPU-6050.

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

«Протокол» общения между регулятором и мотором нам не так важен, как «протокол» общения между полетным контроллером и регулятором, ведь нам предстоит из контроллера программно управлять регулятором. Бывают регуляторы, управляемые по i2c, но наиболее распространенные управляются сигналом прямоугольной формы с минимумом 0 вольт и максимумом 3-5 вольт (его называют ШИМ или PWM, а некоторые утверждают, что правильнее — PPM. Подробнее, например, здесь).

«Протокол» — это громко сказано: чтобы дать команду мотору вращаться с максимальной скоростью контроллер должен отправлять импульсы длительностью 2 миллисекунды, перемежающиеся логическим нулем длительностью 10 — 20 миллисекунд. Длительности импульса в 1 миллисекунду соответствует остановка мотора, 1.

При всей кажущейся простоте, здесь кроется засада: полетные контроллеры бывают разные с разными настройками, регуляторы бывают разные, и минимум (1 мс) и максимум (2 мс) — не универсальны. В зависимости от множества факторов диапазон 1-2 мс может на деле оказаться 1.1 — 1.9 мс.

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

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

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

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

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

Помимо программы для полетного контроллера необходима еще одна программа: интерфейс настройки полетного контроллера. Чаще всего им является программа для PC, которая соединяется с полетным контроллером по USB и позволяет пользователю настраивать и проверять полетную программу, например: запускать калибровку радио, настраивать параметры стабилизации, проверять работу датчиков, задавать маршрут полета на карте, определять поведение мультикоптера при потере сигнала и многое другое. Мы свой интерфейс настройки будем писать на C и Qt в виде консольной утилиты. Вот она, если заглянуть в будущее:

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

Поэтому полетный контроллер должен обеспечивать хоть какую-то безопасность: механизм armed/disarmed. Состояние квадрокоптера «disarmed» означает, что моторы отключены и даже команда полного газа с пульта не имеет никакого эффекта, хотя питание подано.

Состояние «armed» квадрокоптера означает, что команды с пульта выполняются полетным контроллером. В этом состоянии квадрокоптеры взлетают, летают и садятся. Квадрокоптер включается и должен сразу попасть в состояние disarmed на тот случай, если невнимальельный пилот включает его, когда стик газа на пульте находится не в нуле.

Чтобы перевести коптер в состояние «armed» пилоту необхоимо сделать какой-то заранее оговоренный жест стиками пульта. Часто этим жестом является удержание левого стика в правом нижнем углу (газ = 0%, рыскание = 100%) втечении пары секунд. После этого полетный контроллер делает хотя бы минимальную самопроверку и при ее успешном прохождении “армится” (к полету готов!)

Вкладка configuration

1. Раздел ESC/Motor Features

Протокол регуляторов скорости (регуляторов оборотов) — посмотрите на характеристики вашего оборудования, какие протоколы оно поддерживает. Рекомендуется использовать DShot. Обычно регуляторы с прошивкой BLHeli_S поддерживают DShot300 или DShot600, а с прошивкой BLHeli_32 — даже DShot1200.

Дополнительная информация: протоколы и прошивки для регуляторов скорости.

Рекомендую отключить параметр «MOTOR_STOP«, иначе вы не сможете определить армлен коптер или нет.

Остальные параметры можно не трогать и оставить значения по умолчанию.

2. Раздел System Configuration

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

Gyro Sampling Rate — частота опроса гироскопов, обычно совпадает с looptime, хотя некоторые предпочитают поставить удвоенную частоту looptime. Можете поставить 4 кГц и looptime 2 кГц.

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

При смене значений этих параметров обратите внимание на CPU load (загрузка процессора) внизу экрана, старайтесь держать это значение меньше 30%. Если значение будет выше, то полетный контроллер может работать нестабильно.

Accelerometer — можно отключить, это высвободит немного процессорных ресурсов, но тогда вы не сможете использовать режимы Angle и Horizon, а 3Д модель на вкладке Setup перестанет двигаться. Еще одна причина по которой отключают эту функцию — чтобы избежать проблем при арминге коптера, если он сильно наклонен.

Отключите Barometer и Magnetometer, они нам не нужны, т.к. мы летаем на миникоптере.

3. Раздел Personalization

Craft name — название коптера, это значение будет отображаться на экране при помощи Betaflight OSD.

4. Раздел Receiver

Если у вас приемник SBUS, IBUS или Spektrum Satellite, тогда выбирайте «Serial-based receiver» в выпадающем списке «Receiver Mode». В параметре Serial Receiver Provider нужно выбрать SBUS, т.к. у нас приемник FrSky.

Если приемник использует PPM, тогда выберите PPM RX Input в списке Receiver Mode.

5. Раздел Other Features

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

• Anti-Gravity
• Dynamic Filter
• Telemetry (чтобы работала SmartPort телеметрия)
• OSD (если ваш ПК поддерживает Betaflight OSD)

Нажмите Save & Reboot.

Иной язык

Несмотря на то, что сейчас “рулят” си-подобные ECMA-языки, мы нормально отнеслись к тому, что от этого придется отказаться. Более того, кажется, что чем больше программа, тем больше вредит укорочение ключевых слов и конструкций. Что касается Rust, то он – субъективно – в отношении минимализма издалека сильно напоминает Perl, к сожалению.

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

 Профили

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

Мы используем профиль Ravenscar, специально для embedded-разработки. Он включает пару дюжин ограничений, которые делают вашу разработку для микроконтроллеров более удобной и верифицируемой: нельзя на ходу переназначать приоритеты задач-потоков, переключать обработчики прерываний, сложные объекты из stdlib-ы и такое.

Вот ограничения профиля Ravescar, для примера

 Runtime

Когда в embedded необходимо создать более-менее сложное приложение, там всегда заводится RTOS, и ее выбор и интеграция это отдельная песня. В случае с Ada с этим больше нет сложностей – сама Ada включает в себя минимальную исполняемую среду с вытесняющим планировщиком потоков (в Ada это tasks, задачи), с интегрированными в сам язык средствами синхронизации (семафоры, рандеву, называются entries) и даже средствами избегания дедлоков и инверсии приоритетов. Это оказалось очень удобно для квадрокоптера, как станет понятно ниже.

Для embedded-разработчика доступны на выбор также разные рантаймы:

Вот пример описания пустой задачи

Хочется обратить внимание, что эти задачи – это по сути легковесные green threads, так как под ними нет никаких настоящих потоков не существует. Поэтому мы не страдаем от отсутствия корутин, ведь задачи не тяжелее них, зато встроены в язык.

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

Почему не “rustRustRUST”!

Когда мы говорим, про гарантии в языках программирования, сразу вспоминается Rust и его гарантии относительно указателей. Почему тут не он? Нам кажется, что Spark мощнее.

Ada не очень любит указатели – там они называются access types, и в большинстве случаев там они не нужны, но если нужны, то – в Spark также есть проверки владения, как в Rust. Если вы аллоцировали объект по указателю, то простое копирование указателя означает передачу владения (которую проконтролирует компилятор/верификатор), а передачу во временное владение (или доступ на чтение) верификатор также понимает и контролирует.

В общем, концепция владения объектом по указателю, и уровень доступа через этот указатель – есть не только в Rust, и его преимуществами можно пользоваться и в других инструментах, в частности, в Ada/SPARK. Подробно можно почитать в [UPS]

Вот пример кода с владением

Почему мы пишем, что в Ada/SPARK не нужны указатели? В отличие от Си, где базовым инструментом является указатель (хочешь ссылку – вот указатель, хочешь адрес в памяти – вот указатель, хочешь массив – вот указатель – ну вы поняли?), в Ada для всего этого есть строгий тип.

Если уже и этого мало, есть интероп с СИ – то есть код можно компилировать совместно, и слинковать на этапе сборки. Но в этом случае гарантии поведения модуля как черного ящика остаются на разработчике. Для интеропа используются атрибуты – вот так, например, мы оборачиваем функцию на Си в доступ для Ada.

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

IDE

Для работы доступна вполне приятная и удобная IDE, но всегда можно использовать и VSCode с плагинами, и другие текстовые редакторы.

О производительности и надежности

Вполне валидным аргументом может быть вопрос с эффективностью ПО. Что касается эффективности, то в интернете доступно свежее исследование [EFF], из которого хочется привести табличку, показывающую, что “старичок» Ada еще огого:

Если говорить о надежности, то SPARK/Ada известен как один из языков с наименьшим количеством ошибок. В планируемом на 21 запуске кубсатов [LIC] полетное ПО планируется реализовывать на Ada, предыдущий спутник BasiLEO тоже на Ada был единственным среди 12, кому удалось приступить к планируемой миссии.

Комплектующие для сборки коптера – hellhog – блог

Математика стабилизации, пид-регуляторы (pid)

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

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

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

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

Кроме того, мы же собираемся писать собственную систему стабилизации квадрокоптера! Предлагаю вместе со мной самим заново «изобрести» и «на пальцах» понять формулу ПИД-регулятора. Для тех, кому больше нравится сухой математический язык, я рекомендую Википедию, английскую статью, т.к. в русской пока не так подробно изложен материал.

Будем рассматривать квадрокоптер в двумерном пространстве, где у него есть только один угол — угол крена, и два мотора: левый и правый.

В полетный контроллер непрерывно поступают команды с земли: «крен 30 градусов», «крен -10 градусов», «крен 0 градусов (держать горизонт)»; его задача — как можно быстрее и точнее их выполнять с помощью моторов с учетом: ветра, неравномерного распределения веса квадрокоптера, неравномерного износа моторов, инерции квадрокоптера и т.п.

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

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

Уровень газа поступает из приемника в контроллер. Обозначим его

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

Здесь P — коэффициент пропорциональности. Чем он больше, тем сильнее будет реакция, тем резче квадрокоптер будет реагировать на отклонение от требуемого угла крена. Эта интуитивно понятная и простая формула описывает работу пропорционального регулятора.

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

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

И вот пропорциональный регулятор превращается в пропорционально-дифференциальный (пропорциональное слагаемое и дифференциальное):

Ошибку

Теперь у нас есть пропорционально-дифференциальный регулятор в плоском «бикоптере», но осталась еще одна проблема. Пусть левый край будет весить чуть больше правого, или, что то же самое, левый мотор работает чуть хуже правого. Квадрокоптер чуть наклонен влево и не поворачивается обратно: дифференциальное слагаемое равно нулю, а пропорциональное слагаемое хоть и принимает положительное значение, но его не хватает, чтобы вернуть квадрокоптер в горизонтальное положение, ведь левый край весит чуть больше правого. Как следствие — квадрокоптер будет все время тянуть влево.

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

где T — текущий момент времени.
Пришло время записать окончательную формулу пропорционально-интергрально-дифференциального регулятора:

где

Существует несколько ее вариаций, например, можно ограничить модуль интегрального слагаемого, чтобы он не превысил определенный допустимый порог (мы так и будем делать).

Проблемы

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

• Перегрузка процессора – сложность вычислительных процессов при обработке первичной информации с датчиков, а также необходимость декодирования на программном уровне сигналов радиоуправления, обслуживание телеметрии и других процессов может приводить к перегрузке центрального процессора, проявляющихся в задержках (лагах) управляющих сигналов. В результате мультикоптер на десятки-сотни миллисекунд остается без управления, что вызывает неустойчивость его полета. Данная проблема свойственна всем полетным контроллерам на основе восьмибитных процессоров. Особенно сильно эта проблема проявляется в достаточно сложной системе ArduPilot.
• Проблемы электрического питания. Электрические двигатели мультикоптера и их контроллеры создают повышенный уровень помех в цепях питания полетного контроллера, что может приводить к программным сбоям и даже зависанию микропроцессора. По этой причине профессиональные полетные контроллеры всегда имеют встроенные вторичные источники питания. В любительских контроллерах цепи питания обычно очень простые, требующие внешнего источника: обычно это BEC (Battery Elimination Circuit) контроллера двигателя, отдельный преобразователь напряжения или, реже, отдельный аккумулятор. Сами такие преобразователи или их длинные соединительные провода являются источником помех.
• Несогласованность сигналов датчиков. Применение достаточно простых датчиков и отсутствие их комплексной юстировки на мультикоптере может приводить в противоречиях их показаний. Например по информации датчика угловой скорости нос коптера поворачивает влево, тогда как по данным магнитометра (компаса) – вправо. Такая ситуация может возникнуть из за влияния коррелированных вибраций и переменного магнитного поля мотора. Часто встречается и ситуация с противоречивыми показаниями барометрического датчика высоты и информации о высоте от GPS/GLONASS приемника. Поведение полетного контроллера в этом случае зависит от особенностей программного обеспечения и при его несовершенстве может вызывать опасные ситуации. Например, DJI Naza при противоречиях показаний акселерометра и барометрического датчика высоты производит автоматическую настройку цифровых фильтров. Однако, если противоречия показаний коррелированы (обусловленные, например пульсациями давления и вибрациями, вызванными вращением воздушного винта), то чувствительность канала управления высотой в процессе автонастройки фильтров может снизиться почти до нуля, что приведет к падению аппарата. При несогласованности показаний направления вектора скорости по компасу и по данным датчиков угловой скорости аппарат может начать двигаться с увеличивающейся скоростью по расходящейся спирали приобретая при этом сильную раскачку (в англоязычных источниках это явление называется toilet bowling, в русскоязычных – “унитазинг”), что в итоге приводит к тяжелой аварии.
• Проблемы надежности программного обеспечения. Если на пилотируемых летательных аппаратах или на профессиональных беспилотниках программное обеспечение проходит тестирование надежности и сертификацию, то для полетных контроллеров массового применения такие процедуры не проводятся. В связи с этим имеется высокий риск аварии по причине сбоя в программном обеспечении.
• Проблемы адаптивности программного обеспечения. Полетный контроллеры широкого применения разрабатываются достаточно универсальным, пригодными для работы на различных летательных аппаратах. Например, ArduPilot с прошивкой ArduCopter может быть настроен для работы практически на любом мультикоптере от миниатюрного гоночного квадрокоптера с тяговооруженностью порядка 10 единиц, до огромного октокоптера, несущего зеркальную камеру на трехосевом подвесе, имеющего тяговооруженность не более 1,5. Хотя общие принципы управления такими аппаратами одинаковы, реальная практическая реализация их полетных характеристик совершенно разная. Гоночному коптеру совершенно не важна стабильность полета, но важно время реакции и возможность полета с большими углами атаки или даже в перевернутом состоянии. Крупному съемочному октокоптеру не нужна маневренность, но требуется высокая стабильность и большое время полета. Следовательно, программное обеспечение должно быть адаптивным, позволяющим использовать различные алгоритмы цифровых фильтров, иметь различные управляющие программы и ПИД-регулятор с большими диапазонами регулирования. Однако реализовать адаптивность достаточно сложно даже на мощных настольных компьютерах не говоря уж о малоресурсных контроллерах.