Движение кордовой авиамодели

[GorSMS]

Dmitriy40 в сообщении #1477348 писал(а):

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

Поясню, как предполагал решить задачу изначально.
Главный посыл: обеспечить устойчиво-управляемый полет модели на минимальной скорости в любой точке полусферы без сваливания.
В простейшем варианте было бы достаточно просто отрегулировать обороты моторчика для горизонтального полета, а дальше анализировать положение оси $Ox$ модели - пошел нос самолета вверх, добавляем обороты, отклонился нос от горизонта вниз - сбрасываем. Тут вообще было бы достаточно одно-осевого "угломера" (акселерометра). И такая система полностью оправдала бы себя, если бы не сферическая образующая траектории. Но и здесь, до углов наклона корд до 45...50 градусов можно было бы обойтись одной координатой $Ox$. А вот при бОльших углах наклона корд для адекватной оценки потребной мощности двигателя придется учитывать и координату $Oy$. Но в идеале, разумеется, потребуется и координата $Oz$.
Для того, чтобы не выполнять в реал-тайм длинных матвычислений (умножение, деление, извлечение корней и т.п.) по расчету скоростей и ускорений на борту самолета (простые микроконтроллеры типа ATmega не умеют этого, а применить более мощный камень не сумею уже я сам ), и возникла мысль смоделировать матрицу всех возможных положений модели на поверхности полусферы, и для каждой точки в пространстве задать коэффициент мощности двигателя. Тогда в полете будет достаточно прочитать данные акселерометра, и выбрать из таблицы требуемый коэффициент мощности.
Для этого достаточно рассмотреть один "полумеридиан" сферы от горизонта до зенита (достаточно 5...7 угловых положений), и в каждой из этих 5...7 точек "повертеть" модель по оси $Oy$ с дискретность ~15 градусов в диапазоне от -90 до +90 градусов. По моим прикидкам, всего в таблице должно храниться порядка сотни "пресетов" на все случаи жизни (полета).

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

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

[wrest]

GorSMS в сообщении #1477369 писал(а):

Главный посыл: обеспечить устойчиво-управляемый полет модели на минимальной скорости в любой точке полусферы без сваливания.

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

(Оффтоп)

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

[EUgeneUS]

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

[GorSMS]

wrest в сообщении #1477382 писал(а):

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

Видимо Вы не обратили внимание, но выше я уже писал, что в горизонтальном полете должна быть заведомо достаточная скорость для устойчивого полета. Я сознательно избегал конкретных цифр, но сейчас их озвучу. Если принять, что длина корд 20 метра (радиус сферы), масса модели ~ 1,5 кг, а горизонтальная скорость 80 км/час (и это далеко не нижний предел, на котором самолет может устойчиво летать и управляться), то будет не трудно посчитать натяжение корд в горизонтальном полете. По моим прикидкам оно будет равно 36,6$N$, или 3,7$kg$, что в два раза больше веса модели. Как говорится - то, что доктор прописал. Можно так же посчитать кинетическую энергию, запасенную на этой скоростью моделью. У меня она получается равной почти 370 Джоулям. (Извините, но правильно писать формулы у меня еще не всегда получается). Этой энергии наверняка хватит, чтобы "перебросить" модель через точку зенита (закроем глаза на неизбежную потерю скорости и энергии при выполнении перехода из горизонтального в вертикальный полет), но вот натяжение корд при подлете к точке зенита существенно уменьшится...

Цитата:

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

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

EUgeneUS в сообщении #1477390 писал(а):

ИМХО, учитывать в регулировке ускорение по продольной оси модели весьма полезно.

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

[wrest]

GorSMS
Скажите, а куда направлен руль направления? Я имею в виду, если запустить самолет без корда и с выключенным мотором, он будет лететь прямо или отвернёт в сторону?

[EUgeneUS]

wrest в сообщении #1477413 писал(а):

Скажите, а куда направлен руль направления

(Оффтоп)

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

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

GorSMS в сообщении #1477408 писал(а):

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

1. Вы (Ваш автомат) управляете тягой (силой тяги) и более ничем. И то с задержкой, связанной со временем раскрутки двигателя.
2. Целевой параметр - это сила натяжения корд, как я понял.
3. Сила натяжение корд
а) её можете измерить почти непосредственно - умножая показания акселерометра по соответствующей оси на массу модели.
б) она зависит только от угла наклона корд и путевой скорости модели.
4. То есть управляя силой тяги, Вы управляете путевой скоростью модели, а значит и силой натяжения корд.
ОК.

