跳到主要內容

掃地機去人進化史

掃地機器人   掃地機器人   掃地機器人吸塵器

在位於美國馬賽諸賽州貝德福德(Bedford)的iRobot總部,一片區域正在翻修,儘管一片狼藉,但櫥櫃、沙發、浴缸以及擺放各種建築材料,都告訴你這不是辦公區。

這裡是iRobot的實驗室。

在過去近十年的歲月長河裡,iRobot的機器人在這裡劃過了無數的軌跡。但沒人想到的是,從1990年公司成立到第一台掃地機器人駛出實驗室,走了12年的路。

家用掃地機器人的誕生,最早可以追溯到1996年,瑞士家電品牌伊萊克斯製造了一台名叫「三葉蟲」的掃地機器人,無論是設計,還是避障的設計思路,這都是一台頗具現代感的機器人。只不過在那個年代,掃地機器人還是個非常稀罕的電器,價格非常昂貴,也沒有很聰明。

90年代末,iRobot和清潔公司Johnson Wax合作推出了大型清潔機器人,這是iRobot第一次把機器人功用性放在清潔目的上。不久之後,公司決定打造家用掃地機器人。在那個年代,傳感器數量少質量差,把清潔機器人做小是一件很有挑戰的事。

團隊希望優先保證掃地機器人的覆蓋度和清潔程度,不管花多少時間。為此,他們制定了一套清潔策略:首先對一片比較大面積的區域進行打掃,完成之後再沿著牆面去到另一片區域,以此往復不斷切換。

而在具體產品形態上,Roomba採用了邊刷+滾刷+吸塵口的三段式清掃結構,大大提升了清掃能力,這一設計也成為如今掃地機器人的主流設計。

2002年,第一台Roomba掃地機器人走出生產線。

後來,Roomba研發出了污垢探測技術(Dirt Detect),機器人會透過物體撞擊的聲音以及視覺傳感器探測有沒有遺漏的髒物,如果某塊區域特別髒,機器人會在此處反復清掃。

Roomba的第二次進化,目標是清掃的「完成率」和「覆蓋率」。

早年的掃地機器人,通常是隨機亂撞的,它會行走大量的重覆路線,歸其原因是機器人不了解周邊的環境,也不知道自己所處的位置。

後來iRobot在高端系列加入了vSLAM技術,讓Roomba搭載了一個35度傾角的攝影鏡頭,它像一雙眼睛,可以不斷地「看到」家庭牆面的特徵,從而對家居環境進行一個畫像。具備了定位和建圖的能力,機器人就可以進行合理的路徑規劃。

測試是工程師日常一項非常重要的工作,iRobot搭建了數個空間去測試Roomba的實用性。

在一件玻璃封閉的實驗室裡,一名測試人員將Roomba掃地機器人固定在一台鋪著紅色地毯的儀器上,儀器會在地毯上進行噴塵處理,Roomba隨後沿著固定軌跡進行清掃,透過5次重複測試,並對清掃前後的塵盒進行稱重,測試人員就能測算出一台掃地機器人的吸塵能力。

實驗人員告訴我們,他們把會榻榻米和地毯混搭在一起,以此來考驗掃地機器人在複雜材質地面的表現。

工程師也會把Roomba帶回家中測試,放在真實居住環境中更有利於發現問題。比如毛髮容易纏繞在掃地機器人毛刷上的這種問題,就是在測試中發現的。工程師因此做了不少改進,比如在高端型號產品裡用上鋸齒胎面設計的雙膠棒主刷。

「我們計劃把2,000平方英尺的實驗室擴張到4,000平方公尺,因為我們推出了針對大戶型的Roomba 900系列之後,IEC標準已經無法適應我們的產品測試了,我們就新建了一個。」iRobot產品管理總監Ken Bazydola說。

Bazydola口中的「IEC標準」是國際性電工標準化機構針對掃地機器人的標準化測試,這套標準對掃地機器人的除塵能力、覆蓋率、甚至細化到邊角除塵能力都有明確的要求。

連營科技

參考資料:https://www.bnext.com.tw/article/48916/irobot

Orignal From: 掃地機去人進化史

留言

這個網誌中的熱門文章

2016年電動車和插電式混合動力車銷量預計將超過70萬輛

