Search in topic

OSD на ATmega1281

может аксель ещё добавить? если с него не было инфы о смене крен - значит врёт пира?

Есть проблема неточности квантования, неизбежных ошибок дискретизации (при которой непрерывная функция условно считается не изменяет значения на время дискретизации).

Это первая большая составляющая погрешности.

Но основная накапливающаяся ошибка после интегратора имхо именно из-за неидеальности ДУС (несимметричного шума, сдвига нуля). Вопрос о необходимости и вариантах коррекции постоянной составляющей после интегратора, как бы собственно к интегратору и не относится, он парень простой- складывает все что дали…

А это - вторая. Каждый раз сложение идёт с некоторой ошибкой. И эта ошибка накапливается по мере складывания.
Источник этой погрешности, конечно же, и в шумах ДУС, и в шумах АЦП, но их порядок довольно мал. В моих фильтрах шум пирометра эффективно давился именно при помощи ДУС, как менее шумного прибора. А вот наибольшую погрешность вызывают как раз ошибки дискретизации. Причём в статике они больше, чем в динамике.

Основная проблема при интегрировании, не только мемсов, а вообще интегрирования, это наличие постоянной составляющей в сигнале. Наличие этой постоянной составляющей и дает постоянный уход сигнала при интегрировании.

Ну дык! Если её не давить, остальные погрешности можно вообще не упоминать. Уход будет диким. Я предполагал, что эта погрешность как раз подавлена калманом или т.п. способом. Например, ТЕКНОЛ применяет термостатирование и отбор сенсоров по параметрам. Тогда основным источником погрешности становятся ошибки дискретизации и линеаризации, которые никак не спрогнозируешь и не подавишь. А это именно ошибки алгоритма. О чём я и говорил.
Опять же, на сколько систематически уходит ДУС? Ну, 0,1-0,5% от шкалы при обычном дрейфе температуры. Это фигня. В фильтрах, корректирующих пиро я вообще на это внимания не обращаю.
Не фигнёй это становится, когда интегратор начинает эти 0,5% многократно суммировать. И именно сбросом интегратора мы добиваемся коррекции, а не ударом по гиро, как было с когерером 😃
Опять виноват интегратор. В алгоритмах, где его нет, и ошибок не накапливается.

может аксель ещё добавить? если с него не было инфы о смене крен - значит врёт пира?

Дельная идея, кстати. Только не аксель, а дус. В этом случае систематика ДУС вообще побоку, т.к. нет интегратора.

Спорить можно бесконечно, думаю мы все говорим об одном и том-же, вопрос терминологии…

может аксель ещё добавить? если с него не было инфы о смене крен - значит врёт пира?

Конечно чем больше датчиков тем надежнее… в теории… если их правильно скоррелировать… А это уже не такая простая задачка, не имеющая аналитического решения.
У меня пока не получается качественно свести даже казалось бы очевидные и однозначные вещи- коррекция ноля крена по пиро (часто значительно уплывающего даже во время полета по объяснимым причинам) с контролем изменения курса…

Тогда основным источником погрешности становятся ошибки дискретизации и линеаризации, которые никак не спрогнозируешь и не подавишь. А это именно ошибки алгоритма. О чём я и говорил.

Во первых, дискретизация не относится к алгоритму. Дискретизацию всю жизнь все считали шумовой составляющей подмешанной ко входному сигналу, но никогда не считали ошибкой алгоритма. Более того, характеристики шума дискретизации всегда известны и измеряемы. А значит результат всегда прогнозируем.
Второе.
Ошибка линеаризации то-же всегда известна. Более того, в большенстве случаев как раз ошибка линеаризации вообще отсутствует или ее можно свести в значению близкому к нулю.
Вообще я не понимаю что Вы понимаете под понятием линеаризации. В цифре есть либо децимация, либо интерполяция. В обоих случаях значения ошибки равны нулю, если конечно правильно делать.

Еще раз по поводу ошибки алгоритма.
Вот есть у меня DSP, где я использую плавующую запятую. На входе у меня приходит сигнал с шумом. Отношение сигнал/шум на входе 50 дБ. Т.е. собственный уровень шума у меня -50 дБ.
Уровень шума алгоритма у меня -192 дБ. Это в 10^-7 раз меньше чем шум на входе.
Если этого не достаточно, то я могу использовать двойную точность и у меня шумы алгоритма будут -384 дБ, это будет 10^-17.

