Программируем высотомер на основе TI eZ430 Chronos

[Валера К 54]

Накатал алгоритм выставления 0, чтоб как в в Viso было На земле работает. Зацените плиз, какие подводные косяки могут быть?

    // Convert pressure (Pa) to altitude (m) преобразуем текущее давление в высоту без поправки

   rawAltitude = conv_pa_to_meter(sAlt.pressure); 

   // zero level 

   // считаем новую высоту со старой поправкой

   altitude = rawAltitude + sAlt.altitude_offset;

   // если по модулю скорость подъема/спуска < 2 м/с И высота < 300 метров (выше ничего не делаем)

   if (abs(altitude - sAlt.altitude)<2&&altitude<300) // здесь была ошибка 

      {

          if (altitude>0) sAlt.altitude_offset--; else  // если высота >0 то убавляем на 1 offset

          if (altitude<0) sAlt.altitude_offset++;       // если высота <0 то прибавляем 1 к offset  

      };

   // end zero level   

   sAlt.altitude = rawAltitude + sAlt.altitude_offset; // вычисляем новую высоту

Пояснения:

altitude, rawAltitude, sAlt.altitude, sAlt.altitude_offset - все типа s32

Данный кусок кода исполняется в функции do_altitude_measurment раз в секунду. Соответственно старое значение - это значение секунду назад.

sAlt.altitude_offset это поправка к значению высоты, вычисленному по давлению. Прибавляется каждый раз к абсолютной высоте (по давлению).

[Twilight_Sun 1913]

Валера К,

// если по модулю скорость подъема/спуска < 2 м/с И высота < 300 метров (выше ничего не делаем)

if (abs(altitude - sAlt.altitude)<2||altitude<300)

в комменте И, в коде ИЛИ. чем такие комменты лучше никаких (ничего личного, просто мнение).

ну а вообще алгоритм как по мне не очень, ведь если самолет со 0м до 50м по каким-то причинам будет медленно подыматься - этот кусок подъема "вырежется". в высотниках вроде идет запоминание истории. и если за какой-то промежуток времени понимается, что это подъем (метров 40 хотя бы) то берется старое значение до этого подъема. вывод такое сделал из того, что до определенной высоты/времени, что визо, что нептун ноль показывают, а потом ВНЕЗАПНО начинают показывать правильно.

да и 2 м/с это получается включили высотник на земле где-то в подвале в укладочной, поднялись бегом на 1ый этаж (на 2,5м) и всё, уже колебания давления зафиксировались, не учитываются.

как по мне так, 1-2 метра это вообще в пределах погрешности датчика. хотя может конечно там какие-то супертехнологии, не в курсе.

чем так делать - так лучше кнопочкой, как выше предлагали.

З.Ы. а чего там, реально целочисельные высоты в метрах? никакие не с плавающей точкой? прикольно. тогда бы уже abs(altitude - sAlt.altitude)<2 записал abs(altitude - sAlt.altitude) = 1 : )) ведь если = 0 - обрабатывать никак не нужно

[Валера К 54]

в комменте И, в коде ИЛИ. чем такие комменты лучше никаких (ничего личного, просто мнение).

Почему же не нужны коменты - как раз по ним уже один баг выловили, спасибо. Должно быть И.

ну а вообще алгоритм как по мне не очень, ведь если самолет со 0м до 50м по каким-то причинам будет медленно подыматься - этот кусок подъема "вырежется".

Если алгоритм не очень, то нужно предложить лучший Тем более, если знаешь, какой алгоритм в других высотниках.

Насколько я знаю, если предположить, что самолет поднимется на 30 метров и будет там долго лететь (чего в принципе не бывает), то любой высотник скорее всего выставит 0 по этому уровню. В случае же, если в момент подъема до 300 метров скорость подъема на некоторое время будет меньше 2 м/с (чего я на нашем аэродроме тоже не встречал ни разу), то в моем алгоритме это не приведет к катастрофическим последствиям. Внесется поправка на это время, умноженная на 1 метр. Т.е. если предположить что в какой-то момент подъема до 300 метров скорость подъема на 5 секунд снизилась до 1 м/с (или вообще вышли в горизонт), то ошибка будет всего 5 метров.

в высотниках вроде идет запоминание истории. и если за какой-то промежуток времени понимается, что это подъем (метров 40 хотя бы) то берется старое значение до этого подъема.

если известен алгоритм работы существующих высотников, то в студию его плиз!

да и 2 м/с это получается включили высотник на земле где-то в подвале в укладочной, поднялись бегом на 1ый этаж (на 2,5м) и всё, уже колебания давления зафиксировались, не учитываются.

