在COSCUP上聽到的各種物聯網

CAN_5105
《站在NAS中心呼喊物聯網》-Spark 的 Photon開發版拉低了物聯網的製作門檻(圖源:COSCUP 2016 官方提供)

最近物聯網熱潮席捲整個科技界,台灣當然也有一群主管每天看新聞當然也不能坐著不動。開源社群當然也要趁機來個iOT群英會。

以下大略列出COSCUP上我聽到 IOT 先關講座題目:

  1. 無人機空汙監控物聯網-整合MQTT於3G/GPRS網絡
  2. 物聯不滿足-自由管理物聯網裝置和溝通的freebird.js
  3. 站在NAS中心呼喊物聯網
  4. Sensor Web 開源真實世界環境,iOT 的Open Data平台

每個講座都暴露了物聯網一個核心問題那就統一性。物聯網之所以強大是因為大家都能相互溝通,自動化生活某些動作。假設某天晚上,如果家中的Nest 攝像機檢測到屋主回家了,而家中另一個智慧溫度計顯示溫度是33度,那麼這時智慧空調是不是應該自動開啟,而家中的Philips Hue是不是應該也要自動開燈呢?

xiaomi_iot.png
小米龐大生態鏈?(圖來自小米中國網站)

可惜那是理想的物聯網世界,而現實的世界卻是物聯網各自為政,不想使用競爭者的機制以免便宜了對方,更別說什麼開源自找麻煩的事了,這樣還能免被破解了還要花一堆力氣去寫補丁。看看市面上的安卓手機就是一個典型的廠商不負責任的後果,各類價值上萬台幣的手機出現了各種資安漏洞廠商都不會去補了,更何況是幾千台幣的物聯網裝置呢?這樣是否最終回變相成廠商會以資安問題,綁架使用者不斷升級裝置來解決問題呢?

另外工業上如果採用物聯網設置,日後擴充也需要找回同一廠家,變相的獨霸狀態。

另一方面,我認為在今日各種通訊機制發達的年代,建立物聯網不再困難。普通一個8歲小孩也能跟著網絡教學用輕易上手的開發版做個物聯網裝置出來。對一位主修先關領域的大學生而言,也可以輕易地寫出一套程式使用自己架設的API 服務。但是他們能否與其他非自制裝置溝通?殘酷的現實表明這是不能的。從零到有,這個過程不困難,困難在於如何統整大家變成說著同一種語言。

我個人覺得物聯網的通訊協定還沒提出一個最佳化(負載輕、能運用在各種頻道上、安全性高)的協定之前。各家還是會各自為陣,自己講著自己的語言,不斷推出各種裝置壯大自己的生態鏈建立自己的平台來吸引消費者。這次的COSCUP沒有出現一個完美的解決方案,只能抱著繼續等待的態度守望。若未來自幹一個物聯網裝置,說著自己的語言。

 

 

 

 

究竟LLVM關我什麼事啊?

先前對於編譯器毫無概念的我,第一場講座的主軸就是編譯器框架—LLVM。第一次接觸編譯器從大會上的講座理解來的,若有什麼錯誤請在文章下留言指正喔~

llvm-1
(截圖自講者簡報)

LLVM 是什麼呢?網絡上有人把它叫做編譯器,可是對我而言它更像是寫編譯器的框架。例如寫網站可能會用Django, Ruby on Rails, Node js, laravel.這些框架能快速的讓你開發網頁,但開發網頁也不一定要使用框架來寫。而LLVM能讓開發人員迅速的將某種語言最佳化,再將語言轉譯成能在目標CPU結構上跑的組合語言(例如ARM與x86都有各自的組合語言)最後再變成機器語言。

這個過程中,大略可以分為三個流程:

llvm-process
(截圖自講者簡報)

1)前端:前段的工作是在得到程式代码之后做掃描、parsing與建立parse-tree(AST)。

2)最佳化:往往程式在編譯過程中為了顧及閱讀性與擴充性,而顧及這兩個前題下寫出的結果對於電腦而言不會是最佳化的程式。這時變會在不改變程式功能的前提下在做刪減的動作。有趣的是 GCC編譯器便用了200多類的最佳化方式,確保程式能以最精簡的方式運行。

3)後端:到了最後的步驟便是將最佳化的程式轉成適合在各種CPU架構上的組合語言。這裡雖然使用LLVM框架可以省去很多步驟(處理變成DAG結構的程式),可是由於不同架構支援的運算能力不同(例如有些處理器不支持除法,所以要將除法變為一堆減法計算)所以需要人手進行一些更動。當然除了這個之外,還有處理不同架構scheduling方式不一樣所以需要做順序最佳化還有register分配最佳化…等問題。

以上介紹了LLVM並非框架的全部,當中還有許多細節與過程我選擇省略掉了。我覺得在這軟體工具繁榮的年代,許多人已經漸漸忘了一行編譯指令背後的血汗過程了。不僅僅需要面對難讀的語言(雖然講者不斷說“LLVM IR 很好讀…”)還要對於CPU架構瞭如指掌,能善用所有的功能確保結果是最適合在該框架上運作的組合語言。

希望各位在寫完程式後,在compile程式時,對於輸出結果能有不一樣的理解,而不再是程式經過一些魔術變成屏幕上能動的魔法。

 

講者浪打與Hydai的簡報網址:http://www.slideshare.net/zongfanyang

 

COSCUP 2016 | DAY 1 心得

 

How_to_be_a_full_stack_engineer
攝於:如何使用Raspberry PI 成為一位全端工程師演講場地 R0

 

一早從新竹出發到台北轉運站,整個人還沈醉在昨日的林李世紀之戰中,除了累還是累。所以在市政府的捷運站下來找個咖啡喝。沒想到順點的三重起司竟然比小七放了一日的三重起司還乾燥,彷彿和我的人生一樣。

滿足了軀體的咖啡因需求量後,便繼續前往中研院。抵達南港捷運站後,忽然發現事前竟然沒有查好巴士站的位置。好在剛好兩位路人,各自都背著背包,一位眼神中透露出一位科學家不妥協於失敗的精神,另一位年輕人則一看就是要去宅男聚會的樣子。於是當下決定跟著二位應該沒錯,哈哈哈哈?

跟著他們腳步,順利抵達車站,搭上不知道哪號公車,莫名其妙的跟著他們在中研新村下車,走著走著就到了中央研究院了繼續跟真的是到了年會會場的人社館!

ethernet_port
沒有人賣網路線嗎?

至於行程原來的規劃是這樣的:

LLVM 由淺入淺 -> 用Raspberry Pi成為全端大師 -> 去社群攤位與美女合照 ->Micro Http Server Implement in C  ->  再去社群攤位與美女合照  -> 逛社群攤位 -> DAY 1 END

original_plan

結果變成了…??

LLVM 由淺入淺 -> 用Raspberry Pi成為全端大師 -> 使用freebird.js 於iOT上-> 無人機空域監控物聯網 -> 國際貿易的自由/開源軟體策略 -> 在NAS中心呼叫物聯網 -> 如何提升程式效能 -> Lightning talk -> DAY 1 END

啊,說好的逛攤位和美女拍照呢?

第一天好不容易結束了,除了搜羅了一堆新名詞之外,對於之後幾篇評論素材也都想到方向了。

好累 à Day 1 END

end_of_the_day
題目叫《對望》好了

COSCUP 議程🔗:http://coscup.org/2016/schedules.html

 

COSCUP D1 | 四軸飛行器 x 環境監控

吃飽午餐以後,去了R1想要參與使用C 實踐Http Server 的講座,結果大家動作比我快一步,位子都沾滿了。不想站著45分鐘的情況下,只好到R0碰碰運氣,沒想到又是座位get,想說就隨便去聽聽好了。

兩位講者, Larry Stanley和Dalin Chang 來自ArkLab多旋翼工作坊的開發人員,開場幽默風趣的對白:“我們是搞機時認識的…(咦?)”。暫時讓我拋開了飯後想睡的雜念,做個好觀眾。

一般聽到大家研究都是專注在如何製作自動導航的相關領域,可是兩位講者從環境監測出發,將採取樣本的工作自動化,透過四軸飛行器採集大面積的樣本。為了達到樣本數據能及時回傳,Arklab團隊使用了GPRS 覆蓋廣闊的優勢並結合 MQTT 傳輸協定負載小的優點將數據傳給node js,透過圖表將數據視覺化。正如講者Larry所說“我要將數據視覺化弄得連我阿嬤也看的懂”

演講者做的是環境監測飛行器所以飛行器上也附加了空氣採集樣本的感測器,將無人機周圍的亂流空氣灌入一個空氣道,行成一個穩定氣流以取得較準確的空氣指標。另外,無人機除了採取空氣樣本以外,還有添加浮漂在螺旋翼上,讓四軸飛行器能穩定的停留在水面上,採集湖水/河水樣本再起飛。

最後講者帶過各種如何指定無人機出錯防護機制後便來到了精彩的demo時間。

由於小編座的位置偏後了,錄影效果不佳…. 這裡就省略了。Demo的內容也只是讓六軸飛行器稍微升空以後就結束整個演講了。

我個人的最大的收穫也莫過於對於遠程實時讀取數據的實作更加了解(GPRS+MQTT) 。至於說好的用C語言實作一個server呢,我想還是乖乖用我的python就好了。