Если вы используете велосипед для передвижения по городу, то, скорее всего, у вас есть какие-то вопросы к велоинфраструктуре и ее качеству.
Чтобы понять, что велодорожки вашего города не такие и идеальные достаточно простого кофе-теста.
Берем в одну руку стакан с кофе, во вторую руль и едем. Если после пары минут неспешной езды кофе не стекает по рукам-ногам-телу, то, скорее всего, у вас руки-амортизаторы (ну или вы использовали крышечку).
Во время такого непредвиденного теста пришла в голову мысль, что отвлекаться во время вождения опасно, а также карта наподобие Яндекс.Пробки, иллюстрирующая качество дорожного покрытия вместо заторов.
После долгих раздумий в голове сформировалось примерное видение того, что хотелось бы реализовать. Главным техническим интересом, позволившим ухватиться за эту идею, стала возможность наконец-то сделать какую-нибудь железку. К тому же в наличии имелась Arduino Uno, приобретенная 5 лет назад и оставшаяся без дела после дежурного мигания светодиодом.
Ниже представлена примерная схема решения, которая от появления идеи до ее реализации, не претерпела особых изменений, хотя реализация каждого компонента, как и способа их взаимодействия, конечно адаптировалась по ходу приближения к финалу.
Задуманная схема решения.
Все компоненты, представленные выше, можно условно разделить на три группы, соответственно роли в общем решении:
- Сбор данных. Задача — собрать сырые данные, необходимые для следующего этапа.
- Обработка данных. Задача этой части — определение некой количественной оценки качества сегмента дороги по данным с устройств, собранных на предыдущем этапе.
- Отображение данных. Задача — каким-то образом отобразить качество покрытия. Хотелось бы как Яндекс.Пробки и чтобы красиво.
При езде по городу Arduino с установленными сенсорами будет собирать данные и передавать по Bluetooth на мобильное устройство, которое в свою очередь добавит к ним дополнительную информацию о местоположении и сохранит на носитель. После этого обработаем полученные файлы с данными и определим качество дорожного полотна. В конце отобразим результат на карте.
Сбор данных. Arduino
Требования к данным
Для начала определим задачи — какие данные хотим получить.
Качество дороги может определяться разными параметрами, среди которых и уклон и прямолинейность и форма самого покрытия (по песку ехать так себе удовольствие). Но в нашем случае (вспоминаем кофе-тест) было важно насколько покрытие ровное, чем оно ровнее, тем ехать приятнее, тряски нет, скорость не теряется, пятая точка рада.
Итак, надо понять что есть тряска, чтобы определить методы ее измерения. Воспользуемся словарем
трясти — внешним усилием приводить что-то в колебательное движение с относительно высокой частотой
Если что-то приводить в движение, то в физическом смысле это означает изменение скорости. Величина, характеризующая изменение скорости — ускорение. Именно его и надо измерять. Так как трясет велосипедиста, обычно, в вертикальной плоскости, то и ускорение нужно получить вертикальное. Значения ускорения вполне можно заиспользовать для количественного определения качества покрытия.
Здесь нам понадобится акселерометр. Но, появляется еще вопрос — тряска на одном и том же участке, с использованием одного и того же велосипеда с наездником, может быть различной в зависимости от скорости движения. Если проезжать лежачий полицейский на разных скоростях, то ощущения разные (как и сила удара головой в потолок). Поскольку мы хотим получить некую универсальную карту, то, скорее всего, нам понадобятся данные о скорости, так как в нашем идеальном вымышленном мире оценка качества для одного и того же участка, пройденного с разными скоростями должна быть одинакова.
Делаем предположение, что оценка качества — некая функция от ускорения и скорости на участке. Упрощенно конечно, но для нашего любительского уровня сойдет. Как итог получаем две группы данных, которые будем пытаться собрать.
Для определения качества полотна:
- ускорение (по вертикали)
- скорость (по горизонтали)
Для привязки оценки качества к карте:
- время
- местоположение
- точность определения местоположения
Схема устройства для сбора данных о качестве дороги.
Компоненты
Как уже было сказано, у нас есть Arduino Uno, с ней добавим пару модулей для сбора и передачи данных.
Весь список используемых компонентов:
- микроконтроллер Arduino UNO
- акселерометр ADXL 345
- геркон NONAME
- bluetooth модуль HC-06
- кучка проводов и резисторов
Сборка
Я так себе эксперт в схемотехнике. Если быть точнее — делал все описанное в этом разделе впервые. Схемы и макеты плат были выполнены в easyEDA и перенесены на текстолит лазерно-утюжным методом. Интересное занятие, особенно для человека, потерявшего связь с "железной" реальностью.
Весь наш нехитрый набор компонентов можно было бы собрать на макетной плате, однако у нас есть требования к месту установки отдельных блоков. Так акселерометр потребуется установить на велосипед отдельно от микроконтроллера, по той причине, что его местоположение будет влиять на результаты. Нам потребуется выбрать для крепления часть транспорта с наименьшей амортизацией, чтобы каждая ямка на асфальте не осталась незамеченной.
Исходя из входных данных, было решено сделать две платы, которые уже будут подключены к Arduino. На первой плате разместим акселерометр с парой подтягивающих резисторов. Эта плата в последствии будет упакована и установлена отдельно от микроконтроллера.
Схема платы для размещения акселерометра.
Акселерометр. Ожидание и реальность.
На второй плате размещаем модуль для передачи данных и подтягивающий резистор для геркона.
Схема платы для размещения модуля передачи данных.
Модуль передачи данных. Ожидание и реальность.
Как вы могли заметить, все компоненты подключаются через коннекторы. Дело в том, что из-за неопытности в пайке да и в проектировании плат в целом, было решено минимизировать риски порчи модулей. Для этого запаяны на плату только дешевые коннекторы, а модули уже просто воткнуты в них. Кстати, на картинках выше изображены первые две платы в моем исполнении. Рассматривайте их компоновку и общее качество, как первый блин, который не обязательно правильный и оптимальный.
Упаковка в корпус
Поскольку девайс должен активно трястись и переносить возможные дождь, грязь, песок, то было решено упаковать в корпус.
Были попытки найти специально предназначенный корпус для подобных компонентов, но все потенциальные кандидаты были по разным причинам не ок. После безуспешных попыток поиска, были найдены на удивление подходящие коробки для разводки разных размеров в строительном магазине.
Коробки в роли корпусов. То, что нужно.
Один корпус для сенсора выносной установки акселерометра и второй побольше для размещения Arduino Uno с кастомной платой для Bluetooth модуля. Корпуса имеют фланцы, что позволит закрепить выносной сенсор по месту установки. Также здесь имеются плотно защелкивающиеся крышки и места под выводы проводов наружу.
Единственный минус выбранных коробок — отсутствие внутренних креплений. Для фиксации плат пришлось заколхозить пластину с установленными в нее стойками. Пластина вклеилась в дно коробки и добавила нашему корпусу недостающие крепления.
Микроконтроллер и плата передачи данных установлена в корпус. Провода — наше все.
Плата акселерометра установлена в корпус.
Установка на велосипед
Мы имеем два сенсора и сам контроллер в корпусе, что должно быть размещено на подопытном велосипеде.
Геркон. Изначально был приобретен отдельный компонент, без корпуса. Но потом, в размышлениях об установке его на велосипед, пришла мысль, что можно использовать геркон с обычного китайского велокомпьютера. Главное преимущество которого — он упакован в корпус и имеет специальную форму и крепления под перо велосипеда. Цепляем геркон на перо, фиксируем стяжками.
Геркон, проставка и стяжки.
Установленный геркон и магнит на спице. Выглядит надежно.
Блок акселерометра. Самое главное требование к установке — он должен крепиться жестко к раме, чтобы фиксировать все воздействия без амортизации. Изначально была попытка закрепить датчик на багажник, но в процессе тестирования оказалось, что при езде он очень сильно вибрирует, чем искажает данные. Более того, от непредназначенной нагрузки отломалась часть багажника, к которой был зафиксирован датчик.
При поиске нового места для крепления, в районе дропаута были обнаружены два отверстия под болты, идеально подходящие под задачу. Из стального уголка был изготовлен кронштейн, который болтами M5 фиксируется к раме и позволяет разместить сенсор на полученной площадке.
Корпус акселерометра, болты, гайки, планка кронштейна.
Корпус акселерометра установлен на кронштейн и ожидает подключения.
Блок микроконтроллера. Данный компонент уже не требует особой установки. Кладем в сумку на багажнике, подключив к пауэрбанку и протянув нужные провода к блокам сенсоров.
Блок микроконтроллера в корпусе.
Прошивка
Наш собранный девайс должен выполнять три функции:
- подсчет скорости с помощью геркона
- сбор данных с акселерометра
- передача данных по Bluetooth на мобильное устройство
В соответствии с поставленными требованиями пишем прошивку на C++ и загружаем посредством Arduino IDE.
Определение скорости
Напомню, мы установили на перо велосипеда сенсор от китайского велокомпьютера.
На спице заднего колеса установлен крошечный магнит, который при вращении колеса замыкает ключ в момент прохождения мимо пера. Используя этот факт, мы можем считать время между замыканием/размыканием ключа.
Курс физики за 5й класс советует добыть еще пройденный путь, для определения скорости. На любой покрышке, обычно, расположена маркировка с ее диаметром. Диаметр превращаем в длину окружности, что и будет являться пройденным путем за один оборот колеса.
Определение скорости по обороту колеса.
При имплементации решения нужно учесть несколько подводных камней:
Дребезг. При прохождении магнита мимо геркона может возникнуть дребезг — несколько переключений ключа за один оборот. Это исправляется добавлением некого минимального лимита между оборотами. Лимит можно прикинуть определив максимально возможную для определения скорость minDt = L / Vmax
Прерывания. Поскольку нам надо ловить кратковременные изменения сигнала, то базовый ардуино-подход с опросом пина в главном цикле loop заставить работать будет невозможно, да и загрузит он плату впустую. Для подобных целей в Arduino есть прерывания. Подключаем наш сигнальный провод к пину, поддерживающему прерывания и в прошивке вешаем функцию-листенер на изменение сигнала. Таким образом, при замыкании ключа в нашем герконе, произойдет изменение сигнала. Оно, в свою очередь, вызовет прерывание, в котором обработчик фиксирует моментальную скорость.
Определение ускорения
Акселерометр позволяет снимать показания ускорения по трем осям (будем использовать только одну).
Для работы с использованным модулем существует готовая библиотека. Используемый экземпляр имеет возможность программной установки конфигурации — здесь устанавливаем максимальный диапазон ±16g и частоту обновления данных в соответствии с технической возможностью читать и отправлять их со стороны Arduino.
Первоначальная идея, читать моментальные значения ускорения и передавать их по Bluetooth, провалилась из-за ограничения пропускной способности канала. А данные, к слову, нужно отправлять часто, поскольку пики ускорения при езде происходят каждые ~10-40ms.
Поэтому, после изучения формы графика ускорения, было принято решение предобрабатывать данные на Arduino и собирать только те, которые как-то могут повлиять на результирующую оценку качества покрытия.
Вместо сбора всех значений, отправляем только значения экстремумов, что позволяет разгрузить канал передачи данных, увеличить частоту опроса акселерометра и повысить качество трекинга ускорения. Вероятность упустить пик стала намного меньше.
Отправка данных
Данные собраны, данные надо отправить. На первый взгляд ничего сложного — используя встроенную библиотеку SoftwareSerial для работы с последовательными портами, отправляем данные и наблюдаем их в тестовом Bluetooth-терминале на мобильном устройстве. Однако на практике пришлось походить по граблям.
Первый момент возник со скоростью. Я, как непуганый веб-девелопер, в первом прототипе передавал по bluetooth данные, обернутые в JSON, содержащие длинные float-числа, кучу ненужных данных про запас. Тогда я и подумать не мог про то, что лимит скорости моего Bluetooth модуля настолько осязаем.
После профайлинга с осознанием, что отправка моих пакетов данных занимает слишком много времени, были предприняты некоторые шаги.
Скорость. Сперва была увеличена скорость самого HC-06 модуля, который по умолчанию работал на 9600 baud. Для изменения таких настроек как скорость устройства, имя, пароль используются AT-команды. Во время попыток конфигурации оказалось, что одни и те же платы могут иметь разные прошивки, поддерживающие разные форматы. Успешно поменять скорость моего Bluetooth модуля, который отказывался подчиняться любым мануалам, было настоящим праздником.
Сжатие данных. Следующим шагом была оптимизация пакета с данными. Был выброшен JSON, выброшены лишние данные, сокращены ключи, округлены числа с плавающей точкой.
После этих манипуляций девайс стал заметно быстрее. Синхронная отправка данных уже не ставит под угрозу периодичность опроса акселерометра.
Скриншот тестового Bluetooth-терминала c поступающими данными. Формат пакета данных.
Пакет данных, отправляемых по Bluetooth содержит время, пиковое значение ускорения, текущую скорость. Отправка данных происходит при прохождении пика, либо по таймауту (если девайс статичен и колебаний нет).
Время
Время понадобится для привязки собираемых данных к местоположению (а в последующем к конкретным сегментам дорожного полотна), причем время, полученное при определении местоположения на мобильном устройстве и время на сенсоре должно быть синхронизировано.
В Arduino имеется встроенная функция для определения времени в миллисекундах, прошедшего от момента запуска устройства. Можем реализовать механизм синхронизации времени на плате с временем на мобильном девайсе через Bluetooth команды. Синхронизацию будем выполнять алгоритмом Кристиана
Алгоритм Кристиана для синхронизации времени.
В идеальном мире с единорожками данную операцию синхронизации понадобится сделать только в начале сеанса обмена данными между устройствами. Однако, на практике оказалось, что время, выдаваемое функцией millis
, не совсем то, чем кажется. На самом деле значения этих часов не точны на длинном промежутке и в моем случае вечно убегали вперед на ~3%
. За минуту отставание в секунды довольно критично для задачи привязки данных к местоположению. Для устранения дрейфа часов процесс синхронизации выполняется периодически, раз в несколько секунд.
Итоги
В результате разработки устройства сбора данных у нас в наличии велосипед с установленными блоками сенсоров и микроконтроллера, который выдает через Bluetooth данные о пиках ускорения, моментальной скорости, текущем времени. Уже сейчас мы можем подключиться любым Bluetooth-терминалом к устройству и наблюдать все пролетающие данные, крутя педали.
Сбор данных. Мобильное приложение.
Требования к приложению.
Мобильное приложение имеет четыре кейса использования.
- сбор данных о местоположении устройства
- принятие данных сенсоров по Bluetooth
- отображение данных в live-режиме
- сохранение данных на носитель для последующего анализа
Схема архитектуры мобильного приложения.
Реализация
Приложение имплементировано для платформы Android с использованием языка Kotlin. Имеет простой интерфейс с одним экраном, на котором отображаются текущие данные с сенсоров и располагается кнопка управления процессом записи данных на носитель.
Скриншот мобильного приложения.
Для формата данных был выбран CSV. Файлы собираемых профилей с данными записываются в директорию приложения, откуда мы сможем их забрать руками. Поскольку эта процедура почти одноразовая, то здесь было решено не усложнять.
В общем мобильное приложение — одна с самых неинтересных частей этого проекта (что видно по объему написанного).
Обработка данных
В результате этапа сбора данных у нас имеется набор csv файлов с данными. Задача этапа обработки — превратить собранную информацию в некие числовые характеристики качества покрытия, сопоставленные с сегментом дороги.
Требования к обработке оказались плотно связаны с тем, как мы собираемся рисовать результирующие данные. Поэтому немного отвлечемся на поиск решения для отображения.
Поиск решения для отрисовки
Процессом монотонного гугления первоначально был обнаружен плагин Leaflet.hotline.
Подопытный позволяет рисовать вполне неплохие разноцветные треки. Для функционирования требует координат трека и числовых характеристик, на основании которых будет определен цвет из настраиваемого диапазона.
Пример трека, нарисованного посредством Leaflet.hotline.
Основной минус этого решения — клиентская отрисовка. Все треки с данными пришлось бы загружать в браузер пользователя. И уже там строить нашу карту.
Этот вариант хорошо подходит для отдельных треков. В принципе, можно было бы и обойтись данной библиотекой. Тогда осталось бы только поставить в соответствие каждой координате из собранных треков числовую характеристику качества покрытия и мы получили бы карту покатушек.
Однако, остается вопрос — что делать если один и тот же сегмент был пройден в разных треках или вообще разными пользователями. Здесь простая отрисовка трека не поможет, нужно иметь некую базу данных, где представлены участки дороги, которым приведены в соответствие наборы собранных данных (могут быть собраны в разное время разными пользователями). Используя такие наборы данных, можно будет агрегировать данные разных треков и получать финальную оценку качества отрезка дороги.
Учитывая минусы первого варианта с клиентской библиотекой, определяемся, что хочется иметь что-то серверное, что отрисовало бы заранее граф дорог в соответствии с собранными данными. Отрисованные фрагменты осталось бы только отобразить в клиентском браузере.
Существует целый пласт систем, задача которых — рендеринг карт. Один из популярных рендереров Mapnik — может рисовать карты, используя геометрические объекты, хранящиеся в разных источниках, в том числе в PostgreSQL.
Таким образом мы сможем зарендерить наборы тайлов (map tiles), представляющих собой дополнительный слой для карты.
Слияние тайлов базового слоя и слоя данных карты.
Отобразить это все можно используя библиотеку Leflet поверх любой базовой карты в браузере.
Подготовка
Приступаем к проектированию структуры базы данных, которая будет использована для сохранения обработанных данных треков и для отрисовки финальной карты в последующем.
Определяем сущности:
- Segment. Представляет часть дорожного полотна. Все сегменты могут быть подсегментом более длинного сегмента (это нам пригодится для отрисовки карты в разных размерах)
- Profile. Представляет отдельный записанный трек с данными. Пригодится для возможности отрисовки слоев на основе данных из разных профилей.
- Layer. Представляет слой для отрисовки.
И связи:
- Profile Segment Quality. Будем использовать для сохранения оценки качества определенного сегмента, затреканного в определенном профиле.
- Layer Segment Quality. Сюда будут агрегированы данные качества сегмента из разных профилей. Таким образом разные оценки качества из разных профилей превратятся в финальное значение для отрисовки путем агрегации по некоему алгоритму. Эти данные в последующем будут использованы для финальной отрисовки карты.
Диаграмма схемы базы данных.
Импорт сегментов
Для последующей реализации алгоритма обработки треков нам понадобится заполнить созданную таблицу сегментами.
- Скачиваем OSM данные для Беларуси в формате *.pbf например отсюда
- Для ускорения обработки отрезаем от этих данных Минск, используя osmosis
- Поднимаем PostgreSQL c расширением PostGIS (позволяет работать с гео-данными). Я использовал AWS EC2 c готовым имеджем.
- Импортируем полученный .pbf файл для Минска в новую базу данных с использованием osm2pgsql
После выполнения этих шагов у нас есть база данных со всем дорогами, зданиями, и другими гео-объектами Минска.
Из всего этого нам пригодятся только дороги.
Была написана небольшая консольная команда, которая извлекает из OSM базы данных дороги, разбивает их в дерево по расстоянию, согласно настройкам.
Например, я использовал 2 уровня — 5 и 50 метров. Это значит, что любой отрезок дороги из OSM будет первоначально разбит на участки не длиннее 50 метров, дальше каждый из них будет разбит на участки не длиннее 5 метров.
Разбиение на сегменты отрезка дороги.
Уже терминальные сегменты (в моем случае не длиннее 5 метров) будут на этапе обработки треков сопоставлены с качеством покрытия. Качество покрытия нетерминальных сегментов (в моем случае по 50 метров) будет получено путем агрегация качества подсегментов.
Запускаем команду, идем за чаем, все 90000+ дорог из OSM попали в таблицу segment и превратились в миллионы записей.
Алгоритм
Подготовка завершена: готова БД, сегменты ждут своей участи.
Опишем основные этапы алгоритма обработки сырых треков.
- Матчинг трека
- Матчинг сегментов
- Матчинг данных сенсоров на сегмент
- Определение качества сегмента
Матчинг трека
На входе мы имеем последовательность координат, которая далека от реальности из-за погрешностей GPS трекинга. Чтобы корректно определить сегменты на следующих этапах, мы должны привязать сырой трек к реальной дорожной сети.
Эта проблема не нова и называется Map matching
Матчинг трека на дорожную сеть.
Один из вариантов решения этой задачи — использование сервисов из проекта OSRM (Open Source Routing Machine).
OSRM предоставляет набор сервисов и REST API к ним. Как это все развернуть описано например здесь.
Нам понадобится сервис Match service. Он принимает на вход последовательность координат и, что важно, точность для каждой координаты. Точность можно получить на этапе сбора данных с мобильного устройства. Результат определения позиции в Android API содержит точность в том числе.
На выходе получаем первоначальный трек, но уже с координатами, привязанными к дорожному полотну. Как результат — мы уже не ездим через реки и не пересекаем заборы или дома.
Матчинг сегментов
На входе у нас есть красивый трек, проложенный по улицам города. По этому треку надо получить список сегментов, которые трек затронул. Напомню, что сегменты у нас достаточно маленькие, не более 5 метров (используются только терминальные).
Здесь первый раз порадуемся тому, что имеем дело с пространственной базой данных, способной работать с геометрическими данными. Для определения списка затронутых сегментов достаточно одного запроса.
Алгоритм запроса следующий:
- Преобразуем трек в GeoJSON линию, которую способен обработать PostGIS
- Используя функцию buffer расширяем нашу линию во все стороны и получаем полигон. Данная операция нужна, чтобы сгладить отклонения в пределах погрешности.
- Ищем все сегменты, которые находятся внутри полученного полигона.
На выходе — список сегментов, пройденных в треке.
Матчинг данных сенсоров на сегмент
На входе:
- список сегментов
- трек, представляющий набор координат со временем их прохождения
- набор данных, в котором каждому элементу соответствует время
Задача — каждому сегменту поставить в соотвествие набор данных с сенсоров.
Пройдемся по каждому сегменту, используя алгоритм:
- Буферизируем сегмент (уже не трек, как в предыдущем этапе) до полигона
- Разобъем трек на части, используя сегмент-полигон
- Возьмем все части трека, которые оказались внутри сегмента
- Определим интервал времени, в который был пройден сегмент
- По интервалу времени найдем все данные сенсоров
На выходе — список сегментов, каждому из которых сопоставлен набор данных с сенсоров.
Определение качества сегмента
На входе:
- список сегментов и данные сенсоров, соответствующие каждому
Задача данного этапа — по набору данных дать числовую оценку качеству отрезка дороги.
Очевидно, что на одном и том же участке дороги можно получить разные значения акселерометра в зависимости, хотя бы, от скорости движения.
В идеальном мире хотелось бы получить некую функцию, которая давала бы одно и то же значение качества для одного и того же участка дороги, пройденного на разных скоростях.
Тогда мы могли бы быть уверены в корректном сравнении качества разных участков дорог между собой визуально на карте.
Однако задача эта не такая уж и тривиальная, существуют десятки научных работ, в которых она решается.
Поэтому оставим данную задачу на потом из-за риска так и бросить все на полпути из-за такой мелочи.
Придумаем что-нибудь простое и более или менее правдоподобное. Диапазон значений акселерометра у нас -160 — +160.
Пусть значение качества дороги будет определяться по следующей формуле q = (Amax - Amin) / 320
.
Для удобства будем использовать целочисленные значения от 0 до 5, где
- 0 — минимальное качество (интервал содержит перепады ускорения до 320)
- 5 — максимальное качество (интервал содержит перепады ускорения до 64)
Применяем функцию качества к данным всех сегментов и на выходе получаем список сегментов с качеством.
Агрегация сегментов
На предыдущих этапах мы получили набор терминальных сегментов с числовыми характеристиками, соответствующими качеству дороги.
Перед отрисовкой нужно провести агрегацию данных, у которой две разные цели:
- получение общего значения качества одних и тех же сегментов, полученных разными затреканными профилями (разное время, разные пользователи)
- получение значения качества сегментов, состоящих из подсегментов (для отрисовки карт с разной детализацией)
Пишем небольшую консольную команду, которая будет создавать новый слой и заполнять его данными.
Для заполнения данными на наших небольших объемах обойдемся sql командами группировки и вставки.
Подсчет качества терминального сегмента по значениям, полученным в разных профилях, выполним используя медиану. Применяем соответствующую функцию PostgreSQL PERCENTILE_DISC
, используя значение перцентиля 0.5
получаем медианное значение качества дороги.
Когда значения качества терминальных сегментов готовы можем агрегировать их для получения значений качества родительских сегментов. Здесь нам тоже пригодится перцентиль, но уже с другим значением. Для его определения был задан вопрос — какая часть дороги должна быть в хорошем состоянии, чтобы принять решение о хорошем состоянии всей дороги. Методом математически выверенного тыка было определено значение перцентиля в 0.7
. Не спрашивайте почему, это значение, когда карта получается и уже не красная и еще не зеленая.
Как итог этапа агрегации, мы имеем таблицу с данными о сегментах, данные о которых представлены в профилях. Можно рисовать!
Отрисовка
Генерация тайлов
Напомню, в рамках подготовки к обработке данных мы выбрали серверный рендеринг тайлов и Mapnik как opensource вариант для этого.
Для генерации тайлов Mapnik использует файл конфигурации, в котором содержится информация об источнике гео-данных и о стилях, применяемых при отрисовке.
Источником данных у нас является PostgreSQL, о чем и сообщаем через конфигурацию. Далее нужно указать из какой таблицы взять геометрические данные и их атрибуты. Здесь можно указать не просто название таблицы, а целый SQL-запрос, поскольку нам требуется к таблице с агрегированным качеством присоединить таблицу с геометрией сегментов.
Данные есть, нужно указать как их отрисовывать. Для этого создаем стиль с пятью правилами (Rules) (по одному на каждый уровень качества). Таким образом Mapnik раскрасит сегменты разными цветами в соответствии со значениями атрибута quality, который будет извлечен в указанном SQL-запросе.
<Style name="default">
<Rule>
<Filter>[quality] = 0</Filter>
<LineSymbolizer stroke="rgb(255, 0, 0)" stroke-width="1"/>
</Rule>
<Rule>
<Filter>[quality] = 1</Filter>
<LineSymbolizer stroke="rgb(255, 128, 0)" stroke-width="1"/>
</Rule>
</Style>
Здесь еще замечу, что для разных уровней приближения будем использовать разные SQL-запросы (с разными длинами сегментов) и разные стили, для чего создадим небольшую обертку на python.
Запускаем генерацию, получаем набор тайлов, сложенных в директории, согласно их позиции и уровню детализации.
Просмотр карты
Пока у нас в распоряжении просто квадратные картинки, давайте поместим их как слой поверх карты.
Возьмем уже анонсированную выше библиотеку Leaflet с удобным API. Для создания просмотрщика нам понадобятся два слоя:
- слой базовой карты
- слой карты качества дорог
Базовый слой можно использовать какой угодно, я выбрал бесплатный из wiki.openstreetmap.org
Наш слой, сгенерированный с помощью Mapnik, нужно куда-то захостить, возьмем githubpages.
Пишем небольшой кусочек js, добавляем слои, деплоим — готово. Пока результат вам не покажу, так как он будет результатом всего проекта, потерпите один абзац.
Катать!
Все эти несколько месяцев с мыслями о завершении проекта я наивно полагал, что завершающий этап катания по городу с устройством на борту будет самым веселым и простым. Однако я недооценил его сложность :/ Все-таки проехать на выходных 100+км за городом на природе это намного веселее и жизнеутверждающе, чем накручивать круги по городу с автомобильными запахами и не лучшей инфраструктурой, да еще и по далеко не самой оптимальной траектории.
Первоначально была мысль проехать город целиком, внутри МКАД. По всем улицам конечно не поедем, только по основным, на которых есть хотя бы тротуары (в Беларуси можно ездить только по тротуарам, если они есть, их-то мы и инспектируем). Задача немного усложняется тем фактом, что в отличие от Яндекс и Гугл — автомобилей, снимающих панорамы города, нам нужно ездить по одной улице как минимум дважды, так как тротуара обычно два, состояние их бывает очень разным.
Мысль конечно потерпела крах после пары выездов, стало понятно, что весь город будет сложновато, поэтому было решено ограничиться частью Минска внутри второго кольца.
Схема запланированного и исследованного участков.
Для того, чтобы ничего не пропустить, я планировал маршруты заранее, составляя треки и закачивая их в maps.me. Кстати, вы знали, что у Android устройств можно сплитать экран и использовать два приложения одновременно? В моем случае это оказалось весьма удобно — на одной части был запущен навигатор, на другом — наше мобильное приложение с мониторингом состояния трекинга.
Транспорт готов к старту.
Обкатать все запланированное получилось за примерно неделю активного катания — все выходные по ~70км, почти каждый будний день с двумя выездами: утром, до работы, около 20км и вечером, после работы, около 30км. Всего чистых затреканных километров получилось около 445км. За это время увидел кучу интересных мест, в которых, кажется, бы и не побывал никогда, хотя объездил Минск на велике достаточно плотно.
Итоги
Нет времени объяснять — держите карту.
Карта качества покрытия тротуаров Минска.
Из карты можно сделать вывод о хорошем состоянии тротуаров и велополос на магистральных дорогах и заметно хуже качестве дорожек в спальных микрорайонах. Тут нужно учесть, что большинство новых спальных микрорайонов остались извне исследованного участка Минска, там ситуация немного будет иная, так как много домов сдаются с уже готовой какой-никакой велоинфраструктурой.
Медитируя над результатом, обратите внимание на закономерности появления красных сегментов на карте, обычно они связаны с пересечением дорог на одном уровне. Наши любимые бордюры. Это, конечно, не обязательно они, но часто примыкание тротуара к дороге сопровождается значительным перепадом высоты, которое и дает "потрясение" при проезде на скорости выше пешеходной.
Напоследок первоначальная схема проекта со всеми использоваными технологиями, инструментами и языками.
Код можно найти в репозитории. Держите в уме, что написан он человеком, который не имел опыта промышленной разработки ни на одном из языков и библиотек, использованных в проекте.
cepera_ang
Нужно делать готовый девайс и сервис для мониторинга вело-инфраструктуры — аггрегированные данные должны быть более полными и аккуратными.
Кстати, а почему не пользовать акселерометр и скорость по gps из самого смартфона?
isxam Автор
По использованию акселлерометра в смартфоне вопрос логичный и закономерный. Действительно, в готовых реализациях мониторинга его и используют, правда, возможно, с дополнительными шагами правильной устрановки и калибровки. Почему здесь был выбран заведомо сложнее варинт — две причины
1. Поскольку проект по фану, то главным интересом для меня здесь была железка, без ее существования заниматься всеми остальными 80% было бы не интересно. Можно считать, что она сюда насильно прикручена.
2. Изначально, для оправдания использования отдельного акселерометра, было задумано собирать еще и скорость с колеса (которая была собрана, но проигнорирована на этапе определения качества). Поэтому раз железка уже нужна, то и акселерометр туда же можно было добавить, для возможности например пользоваться смартфоном во время трекинга, без жесткой его фиксации.
Gourry_aka_pm
Ну еще минус — то, что смартфон (если он на владельце едет) дополнительно самортизирован.
k102
Можно на руль прикрепить — для этого уже куча готовых решений. А если взять какой-то старый и не сильно нужный — изолентой к раме)
isxam Автор
У меня так и закреплен, на такую
grayich
Не хватает корреляции данных с стравой, скорее всего они будут совпадать во многом.
isxam Автор
Вы имеете в виду www.strava.com/heatmap?
grayich
ага
ximik666
Делал что-то подобное, но для анализа качества воздуха. В коробочке акселерометр, плата для логов, точного времени, GPS, «показометр» качества воздуха. Потом все скидывалось в Influx/Grafana. Делал для себя, но потом забросил — качественные датчики стоят дорого.
isxam Автор
Круто! Да, общая часть значительная, только данные разные. А для чего использовался акселерометр в вашем случае?
ximik666
Была идея данные с видеорегистратора по времени связать с показаниями акселерометра, чтобы вытаскивать фотографии с ямами, а потом на основе этих фотографии обучать сети и как-то потом выйти на качество дороги.
k102
Тк паять я не умею, возникла идея попробовать добавить данные с акселерометра в gpx, который можно взять из велокомпа или похожего устройства.
isxam Автор
Как справедливо заметили в первом комментарии, здесь можно обойтись и одним смартфоном без пайки. Железное устройство здесь притянуто за уши, можно сказать от моих личных хотелок. Вроде даже есть приложения для работы с акселлерометром, которые могут писать в лог. Так что и кастомное мобильное приложение можно отбросить при желании.
vesper-bot
Насчет кофе-теста — если стакан достаточно тяжел, можно не расплескать кофе и на плохой дороге, за счет инерции самого стакана колебания кофе будут слабее.
drWhy
Стакан — твёрдое тело, относительно жёстко зафиксированное. Кофе — невязкая жидкость со своей инерцией. Если кофе в стакане больше половины, никакие силы не удержат его от расплёскивания при резких ускорениях.
Тест прекрасен, хочется иногда предложить его некоторым водителям автобуса, а иногда и метро. Как раз в метро очень хотелось наличия подобного приложения у большинства пассажиров, чтобы все косяки линии и наплевательское отношение водителя поступали сразу в диспетчерскую метро.
honechko
Было бы круто, если бы множество катальщиков собирало эти данные. Для этого действительно нужно упростить «железную» часть только до одного смартфона. Чтобы катальщики были заинтересованы во время катания запускать это приложение, нужно в него добавить каких-то полезных фишек, одна из них — сами результаты работы — карта качества дорог.
Я, как тоже катальщик на велосипеде, скажу, что большее раздражение вызывает не тряска, а необходимость прикладывать усилия, например езда по песку. Как такое измерить, даже не знаю, на ум приходит сопоставление пульса и скорости движения.
NLO
НЛО прилетело и опубликовало эту надпись здесь
drWhy
Песок, кстати, ещё не худший случай — он легко укатывается и на нём можно неплохо ездить на широкой приспущенной резине, ещё лучше на фатбайке. Жёваный асфальт, шебёнка, застывшие потёки от бетономешалок, выкрошенная тротуарная плитка, бордюры через каждый метр с ямами перед и за ними — это да, бывает нередко.
В городской черте песок именно на дорогах бывает обычно только после ремонта, например, канализации до укладки нового асфальта. А вот щебёнкой могут засыпать, а заасфальтировать через полгодика.
honechko
Песок это в качестве примера — его не засечет датчик вибрации (в отличие от щебенки), но он ухудшает качество дороги на уровне не меньше, чем щебенка.
С другой стороны, применение приложения можно и расширить — не только город, а и везде, где катаются велосипедисты.
Был случай, катался за городом и уже возвращался, можно было ехать по трассе, но по карте посмотрел и получалось, что срезать через лес было бы выгоднее. А через лес дорога была с песком, причем проходимость снижалась по нарастающей. Возвращаться тоже уже был не вариант — далеко и опять по песку. Вот для таких случаев приложение было бы идеальным помощником.
isxam Автор
Прям истории с моей maps.me навигацией :D Часто кажется, что там, где пробежала собака — уже тропинка, а там, где по полю проехал разок трактор — на карте это автобан
cepera_ang
Так там же сами пользователи рисуют, где проехали — там и дорога :)
isxam Автор
да, отсюда и плюсы/минусы как у любых краудсорсинговых проектов. Но я отдаю предпочтение в этом деле объему информации, которая есть на OSM, хоть и есть риск поиска брода
LQuatt
Подскажите, пожалуйста, где такой мост.
isxam Автор
держите Птичь в Осиповичском районе
LQuatt
Благодарю.
drWhy
Пульс поднимается не сразу, он интегрирует нагрузку. Для протяжённых участков можно использовать. Также зависит от других факторов — ветра, физподготовки, степени усталости, настроения и т.д. КМК нужен датчик натяжения цепи — можно снимать значения с отдельного небольшого натяжителя, значения скорости, каденса и уклона — его можно снимать с жёстко закреплённого акселерометра. Возможно, что-то окажется лишним.
Вопрос с картой качества дорог в её назначении — прокладка маршрута — понятно. Ремонт дорог — под вопросом, здесь нужны инициативная группа и выход на городские службы. А там бюджет, внесение в планы работ на предстоящий период, собственно ремонт, повторный контроль и т.д. Иногда складывается впечатление, что при наличии у служб актуальной информации об участках дороги, действительно нуждающихся в ремонте, асфальт перестанут закапывать из года в год на одних и тех же местах.
dabar347
Тензометрический датчик в педалях подойдет (используется для замера выходной мощности велосипедиста вполне активно)
drWhy
Деформацию какой детали покажет тензодатчик? Шатун и ось педали не подходят, их деформацией можно пренебречь. Можно было бы схимичить демпфирующую накладку на педаль и снимать с неё.
dabar347
Почему же не подходят если используют именно их www.cyclingweekly.com/group-tests/power-meters-everything-you-need-to-know-35563
anonymous
оч круто. можно еще авторассылку сделать с плохими местами дороги на сайт 115.бел. К слову, я часто гуляю с ребенком в коляске, покрытие тоже очень важно (привет, новая боровая!), в общем я кидал туда фотки и координаты, где были плохие пандусы на лестницах, в переходах метро, кидал фотки, где штыри торчат в земле, они достаточно быстро все исправляют. сайт хороший, молодцы
anonymous
вот пример. важно это им всё отправлять, так как они не физически не могут видеть все проблемы города
drWhy
На первом фото почти идеальный пандус. Перехожу ежедневно по швеллерам, на которые сначала нужно взобраться — ступень сантиметров 25, затем умудриться не зацепиться за швеллер. На выходе повторить.
Просто отсутствуют как класс отработанная технология и контроль, конкретные технические решения принимает на месте либо прораб, у которого в лучшем случае есть некоторый опыт и смекалка, в худшем — непосредственно Джумшут. В результате гнут бетонные бордюры, делают специальные уклоны на краю тротуара для удобного скольжения по льду под машину и другие дикости, и это никто не контролирует, а подрядчики ни за что не отвечают, переделывают за другие деньги другие джумшуты.
Нет системы. Нужно при приёмке заставлять прораба по готовому пандусу провезти на тачке пять мешков цемента. Если не помогло — подниматься по иерархии — повторить с руководителями подрядчика, контролирующего органа… И всё нормализуется.
А так да, отдельные обращения удовлетворяются.
isxam Автор
да, но оно больше подходит для «латания дыр», когда все уже сделано хорошо и правильно. А когда нужно переделывать например весь тротуар, менять организацию движения и тд., то исправление мелких «ям» выглядит как бессмысленная мышиная возня, оттягивающая время двух сторон от вопросов глобальнее. Поэтому отношусь осторожно к этому сервису, но для правильных целей он хорош, согласен
anonymous
чем больше сообщений что надо поменять весь тротуар, тем выше вероятность, что его поменяют)
isxam Автор
да, если речь про весь. Но часто это превращается в репорт про отдельную плиточку на тротуаре где каждая 5я плохая. А поскольку, я подозреваю, что у этих ребят тоже есть метрики, то получается они фиксят эти тикеты по отдельности, тратя намного больше сил и времени вместо того, чтобы подумать и заменить все целиком. Утрировано получилось, но, надеюсь, позицию получилось описать. Хорошо если у них есть какой-то мета-прораб, который в силах отследить тренды и не дать работягам фиксать то, что будут решать «фундаментально» объединив кучу заявок (предыдущих и будущих) и решив источник проблемы, а не симтом.
anonymous
с чего-то надо начинать. в наше дни популярными стали средства личной мобильности(электроколеса, элетросамокаты, и прочая колесная каталка), для них покрытие намного критичнее, чем для велосипедиста. А дальше их будет много больше. Вообще, по моим наблюдениям, надо пол Минска переделывать для этих целей. Но с чего-то надо начинать, но и нам грех жаловаться — велодорожки у нас огонь. То, что в своё время через весь центр сделали велодорожку, учитывая наш совок, для меня было нонсенсом!
Erop22
Пожалуй, это лучший курсач, который я видел! Причём сразу по нескольким предметам. А может даже и на дипломный проект тянет…
Но если
включить старого пердунабыть честным, давайте признаем, что практическая ценность этого проекта (в данной реализации) стремится к нулю. И вот почему:1. Лисапедист — не трамвай, он старается объезжать препятствия на дороге. То есть если дорога в целом убита вусмерть, но есть маленькая колея с приличным покрытием — мало кто «ради чистоты собираемых данных» будет систематически ездить по ямам (а ткнуть в условной программе на телефоне кнопку «дорога — хлам» — легко мог бы).
2. Возможна и обратная ситуация, когда дорога вполне себе норм, но локальные обстоятельства вынуждают велосипедиста выбирать «буераки» (например, при объезде группы пешеходов)
3. Само по себе понятие качества тротуаров — весьма относительно. Например, для лясика плитка — вполне себе годное покрытие, но для роллера (который по простоте душевной решит воспользоваться данной картой) — это верная смерть. Для «горника» или фэт-байка мелкие ямки тоже не проблема, но для шоссера — печаль грустная. Кстати, грунтовки тоже могут быть очень разными, но данный девайс в принципе никак не поможет оценить их качество.
4. У всех, конечно, разные навыки и стили катания, и это стоило бы учитывать. То есть карта для девчачьих покатушек «на расслабоне» и нормальной «вкатки» — это очень разные карты.
З.Ы. Когда я жил в Минске, я в среднем вкатывал по 50-70 км в день (пара-тройка часов быстрой езды). Хотя по правде, качество дорог — это последнее, о чём я думал (ибо на лясике все дороги проходимы). Искатаны были все дороги (и лесные тропинки) Цнянки/Зелёного Луга/Уручья, половина парков города, все проспекты, велодорожки и много «просто улиц». Я не про-райдер, но катаю быстро, могу кое-где «перепрыгнуть» препятствие, все типы покрытия (включая снег и гололёд) для меня были норм. Впрочем, чаще всего я принципиально нарушал действующее ПДД, катаясь по дорогам. Однажды даже был привлечён за это к ответственности, с присущей белорусским силовикам неадекватностью (ехал часа в два ночи по пустой освещённой дороге домой (по две широченных полосы в каждую сторону), и навстречу гайцы… Маякнули мне сигнализацией, дескать, вали на тротуар, паря. Но конкретно в тот момент между мной и тротуаром была зелёная зона, а я не люблю без надобности «давить» траву; решил доехать до съезда во двор и там уже (разумеется, временно) съехать на тротуар. ДПСники, видимо, посчитали это личным оскорблением (отказ от мгновенного и бесприкословного подчинения их намёкам), развернулись (через две сплошные и без включения спецсигналов) и, обогнав меня, остановились. И вместо того, чтобы спокойно запрыгнуть на тротуар и «умчать вдаль», я решил всё же пообщаться, объяснив свою позицию. В итоге, второй гаишник гулял вокруг нас где-то с полчаса, а достучаться до человека за ширмой винтика в системе мне так и не удалось (хотя порой казалось, что лёд почти сломлен). С тех пор законные требования гайцов остановиться не замечаю. Для тех водителей, кто
не поленился дочитать ипреисполнился праведным гневом «что за дятел на дороге, да ещё и кичится этим», поверьте, я исключительно корректный водитель (и на лясике, и на авто/мото). Моя скорость на лясике в среднем близка скорости общественного транспорта (хотя вечерние троллейбусы, конечно, любят поиграть в шашки), все правила ПДД (кроме запрета ездить по проезжей части) я выполняю, в случае спорной ситуации всегда принципиально уступаю водителям/пешеходам (как раз по причине «незаконности» своего движения по проезжей части). Но двигаться по тротуарам/велодорожкам чаще всего (при моём стиле езды) гораздо опаснее (для окружающих), поэтому и выбираю меньшее из доступных зол…з.з.з.ы ещё раз респект за проект! уверен, получили много удовольствия и знаний при разработке. Если (когда) вернусь в Минск, с удовольствием бы познакомился/покатался бы вместе. Удач! ;)
drWhy
Одно дело ткнуть во всю дорогу, на ремонт которой целиком деньги выделят никогда. Совсем другое попытаться создать техническую основу для сбора координат конкретных провалов. Скажем, на ЖД есть специальные вагоны-лаборатории, которые периодически цепляют к составам и логируют состояние перегонов с целью дать конкретные указания путейщикам для замены конкретных шпал или отсыпки щебня. Теоретически такую лабу можно представить для автодороги. А на тротуарах Вы хоть раз видели лабораторию, официальную? То-то же.
Снова ключевое слово — «инфраструктура», которая теоретически должна подразумевать замкнутую систему велодорожек. Если на велодорожке пешеход — вопрос уже к нему в соответствии с ПДД.
Слова не мальчика, но мужа. Автор статьи представил своё средство передвижения и техническое решение под него. Да, жёсткая прицепная тележка на двух небольших колёсах в этом смысле будет универсальнее. Критикуя — предлагайте.
Тут первоначально неверное решение запретить движение по дорогам в случае наличия тротуаров заложило хороший фундамент для последующих проблем, в т.ч. с легализацией моноколёс и прочих самокатов. Теоретически это может повлечь положительные изменения в сквозной проходимости тротуатов — по ним ведь и коляски с детьми возят, и тележки-чемоданы. Но практически такой вариант развития что-то сомнителен — больно дорого переделать все тротуары.
4. На вкус и цвет, конечно, но некоторые не гоняют, а передвигаются из пункта А в пункт Б, и тут чем меньше сюрпризов, тем лучше. Ведь удивительно было бы видеть, скажем, бордюры поперёк шоссе. А главное, есть же опыт стран с развитой велоинфраструктурой и оживлённым велотрафиком.
Erop22
Я не очень понял, как это соотносится с моим комментарием… ))
С велодорожками существенная проблема не только в том, что их надо сделать (и это стоит денег), но и в том, что нужна культура велодвижения, а её в Беларуси (и других постсоветских странах, насколько я могу судить) пока нет. То есть катаясь по велодорожке, вы на ней встретите и роллеров, и мамочек с колясками, и детские лясики и собак и просто пешеходов… И всех этих людей (и животных), конечно, легко понять — дорожка-то удобная, не только ж для
этих сумасшедших идиотоввелосипедистов она… Но как вы правильно подметили, должна быть только для них (причём не унылые пару метров ширины в обе стороны, а по паре метров в каждую, да вдоль проезжей части), а иначе она — просто тротуар. Я тоже думаю, что тут стоит равняться на пример датчан или голандцев — там действительно созданы условия для велосипедистов — и народ действительно катает… Но у нас пока законодателям глубоко безразличны интересы масс, думали больше об откатах пожирнее… С надеждойждёмдвижемся к переменам…Касательно ремонтов… Эээ… С чего бы нормальную дорогу ремонтировать? Но имхо, тут (в топике) речь немного не о том была (потому что для ремонта дорог уже есть шикарный проект, но только для России пока). Вот вам, кстати, и встречное предложение (запилить подобный проект/сайт для других стран)… Но критики моей как таковой нет, потому что какая может быть критика DIY? Человек реально нормально заморочился, довольно глубоко погрузился в тему. Не думаю, что он всерьёз думает «взлететь» на этом проекте, скорее всё «по фану» делалось… Собственно: Как я это понял, идея была в том, чтобы (после составления внесения данных в автоматическом режиме) открыл карту и увидел, где лучше проехать. Но в такой реализации это очень недостоверно будет.
Касательно автоматического распознавания качества дорог. ИМХО, тут только системы CV помогут. Ну либо какие-нибудь хитрые эхолоты/лазеры… Ну или городить что-то малоадекватное (для XXI века) типа тележки со множеством колёс в ряд и датчиком на каждом…
Конкретно в Минске в основном тротуары широкие (наследие советских архитекторов, спасибо им за это). И страндартная практика «дорожников» — это просто нарисовать полосы для велосипедистов. Но это не решает проблему, а усугубляет её. На хорошей ровной дороге я вкатываю в среднем 30км/ч. Массы во мне 85 кг. Коэффициенты сцепления и площадь пятна контакта не знаю, но метров 5-8 мне надо точно, чтобы остановиться (и это на сухом асфальте)… Но пешеход, идущий «по ту сторону линии», меня не слышит и не видит, физически ему зайти на велодорожку ничего не мешает, результат бывает предсказуемо печален для всех… Ровно по этой причине я и езжу по проезжей части, там ко «встрече» со мной участники ДД более готовы…
drWhy
isxam Автор
1. Не написал в статье, но мой метод исследования не предполагал каких-то отличий от повседневной езды. Ехал именно так как еду всегда — если на тротуаре тропинка с норм асфальтом, а по кругу ямы, то едем так как оптимально. То есть карта фактически показывает с какой минимальной болью(в то конкретное время) можно преодолеть дорогу, а не что нужно починить (что нужно починить это косвенно показывает конечно)
2. Все так, поэтому краудсорсинг решил бы проблему, механизм мержинга данных разных профилей/пользователей есть
3. Да, поэтому была идея получить некую унверсальную оценку качества. А каждое траспортное средство или наездник уже может выбрать дороги соответственно своим лимитам (весенний шоссер — q = 8-10, летний горожанин — q = 5-10, осенний мтбшник — q = 2-10) Получить такую оценку не так и просто, но идея такая была.
4. Та же идея, что и в 3м пункте
По поводу неадекватности наказания — привлекался не раз, но в этом плане минские по моим впечатлением намного адекватнее местечковых ГАИ (что кстати подтверждает ваш факт про просьбу съехать на тротуар, у меня тоже так было). Меня штрафовали за езду по дороге, но каждый раз в районных цетрах, когда я был навьючен велобаулом на пару дней путешествия и преодолевать бордюры никак не мог был. Один раз даже оштрафовали за выездом из мелкого города, потому что оказалось, что с другой стороны дороги (за встречкой) в низине есть тротуар загородный, который 20 метров, а мне после этого по дороге все равно ехать с автомобилями десятки километров. (обозначен был разноцветно и заметно) Что самое забавное — штрафовал меня начальник ГАИ лично этого города. После этого мои представления о справедливости немного пошатнулись :D
Erop22
На мой очень субъективный взгляд, ценность проекта, в достоверности данных которого необходимо сомневаться, достаточно невысока… А при таком раскладе достоверность очень невысока. Надеюсь, вы понимаете, что я не критикую ваш проект, как по мне, для «фанового» проекта вы зашли даже дальше, чем стоило бы )) Но если говорить про потребительскую ценность «карт качества дорог для велосипедистов», то надстройка над OSM с возможностью оценки этого самого качества была бы куда более достоверна (хотя и требовала бы ручного/полуавтоматического по данным телефона внесения информации).
4. У меня именно на веле не очень большой опыт по Беларуси, может, пару тысяч всего… Но как-то с райцентральными гайцами не сталкивался (один раз хотели было привлечь за «без фликера» (стопил куда-то ночью), но были корректно посланы). Впрочем, я давно не был в родных краях, вполне допускаю, что сейчас «местячковые» стали злее… Ну и да, те столичные не просили меня съезать на тротуар, это я так расценил их сигнализацию (они не сразу ко мне кинулись, а сначала коротко маякнули; а потом (вероятно посчитав, что я их проигнорировал), через пару секунд, поехали за мной)…
Но да, в целом в той системе ничтожно мало адекватных людей. Система дрессировала их не предупреждать нарушения, а карать (причём невсегда даже за что-то, просто по факту нашего существования)…
isxam Автор
Да, я конечно это все понимаю. Про ценность при создании всего этого я больше думал для обучения, в первую очередь себя, иллюзий про реальную применимость этого вот всего не было :) Кстати, в осм точно есть атрибуты типа покрытия, возможно и качество там в каком-то виде присутствует
egor
Очень круто, я думал про что-то похожее но для скейта или в крайнем случае самоката — колёса меньше, проехать сложнее, на скейте так много где вообще невозможно где велосипед проедет.
Ну и в том решении, про котрое мы думали и GPS был на плате, подключать к телефону или компу нужно было бы только уже дома.
Но мы только думали, а тут и сделали и проехали весь город.
isxam Автор
Думал, что было бы круто, чтобы шеринговые электросамокаты собирали эти данные, такой объем данных нескончаемый был бы. Тем более у них все есть уже нужное на борту, кроме разве что акселерометра, хотя и он возможно в наличии
egor
Осталось определить где и в каком виде хранить результаты и написать в службы шеринговых самокатов )
isxam Автор
больше как мысль для идеального мира с розовыми единорогами :)
NetNazgul
Очень интересный материал! Если вы ещё не слышали о Минском Велосипедном Обществе, то обязательно свяжитесь [и вступайте], наверняка наработки пригодятся.
bubal93
Очень крутая и подробная статья, спасибо! Как раз работаю над чем-то подобным, только с использованием существующих велокомпьютеров.
Можно поинтересоваться, исследовали ли вы этот вопрос подробнее?
Может проводили тесты с креплением на каретку/вилку/вынос и другие места?
isxam Автор
Подробные тесты не проводил, больше на основе предположений о физике этого явления. Первая установка у меня была на багажник, но, из-за вибраций в соединениях, кронштейн оторвал кусок багажника. Кроме того акселерометр ловил много шума во всех плоскостях, хотя должен был преимущественно по вертикали. Думаю, что проще всего действительно провести тест с синей изолентой и смартфоном)
bubal93
Неужели при закреплении на дропаутах у вас нет горизонтальных шумов?
Тут наверное стоит уточнить материал рамы — судя по фото, у вас это аллюминий.
Сталь, титан и карбон любят по разному изгибаться, хотя на дропаутах этот эффект наверняка будет малозаметен.
P.S. извиняюсь, промахнулся веткой.
isxam Автор
на дропауте они есть, но на багажнике они были одного порядка с данными. Но здесь не очень релевантный пример, думаю основная проблема была в конструкции кронштейна и креплении багажника. Получалось так, что сам багажник вибрирует, вибрирует его часть, к которой крепился кронштейн, вибрирует кронштейн, а уже на нем акселерометр. Все это входит в резонанс и потом получилось как на фотке выше)