Подменяем зашумленную ревльную кривую математически правильной синусоидой, у которой уже легко и абсолютно точно можно определить период. Достоверность апроксимации тоже можно оценить точно. Помнится, что то такое нам в институте рассказывали... Единственное ограничение этого метода - сэмпл должен быть действительно синусоидальным, а не переменной частоты.
Все это легко программируется.
Это лишь один из способов решения, который мне пришел в голову, при тех условиях которые вы привели. Может вам еще какие подскажут или вас натолкнут на другие решения.
Сначала надо попытаться аппроксимировать сэмпл гармоничной функцией. Это можно сделать разными способами. Например, тем же фильтром Калмана, у которого будет в качестве априорной модели установлена синусоида. Результат точности апроксимации тоже не сложно оценить по тому же средне-квадратичному отклонению.
Если так получится, то и измерять и считать особо ничего больше не надо. По подобранным коэфф.для апрокс. функции можно сразу посчитать частоту.
Если вы на 100% уверенны, что в сэмплах синусоида, а частота дискретизации точно в 3 раза, а лучше в 10 раз выше предполагаемой частоты гармоники сэмпла.
1 такой фековый запрос и всё пойдёт в кашу малашу.
В качестве альтернативы, представьте что хостится сервер правительственного/военного уровня. Ну так, чтобы просто ориентир был. Но только это не военный уровень, а просто один одноплатник за 45$ с повышенной безопасностью.
Есть способы борьбы и с этой напастью. Посмотрел в больших самолетах. Принцип называется "кворумирование". Почитайте, интересно. Кроме того, что программисты умеют отличать настоящий GPS сигнал от фейкового, так еще можно защититься кворумированием. Без него бы все Эрбасы-Боинги-Ту-204 -Сушки давно бы попадали. Три датчика = три сигнала не являются сами по себе резервированием. Только после процедуры кворумирования их показаниям можно доверять.
Я пытался скопировать решения с большой авиации. Система единого времени, СЕВ, раньше была развернута по всей стране, на земле и в космосе (почитайте, полезно для понимания принципов и повторения в своих системах, но на других источниках).
Плюс похожее решение (методически) применяются в современных авиационных инерциальных системах (ИНС), которым тоже вдохновлялись. Пока есть эталонный сигнал, работаем по нему, параллельно идет расчет своего сигнала, и мы его непрерывно корректируем по эталону. Пропал эталон, работаем по своему неточному расчетному сигналу. Ну и т.д. Появился эталон - снова работаем по ему и снова постоянно корректируем свой расчетный, до следующего пропадания. В итоге много не набегает. Например, для БЛА автономный полет (без коррекции) с расстояния 300 км ошибка возвращения в район аэродрома составляет 3 км. Это шикарно, потому что 1) вряд ли есть у кого то наглость глушить эталонный сигнал под носом у базового аэродрома, 2) есть еще запасные варианты, 3) иные источники эталонного сигнала по маршруту в районе аэродрома в кол-ве 4 шт... "Всех не заглушат".
Итого, как сделано у нас. При имеющихся компонентах - без вариантов.
Есть модуль GPS с 10 Гц в потоке и 1 Гц с синхросигналом PPS. Есть аналогичный модуль DS3223, по сути тоже самое - дата и время с точностью 1 сек и такой же синхросигнал 1 Гц (для нас он смысла не имеет, а вам может и как раз).
В Меге бежит свое неточное время millis(). Мы принимаем сигнал с GPS с частотой 10 Гц, в начале работы прописываем в DS3223 (не взирая на ее точность, принудительно, всегда), а затем при каждом чтении времени GPS ставим в соответствие "истинное время GPS" = millis() в основном микроконтроллере Мега 2560.
Была и другая мысль. Я поднимал программиста на, как уже упоминал ранее, на обработку по прерыванию сигнала 1 Гц PPS с GPS (а в вашем случае это будет этот же сигнал с DS3223) и коррекция millis() микроконтроллера. На реальных интервалах много не набежит. Решение зависло, потому что появилась Ardu Uno R4, со встроенными точными часами, внешним питанием часов и вроде как точными до миллисекунды.
И потом, рассмотрите реальные интервалы пропадания эталона. Неужели действительно у вас год не будет GPS? Ну ОК, тогда используйте DS3223. Она хорошо работает на длительных условиях (погуглите, где то написана конкретная точность). Но все равно периодически ее надо по чему то корректировать тоже и обрабатывать по прерываниям сигнал PPS.
П.С. Техническая подробность:
модуль DS3223 уже I2C, а вот простые GPS на базе народного чипа UBLOX сплошь UART. Обработка последовательного порта отъедает очень много времени у основного микроконтроллера. Мы сделали по сути "распределенные вычисления". GPS подключили к Ardu Pro Micro. Она принимает информацию с GPS, отбрасывает не нужное нам, переупаковывает, и по запросу основного контроллера Мега 2650 отправляет готовую инфу, а он сразу не обрабатывая ее пишет на SD. Такое решение работает быстрее, чем прямое подключение GPS к Меге.
Константин, не могу ответить нечего конкретного. Заказал перед отпуском, лежит на работе, привезут в Россию только 9 сентября. Сам еще не видел, в руках не держал.
В описании к плате написано, что должно быть точно. Неточные часы внутри Ardu - это известная проблема.
А еще сейчас модуль часов - внешний, на шине i2c. Сам модуль DS3223 весьма точный, пара секунд в месяц, вроде. Год - это все таки долго.
Мелочь, но задержка между запросом времени по шине и обработкой полученного значения тоже есть. И опять - дискрета выдачи с модуля 1 сек. Ну не предусмотрены в модуле mills(), "а мне надо".
Константин, понял, а то я подумал, что троллинг. Тогда надо подумать.
Для моих задач точное время особо и не нужно. Мы работаем в относительном времени - зачетный режим в течение 2-3 мин. Ну еще синхронизация с другими устройствами, но пока эта проблема остро не вставала, поскольку все пока находится под контролем одной Меги 2560, которая и время считает и пишет.
Оказалось, что Ардуино сильно тормозит на некоторых командах. Ну например, на обработке данных по UART порту. А команда измерения интервала времени между импульсами pulseIn() вообще может остановить работу контроллера. Вот на этом мы и споткнулись.
Потому решение поставить Арду на работу с GPS (UART) и общаться только по I2C несколько спасают ситуацию.
Аналогично с АЦП. Аналогично с замером ширины импульсов ШИМ - два раза не прислал данных, ушел в задумчивость, получит сигнал от какого нибудь контроллера на перезагрузку. Чем не многоядерность и распараллеливание задач?
Основному контроллеру оставили только общение по I2C с периферией и запись на SD. Полученная скорость записи данных нас устроила, возможные пропуски данных - обычное дело, сбойные участки обрабатываются математикой потом, на постобработке.
Borys Latysh, оно конечно одно ядро против двух и 16 Мгц против 70 всегда проиграет.
Оказалось, что Ардуино сильно тормозит на некоторых командах. Ну например, измерение интервала между импульсами, на обработке данных по UART порту... Потому решение поставить несколько Арду и общаться только по I2C несколько спасают ситуацию.
В моих задачах (регистрация данных) большой математики нет, поэтому ничего не могу сказать.
Почему должны, почему независимо? Автор как раз спрашивает - а можно вместе?
Говорю же - от задачи надо идти. Можно и вместе.
Если известна математическая модель источника фильтруемых данных, то на основании предыдущих данных, подставленных в матмодель делается прогноз (расчет) на следующий сэмпл времени, и в зависимости от ошибки между прогнозом и реальным следующим значением, учитывая частотные и/или статистические настройки фильтра вычисляется следующее отфильтрованное значение.
Можно и одиночный параметр отфильровать, опираясь только на частотную характеристику и простую апроксимацию по предыдущим данным и построенному по апроксимирующему полиному нужной степени вычислить уже значение, которое будет являться отфильтрованным.
Оба метода похожи, и хороши, но практический результат сильно разный будет. Первый метод значительно сложнее, но зато он дает более достоверные результаты для реальных объектов, где чаще всего оси все таки связанны.
Например, искусственный горизонт. Там тоже три оси X, Y и Z, но назвать их несвязанными никак нельзя. Как минимум это углы Эйлера одного и того же объекта, между которыми один и тот же угол постоянно - 90°. Если, например это акселерометры, и движение очень медленное (вычисляем по производным тех же акселерометров и угловым скоростям), то связь между всеми тремя осями акселерометров - простая тригонометрия. Фильтровать отдельно показания осей X, Y и Z такого объекта - грубейшая ошибка.
И еще. Автор говорит о фильтрации, а вы предлагаете сгладить. Это не одно и то же.
Сгладить можно да хоть скользящим средним, самый простой метод. Выбирается база (количество точек) и считается среднее значение. Полученная цифра - и есть сглаживание.
Как только сигнал становится сильно изменяющимся по времени сглаживание даст заметное запаздывание, а на определенных частотах вообще перестанет работать и даст шум. Даже МНК дает результат лучше.
Дополню лишь, что CS - это сигнал Chip Select, ну то есть как выше сказали, выбор устройства. Тогда устройство будет реагировать только на команды и данные отправленные непосредственно для него.
TFT:
sck - 13;
sda - 11; - это сигнал устройств с интерфейсом I2C
А тут вообще все в кучу:
RFID: sda - 10;
sck - 13;
mosi - 11;
miso - 12;
rst - 9;
SDA- это опять I2C
а MOSI и MISO - это прием-передача данных по шине SPI.
!SS - то же самое что и CS.
SCK - синхроимпульсы, тактирование.
Возможно автор использует устройство которое работает по любой из двух шин, и подключил его к обеим? Наверное, так тоже не надо делать.
Типичная ошибка любителей изучать инерциальные навигационные системы. Извините, поправлю, подбешивает.
Фильтр Калмана не является способом получать координаты. Взгляните на название - это всего лишь фильтр. Это хороший фильтр, адаптивный и настраиваемый. Для того чтобы его настроить надо иметь мало-мальски похожую математическую модель движения объекта - система дифференциальных уравнений движения объекта в пространстве. Отсюда и получается, что вы как бы решаете задачу задом наперед - ой, для сглаживания показаний нам нужен фильтр Калмана. А фильтру Калмана для корректной работы нужна модель. Причем даже уравнения модели движения для фильтра приходится выворачивать наоборот - как будто мы знаем координаты и параметры движения объекта, то что должны показать датчики? Построив такую модель, по сути мы сами уже на 50% решили задачу вычисления координат. Если это не самолет, то можно и без Калмана обойтись, простыми частотными фильтрами, а то и вообще скользящим средним. Способов сглаживания - миллион.
Фильтр Калмана приходится использовать лишь из-за того, что чем чувствительнее датчик, тем больше он шумов примет, и отделить шум или упорядочить его можно только хотя бы примерно зная куда движется объект. Если движение объекта не слишком быстрое и не сильно зашумлено внешними воздействиями (не как самолет или квадрокоптер - турбулентность, неидеальная аэродинамика, вибрации от оборудования на борту), объект движется не по всем трем осям одновременно, то можно использовать другие датчики, и тогда не нужен и фильтр Калмана.
Если у вас автомобиль, то можно вообще другими способами получать координаты. В свете СВО снова актуальной становится локальная триангуляционная навигационная система - на расстоянии 300 км друг от друга расположены передатчики навигационного сигнала. Поскольку все это на земле, то заглушить их сложно, потому что мощность в сигнал можно вкачивать какую угодно, да еще и шифрование применять и менять шифр хоть каждый час.
Считайте что подкинул вам идею. И это не обязательно должен быть радиоканал.
То, что координаты можно получать путем двойного интегрирования перегрузок и введением какой-либо коррекции (колеса, магнитометр, специально установленные маяки) - все правильно и не новость. Тут я согласен.
Но для автомобиля интегрировать перегрузки - это самый длинный путь к результату. Даже на самолете координаты вычисляют интегрируя угловые скорости, получают крен-тангаж-рыскание, и далее всю навигацию считают по аэродинамическим формулам. Акселерометры и магнитометры же в авиационной ИНС как раз нужны для коррекции или для определения начального положения (и то - из-за неквалифицированных пользователей, а то и это бы не делали). Например, бомбардировщики выставляют ИНС 45 мин стоя на точках с заранее известными координатами, и все получается. Авиационная ИНС в чисто инерциальном режиме имеет 5 источников для вычисления поправок - от радиостанций двух типов, датчиков угла и сноса на самолете, компасов разных типов и от той же самой СНС, если она выдает достоверные координаты.
Стоит ли ТС запускать по такому неоправданно сложному пути для такой простой задачи, как автомобиль?
Deahesi, вариант подмены координат возможен. Но зачем такие сложности?
Ublox в Matek передает координаты текстом в протоколе NMEA-0183. Теоретически, вы можете скармливать контроллеру свои координаты, но зачем тогда вам контроллер.
Есть открытые системы, Навроде Ardupilot. Вы там можете вставить свой код куда хотите.
В настоящих БЛА режим управления реализован не так, как в маленьких. Там два блока - КСУ и БИОС. КСУ занимается только стабилизацией, управлением, выполняет базовые простые маневры. Фактически, реализует только полет от точки к точки. Можно найти такой контроллер.
БИОС хранит маршрут, POI, и рассчитывает полет в соответствии с целью полета, скармливая координаты КСУ. КСУ как осел к морковке тупо идет к указанной координате.
Именно сейчас мы с коллегой на Ардуино делаем бортовой регистратор данных (т.н. "черный ящик") для научных испытаний одного подвижного объекта. Поскольку контракт подразумевает сотрудничество с французским предприятием-партнером, то, как говорится - угадайте, где мы находимся последние два месяца?
Теперь об арду и нашей задаче. За базу была взята Арду Мега2560, но за полгода мы поняли, что это слишком сложная задача для нее. Начиналось все с 8 параметров - крен, тангаж, перегрузки по трем осям и все gps-ное. Постепенно задача выросла до 45 параметров, причем некоторые Главному конструктору хочется регистрировать с частотой более, чем 20 Гц.
У нас быстро возникли проблемы с контактами дюпонт. Слабая диагностика и скромный перечень ошибок маскирует отсутствие контактов. Особенно при записи на SD. Искали долго, пока не догадались. Пришлось перейти на макетные платы и пайку модулей-шилдов.
Возникли проблемы с авиагоризонтом от китайцев. Старая версия прекрасно работает с GPS, но не подключается к IIC. Новая версия не видит GPS. Даже по переписке с поддержкой видно, что китайцы пугаются вопросов и с испуганными лицами разбегаются от нас. С трудом добились от них кое чего. Оказалось, что они поделили изделие на два направления, и никому про это не сказали. И ПДФки не обновляют. Два месяца мы потеряли только на этом. Прилаживая костыли заодно кое что пикантное выяснили и про GPS.
Приемники GPS от ublox - устройства, которые просто лупят данные в УАРТ и плохо поддаются управлению. Пришлось приемник повесить на отдельную Арду Нано и упаковывать его данные и уже тогда можно получать по запросу с шины IIC. Кроме того, приемники оказывается бывают с памятью и без памяти. Продают в основном без, а нам тепрь нужно с памятью, что бы хранить свои уникальные наработанные настройки. На это потратили еще месяц.
Некоторые регистрируемые параметры были либо ШИМ либо частота. Нужно было измерить их параметры. Поняли, что Мега просто не успеет справиться с таким количеством задач. Либо нужно что то более высокочастотное, либо еще одна Арду.
Устав от этого, решили перейти на ESP32, в частности Пиранья. Пока любовались сим произведением отечественной электроники (без юмора, правда - красивая плата), пришла простая мысль, что нас достала не меньше и сама среда программирования. В итоге начали писать программу в MS VS 2022 максимально близко к С, отлаживать, и потом просто переносить исходник в IDE. А все эти плагины (два) под Студио погоды не делают.
В итоге, второй регистратор мы уже делаем на OrangePI, который программируется хотя бы библиотеками понятной ОС, в нормальной среде MS VS, со всеми возможными библиотеками и прочим. Периферия та же.
К чему это все? Да к тому что, любая реальная, казалось бы, простая задача потребует от инженера максимума знаний и времени. Поэтому не важно, на каком железе и в какой среде, это лишь детали. Основное время займет удержание в фокусе конечной цели, осознание правильности выбранного решения, поиск решений и обходов, отладка. То есть именно Ардуино усложняет работу, если работаете больше чем с 3 входными устройствами, но суть то от этого не меняется.
П.С.: наши французские коллеги из бригады силовых установок городят свой блок управления электрической силовой установкой. И тоже на Меге 2560. Абсолютно не испытывают никаких угрызений совести и ощущений собственной неполноценности. Перенести отработанные решения на другое железо - это уже задача программиста, с бюджетом 1 месяц. Я с ними согласен.
П.С.С.: надо ли говорить, что наша работа на половину состоит из авиамодельного и радиокружка в лучших традициях дома пионеров. Много слесарки и пайки. Датчики надо установить, макетки напилить, корпуса напечатать, провода и разъемы спаять.
В IDE есть меню Инструменты и пункт меню что то типа "Получить информацию о подключенной плате". Если ответ хоть какой то приходит (название контроллера, процессора, серии, номера), то связь контроллера с IDE есть - драйвера установлены и работают, мост подключен к устройствам Windows и COM порт ему назначен, кабель исправен.
Я бы сказал, что здесь не работает bootloader, но меня смущает конкретный код ошибки 0х47.
Я сам удивлен, что продаются устройства 10-тилетней давности с до сих пор не исправленным программным обеспечением. У меня лежит оригинальная итальянская МЕГА2560 с неработающим bootloader, и я даже с помощью программатора не могу ее победить.