Далее. Измеряя только силу натяжения корд (см. выше), Вы получаете информацию вида "сила натяжения корд хороша", "сила натяжения корд мала", "сила натяжения корд велика".
А если измерять ещё и ускорение по продольной оси, Вы получаете информацию вида "сила натяжения корд хороша, но падает\растёт\не меняется", "сила натяжения корд мала, но падает\растёт\не меняется", "сила натяжения корд велика, но падает\растёт\не меняется".
ИМХО, это позволит более адекватно формировать управляющее воздействие.

-- 05.08.2020, 17:46 --

Более формально:
из

EUgeneUS в сообщении #1477163 писал(а):

$mg \sin \alpha + N = \frac{mV^2}{R}$

$N = \frac{mV^2}{R} - mg \sin \alpha$
А теперь посмотрим, как меняется сила натяжения кордов
$\frac{dN}{dt} = \frac{2mV}{R} \frac{dV}{dt}- mg \cos \alpha \frac{d \alpha}{d t}$

$\frac{dV}{dt}$ - это как раз ускорение по продольной оси (не забываем, это ускорение по продольной оси в Со Земли, а не то, что показывает акселерометр)
$\frac{d \alpha}{d t}$ - это скорость изменения угла наклона корд к горизонту.\
То есть, имея показания акслерометра по всем трем осям, положения модели (углы наклона) и величину модуля скорости $V$, Вы легко можете рассчитать не только величину силы натяжения корд, но скорость её изменения. В данный момент времени.

[EUgeneUS]

Кстати.

GorSMS в сообщении #1477369 писал(а):

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

Ардуины вполне быстро (достаточно быстро, то есть единицы миллисекунд и быстрее) возводят в степень, вычисляют квадратный корень и тригнометрические функции.
Даже в "младших моделях", типа Arduino Uno или Arduino Mini. А вот чтобы хранить довольно большую таблицу понадобится модель с большой памятью, например Arduino Mega.

[GorSMS]

wrest в сообщении #1477413 писал(а):

Скажите, а куда направлен руль направления? Я имею в виду, если запустить самолет без корда и с выключенным мотором, он будет лететь прямо или отвернёт в сторону?

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

EUgeneUS в сообщении #1477418 писал(а):

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

К чему такие сложности? Для адекватной регулировки достаточно знать, куда направлен нос модели: если вверх, добавляем газ, если вниз, сбрасываем. По углу наклона продольной оси модели даже можно реализовать пропорциональность управления тягой. Поясню. Рассмотрим момент начала увеличения тангажа из горизонтального полета. При этом скорость, как я показал выше, около 80 км/час. Следовательно, и скорости, и момента инерции массы модели будет достаточно для того, чтобы уверенно подняться строго вертикально, как минимум на 2/3 высоты полусферы. Это, грубо говоря, около 60 градусов наклона корд к горизонту, или примерно 1/3 длины полуокружности, что при радиусе 20 метров равно 21 метру, Время, которое нужно модели, чтобы пролететь этот путь при указанной скорости, чуть меньше секунды. Так вот если команда на открытие дроссельной заслонки карбюратора пройдет в тот момент, когда нос модели только начнет подниматься вверх, мотор выйдет на максимальные обороты как раз к тому моменту, когда модели и потребуется "волшебный пинок в зад" для уверенного прохождения зенита без потери натяжения корд. Более того, к точке зенита команда на открытие дросселя будет отменена, а затем нос модели начнет опускаться вниз, и сразу же пройдет команда на полное закрытие дросселя, так как при полете вниз модель и без того разгоняется. Ну и при возвращении в горизонт вновь будет подана команда поднять обороты движка до "крейсерских" (средних).
И заметьте, весь мой "алгоритм" управления (конечно, в сильно упрощенном изложении) сводится к контролю только одного параметра - угла наклона оси $Ox$.

EUgeneUS в сообщении #1477448 писал(а):

Ардуины вполне быстро (достаточно быстро, то есть единицы миллисекунд и быстрее) возводят в степень, вычисляют квадратный корень и тригнометрические функции. Даже в "младших моделях", типа Arduino Uno или Arduino Mini.

