Попередній Наступний

UARoads — стартап з оцінки якості доріг України

Індустрія Логістика
Локація Україна
Розробка 2014 – 2018

Протягом багатьох років команда stfalcon.com працювала над розробкою веб-сервісу та додатків для проекту UARoads. У липні 2018 року ми передали його іншій команді, яка продовжила розвивати сервіс. Знайомтеся нижче з процесом розробки.

Задача

«Дороги України» — улюблене дітище нашої студії. Україна не може похвалитися високою якістю дорожнього покриття — 95% доріг країни перебувають у незадовільному стані (станом на 2013). Це збільшує ризик дорожньо-транспортних пригод, а також витрати автомобілістів на ремонт, тому 2013 року ми запустили соціальний стартап, орієнтований на автомобілістів.

Мета проекту — спільними зусиллями визначити найзручніші, найшвидші та найбезпечніші дороги з найменшою кількістю ям. Він допомагає:

  • Підвищити безпеку водіїв шляхом прокладання маршрутів дорогами з найкращим покриттям;
  • Захистити автомобіль від передчасного ремонту через ями та вибоїни;
  • Зменшити витрати з бюджету на моніторинг якості доріг;
  • Контролювати діяльність дорожніх служб та якість ремонту доріг;

Структура

Проект «Дороги України» складається з:

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

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

Збір даних

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

Збір даних починається з моменту, коли додаток розпізнає рухи автомобіля, ґрунтуючись на даних акселерометра. Всі дані, що передаються на сервер, знеособлені, тобто не містять жодної інформації про користувача або його автомобіль.

Роутинг і навігація

Для того, щоб прокладати оптимальний маршрут хорошими дорогами, ми використовуємо власний сервіс для роутингу (прокладання маршруту). З нуля розробляти додатки для цих цілей - це складне ресурсомістке завдання, але існують вже готові Open Source рішення. Ми вибрали OSRM, який легко налаштувати за допомогою скриптової мови LUA.

Для OSRM ми використовували власний конфігураційний профіль на .lua, який при побудові маршруту враховує не тільки довжину відрізка дороги (графа), а й тип відрізка, середню швидкість та стан дороги. База даних про стан дорожнього покриття оновлюється щодня. OSRM сервер працює за REST API. Клієнт надсилає запит з координатами початку та кінця маршруту, а сервер розраховує маршрут та віддає результат у вигляді JSON-об'єкта.

Карта стану доріг

«Дороги України» використовують картографічні рішення з відкритим вихідним кодом:

  • Карти OpenStreetMap (OSM) – для прокладання маршруту;
  • Інструментарій Mapnik — для рендерингу растрових карток з векторних даних;
  • JS-бібліотеку Leaflet – для відображення картки на мобільних та стаціонарних пристроях.

Тайли

Карта на сайті проекту складається з 2 основних шарів:

  • шар світу, який використовує тайл-сервер OSM;
  • шар зі станом доріг, який працює на власному тайл-сервері.

Щоб карту було зручно відображати, її зображення розбивається на тайли, які є квадратами 256 x 256 пікселів. Коли користувач відкриває картку в браузері, завантажуються тільки ті тайли, які видно на даний момент, що прискорює відображення та заощаджує трафік.

Шари накладаються один на одного і ми отримуємо карту зі станом доріг:

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

  • При запиті тайла – сервер перевіряє його наявність у своєму кеші, якщо тайл знайдено – він повертається клієнту;
  • Якщо тайл не знайдено, здійснюється його рендеринг, після чого він зберігається в кеші і тільки після цього повертається клієнту.

Дизайн мобільного додатку

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

Розрабка мобільного додатку

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

Було створено інструмент, з яким розробники та команда математиків проводили польові випробування. Він складався з двох додатків:

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

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

Нюанси

Що може вплинути на точність отриманих результатів? Відповідь проста – зовнішні чинники. Це можуть бути погодні умови, людський фактор, технічні моменти тощо. Математика наука точна, і можна нескінченно ускладнювати алгоритми, включаючи все більше і більше змінних умов завдання, які надає нам реальний світ.

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

Першим завданням, яке потрібно було вирішити, була прив'язка GPS-треків, записаних користувачами до існуючих контурів доріг на карті. Так як точність електронних карт і датчиків, встановлених на пристроях, не є ідеальними - просто з'єднати GPS точки лінії і нанести поверх карти не вийде. Якщо так зробити, то при досить великому збільшенні отримаємо щось схоже на кардіограму поверх дороги.

Закриваючи питання про рівень точності, який влаштовує умови завдань, поставлених перед сервісом, назвемо такі цифри:

  • похибка GPS мобільного пристрою: точність 5-40 м з ймовірністю 60% опинитися всередині діаметра цього кола.
  • 20% похибка у визначенні швидкості руху.

