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-треків від користувачів та алгоритм, який у реальному часі валідує треки, що надходять, і додає їх до загальної статистики, ми отримуємо «живу» карту доріг, тобто засновану на даних у реальному часі. Протягом півроку ми випробували кілька підходів, перш ніж прийти до описаного вище адаптивного алгоритму.