Ничего не понял, про этот пример. Забежали наверх, подождали, на экране 0. Спустились, подождали несколько секунд - опять на экране 0.

З.Ы. а чего там, реально целочисельные высоты в метрах? никакие не с плавающей точкой? прикольно. тогда бы уже abs(altitude - sAlt.altitude)<2 записал abs(altitude - sAlt.altitude) = 1 : )) ведь если = 0 - обрабатывать никак не нужно

Высоты в метрах целые. Если 0, то там тоже процесс идет, посмотри внимательно Походу надо на русском алгоритм написать, чтоб всем было понятно

[Twilight_Sun 1913]

Валера К, да, на русском лучше. я ща просто на 1С код проверяю в основном по работе : )

в общем признаю, чуть затупил, визуально перепутал пару переменных (вечер, пиво по случаю дня числа Пи). просто я бы хранил rawAltitude и altitude_offset, а вычислял бы уже по ходу. но это уже кто как мыслит...

биже к делу. По алгоритму всё равно неясно, допустим ты в подъеме, у тебя высота относительно нуля (sAlt.altitude) 100м, и тут ты считаешь новую высоту (rawAltitude + sAlt.altitude_offset), получаешь 101м, при этом делаешь sAlt.altitude_offset-- ,потом (мы делаем полку например) получаешь 99м, и опять по алгоритму делаешь sAlt.altitude_offset-- т.к. у тебя altitude>0 .

где тут логика? наверное с нулем надо тебе сравнивать всё-таки то, чего ты по модулю проверяешь, если исходить из того, что ты тут закладываешь в качестве идеи. или я в корне неверно понял мысль.

как вариант, если надо rawAltitude + sAlt.altitude_offset к нулю приравнять, то просто делать sAlt.altitude_offset = -rawAltitude, а если к тому, что было, так sAlt.altitude_offset = sAlt.altitude - rawAltitude , тогда не надо будет запариваться в случае если вместо "2" будет другое число что именно там надо вместо ++ и --

насчет лучше - это выше писали примерно, плюс я вот написал идею с историей. не готов прям сейчас её до кода продумать.

Тем более, если знаешь, какой алгоритм в других высотниках.

не знаю, а предполагаю

[Валера К 54]

Ок, опишу логику словами.

У нас 4 состояния:

1) на земле (погода медленно меняется, датчик шумит)

2) в наборе до 300 метров (скорость подъема >1 м/c)

3) выше 300 метров

4) снижение с 300 метров до 0.

Сначала опишу, как это работает в идеальном случае:

При включении определяем высоту. Делаем поправку равную -высота. Результирующая высота получается 0 (с учетом поправки).

1) На земле. В связи с изменением давления или поднялись по лестнице, высота изменилась. Если высота изменилась быстро, то поправок не вносим (может уже взлетаем?). Если высота изменилась медленно (<2 м/c), то в зависимости от знака высоты каждую секунду прибавляем или убавляем 1 к поправке. Таким образом высота сходится к 0 со скоростью 1 м/с.

2) Это первый случай со скоростью увеличения высоты >1 м/с. Это переходный процесс, который будет происходить до высоты 300 метров. При нормальном взлете до 300 метров самолет набирает высоту со скороподъемностью >5 м/c, поэтому ошибок быть не должно.

В случае, если самолет сделал полку на высоте, к примеру, 150 метров на время 5 секунд, то за это время внесется поправка -5 метров. Если он завис на этой высоте на 150 секунд, а потом полетел вверх, то 0 будет на высоте 150 метров. Думаю, любой высотомер сделает так-же. Вопрос только в высоте граничной. Сейчас подумал, что стоит снизить граничную высоту метров до 100 - 50, тогда будет надежнее.

3) Выше 300 метров никаких поправок не вносим.

4) Как только спустились ниже 300 метров, ничинаем вносить поправку, как только приземлились (скорость спуска стала <= 1 м/c).

PS: По модулю я проверяю скорость набора/спуска. Т.к. она может быть как положительной, так и отрицательной.

[соло 75]

Валера К, а какой смысл сдвигать смещение каждый раз на 1?

у тебя давление немного скакнуло (скажем на высоту 1см) - ты его бамс на целый метр в эту сторону. давления на 1см в другую сторону скакнуло а для тебя это уже 101 см, т.к. ты себя на предыдущем шаге принудительно в метровую ошибку загнал..

критично или нет - покажет практика, но выглядит не слишком элегантно, а значит рано или поздно даст по морде (это из необъяснимого опыта)