中汽協日前預測,2016年全國電動汽車和插電式混合動力車的銷量預計將超過70萬輛,較2015年的銷量增長一倍。 2015年電動車和插電式混合動力車的合併銷量為331092輛,較2014年增長了340%。其中包括247482輛電動車和83610輛插電式混合動力車,在24萬輛多的電動汽車銷量中,包括146719輛乘用車,另有100763輛為商用車。插電式混合動力車的銷量中,60663輛為乘用車,22947輛為商用車。 根據2015年起草的藍圖,政府計畫到2020年在全國範圍內新建12000個充電站和480枚充電樁。2014年年底,全國共有780個充電站共31000枚充電樁。2015年政府還為27個省市自治區設定了電動車的最低銷量目標。 政府預計,這些措施到位後,自主品牌車企的電動車和插電式混合動力車銷量到2020年可達100萬輛,到2025年可達300萬輛。 本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理 【其他文章推薦】 ※為什麼 USB CONNECTOR 是電子產業重要的元件? ※ 網頁設計 一頭霧水??該從何著手呢? 找到專業技術的 網頁設計公司 ,幫您輕鬆架站! ※想要讓你的商品成為最夯、最多人討論的話題? 網頁設計公司 讓你強力曝光 ※想知道最厲害的 台北網頁設計公司推薦 、 台中網頁設計公司推薦 專業設計師"嚨底家"!! Orignal From: 2016年電動車和插電式混合動力車銷量預計將超過70萬輛

012.Kubernetes二進制部署worker節點Flannel

一 部署flannel 1.1 安裝flannel kubernetes 要求集群內各節點(包括 master 節點)能通過 Pod 網段互聯互通。flannel 使用 vxlan 技術為各節點創建一個可以互通的 Pod 網絡,使用的端口為 UDP 8472。 flanneld 第一次啟動時,從 etcd 獲取配置的 Pod 網段信息,為本節點分配一個未使用的地址段,然後創建 flannedl.1 網絡接口(也可能是其它名稱,如 flannel1 等)。 flannel 將分配給自己的 Pod 網段信息寫入 /run/flannel/docker 文件,docker 後續使用這個文件中的環境變量設置 docker0 網橋,從而從這個地址段為本節點的所有 Pod 容器分配 IP。 更多flannel參考:《008.Docker Flannel+Etcd分佈式網絡部署》。 提示:k8smaster01節點已下載相應二進制,可直接分發至node節點。 1.2 分發flannel 1 [root@k8smaster01 ~]# cd /opt/k8s/work 2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh 3 [root@k8smaster01 work]# for node_ip in ${NODE_IPS[@]} 4 do 5 echo " >>> ${node_ip} " 6 scp flannel/{flanneld,mk-docker-opts.sh} root@${node_ip}:/opt/k8s/bin/ 7 ssh root@${node_ip} " chmod +x /opt/k8s/bin/* " 8 done 1.3 創建flannel證書和密鑰 提示:k8smaster01節點已創建flanneld的CA證書請求文件,可直接分發至node節點。 1.4 分發證書和私鑰 1 ...

怎麼把CAT客戶端的RootMessageId記錄到每條日誌中?

什麼是RootMessageId? 為了理解RootMessageId先簡單介紹一下CAT的數據結構設計。CAT客戶端會將所有消息都封裝為一個完整的消息樹(MessageTree),消息樹可能包括Transaction、Event、Heartbeat、Metric等類型的消息。具體如下: Transaction:適合記錄跨越系統邊界的程序訪問行為,比如遠程調用,數據庫調用,也適合執行時間較長的業務邏輯監控,Transaction用來記錄一段代碼的執行時間和次數 Event:用來記錄一件事發生的次數,比如記錄系統異常,它和transaction相比缺少了時間的統計,開銷比transaction要小 Heartbeat:表示程序內定期產生的統計信息, 如CPU利用率, 內存利用率, 連接池狀態, 系統負載等 Metric:用於記錄業務指標、指標可能包含對一個指標記錄次數、記錄平均值、記錄總和,業務指標最低統計粒度為1分鐘 歡迎關注微信公眾號: 萬貓學社 ,每周一分享Java技術乾貨。 其中,Transaction類型的消息可作為消息樹節點,而其他消息只可作為消息樹的恭弘=叶 恭弘子節點,也就是Transaction是一個可嵌套的遞歸結構。比如: 消息樹的每一節點都有一個屬性messageId,用來唯一表示節點本身,其構成為:{domain}-{ip}-{timestamp}-{自增index}。另外還有兩個屬性,分別是parentMessageId, rootMessageId。parentMessageId表示父節點的messageId; rootMessageId 則表示整個消息樹的根節點的messageId。這兩個屬性在之後CAT的調用鏈分析與分佈式調用鏈分析中發揮了關鍵作用。 歡迎關注微信公眾號: 萬貓學社 ,每周一分享Java技術乾貨。 為什麼在日誌中記錄? 根據RootMessageId可以追蹤某一個請求的整個分佈式調用鏈,結合每一條日誌快速定位耗費性能的癥結,做針對性的性能優化。更加方便地做性能優化,特別是TP95、TP99等指標。 遇到偶爾發生的bug,是最讓人頭疼的,只有先從日誌中找線索,但是在海量的日誌中找到出現bug的那一個請求是很困難的。有了上游API提供的RootMessage...