Создание собственной системы стабилизации
ГНСС+дельтаИНС тем больше, чем больше убегание ИНС вперед за время задержки от предыдущего состояния. Я всё правильно понял, не ошибся?
это сложно назвать положительной обратной связью по одной простой причине. дельта инс не имеет интегратора, она всегда берет краткосрочные данные инерциалки. собственно в этом и фенечка. Инс особенно с нашими сенсорами и частотой обработки штука очень быстро деградирующая во времени, но в краткосрочном промежутке она очень даже неплоха. к ГНСС добавляется очень краткосрочный прогноз
эквивалентом было бы сохранить в массив на 50-100 элементов данных в быстром цикле инерциалки ускорения по осям ax ay и dt а в цикле синхронизации жпс данных получать суммированием из ускорений и dt дельту скорости и позиции за заданное время задержки жпс данных (за время соотвествующее сумме dt), но на апм такое просадило бы проц и заняло бы существенный кусок оперативы - поэтому сохраняю готовые ускорения и перемещения с интервалом поступления ГНСС данных
дельта инс не имеет интегратора,
Т.е. фактически у Вас не дельта скорости на выходе а дельта ускорения… а прибавляете вы ее, если не ошибаюсь, к расстоянию по жпс… как то не клеится (??)…
Ну да ладно, а результат проверки этого алгоритма в полете можете прокоментировать ? лучше стало ? (насколько)…
Т.е. фактически у Вас не дельта скорости на выходе а дельта ускорения…
в настоящее время беру и скорость и текущую позицию прямо из расчетов инерциалки
сохряняю текущую позицию и скрость в буффер “снизу” это проталкивает данные наверх, сэмплов 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);
но на быстрых процах можно было бы из ускорений все считать
Ну да ладно, а результат проверки этого алгоритма в полете можете прокоментировать ? лучше стало ? (насколько)…
визуально сильно снизилась тенденция к раскрутке по спирали при ошибке компаса, при анализе логов уменьшилось расхождение между координатами ГНСС и INAV. я вывел в лог в пакете INAV параметры LA LN с тем чтобы можно было сравнивать инерциальные координаты с данными навигационного приемника gps LAT LNG прямо в анализаторе логов мишен планера
Т.е. фактически у Вас не дельта скорости на выходе а дельта ускорения… а прибавляете вы ее, если не ошибаюсь, к расстоянию по жпс… как то не клеится (??)…
да нет, всё клеится РастИНС1-РастИНС0 = дельтаРастИНС, это как раз и есть расчет ИНСки между отсчетами ГНСС, т.е. актуализация положения между отсчетами ГНСС. дельтаРастИНС/dt = СкоростьИНС (за период dt); где dt - период получения данных ГНСС. Алексей, коэффициент притяжки ИНС и период обновления ИНС какие?
Алексей, коэффициент притяжки ИНС и период обновления ИНС какие?
_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
параметры подтяга и компенсации жпс лага - ругулируемые из парметров, привел значения которые были использованы в полете на видео
к раскрутке по спирали при ошибке компаса,
компас, я так понял, смешивается с гирой и акселем в общий алгоритм ориентации ИНС (типа алго магвика и махони)??
визуально сильно снизилась тенденция к раскрутке
тогда - это результат (!), поздравляю…
Я тут был воодушевлён применением RPi в качестве контроллера полета… Так вот последние изыскания показали, что при работе с SPI многозадачный линукс становится фактически однозадачным… Иными словами - запустив в одном терминале процесс обмена данными по SPI и их выводом на экран, другие задачи запускаться не собираются до тех пор пока мы не убьём этот процесс…
Вывод: нафига тогда всё это (?), и вопрос по передаче видео по WiFi и тому подобное отпадает сам собой… Не понятно как люди, делающие платы типа “NAVIO” надеются на развитие этого направления (?).
Там правда у них какойто “патч” линукса… и похоже I2C… - но это, по моему, только усугубляет проблему…
Так вот последние изыскания показали, что при работе с SPI многозадачный линукс становится фактически однозадачным… Иными словами - запустив в одном терминале процесс обмена данными по SPI и их выводом на экран, другие задачи запускаться не собираются до тех пор пока мы не убьём этот процесс…
Дык там похоже внутри процесса бесконечный опрос битов в регистре СПИ, надо код драйвера прошерстить, в момент ожидания должна вызываться спецфункция передачи управления ОС.
надо код драйвера прошерстить,
Да, тут без “хирургического вмешательства” не обойтись, только для такого меня этот процесс может надолго затянуться… проще наверно дождаться когда “гурманы-операционьщики” сделают нормальную РТОС для этих целей.
имхо напрасное это дело возлагать на бортовой компьютер функции по стабилизации полета и управлении моторами.
куда более было бы просто оставить стабилизацию на хорошем проверенном апм а функции навигации реализовать на бортовом компе
втч визуальную ориентацию. требуемые для полета угловые поправки можно передавать по мавлинку через сериал
а функции навигации реализовать на бортовом компе
втч визуальную ориентацию.
Всю навигацию, любого уровня сложности, stm обсчитывает не напрягаясь… Я у себя ему и RTOS и OSD навесил + 500 гц реалтайм, а ему (stmF4) всё ни по чём, только ОЗУ уже впритык… А визуальная ориентация - больше мечты, чем реальность, пока даже прототипов не видно на просторах инета.
От RPi хотелось только одного - чтоб весь софт был на языке высокого уровня, чтоб без всякой компиляции/перепрошивки и прочей колготы с программаторами и средами разработки, чуть ли не в поле, испытывать те или иные идеи алгоритмов управления, навешивать новые сенсоры, и т.д … пока что глухо с этой затеей (на полку, до лучших времен)
Всю навигацию, любого уровня сложности, stm обсчитывает не напрягаясь…
за исключением визуального ориентирования, именно его я и имел ввиду под внешней навигационной системой.
Привет Друзья и Коллеги по хобби! Пользуясь случаем поздравляю всех с наступающим Новым годом! Здоровья крепкого Вам и родным, удачи во всех начинаниях, мирного неба! Высоких и красивых полётов!
С наступающим Новым Годом!
Всем здравия в новом году!
Шавет нужен:
Короче писал-писал драйвер да не выписал, точнее драйвер то есть, но случилось беда - при экспериментах с мелкой уложил 6000 и лапу проца - но не суть, куплю - приедут. Как говорится “плохой результат-тоже результат” )))
Суть в другом, пока это всё ехать собирается, на мелкой накопилось куча косяков и вопросов которые надо решать:
- и самое основное - что делать? (риторический вопрос) т.к. я-мы убедились, что компас в 9250 - нехорошее железо и связываться с ним не хочется - есть 2 решения данной беды:
а) вешать компас через 9250 или оставить через 6000 (это всё не проверено и недоказуемо)
б) вешать компас на spi (HMC5983) забирать обе лапы с 6000 - тем самым забыть о 2- imu 😦 - сделать плату чуть шире скажем не 28Х28 а 28Х32 - будет место поставить MINI-USB рядом с выходами на моторы, а не микро как сейчас…
6000 есть с донора, если нужно для опытов не вопрос.
компас надо либо вешать на спи либо понижать частоту айтуси
второй иму будет интересен, надо поискать другие свободные лапы.
юсб можно вообще убрать с мини платы. все вывести на мкроплощадки для распайки на тонкие проводки,
на микроаппарататах каждый грамм на счету кому нужен юсб припаяются
миниюсб вообще лошадь и не вариант
6000 есть с донора, если нужно для опытов не вопрос.
“Золушка в 12 часов превратилась в тыкву, но принца уже было не остановить” ))) я уже с ф4бы выдрал - всё пучком…
лап нет сапсем ))) - экспериментирую дальше )))
Всем здравия в новом году!
Привет! С Наступившим!
что компас в 9250 - нехорошее железо и связываться с ним не хочется
Делись, чем оно плохо? А то у меня есть платка с ней, но пока не разбирался.
а) вешать компас через 9250 или оставить через 6000 (это всё не проверено и недоказуемо)
б) вешать компас на spi (HMC5983) забирать обе лапы с 6000 - тем самым забыть о 2- imu
Вешать лучше отдельно (не через МПУ), ибо ты сам написал почему. хотя… надо бы проверить сквозное чтение.
2 датчика нужны? а зачем? если только в плане отказоустойчивости, но прецедентов в полёте ведь не было? если смысл удорожания и нагромождения?
- сделать плату чуть шире скажем не 28Х28 а 28Х32 - будет место поставить MINI-USB рядом с выходами на моторы, а не микро как сейчас…
вот мне понравилась компоновка 20х40 banggood.com/Mini-NAZE32-SP-Racing-F3-Flight-Contr…
но правда это Ф3, там назе32шная дурь с внешним юсб-юсарт, можно поставить Ф4 и убрать мостик, и ещё флэху спиашную поставить
Делись, чем оно плохо? А то у меня есть платка с ней, но пока не разбирался.
грубо: если данные с hmc мне надо делить на 1095, то АК надо умножать на 1.5 ( вчера всё-таки заставил 6000 -ю упираться в аукс и2ц - надо осцилл на работе забрать теперь…
и ещё флэху спиашную поставить
мы с Максом думали на воткнуть что-нибудь вместо sd, но чёт ничего серьёзного (в плане объёма) и дешевого нет - легче sd припаять))) в мелкой пока связка фрам+сд не мешают)))
недостатки сд карт.
-кардхолдер занимает много места
-содержит намагничиваемый металл и если рядом с компасом то после касания его отверткой может отравлять компасу жизнь
-содержит котнтакты нужно осторожничать с промывкой, может насосать в себя раствора промывочной жидкости и тогда привет
в логике арду заложено что если карта не вставлена при запуске то только консоль - значит нужен будет джампер при отказе от сд
в логике арду заложено что если карта не вставлена при запуске то только консоль - значит нужен будет джампер при отказе от сд
ну его - эту логику:
- если что-то не так вываливаться в консоль
- желательно при перепрошивке стирать фрам (задать буту такую возможность) что на мой взгляд лучше всего - никаких проблем с параметрами после прошивки…
- из станции стирать фрам с ребутом
например в таулабсе в отличии от опенпилота можно флеш стирать из станции, а не заливать отдельную прошивку для этого…
а так да особенно на мелкой - кусок железа на всё брюхо…