Маневренность Ме-109Е

[-DED-geny]

Посчитал по данным из файла .acmi угол атаки Ме-109Е (расчет в файле .xlsm) в одном из вылетов в онлайне. На графике начиная с 17.4 сек. по 19.6 сек.  Ме-109Е держит угол атаки от 25.1 до 27.3 град. без  срыва и сваливания. Не слишком ли это много для профиля крыла ( NACA 2R1 14.2 в корне и NACA 2R1 11.35 на кончике) ? Не нашел поляр для этих профилей, если найдете буду благодарен. Запись полета, файл .acmi и файл .xlsm в облаке https://cloud.mail.ru/public/tDkD/Vn4AjyieC.

 

[[I.B.]ViRUS]

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

От себя могу добавить, что к данной проге нужно относиться оооочень осторожно, поскольку она пытается натянуть "плоскоземельные" карты из Ил-2 на шарообразную землю внутри программы. Без искажений данный процесс невозможен. Для примера:

И еще:

Я делал тесты и таки да, данные по скорости при пролете диагоналей 1403 на карте Рейнланда отличаются 446 против 466 приборной при скорости 443 в игре по прибору. А при полете по линии между квадратами 1226 и 1227 на юг по прямой, таквью показывает, что траектория менялась в местах неподалёку (не точно в том же месте) от излома проекции карты БзХ на глобус. Т.е. все координаты, по которым даются расчеты, по которым даются расчеты скоростей, ускорений и пр. уже на этом этапе не совпадают. Т.е. по этой проге даже истинную скорость самолёта можно замерять с погрешностью +- 5-10% (в зависимости от точки карты). Как углы атаки в ней считаются вообще фиг знает.

[-DED-geny]

В какой проге? Прежде чем раз говорить , посмотри где и как  произведен расчет! Он сделан по данным предоставленным разрабами (файл  acmi), и в их достоверности сомнения нет!!! Никакого отношения к ТакВью это не имеет!

[[I.B.]ViRUS]

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

44 минуты назад, -DED-geny сказал:

и в их достоверности сомнения нет!!!

В дискретизации данных и в методике расчета - есть.

[-DED-geny]

13 минут назад, [I.B.]ViRUS сказал:

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

В дискретизации данных и в методике расчета - есть.

эти данные ни в какую ТакВью я не передаю. Забудь про ТакВью и проблемы с ней связанные!

Дискретизация данных 0.2 сек. вполне достаточна для точности 0,1 град. по углу атаки.

Если сомневаешся в методике, никто не мешает проверить самому. Все формулы доступны в файле xlsm

Изменено 22 апреля 2022 пользователем -DED-geny

[[I.B.]ViRUS]

10 минут назад, -DED-geny сказал:

Забудь про ТакВью и проблемы с ней связанные!

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

10 минут назад, -DED-geny сказал:

Дискретизация данных 0.2 сек. вполне достаточна для точности 0,1 град. по углу атаки.

Откуда такая уверенность? С потолка?

 

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

Изменено 22 апреля 2022 пользователем [I.B.]ViRUS

[-DED-geny]

Восхищаюсь упрямству! Открой xlsm, там все исходные данные. Никакой скорости там нет! Еще раз(последний!):  к ТАКВЬЮ и его алгоритмам этот расчет не имеет никакого отношения!!! А уверенность в знании методов численного интегрирования.

[[I.B.]ViRUS]

15 минут назад, -DED-geny сказал:

Восхищаюсь упрямству! Открой xlsm, там все исходные данные. Никакой скорости там нет! Еще раз(последний!):  к ТАКВЬЮ и его алгоритмам этот расчет не имеет никакого отношения!!! А уверенность в знании методов численного интегрирования.

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

Про методы аппроксимации знаю из личного опыта, в свое время по показаниям приборов делал ролик с измерением энергии в полете (с учетом запаздывания показаний приборов). Вот у себя я использовал более точный метод Рунге-Кутты.

Изменено 22 апреля 2022 пользователем [I.B.]ViRUS

[-DED-geny]

Да, в моменты быстрого изменения параметров погрешность возрастает. Время превышения угла атаки 25 градусов длится более 2 сек. и  все параметры достаточно стабильны (самолет стоит в вираже) и погрешность минимальна. Можно оценить погрешность метода  расчета с шагом 0,2 сек. "загнав" в исходные данные  теоретические данные установившегося виража. Я это делал  , погрешность угла атаки не будет превышать 0.1 град.

[[I.B.]ViRUS]

15 минут назад, -DED-geny сказал:

