Создание собственной системы стабилизации
так что точночть динамически непредсказуемо скачет и довольно сильно…
Олег, сильно это сколько ±50?
вот кстати сравнительная табличка точности по высоте
Спасибо за табличку, Алексей, но всё ж хотелось знать именно величину “скачков”.
Тут сыну ракету прикупил, при среднем ветре её на парашюте метров на 200 может отнести, есть задумка сделать подруливание к точке старта, но использовать барик внутри падающей трубки кажется бессмысленным.
кстати это будет первая хобийная крылатая ракета)
кстати это будет первая хобийная крылатая ракета)
))) даже если будет, то уже не первая. В тубе есть несколько видео.
В части ракетомоделизма, меня увлекла одна идея - сделать АП без искусственного горизонта. Идея примерна та же, что и у тебя измерение отклонения скорости ИНС от ГНСС. Только схема здесь такая: имеем простой угловой стабилизатор угловой скорости(СУС) (АКРО режим), он не позволит ЛА делать быстрые эволюции; имеем ГНСС на борту, которая дает радиус-вектор на точку старта, а так же вектор текущей скорости (усредненный за 1-2 сек); задача АП “интуитивно” совместить радиус-вектор на базу и вектор текущей скорости, не определяя своего положения в пространстве, просто немножко подруливая, в добавок к воздействию от СУС.
Пара таких модулей до сих пор в углу пылятся, на момент тестов я так и не получил я от них не то что РТК навигации, даже как обычный GPS их было вообще невозможно использовать. Вроде новые прошивки выходят, кто знает, может и заработает когда-нить.
Проблема видится только в качестве получения 3м вектора скорости (включая вертикаль), ну и высоты раскрытия парашюта.
даже как обычный GPS их было вообще невозможно использовать. Вроде новые прошивки выходят, кто знает, может и заработает когда-нить.
в мануале написано что в консоли включается вывод в формате нмеа
в мануале написано что в консоли включается вывод в формате нмеа
Так до встраивания в аппарат тогда даже дело и не дошло, было года полтора-два назад это. Тыкался с консолью, стабильного приема спутников так и не получил, а без этого о какой либо навигации мечтать не приходится. Недавно прошивал последнюю версию, ждал минут 20 на встроеной антенне - фикса не дождался. Спутников ловил очень мало и неустойчиво. Пасмурно конечно было, но ублокс работал тогда без проблем. На мой взгляд сыроват еще проект.
сильно это сколько ±50?
На сколько я помню (давно это было), может и больше, просто интересовался, в своё время, принципами работы модулей, - там чистая математика и геометрия заточены в основном на позиционировании в плоскости, а высота как “бесплатное приложение”… Александр, а что, нет под рукой для эксперимента ни одного модуля ? а то могу сейчас прям на столе зацепить свой sim68 (продвинутый 66 каналов, чуйка уухх ))) и отчитаться, если надо.
Александр, а что, нет под рукой для эксперимента ни одного модуля ?
Да модули то есть, кто их вверх-вниз таскать будет? Я думал может кто логами богат…
может кто логами богат…
Аж самому стало интересно (😃), уже вот включил и смотрю, : высота по гуглю у меня 160 метров…, модуль при 10 спутниках (под крышей ж/б дома) показывает разброс +/- 15 метров, Но блин точно вокруг 160 (!), прыжки происходят при захвате/потере очередного спутника… двигаю модуль вверх/вниз - эффект странный: опускаю - высота растёт, поднимаю - падает… короче лажа (наверно переотражение и т.д.)
Вывод - не всё так плохо…(беру свои слова обратно:)) Только надо учитывать что я на свои платки ставлю дополнительный LPF (чтоб не забивался от видео 1.3 Ггц), может это влияет на общую картину… ды и такие эксперименты надо проводить долго в течение суток чтоб был адекватный результат, а так везде пишут что точность по высоте в несколько раз меньше точности по горизонтали…
с ракетой жпс может и фикс потерять математика там не любит резких ускорений
с ракетой жпс может и фикс потерять математика там не любит резких ускорений
Возможно, всё нужно проверять. Видимо сначала придётся делать “спускаемый аппарат” , поднимать на коптере и скидывать с тормозной ленточкой, писать логи. Зимой как раз удобно, внизу снег, не разобьётся. Стартовое ускорение мне мешать не будет, активный участок начинается с невесомости - верхней точки полёта.
Сам алгоритм руления отлажу в виртуале.
Проверил на виртуалке полёт без компаса, на ровных участках полета есть небольшой увод, при выполнении правой спирали (разворота) рыск сводится к реальному, при левом - уходит на 90гр…
нашел в ардукоптере одну печальку. поскольку арду изначальн описался под самоль - там нет алгоритма расчета воздушной скорости (силы воздействия ветра)
полагая что ожидаемое ускорение мультироторного аппарата в плоскости горизонта можно описать как G * косинус угла наклона ( питч и крен) разделенное на массу аппарата
полагая что ускорение от внешнего воздействия также может быть описано a = f/m
немного поразмыслив если методом калибровки найти пропорцию kff определяющую неточность измерений между
тягамоторов * COS(кренпитч) = ускорение_в_горизонтальной плоскости * kff то любые внешние воздействия на аппарат будут эквивалентны вычисляемой величине. исходя из константы веса аппарата и получаемой экспериментально парусности можно будет вычислить даже скорость ветра
тяга моторов = сумма векторов акселерометров
тоесть сила внешнего воздействия = сумма векторов акселерометров * COS(кренпитч) - ускорение_в_горизонтальной плоскости * kff
как правило для внутрених целей стабилизации полета точное вычисления скорости воздушного потока не требуется. достаточно знать силу внешнего воздействия для того чтобы ее моментально компенсировать
тяга моторов = сумма векторов акселерометров
Это как ? И вообще, поделитесь секретом - как вычисляется линейное ускорение коптера по осям ? (никогда не копался в готовых кодах), есть подозрение что вещь эта довольно “шумная” и для расчетов непригодная…
проекция акселей на плоскость горизонта?
github.com/diydrones/ardupilot/…/AP_AHRS_DCM.cpp#L…
_accel_ef[i] = _dcm_matrix * _ins.get_accel(i);
_accel_ef[i] - это 3д вектор где
_accel_ef[i].x - ускорение на север
_accel_ef[i].y - ускорение на восток
_accel_ef[i].z - ускорение вверх
_dcm_matrix - матрица поворотов (горизонт коптера)
_ins.get_accel(i) - конкретный акселерометр с номером i
или как читают регистры мпу чтобы получить значения гир и акселей?
есть подозрение что вещь эта довольно “шумная” и для расчетов непригодная…
в мпу6000 есть функционал встроенного фильтра, фильтрует неплохо. точность конечно желает лучшего но на нашем уровне пока в эту цену ничего лучшего нет
или как читают регистры мпу чтобы получить значения гир и акселей?
Нет, это всё ясно, (у меня рабочая, в плане стабилизации, собственная прошивка)), и в плане линейного ускорения понятно - что надо просто вычесть из “сырого” показания акселя текущую проекцию силы тяжести, вопрос в том что:
1.оси акселя офигенно шумят, просто сами, и от внешних вибраций…
2.всегда присутствует разброс у конкретного акселя по осям, т.е. надо кропотливо откалибровать каждую ось (возможно ли это вообще ? на практике)
3.показания уплывают при нагреве/остывании, (с этим ещё сложнее, в “назе” например аж внешний подогрев сделали)
4.(самое неприятное) вычитаемое значение проекции G (у меня кватернионы) имеет естественное запаздывание от реалтайма, в связи с этим происходят “выбросы” ускорения, которые непонятно как убирать…
Как можно вообще такие показания интегрировать, для получения скажем скорости, и уж того больше, расстояния ?? как эти трудности решаются в известных проектах ?
1.оси акселя офигенно шумят, просто сами, и от внешних вибраций…
фильтр датчика + программный фильтр
2.всегда присутствует разброс у конкретного акселя по осям, т.е. надо кропотливо откалибровать каждую ось (возможно ли это вообще ? на практике)
калибровка всех осей причём в обе стороны
показания уплывают при нагреве/остывании, (с этим ещё сложнее, в “назе” например аж внешний подогрев сделали)
в МПУ практически не плывут, ну если перепад не слишком большой ±15 градусов за пару секунд, где-то тут в ветке я когда-то экспериментировал с лсм - подсовывал под кулер ноута - как пьяный был, с мпу такого не наблюдается, в крайнем случае в датчике есть температурный датчик - можно пользовать его, конечно зависимость не совсем линейна - но похожа на правду
4.(самое неприятное) вычитаемое значение проекции G (у меня кватернионы) имеет естественное запаздывание от реалтайма, в связи с этим происходят “выбросы” ускорения, которые непонятно как убирать…
инерциалка не работает как иму, а раза в 4 медленней… можно и нужно фильтронуть дополнительно значения…
можно и нужно фильтронуть дополнительно значения…
Вопрос как ?
Тут делема: увеличиваешь “вес” акселя - реакция ускоряется (хорошо вроде), но как следствие на горизонт больше влияет центробежные ускорения (совсем не хорошо)… и как “фильтронуть” то ?
Тут делема: увеличиваешь “вес” акселя - реакция ускоряется (хорошо вроде), но как следствие на горизонт больше влияет центробежные ускорения (совсем не хорошо)… и как “фильтронуть” то ?
Динамически менять подтяг в зависимости от условий полета
или… попробовать вычитать горизонтальную проекцию ускорений - но тут тоже есть риск получить барона мюнхаузена который пытается себя вытащить за волосы из болота.
-
3д вектор компаса. он почти всегда может по двум точкам определить плоскость горизонта. т.е. не даст ось лишь при соосности питча или рола четко на магнитный север, нужно учитывать манитное на клонение и перекосы в установке
-
крен питч у коптера постоянно меняется и можно сравнивать ожидаемое от изменения крена ускорение с реальным (но тут немного будет мешать сила воздействия ветра) т.е зная что при крене 5град имеем ускорение тяга * cos(угол) - при этом дельта этого выражения с реальным ускорением либо внешний толчок либо ветер либо ошибка горизонта
Динамически менять подтяг в зависимости от условий полета
Опять “мюнхаузен”… - в “условиях полета” опять засел аксель… А ведь это самый каверзный вопрос вообще в системах стабилизации на основе акселерометра (😃) - как отделить чистое ускорение от направления силы тяжести если физически для датчика это одно и то-же… если б не это, то вопрос удержания позиции в точке вообще бы не стоял… (нужели Калману звонить?)))