UARoads — стартап по оценке качества дорог Украины

Структура

Проект «Дороги Украины» состоит из:

• основного сайта, на котором отображается карта (front-end);
• системы обработки треков (back-end);
• инструментов для анализа (data science);
• сервиса для рендеринга карт (tile server);
• сервиса для прокладывания оптимального маршрута (OSRM);

Также проект можно условно разделить на 2 части: навигацию и отображение состояния дорог на карте. Разумеется, все начинается со сбора данных.

Сбор данных

В основе работы «Дорог Украины» был заложен принцип фиксирования сотрясений с помощью мобильных устройств и их привязка к GPS-координатам. Сбор данных осуществляется автоматически с помощью мобильного приложения для Android, iOS или Windows Phone. Android и iOS-версия делались в студии, а за разработку под Windows Phone взялись волонтеры из числа пользователей. Водитель устанавливает приложение на свое мобильное устройство и ездит как обычно. В это время приложение автоматически фиксирует сотрясения, сохраняет данные с акселерометра и GPS-координаты в трек, а также самостоятельно включается и выключается. При подключении к сети передачи данных или Wi-Fi данные передаются на сервер.

Сбор данных начинается с момента, когда приложение распознает движения автомобиля, основываясь на данных акселерометра. Все данные, которые передаются на сервер, обезличены, то есть не содержат никакой информации о пользователе или его автомобиле.

Рендерингом карт занимается тайловый сервер:

• При запросе тайла — сервер проверяет его наличие в своем кэше, если тайл найден — он возвращается клиенту;
• Если тайл не найден, то осуществляется его рендеринг, после чего он сохраняется в кэше и только после этого возвращается клиенту.

Дизайн мобильного приложения

Пользователю предлагается создать учетную запись, если он хочет иметь возможность просматривать свою статистику на сайте и принимать участие в рейтинге пользователей.

Разработка мобильного приложения

Проект «Дороги Украины» отличался от всего того, что мы делали ранее. Полного описания бизнес-процессов, алгоритмов и принципов работы приложения попросту не было. Поэтому перед командой разработчиков была поставлена задача разработать экспериментальный прототип приложения, которое будет собирать сырые данные со всех возможных датчиков, хранить в удобном для дальнейшего анализа виде и отображать в режиме реального времени. Данное приложение должно было помочь команде подтвердить гипотезу на практике, помочь найти закономерности в потоках данных и уже на их основании ввести алгоритмы, которые решили бы проблему анализа состояния дорожного покрытия.

Был создан инструмент, с которым разработчики и команда математиков проводили полевые испытания. Он состоял из двух приложений:

• Клиента, который устанавливался на все девайсы, участвующие в эксперименте;
• Сервера, которым являлось приложение, инсталлированное на планшет.

Серверное приложение создавало сеть Wi-Fi, к которой подключались все клиенты, передавая данные во время эксперимента в режиме реального времени. Первоначальные приложения были очень простыми с минимальным количеством опций:

Формат экспериментов

Экспериментальное тестирование проводилось в соответствии со всеми научными канонами. Изначально был выбран эталонный отрезок дороги, на котором и проводились все эксперименты. На данном участке присутствовали все типи дефектов дорожного покрытия (ямы, трещины, выбоины, наплыви и колии), все было измерено вдоль и поперек рулеткой и линейкой, записано и схематизировано для дальнейшего использования при анализе результатов.

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

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

Результатом работы команды на данном этапе было приложение, способное корректно собирать нужные нам данные и передавать их на сервер.

Итоги экспериментов

Эксперименты дали нам четкое понимание физики движения автомобиля, вибраций, которые возникают при проезде разных типов дефектов на дороге, силы ударов и влияния скорости на конечные показатели.