если бы я борол подобную проблему, я бы тупо завел два режима - на земле/в воздухе. переход между этими состояниями делать на основе более длительных наблюдений, чем 1 секунда. например - 10 секунд монотонно возрастающей высоты с какой-то минимальной скоростью (например твои же 2мс) это более правдоподобный признак начала подъема, чем скорось 2мс на протяжении прошедшей секунды. определили, что летим - значение 10ти секундной давности принимаем за 0.

в состоянии полета - определили, что высота отличается от нуля скажем не больше чем на 100 метров и остается постоянной +- пара метров на протяжении 10 секунд - значит на земле?

пока мы на земле - просто тупо запоминаем историю 10 последних (крайних) отсчетов, а на дисплее всегда рисуем 0. пересчетами давления при этом вообще не маемся - зачем?

как то так...

[Twilight_Sun 1913]

Валера К, лихо закручен сюжет. теперь понятно. просто сходу как-то не пришло в голосу, что ты считаешь что при полке можно по метру в секунду высоту корректировать. А если потом окажется что 2 м/с плохая граничная скорость и лучше 5 м/с - то будешь по 4 м/с догонять на полке?

в общем как по мне проще запоминать время когда был установлен ноль, и сбрасывать уже по нему. тогда на полке у нас не будет ненужной коррекции.

впрочем я не настаиваю. твой алгоритм в большинстве условий будет работать тогда с такими раскладами. вопрос, что надо предусмотреть всякие кнопочку ручной коррекции и указания "я в подъеме"/"я на дз" для тех случаев, которые не попадают в это большиство (например на машине быстренько на 50м поднялись или полка долгая).

Ну и остаются недостатки, что эта неявная коррекция по "полке" может быть не отловлена и требует контроля со стороны юзера.

соло, вот, я бы тоже так сделал как ты описываешь примерно. где-то тоже самое собственно и пытался описать со словами про историю. только у него там числа целые вроде как, поэтому 1см - это разве что около сколько-то + 0,5 где-то гуляет высота. тогда будет конечно дергаться.

[Лелик 97]

никакие смещения двигать не нужно, как только прибор почуствовал изменения высоты, не связанные с медленно текущими атмосферными явлениями, запоминаем эту высоту как 0, если определенный промежуток времени, высота увеличивается, значит смело можно считать запомненную высоту как 0. просто нужно еще добавить немного веток в алгоритме для обработки отдельных случаев, например подъем до 200м и посадка, итд

сейчас вам нужно собрать как можно больше логов подъемов и посадок, как в свободном падении так и в самолете, и уже на базе этих графиков править алгоритм

[wami 0]

Выкладываю для теста мои наработки.

Основывется на проекте OpenChronos

+работает вариометр(пускай пока и немного криво)

+добавлена возможность в режиме вариометра ничего не выводить в нижней строке (тоесть сверху высотомер, снизу пусто) (нажатие v в режиме варио внизу показывает варио\давление\макс-мин скорость\время в режиме\ пустой экран)

+по нажатию на подсветку экран светится секунды 3, а не пока нажата кнопка

+при блокировке по нажатии на подсветку не показывает Lock

+при компиляции можно установить 8 часовой таймаут для высотника (выбрано по умолчанию)

+при компиляции можно отключить фильтр высотника (выбрано по умолчанию)

+увеличено ограничение на ручную установку высоты до 7000м

В проекте

-интеграция альтернативного расчета высоты

-постоянна подсветка по долгому нажатию на кнопку подсветки

-округление показаний в зависимости от высоты/вектора скорости

-нормальный вариометр

-облегчить выставление нуля

-автоматическое выставление нуля

Кто может, присоединяйтесь к разработке на https://github.com/Wami/OpenChronos

Комментарии, отчеты по ошибкам, пожелания, свои наработки крайне приветствуются.

скомпилировано для 868 версии

build.zip

[Валера К 54]

wami

Пара вопросов по OpenCronos.

Они реализовали другой алгоритм определения высоты (директива FIXDPOINT для прекомпилятора). Ты разобрался, как он работает?

Там получается все вносят изменения в 1 проект? Нет разделения веток для парашютистов/парапланеристов/горных походов?

Чем ты ее компилишь? Можно по шагам для dumb`ов?

[wami 0]

Пара вопросов по OpenCronos.

Они реализовали другой алгоритм определения высоты (директива FIXDPOINT для прекомпилятора). Ты разобрался, как он работает?

Там получается все вносят изменения в 1 проект? Нет разделения веток для парашютистов/парапланеристов/горных походов?

Чем ты ее компилишь? Можно по шагам для dumb`ов?