Короче, то что Вы называете ошибками алгоритма, ошибками самого алгоритма не является. Это просто чувствительность алгоритма к шуму с определенными характеристиками (как на пример оффсет ADC).

Ну а если я не прав, то вот мне правда интересно, а какие еще есть погрешности в алгоритме, которые надо упоминать?

Дмитрий, имхо не стоит спорить по мелочам, что значения углов посчитанных по ДУС плывут и причина этого понятна уже каждому “школьнику”… Лучше поподробнее расскажите про:

Компенсировать эту ошибку можно разными методами. Вот некоторые предлагают использовать данные темпиратуры для этого. Я на пример использую оценку постоянной составляющей во времени фильтром 8-го порядка. И т.д.

Честно говоря ничего не понял… Подразумевается, что усредняя за большой период времени скажем крен должен быть нулевым и от этого коррекция? но в реальных полетах это не так… 😦

Честно говоря ничего не понял… Подразумевается, что усредняя за большой период времени скажем крен должен быть нулевым и от этого коррекция? но в реальных полетах это не так…

Да. Коррекция от этого, но не совсем в лоб. 😃
Вообще, я до самолета еще не добрался. Во думаю завтра-послезавтра в машине повозить а в выходные на самолете полетать и накопить данные сенсоров. Но на данный момент, на столе это работает так:
Есть данные начальной оценки. Т.е. сначала первые несколько секунд все спокойно, и я могу просто накопить ошибку. Эта ошибка и есть начальная оценка.
Потом включается следующий алгоритм:
ФНЧ (тот который 8-го порядка) включается тогда, когда изменения гиро - минимальные (а еще я подключу аксель и компас и буду считать изменения векторов гиро, компаса и акселя. Не их амплитуды, а их направления). Но с акселем там есть засада со знаком…
Так вот, вот когда изменения меньше пороговых, вот тогда все и считается.
Я конечно понимаю что это нелинейно, но кому сейчас легко. 😃
Все работает нормально если после долгой тряски на некоторое время будут спокойные промежутки.

Пока я вижу сто этого достаточно для коррекции. Потом уже будет введена корекция по абсолютной и относительной скоростям и высотам. Т.е. нафига мне нужен ноль по гироскопам если скорость не стабильна, высота падает и курс меняется. 😃

Вообще у меня с попробовать любой алгоритм проблем вообще нет. Все сводится к рисованию этого самого алгоритма. Если это работать не будет, то я спокойно его изменю. Причем я могу это делать как реалтайм, т.е. на данных с платы, так и на записанных данных.

Да еще.
У меня еще есть замечательный компас. Он работает не так быстро как другие устройства, но работает хорошо. Начальное направление держит очень прилично, как ни крути. Да и у акселя уход минимальный.
Так что за авиагоризонт лично я не волнуюсь. Вот расчет абсолютных координат это да. Вот там надо будет думать… 😃

Развил свою идею ограничение скорости изменения курса до полного определения целевого крена этой скоростью. Вот такая диаграммка иллюстрирует этот процесс.
В симуляторе работает хорошо (быстрая реакция на изменения, малое перерегулирование), осталось на поле проверить… Есть шанс, что может оказаться неработоспособной, посмотрим…

Дискретизацию всю жизнь все считали шумовой составляющей

И как это противоречит моим “Тогда основным источником погрешности становятся ошибки дискретизации и линеаризации”?

Более того, характеристики шума дискретизации всегда известны и измеряемы. А значит результат всегда прогнозируем.

Гладко было на бумаге…

Вообще я не понимаю что Вы понимаете под понятием линеаризации.

Линеаризацией всегда называлось упрощённое представление функции в ограниченных условиях. Если мы рассматриваем функцию, а не мгновенное изменение параметра, то мы всегда имеем линеаризацию в АП. Я так понял, Калмана вы не используете, значит и значение линеаризации для вас не так велико.

Короче, то что Вы называете ошибками алгоритма, ошибками самого алгоритма не является.