Да, в моменты быстрого изменения параметров погрешность возрастает. Время превышения угла атаки 25 градусов длится более 2 сек. и  все параметры достаточно стабильны (самолет стоит в вираже) и погрешность минимальна. Можно оценить погрешность метода  расчета с шагом 0,2 сек. "загнав" в исходные данные  теоретические данные установившегося виража. Я это делал  , погрешность угла атаки не будет превышать 0.1 град.

Условие виража, пускай даже стабильного по величине угловой скорости, есть изменение вектора. Чем меньше время виража и больше угловая скорость, тем выше ошибка. Она вызвана не колебанием угловой скорости, в дельтой разницы углов. Я понятия не имею, как "подтверждалась" точность 0,1 градуса, использованный в Экселе метод расчета не может обеспечить подобной точности в принципе при заданном шаге по времени.

Изменено 22 апреля 2022 пользователем [I.B.]ViRUS

[-DED-geny]

9 минут назад, [I.B.]ViRUS сказал:

Условие виража, пускай даже стабильного по величине угловой скорости, есть изменение вектора. Чем меньше время виража и больше угловая скорость, тем выше ошибка. Она вызвана не колебанием угловой скорости, в дельтой разницы углов. Я понятия не имею, как "подтверждалась" точность 0,1 градуса, использованный в Экселе метод расчета не может обеспечить подобной точности в принципе при заданном шаге по времени.

Проверьте, если есть сомнения, я уже сказал как это сделать.

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

[DeadlyMercury]

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

 

"Оценку точности", как и границы применения численного метода, надо смотреть вообще говоря в момент его выбора  Чтобы почитать про все это дело подробнее - гуглите методички по численным методам решения дифференциальных уравнений. Метод Эйлера и оценку погрешности метода Эйлера можно встретить в каждом первом лабнике по численным методам. Метод Рунге-Кутта - в каждом втором ну или третьем.

 

Хотя кроме метода там есть проблемы - в частности что за удивительная вещь написана в нормальной перегрузке?.. Да и вообще в любой перегрузке? Зачем вы берете нормальное ускорение, делите его на модуль полного ускорения и прибавляете потом единицу? У вас нормальная перегрузка по определению ny=Y/G, где ma=Y-mg, Y=ma+mg, ny=a/g+g/g (g - проекция g на ось z самолета). Но никак не a/|a| + 1

 

Ну и пара наглядных примеров, почему оно в общем-то не работает:

 

Это - poweroff stall. По графику крена и тангажа вы можете легко понять, когда в общем-то началось сваливание - и метод вместо угла атаки начал показывать погоду на марсе.

 

poweron stall:

Всего-лишь угол атаки в 50 градусов. Почему бы и нет.

 

Форсированный разворот:

 

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

 

И отдельный момент - все это от цвета самолета не зависит вообще. 

Як-1:

 

Срыв (достигли критического угла атаки - 18 градусов) - видно по крену. Но типа до срыва мы дошли до 25 градусов. Еще один интересный момент - сравнение перегрузки.

 

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

 

 

22.04.2022 в 06:29, [I.B.]ViRUS сказал:

От себя могу добавить, что к данной проге нужно относиться оооочень осторожно, поскольку она пытается натянуть "плоскоземельные" карты из Ил-2 на шарообразную землю внутри программы. Без искажений данный процесс невозможен. Для примера:

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

 

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

[-DED-geny]

".. Да и вообще в любой перегрузке? Зачем вы берете нормальное ускорение, делите его на модуль полного ускорения и прибавляете потом единицу? У вас нормальная перегрузка по определению ny=Y/G, где ma=Y-mg, Y=ma+mg, ny=a/g+g/g (g - проекция g на ось z самолета). Но никак не a/|a| + 1"

В расчете приведен коэффициент перегрузки  k= m(g+a)/mg= 1+a/g.  Обычно именно это имеют в виду (во сколько раз вес увеличивается по сравнению с покоем), когда говорят о перегрузках действующих на человека.

 

Уточните плиз откуда ваши графики?

 

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

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

 

Оценить точность метода расчета несложно:  упростим модель, возьмем тело движущееся по горизонтальному  кругу со скоростью скажем 300 км/ч и перегрузкой скажем 8. По формулам, можно в любой момент времени посчитать координаты и вектор(направление) скорости.  Подставим теоретически рассчитанные  координаты с шагом 0.2сек.  в расчет и сравним разницу в угле теоретической скорости и расчетной. Это и будет погрешность метода, так как угол атаки есть угол между осью самолета и проекцией вектора скорости на соответствующую плоскость.  А так, как направление оси самолета не рассчитывается , а дается разрабами в исходных данных (точное), то погрешность угла атаки = погрешности угла между теоретической и расчетной скоростью.