Хм, что касается алгоритмов вычисления высоты, может кто-нибудь посмотреть и оценить (Желательно на экспириментах и модуляции ) то, что предлагает OpenChronos?

Что касается OpenChronos - открытые исходники, используется система управления версиями GIT

Фича Git в том что каждый может сделать ответвление от работы любого человека, и реализовать необходимые ему фичи. Причем отстальные могут отслеживать работу сообщества и очень просто интегрировать понравившиеся изменеия. Я взял за основу ветку с вариометром. Вот так щас выглядит история в виде графа.

скачать текущие исходники можно с моей ветки проекта.

Я компилирую при помощью msp430-gcc4 из под cygwin

== Requirements ==

msp430-gcc4 http://mspgcc4.sourceforge.net/

make

python http://python.org


== Supported Compilers ==


msp430-gcc4

   Working combinations:

   gcc=4.4.3 binutils=2.20.1 libc=20100430


IAR msp430


== HOWTO ==

Copy gcc/intrinsics.h into [msp430-gcc-path]/msp430/include/intrinsics.h


To configure your image, run:

   make config


which will generate a config.h file that contains the settings for your build.


To compile the image run:

   make


It is HIGHLY suggested to make a clean build before you flash the image with:

   make clean main

vti_ps.zip

[diwil 6]

вот тут хорошо предложено -

http://www.intersema.ch/index.php?option=c...&format=raw

а дальше кто во что горазд.

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

[wami 0]

вот тут хорошо предложено -

http://www.intersema.ch/index.php?option=c...&format=raw

а дальше кто во что горазд.

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

Интересно было-б выяснить что уже имеем, циферки вроде бегают довольно шустро.

Может так нормально будет считать. Ато уж больно лениво сильно заморочиться.

[diwil 6]

ну.. вот. два файла в архиве.

обращаю внимание на следующее -

1. коэффициенты 32х битные, поэтому и тип int32_t, int в mspgcc 16и битный , требует заголовка sys/types.h

2. макруха MUL_1_1000 это умножение на 0.001 т.е. деление на 1000 и может быть выполнено через деление. Тут надо смотреть что быстрее получится - или умножение 32х битных с 64битным результатом или деление . По размеру кода деление предпочтительней. По скорости - сложно сказать.

3. В принципе, можно перейти к 16и битной арифметике и избавиться от сложных делений, но это надо думать. мне в свое время это было не нужно.

4. погрешность пересчета давления в высоту не хуже метра на малых высотах и не хуже 0.5% на высотах больше 5000м

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

[wami 0]

ну.. вот. два файла в архиве.

обращаю внимание на следующее -

1. коэффициенты 32х битные, поэтому и тип int32_t, int в mspgcc 16и битный , требует заголовка sys/types.h

2. макруха MUL_1_1000 это умножение на 0.001 т.е. деление на 1000 и может быть выполнено через деление. Тут надо смотреть что быстрее получится - или умножение 32х битных с 64битным результатом или деление . По размеру кода деление предпочтительней. По скорости - сложно сказать.

3. В принципе, можно перейти к 16и битной арифметике и избавиться от сложных делений, но это надо думать. мне в свое время это было не нужно.

4. погрешность пересчета давления в высоту не хуже метра на малых высотах и не хуже 0.5% на высотах больше 5000м

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

Эмм.. А где собственно архив?

ЗЫ. мы модификатором volatile не увлекаемся, и знаем что это такое. Это креатив предыдущих разработчиков. Зачем так сделано, пока не понятно.

[Валера К 54]

ЗЫ. мы модификатором volatile не увлекаемся, и знаем что это такое. Это креатив предыдущих разработчиков. Зачем так сделано, пока не понятно.

Я могу сказать, зачем я поставил volatile Во время отладки CCS без volatile отображает переменные типа u32 или s32 только 2-мя младьшими байтами Т.е. до 32768, а дальше начинает врать. Стоило поставить volatile и все заработало как часы

[wami 0]

ну.. вот. два файла в архиве.

обращаю внимание на следующее -

1. коэффициенты 32х битные, поэтому и тип int32_t, int в mspgcc 16и битный , требует заголовка sys/types.h

2. макруха MUL_1_1000 это умножение на 0.001 т.е. деление на 1000 и может быть выполнено через деление. Тут надо смотреть что быстрее получится - или умножение 32х битных с 64битным результатом или деление . По размеру кода деление предпочтительней. По скорости - сложно сказать.