Да это не я называю, это терминология такая, сложившаяся. Во всех статьях и патентах, что я видел. Вы зациклились на ошибках матаппарата и сводите их к ошибкам алгоритма, не выводя алгоритм за пределы программы. Вот, шум вычисления в double зачем-то посчитали… Я же понимаю это в более широком смысле, называя алгоритмом весь процесс работы АП. Откажитесь от интегрирования, используйте только угловую скорость, и вы обнаружите что даже на дрейф нуля можно забить. Не говоря про офсеты АЦП. Накопление ошибки образуется только при вводе интегрирования, и называются они ошибками интегрирования. А интегрирование - неотъемлимая часть алгоритма работы с ДУС.
Если же, как вы, рассматривать АП по кусочкам, а не единой системой, то перспективы раскрываются весьма радужные.

а какие еще есть погрешности в алгоритме, которые надо упоминать?

Большинство я вам описал. Не забудьте ещё про вибрацию двигателя и раскачку самолёта ветром на полосе, когда вы будете накапливать “начальную оценку”. А так же то, что эта оценка на столе и в полёте будет разная 😃 Причём в полёте всё будет немного лучше.
Короче, полетайте, позаписывайте параметры. Тогда и видно будет, что и где шумит. Тогда и поспорим в отдельной ветке 😃 А тут с оффом надо завязывать.
Скажу лишь, что коррекция акселем на ровных участках, в итоге, оказалась у нас самой эффективной. Все новомодные фичи, вроде GPS, компасов и пиро по совокупности работают хуже. Хотя, каждый из способов имеет свои преимущества в опр. условиях.

Полевые испытания алгоритма #441 прошли вполне успешно. Этот, в некотором смысле, PID, вывернутый наизнанку (да простят меня спецы ТАУ), отлично справляется с торможением, дает минимальное перерегулирование, ну и более безопасен для устойчивости самолета даже при неточном горизонте, тк. ограничивает в явном виде скорость поворота. Подобного эффекта я долго надеялся получить от Д-ветки обычного ПИД-а, и в принципе эффект торможения она (Д-ветка) давала, но несравнимо хуже и как бы плохо предсказуемый… Теперь думаю, может такой же алгоритм применить для определения “целевая высота->целевой тангаж”?
ЗЫ Был атакован стаей каких-то больших птиц, их 15 штук собралось… Летали косяком за самолетом, периодически одна вырывалась нападала… Но все обошлось… 😃 Жаль только не установлена камера “заднего вида”, были бы отличные кадры…

Интерсно пляшут девки. Птицы большие и не опознаны, это как то не по нашенски😵 Надо сказать у меня материал в ноутбуке тоже пропал, вот в прострации буду делать вскрытие. А софт чувствуется обретает все более зримые контуры ( мой шкурный интерес вполне логичен😒 надеюсь договориться) Меня тоже стали часто атоковывать птицы в последнее время. С точки зрения статистики, довольно аномально. Хорошо что не бабочки а то эти энтомологи, в душе и по сути
очень сеньтиментальны. Бабочек собирать…для науки. А то еще и чебурашку покажут, походу.

Полевые испытания алгоритма #441 прошли вполне успешно.

А можно посмотреть это в виде кода? По блок-схеме не очень понятно.

Ок, плс:

#define MAX_SPEED_ROTATION (180/4)  //180grad for 4 sec=45g/s
//---------------------------------------------------------------------------
s_int CalcRollFromCourse(s_int new_course)
{
s_int e, c;

e=(new_course-g_course); if(e<0) e+=360;
if(gRollHysteresis>0) { if(e>(180+gRollHysteresis)) gRollHysteresis=-gAP.CourseDirHyst; }
else { if(e<(180+gRollHysteresis)) gRollHysteresis=gAP.CourseDirHyst; }
if(gRollHysteresis<0) e-=360;
//-- target speed of rotation -----------
e*=MAX_SPEED_ROTATION; e/=90;
if(e>MAX_SPEED_ROTATION) e=MAX_SPEED_ROTATION;
else if(e<-MAX_SPEED_ROTATION) e=-MAX_SPEED_ROTATION;
//-- current speed of rotation --
c=(g_course-g_course1);
g_course1=g_course;
if(c<0) c+=360;
if(c>180) c-=360;
c*=50; //grad/sec
//------------------
e=IIR_Filter(&gIIR_CourseRoll, e-c);
e*=gRoll.MaxAngle; e/=MAX_SPEED_ROTATION; //MAX_SPEED_ROTATION->gRoll.MaxAngle;
e=PID_Work(&gPID_CourseRoll, e);
return e;
}

