Одометр. Помогите с алгоритмом))
- Войдите на сайт для отправки комментариев
Втр, 20/08/2019 - 11:34
Всем привет! Делаю спидометр - одометр. Текущее значение скорости получаю по CAN-bus шине данных. Поэтому со спидометром вопросов нет, а вот с одометром немного не понятно, как лучше его значение формировать. Идея такая - каждую секунду фиксировать текущее значение, естественно в м/с, и прибавлять это количество метров. Что думаете? Может есть другие пути решения?
Не обязательно каждую сек. Всё зависит от точности. К тому же, как я понимаю, вам эти значения нужно сохранять в энергонезависимой памяти... Подумайте.)
Ага. В память, тоже каждую секунду. Вот на чсет точности - скорость, за туже минуту, может поменяться много раз. Либо расстояние быстро вычислять, где-то хранить и в пямять класть результат за минуту. Или каждую секунду это делать. Чего-то больше не могу сообразить.
Вам все равно придется что то вычислять, почему бы и не каждую секунду количество метров если ничто этому не мешает.
Интеграл мгновенной скорости даст путь.
получается, можно, например, за минуту накопить массив скоростей, которые были каждую секунду, затем интегрировав путь за минуту. так?
Ну да. А дифференциал пути есть скорость. Фактически так спидометр и работает ;)
массив скоростей, которые были каждую секунду
это очень большой интервал для численного интегрирования. Ошибка будет большая.
В итоге, все равно каждую секунду мы будем запоимнать скорость, для получение средней. Т.е. неизбежно выполнение действия через равные промежутки времени, где точность обратна равна ему(времени).
ну, няхай будет так. в первом приближении.
В итоге, все равно каждую секунду мы будем запоимнать скорость, для получение средней. Т.е. неизбежно выполнение действия через равные промежутки времени, где точность обратна равна ему(времени).
запоминать в ЕЕПРОМ и запоминать в памяти - разные вещи. В памяти ты можешь запоминать хоть каждую миллисекунду... доведя точность хоть до космических высот
массив скоростей, которые были каждую секунду
это очень большой интервал для численного интегрирования. Ошибка будет большая.
Хотя, если вместо кусочно-линейной аппроксимации заюзать сплайн, мошт и поточнее будет, на таких отрезках.
В итоге, все равно каждую секунду мы будем запоимнать скорость, для получение средней. Т.е. неизбежно выполнение действия через равные промежутки времени, где точность обратна равна ему(времени).
запоминать в ЕЕПРОМ и запоминать в памяти - разные вещи. В памяти ты можешь запоминать хоть каждую миллисекунду... доведя точность хоть до космических высот
ну ок, каждую мс не буду в еепром писать.)) память, тут общее понятие. в озу каждую секунду, в флеш раз в минуту или при выключении зажигания или когда-то там еще))
Блин ну что там сложного. 1 секунду проехал 120 км+1 секунду проехал 100 км... 1 секунду стоял. Ну так и считаешь сколько проехал каждую секунду.
я про это и написал в самом начале. так и хотел сделать. решил спросить у форумчан, про другие способы, более оптимальные например.
Получил по шине скорость, зафиксировал время получения. Получил новые показания и снова время. Разница по времени - сколько ехал. Скорости сложил разделил на два с какой скоростью ехал. Перемножил и получил сколько проехал. Теперь вопрос. В каком классе школьник может решить эту задачу?
я про это и написал в самом начале. так и хотел сделать. решил спросить у форумчан, про другие способы, более оптимальные например.
разве что
если вместо кусочно-линейной аппроксимации заюзать сплайн, мошт и поточнее будет
а если точности хватит со сложением расстояния раз в секунду, то можно и в лоб - вычислений все равно копейки
А ведь всё это начинается со специального датчика, который формирует 1 импульс на каждые N единиц расстояния...
А ведь всё это начинается со специального датчика, который формирует 1 импульс на каждые N единиц расстояния...
В теории - да. Но в моем случае информация о скорости приходит в сообщении, по кан-шине, раз в пол секунды(500мс).
В теории - да. Но в моем случае информация о скорости приходит в сообщении, по кан-шине, раз в пол секунды(500мс).
о скорости или о расстоянии?
EEPROM не советую часто записывать(ограничение по ресурсу записи)
попробуйте добавить аккумулятор или варистор большой емкости, что бы при выключении внешнего питания записывалось в EEPROM и затем отключить варистор или аккумулятор.
попробуйте добавить аккумулятор или варистор большой емкости...
хм... точно не варикап?
— Ну, конечно, знаю, оставьте меня в покое...
— Как вы себе представляете домкрат? Опишите своими словами.
— Такой... Падает, одним словом.
Упс, в точку.)))
В шине также может присутствовать инфа и по пробегу. Только в низкоскоростной салонной как вариант.
Точно нет. только скорость.
скорость это как раз вычисляемая величина. ЭБУ получает данные от датчика в виде импульсов, т.е. их количество это пробег. А скорость вычисляется, используя время тикания этих импульсов. вы хотите сделать обратные вычисления, будет очень грубый подсчет.
Если скорость в CANе обновляется раз в полсекунды, имхо пробег нормально не посчитать - слишком большие куски для интегрирования. А вижу, Деда уже выше это писал.
Машина какая?
есть вариант подключиться к датчику скорости и считать импульсы внешним прерыванием. Иногда сигнал с этих датчиков 5 вольтовый, в таком случае вообще всё просто. один провод кинуть.
скорость это как раз вычисляемая величина. ЭБУ получает данные от датчика в виде импульсов, т.е. их количество это пробег. А скорость вычисляется, используя время тикания этих импульсов. вы хотите сделать обратные вычисления, будет очень грубый подсчет.
Если скорость в CANе обновляется раз в полсекунды, имхо пробег нормально не посчитать - слишком большие куски для интегрирования. А вижу, Деда уже выше это писал.
Машина какая?
есть вариант подключиться к датчику скорости и считать импульсы внешним прерыванием. Иногда сигнал с этих датчиков 5 вольтовый, в таком случае вообще всё просто. один провод кинуть.
Как получается данные о скорости и пробегу в ЭБУ понимаю. И было бы проще подключиться к датчику скорости. Но у меня есть только посылка со скоростью.
Извиняюсь, ввел в заблуждение - посылка раз в 100 мс.
Все данные у меня идут по стандарту j1939. Это все что есть.
EEPROM не советую часто записывать(ограничение по ресурсу записи)
попробуйте добавить аккумулятор или варистор большой емкости, что бы при выключении внешнего питания записывалось в EEPROM и затем отключить варистор или аккумулятор.
Ионистор. В меге 168 есть супервизор питания? Или тут только доп вход, по пропаданию +5В использовать?
По пропаданию
Есть еще один вариант без акумулятора - Пробежали 1 км сбросили 1 бит в 0 . 8 км - 1 байт . 32 тысячи км это 4 кБайта . Ну и дальше по кругу. А где взять 4кбайта - так здесь #137
У меня на катере самодельная приборка, работает по Кан шине. Сохраняет значения расстояния и израсходанного топлива, когда видет что мотор не работает (заглушен) и сохранённое значение в EEPROM отличается от значения в оперативке.
Пройденное расстояние считается так-
dist += (float)sped/3600.0;
Каждую секунду добавляется пройденный путь за это время.
Есть еще один вариант без акумулятора - Пробежали 1 км сбросили 1 бит в 0 . 8 км - 1 байт . 32 тысячи км это 4 кБайта . Ну и дальше по кругу. А где взять 4кбайта - так здесь #137
Можно и внешнее ЕЕПРОМ, можно и внутреннее. Нам ведь не обязательно кольцо на 32 тысячи делать, можно и поменьше + счётчик колец.
Можно. Там и в часах озу есть. Если есть батарейка, то там накапливать расстояние поменьше километра до получния новой посылки скорости и подсчету прироста. А километры в ОЗУ писать.
ну раз в 100 мс должно быть норм. Считаете время, прошедшее после последнего CAN сообщения со скоростью. а далее плюсуете к одометру кусок пути , который по простой формуле: кусок пути = текущая скорость (в сообщении) * время (после последнего сообщения).
Имхо сохранять в еепром можно и периодически (при приросте км) и при пропадании CAN сообщений более установленного времени (или при пропадании питания на цифровом входе). при этом МК можно запитать от мощного конденсатора через диод, чтобы успевала в еепром сохранить при пропадании питания.
ну раз в 100 мс должно быть норм. Считаете время, прошедшее после последнего CAN сообщения со скоростью. а далее плюсуете к одометру кусок пути , который по простой формуле: кусок пути = текущая скорость (в сообщении) * время (после последнего сообщения).
Имхо сохранять в еепром можно и периодически (при приросте км) и при пропадании CAN сообщений более установленного времени (или при пропадании питания на цифровом входе). при этом МК можно запитать от мощного конденсатора через диод, чтобы успевала в еепром сохранить при пропадании питания.
Для чего считать время, если посылка идет очень точно по времени. Приять это время как константу 100 мс нельзя?
думается, что все равно разбег идёт в миллисекунды от 100. Шина ведь не всегда свободна ровно в это время. Другой вопрос велика ли погрешность будет из-за этих небольших разбегов. Можно пренебречь и да, сделать время одинаковое в 100мс.
Для чего считать время, если посылка идет очень точно по времени. Приять это время как константу 100 мс нельзя?
А почему бы его не считать. ведь это совсем несложно. Почему оно может меняться - MaksVV уже обьяснил. А я добавлю, что каждая миллисекунда сдвига туда или обратно даст примерно 1% ошибки - это совсем немало.
Для чего считать время, если посылка идет очень точно по времени. Приять это время как константу 100 мс нельзя?
думается, что все равно разбег идёт в миллисекунды от 100. Шина ведь не всегда свободна ровно в это время. Другой вопрос велика ли погрешность будет из-за этих небольших разбегов. Можно пренебречь и да, сделать время одинаковое в 100мс.
А почему бы его не считать. ведь это совсем несложно. Почему оно может меняться - MaksVV уже обьяснил. А я добавлю, что каждая миллисекунда сдвига туда или обратно даст примерно 1% ошибки - это совсем немало.
Не могу с вами не согласиться, буду считать)
И самое главное что можете один раз не считать посылку или считать с ошибкой. Так что лучше фиксировать время между успешно принятыми посылками.