3. В принципе, можно перейти к 16и битной арифметике и избавиться от сложных делений, но это надо думать. мне в свое время это было не нужно.

4. погрешность пересчета давления в высоту не хуже метра на малых высотах и не хуже 0.5% на высотах больше 5000м

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

Эмм.. А где собственно архив?

ЗЫ. мы модификатором volatile не увлекаемся, и знаем что это такое. Это креатив предыдущих разработчиков. Зачем так сделано, пока не понятно.

[Лелик 97]

вот вам для изучения, лог прыжка на 72м Сирокко

данные с датчика давления и модуля GPS о высоте

в лог писалось 5 измерений в секунду

датчик давления работал в самом быстром режиме 100Hz

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

Калмана данные

11.xls

[wami 0]

Новая версия для теста 1.3.21

++быстрое обнуление высотника по долгому нажатию ВВЕРХ. (Мне такого метода вполне достаточно, и не надо никаких автоматических обнулений)

++при компиляции можно включить округление высоты в меньшую сторону до 50м когда мы выше 1000м. (выбрано по умолчанию)

++В режиме вариометра отключил надоедливое мигающий символ R

+работает вариометр(пускай пока и немного криво)

+добавлена возможность в режиме вариометра ничего не выводить в нижней строке (тоесть сверху высотомер, снизу пусто) (нажатие v в режиме варио внизу показывает варио\давление\макс-мин скорость\время в режиме\ пустой экран)

+по нажатию на подсветку экран светится секунды 3, а не пока нажата кнопка

+при блокировке по нажатии на подсветку не показывает Lock

+при компиляции можно установить 8 часовой таймаут для высотника (выбрано по умолчанию)

+при компиляции можно отключить фильтр высотника (выбрано по умолчанию)

+увеличено ограничение на ручную установку высоты до 7000м

В проекте

-интеграция альтернативного расчета высоты

-постоянна подсветка по долгому нажатию на кнопку подсветки

-/+округление показаний в зависимости от высоты/вектора скорости

-нормальный вариометр

-автоматическое выставление нуля

Кто может, присоединяйтесь к разработке https://github.com/Wami/OpenChronos

Комментарии, отчеты по ошибкам, пожелания, свои наработки крайне приветствуются.

скомпилировано для 868 версии в 3-х вариантах:

1. без округления с фильтрами

2. с округлением с фильтрами

3. без округления без фильтров

1_3_21.rar

[diwil 6]

мнда... архив мне прицепить не дают. могу отправить на почту.

Лелик, посмотрел данные. А что делать с "отрицательными" скоростями и наборами высоты во время ФФ?

А что такое высота КЛМН?

[Лелик 97]

мнда... архив мне прицепить не дают. могу отправить на почту.

Лелик, посмотрел данные. А что делать с "отрицательными" скоростями и наборами высоты во время ФФ?

А что такое высота КЛМН?

КЛМН это после фильтра Калмана

положительные скорости во время фф появляются в результате не точности измерения,

для этого и нужно фильтровать, GPS показывает довольно точно, без скачков, но это благодаря тому,

что в нем тоже на аппаратном уровне используется фильтрация, любые датчики фонят, нужно фильтровать

[diwil 6]

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

Тока похоже это второго порядка клмн. А что если его сделать constrained? и еще и 3его порядка?

а вот из опята GPS, особенно с непойми-какой-антенной, на малых высотах врет безбожно. Так что за основу вряд-ли его показания можно принимать.

[diwil 6]

ох, зараза, и намучался я ж с экселем...

altitude_filtering.xls

[Лелик 97]

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

Тока похоже это второго порядка клмн. А что если его сделать constrained? и еще и 3его порядка?

а вот из опята GPS, особенно с непойми-какой-антенной, на малых высотах врет безбожно. Так что за основу вряд-ли его показания можно принимать.

Тока похоже это второго порядка клмн. А что если его сделать constrained? и еще и 3его порядка?

хватает и такого, при 20 измерениях в секунду ресурсов много будет отъедать

а вот из опята GPS, особенно с непойми-какой-антенной, на малых высотах врет безбожно. Так что за основу вряд-ли его показания можно принимать.

у меня с нормальной антенной уверенно ловит в любом ЛА, не зависимо где находишся

точность отличная

[diwil 6]

ну... если борьба за ресурсы, то да.

ГПС ловить может отлично с какой-то там точностью. А на малых высотах начинает сказываться отражение от земли. В зависимости от используемого созвездия DOP может быть шикарным, а вот точка в пространстве, особенно по высоте, сильно съехать.