Несомненно, при произвольной траектории погрешность возрастет, ну постройте теоретическую кривую  по параболе или ещё какую сможете и оцените её...

Изменено 25 апреля 2022 пользователем -DED-geny

[DeadlyMercury]

4 часа назад, -DED-geny сказал:

В расчете приведен коэффициент перегрузки  k= m(g+a)/mg= 1+a/g.  Обычно именно это имеют в виду (во сколько раз вес увеличивается по сравнению с покоем), когда говорят о перегрузках действующих на человека.

Это работает только в горизонтальном полете. Во всех остальных случаях вообще говоря надо учитывать направление g.

Кроме того вы не считаете a/g - вы считаете a/|a|. Что вообще не объяснимо никак.

 

4 часа назад, -DED-geny сказал:

Уточните плиз откуда ваши графики?

Из вашего же xls, разве что формулу перегрузки поправил.

 

 

4 часа назад, -DED-geny сказал:

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

Речь вообще не о "быстром движении" и не о рывках ручки - речь идет об изменении вектора скорости. Стоять в установившемся вираже например - это тоже изменение скорости. И достаточно быстрое, поскольку угловая скорость высокая.

 

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

Что-то более-менее адекватное метод может показать в горизонтальном полете без разворотов - тот же power off stall. Разве что опять же после срыва показывается фигня, а не угол атаки.

 

4 часа назад, -DED-geny сказал:

Оценить точность метода расчета несложно:  упростим модель, возьмем тело движущееся по горизонтальному  кругу со скоростью скажем 300 км/ч и перегрузкой скажем 8. По формулам, можно в любой момент времени посчитать координаты и вектор(направление) скорости.  Подставим теоретически рассчитанные  координаты с шагом 0.2сек.  в расчет и сравним разницу в угле теоретической скорости и расчетной. Это и будет погрешность метода, так как угол атаки есть угол между осью самолета и проекцией вектора скорости на соответствующую плоскость.  А так, как направление оси самолета не рассчитывается , а дается разрабами в исходных данных (точное), то погрешность угла атаки = погрешности угла между теоретической и расчетной скоростью.

Ну, во-первых - все немного проще. Погрешность метода Эйлера - O(h). Это метод первого порядка.

 

Во-вторых, в случае движения самолета по окружности с перегрузкой 8g и скорости 300 км/ч - при точках 0.2с у вас погрешность будет равна 6 градусам. При том, что вы пытаетесь поймать значение "от 15 до 20 градусов".

Изменено 25 апреля 2022 пользователем DeadlyMercury

[-DED-geny]

15 часов назад, DeadlyMercury сказал:

Это работает только в горизонтальном полете. Во всех остальных случаях вообще говоря надо учитывать направление g.

Кроме того вы не считаете a/g - вы считаете a/|a|. Что вообще не объяснимо никак.

 

Направление g постоянно (к центру земли ). Учитывается направление a.

Я не пойму где вы увидели |a|  , в столбце AV в знаменателе g  стоит.

15 часов назад, DeadlyMercury сказал:

 

 

Во-вторых, в случае движения самолета по окружности с перегрузкой 8g и скорости 300 км/ч - при точках 0.2с у вас погрешность будет равна 6 градусам. При том, что вы пытаетесь поймать значение "от 15 до 20 градусов".

Подозреваю, что это не погрешность вычисления, а методическая ошибка. Хорошо бы просчитать тоже самое с шагом скажем 0.01с. и сравнить получившийся угол с 6 градусами. Это и будет погрешность вычисления. В расчете угла атаки надо учитывать влияние угловой скорости (что мною не сделано). Есть мысли как это сделать?  Я со своей стороны буду думать над этим. Возможно совместными усилиями удастся довести алгоритм до приемлемых значений погрешности.

 

Кстати (вы наверно это уже поняли) в расчет можно загрузить свои данные (файл .acmi) для этого на вкладке "import" надо указать путь и имя файла (поле "имя пилота" должно быть пустым) и нажать кнопку "import".  Загрузятся данные автора трека. Если в записи присутствуют сетевые игроки их имена отобразятся в правом столбце. Потом можно загрузить данные этих игроков вставив их имя или идентификатор в поле "имя пилота" и вновь нажать "import".

Потом можно выбрать отображаемые на графике параметры и диапазон времени и нажать кнопку "перестроить график".

 

 

[DeadlyMercury]

1 час назад, -DED-geny сказал:

Направление g постоянно (к центру земли ). Учитывается направление a.

Я не пойму где вы увидели |a|  , в столбце AV в знаменателе g  стоит.

А, теперь заметил. Я почему-то на столбец AU подумал. Либо у меня так волшебно импорт в гугл сработал.

Плюс еще вопрос "а на 10 то нафига" - но я так понял это чтобы на графике в ось влезало.

 

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

Суть перегрузки - это отношение силы, двигающей объект (кроме веса) к весу этого объекта. У вас не рассчитывается сила, но рассчитывается ускорение. Но ускорение рассчитывается под действием абсолютно всех сил. И вот из этого ускорения и надо выкинуть g чтобы получить правильный результат. В случае нормальной перегрузки - это не +1, а +cos(θ)*cos(ϕ). Только когда у нас крен и тангаж 0 - это равно 1. При крене или тангаже 90 - 0, в перевернутом полете - -1.

 

1 час назад, -DED-geny сказал:

Подозреваю, что это не погрешность вычисления, а методическая ошибка. Хорошо бы просчитать тоже самое с шагом скажем 0.01с. и сравнить получившийся угол с 6 градусами. Это и будет погрешность вычисления. В расчете угла атаки надо учитывать влияние угловой скорости (что мною не сделано). Есть мысли как это сделать?  Я со своей стороны буду думать над этим. Возможно совместными усилиями удастся довести алгоритм до приемлемых значений погрешности.

Это погрешность метода. Ну то есть да, "методическая ошибка". С 0.01с погрешность будет ровно на порядок меньше - опять же потому что у вас метод первого порядка. Но если вы возьмете те же 0.01 при в 10 раз большей угловой скорости - получите все те же условные 6 градусов.

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

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

https://mipt.ru/upload/medialibrary/87d/rk.pdf
https://kpfu.ru/portal/docs/F634837900/Kadushin._.Metody.resheniya.zadachi.Koshi.dlya.ODU.pdf
https://studbooks.net/2261353/matematika_himiya_fizika/chislennoe_reshenie_metodom_runge_kutta_excel_turbo_pascal
 

И так далее и тому подобное.

 

Заодно надо понять, что делать с картой и координатами. Метод, который используете вы - при полете по кругу нарисует вам элипс вместо круга, а на графике скорости будет волна идти, хотя скорость была постоянной. Похоже что ответ на этот вопрос - это действительно "плоская карта", то есть переводить это с учетом окружности земли нельзя. А как тогда это переводить - не очень понятно. 

 

1 час назад, -DED-geny сказал:

Кстати (вы наверно это уже поняли) в расчет можно загрузить свои данные (файл .acmi) для этого на вкладке "import" надо указать путь и имя файла (поле "имя пилота" должно быть пустым) и нажать кнопку "import".  Загрузятся данные автора трека. Если в записи присутствуют сетевые игроки их имена отобразятся в правом столбце. Потом можно загрузить данные этих игроков вставив их имя или идентификатор в поле "имя пилота" и вновь нажать "import".

Потом можно выбрать отображаемые на графике параметры и диапазон времени и нажать кнопку "перестроить график".

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

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

Изменено 26 апреля 2022 пользователем DeadlyMercury

[-DED-geny]

26.04.2022 в 15:44, DeadlyMercury сказал:

 

 

Это погрешность метода. Ну то есть да, "методическая ошибка". С 0.01с погрешность будет ровно на порядок меньше - опять же потому что у вас метод первого порядка. Но если вы возьмете те же 0.01 при в 10 раз большей угловой скорости - получите все те же условные 6 градусов.

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

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

https://mipt.ru/upload/medialibrary/87d/rk.pdf
https://kpfu.ru/portal/docs/F634837900/Kadushin._.Metody.resheniya.zadachi.Koshi.dlya.ODU.pdf
https://studbooks.net/2261353/matematika_himiya_fizika/chislennoe_reshenie_metodom_runge_kutta_excel_turbo_pascal
 

И так далее и тому подобное.

 

Насколько я понял, метод Рунге-Кутта применяется для диф уравнений вида y'= f (x,y) и предполагает возможность вычислять  эту функцию  f для произвольных x,y.

Пока не представляю каким боком применить это к функции y=f(t)  представленной значениями в узлах.  Будем думать...

 

26.04.2022 в 15:44, DeadlyMercury сказал:

 

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

Круто, мне бы и  в голову не пришло... ?

[DeadlyMercury]

30 минут назад, -DED-geny сказал:

Насколько я понял, метод Рунге-Кутта применяется для диф уравнений вида y'= f (x,y) и предполагает возможность вычислять  эту функцию  f для произвольных x,y.

Пока не представляю каким боком применить это к функции y=f(t)  представленной значениями в узлах.  Будем думать...

Нет. Этот метод, как и метод Эйлера, помогает вам решить диференциальное уравнение - а не найти f(x,y).

 

В задаче уже задан f(x,y) и речь идет о том, чтобы найти решение уравнения dy/dx=f(x,y) - то есть фактически найти y(x).

При этом в обоих методах (как, собственно, везде в численных методах) для решения задачи не используется аналитическое решение, а f(x,y) задается / выбирается набором точек - а не представляет из себя какое-то уравнение.

 

То есть собственно это что ни на есть та самая задача, которую вы пытаетесь решить. У вас есть набор точек (x,y,z,t) - и вы хотите найти dx/dt, dy/dt, dz/dt чтобы получить скорость. И потом повторно продиференцировать, чтобы найти ускорение. Фактически именно это вы сейчас и делаете, просто методом эйлера, как самым простым и самым неточным.

 

Изменено 27 апреля 2022 пользователем DeadlyMercury

[-DED-geny]

Появилось время , а главное желание вернуться к нашим «баранам».

Посмотрел книжку: https://obuchalka.org/2016011788006/chislennie-metodi-formalev-v-f-reviznikov-d-l-2006.html

В ней ученые мужи  написали следующие разделы:

§ 3.4. Численное дифференцирование . . . . . . . . . . . . . . . . . . . . . 127

3.4.1. Метод Рунге уточнения формул численного дифференцирования

(130).

§ 3.5. Численное интегрирование функций. . . . . . . . . . . . . . . . . . 134

3.5.1. Формула прямоугольников численного интегрирова-

ния (135). 3.5.2. Численное интегрирование с помощью

формулы трапеций (136). 3.5.3. Формула Симпсона числен-

ного интегрирования (140). 3.5.4. Процедура Рунге оценки

погрешности и уточнения формул численного интегрирова-

ния (144).

Гл а в а 4. Численные методы решения задач для обыкновенных

дифференциальных уравнений . . . . . . . . . . . . . 150

§ 4.1. Основные определения и постановка задач Коши для обык-

новенных дифференциальных уравнений . . . . . . . . . . . . . . 150

§ 4.2. Метод Эйлера численного решения задач Коши для ОДУ и

систем ОДУ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

4.2.1. Метод Эйлера для нормальных систем ОДУ (155).

§ 4.3. Метод Эйлера-Коши (Эйлера с пересчетом) . . . . . . . . . . . . 156

4.3.1. Метод Эйлера-Коши для нормальных систем (157).

§ 4.4. Метод Рунге-Кутта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

4.4.1. Метод Рунге-Кутта для нормальных систем

ОДУ (161).

§ 4.5. Выбор шага численного интегрирования задач Коши . . . . . 162

§ 4.6. Процедура Рунге оценки погрешности и уточнения числен-

ного решения задач Коши . . . . . . . . . . . . . . . . . . . . . . . . . 163

 

Численное дифференцирование описывает как найти производную функции заданной таблично

(нам это и надо т.к. скорость есть производная от координат) и  указывает 3 метода :

Конечных разностей справа

Конечных разностей слева (он то и реализован в моих расчетах)

Метод  центральных разностей (как наиболее точный из них)

Численное интегрирование , включая решения ОДУ, описывает как найти функцию по заданной таблично производной. В том числе  методами Эйлера и Рунге-Кута.

У меня нет такой задачи!

Каким раком приладить Рунге-Кута к моим расчетам , я так и не понял.

 

Посчитал тестовый пример (движение по окружности  скорость 300, перегрузка 8  ) сшагом 0.2с

Здесь расчет:

https://cloud.mail.ru/public/oRV9/YA7BGHzmD

Метод Конечных разностей слева дал погрешность (по углу скорости, а следовательно и по углу атаки в моих расчетах)) 0,55 градусов.  Откуда Меркурий взял 6 градусов?

Метод  центральных разностей дал погрешность , понятно 0.

Не исключаю ошибок , проверьте…  и если их нет повторю вопрос :

 

Ме-109Е держит угол атаки от 25.1- 0.55 до 27.3- 0.55 град. без  срыва и сваливания. Не слишком ли это много для профиля крыла ( NACA 2R1 14.2 в корне и NACA 2R1 11.35 на кончике) ?

Изменено 22 июля 2022 пользователем -DED-geny

[DeadlyMercury]

22.07.2022 в 15:52, -DED-geny сказал:

Метод Конечных разностей слева дал погрешность (по углу скорости, а следовательно и по углу атаки в моих расчетах)) 0,55 градусов.  Откуда Меркурий взял 6 градусов?

 

Банальная геометрия. Нарисуйте параболу, потом поделите ее отрезками и посмотрите как сильно будет отличаться отрезок от касательной.

[DeadlyMercury]

22.07.2022 в 15:52, -DED-geny сказал:

 

Численное дифференцирование описывает как найти производную функции заданной таблично

Именно.

 

22.07.2022 в 15:52, -DED-geny сказал:

Численное интегрирование , включая решения ОДУ, описывает как найти функцию по заданной таблично производной.

Именно.

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

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

 

Возможно Вирус предлагал вариант найти интеграл и далее дифференцировать его аналитически? А я повелся на это?

Ну либо это не Рунге-Кутта, а Рунге-Ромберга?.. Сложно сказать сейчас.

 

22.07.2022 в 15:52, -DED-geny сказал:

Метод  центральных разностей (как наиболее точный из них)

Ключевое.

 

22.07.2022 в 15:52, -DED-geny сказал:

Посчитал тестовый пример (движение по окружности  скорость 300, перегрузка 8  ) сшагом 0.2с

Здесь расчет:

https://cloud.mail.ru/public/oRV9/YA7BGHzmD

Перегрузка просто не 8g. 

 

А так да - на идеальной окружности центральный метод даст погрешность ноль. Проблема только в том, что у нас нет окружностей совсем.

 

UPD та самая "парабола":

 

Изменено 25 июля 2022 пользователем DeadlyMercury

[DeadlyMercury]

UPD2 посмотрите еще вот это, сразу с формулками, которые в теории можно не долго думая зафигачить в эксель:
https://codetown.ru/matlab/chislennoe-differencirovanie/

22.07.2022 в 15:52, -DED-geny сказал:

Ме-109Е держит угол атаки от 25.1- 0.55 до 27.3- 0.55 град. без  срыва и сваливания. Не слишком ли это много для профиля крыла ( NACA 2R1 14.2 в корне и NACA 2R1 11.35 на кончике) ?

Самый главный мой вопрос вы к слову проигнорировали.

Почему именно ме-109е? Я вам выше показал график, который выдал 50 градусов угла атаки для ла-5 и 25 градусов для як-1. То есть что косяк таки не в самолете - а именно в методе.

 

Ну то есть возьмите ваш же метод и засуньте в него трек энергичных разворотов на лавке - станет ли вдруг метод лучше? Или будет показывать ту же ересь, что и для ме-109, на основании которой вы делаете вывод, что с ме-109 что-то не так?

Изменено 25 июля 2022 пользователем DeadlyMercury

[-DED-geny]

45 минут назад, DeadlyMercury сказал:

 

Ключевое.

поправлю расчет, это не трудно.

 

Вопрос в том, как оценить точность? Есть мысли?

 

47 минут назад, DeadlyMercury сказал:

 

Перегрузка просто не 8g. 

Да, я ступил.

 

 

 

24 минуты назад, DeadlyMercury сказал:

UPD2 посмотрите еще вот это, сразу с формулками, которые в теории можно не долго думая зафигачить в эксель:
https://codetown.ru/matlab/chislennoe-differencirovanie/

Самый главный мой вопрос вы к слову проигнорировали.

Почему именно ме-109е? Я вам выше показал график, который выдал 50 градусов угла атаки для ла-5 и 25 градусов для як-1. То есть что косяк таки не в самолете - а именно в методе.

 

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

[DeadlyMercury]

25 минут назад, -DED-geny сказал:

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

Извини, но я-августовский не смогу тебе прислать треки от я-апрельского

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

 

Собственно я именно это в апреле и делал - сначала демонстрация poweroff stall и poweron stall - а затем просто полетать с разгонами-разворотами-петлями. То есть никакой магии или каких-то суперсекретных маневров я не делал. В том числе можешь тупо разогнаться - а потом перейти в интенсивный разворот с потерей скорости или в петлю опять же с потерей скорости. Суть в том, что чем сильнее меняется твоя траектория (и будет отличаться от окружности в том числе) и чем больше у тебя будет угловая скорость - тем большую ошибку тебе выдаст метод. То есть начать делать петлю на 500 и тянуть ее почти до срыва по вибрации/шуму до 300-250 - и получишь к этим 300-250 угол атаки в 25-30 градусов. Хотя если повторишь тот же срыв в горизонтальном полете - получишь перед срывом угол атаки плюс-минус описанный в свойствах самолета. А если допустишь срыв - то там вообще метод показывает нечто невразумительное сразу. 

 

