※ 本文為 dinos 轉寄自 ptt.cc 更新時間: 2017-05-03 07:19:45
看板 Soft_Job
作者 標題 [心得] 2017 NASA Hackathon 經驗分享
時間 Tue May 2 22:56:52 2017
要看圖的可以去FB https://goo.gl/ll6Vpc,我設公開。以下正文。
===========================================================
因緣際會下跟人組了隊參加這次 NASA 辦的 hackathon。
這是第六屆,會在全球不同城市同步舉行,而台灣則是第一次參加。
地球衛星觀測資料的特點是影像涵蓋範圍跟時間跨度大,
適合監控長時間變化,或是從大區域中過濾出感興趣的區域再派人去現地。
但大多數更新頻率最多每日一次,所以不適合做即時監控。
每顆衛星的目的性都非常強,資料分析的工具一般在發射前就準備好了
(搞不好 paper 的草稿都寫好了,只缺把資料補進去)。
NASA 舉辦這樣的活動,大概是打算挖出這些公開資料的剩餘價值。
每年都有一個主題。前五屆都是天文相關的主題,這屆則是地科相關。
所以很可惜我的背景知識能發揮的地方有限,
但相對其他組員我還是對衛星資料比較了解。
我們團隊共五個人,技能組成範圍蠻廣的,
軟/硬體、網頁前/後端、資料分析、手機 app、UI/UX/設計。
這個 hackathon 在資料處理/分析上有相當的門檻在。
相較一般 hackathon 在當日才公布題目,
NASA Hackathon 在宣佈舉辦時就公布了五大方向,
在賽前一個禮拜前公布題目,共25道題,大家挑自己喜歡的做。
門檻一是在於衛星資料不論種類還是數量都相當多,
而且資料格式不是熟知的 JSON、XML、CSV 等等而是 HDF5 或 netCDF4,
無法用一般工具讀。
二是就算能成功讀取,資料也不容易理解。
事實上在決選時,評審最常問的問題就是
「你做的應用,跟 NASA 的資料有什麼關係?」
或是
「用了哪些 NASA 的資料?」
我猜參賽者應該也不是不想用,而是不知道該怎麼用。
題目公布前我們做了一次 brainstorming,
公布後我很快的把題目都看過一遍並寫下 comment與可能的門檻。
我大致的想法是:
1. 防救災的不要碰。因為台灣因為環境因素,這方面的投入蠻大的,成果不錯,
也有startup 在做這方面了(例如究心科技)。
在一次 Hackathon 要找到之前被忽略的痛點其實不容易。
2. 生物方面的題目有趣,但如何利用衛星資料做出物種入侵、變遷的成果,
專業知識門檻實在太高。
經過這樣限縮範圍與反覆討論,最後我們打算太陽能的能源管理以及太空騎士兩者擇一。
太空騎士是要做一個服務,讓使用者像在搭乘人造衛星看地球。
如果只是這樣那也沒什麼意思,
但我們從另一個方向切入,希望盲人也能夠理解衛星影像的內容,
為盲人做衛星資料「視覺化」,這就很有創意跟挑戰了。
我們打算透過聽覺跟觸覺兩種方式讓盲人理解影像。
聽覺的部分也許可以用 machine learning 或 AI 把影像轉成文字,
再用 cognitive service 把文字轉為語音。
不過影像轉文字這段困難度不小,而且結果可能不靠譜,
所以我們借用 Be My Eyes 的想法,
打算做個 crowdsourcing 平台,
讓大家在上面能夠對每張衛星影像寫下描述/錄音/上tag/對描述給出評價
(把它當成字幕組就是了)
以補這部份的不足。
而且這些 labeled data 之後也可以拿來做 training。
觸覺的部分打算做出類似 MIT Media Lab 裡 Tangible Media Group
做出來的東西用來描繪衛星影像,讓盲人可以直接觸摸。
不過 crowdsourcing 的貢獻者需要看到影像,
所以仍然得做一個題目描述中的 web service。
所以仍然得做一個題目描述中的 web service。
至此我們的工作確定分為 web service 後端、前端、
crowdsourcing 平台、觸覺硬體四個部分。
我們也打算利用這次機會練兵,摸一下平常在工作沒機會碰的工具。
我們一來已經有 AWS 的經驗,再者也想玩一下 cognitive service,
所以這次試試 Microsoft Azure。但後來證明這是錯誤的策略。
我們一來已經有 AWS 的經驗,再者也想玩一下 cognitive service,
所以這次試試 Microsoft Azure。但後來證明這是錯誤的策略。
Hackathon 時間非常有限,使用不熟悉的工具那是挖坑給自己跳。
我們要做 web service 是確定的,
所以在一個禮拜前我打算把一個空的網路服務先架起來,到時候再改。
Azure 跟 AWS 差不多,也提供很多不同的服務。
一開始我試著用 web app 開 Django project,
一開始我試著用 web app 開 Django project,
web app 的好處是不用 host server,但試來試去都不成功,
連官方提供的 default 都有問題(還是 AWS 的 Elastic Beanstalk 比較靠譜)。
後來索性直接開 VM 自己架 nginx+uwsgi+django。
另一名夥伴直接用 visual studio deploy 到 Azure web app 就沒問題
(是排擠mac user嗎?)。
用 web app 的好處是它有提供 CI 的服務,只要把 code push 到 github,
deploy 的 service 就會自動更新。所以我們決定把 code push 到這位夥伴的 github。
我主要負責後端,任務是前端送衛星名稱跟時間,我就回傳衛星位置。
我主要負責後端,任務是前端送衛星名稱跟時間,我就回傳衛星位置。
這個工作分兩個階段,首先要撈到對應衛星跟時間的 two-line element (TLE)。
TLE 就是衛星的軌道資料,每日更新。其次是用軌道資料算任意時間的衛星位置。
這兩個部分我都有找到現成套件可以做,真的好棒棒!
TLE 就是衛星的軌道資料,每日更新。其次是用軌道資料算任意時間的衛星位置。
這兩個部分我都有找到現成套件可以做,真的好棒棒!
其實 hackathon 還沒開始前我就已經在 Jupyter 上把這段串好了,
接下來只要把整段 code 放到後台邏輯裡就好,能有什麼問題?
只能說雷總是埋在意想不到的地方。
2013年後官方提供 API 直接撈取 TLE。
但必須註冊為會員且登入後才能拿,同時一分鐘能送出的 request 上限是20次。
官方針對不同平台提供了不同方法去撈取 TLE。
Linux 平台可以用 curl 去撈,
但基本邏輯都是先登入拿到 cookie,再拿這個 cookie 去要 TLE。
試了沒有問題,但在 code 裡用 shell command 不符合我的美學,
於是我試著用 requests 套件模擬上述行為,
試了沒有問題,但在 code 裡用 shell command 不符合我的美學,
於是我試著用 requests 套件模擬上述行為,
但總是有問題,cookie 也確定有送。
後來找到專門拉 TLE 的套件,可喜可賀。
結果呢,我在 Django 的環境裡使用這個套件竟然有問題。
看了下 error message 竟然是 "there is no current event loop in thread xxx”。
奇怪,我只不過送個 http request,什麼時候開 thread 了?
看了一下 package 的 source code 才發現
原來它為了保證一分鐘送出去的 requests 不超過20次,
竟然用 asynchronous 的方法去送。
asynchronous 不易維護,bug不好找。
除非有 performance 的issue 不然通常我會避免使用。
沒辦法,只好寫個 python script 然後用 os.system() 去執行...
靠北喔,那這樣我一開始就用 curl 不就得了?!
總之這個問題是解決了,結果算軌道又出現錯誤,
原因竟然是找不到 TLE 檔,
總之這個問題是解決了,結果算軌道又出現錯誤,
原因竟然是找不到 TLE 檔,
但 error message 裡那個說是錯誤的路徑就是檔案路徑啊...
再看了下套件的 source code 發現它竟然把 file path 當成 url 送出去,
靠北那當然撈不到東西啊!
後來我也不想 debug,直接改 package source code(這是壞榜樣,好孩子不要學)。
別再雞婆幫我判斷是 file 還是 url,老子給你什麼,給我開就是了!
本來 web service 我打算用 django 後端/前端來做,
但前端想用自己慣用的工具開發,因此希望我開 API 出來。
合理,而且這是比較好的作法,但我沒做過 API 啊哈哈哈。
合理,而且這是比較好的作法,但我沒做過 API 啊哈哈哈。
其實我在公司本來也需要做 API,只是有其他事所以一直耽擱了,
既然如此那就立刻學立刻做吧!
孤狗大神說有個叫 Django REST framework 的套件不錯。
看了一下說明,它基本上就是提供一個 APIView 的 class,
只要改用 APIView 建後端邏輯,然後回傳時用套件提供的 Response 這樣就可以了。
一個從來沒開過 API 的人,
從開始孤狗到成功建起 API 只花了40分鐘,
python 開發速度真的超快!
後端邏輯跟 API 在 localhost 都建好了,用 postman 送 request 也撈的到資料,
接下來只要 deploy 到 Azure 上,正式的 API service 就完成囉~
But,經驗告訴我這關常會出問題,而很不幸地壞預感通常特別準。
deploy 失敗的原因也很妙,
But,經驗告訴我這關常會出問題,而很不幸地壞預感通常特別準。
deploy 失敗的原因也很妙,
竟然是 Azure web app 沒辦法安裝某個我需要的套件 Orz。
剛好家齊大大是 Microsoft 的技術顧問,趕快請他救援,
不過最後還是沒有成功。
只好退回 Plan B -- 用我開的 VM 架 API。
在 VM 上那個套件可以成功安裝,但我在 git pull 時似乎搞掉一個 config 檔...
好像是我把 *.conf 放在 .gitignore 裡但我不小心把 config 檔殺掉了所以也救不回來
那時頭很昏所以也不太確定究竟發生了什麼,
總之 Azure 上的 service 起不來了。
其實當初從開 VM、架 nginx、到 django web service 起來也只花了45分鐘,
但現在怎麼找都找不到 bug 在哪。崩潰啊!
最後沒辦法,只好在 localhost 架 API,
allowed host to all 行不行 ?!
cors origin allow to all 行不行 ?!
被逼急了,別說是狗,就算是豬也照樣翻牆給你看。
本來 web service 的規劃是用 OpenLayers/CartoDB 或其他工具在前端套衛星影像,
這樣的好處是只要按照以下的格式去要圖,
https://gibs.earthdata.nasa.gov/wmts/epsg{EPSG:Code}/best/{ProductName}/default/{Time}/{TileMatrixSet}/{ZoomLevel}/{TileRow}/{TileCol}.png
並把 ZoomLevel、TileRow、TileCol 留空如下例
https://gibs.earthdata.nasa.gov/wmts...9/GoogleMapsCompatible_Level6/{level}/{row}/{col}.png
如此便不需要指定完整 url,
這些工具可依照 user 的拖拉或縮放自動去撈對應的影像,
前端要做的工作就是把我給的衛星位置定為影像中心。
但後來前端想直接從 worldview 拉影像,
我們玩了一下發現 worldview 可以直接在影像上拉個框下載,
它其實是給一串網址,打開就是我們要的影像。
觀察了一下 url,發現包含了各種必要資訊像是衛星、時間、影像四角座標、大小等等。
那,自己隨意更改 url 的四角座標,能不能撈出影像?
發現竟然可以!太讚了!於是我跟前端立刻調整做法,
他一樣送衛星跟時間的 request 過來,
我直接回傳衛星在那個時間看到的影像四角座標(影像大小我自己先 hard code),
前端再拿這個資訊串成完整的 url 跟 NASA 去要影像。
後來實在太累就跑去主辦單位準備的房間躺在懶骨頭上睡覺,
而就在這段時間 crowdsourcing 平台竟然默默完成了!
是一個手機 app,點圖就可以錄下這張圖的敘述並上傳,太強了!
負責硬體的人也默默做了像下圖這樣的一個東西出來。
晚上看荷蘭人一直在切竹筷,原來要做這個。
竹筷下面有放一個泡綿,壓下去可以感覺到它的彈性。
每根竹筷的高度代表一個 pixel value,這樣就可以用摸的感覺一張圖。
看起來不太起眼,但摸起來感覺挺不錯的。
事實上就是因為這個裝置,活動結束後某個單位有來跟我們談,
說可以給我們一些資金,希望我們可以讓它的完成度更高一點。
隔天早上10點評審開始做初選,中午12點前必須結束工作。
說可以給我們一些資金,希望我們可以讓它的完成度更高一點。
隔天早上10點評審開始做初選,中午12點前必須結束工作。
初選每組只一分半介紹,很幸運我們有獲得評審青睞進入決選。
進入決選的組別輪流上台 pitch,每組四分鐘簡報,兩分鐘 Q&A。
我們 Pitch 不太順利,
影像其實有附上聲音但負責舞台的廠商不知道設定方面有什麼狀況,
總之聲音沒出來,
而且當時我跟前端其實還沒有整個串起來。
但 pitch 結束後仍持續努力,總算是在活動結束前完成。
在前端看到衛星影像時,實在是太感動了,總算是有圓滿結束(同時有燃燒殆盡)的感覺
感想:
感想:
1. 每次大會公布有食物補給結果去拿發現都被掃光了。
是誰跟我說 hackathon 會提供吃不完的食物的?給我出來面對!
2. 我總算知道這種活動為什麼叫 hackathon 了。
因為在時間壓力下根本無法以正常方式 coding,
只能不斷地 hacking 跟 work around,
hackathon 這名字實在太貼切了 XD
3. 寫 code 需要高度集中。當疲勞累積到一定程度時很容易出問題,
這種情況花再多時間 coding 都是做白工。效率至上。
4. Hackathon 看的主要不是完成度而是 concept。
5. 門面很重要,包括 pitching、簡報、前端。
6. 我的夥伴實在太棒了,大家都好專業,是最棒的夥伴!
能跟他們一起工作是我的榮幸。
--
學習,是不斷地知識解構再重建的一種過程
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.147.21.165
※ 文章代碼(AID): #1P29v0b- (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1493737024.A.97E.html
推 : 好棒!1F 05/02 23:11
推 : 感謝大大無私分享2F 05/02 23:58
推 : 食物真的很重要!3F 05/03 00:01
推 : 推分享4F 05/03 00:26
推 : 推5F 05/03 00:30
推 : 好強6F 05/03 01:18
推 : 推7F 05/03 01:25
推 : 推 很棒的分享8F 05/03 01:30
推 : 推9F 05/03 01:44
推 : 推~10F 05/03 02:15
推 : 好猛推11F 05/03 04:01
--
※ 看板: dinos 文章推薦值: 0 目前人氣: 0 累積人氣: 125
回列表(←)
分享