Нечёткие измерения, или фильтр Калмана

[Алексей Еремеев]

9 часов назад, We Are сказал:

У стрелок есть большой минус - их надо видеть.

а слепому и графики не нужны :-)

для контроля адекватности простого усреднения достаточно

посмотрите как устроены "цифровые" индикаторы на PFD

https://docs.flybywiresim.com/pilots-corner/a32nx-briefing/pfd/

Изменено 14 февраля пользователем Алексей Еремеев

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[We Are]

Речь про то, что все это нужнее автоматике - управление, контроль, учёт, статистика.

Там стрелки ну никак, некому на них смотреть.

А на графики есть кому, но до ввода в эксплуатацию и иногда после ))

 

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[Starichok]

@We Are , как часто ты производишь измерения? или иначе - сколько времени уходит на 50 измерений для твоего фильтра?

и какая инерционность процессов, которые ты измеряешь? то есть, как часто нужно проводить измерения?

и что у тебя по горизонтальной шкале (от 0 до 7000)?

[Реклама]

Особенности хранения литиевых аккумуляторов и батареек

Потеря емкости аккумулятора напрямую зависит от условий хранения и эксплуатации. При неправильном хранении даже самый лучший литиевый источник тока с превосходными характеристиками может не оправдать ожиданий. Технология, основанная на рекомендациях таких известных производителей литиевых источников тока, как компании FANSO и EVE Energy, поможет организовать правильный процесс хранения батареек и аккумуляторов. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[We Are]

1 hour ago, Starichok said:

как часто ты производишь измерения? или иначе - сколько времени уходит на 50 измерений для твоего фильтра?

В данном конкретном случае это было просто наглядное тестирование разных алгоритмов, одно измерение в 20 секунд, процесс разряда батареи (с тем же успехом можно брать данные по температуре - она тоже меняется плавно). Смысл в том, что все три варианта дают практически одинаковые результаты, кое-кто этому не верил, типа "вот так правильно, а вот так неправильно".
По горизонтали - количество замеров.

Подобных измерений много - автоматика.

[Реклама]

Секреты депассивации литиевых батареек FANSO EVE Energy

Самыми лучшими параметрами по энергоемкости, сроку хранения, температурному диапазону и номинальному напряжению обладают батарейки литий-тионилхлоридной электрохимической системы. Но при длительном хранении происходит процесс пассивации. Разберем в чем плюсы и минусы, как можно ее избежать или уменьшить последствия и как проводить депассивацию батареек на примере продукции и рекомендаций компании FANSO EVE Energy. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Starichok]

1 час назад, We Are сказал:

одно измерение в 20 секунд

если я правильно понимаю, на 50 измерений (для фильтра) уйдет 20 * 50 = 1000 секунд?

если для аккумулятора,то такое получение результата очень редко.

например, в моем приборе (моей разработки) для тестирования аккумуляторов напряжение и ток измеряются по 256 раз за 1 секунду, и результат представляет простое среднее из суммы 256 измерений. график получается идеально ровный, без "дерготухи", как на твоей первой картинке.

[We Are]

Все зависит от целей и задач.

Тестирование аккумулятора - это одно. Там нагрузка, заряд, разряд, всё должно быть в приемлемые сроки. Можно себе позволить молотить по 256 измерений в секунду, не вопрос. Самый простой вариант.

Работа оборудования на аккумуляторе - это совсем другое. Если расчетное время работы несколько месяцев - то любое лишнее шевеление - расход энергии впустую и сокращение периодов обслуживания. С другой стороны - и 1000 минут будет приемлемо, за это время существенных изменений быть не должно.
Или наоборот, если емкость аккумулятора несколько сотен Ач - там 1000 секунд вообще ни о чем, при этом нагрузка может быть нестабильна, и напряжение тоже.
Так-то у меня есть задачи и такие и такие.

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

Вот такого типа данные. 
Микроконтроллеры - это же не только про очередные "часы с термометром", это средство для облегчения контроля различных рабочих процессов.

 

[Starichok]