Но данные собранные во время экспериментов помогли решить только часть проблемы, а именно проблему сбора данных пользователями. Вторую же часть — анализ и классификация состояния дорог на карте, которую пользователи сейчас видят на сайте — только предстояло решить. Для этого нам нужно было куда больше треков, чем нам могли предоставить эксперименты. Было решено выпускать пользовательскую версию приложения раньше сайта с целью сбора нового массива данных, необходимого для дальнейшего развития проекта.

Разработка пользовательской версии

Основным мотивом при создании приложения было повышение безопасности на дорогах. Исходя из этого, при разработке стояла задача минимизировать все отвлекающие факторы, которые возникают во время использования приложения.

В основу пользовательской версии легла экспериментальная версия. Был разработан удобный UI и два алгоритма работы с приложением — ручной и автоматический. Работа автоматического режима зависит от многих факторов, одним из которых является мощность GPS-сигнала. Если сигнал плохой, пользователь может воспользоваться ручным режимом. Также пользователь может сам определить как отправлять треки, используя Wi-Fi или мобильную сеть, вручную либо автоматически отправлять все.

Разработка проводилась одновременно под две платформы, Android и iOS, с использованием нативного кода. Для связи с RestFull API сервера в Android изначально использовалась библиотека robospice, в процессе развития проекта она была заменена на связку Retrofit2.0 и OkHttp. В качестве локальной базы для хранения записанных треков был применен SQLite (в планах заменить на Realm). Минимальная поддерживаемая версия SDK — v9. Также приложение активно использует Google Play Services, потому важно, чтобы на девайсе пользователя была установлена их актуальная версия.

Таким образом, первая пользовательская версия приложения располагала только функционалом для сбора статистики. О роутинге с точки А в точку Б команда пока только мечтала, не говоря уже о навигаторе. Но все верили в успех проекта, в первую очередь благодаря комьюнити, которое проявляло огромный интерес к готовящемуся в релиз продукту.

Анализ данных

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

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

Первой задачей, которую предстояло решить, была привязка GPS-треков, записанных пользователями к существующим контурам дорог на карте. Так как точность электронных карт и датчиков, установленных на устройствах, не являются идеальными — просто соединить GPS-точки линиями и нанести поверх карты не выйдет. Если так сделать, то при достаточно большом увеличении получим что-то похожее на кардиограмму поверх дороги.

Поэтому все дороги на карте были поделены на сегменты по 30-50 м, а GPS-точки пользовательских треков, которые подходили сегменту по критерию отдаленности и направления движения, связывались с ним и записывались в базу для дальнейшего анализа. Таким образом, мы получили карту GPS-треков и базу с отсортированными точками вместе с данными акселерометра. Это упрощенное описание процесса, множество критериев и подводных камней опущено для простоты понимания алгоритма привязки треков на карту.

Второй задачей стал непосредственно анализ данных. Немного абстрагировав, его можно разделить на несколько этапов:

• Валидация. Так как данным, пришедшим от пользователя, доверять на все сто нельзя, сначала их нужно валидировать. Для этого используется простая математическая модель поведения автомобиля на дороге. Сравнив последовательность с критериями, которые диктует нам модель, алгоритм определяет является ли данный трек валидным и стоит ли пропускать его на следующий этап статистического анализа.
• Статистический анализ. В его ходе определяются места, в которых последовательности подчиняются определенным закономерностям, указывающим, что на данном отрезке дороги присутствует дефект. Оценивается вероятность правдивости выводов относительно данного отрезка дороги и силы сотрясения, которую зафиксировали датчики в этом месте. Таким образом, мы получаем яму на карте. Оценка всегда основывается на данных, которые имеют определенный период актуальности и достаточный объем для статистического анализа.

Таким образом, имея постоянный поток GPS-треков от пользователей и алгоритм, который в реальном времени валидирует поступающие треки и добавляет их к общей статистике, мы получаем «живую» карту дорог, т. е. основанную на данных в реальном времени. На протяжении полугода мы опробовали несколько подходов, прежде чем прийти к описанному выше адаптивному алгоритму.