Создание собственной системы стабилизации
в настройках платы выбираю FlexyPort->Telemetry
тут подумалось - сделай HAL из AQ32 борды, там вроде порты обозваны не майн и флекси, а усарт такой-то и их там больше…
тут подумалось - сделай HAL из AQ32 борды, там вроде порты обозваны не майн и флекси, а усарт такой-то и их там больше…
Серег у меня плата уже прошитая, Sparky на Ф3м, переделывать особо не зачем, я её брал под свое ПО. Просто хотел посмотреть какой там алго в плане реакции на боковые ускорения. Было бы интересно последнюю калманутую прошивку пиксхавка тоже покатать.
просто я думал ты делал на ф4бы, а aq32 похожа ну порты переписать только, я собирался хал сделать, но сейчас есть другие задачи…
Пиши, спрашивай, что смогу отвечу.
Александр, у меня вопрос: как в питоне можно <структуру> данных создать, аналогичную СИ ??
Замысел такой: передавать по указателю массив байт, по SPI, из структуры STM (Си) в аналогичную структуру RPi под питоном…
Короче - реализовать синхронизацию разнотипных переменных за одну транзакцию (?)…
у нас событие…
первый красивый полет на ардукоптере с полностью своей инерциалкой
ссылка
полет тимура
у нас событие…
Отлично! Поздравляю!
Есть вопросы, я так понял что угол искривляли на ±5 гр, не мало? Какова длительность периода адаптации? При адаптации крутите угол яв?
сделали несколько вещей
- убрали имакс в пидах лоитера до минимума
- добавили лоитер D у ардукоптера он был 0
- добавил компенсацию времени задержки координат жпсом, причем в отличие от кода ардукоптера сделал ее регулируемой
при этом при существенных ошибках компаса исчезла склонность начать нарезать спирали
- убрали имакс в пидах лоитера до минимума
это верно, в части уменьшения расскачки, но нужно проверить реакцию на боковой ветер, может не хватить “подтяга” против ветра
добавили лоитер D у ардукоптера он был 0
это хорошо, и если Д берется от инерциалки (т.е. это боковые ускорения с акселя), т.е. НЕ ЗАВИСИТ от ориентации азимута, это основной момент в борьбе с унитазом
- добавил компенсацию времени задержки координат жпсом, причем в отличие от кода ардукоптера сделал ее регулируемой
изменяемая позиция выборки из буфера инециалки?
изменяемая позиция выборки из буфера инециалки?
жпс настраивается на 10 гц
при каждом поступлении новых данных запоминается текущие значения позиции и скорости инерциалки и проталкивается вниз буффера
буффер на 5 ячеек, в зависимости от необходимости можно снимать задержку за 1,2,3 или 4 сэмпла назад тоесть за 0,1 - 0,4 сек
вычитая из текущего состояния инерциалки ее состояние некоторое время назад получаем дельту позиции и скорости за заданный промежуток времени
эту дельту добавляем к текущим показаниям жпс при выборе точки к которой “подтягивается инерциалка”
вычитая из текущего состояния инерциалки ее состояние некоторое время назад получаем дельту позиции и скорости за заданный промежуток времени
эту дельту добавляем к текущим показаниям жпс при выборе точки к которой “подтягивается инерциалка”
Мудрёно))
Алексей, терзают смутные сомнения, в твоей коррекции присутствует положительная обратная связь, ГНСС+дельтаИНС тем больше, чем больше убегание ИНС вперед за время задержки от предыдущего состояния. Я всё правильно понял, не ошибся? Если так, то чревато расскачкой (причем внутренней, математической) даже с ровным наложением ИНС и азимута.
ГНСС+дельтаИНС тем больше, чем больше убегание ИНС вперед за время задержки от предыдущего состояния. Я всё правильно понял, не ошибся?
это сложно назвать положительной обратной связью по одной простой причине. дельта инс не имеет интегратора, она всегда берет краткосрочные данные инерциалки. собственно в этом и фенечка. Инс особенно с нашими сенсорами и частотой обработки штука очень быстро деградирующая во времени, но в краткосрочном промежутке она очень даже неплоха. к ГНСС добавляется очень краткосрочный прогноз
эквивалентом было бы сохранить в массив на 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 и их выводом на экран, другие задачи запускаться не собираются до тех пор пока мы не убьём этот процесс…
Дык там похоже внутри процесса бесконечный опрос битов в регистре СПИ, надо код драйвера прошерстить, в момент ожидания должна вызываться спецфункция передачи управления ОС.
надо код драйвера прошерстить,
Да, тут без “хирургического вмешательства” не обойтись, только для такого меня этот процесс может надолго затянуться… проще наверно дождаться когда “гурманы-операционьщики” сделают нормальную РТОС для этих целей.
имхо напрасное это дело возлагать на бортовой компьютер функции по стабилизации полета и управлении моторами.
куда более было бы просто оставить стабилизацию на хорошем проверенном апм а функции навигации реализовать на бортовом компе
втч визуальную ориентацию. требуемые для полета угловые поправки можно передавать по мавлинку через сериал