а что такое "достоверный результат" по отношению к счетчику Гейгера, когда события абсолютно случайны?

а какое отношение имеет фильтр Калмана к числу посетителей, гуляющих по коридору?

[We Are]

Есть такое понятие "радиоактивный фон". То есть, события абсолютно случайные, но происходят они в некоторой вероятностью: если вы стоите посреди чиста поля - это одно, если в гранитном мавзолее - это другое, а если на соседней АЭС "ничего не происходит, незачем волноваться" - это третье.
И во всех случаях фон будет разный, но требуется его оценивать, и возможно, принимать какие-то меры.

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

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

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

 

[my504]

Подтверждаю, что "упрощенный Калман" никакого отношения к фильтру Калмана не имеет. Это простейший IIR первого порядка именуемый как экспоненциальный фильтр, бета-фильтр или просто фильтр сглаживания...  Легко считается в целых числах, если они фикспойнт. Об этом выше упоминали.

А так да, все рекурсивные фильтры похожи своей рекурсивностью.... 

Скользящее среднее - это FIR с прямоугольным окном. Простейший фильтр с максимальным уровнем боковых лепестков на АЧХ.

Есть достаточно эффективные нелинейные фильтры. В том числе основанные на статистике сигнала.

 

 

Изменено 18 февраля пользователем my504

[ДядяВован]

В своей паяльной станции применил такую фильтрацию температуры (может быть это вариация одного из перечисленных в первом посте вариантов):

S - сумматор фильтра
X - новое значение измерения
Y - предыдущее, оно же новое отфильтрованное значение

S = S + (X - Y) * k
Y = S / m
k, m кратны степеням двойки (в частности k=128, m=256). Уменьшая k (64, 32 ...) "усиливаем" фильтрацию одновременно "замедляя" фильтр.

Написано на ассемблере, фильтрует хорошо, работает быстро.

[Starichok]

(X - Y) * k - фактически это приращение напряжения на конденсаторе в RC-фильтре за время dt.

и поэтому твои две формулы можно объединить в одну:

Ynew = Yold + (X - Yold) * k.

где новый коэффициент k равен твоим k/m.

а Ynew будет сразу новым результатом вместо твоей суммы  S.

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

[ДядяВован]

Возможно я исходную формулу и разбил на две, чтобы сохранить целочисленную математику и избежать умножения на k<1.
256 значений накапливать нет необходимости, при k=128 и скачкообразном изменении X от 0 до 1023 (значение АЦП), мы поучаем на выходе фильтра то же самое значение через 12 итераций.

Спойлер

 

[Yurkin2015]

11 minutes ago, ДядяВован said:

умножения на k<1.

Когда k, m равны степеням двойки, то такое умножение заменяется сдвигом вправо на разность степеней m и k. 

[ДядяВован]

26 минут назад, Yurkin2015 сказал:

на разность степеней

Да. это так.

Проверил, согласен, @Starichok прав, не нужно накапливать сумму. Результат работы фильтра одинаковый. Надо будет исправить прошивку на формулу:
Ynew = Yold + (X - Yold) * k

[Starichok]

42 минуты назад, ДядяВован сказал:

чтобы сохранить целочисленную математику и избежать умножения на k<1.

умножение на k<1 выполняется умножением на некоторое целое число и делением на другое целое число.

именно это ты и делаешь - умножаешь на 128 и делишь 256, при общем коэффициенте 0,5.

в принципе, у тебя получается 

либо сдвигом вправо на нужно число разрядов, как выше сказал Yurkin2015.

и у тебя ошибки в таблице - 130944  поделить на 256 получится 511 при целочисленных вычислениях. дальше я не проверял.

42 минуты назад, ДядяВован сказал:

256 значений накапливать нет необходимости

тут неправильно я тебя понял. теперь вижу, что накапливания не было.

если вычислять, как я предложил, то получится следующее:

1. 0 + (1023 - 0) * 0,5 (* 128 и / 256) = 511

2. 511 + (1023 - 511) * 0,5 = 767

3. 767 + (1023 - 767) * 0,5 = 895

