高德導(dǎo)航中紅綠燈倒計(jì)時(shí)方案猜測(cè)
本篇文章通過對(duì)高德地圖的紅綠燈倒計(jì)時(shí)提示,引發(fā)作者對(duì)此方案設(shè)計(jì)的猜測(cè)。作者以方案分析、功能梳理兩個(gè)方面為主要論述內(nèi)容,分析他對(duì)其的思考猜測(cè),希望能對(duì)你有所幫助。
作為一個(gè)產(chǎn)品經(jīng)理,尤其是有好奇心的產(chǎn)品經(jīng)理,分析拆解已發(fā)布的產(chǎn)品功能是必不可少的事兒。
而最近對(duì)高德紅綠燈預(yù)測(cè)的方案分析就是其中之一。
一、起因
一天下午和我們的技術(shù)同學(xué)一同出差,路上在十字路口等著漫長(zhǎng)的紅燈讀秒。而此時(shí)高德導(dǎo)航上也在顯示紅綠燈倒計(jì)時(shí),第一反應(yīng)是這個(gè)功能有意思且有用,解決因前方大車遮擋而看不到紅綠燈的問題能提高通行效率(可以讓司機(jī)提前準(zhǔn)備駕駛,從抖音、朋友圈的娛樂中回到駕駛中)。
我在感嘆這個(gè)功能不錯(cuò)同時(shí),也在想它是如何實(shí)現(xiàn)。
而我們的技術(shù)同學(xué)強(qiáng)烈表示這是個(gè)硬件方案,要不咋能這么準(zhǔn)確哪?
雖然在接下來的路口我們認(rèn)真核對(duì)APP倒計(jì)時(shí)和燈桿上倒計(jì)時(shí)的差距,大概有2到3秒的誤差。但是其仍認(rèn)為是硬件的IOT方案,在保持沒有深入思考就沒有發(fā)言權(quán)的原則同時(shí),我選擇回來想想到底要如實(shí)現(xiàn)。
二、方案分析
1. 硬件IOT方案
如果想知道是不是硬件IOT方案,首先要想:如果是這個(gè)方案,那么需要和誰合作?有什么成本?
- 合作方:需要和各個(gè)地方的交管部門合作,同時(shí)涉及到硬件的采買、定制改造、安裝等,而且紅綠燈的硬件和家用燈硬件標(biāo)準(zhǔn)不同。紅綠燈需要在高溫、大雨等各種惡劣環(huán)境都能長(zhǎng)時(shí)間正常運(yùn)行,而家用燈很多時(shí)候根本無需考慮雨雪高溫等情況。那么這個(gè)硬件成本的上升和各種合規(guī)測(cè)試,由誰來負(fù)責(zé)?
- 成本:除了我們上面的說的硬件本身,還有后續(xù)的安裝等成本,還有一條潛在成本:如何協(xié)調(diào)各個(gè)地方的交管部門在同一個(gè)時(shí)間前,都能上線?這個(gè)成本是無形的,但是很大,如果大家做過To B業(yè)務(wù)就能夠理解。就比方你在公司內(nèi)部做一個(gè)跨部門的合作,都不一定能順暢,那么跨地域、跨部門哪?畢竟高德的紅綠燈預(yù)測(cè)在上線初期就有了好幾十個(gè)城市,和這些城市的幾萬個(gè)核心路口。
通過以上看,硬件IOT的方案是理論上可行,但是成本太大,大概率不會(huì)是這個(gè)方案。
2. 平臺(tái)接入
如果有硬件且需要多方協(xié)調(diào)的成本如此大,是否可以純軟件平臺(tái)介入哪?比如直接拿各個(gè)地方交管平臺(tái)的數(shù)據(jù)哪?
我理解這個(gè)也不行,除了數(shù)據(jù)安全的角度外,最大的一個(gè)悖論是:如果我拿到了交管平臺(tái)的數(shù)據(jù),我為啥不把所有路口的倒計(jì)時(shí)都做了哪?為啥只有一部分路口數(shù)據(jù),而另一部分沒有哪?
因?yàn)閺慕还芷脚_(tái)的角度看,各個(gè)紅路燈的倒計(jì)時(shí)數(shù)據(jù)是沒有本質(zhì)差別的。
而這個(gè)矛盾點(diǎn)的存在,證明現(xiàn)有的方案也不是交管平臺(tái)接入。
3. 數(shù)據(jù)挖掘
如果既不是硬件也不是平臺(tái),還能是什么?大數(shù)據(jù)挖掘。這個(gè)方案的好處是:
- 不依賴公司外部,只需要組織(項(xiàng)目組)內(nèi)部協(xié)調(diào),周期自控。
- 現(xiàn)有的核心數(shù)據(jù)在移動(dòng)端都可以獲得,且DAU足夠大,畢竟國(guó)內(nèi)導(dǎo)航top2就是百度和高德。
- 針對(duì)路口車流量數(shù)據(jù)(數(shù)量、質(zhì)量、置信度等)來區(qū)分是否需要挖掘該位置信息,非核心路口的車流量小,那么對(duì)應(yīng)數(shù)據(jù)就少,經(jīng)過數(shù)據(jù)清洗后可用的數(shù)據(jù)、能提高/達(dá)到的置信度都會(huì)比較難,所以才導(dǎo)致車流量小的非核心路口,沒有上線該能力。
三、功能梳理
我們分析完,發(fā)現(xiàn)最可能得是組織內(nèi)部的純軟件方案, 那么結(jié)合一個(gè)case,我們嘗試梳理下需要哪些數(shù)據(jù),及如何實(shí)現(xiàn)。
我們以一個(gè)十字路口要識(shí)別直行的紅燈、綠燈時(shí)長(zhǎng)為例子來考慮。
基于如上的信息,先看司機(jī)是否在導(dǎo)航中,再看要識(shí)別的這個(gè)路口是否在用戶當(dāng)前的規(guī)劃路線中。如果是,我們?cè)倏串?dāng)前車輛在紅綠燈前后的表現(xiàn),也就是關(guān)注速度的變化。
當(dāng)考慮如下圖的一個(gè)十字路口時(shí),我們先看不同車道的通行限制。其中只有中間車道可以直行,所以可以忽略后續(xù)左轉(zhuǎn)和右轉(zhuǎn)的車輛,僅僅看那些車輛從當(dāng)前俯視圖路口的左側(cè)到達(dá)了右側(cè)。
比如圖中的轎車和跑車的行駛數(shù)據(jù),而其中右轉(zhuǎn)的皮卡則無需關(guān)注,因?yàn)樗臄?shù)據(jù)對(duì)當(dāng)前直行紅綠燈時(shí)間判斷幾乎沒有影響。
然后再看不同車輛在這個(gè)路口附近(附近這個(gè)概念可以是上一個(gè)路口到這個(gè)路口,或者限定多遠(yuǎn)的距離內(nèi),或者兩者結(jié)合取最小值)速度的變化。
如果我們以當(dāng)前路口為例,將一天內(nèi)各個(gè)時(shí)段經(jīng)過該路口的不同車輛速度都畫在一個(gè)二維坐標(biāo)系中,會(huì)是怎么樣哪?
我們以三臺(tái)車和一個(gè)紅綠燈周期為例子還嘗試畫出來:
因?yàn)椴煌囕v在到達(dá)該紅綠燈附近的速度不同,而且在該紅綠燈前方停止的車輛數(shù)量不同,會(huì)導(dǎo)致其剎車時(shí)的加速度不同。也就是影響了曲線斜率(為了簡(jiǎn)單,假設(shè)加速度都是線性變化),同時(shí)會(huì)導(dǎo)致其停止的時(shí)間不同。
如果考慮這三輛車的速度變化,綠色停的最晚、起步也最晚;而紅色停的最早,起步也最早。
大概率是紅色排在第一,藍(lán)色第二,綠色第三,而他們?nèi)齻€(gè)的停車時(shí)長(zhǎng)所占用的是時(shí)間段,就是該紅綠燈的紅燈時(shí)段。
我們可以把這個(gè)例子再擴(kuò)充下,考慮兩輛車遇到紅綠燈需要停車再起步,另一輛車遇到綠燈直接開過去的情況。
紅車和綠車符合剛才說的規(guī)律,在其起步并且速度起來后的時(shí)段中,藍(lán)色車以一定速度駛?cè)?,并且做了減速(過路口一般要減速),然后在提速。
那么可以看到在藍(lán)色車的這個(gè)時(shí)間段內(nèi)就是緊接著剛才紅燈時(shí)段的綠燈時(shí)段,然后再會(huì)進(jìn)入下一個(gè)紅綠燈時(shí)段的循環(huán)。
再接著如上的例子,我們將右轉(zhuǎn)擴(kuò)展為右轉(zhuǎn)加直行,那么這種情況會(huì)比剛才復(fù)雜。當(dāng)直行紅燈時(shí),在最右側(cè)車道上需直行的車輛依然會(huì)停車,從速度減為零,再?gòu)牧闫鸩竭@個(gè)過程與剛才類似。
但是如果此時(shí)是綠燈,一部分行人和電瓶車的直行導(dǎo)致右轉(zhuǎn)車輛停車等待,而此時(shí)在右側(cè)車道要直行的車輛,必然也需要等待。
如圖中需要直行的藍(lán)色車輛和需要右轉(zhuǎn)的灰色車輛(用對(duì)應(yīng)顏色線表示其即將走的軌跡),此時(shí)與已經(jīng)直行的車輛數(shù)據(jù)要如何處理?
筆者大膽猜測(cè),當(dāng)有一定數(shù)量的直行數(shù)據(jù)時(shí)候,這部分為零的數(shù)據(jù),可以不要。或者我們考慮使用該數(shù)據(jù),但是需要如下思考:
- 司機(jī)是理性人,當(dāng)中間車道沒有車或者車輛明顯少于右側(cè)車道時(shí),其不會(huì)駛?cè)胗覀?cè)車道來直行。所以司機(jī)在右側(cè)車道直行時(shí),中間車道的直行車輛必然多于右側(cè)車道的直行車。
- 而考慮到數(shù)據(jù)的置信區(qū)間,當(dāng)數(shù)據(jù)通過多次累計(jì)后,便可以知道紅燈時(shí)長(zhǎng)。如圖,藍(lán)色車輛速度為0的時(shí)間明顯更長(zhǎng),但是在多次數(shù)據(jù)積累下,還是可以確信紅色和綠色車輛的零速時(shí)間段為紅燈時(shí)間段。
上面所有信息都沒有基于導(dǎo)航的地理位置數(shù)據(jù)來分析,如果考慮可以精確到車道級(jí)別的數(shù)據(jù)來分析,就回更加簡(jiǎn)單。
比如剛才右側(cè)車道允許直行的例子就好處理,可以將所有右側(cè)車道的數(shù)據(jù)單獨(dú)處理,或者作為輔助判斷即可,也可以用同一個(gè)時(shí)刻右轉(zhuǎn)車輛的等待時(shí)間結(jié)合起來計(jì)算。
相對(duì)簡(jiǎn)單的辦法就是用中間直行車道數(shù)據(jù)來計(jì)算,因?yàn)閿?shù)據(jù)量足夠大,所以暫時(shí)剔除一部分應(yīng)該對(duì)預(yù)測(cè)準(zhǔn)確性影響不大。
當(dāng)一個(gè)簡(jiǎn)單情況分析后(類似我們學(xué)數(shù)學(xué)的特例),我們?cè)贁U(kuò)展條件,比如上文提到的右轉(zhuǎn)車道上允許直行。
在考慮這個(gè)擴(kuò)展后,我們還可以考慮如下更多因素:
- 考慮N天的同一時(shí)段的數(shù)據(jù),紅綠燈循環(huán)有穩(wěn)定性的周期性,再結(jié)合工作日和休息日考慮(有部分紅綠燈在休息日是黃燈閃爍)。
- 考慮天氣異常對(duì)車輛行駛速度的影響。
- 考慮司機(jī)臨時(shí)改變路線(可能是開錯(cuò)了數(shù)據(jù)如何處理)。
- 在考慮非導(dǎo)航內(nèi)數(shù)據(jù)如何使用(此處可以截個(gè)行車軌跡圖,高德有的)。
當(dāng)模型已經(jīng)有了一個(gè)版本,如何更新迭代?
此時(shí)建立一個(gè)數(shù)據(jù)模型循環(huán)飛輪即可。筆者認(rèn)為該功能在最初上線前,除了通過原始數(shù)據(jù)中部分未參與模型訓(xùn)練數(shù)據(jù)進(jìn)行模式測(cè)試,同時(shí)可結(jié)合實(shí)際線上的、實(shí)時(shí)的車輛行駛數(shù)據(jù)進(jìn)行測(cè)試。
- 比如模型預(yù)測(cè)該紅綠燈現(xiàn)在司機(jī)需要停車,當(dāng)然此時(shí)用戶側(cè)無感知,然后看車輛接下來的速度變化是否符合預(yù)期。
- 比如模型預(yù)測(cè)該司機(jī)保持現(xiàn)有速度可以綠波通過接下來的四個(gè)紅綠燈,但是在第三個(gè)卻停車,這便不符合預(yù)期,那就結(jié)合前段時(shí)間(天)該路口的數(shù)據(jù)從新分析。
- 比如模型預(yù)測(cè)該司機(jī)此時(shí)可以行駛過該路口但是卻停下來了,而且接下來的周期中經(jīng)常出現(xiàn)該情況,就要考慮是否此處紅燈時(shí)間或者周期已經(jīng)進(jìn)行調(diào)整,然后從新更改模型。
四、寫在最后
以上的分析都是站在廚房門外,聞著味道猜測(cè)做了什么菜、怎么做的菜。如果有讀者知道菜譜,還望聯(lián)系分享。
專欄作家
代成龍,人人都是產(chǎn)品經(jīng)理專欄作家,智能硬件創(chuàng)業(yè)公司產(chǎn)品狗,從視頻巨頭公司到玩智能硬件的公司,繼續(xù)產(chǎn)品設(shè)計(jì)工作。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
其主要思路就是根據(jù)紅綠燈的周期性來做的。
第一步根據(jù)車輛的啟停時(shí)間,尤其是第一輛車的啟停定位出紅綠燈的啟停時(shí)間,并根據(jù)紅綠燈切換規(guī)律計(jì)算出紅綠燈的周期。
那每次顯示紅燈倒計(jì)時(shí),只需要根據(jù)起點(diǎn)時(shí)間和紅綠燈切換周期計(jì)算當(dāng)前時(shí)間的紅綠燈狀態(tài),下次切換的時(shí)間差即為倒計(jì)時(shí)。
看地點(diǎn)和清晰的描述,感覺像是內(nèi)部的,哈哈,多謝分享
高德已經(jīng)申請(qǐng)了算法專利
https://www.zhangqiaokeyan.com/patent-detail/06120114907881.html
兄弟,寫得真好~
不過高德這套算法已經(jīng)注冊(cè)了專利權(quán),可以直接查看到??梢运阉鲗@?hào)或者標(biāo)題查詢:CN114463969A 紅綠燈周期時(shí)長(zhǎng)的挖掘方法、電子設(shè)備及計(jì)算機(jī)程序產(chǎn)品
多謝分享啊
正好有相同的疑問,感謝波!
肯定是算法,高德還為這個(gè)算法申請(qǐng)專利了。我覺得,應(yīng)該沒有樓主分析的那么復(fù)雜。首先高德知道車輛是直行還是左右轉(zhuǎn),其次,等候紅燈的時(shí)間數(shù)據(jù)應(yīng)該是滿足正態(tài)分布的情形。通過算法獲取到占比最多的停車時(shí)長(zhǎng)區(qū)間,最后通過平均法之類的方式取得紅燈時(shí)長(zhǎng),采集樣本用ai匹配最合適的算法。
實(shí)際上,就是交管系統(tǒng)的對(duì)接數(shù)據(jù),其實(shí)所謂的成本也并沒有那么大,交管系統(tǒng)有自己一套獨(dú)立的紅綠燈控制系統(tǒng)
請(qǐng)問您有比較確切消息嗎,我自己是判斷為大數(shù)據(jù)預(yù)測(cè)的,比較難以獲得確切消息
首先你的想法很大膽,也有一定基礎(chǔ),慶幸的是高德是有對(duì)應(yīng)的算法,也有對(duì)應(yīng)的專利,但是算法是大數(shù)據(jù)獲取,基礎(chǔ)還是支撐在對(duì)接交管系統(tǒng)中,我做過相鄰項(xiàng)目,高德的具體情況我不很了解,但是我了解到的是這樣
不好意思,忘了查看消息。應(yīng)該也沒有很大膽吧,哈哈。畢竟這個(gè)數(shù)據(jù)相對(duì)還是好算的,會(huì)更傾向于是算法預(yù)測(cè)。尤其是也時(shí)常有預(yù)測(cè)錯(cuò)的case
不是交管數(shù)據(jù)。我為啥可以肯定這么說呢,是因?yàn)槲疫@有一個(gè)施工的路口是一個(gè)簡(jiǎn)易的紅綠燈,這種紅綠燈只有一個(gè)太陽能板用于發(fā)電。擺了一段時(shí)間后,有一天我開車經(jīng)過時(shí),突然我的導(dǎo)航就有這個(gè)紅綠燈的讀秒。這種簡(jiǎn)易紅綠燈應(yīng)該沒道理接入交管系統(tǒng)吧
最簡(jiǎn)單的例子,同一個(gè)路口有時(shí)候有讀秒,有時(shí)候就沒有。如果對(duì)接獲取交管系統(tǒng)數(shù)據(jù),應(yīng)該每次紅燈都有讀秒。
沒看懂,到底是靠啥顯示.0.0
用戶行為