Создание собственной системы стабилизации
О AeroSim RC я даже не слышал )
а я им вроде бы даже в этой ветке когда-то хвастался (железный CC подключен через GSC к симу) 😉
на то время это был единственный модельный симулятор с поддержкой плагинов (то есть полным доступом ко всей внутрянке). пробовали использовать X-Plane, Flightgear и даже Ил-2, но боинги и цессны все-таки имеют другие масштабы. с подачи OP-сообщества пробовали пинать разработчиков Aerofly, RealFlight, Phoenix RC и прочих ClearView, но откликнулся только разработчик Аэросима. причем не только откликнулся, но и добавил много чего по просьбам трудящихся.
принцип там такой же, как у X-Plane, dll-ка имеет доступ к нужным параметрам и большинство из них может изменять. самое сложное — перенастроить модель в самом симуляторе, чтобы отключить все встроенные помогайки и оставить только прямое управление моторами/плоскостями.
p.s.
а, киллер-фичу забыл: в Аэросиме можно рулить стабилизированой бортовой камерой (время 4:30 в вышеуказанном видео).
это слишком примитивно.
у коптера факторы только для каждого вмг
- яв фактор по часовой или против
- рол фактор влияние на крен
- питч фатор влияние на пикирование
если будут тяговые моторы то еще форвард фактор для всех моторов
Всё это есть, для коптера на любую конфигурацию можно настроить, моторы хоть в шахматном порядке (см. картинку).
а, киллер-фичу забыл: в Аэросиме можно рулить (стабилизированой) бортовой камерой
Это классно, но для испытаний АП не особо нужно. Вот если б полная иммитация механики (энерции, вибрации) подвеса, то можно бы было ПО для стабов подвесов пробовать )
рулевые плоскости
-изменение отклонения вызывает изменение силы воздействющей на один из факторов, сила зависит не только от угла отклонения но и от обдува но не линейно.
обдув это не только воздушная скорость но и обдув потоками с винтов
Вот всё кино исключительно в том, что нелинейно. Иначе бы я просто доп измерение в микс добавил - аэро. А тяга там и так есть, ставь соответсвующий коэффициент и всё. Поэтому надо придумать мин и дост набор примитивов для описания и ввода нелинейностей
Вот если б полная иммитация механики (энерции, вибрации) подвеса
хех, это уже отдельный симулятор выйдет.
Вот всё кино исключительно в том, что нелинейно.
а какая, по большому счету, разница? всякие обдувы и прочие факторы всего лишь та самая ошибка, которую и должен уменьшить ПИД-регулятор, к примеру, причем пользуясь единственным доступным ему способом — отклонением плоскости. ведь ему (ПИД-регулятору) совершенно неизвестно, вызвано ли отклонение модели от заданного положения ветром, обдувом, пролетающей птицей или брошенным камнем.
сошлюсь опять на свое видео, 2:25 — влияние турбулентностей. включил ветер, добавил ему “неспокойности”, модель с теми же самыми миксами и ПИД-ами продолжает выдерживать положение и направление. несмотря на кособокий полет.
а какая, по большому счету, разница?
Разница есть, см. мое видео 1:18 и 1:44, при высокой скорости эффективность рулей резко растет и начинается раскачка. Более того раскачка может начаться сама по себе при закритичной скорости. Так что приборную скорость нужно отслежтвать и менять коэффициенты.
Хплан очень хорошо отрабатывает физику (жесткость, упругость, кручение), твой же сим видимо вообще этим не заморочен. Не в обиду, но мне кажется эти фактры стоит учитывать.
раскачка есть следствие малой и нестабильной частоты опроса “датчиков”, а любой цифровой ПИД-регулятор чрезвычайно критичен к этим цифрам. железки худо-бедно работают на сотнях герц, дорогущие коммерческие модельные IMU уже на килогерцах, а у вас “обычно 25-35”. тяжелым и инертным боингом рулить можно, отлаживать работу автопилота по маршрутным точкам тоже кое-как можно. а посмотреть, как железка справится с реактивной моделькой — уже нет.
у Аэросим-а та же беда, либо ограничиваем опрос до 60-75-120 Гц вертикальной синхронизацией, либо отключаем ее и получаем 300-400 Гц (сим-то к компьютеру не требовательный) и гарантированный затык в любом внешнем протоколе обмена. но 60 всяко лучше, чем 30.
по поводу жесткости и прочего. X-Plane еще и профиль плоскостей и форму фюзеляжа учитывает (модель табуретки может и не полететь, в отличии от MFS), но только с таким шагом, что в промежутках поместится несколько коптеров. XP технически неспособен проводить симуляцию моделей малых размеров, любые попытки это сделать вынуждены натыкаться на масштабирование и/или ускорение внутреннего времени.
а “мой” сим довольно честно имитирует (как и остальные модельные симы) поведение мотора с винтом, к которому присобачены плоскости с выбранным профилем либо другие моторы в виде абсолютно жесткого тела. ибо никто не запаривается тем, что у тридцатисантиметрового коптера при резком газе лучи смещаются на доли миллиметра. зато имеется настройка скорости и отклика для сервоприводов, учитывается масса ротора (для симуляции обратного момента), есть учет изменяемого в полете топлива (смещение ЦТ) и падение напряжения (мощности) на аккумуляторах и еще кучка именно модельных параметров.
Возвращаясь к истокам беседы, мне вот интересно, как в симуляторе отладить с нуля писаную ИНС?
если теоретически, то взять входные данные из сима, подсунуть их ИНС и посмотреть на результат. а на практике — только в связке с конкретными датчиками/сенсорами, ибо шумы/дрейфы/погрешности симуляторы не симулируют.
Дмитрий, кстати а чего опенпилоты, разбежались?
сижу курю их екф и - это чё чтобы шпионы не догадались?
void SerialUpdate(float H[NUMV][NUMX], float R[NUMV], float Z[NUMV],
float Y[NUMV], float P[NUMX][NUMX], float X[NUMX],
uint16_t SensorsUsed)
{
float HP[NUMX], HPHR, Error;
uint8_t i, j, k, m;
// Iterate through all the possible measurements and apply the
// appropriate corrections
for (m = 0; m < NUMV; m++) {
if (SensorsUsed & (0x01 << m)) { // use this sensor for update
for (j = 0; j < NUMX; j++) { // Find Hp = H*P
HP[j] = 0.0f;
for (k = 0; k < NUMX; k++)
HP[j] += H[m][k] * P[k][j];
}
HPHR = R[m]; // Find HPHR = H*P*H' + R
for (k = 0; k < NUMX; k++)
HPHR += HP[k] * H[m][k];
for (k = 0; k < NUMX; k++)
K[k][m] = HP[k] / HPHR; // find K = HP/HPHR
for (i = 0; i < NUMX; i++) { // Find P(m)= P(m-1) + K*HP
for (j = i; j < NUMX; j++)
P[i][j] = P[j][i] =
P[i][j] - K[i][m] * HP[j];
}
Error = Z[m] - Y[m];
for (i = 0; i < NUMX; i++) // Find X(m)= X(m-1) + K*Error
X[i] = X[i] + K[i][m] * Error;
}
}
}
я то дурак всё голову ломал, чёй-то с екф загрузка проца 18% вот досюда всё чики-пуки // Find HPHR = H*P*H’ + R , а потом должно быть так K = HP*invHPHR (т.е. умножение на обратную матрицу), а что мы видим K = HP/HPHR - ход конём прям, вместо этого взять и разделить? Кстати - там затык конкретный матрица 16Х16 не то что я балуюсь с 3Х3
скажу просто “сменились люди”, чтобы сор не выносить. но все-таки хочется надеятся, что форум и вики не работают временно, а не по причине “всё”. что выпиливание поддержки старых моделей из последнего софта ради “клонов” Revo Nano и CC3D Atom обусловлено аппаратными проблемами, а не денежными…
а про EKF не только шпионы не догадывались 😉
лаг ЖПС у тебя перекрывается уже здесь: инав_позиция = инав_позиция * 0.998 + жпс_позиция * 0.002 и служит это дело для долгосрочной коррекции “уплывания” интегратора и совершенно пофиг, что оно лагает пока ЖПС “доплывёт” до пределов способных существенно влиять на интегратор - оно усреднится так, что мама не горюй… короче показания будут правдоподобны…
Сереж, это была отличная идея. видя по логам что частота собственных колебаний системы 1/5 Гц подобрал экспериментально минимальный коэфициент при котором скорость спадает секунд за пять и … это полетело
Тимур - тестировщик мечты.
зима, ночь, минус 10, толково выполнил все инструкции и облетал.
на будущее
багофиксы основного функционала:
- в настоящей прошивке улучшения обсчета компаса пока нет, делать будем - но это не первоочередное и ненужно смешивать. формально я знаю почему но пока решение не писал. Полагаю что причина в том что данные регистров компаса накапливаются и усредняются в системе координат земли. затем к этим накопленным данным происходит подтяг курсового гироскопа. если происходит быстрое вращение то данные компаса запаздывают и утягивают компас в сторону противоположную вращению
-каков бы не был минимальный лаг жпс нужно будет обмерять мтк и юблокс и сделать программную компенсацию лага за время задержки жпс
- нужно искать в инерциалке причины недостаточно точных измерений ускорений, это можно сделать в домашних условиях
зы. напрасно я сделал усиление подтяга на скорости. по логам как только скорость растет свыше 1мс до трех осциляции прогрессируют - явно этот коэф мешает…
в этом графике видно что при скорости по жпс < 1мс осциляций инерциальной скорости нет (красный тренд в см/с)
float spd_kff = mapf(constrain(fabs(pythagorous2(_velocity.x, _velocity.y)), 100.f, 300.f) ,100.f ,300.f , 1.f , 3.f ); // speed 0-100 cm per second spd_kff = 1 200=2 300 and above = 3
_gps_k_gps_spd = (float)_gps_k_spd * spd_kff /1000.0f; //v7 10 000 v008 1000
_gps_k_inav_spd = 1.0f - _gps_k_gps_spd ;
_gps_k_gps_pos = (float)_gps_k_pos * spd_kff /1000.0f; //v7 10 000 v008 1000
_gps_k_inav_pos = 1.0f - _gps_k_gps_pos ;
зы. напрасно я сделал усиление подтяга на скорости.
фильтр должен быть адаптивный, ты не смотрел - Hdop на скорости часом не растёт?
у нас есть такие параметры как вибрации, hdop, “количество звёзд на небе” высота (ну тут hdop везде сработает) вот и выстраиваешь если hdop>2.8 - коэф=о и всё доверие акселю, и чем меньше hdop увеличиваешь доверие ЖПС - т.е. увеличиваешь коэф влияния его на интегратор? плюс на скорости коптер наклоняется - 100% часть спутников он в этот момент теряет… да и для скоростей больше доверие акселю, для положения - меньше, т.к. там уже двойное интегрирование…
p.s. по видео так прям зима, а у нас дожди (((
ты не смотрел - Hdop на скорости часом не растёт?
Hdop штука загадочная и весьма абстрактная. по логу он всю дорогу 0,62 а спутников 17
если интересно лог посмотреть …apmcopter.ru/…/2015-12-04-17-43-03-zip.1460/
пересобрал новую версии прошивки где поставил переключение бауда жпс на 115200 а скорости обновления на 10гц с тем чтобы сократить задержку данных.(тоесть посылает жпс модулю на скорости 38400 команду на переключения на 115200 и сам преходит на этот бауд)
в числе прочего сделал выдачу rmc строки раз в полсекунды она несет в себе из полезного только дату, а основное есть в gpgga (для уменьшения объема данных)
фильтр должен быть адаптивный
думаю жесткую лимитирующую окружность сделать по позиции и диапазон расхождения скоростей для предотвращения сильных рассогласований инав и жпс
но пока даже на небольших коэфициентах этого не наблюдается
зы. цель переписывания инерциалки - предотвращение “туалетной воронки” и улета в случае если компас неправ
давай там forum.apmcopter.ru/threads/…/page-6 писать, а то в 2-х местах всё перемешается…
а про EKF не только шпионы не догадывались
это болезнь, или я чего-то не догоняю
K_k=(P_apr*H_k(1:3,1:12)'/(S_k));
- это в пиксе, оказывается все так делают, может это я отстал от жизни? неее - уже никто никуда не летит…
Оптимальная по Калману матрица коэффициентов усиления, формирующаяся на основании ковариационных матриц имеющейся экстраполяции вектора состояния и полученных измерений (посредством ковариационной матрицы вектора отклонения):
ну так же должно? -1 -'это не степень - это обратная матрица грубо - это матрица S*S-1=E(единичная матрица у которой все нули кроме главной диагонали - где единицы), а S/S нифига не E
поскольку глубоко в коде екф маленький вопрос.
почему если у пикса екф отвалил датчик то это навсегда.
я пробовал полет на ардукоптер 3.2 с екф. альтхолд без баро очень неудобный режим
недавно Дмитрий Чернов очень прикольно это описал
“Запустил на Пихоке Коптер 3.3.2
Очень интересно наблюдать за статусом екф. Поднёс отвёртку к компасу - компас отвалился. снял пену с баро и посветил - баро отвалилось.
Но почему-то обратно отвалившееся не подключается, а в принципе-то ничто не препятствует - проверять уместность показаний глюкнувших датчиков и по прошествии какого-то количества годных отсчётов включать в рассчёт.”
надо найти это место в коде арду - боюсь та же ошибка, по сей причине доверие датчикам не возвращается 😦 я ка-то сел в уголке и пересчитал на бумажке первую интерацию, даа бумажек было много)))
показываю код арду один раз, и пошел я писать собственную прошивку (
float varInnovInv = 1.0f / varInnov;
varInnov -это матрица S
показываю код арду один раз, и пошел я писать собственную прошивку (
а для непосвященных как это можно использовать?
а, кажись понял - это деление матриц из опенпилота которое сжирает производительность
нет ты не понял - это те же грабли что и в опенпилоте пикссе и ещё чёрт знает где - короче это неправильно!
S-1 = 1/определитель матрицы * ST (транспонированную матрицу S) - вот это так сожрёт производительность, что надо задумываться брать пачку F7
вот что в этом деле будет жрать немерено
а уже транспонирование - это легко столбцы со строками местами поменять…
искал почему инерциалка не рисует коробочку при коротких перемещениях…
путь явно занижен…
и кажись нашел очень большие грабли.
Еще раз спасибо Дмитрию Чернову за идею с коробочкой.
делаем такой эксперимент.
- кладем полетник на большую горизонтальную плоскость
- включаем отображение графика питча
- касаясь дном полетника ровной плоскости водим вперед - назад с размахом метр с периодом в секунду.
я сделал самый минимальный подтяг гироскопа к акселю какой позволяет арду из параметров
и увидел о ужас!
горизонт гуляет отседова искривление эрч фрэйма и ошибки калькуляции
и отсюда же просадка некоторых аппаратов в быстрых пролетах
что думаете товарищи?
надо учитывать горизонтальные ускорения при расчете надира к которому тянется горизонт ахрс
надо учитывать горизонтальные ускорения при расчете надира к которому тянется горизонт ахрс
Лучше привязать к модулю трехмерного вектора ускорения.
Лучше привязать к модулю трехмерного вектора ускорения.
хорошо бы.
github.com/kozinalexey/…/AP_AHRS_DCM.cpp#L678
поменял на единичку, подправил типы - загрузил проверил на апм - ничего не изменилось хотя похоже было на то что нужно
varInnov -это матрица S
уточню - это вообще какая-то хрень
поменял на единичку, подправил типы - загрузил проверил на апм - ничего не изменилось хотя похоже было на то что нужно
это тут не причём
надо учитывать горизонтальные ускорения при расчете надира к которому тянется горизонт ахрс
отдаём доверие гирам (угол который получился) берём за основу вычисления горизонтальных ускорений, вычитаем их из расчёта углов с акселя - задница конечно, но на столе посмотреть можно, и так вот кучу костылей вставляешь в чужее ПО ещё и виноватым останешся (
а вообще надо корректировать аксель по кривому компасу…