Крім несправних девайсів, у яких датчики з тих чи інших причин втратили свою точність і потребують додаткової калібрування, є момент з даними, які зрідка надходять від справних девайсів, але диктують аномальні показники. Вони успішно відсіваються алгоритмом, але у процесі вивчення проблеми ми виявили таке:

  • GPS не можна приймати за постійну величину: на рівень сигналу також впливає безліч факторів від місця розташування пристрою в автомобілі до броні, з якою цей автомобіль зроблено. Є також локації, в яких просто немає сигналу, причому в деяких не виявляється достатньо супутників для обчислення розташування, а в інших є супутники, але ОS так і не надає жодних оновлень про місцезнаходження. У будь-якому випадку в таких умовах усі додатки, які використовують GPS в цей момент поводяться однаково.
  • Так як дані з акселерометра не наводяться до будь-якої просторової осі, а аналізуються комплексно, ми отримуємо показник комфорту їзди по дорожньому покриттю, включаючи бічне прискорення в повороті, різкі прискорення та гальмування.

Останній фактор важко визначити як негативний чи позитивний. З одного боку, він говорить нам про те, що водій у конкретному місці зробив різкий маневр (можливо він ухилявся від дорожнього дефекту), а, з іншого боку, ми отримуємо такі ж дані від лихачів на світлофорах та різких поворотах. Команда працює у цьому напрямі та шукає корисне застосування цієї особливості.

Розробка навігатора

Ось уже сервер активно обробляє дані, які постійно надходять від користувачів, а обсяги надходжень становлять приблизно 1000 треків на день. Карта все доповнюється новими подробицями. Настав час використовувати зібрану статистику на благо тих самих користувачів, які її й збирали. Карта на сайті досить інформативний варіант, якщо ви водій з великим досвідом у побудові маршрутів та знаєте без навігатора як і куди дістатися. Якщо ж ваша стихія місто, а вам потрібно поїхати кудись далі, ви потрапляєте у світ ям та вибоїн, тому зручніше, звичайно, якщо вас проведуть за маршрутом, який мінімізує зустріч із цими перешкодами. Так спочатку планувалася розробка саме навігатора, команда з нетерпінням чекала на можливість реалізувати цю функцію.

На етапі розробки навігатора було вирішено залучити сторонніх розробників із досвідом роботи у цій сфері. Це допомогло заощадити час та уникнути проблем, пов'язаних із нюансами написання навігаторів. На допомогу нам прийшли хлопці з Дніпра, за що їм окреме спасибі!

«Навіщо ж писати свій навігатор, якщо є безліч готових та популярних рішень, таких як Google?» — спитайте ви. Виявляється, не все так просто. Для того, щоб провести користувача максимально безпечним і зручним маршрутом, нам потрібно вказати всі проміжні точки між пунктами відбуття та прибуття. На жаль, жоден з великих популярних навігаторів не здатний таке робити, йому важливо лише звідки і куди ви хочете потрапити.

Іноді більш просунуті рішення пропонують обмежену кількість проміжних пунктів, яку можна порахувати на пальцях, що не влаштовує умову поставленого завдання. Ми зв'язалися з розробниками найпопулярніших продуктів з питання інтеграції з їх додатками, дехто зацікавився, але переговори зазвичай справа не швидка, а навігатор нам потрібен вже. Тому, не виключаючи можливості співпраці, ми створили власне рішення.

Ми точно знаємо, що тема якості українських доріг близька кожному автомобілісту. На липень 2018 року сервіс «Дороги України» отримав понад 1200 треків від користувачів. Таким чином було вже опрацьовано 54% українських доріг.

Над проєктом працювали:

  • Степан Танасійчук
    Степан Танасійчук

    CEO і засновник

  • Ігор Федун
    Ігор Федун

    Менеджер

  • Діма
    Діма

    Менеджер

  • Yulia Kondratyuk
    Yulia Kondratyuk

    Керівник проекту

  • Oleg
    Oleg

    Дизайнер

  • Вадим Гуменний
    Вадим Гуменний

    Back-end розробник

  • Саша Ленський
    Саша Ленський

    Back-end розробник

  • Timur
    Timur

    Back-end розробник

  • Євген
    Євген

    Системний адміністратор

  • Олександр
    Олександр

    Android розробник

  • Антон
    Антон

    Android розробник

  • Konstantin Kolesnik
    Konstantin Kolesnik

    iOS розробник

  • Олександра
    Олександра

    PR менеджер

Наші проєкти

  • Сайт для MeinFernbus

    Сайт для MeinFernbus

    Розробка програмної частини та дизайн сайту для найбільшої автобусної компанії, Німеччина

  • Сервіс BenzinPreis24

    Сервіс BenzinPreis24

    Сервіс для ефективного пошуку заправок у Швейцарії

  • SmartSeeds

    SmartSeeds

    Uber like рішення для ринку вантажного перевеження зернових культур "SmartSeeds"

Залишайте контакти і дізнайтеся вартість вашого проєкту

Бюджет

  • 10K
  • 20K
  • 50K
  • 100K
  • 150K
  • 200K