Код не оптимизирован, но зато более понятен… (мне во всяком случае… 😃)

Что то не могу на fmadirect отдельно голову найти только вместе с co-pilotом , плохо ищу или их там уже нет, если не трудно киньте ссылочку где можно купить отдельно голову или может где отдельно датчики появились ?

И еще, может кому пригодится.
Для вывода изоражения я обычно использую модуль SPI. В PIC24 просто песня , 16 битный SPI c восьмиуровневым FIFO прямо готовая видеокарта , восемь 16 битных слов в буфер кинул (128 пикселей) и пошел заниматься своим делом. процессор почти не напрягается.

Увы …revolectrix.com/…/Co-Pilot-CPD4-Sensor-Unit Out of Stock… Боюсь и не появится. Зато цены заметно упали… Почти за те день которые я только за голову заплатил, можно готовый пилот взять …revolectrix.com/…/Co-Pilot-CPD4-2-Channel-Flight-…. Есть шанс, что это тоже остатки…
Я бы тоже взял вертикальную пару для экспериментов, поэтому присоединяюсь к вопросу- может подскажут где по дешевке модуль готовый взять или хотя бы сенсоры?

SPI с аппаратным FIFO это здорово… В меге даже буферный регистр для SPI поленились сделать… 😦

Увы …revolectrix.com/…/Co-Pilot-CPD4-Sensor-Unit Out of Stock… Боюсь и не появится.

Спасибо , я заходил на www.revolectrix.com (без store) Вроде то же, но ссылка на “Co-Pilot CPD4 Sensor Unit” напроч отсутствует. Правда цена не радует.

Цена (тогда она была под 50) меня начала радовать, когда понял, что в розницу отдельно пиродатчики меньше чем 20 за сенсор не найти… 😃
ЗЫ Вспомнил, драгоценную голову из самой америки почтовики просто бросили в почтовый ящик… За неделю до этого мелкий пакет, тоже без оценки, из ГК категорически не стали отдавать жене по моему паспорту…

40$ голова, 55$ co-pilot с головой , брать отдельно вроде как смысла нет , а если возьму целиком , то свою стабилизацию точно делать не буду 😦

что в розницу отдельно пиродатчики меньше чем 20 за сенсор не найти…

вот отдельно, по триписят:) goodluckbuy.com/pir-directional-infrared-radial-se…

Это pyroelectric… Не пойдет… 😦 Надо thermopile.

если возьму целиком , то свою стабилизацию точно делать не буду

Во первых- уверены, что удовлетворит все Ваши возрастающие потребности?.. А во вторых- насколько интересно в каждом полете проверять воплощение своих очередных идей!.. Все остальные свои самолеты похоже окончательно забросил, не интересно… Ну летают, ну и что…

Это pyroelectric… Не пойдет… Надо thermopile.

И это- правильно: пироэлектрик содержит внутри буферный транзистор, что делает его абсолютно непригодным для наших применений. А вот термофил- то, что надо…
Термобатарейка с диапазоном чувствительности 5-14 нМ 😃
Только фирма Декстер, которая их раньше запросто продавала по 10$- теперь на сайте пишет “введите паспортные данные, тогда поговорим” 😦

Во первых- уверены, что удовлетворит все Ваши возрастающие потребности?.

Даже точно знаю что не удовлетворит

А во вторых- насколько интересно в каждом полете проверять воплощение своих очередных идей!.. Все остальные свои самолеты похоже окончательно забросил, не интересно… Ну летают, ну и что…

Именно! Но есть еще лень матушка , особенно когда под рукой что то готовое и почти удовлетворяющее 😦
Хотя задача довольно интересная и возможно переборет лень , но пока не буду рисковать, поищу датчики отдельно и покапаю в сторону видеогоризонта.