Спасибо за пояснения, сейчас понятнее. Что касается будущего этого проекта, то он и создан чтобы не продолжаться, результат более-менее рабочий получен, этого достаточно. Для вывода его в продакшен требовались бы трудозатраты на порядок выше, так как до продукта это далеко
Вполне возможно, толком сигнал я не исследовал, хотя изначально предполагал. Объем всего остального функционала меня поглотил, как итог получилось всего по чуть-чуть и ничего доверенного до идеала :) видел много работ, связанных именно с методами определения качества по показаниям акселерометра, но оно так и осталось в мыслях :/
Про 2ms написал условно, я там менял настройки акселерометра, отвечающие за рейт этот, по дефолту было много больше.
А всё-таки про поточное чтение — механизм тот же взаимодействия акселерометром, только устанавливается настройка при ините?
В общем да, только отправляю данные и очищаю когда график начинает двигаться в противоположную сторону (место перегиба).
Хм, интересно, не в курсе про разные режимы (точнее знаю про много настроек, но пользовался только частотой и точностью). Да, судя по тому, что я прочитал — проблема альясинга вполне возможна в моем случае. Но в моем случае это не изменит значение качества дороги, так как форма не используется в алгоритме. А непрерывное чтение как происходит, какие механизмы отличные от моего варианта?
Тут сознательно остановился на решении с мобильным устройством, этом мне показалось интереснее в данном случае. Поэтому, синхронизация через BT вроде ок решение в моем случае
А, имеется ввиду про ускорение по горизонтали?
Хм, не чувствую уверенности в этой области, но проясните, если можно. Начнем с того, что я не передаю сигнал и не хочу его передавать, так как его форма никак не использутеся, а только максимальные значения. Вот на простом примере для меня чтобы было понятно:
В первоначальной имплементации я каждые 2ms читаю значения ускорения и передаю их по БТ, после чего в данных для оценки качества у меня последовательность некая значений моментальных:
1,7,11,5,-2,-8,-4,0,3 => max = 11, min = -8
Чтобы отправлять меньше данных (принимая во внимание факт, что для алгоритма будут использованы только максимальные значения) мы читаем момнтальные значения быстрее, но отправляем только экстремумы
Для предыдущего примера это будет выглядеть как
11,-8 => max = 11, min = -8
В итоге алгоритм упрощенный даст те же оценки качества, но количество данных намного меньше. Где в моем рассуждении фейл?
Конечно же проект никоим образом не претендует на пример идеальной реализации, каждая из его частей может быть существенно усовершенственна
Да, проблемы с этим, определенно, были, из-за чего был имплементирован алгоритм Кристиана, который предполагает разное время задержек и кое-как справляется с этим. Что касается LoRa, никогда не слышал (да, я тот еще эксперт в электронике). В качестве мастер-устройства для синка времени может в данном случае выступить дефолтное андроид устройство с базовым набором периферии?
Не совсем понял про недостаточность GPS для позиционирования и как связан акселерометр с этим, можно поподробнее?
Пиками я обошелся по двум причинам — одна из которых то, что упрощенный донельзя алгоритм определения качества сегмента использует только экстремумы, без учета формы сигнала. Про проблему пиков не уверен, что вы меня правильно поняли. Основной вопрос был в том, что если передавать все значения измерянные вподряд, то на передачу уходит значительное время, во время которого нет возможности продолжать измерения ускорения из-за синхронной отправки данных. Поэтому высока вероятность упустить важные данные, передавая все вподряд.
на дропауте они есть, но на багажнике они были одного порядка с данными. Но здесь не очень релевантный пример, думаю основная проблема была в конструкции кронштейна и креплении багажника. Получалось так, что сам багажник вибрирует, вибрирует его часть, к которой крепился кронштейн, вибрирует кронштейн, а уже на нем акселерометр. Все это входит в резонанс и потом получилось как на фотке выше)
Подробные тесты не проводил, больше на основе предположений о физике этого явления. Первая установка у меня была на багажник, но, из-за вибраций в соединениях, кронштейн оторвал кусок багажника. Кроме того акселерометр ловил много шума во всех плоскостях, хотя должен был преимущественно по вертикали. Думаю, что проще всего действительно провести тест с синей изолентой и смартфоном)
Думал, что было бы круто, чтобы шеринговые электросамокаты собирали эти данные, такой объем данных нескончаемый был бы. Тем более у них все есть уже нужное на борту, кроме разве что акселерометра, хотя и он возможно в наличии
Да, я конечно это все понимаю. Про ценность при создании всего этого я больше думал для обучения, в первую очередь себя, иллюзий про реальную применимость этого вот всего не было :) Кстати, в осм точно есть атрибуты типа покрытия, возможно и качество там в каком-то виде присутствует
да, если речь про весь. Но часто это превращается в репорт про отдельную плиточку на тротуаре где каждая 5я плохая. А поскольку, я подозреваю, что у этих ребят тоже есть метрики, то получается они фиксят эти тикеты по отдельности, тратя намного больше сил и времени вместо того, чтобы подумать и заменить все целиком. Утрировано получилось, но, надеюсь, позицию получилось описать. Хорошо если у них есть какой-то мета-прораб, который в силах отследить тренды и не дать работягам фиксать то, что будут решать «фундаментально» объединив кучу заявок (предыдущих и будущих) и решив источник проблемы, а не симтом.
1. Не написал в статье, но мой метод исследования не предполагал каких-то отличий от повседневной езды. Ехал именно так как еду всегда — если на тротуаре тропинка с норм асфальтом, а по кругу ямы, то едем так как оптимально. То есть карта фактически показывает с какой минимальной болью(в то конкретное время) можно преодолеть дорогу, а не что нужно починить (что нужно починить это косвенно показывает конечно)
2. Все так, поэтому краудсорсинг решил бы проблему, механизм мержинга данных разных профилей/пользователей есть
3. Да, поэтому была идея получить некую унверсальную оценку качества. А каждое траспортное средство или наездник уже может выбрать дороги соответственно своим лимитам (весенний шоссер — q = 8-10, летний горожанин — q = 5-10, осенний мтбшник — q = 2-10) Получить такую оценку не так и просто, но идея такая была.
4. Та же идея, что и в 3м пункте
По поводу неадекватности наказания — привлекался не раз, но в этом плане минские по моим впечатлением намного адекватнее местечковых ГАИ (что кстати подтверждает ваш факт про просьбу съехать на тротуар, у меня тоже так было). Меня штрафовали за езду по дороге, но каждый раз в районных цетрах, когда я был навьючен велобаулом на пару дней путешествия и преодолевать бордюры никак не мог был. Один раз даже оштрафовали за выездом из мелкого города, потому что оказалось, что с другой стороны дороги (за встречкой) в низине есть тротуар загородный, который 20 метров, а мне после этого по дороге все равно ехать с автомобилями десятки километров. (обозначен был разноцветно и заметно) Что самое забавное — штрафовал меня начальник ГАИ лично этого города. После этого мои представления о справедливости немного пошатнулись :D
да, но оно больше подходит для «латания дыр», когда все уже сделано хорошо и правильно. А когда нужно переделывать например весь тротуар, менять организацию движения и тд., то исправление мелких «ям» выглядит как бессмысленная мышиная возня, оттягивающая время двух сторон от вопросов глобальнее. Поэтому отношусь осторожно к этому сервису, но для правильных целей он хорош, согласен
да, отсюда и плюсы/минусы как у любых краудсорсинговых проектов. Но я отдаю предпочтение в этом деле объему информации, которая есть на OSM, хоть и есть риск поиска брода
Прям истории с моей maps.me навигацией :D Часто кажется, что там, где пробежала собака — уже тропинка, а там, где по полю проехал разок трактор — на карте это автобан
Как справедливо заметили в первом комментарии, здесь можно обойтись и одним смартфоном без пайки. Железное устройство здесь притянуто за уши, можно сказать от моих личных хотелок. Вроде даже есть приложения для работы с акселлерометром, которые могут писать в лог. Так что и кастомное мобильное приложение можно отбросить при желании.
Но так его юзабельность сужается конечно, а выкручивать вперед-назад надоедает, если активно фоткать например или разговаривать. Так что отдельный смартфон выглядит более выигрышным решением.
Спасибо за пояснения, сейчас понятнее. Что касается будущего этого проекта, то он и создан чтобы не продолжаться, результат более-менее рабочий получен, этого достаточно. Для вывода его в продакшен требовались бы трудозатраты на порядок выше, так как до продукта это далеко
Вполне возможно, толком сигнал я не исследовал, хотя изначально предполагал. Объем всего остального функционала меня поглотил, как итог получилось всего по чуть-чуть и ничего доверенного до идеала :) видел много работ, связанных именно с методами определения качества по показаниям акселерометра, но оно так и осталось в мыслях :/
Про 2ms написал условно, я там менял настройки акселерометра, отвечающие за рейт этот, по дефолту было много больше.
А всё-таки про поточное чтение — механизм тот же взаимодействия акселерометром, только устанавливается настройка при ините?
В общем да, только отправляю данные и очищаю когда график начинает двигаться в противоположную сторону (место перегиба).
Хм, интересно, не в курсе про разные режимы (точнее знаю про много настроек, но пользовался только частотой и точностью). Да, судя по тому, что я прочитал — проблема альясинга вполне возможна в моем случае. Но в моем случае это не изменит значение качества дороги, так как форма не используется в алгоритме. А непрерывное чтение как происходит, какие механизмы отличные от моего варианта?
Тут сознательно остановился на решении с мобильным устройством, этом мне показалось интереснее в данном случае. Поэтому, синхронизация через BT вроде ок решение в моем случае
А, имеется ввиду про ускорение по горизонтали?
Хм, не чувствую уверенности в этой области, но проясните, если можно. Начнем с того, что я не передаю сигнал и не хочу его передавать, так как его форма никак не использутеся, а только максимальные значения. Вот на простом примере для меня чтобы было понятно:
В первоначальной имплементации я каждые 2ms читаю значения ускорения и передаю их по БТ, после чего в данных для оценки качества у меня последовательность некая значений моментальных:
1,7,11,5,-2,-8,-4,0,3 => max = 11, min = -8
Чтобы отправлять меньше данных (принимая во внимание факт, что для алгоритма будут использованы только максимальные значения) мы читаем момнтальные значения быстрее, но отправляем только экстремумы
Для предыдущего примера это будет выглядеть как
11,-8 => max = 11, min = -8
В итоге алгоритм упрощенный даст те же оценки качества, но количество данных намного меньше. Где в моем рассуждении фейл?
Конечно же проект никоим образом не претендует на пример идеальной реализации, каждая из его частей может быть существенно усовершенственна
Да, проблемы с этим, определенно, были, из-за чего был имплементирован алгоритм Кристиана, который предполагает разное время задержек и кое-как справляется с этим. Что касается LoRa, никогда не слышал (да, я тот еще эксперт в электронике). В качестве мастер-устройства для синка времени может в данном случае выступить дефолтное андроид устройство с базовым набором периферии?
Не совсем понял про недостаточность GPS для позиционирования и как связан акселерометр с этим, можно поподробнее?
Пиками я обошелся по двум причинам — одна из которых то, что упрощенный донельзя алгоритм определения качества сегмента использует только экстремумы, без учета формы сигнала. Про проблему пиков не уверен, что вы меня правильно поняли. Основной вопрос был в том, что если передавать все значения измерянные вподряд, то на передачу уходит значительное время, во время которого нет возможности продолжать измерения ускорения из-за синхронной отправки данных. Поэтому высока вероятность упустить важные данные, передавая все вподряд.
на дропауте они есть, но на багажнике они были одного порядка с данными. Но здесь не очень релевантный пример, думаю основная проблема была в конструкции кронштейна и креплении багажника. Получалось так, что сам багажник вибрирует, вибрирует его часть, к которой крепился кронштейн, вибрирует кронштейн, а уже на нем акселерометр. Все это входит в резонанс и потом получилось как на фотке выше)
Подробные тесты не проводил, больше на основе предположений о физике этого явления. Первая установка у меня была на багажник, но, из-за вибраций в соединениях, кронштейн оторвал кусок багажника. Кроме того акселерометр ловил много шума во всех плоскостях, хотя должен был преимущественно по вертикали. Думаю, что проще всего действительно провести тест с синей изолентой и смартфоном)
Думал, что было бы круто, чтобы шеринговые электросамокаты собирали эти данные, такой объем данных нескончаемый был бы. Тем более у них все есть уже нужное на борту, кроме разве что акселерометра, хотя и он возможно в наличии
2. Все так, поэтому краудсорсинг решил бы проблему, механизм мержинга данных разных профилей/пользователей есть
3. Да, поэтому была идея получить некую унверсальную оценку качества. А каждое траспортное средство или наездник уже может выбрать дороги соответственно своим лимитам (весенний шоссер — q = 8-10, летний горожанин — q = 5-10, осенний мтбшник — q = 2-10) Получить такую оценку не так и просто, но идея такая была.
4. Та же идея, что и в 3м пункте
По поводу неадекватности наказания — привлекался не раз, но в этом плане минские по моим впечатлением намного адекватнее местечковых ГАИ (что кстати подтверждает ваш факт про просьбу съехать на тротуар, у меня тоже так было). Меня штрафовали за езду по дороге, но каждый раз в районных цетрах, когда я был навьючен велобаулом на пару дней путешествия и преодолевать бордюры никак не мог был. Один раз даже оштрафовали за выездом из мелкого города, потому что оказалось, что с другой стороны дороги (за встречкой) в низине есть тротуар загородный, который 20 метров, а мне после этого по дороге все равно ехать с автомобилями десятки километров. (обозначен был разноцветно и заметно) Что самое забавное — штрафовал меня начальник ГАИ лично этого города. После этого мои представления о справедливости немного пошатнулись :D
Но так его юзабельность сужается конечно, а выкручивать вперед-назад надоедает, если активно фоткать например или разговаривать. Так что отдельный смартфон выглядит более выигрышным решением.