Листая ленту, заметил вариант высотомера на модуле барометра BMP180.
Вспомнил, что сам когда то писал, ну типа библиотеку, для данного барометра. Но тогда я делал это первый раз и цель была именно написать с нуля для любого датчика, чтобы понять как и что происходит, какие фалы требуются, каково должно быть их содержание. Первый раз для соединения по I2C использовал ардуиновскую wire.h, достаточно провозившись тогда с поиском описания её работы, но в итоге все же запустил датчик. И немногим позже, разобравшись с работой регистров микроконтроллера, уже переписал под свое видение соединения.
По своей сути библиотеки датчиков не сильно отличаются друг от друга. Если это барометр, делаем запрос, он его обрабатывает и кладет в свой регистр результат. Его нужно прочесть по прошествии некоторого времени. И это кстати говоря довольно серьезный минус. На многих более современных датчиках есть возможность включить режим, когда датчик постоянно будет вести расчет и скидывать результат в регистр. В этом случае процесс рабочего взаимодействия сократится до чтения одного регистра. Причем, даже если произошло чтение данных которые еще не успели обновиться, это ни как не влияет на работу программы. Не изменилась например температура, в сравнении с прошлым запросом, ну вполне себе ситуация. Иначе внутри функции нужно проставлять delay. Либо делать две функции, первая запрос, вторая чтение. Но конкретно здесь для пользователя все еще усложняется и тем, что можно запросить не единичный замер, а выборку из 2, 4 или 8 значений. И время на обработку таких запросов тоже разное. А чтобы соответствовать стандарту “User Frendly”, все это нужно отдавать на откуп функции или методу.
Тогда я впервые засомневался в необходимости больших скоростей микроконтроллеру, если большую часть времени он попросту ожидает данных от датчиков.
После прочтения данных, их нужно привести к человеческому виду. В большинстве случаев все очень просто, 1 бит значения = сколько-то мили…чего-то там. Но в случае с барометром, присутствует еще ряд довольно емких расчетов, для приведения сырых данных в Паскали. Причем когда их пишешь, ни на секунду не отпускают сомнения, что все это заведется с первого раза. Но необходимо лишь точно следовать указаниям из даташита.
На этом вроде как и должно быть всё. Данные получены. Продвинутым летчикам даже дельту искать не нужно, для приведения высоты к метрам, футам и прочим условностям, все и так измеряется в Гектопаскалях.
Если же продолжить движение дальше, то для высотомера нужна еще и нулевая точка. Высота будет определяться разностью значений, между ней и текущими данными. Это будет набор среднеарифметических данных за некоторый отрезок времени, и чем он больше тем лучше. Но итоговый результат все равно довольно сильно скачет, при том что устройство не двигается, а покоится на столе. Это шумы самого АЦП барометра и природные колебания температуры и атмосферного давления.
Уж на этом точно можно остановиться? Если высотомер например для спортивной ракеты, то да. Тут особо ничего не выдумаешь, если данные «шумят», ничего не поделаешь, необходимо использовать самый быстрый режим, одна или две выборки. И с большой вероятностью погрешность измерений не выйдет за пределы метра.
Но если планируется самолет или коптер, которые не обладают столь стремительной скороподъемностью, то колебание высоты можно попробовать устаканить.
Для начала можно посмотреть настройки самого барометра.
Но чего-то более интересного и значимого там нет. Регистр 0xF4, это для запросов. А так как вариантов не много, они прям в даташите сформированы в виде конкретных, константных значений.
При запросе давления, необходимо запросить сперва температуру из датчика в самом барометре. Она необходима для расчетов. Но на запрос температуры тратится времени как на запрос одного значения. Если предположить, что температура не меняется за промежуток 0.1-0.3сек (такие промежутки опроса планируются использовать), то для большой пачки данных, которые будут впоследствии устаканиваться среднеарифметическим, достаточно будет одного запроса. И за тот же, период можно будет запросить больше данных, чтобы получить более правильное среднеарифметическое. Но практика показала что все становится только хуже. И пришлось сделать наоборот, для режимов с количеством выборок 4 и 8, (oss 2 и 3) запрос температуры происходит дважды. До запроса давления и после. Это немного снизило слишком резкие пики. Возможно температура будет не столь актуальна для минусовых значений. Чтение непосредственно тех значений температуры которые употребляет барометр при расчете давления показало, что да, они немного скачут, в пределах 1-2-3, реже 4 значения.
На первый взгляд у нас имеется электронный прибор, точность которого физически ограничена его внутренними, конструктивными особенностями. Он выдает Паскали и милиПаскали из него не выдавишь, но это только на первый взгляд :) Нужно лишь к прибору прикрутить небольшой математический аппарат.
В чем физическая суть этого действия. Глядя на электронный, измерительный прибор, к которому не прикручен гистерезис, порой можно заметить постоянную смену последнего знака. На мультиметре он например принципиально не прикручен. То есть АЦП прибора вроде как уже фиксирует значение на единицу выше, но лишь в один из периодов времени. И если за отрезок времени или 10 значений, число 12 было 5 раз и число 13 было 5 раз, то и математически и логично что мы имеем дело с цифрой 12,5. Только это будет не дробное число, чтобы не терять остаток, а так и останется суммой. То есть будет не 12,5 Паскалей, а 125 дециПаскалей. А если будет выборка из 100 значений, то это уже будет сантиПаскали, если 1000, то это уже миллиПаскали. Все дело в том, что на практике нужно двигаться в обратную сторону или по крайней мере не сдвигаться вниз, в санти, милли и пр. Но сантиметры достаточно удобны для коптера, а дельта в 120 миллиПаскалей = 1см. Да и 120 достаточно хороший запас, если будут еще уточнения. Путем например увеличения количества барометров.
В целом, это конечно же ни какое не увеличение точности, это среднеарифметическое, только без потери остатка. Так как в расчет попадают не только колебания соседних друг к другу чисел, но и все другие значения что успели появиться в измеряемый период. На практике, пока что 1000 значений, даже порой и 100, достаточно много, так как присутствуют следующие ступени сглаживания результата. Поэтому санти- и деци- Паскали чаще всего приходится умножать на 10 и 100, чтобы довести до канонических милли-. Но ценой всему время, а его барометру очень не хватает, когда изменения высоты происходят достаточно быстро.
Выглядит это все куда более проще.
Стоит отметить лишь переменную delta_altitude_santimetr. Для расчеты высоты я начал искать в инете, а сколько же в одном метре Паскалей? И везде натыкался на разные цифры. Хотя значение немного меняется, в зависимости от высоты, но разница была куда более значительной. Потом оказалось, что в самом руководстве на барометр есть указание на этот счет.
Может показаться что всё? Но это только начало.
Показания все равно достаточно сильно прыгают. Чтобы их сгладить, можно применить еще одну разновидность среднеарифметического. Этакий цикличный перерасчет. В этом случае, каждое новое значение пишется в массив относительно небольшой длины. При каждом вызове, на следующее место, затирая старые данные. Как например циклическая запись на SD карту. А после записи функция производит среднеарифметические со всеми данными массива. Преимущество, в высокой степени сглаживания данных, которая зависит от размера массива и очень быстром получении результата. Минусом является высокая инерция показаний, которая будет зависеть от размера массива. На графиках ниже видно, как пики и моменты роста и снижения графика сглаженного значения отстают от текущих значений, которые тоже сглажены, но только первой ступенью.
На графике 3 можно заметить еще одну особенность, это ошибочный выбор нулевой точки. На первых двух, значения хоть скачут, но делают это вокруг нулевой отметки. В третьем случае, период расчета нулевой точки пришелся на участки сниженного давления, и в результате все показания, хоть и более сглаженные, но сдвинуты вверх на 15-20см.
На основании этого вырисовывается один из вариантов значительного снижения пульсаций давления, это получать текущие значения давления нулевой точки, от самой земли, то есть с такого же барометра, например пульта управления. Тут ничего нового, всё как в большой авиации. Так как можно предположить, что атмосфера достаточно изотропна, на некотором расстоянии. Но здесь нужно тестить, причем уже на летающих моделях.
Как мне кажется, общую тенденцию роста или снижения давления можно будет передать, а вот сгладить таким образом небольшие, частные бугры, не факт что получится. Они могут быть как порыв ветра, двигаться с определенной скоростью. И один и тот же бугор, не факт что получится синхронизировать, между нулевой точки с земли и текущими показаниями с воздуха. Без лишних движений разумеется.
Так как опасно сильно утяжелять методы условиями, в погоне за идеальным результатом. Атмосфера штука сложная, имеет разного рода эффекты, типа сдвига ветра, турбулентности и пр. Как мне кажется стоит оставаться максимально консервативным в выборе средств.
Данный одиночный график, это вариант избыточно большого массива, но как результат с хорошей степенью сглаживания.
Чтобы более наглядно видеть проблему, я сделал еще ряд замеров, в которых я поднимаю макетку с пола, на высоту вытянутой вверх руки, настолько быстро, насколько могу, и так же быстро опускаю, через некоторое время. По замерам высоты это примерно 2.2м.
Второй бугор на первых двух графиках, это попытка относительно плавного подъема, но тут видно что все достаточно приемлемо. Вырисовывается вариант решения этой проблемы, это использование акселерометра. Как только по оси Z пошли сильные изменения , то массив заполняется нулями а его размер указывается равным 8, 4, или даже 1. То есть на момент подъема данные будут поступать без второй ступени сглаживания. Второй вариант это изменять размер массива на основании данных от пульта управления. В этом случае все остальные изменения давления можно сглаживать самыми сильными методами. Разумеется физически сам размер массива не меняется, он как создан, так и остается с тем же размером, меняется лишь аргумент функции, который указывает на его размер.
Все так же выглядит достаточно просто, проблема лишь в static счетчике, его конечно можно вынести наружу. Но здесь очевидным образом назревает C++ класс, в котором все будет крутиться, включая методы очистки массива и прочие движения. Счетчик в этом случае будет индивидуален под каждый объект. Пока, для общих тестов, оно в таком виде.
Так же был произведен замер на улице, но не шибко удачный, так как происходил момент уверенного снижения атмосферного давления и мелкие зубцы оказались отмасштабированы. Хотелось в первую очередь сравнить, имеют ли они схожий характер. Но были зафиксированы участки короткого, но достаточно сильного увеличения давления, которые вероятно могли быть вызваны коротким порывом ветра. Что наводит на мысль, что барометр стоит упрятать в какой-нибудь лабиринт.
Можно так же более детально исследовать саму атмосферу. Поставить несколько датчиков на удалении, посмотреть как двигаются все эти бугры и прочие возвышения.
Но это уже будут результаты когда-нибудь следующих изысканий.
Функции доступны по ссылке на сайте и на ЯндексДиск: