මම කොළඹට හරියන Free Route Optimizer එකක් හැදුවා. හැබැයි මේකට දැන් Real Traffic Data ඕනේ.
පහුගිය මාස කිහිපය පුරාවටම මම වැඩ කළේ කොළඹ delivery riders ලට පාවිච්චි කරන්න පුළුවන් Open-source route optimizer එකක් හදන්න. මේකෙන් ඩිලිවරි කරන්න තියෙන තැන්වලට යන්න ඕනේ හොඳම පිළිවෙළ ප්ලෑන් කරනවා විතරක් නෙවෙයි, දවසේ වෙලාව සහ නිවාඩු දවස් අනුව traffic එකත් predict කරනවා. විශේෂම දේ තමයි මේක පාවිච්චි කරන්න කිසිම ගාස්තුවක් යන්නේ නැහැ.
තවත් ගැඹුරටවිනාඩි 2
කෙටියෙන්ම කිව්වොත්
හැබැයි පොඩි අවුලකට තියෙන්නේ, මේක දැනට Proof of Concept (PoC) එකක් විතරයි. මේකේ පාරවල් ඇත්ත වුණාට, දැනට තියෙන traffic data simulated (කෘත්රිමව හදපු) ඒවා. මේක ඇත්තටම ප්රයෝජනවත් tool එකක් කරන්න නම්, ලංකාවේ පාරවල්වල real traffic data මේකට අත්යවශ්ය වෙනවා.
අන්න ඒ නිසයි මම මේ ප්රොජෙක්ට් එක සම්පූර්ණ වෙන්නත් කලින්ම GitHub එකේ ඔයාලත් එක්ක share කරගන්න හිතුවේ.
ඇයි මේක වැදගත් වෙන්නේ? ලංකාවේ courier සර්විස්, grocery ඇප් සහ ඩිස්ට්රිබියුටර්ස්ලට routing කියන්නේ දෛනිකව ලොකු වියදමක් යන වැඩක්. දැනට තියෙන හොඳ routing tools හැම request එකකටම ගාණක් අය කරනවා. පොඩි local ටීම් එකකට මේක දරාගන්න අමාරුයි.
ඒ වගේම කොළඹ traffic එකට තියෙන්නේ වෙනමම rhythm එකක්. ඔෆිස් වෙලාවල්, පෝය දවස්, දිග සතිඅන්ත (long weekends) වගේම සිංහල හින්දු අලුත් අවුරුද්ද වගේ දවස්වලට කොළඹ traffic එක සම්පූර්ණයෙන්ම වෙනස් වෙනවා. Global tools වලට අපේ මේ දේවල් ඒ තරම් හරියට අඳුරගන්න බැහැ.
මගේ අදහස වුණේ, අපේ රටේ traffic රටාවන් තේරුම් ගන්න පුළුවන් AI model එකක්, නොමිලේ තියෙන තාක්ෂණයන් (free building blocks) එක්ක එකතු කරලා හැමෝටම පාවිච්චි කරන්න දෙන එකයි.
මම හැදුවේ මොකක්ද? ඩිස්පැචර් කෙනෙක්ට පුළුවන් මේ වෙබ් පේජ් එකට ගිහින්, map එකේ ඩිලිවරි කරන්න තියෙන තැන් ටිකයි ඩිපෝ එකයි මාක් කරලා, දිනයක් සහ ෂිෆ්ට් එකට අදාළ වෙලාව දීලා "Optimize" ක්ලික් කරන්න. තත්පර කිහිපයකින් ඩිලිවරි කරන්න ඕනේ හරියටම පිළිවෙළ, ඒ ඒ තැනට යන වෙලාවල් සහ සම්පූර්ණ රූට් එක map එකේ බලාගන්න පුළුවන්.
මේක පිටිපස්සේ ප්රධාන free tools 4ක් එකතු වෙලා වැඩ කරනවා:
- Map එක: OpenStreetMap පාවිච්චි කරලා තියෙන්නේ. ලංකාවේ පාරවල්වල මෝටර් සයිකල් යන වේගයන්ට ගැළපෙන්න මේක වෙනස් කරලා තියෙනවා.
- Router එක: OSRM (Open Source Routing Machine). එක තැනක ඉඳන් තව තැනකට යන්න කොච්චර වෙලා යනවද කියන එක ගණනය කරන්නේ මේකෙන්.
- Planner එක: VROOM. ෂිෆ්ට් එක ඇතුළත යන්න ඕනේ හොඳම පිළිවෙළ තීරණය කරන්නේ මේක හරහා.
- Traffic Model එක: මේක පුංචි Neural Network එකක්. පෝය, අවුරුදු වගේ දවසුත් ඇතුළුව, දෙන ලද දවසකට සහ වෙලාවකට අදාළව පාරේ වාහන යන වේගය predict කරන්නේ මේකෙන්.
අපි ඇතුළත් කරපු පිළිවෙළටම ඩිලිවරි කරනවට වඩා, මේ optimize කරපු ප්ලෑන් එකෙන් කොච්චර දුරක් සහ කාලයක් ඉතුරු වෙනවද කියලත් ඇප් එකෙන් පෙන්නනවා.
වැඩේ කරගෙන යද්දි ආපු අභියෝග (The bumpy parts) මගේ කාලයෙන් වැඩි හරියක් ගියේ අලුත් දේවල් හදන්න නෙවෙයි, හිතපු නැති විදිහට කඩාකප්පල් වෙච්ච දේවල් හදාගන්නයි.
- කොළඹට open traffic data නැහැ: මම මාස ගාණක් හෙව්වා. අන්තිමේදී බීජිංවල ටැක්සි GPS data, කැලිෆෝනියාවේ හයිවේ සෙන්සර් data සහ පෝටෝවල ටැක්සි ඩේටා වගේ දේවල් පාවිච්චි කරලා බලන්න හැදුවා. ඒවයින් traffic models ගැන ගොඩක් දේවල් ඉගෙන ගත්තත්, ඒ data කෙලින්ම කොළඹ පාරවල් වලට ගළපන්න බැහැ.
- Model එක predict කළේ වැරදි නගරයකට: මගේ මුල්ම model එකේ output එක බීජිංවල පාරවල්වලටයි සෙට් වෙලා තිබුණේ. ඒ නිසා predictions ඇත්ත කොළඹ පාරවල්වලට වැටෙන විදිහට, කොළඹ පාරවල්වල කෑලි (road segments) 17,000කින් විතර මට අලුතෙන්ම graph එකක් හදන්න සිද්ධ වුණා.
- Model එක collapse වුණා: Training වල තිබුණ පොඩි bug එකක් නිසා model එක දැකලා තිබුණේ දවල් කාලය විතරයි. ඒ නිසා ඒක එක අගයක් ඉගෙනගෙන හැම පැයකටම ඒකම repeat කළා. දවස පුරාම තියෙන training windows shuffle කරලා තමයි මම ඒක හදාගත්තේ.
- අපේ කැලැන්ඩර්ස් ටිකක් සංකීර්ණයි: පෝය දවස තීරණය වෙන්නේ හඳ අනුවනේ. ඒ වගේම අවුරුදු දවසත් අධික අවුරුදුවලදී වෙනස් වෙනවා. Prototype එකට මම එක අවුරුද්දක දවස් ටිකක් hard-code කළා. හැබැයි ඒක demo එකකට හරියනවා මිසක් production එකකට නම් හරියන්නේ නැහැ.
- Live traffic updates නිසා router එක crash වුණා: හැම optimization එකකදීම පාරේ වේගයන් අලුතින් හැදිලා routing engine එක restart වුණා. Request දෙකක් එක ළඟ ආවොත් බාගෙට ලියවුණු ෆයිල්ස් read වෙලා ලොකු අවුලක් ගියා.
- Savings ගණනය කිරීම් වැරදුණා: Compare කරන්න හදපු සාමාන්ය රූට් එකේදී එක stop එකකට විනාඩි 15ක් යනවා කියලා අරගෙන, optimize කරපු එකේ විනාඩි 3යි ගත්තේ. ඒ නිසා මම ඒක හරියට හදලා සමාන කරනකම්, හැම stop එකකින්ම විනාඩි 12ක් ඉතුරුයි කියලා පෙන්නුවා.
පාඩම: ලස්සනට පේන චාට්ස් අස්සේ ලොකු වැරදි හැංගිලා තියෙන්න පුළුවන්. දැන් මම හැම අගයක්ම මුලින්ම බොහොම සරල baseline එකක් එක්ක චෙක් කරලා බලනවා.
දැනට මේක තියෙන තත්ත්වය Routing part එක දැන් නියමෙටම වැඩ. කොළඹ ඇත්ත pins ටිකක් දුන්නොත්, තත්පරයක් යන්න කලින් හොඳ ප්රායෝගික ප්ලෑන් එකක් හදලා දෙනවා.
හැබැයි Traffic model එක නම් තාම හරියටම ready නැහැ:
- පාරවල් ඇත්ත වුණාට ඒවයේ යන speed එක ඇත්ත නෙවෙයි. මේක ට්රේන් කළේ කෘත්රිමව හදපු එක අවුරුද්දක ඩේටා වලින් (rush-hour curve එකක්, නිවාඩු දවස්වල වෙනස්කම් සහ random noise ටිකක් දාලා).
- දැනට Neural network එකෙන් එන රිසල්ට් එකට වඩා, "මේ වෙලාවට තියෙන සාමාන්ය වේගය" කියලා නිකන්ම අනුමාන කරන (simple lookup) එකත් නිවැරදියි. ඒක සාමාන්යයි, මොකද model එකකට ඉගෙනගන්න පුළුවන් අපි දෙන ඩේටාවල තියෙන දේවල් විතරයිනේ.
- මේක කරන වැඩේ හැටියට ගොඩක් heavy. එක traffic update එකකට විනාඩියකට වඩා යනවා වගේම ලැප්ටොප් එකේ 6GB විතර RAM එකක් අදිනවා.
කෙටියෙන්ම කිව්වොත්: System එකේ මූලික අඩිතාලම දාලා ඉවරයි. දැන් අඩු, මේ model එක ඇත්තටම ප්රයෝජනවත් කරන්න ඕනේ කරන real data ටික විතරයි.
ඊළඟට මොකද වෙන්නේ? ඔයාලට උදව් කරන්න පුළුවන් කොහොමද? ඊළඟ පියවර කියන්න ලේසියි: කොළඹ පාරවල්වල වෙලාවත් එක්ක තියෙන ඇත්ත GPS traces පාවිච්චි කරලා මේක ට්රේන් කරන එක. ඒ වගේම අලුත් ඩේටා එනකොට දිගටම අප්ඩේට් කරන එක.
මට ගොඩක්ම වටින්නේ මේ දේවල්:
- Fleet සහ courier ධාවනය කරන අයගෙන්: ඔයාලගේ riders ලගේ හරි වෑන්වල හරි පෞද්ගලිකත්වය ආරක්ෂා වෙන විදිහට (anonymized) දෙන GPS pings (location, time, speed). වාහන කිහිපයක සති කිහිපයක ඩේටා වුණත් වැඩේ පටන් ගන්න ලොකු උදව්වක්.
- Ride-hailing, බස් හෝ ටුක්-ටුක් ඩේටා: නගරයේ වාහන යන වේගය ගැන තියෙන පරණ ඩේටා හෝ live speed feed එකක්.
- Engineers ලා සහ students ලගෙන්: වඩා හොඳ map matching, හරියටම වැඩ කරන පෝය සහ නිවාඩු දින කැලැන්ඩරයක්, සහ simple baselines එක්ක හරියටම evaluate කරන්න උදව්වක්.
- Dispatchers ලගෙන්: ඇත්තම ෂිෆ්ට් එකකදී routing tool එකකින් මොනවද වෙන්න ඕනේ කියලා මට කියන්න.
මගේ පොරොන්දුව: මේ ටූල් එක දිගටම free සහ open source විදිහට තියෙනවා. ඒ වගේම ඔයාලා share කරන ඕනෑම ඩේටා එකක්, පෞද්ගලිකත්වයට (privacy) මුල් තැන දීලා තමයි හසුරුවන්නේ.
මේ කියපු දේවල්වලින් ඔයාලට උදව්වක් දෙන්න පුළුවන් නම්, GitHub එකේ issue එකක් open කරන්න, නැත්නම් මට කෙලින්ම message එකක් දාන්න.
තවත් ගැඹුරටමේ ලිපිය පිටිපස්සේ තියෙන සම්පූර්ණ විස්තර, මූලාශ්ර එක්කම.
ඇතුළේ: තාක්ෂණික විස්තර ඕනේ අයට (Go deeper)
කියවන්නවසන්න
මේ ලිපිය පිටිපස්සේ තියෙන සම්පූර්ණ විස්තර, මූලාශ්ර එක්කම.
ඇතුළේ: තාක්ෂණික විස්තර ඕනේ අයට (Go deeper)
තාක්ෂණික විස්තර ඕනේ අයට (Go deeper)
ප්රොජෙක්ට් එක clone කරන්න කලින් technical විස්තර දැනගන්න ආස engineers ලටයි මේ ටික.

API එකෙන් traffic model එකට අදාළ වෙලාව සහ දිනය යවනවා. ඊටපස්සේ model එකෙන් predict කරන speeds ටික OSRM එකට write කරනවා. ඒක පාවිච්චි කරලා VROOM එකෙන් ඩිලිවරි කරන්න ඕනේ පිළිවෙළ ප්ලෑන් කරනවා.
Model එක ගැන
- ST-GAT: Graph attention layers දෙකක් (4 heads, hidden size 16) හරහා 2-layer GRU එකකට සහ පොඩි output layer එකකට ඩේටා යනවා. PyTorch Geometric වලින් හදපු මේකේ parameters 5,100ක් විතර තියෙනවා.
- Graph එක: කොළඹ වටේම OSRM routes වලින් ගත්ත intersections 13,499ක් සහ directed road segments 17,236ක් තියෙනවා.
- Inputs: හැම intersection එකකම පහුගිය පැය 12 ඇතුළත වේගය, ඒ වගේම calendar flags පහක් (සතිඅන්තය, දිගු සතිඅන්ත, පෝය දවස්, සහ අවුරුද්දට පෙර හා පසු දින).
- Output: හැම intersection එකකම ඊළඟ පැයේ තියෙන වේගය (මේක OSRM එකට segment speed file එකක් විදිහට ලියවෙනවා).
Routing ගැන
- ලංකාවේ OpenStreetMap extract එක උඩ OSRM එකේ MLD (Multi-Level Dijkstra) algorithm එක run වෙනවා. මේකට පාවිච්චි කරන්නේ මෝටර් සයිකල් profile එකක් (ප්රධාන පාරවල් 40 km/h, අතුරු පාරවල් 20 km/h).
- VROOM එකෙන් එක ඩිලිවරි එකකට විනාඩි 3ක සේවා කාලයක් (service time) අරගෙන, යූසර්ගේ ෂිෆ්ට් එක ඇතුළත යන්න ඕනේ හොඳම පිළිවෙළ හදලා දෙනවා.
- FastAPI වලින් හදපු backend එකෙන් orders ටික PostGIS වල සේව් කරනවා. ඒ වගේම UI එකට services වැඩද කියලා බලාගන්න health endpoint එකකුත් දෙනවා.
ඉදිරියට හදන්න තියෙන දේවල් (Known gaps worth fixing)
- දැනට Map matcher එක speed එක ගණනය කරන්නේ OSRM එකේම estimated travel time එකෙන් මිසක් GPS timestamps වලින් නෙවෙයි. Real ඩේටා වලදී අනිවාර්යයෙන්ම timestamps ඕනේ වෙනවා.
- හැම traffic update එකකදීම අවුරුද්දකම synthetic ඩේටා memory එකේ අලුතින් හැදෙනවා. Real ඩේටා ආවාම මේක rolling window එකකින් replace කරන්න පුළුවන්.
- දැනට නිවාඩු දවස් එක අවුරුද්දකට hard-code කරලයි තියෙන්නේ. මේකට හරියට වැඩ කරන lunar (චන්ද්ර මාස) කැලැන්ඩරයක් ඕනේ.
- Traffic updates එනකොට OSRM එක restart වෙන නිසා, එකවර එන requests (concurrent requests) මැනේජ් කරන්න queue එකක් හරි lock එකක් හරි පාවිච්චි කරන්න වෙනවා.
ඔයාලටත් මේක run කරලා බලන්න පුළුවන්: Database, OSRM, VROOM සහ API එකට Docker Compose තියෙනවා. ඒ වගේම model එකට Python environment එකක් ඕනේ. මේක සෙට්අප් කරන විදිහ ගැන සම්පූර්ණ විස්තරේ README එකේ දාලා තියෙනවා.
