Создание собственной системы стабилизации

alexeykozin
rual:

изменяемая позиция выборки из буфера инециалки?

жпс настраивается на 10 гц
при каждом поступлении новых данных запоминается текущие значения позиции и скорости инерциалки и проталкивается вниз буффера
буффер на 5 ячеек, в зависимости от необходимости можно снимать задержку за 1,2,3 или 4 сэмпла назад тоесть за 0,1 - 0,4 сек
вычитая из текущего состояния инерциалки ее состояние некоторое время назад получаем дельту позиции и скорости за заданный промежуток времени
эту дельту добавляем к текущим показаниям жпс при выборе точки к которой “подтягивается инерциалка”

rual
alexeykozin:

вычитая из текущего состояния инерциалки ее состояние некоторое время назад получаем дельту позиции и скорости за заданный промежуток времени
эту дельту добавляем к текущим показаниям жпс при выборе точки к которой “подтягивается инерциалка”

Мудрёно))

rual

Алексей, терзают смутные сомнения, в твоей коррекции присутствует положительная обратная связь, ГНСС+дельтаИНС тем больше, чем больше убегание ИНС вперед за время задержки от предыдущего состояния. Я всё правильно понял, не ошибся? Если так, то чревато расскачкой (причем внутренней, математической) даже с ровным наложением ИНС и азимута.

alexeykozin
rual:

ГНСС+дельтаИНС тем больше, чем больше убегание ИНС вперед за время задержки от предыдущего состояния. Я всё правильно понял, не ошибся?

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

эквивалентом было бы сохранить в массив на 50-100 элементов данных в быстром цикле инерциалки ускорения по осям ax ay и dt а в цикле синхронизации жпс данных получать суммированием из ускорений и dt дельту скорости и позиции за заданное время задержки жпс данных (за время соотвествующее сумме dt), но на апм такое просадило бы проц и заняло бы существенный кусок оперативы - поэтому сохраняю готовые ускорения и перемещения с интервалом поступления ГНСС данных

oleg70
alexeykozin:

дельта инс не имеет интегратора,

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

alexeykozin
oleg70:

Т.е. фактически у Вас не дельта скорости на выходе а дельта ускорения…

в настоящее время беру и скорость и текущую позицию прямо из расчетов инерциалки
сохряняю текущую позицию и скрость в буффер “снизу” это проталкивает данные наверх, сэмплов 5, шестой затирается.
github.com/kozinalexey/…/AP_InertialNav.cpp#L255

_hp_x.push_back(_position.x); //save current inav position to buffer back point for calculate position change during gps delay
_hp_y.push_back(_position.y);

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

github.com/kozinalexey/…/AP_InertialNav.cpp#L268

_gps_position_lag_x = _position.x - _hp_x.peek(_gps_sample_number); //peek 0 400ms peek 1 300ms etc
_gps_position_lag_y = _position.y - _hp_y.peek(_gps_sample_number);	

но на быстрых процах можно было бы из ускорений все считать

oleg70:

Ну да ладно, а результат проверки этого алгоритма в полете можете прокоментировать ? лучше стало ? (насколько)…

визуально сильно снизилась тенденция к раскрутке по спирали при ошибке компаса, при анализе логов уменьшилось расхождение между координатами ГНСС и INAV. я вывел в лог в пакете INAV параметры LA LN с тем чтобы можно было сравнивать инерциальные координаты с данными навигационного приемника gps LAT LNG прямо в анализаторе логов мишен планера

rual
oleg70:

Т.е. фактически у Вас не дельта скорости на выходе а дельта ускорения… а прибавляете вы ее, если не ошибаюсь, к расстоянию по жпс… как то не клеится (??)…

да нет, всё клеится РастИНС1-РастИНС0 = дельтаРастИНС, это как раз и есть расчет ИНСки между отсчетами ГНСС, т.е. актуализация положения между отсчетами ГНСС. дельтаРастИНС/dt = СкоростьИНС (за период dt); где dt - период получения данных ГНСС. Алексей, коэффициент притяжки ИНС и период обновления ИНС какие?

alexeykozin
rual:

Алексей, коэффициент притяжки ИНС и период обновления ИНС какие?

_gps_k_gps_spd =0.003 к 0.997 (подтяг скорости )
_gps_k_gps_pos =0.008 к 0.992 (подтяг позиции )

осуществляется с частотой около 100 гц

_position.x = _position.x * _gps_k_inav_pos +  (_gps_position.x + _gps_position_lag_x) * _gps_k_gps_pos; //pool inav position to gps position
_position.y = _position.y * _gps_k_inav_pos +  (_gps_position.y + _gps_position_lag_y) * _gps_k_gps_pos;


_velocity.x = _velocity.x * _gps_k_inav_spd + (_gps_velocity_x + _gps_velocity_lag_x) * _gps_k_gps_spd ; //pool inav velocity to gps velocity
_velocity.y = _velocity.y * _gps_k_inav_spd + (_gps_velocity_y + _gps_velocity_lag_y) * _gps_k_gps_spd ;

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

oleg70
alexeykozin:

к раскрутке по спирали при ошибке компаса,

компас, я так понял, смешивается с гирой и акселем в общий алгоритм ориентации ИНС (типа алго магвика и махони)??

alexeykozin:

визуально сильно снизилась тенденция к раскрутке

тогда - это результат (!), поздравляю…

oleg70

Я тут был воодушевлён применением RPi в качестве контроллера полета… Так вот последние изыскания показали, что при работе с SPI многозадачный линукс становится фактически однозадачным… Иными словами - запустив в одном терминале процесс обмена данными по SPI и их выводом на экран, другие задачи запускаться не собираются до тех пор пока мы не убьём этот процесс…
Вывод: нафига тогда всё это (?), и вопрос по передаче видео по WiFi и тому подобное отпадает сам собой… Не понятно как люди, делающие платы типа “NAVIO” надеются на развитие этого направления (?).
Там правда у них какойто “патч” линукса… и похоже I2C… - но это, по моему, только усугубляет проблему…

rual
oleg70:

Так вот последние изыскания показали, что при работе с SPI многозадачный линукс становится фактически однозадачным… Иными словами - запустив в одном терминале процесс обмена данными по SPI и их выводом на экран, другие задачи запускаться не собираются до тех пор пока мы не убьём этот процесс…

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

oleg70
rual:

надо код драйвера прошерстить,

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

alexeykozin

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

oleg70
alexeykozin:

а функции навигации реализовать на бортовом компе
втч визуальную ориентацию.

Всю навигацию, любого уровня сложности, stm обсчитывает не напрягаясь… Я у себя ему и RTOS и OSD навесил + 500 гц реалтайм, а ему (stmF4) всё ни по чём, только ОЗУ уже впритык… А визуальная ориентация - больше мечты, чем реальность, пока даже прототипов не видно на просторах инета.
От RPi хотелось только одного - чтоб весь софт был на языке высокого уровня, чтоб без всякой компиляции/перепрошивки и прочей колготы с программаторами и средами разработки, чуть ли не в поле, испытывать те или иные идеи алгоритмов управления, навешивать новые сенсоры, и т.д … пока что глухо с этой затеей (на полку, до лучших времен)

alexeykozin
oleg70:

Всю навигацию, любого уровня сложности, stm обсчитывает не напрягаясь…

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

rual

Привет Друзья и Коллеги по хобби! Пользуясь случаем поздравляю всех с наступающим Новым годом! Здоровья крепкого Вам и родным, удачи во всех начинаниях, мирного неба! Высоких и красивых полётов!

11 days later
SergDoc

Всем здравия в новом году!
Шавет нужен:
Короче писал-писал драйвер да не выписал, точнее драйвер то есть, но случилось беда - при экспериментах с мелкой уложил 6000 и лапу проца - но не суть, куплю - приедут. Как говорится “плохой результат-тоже результат” )))
Суть в другом, пока это всё ехать собирается, на мелкой накопилось куча косяков и вопросов которые надо решать:

  1. и самое основное - что делать? (риторический вопрос) т.к. я-мы убедились, что компас в 9250 - нехорошее железо и связываться с ним не хочется - есть 2 решения данной беды:
    а) вешать компас через 9250 или оставить через 6000 (это всё не проверено и недоказуемо)
    б) вешать компас на spi (HMC5983) забирать обе лапы с 6000 - тем самым забыть о 2- imu 😦
  2. сделать плату чуть шире скажем не 28Х28 а 28Х32 - будет место поставить MINI-USB рядом с выходами на моторы, а не микро как сейчас…
alexeykozin

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

SergDoc
alexeykozin:

6000 есть с донора, если нужно для опытов не вопрос.

“Золушка в 12 часов превратилась в тыкву, но принца уже было не остановить” ))) я уже с ф4бы выдрал - всё пучком…
лап нет сапсем ))) - экспериментирую дальше )))

rual
SergDoc:

Всем здравия в новом году!

Привет! С Наступившим!

SergDoc:

что компас в 9250 - нехорошее железо и связываться с ним не хочется

Делись, чем оно плохо? А то у меня есть платка с ней, но пока не разбирался.

SergDoc:

а) вешать компас через 9250 или оставить через 6000 (это всё не проверено и недоказуемо)
б) вешать компас на spi (HMC5983) забирать обе лапы с 6000 - тем самым забыть о 2- imu

Вешать лучше отдельно (не через МПУ), ибо ты сам написал почему. хотя… надо бы проверить сквозное чтение.
2 датчика нужны? а зачем? если только в плане отказоустойчивости, но прецедентов в полёте ведь не было? если смысл удорожания и нагромождения?

SergDoc:
  1. сделать плату чуть шире скажем не 28Х28 а 28Х32 - будет место поставить MINI-USB рядом с выходами на моторы, а не микро как сейчас…

вот мне понравилась компоновка 20х40 banggood.com/Mini-NAZE32-SP-Racing-F3-Flight-Contr…
но правда это Ф3, там назе32шная дурь с внешним юсб-юсарт, можно поставить Ф4 и убрать мостик, и ещё флэху спиашную поставить