25 минут назад, -DED-geny сказал:

Вопрос в том, как оценить точность? Есть мысли?

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

 

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

25 минут назад, -DED-geny сказал:

поправлю расчет, это не трудно.

Нет, "ключевое" не то что он "точный" - а то что он "точный из них"  Грубо говоря самая вкусная из трех какашка.

Но он по-прежнему метод первого порядка.

Изменено 25 июля 2022 пользователем DeadlyMercury

[-DED-geny]

6 минут назад, DeadlyMercury сказал:

Извини, но я-августовский не смогу тебе прислать треки от я-апрельского

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

 Косяки в методике?  В методике чего? формул дифференцирования? Сомневаюсь.  Проблема с большим шагом да, есть. Я уже говорил , что не рассматриваю "быстрое"  движение. Я привел участок траектории Ме109, когда самолет стоит практически в стабильном (пусть и не установившемся, пусть форсированном) вираже в течении примерно 4-5 сек без "кувырканий".

[DeadlyMercury]

Только что, -DED-geny сказал:

 Косяки в методике?  В методике чего? формул дифференцирования? Сомневаюсь.  Проблема с большим шагом да, есть. Я уже говорил , что не рассматриваю "быстрое"  движение. Я привел участок траектории Ме109, когда самолет стоит практически в стабильном (пусть и не установившемся, пусть форсированном) вираже в течении примерно 4-5 сек без "кувырканий".

Еще раз: "стабильный" для этого метода - это ни в коем случае не вираж, а горизонтальный полет. Добейся от ме-109 полета на 25 градусах атаки в горизонте (на планировании без двигателя или в наборе на низкой скорости с двигателем) - и ты даже своим методом сможешь показать, что с углом атаки у ме-109 что-то не так. Только тебе твой же метод в этом эксперименте покажет 20 градусов - а не 25-27.

 

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

 

 

Проблема именно в методе. То есть именно в "формуле дифференцирования". Что при таком шаге этот метод может показывать что-то полезное разве что в горизонтальном полете. Что ты получил 0.6 градуса погрешности в развороте за 65 секунд - в обычном установившемся вираже за 22 секунды это будет уже 1.8 градуса, в три раза больше. Что это метод первого порядка. Сомневатья тут нет смысла - просто посмотри ссылку и используй метод 4 порядка:

https://codetown.ru/matlab/chislennoe-differencirovanie/

 

Либо - тебе надо выбрать меньший шаг. Не 0.2 секунды - а 0.01 секунды. Есть только одна проблема - ты это не можешь сделать физически.

[DeadlyMercury]

46 минут назад, -DED-geny сказал:

Косяки в методике?  В методике чего? формул дифференцирования? Сомневаюсь.  Проблема с большим шагом да, есть.

Кстати говоря вообще эта фраза странная.

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

 

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

против

 

ну получится у тебя результат для точки посередине между шагами - ну и что? между этими точками один фиг будет h.

Бонусом там есть формула для второй производной:

 

Изменено 25 июля 2022 пользователем DeadlyMercury

[-DED-geny]

25.07.2022 в 18:29, DeadlyMercury сказал:

 

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

С промежуточным узлом в Екселе не удобно работать. Нашел  другие формулы по 4 точкам  , правда 3 го порядка:

Для тестирования точности, по  уравнениям ниже   с шагом  0,01с посчитал (проинтегрировал) «мертвую петлю».

С начальными условиями V=300км/ч; Nxa=0; Nya=6. Причем  нормальную перегрузку будем увеличивать с темпом 1 за 8 сек. (Nya=6 +1/8*t).

 

Получилась такая  («эталонная») траектория в которой меняется скорость (как по углу так и по модулю) и перегрузка :

попробовал восстановить «эталонную» скорость по координатам с шагом 0,2с  разными методами и посмотреть ошибки.

 

 

Метод 3 го порядка дал ошибку по углу 0,3 град. И показал результат почему-то  лучше , чем метод 4 го порядка (от Меркури).

Все расчеты в  екселе здесь: https://cloud.mail.ru/public/P14L/pjD8HRuXA

Если замечаний нет, применю метод 3го порядка для расчета обсуждаемого трека.

Изменено 28 июля 2022 пользователем -DED-geny

[DeadlyMercury]

10 часов назад, -DED-geny сказал:

Метод 3 го порядка дал ошибку по углу 0,3 град. И показал результат почему-то  лучше , чем метод 4 го порядка (от Меркури).

И это странно.

Но я из интереса попробовал другую формулу y'(i)=(y(i-2)-8y(i-1)+8y(i+1)-y(i+2))/12h - она дала плюс-минус такой же результат, что и эти "полшаговые".

 

В остальном - 

 

Особенно:

10 часов назад, -DED-geny сказал:

Для тестирования точности, по  уравнениям ниже   с шагом  0,01с посчитал (проинтегрировал) «мертвую петлю».

С начальными условиями V=300км/ч; Nxa=0; Nya=6. Причем  нормальную перегрузку будем увеличивать с темпом 1 за 8 сек. (Nya=6 +1/8*t).

Это интересная идея сама по себе. Как обычно это делают ленивые математики: берут рандомную кривую (аналитическое уравнение) и считают точки по ней.

Грубо говоря как в примере с матлабом взяли sin(x) и упорно находили ее производную, прекрасно зная что должно получиться. Интересно правда найти формулу кривой похожей на полученную петлю, но это скорее надо вольфрам насиловать

 

Изменено 28 июля 2022 пользователем DeadlyMercury

[-DED-geny]

Ниже новый расчёт. График старого  угла атаки приведен тем же цветом частым пунктиром(разница не превышает 3 град.). На графике начиная с 17.4 сек. по 19.6 сек.  Ме-109Е держит угол атаки от 22.4 до 24.1град( с учетом ошибки в 0,3 град).  Бред!!! Кстати угол атаки срыва для Як-1б в том же треке достиг 22 град.(с учетом ошибки 0.3) на 17,6 сек.   Да, и если довести эти ЛА до срыва в горизонтальном полете , цифры будут совсем другими.

Ме-109

Як-1б

 

 

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

 

 

 

[DeadlyMercury]

Мы много чего на самом деле не учитываем. Поэтому полчить 24 при "паспортном" 20 и 22 при паспортном 18 - вполне нормально.

 

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

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

Косяк есть даже в полете по прямой: при полете курсом скажем 170 - рассчет покажет другой курс. Как с этим бороться - я не знаю.

 

Далее уже можно вспоминать про всякие нюансы типа спрямление потока перед крылом винтом, угла установки крыла и так далее. В частности, сравнить угол сваливания в прямом полете без мотора (на планировании) и с мотором (в наборе) - наверняка будет какое-то отличие. Точнее не "наверняка будет" - а "должно быть", потому что такое отличие есть irl.

 

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

[-DED-geny]

2 часа назад, DeadlyMercury сказал:

Мы много чего на самом деле не учитываем. Поэтому полчить 24 при "паспортном" 20 и 22 при паспортном 18 - вполне нормально.

 

В первую очередь - у нас есть косяк с переводом координат. Грубо говоря с банальной геометрией. Мы считаем, что земля плоская - а в игре земля круглая. Это, например, вылезает так: ты можешь перевести самолет в автогоризонт и зажать автопилоту поворот влево или вправо. В результате ты получишь очень медленный разворот и идеальный круг с постоянной угловой скоростью. Причем скорость ты видишь глазами, а угловую скорость можно посчитать по компасу и убедиться, что она константа.Если после этого перевести данные из трека тем же способом что используешь ты - мы получим не круг, а элипс. И у нас будет "гулять" скорость полета и угловая скорость синусоидой.

 

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

2 часа назад, DeadlyMercury сказал:

 

Косяк есть даже в полете по прямой: при полете курсом скажем 170 - рассчет покажет другой курс. Как с этим бороться - я не знаю.

 

В навигации с этим борются пересчетом в ортодромические координаты. Полет вдоль меридиана курсом 270 или 90 не должен менять курс.

 

2 часа назад, DeadlyMercury сказал:

 

Далее уже можно вспоминать про всякие нюансы типа спрямление потока перед крылом винтом, угла установки крыла и так далее. В частности, сравнить угол сваливания в прямом полете без мотора (на планировании) и с мотором (в наборе) - наверняка будет какое-то отличие. Точнее не "наверняка будет" - а "должно быть", потому что такое отличие есть irl.

 

Угол установки известен "паспортный" , а вот с обдувом полная неизвестность. Хотя это отличная идея : сравнить "полет без мотора (на планировании) и с мотором (в наборе)". так можно оценить влияние обдува.

 

2 часа назад, DeadlyMercury сказал:

 

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

Я своё любопытство удовлетворил :). Есть Ексель файл, в котором реализован расчет и возможность легко загружать исходные данные и строить графики. Кто хочет, может экспериментировать...  https://cloud.mail.ru/public/eCeT/eXvDJotGD