Elite Games - Свобода среди звезд!
.
ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!

  » Bloodest'у про автопилот | страница 1
Конференция предназначена для общения пилотов. Для удобства она разделена на каналы, каждый из которых посвящен определенной игре. Пожалуйста, открывайте темы только в соответствующих каналах и после того, как убедитесь, что данный вопрос не обсуждался ранее.

Поиск | Правила конференции | Фотоальбом | Регистрация | Список пилотов | Профиль | Войти и проверить личные сообщения | Вход

   Страница 1 из 1
 
Поиск в этой теме:
Канал Orbiter: «Bloodest'у про автопилот»
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Bloodest, по-поводу неправильных предсказаний Орбитера длины текущего шага.

Уточнить хочу. Там есть два колбэка - clbkPreStep и clbkPostStep. Второй вызывается ПОСЛЕ щага симуляции и там длина соостветственно ПРЕДЫДУЩЕГО шага (этот колбэк соответствует старинному ovcTimeStep). Ну а первый, соответственно, дает длину того шага, который будет сейчас. Я проверял - вроде ошибок не дает.

Просто на всякий случай пишу. Может, проблема в этом?
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 15:49 04-10-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
У меня ветка начинается вот так (управление полетом РН)

void n1bisM_RN::clbkPreStep (double simt, double simdt, double mjd)
{....
Дальше идет вывал инфы в файл
.....
deb[4] = (oapiGetSimStep()-deb[3])/deb[3]*100.;
fprintf(out," %6.2f ; %5.1f; %+6.2f; %.2g %.2g \n",
oapiGetSimTime(),oapiGetTimeAcceleration (),deb[4],deb[3],oapiGetSimStep());
deb[3] = simdt;//живет до след шага

Результат

время варп ошибка прогноз реал
132.29 ; 10.0; +0.00; 0.28 0.28
132.73 ; 10.0; +57.14; 0.28 0.44
133.01 ; 10.0; -36.36; 0.44 0.28
133.28 ; 10.0; -3.57; 0.28 0.27
133.55 ; 10.0; +0.00; 0.27 0.27
133.99 ; 10.0; +62.96; 0.27 0.44
134.41 ; 10.0; -4.55; 0.44 0.42
134.68 ; 10.0; -35.71; 0.42 0.27
135.12 ; 10.0; +62.96; 0.27 0.44
135.41 ; 10.0; -34.09; 0.44 0.29

154.35 ; 1.0; +57.14; 0.028 0.044
154.38 ; 1.0; -13.64; 0.044 0.038
154.41 ; 1.0; -26.32; 0.038 0.028
154.46 ; 1.0; +64.29; 0.028 0.046
154.49 ; 1.0; -41.30; 0.046 0.027
154.51 ; 1.0; +3.70; 0.027 0.028
154.56 ; 1.0; +57.14; 0.028 0.044
154.58 ; 1.0; -38.64; 0.044 0.027

Блин, прогноз (simdt) равен текущей длине шага!
    Добавлено: 20:19 04-10-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Ну так все правильно. Сейчас вот специально сел и написал проверочный пример.

void EnergyC::clbkPreStep(double simt, double simdt, double mjd)
{
DumpToFile("pre ", simdt, oapiGetSimStep());
}

void EnergyC::clbkPostStep (double simt, double simdt, double mjd)
{
DumpToFile("post", simdt, oapiGetSimStep());
..................
}

Функция DumpToFile у меня просто сбрасывает в файл подряд свои параметры.

Вот результат:

pre 0.01 0.01
post 0.01 0.01
pre 0.085 0.085
post 0.085 0.085
pre 0.097 0.097
post 0.097 0.097
pre 0.075 0.075
post 0.075 0.075
pre 0.07 0.07
post 0.07 0.07
pre 0.069 0.069
post 0.069 0.069
pre 0.072 0.072
post 0.072 0.072
pre 0.07 0.07
...

ну и так далее. От врапа не зависит. То есть в preStep и шаг и то, что возвращает oapiGetSimStep - одно и то же. Это - шаг, который сейчас будет обсчитан.

postStep вызывается когда этот шаг уже обсчитан и величина его та же. А прогноза никакого нет - это все про текущий шаг.
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 10:40 05-10-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
Дык, елы палы, это так кажется на первый взгляд Гы-гы что все хорошо и пушисто -> здесь оооочень большая собака зарыта. Откопать ее просто

void n1bisM_RN::clbkPostStep (double simt, double simdt, double mjd)
{
fprintf(out897,"post %.4f %.4f %.4f \n\n",simt,simdt,oapiGetSimStep());
}

void n1bisM_RN::clbkPreStep (double simt, double simdt, double mjd)
{
fprintf(out897,"pre %.4f %.4f %.4f \n",simt,simdt,oapiGetSimStep());
....

Почти полный аналог НО впереди выведено время

результат:

pre 131.1890 0.5000 0.5000
post 131.1890 0.5000 0.5000

pre 131.7190 0.5300 0.5300
post 131.7190 0.5300 0.5300

pre 132.1590 0.4400 0.4400
post 132.1590 0.4400 0.4400

pre 132.6690 0.5100 0.5100
post 132.6690 0.5100 0.5100

pre 133.2090 0.5400 0.5400
post 133.2090 0.5400 0.5400

Шаги выглядят прекрасно
но вот 131.189+0,5 != 131.719 конечно же 131.189+0,53=131.719
simdt в clbkPreStep не более чем прогноз величины предстоящего шага...
    Добавлено: 18:28 05-10-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Хм... Ну, значит, недопонял я Улыбка

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

А получается вот так.

Нету там никаких прогнозов. И в preStep и в postStep речь идет о шаге, который сейчас будет. Под simdt дается длина этого шага, под simt - СЛЕДУЮЩЕЕ текущее время (время в момент завершения этого шага). См. API ref - там так и сказано SimT - next simulation run time, то есть время, которое часы покажут в следующем шаге (прогноз времени, ха-ха).

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

Суть функции preStep просто-напросто в том, что она вызывается перед расчетами действия сил для текукщего шага что дает возможность "успеть" воткнуть применение AddForce, других применений я пока не придумал.

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

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

Просто под словом Step имеется в виду обновление статуса симулятора.
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 08:32 06-10-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
Понял, большое спасибо за разъяснение...

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

Это нужно не только для ЛК3 но и с автопилотом самой Н1 я полез в дебри. Читая у Вейда о Н1 я нашел план полета Л7 (последней, которая гидроударом накрылась)и там написано что парковочная околоземная орбита - круговая 400 км. Дык простое управление тангажом по сплайну не позволило выбратся на такую высоту. Тем более что сплайн был от балды.
Порыскав надыбал элементарное изложение теории оптимального управления приминительно к РН
http://www.geocities.com/levinkirill/SpaceModel/rus/
заведя данные Н1 подогнал сплайн. Но вот незадача - управление всегда идет с ошибкой она накапливается и РН выходит на не заданную высоту, причем с очень большой ошибкой - десятки километров.
И вот сподвигся засунуть в автопилот самый простейший вариант
Teta=arctg(a*t+b).
Для интегрирования используется метод Гауса. Для нахождения коэффициентов a и b - метод Ньютона.
На старте пилот задает высоты вывода и оппозитной ему точки. Автопилот выдает начальную траеторию полета. И после запуска на каждом шагу производится поиск оптимальной траектории исходя из текущих параметров. Естественно интеграция ведется с очень большим шагом. А метод Ньютона может совершить только 5 попыток на данном таймстепе, впрочем это только нужно при начальном расчете - в полете последующие уточнения находятся за 1-2 попытки.
Естественно такая математика потребовала и соответствющего управления двигателеми в части точности ориентации. Должны невилироваться отклонения не только по углу, но и по угловой скорости. Иначе ошибка через текущее состояние будет выползать через текущее состояние в оптимизатор траектории с последующими потерями топлива.

Результат опупенный - отклонение от заданной высоты - 10-20 метров! Н1 может вывести ПН в 98 тонн на орбиты 650*650 или 200*3000.
На тайм варпе 10 точность падает - 2-3 километра и резко снижаются достижимые орбиты, наблюдается дрожание по тангажу (видимое невооруженным глазом).
Считывание в файл показало что дрожание есть и при отсутствии ускорения оно есть.
Вот отсюда и возникла мысль о таймстепах - нос гуляет вокруг нуля ошибки из за неточности управления из-за переменного шага.
Теперь ясно что это не так.
Будем искать, пока вариантов два
- Неточность управления - Орбитер интегрирует каждый шаг Рунге-Кутом 4ого порядка - если там есть изменение массы - то динамические характеристики будут изменятся.
- Флуктуации решения из оптимизатора.
    Добавлено: 10:58 07-10-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Мне теперь стыдно за мой автопилот вывода "Энергии". У меня там ошибка по высоте - от 1-5 км для низких орбит до 20 км для высот порядка 300 км. Потому я и заложил ограничения по высоте - 300 км, хотя понятно, что можно добиться вывода и на более высокий эллипс.

Правда и задача посложнее - нужно добиться приемлемой точности для любого ПГ массой от 25 до 120 тонн. Кроме того, нужно получить не круговую орбиту, а эллипс с вполне конкретными параметрами. Хорошая точность у меня пока только с наклонением орбиты (доли градуса). Есть еще одна засада - у меня управляющие моменты выдаются поворотом камер двигателей. Поворот производится реально - с конечной скоростью (около 14 градусов в секунду). И еще - в процессе полета тяга двигателей меняется исходя из ограничений по скоростному напору и по перегрузке (3 же). Да и процесс выключения двигателей тоже непростой, сначала перевод их в конечную фазу (дросселирование до 50%), потом выключение попарно... Это и "боковушек" касается, кстати.

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

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

Фактически используется некая "эталонная" траектория (она сама по себе уже далека от идеальной, так как получена просто съемкой с "натуры", при "ручном" полете с грузом 100 тонн на высоту апогея 200 км), которая растягивается по вертикали в зависимости от требуемой высоты выноса для конкретного случая. Полученную таблицу цифр (высота/наклон к горизонту) я аппроксимировал полиномом 6-го порядка.

А сам автопилот действует адаптивно в зависимости от текущих скоростей и текущей массы, стараясь при этом максимальным образом вести РН по траектории как по рельсам.

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

-----------------------------------

Что касается трепыхания по тангажу, то я тоже сталкивался с такой проблемой. По моим наблюдениям дрожание возникает в результате запаздывания реакции системы управления на реальное положение вещей. Ну, это и так понятно. А вот почему происходит запаздывание... В моем проекте есть две причины - первая, это то, что камеры вращаются к конечной скоростью (появление управляющего момента запаздывает, особенно для больших отклонений). Вторая - когда возникает попытка для малых отклонений создать большой управляющий момент (чревато перелетом мимо нуля). Второй случай возникает именно тогда, когда пытаешься включить в расчеты время шага. Поэтому я в расчеты длину шага не включаю в принципе, а использую понятие "характерное время маневра" (константа), сам придумал. Любое воздействие (то есть любое изменение угловой скорости по одному из трех каналов управления) я пытаюсь выполнить за это время (его подставляю в закон Эйлера). Опытным путем выяснил, что время это имеет минимальную величину - около 0.3 секунды. В зависимости от FPS (т.е., фактически, от шага) именно в районе 0.3-0.5 секунды возникает перелет. Фактически минимальное время маневра, при котором возникают дрожания, близко к длине шага. Максимальное характерное время маневра определяется только требуемой скоростью реакции системы, моя Энергия может сносно лететь даже при значении 10 секунд (Но для ЛК, я так понял, нужен практически мгновенный отклик).

Был у меня вариант, в котором время маневра было не константой, а высчитывалось - брал шаг и тупо умножал на 10. Но такой подход делал автопилот черезчур "дерганым". Так что сейчас у меня характерное время маневра - 0.75 сек, а врап во время старта просто запрещен.
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 12:45 07-10-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
Все, выяснил - основная причина дрожания в оптизаторе... Тут уже ни чего не поделаешь, хотя...

По тангажу у меня закон изменения arctng(at+b), тут в доме книги прикупил книженцию - сборная солянка (от динамики конструкций до теплообмена) Баллистические ракеты называеся есть там раздел по управлению тангажом. дык там говорится что и закон at+b (без тангенса имеет полные права) - тогда b - просто начальный угол тангажа а - скорость вращения, более того для токого закона приведено аналитическое решение.

Собственно дифуры не решаются, а интегрируются Гауссом с шагом в 3 секунды (те примерно 200 итераций в самом начале)
Есть начальные высота, скорости берем первое приближение а и b интегрируем, если задана конечная высота оппозитной точки до достижения заданной ею горизонтальной скорости, иначе просто до сканчания топлива. Соответственно получаем высоту и вертикальную скорость в конце. В результате можно сказать что есть два псевдоуравнения
f1(a,b)-Hзад = 0
f2(a,b)=Vh=0
Ну а эту системку Ньютом решить плевое дело.

Сечас у меня управление идет так - на заданную точность 0,01 градуса ведется сведение по линеаризованным уравнениям (+в нуле заданная угловая скорость) при попадании в 0.01 точность расширяется до 0.1 и управление идет только по угловой скорости по U=(Omz-Om)/J/dT. Время удержания в таком режиме достигло 20-30 секунд (после исправления, указанной выше моей ошибки, по неправильному трактованию шага времени). При выходе за 0,1 цикл повторяется. Лунник тупо пытается выжать максимальную точность и болтается вокруг нуля. После исправления, естественно и выросли достижимые орбиты - при полете на свободный апогей достигнута орбита 200*4300 км (в предыдущем посте я ошибся не не 9000 (это примерный радиус) а 3000)
главное что на варпе 10 результат получился 200*4600 - это уже погрешности интегрирования.

С наклонением у меня пока туго - есть только куцие данные о том как идет управление по рысканью. Собстевенно я пробывал методику описанную в аддоне востока и союза - не понравилась мне она - много потерь
Испльзую тупую последовательность
Азимут траектории
tab = asin(cos(inc)/cos(latitude));
Азимут старта (поправка на снос от вращения Земли)
iab = tab - 465./PitchM.PK.VX*cos(inc);
PitchM.PK.VX - скорость полета в конце траектории.
Азимут выдерживается в течении первых 60 секунд. Далеше просто лечу по рысканью в режиме прогрейд. Точность наклонения +-0,3 градуса.
Именнов в поправке ошибка - она систематическая - случайная часть составляет 0,05 градуса. Вроде в указанной книге уравнение поправки другое - надо попробывать.

Собственно реальная точность вывода КЛА есть тут
http://space.org.ru/Media/Books/DPKA - ошибки у Вашей Энергии почти такие же


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

Счас буду переводить линеаризацию на управление по исходной нелинейной динамике раз dT шага можно точно определить. Мот и закон упраления тангажом упростить до линейного - лафа - после выдерживания при разделении выйти на угол и скорость и бить баклуши а не подруливать под тангес. Анолитическое решение боюсь пробывать иж больно там многоэтажные формулы.
    Добавлено: 19:08 07-10-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Ну, надеюсь, теперь мы уже скоро увидим Н1? Супер!
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 08:46 10-10-2005   
Канал Orbiter: «Bloodest'у про автопилот»
 
  
Показать: 
Предыдущая тема | Следующая тема |
К списку каналов | Наверх страницы
Цитата не в тему: Два ночи, город был во мраке, мозг уже два часа, как смотрел сны: Мелек поняла - пора в интернет. (Harley)

  » Bloodest'у про автопилот | страница 1
Каналы: Новости | Elite | Elite: Dangerous | Freelancer | Star Citizen | X-Tension/X-BTF | X2: The Threat | X3: Reunion | X3: Terran Conflict | X Rebirth | X4: Foundations | EVE Online | Orbiter | Kerbal Space Program | Evochron | VoidExpanse | Космические Миры | Онлайновые игры | Другие игры | Цифровая дистрибуция | play.elite-games.ru | ЗВ 2: Гражданская война | Творчество | Железо | Игра Мечты | Сайт
   Дизайн Elite Games V5 beta.18