Создание собственной системы стабилизации
О!Неужели свое?! Или что?
Как говориться, всего в жизни не заработаешь, что-то придётся украсть )))
Или ты думаешь я способен собственную станцию собрать и алгоритмы общения с ней - конечно нет ))) с миру по нитке))) EKF же не я придумал, кватернионы, ПИД-ы тоже, что можно назвать своим?
Привет! Давно тебя не слышно не видно, или это меня ))) короче я вернулся после ремонтов - теперь всю зиму можно экспериментировать… Мне бы хотелось развивать это направление, но боюсь только для себя, людям нужен арду…
Или ты думаешь я способен собственную станцию собрать и алгоритмы общения с ней - конечно нет ))) с миру по нитке))) EKF же не я придумал, кватернионы, ПИД-ы тоже, что можно назвать своим?
с этим всё понятно, ориентацию и АП сам писал?
Привет! Давно тебя не слышно не видно, или это меня ))) короче я вернулся после ремонтов - теперь всю зиму можно экспериментировать…
Привет! ) да, редко захожу, времени нет, да и интересных тем особо не было.
Все обсуждают одни и те же мелкие детали… Видимо качество систем достигло некоего порога, когда существующие возможности АП достаточны для потребителя, а качественный скачёк требует серьезного вложения времени и средств.
Мне бы хотелось развивать это направление, но боюсь только для себя, людям нужен арду…
Абсолютно аналогично, но потребителя можно понять - ему необходим развивающийся и поддерживаемый продукт. Один разработчик-энтузиаст не может обеспечить поддержку массовому потребителю.
Я пока полностью ушел в “виртуал”, допиливаю взаимодействие с симулятором. Сейчас мне эта тема наиболее интересна, позволяет бесплатно экспериментировать ))) Как будет время покажу результаты.
Привет всем.
А BMP280 и MS5611 сравнивал кто?
Смотрю даташиты, на первый взгляд MS5611 точнее, но если вчитаться, то они хитрят и датчики, по сути, равнозначны.
Есть ли опыт применения 280-го?
Может в этой ветке кто идейку интересную подкинет ? делать то что то надо…
dslib.net/…/katadioptricheskaja-sistema-orientacii… уже было?
Привет!
А BMP280 и MS5611 сравнивал кто?
Смотрю даташиты, на первый взгляд MS5611 точнее, но если вчитаться, то они хитрят и датчики, по сути, равнозначны.
Есть ли опыт применения 280-го?
ПМСМ, аппаратура АП на ближайшие 5 лет уже сформировалась : STM32+MPU6xxx-9xxx+MS5611. Под это есть наработки и код. Переход на другую аппаратуру без ощутимого изменения качества считаю нецелесообразным. Вот 3-5 лет назад всё было совсем по другому, приличного железа для АП не было. Сейчас можно выбирать 5-6 вариантов по сути с одним и тем же ядром датчиков и вычислителей.
Я в коптерах не опытный сварщик, но мне нужно висение и удержание позиции. Судя по тесту, 5611 гораздо шустрее отрабатывает позицию. А 280-й даёт смесь огибающей с чебурашкой.
Вот и стало интересно.
Бо Measurement Specialties хитрые ребята и даташит у них написан хитро, что до барометра, что до термометра. Когда начинаешь вглубь рыть, не так всё красиво.
И ещё. Я ветку только начал читать, но уже выхватил что ставят 2 комплекта датчиков - жётско и на виброподвесе.
А не пробовали вибрацию анализироватьаналоговым акселем? Типа MXR9500G, например. Вибросмещение вычислить совсем просто, я это делал уже в приборе измерения вибраций двигателя ТВ3-117 www.dikoy.info/projects/Vibrotester.htm
А на основе анализа вибросмещения докрутить всю систему ориентации?
Судя по тесту, 5611 гораздо шустрее отрабатывает позицию. А 280-й даёт смесь огибающей с чебурашкой.
Так для коптера лучше 5611, а для самоля вообще гораздо важнее аэродинамика расположения датчика.
А не пробовали вибрацию анализироватьаналоговым акселем? Типа MXR9500G, например. Вибросмещение вычислить совсем просто, я это делал уже в приборе измерения вибраций двигателя ТВ3-117 www.dikoy.info/projects/Vibrotester.htm
А на основе анализа вибросмещения докрутить всю систему ориентации?
Так то для большого вертолета. Ты наверное данные для коррекции с какого нить ДИССа брал, который шустрый и точный? А мы (любители) то склонны опираться максимум на показания приемыша ГНСС, который инерционный и болтает его иногда…
а для самоля вообще гораздо важнее аэродинамика расположения датчика
для коптера тоже важна аэродинамика расположения датчика, ибо иначе будут просадки при быстрых пролетах ииза обдува
уважаемые знатоки, просьба помочь советом.
я решил на пробу переписать инерциалку ардукоптера на свой манер.
пока ничего нового никаких фокусов - обычная физика.
инерциалка ардукоптера в плоскости горизонта имела на входе данные жпс а на выходе инерциальную скорость и инерциальную позицию
вводные. частота выполнения цикла 100гц (обусловлено использованием на атмеге 2560)
на входе предоставляемый системой AHRS 3д вектор ускорений в системе координат земли тоесть x- ускорение на север y - ускорение на восток
если в упрощенном виде то по оси юг-север выглядит примерно так
velocity_increase.x = accel_ef.x * dt ;
_velocity += velocity_increase;
_position_correction.x = _velocity.x * dt ;
_position.x = _position.x + _position_correction.x;
таким образом получаем нескорректированную инерциалку, которая весьма быстро деградирует
исправляем деградацию позиции за счет притягивания к позиции жпс
_position.x = _position.x * 0.998f + _gps_position.x * 0.002f;
исправляем деградацию скорости инав за счет подтягивания к скорости жпс
_velocity.x = _velocity.x * 0.998f + _gps_velocity_x * 0.002f ;
коэфициенты 0.998f и 0.002f настраиваемые но в контексте для удобочитаемости показаны константами.
ребята помогли мне с облетами и сделали наблюдение что это неплохо работает если входить в удержание позиции. но если совершить резкую остановку то происходят нарастающие осциляции.
в принципе это и ожидалось логично что при резком переходе из скоростного режима в останов изза накопленной на скорости ошибки инерциалки
ошибку можно уменьшить увеличив подтяг к жпс позиции, но если это сделать то удержание в режиме низкой скорости станет хуже.
поэтому гипотезы дальнейшего развития такие
-создать “амортизатор”
либо в зависимости от скорости изменять динамически пропорцию определяющую подтяг. (на скорости инерциалка почти не нужна)
либо создать некий радиус “мертвой зоны” подтяга для режима зависания и существенно его сужать при наборе скорости
тоесть
_position.x = constraint(_position.x, _gps_position.x - deadzone , _gps_position.x + deadzone)
соственно просьба помочь советом
как лучше, как это делают другие
Динамическое изменение пропорции вполне распространено. Думаю в этом случае тоже сработает.
Например с увеличением скорости сильнее подтягивать скорость инерциалки к GPS.
Динамическое изменение пропорции вполне распространено. Думаю в этом случае тоже сработает.
Например с увеличением скорости сильнее подтягивать скорость инерциалки к GPS.
только скорость тянуть сильнее или и скорость и позицию?
возможно есть какие то наработанные константы?
что то вроде норматива скорость 1мс - нейтральное положение коэффициента подтяга. 5 мс в N раз больше, свыше не меняется
только скорость тянуть сильнее или и скорость и позицию?
возможно есть какие то наработанные константы?
что то вроде норматива скорость 1мс - нейтральное положение коэффициента подтяга. 5 мс в N раз больше, свыше не меняется
Думаю наилучший норматив это стабильное поведение аппарата во всех условиях. Если разрабатывать с нуля то без экспериментов и доводки алгоритма на аппарате сложно посоветовать чтото конкретное.
Думаю наилучший норматив это стабильное поведение аппарата во всех условиях. Если разрабатывать с нуля то без экспериментов и доводки алгоритма на аппарате сложно посоветовать чтото конкретное.
полеты - дело долгое и хлопотное, особенно пока система сыра и не слишком стабильна
но уже летаем по чуть чуть …apmcopter.ru/…/sozdanie-sobstvennoj-proshivki-ard…
только скорость тянуть сильнее или и скорость и позицию?
возможно есть какие то наработанные константы?
что то вроде норматива скорость 1мс - нейтральное положение коэффициента подтяга. 5 мс в N раз больше, свыше не меняется
А если определить практическим путем?
Задаем диапазон изменения пропорции и вешаем ее на крутилку. По результатам тестов определяем границы выше и ниже которых крутить нет смысла.
Логически понятно что изменение пропорции вряд ли будет линейным, соответственно вешаем на крутилку “кривизну” изменения пропорции и снова тестим.
да можно и без крутилок, во всем остальном прошивка - ардукоптер. все легко регулируется через радиомодем по телеметрии с компа
соственно просьба помочь советом
Нужно весь интегратор обвязать петлей ОС через ПД-регулятор, т.е. velocity_increase.x = accel_ef.x * dt + _position_correction.x *p - delta(_position_correction.x) *d ;
без промежуточной коррекции скорости, петля сама её выровняет пропорционально dt, p и d
спасибо Александр, возможно имеет смысл сделать обратную связь, но я глубоко убежден, без дополнительной коррекции от жпс не обойтись.
я анализировал множество логов полета ардукоптера где изза отсутствия корекции скорости от жпс присходила сильнейшая деградация в случае минимальных ошибок компаса или ошибки определения магнитного склонения.
тоесть ошибка компаса в 5-7 градусов приводит к сильнейшей деградации инерциальной скорости. и в результате получается “унитазинг”
в результате “мастера” конечно же сделают коптер чтобы он летел стабильно, но при применении в широких массах “это не летит”
без дополнительной коррекции от жпс не обойтись.
Дык я и не призываю отказаться от коррекции, я говорил что петля коррекции должна начинаться с интеграции ускорения, а скорость и позицию ОТДЕЛЬНО корректировать не надо, коррекция должна входить в интегратор ВМЕСТЕ С АКСЕЛЕМ. _position_correction.x - вот это как я понял как раз есть разность между жпс и ИНС
для коптера тоже важна аэродинамика расположения датчика
Под брюшком лучше?
Ещё пеной залепляют, видел…
delta(_position_correction.x)
float delta( float position_correctionx)
{
static float position_correctionx_old;
float ret;
ret = position_correctionx - position_correctionx_old;
position_correctionx_old = position_correctionx;
return ret;
}
это имелось в виду?
каков может быть диапазон p,d для начала?
это имелось в виду?
да, диффошибка положения = скорость (изменения положения)
каков может быть диапазон p,d для начала?
у меня p=d =0.1f , только само d = kd/dt. увеличение kd добавляет ВЧ на выходе фильтра, т.е. мгновенную ошибку, уменьшение приводит к “болтанию” положения. Всё как с обычным ПИД.
поскольку на высокой скорости инерциалка нужна существенно меньше, а сама скорость жпс более достоверна, решил пока попробовать увеличивать подтяг в зависимости от скорости
// speed 0-100 cm per second spd_kff = 1 200=2 300 and above = 3
float spd_kff =mapf(constrain(fabs(pythagorous2(_velocity.x, _velocity.y)), 100.f, 300.f) ,100.f ,300.f , 1.f , 3.f );
т.е. для 0-100 см надбавка “1” от метра в секунду до 3 пропорционально от1 до 3. свыше 3 мс подтяг утраивается.
ставил эксперимент - идеально калибровал аксели по уровню в неподвижности.
отключил подтяг и наблюдал как уплывает позиция. на одном боку в одну сторону плывет на другом в другую…
собственно - это мотив к интегратору с обратной связью, но возможно общее значение интегратора следует ограничить каким нибудь IMAX ибо слишком большой накопленный интегратор может негативно сказываться при переваливании с одного боку на другой
собственно - это мотив к интегратору с обратной связью, но возможно общее значение интегратора следует ограничить каким нибудь IMAX ибо слишком большой накопленный интегратор может негативно сказываться при переваливании с одного боку на другой
Алексей, ты меня не понял. Я имел ввиду не интегратор ошибки, который даст среднее смещение акселя. Я говорил об интеграторе ИНС ускорение-скорость-расстояние, что надо не “притягивать” скорость и расстояние ИНС к ЖПС скорости-расстоянию, а подавать ошибку ИНС-ЖПС непосредственно на вход интегратора ИНС.