и так далее.

как видишь, получается то же самое, как в твоей таблице.

[ДядяВован]

1 минуту назад, Starichok сказал:

как видишь, получается то же самое, как в твоей таблице

Да, благодарю! Проверил, именно так и получается.

[Starichok]

и еще два замечания.

1. при твоем коэффициенте 0,5 требуется сдвиг разницы один раз вправо.

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

без округления у тебя максимум получится 1022, так как 0,5 в целом виде прибавить не получится.

[ДядяВован]

25 минут назад, Starichok сказал:

и нужно работать с округлением

Ок. Но надо хорошо подумать, прежде чем менять алгоритм. Пока для меня не очевидно, что получится быстрее. С сумматором всё работает, а лучшее, как говорится, враг хорошего.

[IMXO]

1 час назад, ДядяВован сказал:

мы поучаем на выходе фильтра то же самое значение через 12 итераций.

получаешь ты его только по причине единичного изменения на входе....
попробуй взять k=8, m=256, S=Y=0  и Х = 5 или 7 вместо 1023 и посчитать это в целочисленной математике. Потом расскажешь через сколько итераций получишь Y= 5 или 7

 

[ДядяВован]

9 минут назад, IMXO сказал:

попробуй взять k=8

Зачем мне брать 8, если меня для паяльника устраивает 128 ??? 
Для фена k = 64.
Я же об этом написал:

5 часов назад, ДядяВован сказал:

Уменьшая k (64, 32 ...) "усиливаем" фильтрацию одновременно "замедляя" фильтр.

 

14 минут назад, IMXO сказал:

попробуй взять k=8, m=256, S=Y=0  и Х = 5 ... Потом расскажешь через сколько итераций получишь Y= 5

Ну если так интересно, то через 73

[Yurkin2015]

 

2 hours ago, Starichok said:

нужно работать с округлением

Кстати, по формулам д.Вована округление получается автоматически за счёт накопления "1" разницы пока результаты не сравняются.

Выходит, формулы д.Вована лучше  

Изменено 25 февраля пользователем Yurkin2015

[Starichok]

1 час назад, ДядяВован сказал:

Пока для меня не очевидно, что получится быстрее.

да, быстрее не получится.

про гораздо быстрее я напутал, так как думал про накапливание суммы из 256 значений.

вот что будет с округлением при числе 1023:

1. 0 + (1023 - 0) * 0,5 = 512

2. 512 + (1023 - 512) * 0,5 = 768

3. 768 + (1023 - 768) * 0,5 = 896

4. 896 + (1023 - 896) * 0,5 = 960

5. 960 + (1023 - 960) * 0,5 = 992

6. 992 + (1023 - 992) * 0,5 = 1008

7. 1008 + (1023 - 1008) * 0,5 = 1016

8. 1016 + (1023 - 1016) * 0,5 = 1020

9. 1020 + (1023 - 1020) * 0,5 = 1022

10. 1022 + (1023 - 1022) * 0,5 = 1023

и так, с округлением результат получен за 10 шагов. то есть, немного быстрее, чем у тебя.

[ДядяВован]

12 минут назад, Starichok сказал:

немного быстрее, чем у тебя

Под "бытрее" я имел ввиду время выполнения фрагмента кода, который реализует алгоритм фильтра.
 

[Starichok]

время выполнения каждого шага практически такое же, а число шагов меньше.

а еще если использовать сдвиг вправо, то будет еще быстрее, чем умножение на 128 и деление на 256.

[ДядяВован]

19 минут назад, Starichok сказал:

умножение на 128 и деление на 256

Умножение на 128 реализовано добавлением ещё одного младшего байта и сдвигом вправо на 1 бит.
Деление на 256 отсутствует, из трёх байтового сумматора извлекаются два "старших" байта.

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

Код писал 3-4 года назад. Сейчас у же всех нюансов не найти, но припоминаю, что перепробовал несколько разных фильтров. И даже возможно формула с накоплением суммы появилась не спроста. Поэтому так сразу изменить код не готов.