А вот здесь Вы довольно сильно заблуждаетесь.
Во-первых, я не работаю с Дуринками. Предпочитаю голые камни. Потому что Arduino IDE чрезвычайно медленная система, не позволяющая в скоростных приложениях использовать по максимуму возможности этих 8-битных РИСК процессоров, и без того не очень впечатляющие.
Во-вторых, даже в младших моделях Ардуинок (Uno, Mini ...) стоят контроллеры ATMega328, которые уступают ATMega2560 из Ардуины Мега лишь по количеству доступных портов, но никак не по скорострельности, или по вычислительным способностям, так как у них практически одинаковый набор машинных команд, и все они не умеют делать самого главного, и времязатратного: деления. Ну и то, что все Дурилки оперируют исключительно 8-разрядными числами, тоже не добавляет энтузиазма. Нет, конечно существуют алгоритмы, позволяющие выполнять и деление, и даже извлечение корней и тригонометрические вычисления, но "единицы миллисекунд" для реал-тайм задач это сильно растяжимое понятие, и оооочень долгое... Допустим, деление двух 16 разрядных чисел выполняется любой Мегой ну никак не быстрее, чем за 100...150 машинных тактов (и это при том, что код будет написан не в Arduino IDE, или даже на чистом Си, а на ассемблере). Что уж говорить о более сложных вычислениях. А ведь потребуется еще и опрашивать акселерометр, и формировать ШИМ для управления сервомашинкой регулировки дросселем, и много чего еще...
В-четвертых, если Вы не заметили, мне не потребуется огромный массив данных, а следовательно, и большой объем памяти. Да и сам код программы в худшем варианте займет не больше 1...2 кБайт, а такай объем флеш-памяти можно найти даже у младших сестер Мег - у Тинек.
Так что, полагаю, этот раунд наших дебатов остался за мной.

[EUgeneUS]

GorSMS в сообщении #1477471 писал(а):

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

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

GorSMS в сообщении #1477471 писал(а):

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

И прекрасно.

GorSMS в сообщении #1477471 писал(а):

Во-вторых, даже в младших моделях Ардуинок (Uno, Mini ...) стоят контроллеры ATMega328, которые уступают ATMega2560 из Ардуины Мега лишь по количеству доступных портов, но никак не по скорострельности, или по вычислительным способностям, так как у них практически одинаковый набор машинных команд, и все они не умеют делать самого главного, и времязатратного: деления.

И по объему доступной памяти, ЕМНИП. О чем я и говорил - примерно одинаковы по вычислительным способностям, но различаются по размеру памяти

(Оффтоп)

В не очень навороченной программе массив 500 uint32_t на Arduino Uno влазил с трудом, а если добавить еще массив 500 uint8_t, то уже и не хватало.
Правда я на Arduino IDE делал.

GorSMS в сообщении #1477471 писал(а):

Что уж говорить о более сложных вычислениях.

Вопрос в том, сколько этих вычислений нужно сделать за "время реакции".
ИМХО, в этом приложении время реакции в 0.01 секунду (время от получения значений с датчиков до выдачи управляющего воздействия) будет вполне достаточным, с запасом. А за это время ATMega достаточное количество раз успеет разделить, умножить, вычислить синус, косинус, купить и продать.

[GorSMS]

EUgeneUS в сообщении #1477482 писал(а):

А если нос модели поднялся случайно? Пилот собирался продолжить горизонтальный полет, и получил волшебный пинок...
И всё таки, уточните, какой у Вас целевой параметр? Грубо говоря, что Вы хотите поддерживать постоянным - натяжение корд или путевую скорость?
...
В не очень навороченной программе массив 500 uint32_t на Arduino Uno влазил с трудом, а если добавить еще массив 500 uint8_t, то уже и не хватало.

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

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

В очередной раз вынужден заметить, что Вы упорно не слышите меня... Не будет у меня массива 500 uint32_t да еще и с прицепом из 500 uint8_t. Зачем мне килобайт с четвертью неизвестно чего? Максимум сотня одно-байтных значений. А 50 ячеек памяти можно легко наскрести по сусекам не только ATMega328, или ATMega168, но и в закромах старших моделей ATTiny.