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