Создание собственной системы стабилизации
ну а дальше - дело техники посчитать из ускорений скорость и перемещение
Понятно, там получается есть коррекция по ГНСС задержанных на полсекунды отсчетов ИНС. Так получается, что ты расхождения ИНС и ГНСС считаешь именно за эти полсекунды?
Понятно, там получается есть коррекция по ГНСС задержанных на полсекунды отсчетов ИНС. Так получается, что ты расхождения ИНС и ГНСС считаешь именно за эти полсекунды?
я пока точно не измерял задержки свойственные жпс модулям разных производителей, рассчитывал по логам, но данные противоречивые, нужен стенд. катапульта. включить запись акселераций и вычислить время между рывком и началом изменения координат.
т.к. нет точного времени задержки нет кусочка компенсации задержки жпс данных.
планирую в 100гц цикле сохранять в массив статистику акселя а по мере поступления данных жпс интегрировать кусочек истории за время задержки полученной экспериментально.
Махови проверял задержку времени получаемую от медиатека 3333 в сопоставлении с атомными часами, он утверждает что время почти не запаздывает, но это не говорит о том что не запаздывают координаты или курс
FlexyPort->Telemetry, сохраняю, но не работает зараза
х.з. может он вообще нерабочий, я хотел его проверить, но руки до него не дошли, там ещё косяков на параход, покатай опенпилот: github.com/openpilot/OpenPilot , HAL почти тот же самый… на flexi в опенпилоте я вешал gps - работал…
тут HAL rcopen.com/blogs/74247/19886
Махови проверял задержку времени получаемую от медиатека 3333 в сопоставлении с атомными часами, он утверждает что время почти не запаздывает, но это не говорит о том что не запаздывают координаты или курс
Алексей чем отличается протокол в 3329 и 3333 - беда в том что 3329 ловит 6 спутников но фикс и hdop есть, а 3333 - показывает у меня координаты и 12 спутников дома, но нет ни фикса, ни hdop, ни vdop нету (
Гироскоп нужно корректировать всегда, и даже если коррекция будет с плавающим весом, угадать когда понижать вес, гарантированно точно нельзя.
в приснопамятном CC когда-то существовала ветка с банальной коррекцией в пару строк: чем ближе длина вектора акселя к единице (ну или к нулю, после вычета G), тем больше его вес. и наоборот, чем больше текущее ускорение, тем меньше он “корректирует” гироскопы. если в полете наблюдалось совсем уж неприятное уплывание, то самолет достаточно было вывести в прямолинейный полет на пару секунд, а коптер ручками завесить.
дополнительно пытались ввести коррекцию по смещению акселя от центра масс аппарата (т. е. из акселя вычитались угловые ускорения). для полного счастья нужны были пара датчиков симметрично равноудаленных от ЦМ, но все уперлось в быстродействие. или в появление CC3D, не помню уже 😉
тем больше его вес. и наоборот, чем больше текущее ускорение, тем меньше он “корректирует”
там оно есть, но как-то странно - я не понял, там сделан ПИД-регулятор веса акселя, плюс тоже что и в арду - при арме вес акселя в 10 раз уменьшается…
- при арме вес акселя в 10 раз уменьшается…
наверно это как раз включается “полетный рабочий вес”, а на земле для ускорения процесса выравнивания горизонта вес завышенный… что логично.
в настройках платы выбираю 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 - период получения данных ГНСС. Алексей, коэффициент притяжки ИНС и период обновления ИНС какие?