7/31/2017

快速且極低成本之AWS臉孔比對 - 利用AWS Lambda




AWS在2016年底釋出的圖片辨識服務(Rekognition)其實是非常非常昂貴。除了前5000次影像辨識不收費之外,接下來每一千次影像處理會收1美金。

乍看之下不多,但實務上,公開使用的影像辨識,通常無意中就暴增。


以之前LINE聊天機器人影像辨識為例,由於會當辨識到女性的照片時,會特別額外辨識內建的臉孔比對(40個亞洲女星照片)。等於是每收到一個女性照片,會進行42次臉孔辨識:40次照片比對+1次特徵比對+一次名人資料庫比對。就LINE聊天機器人數百的好友而言,該功能開放不到7天,就已經超過四萬次比對,換算價格約35美金。

35美金其實足以開啟維持t2.medium (EC2 VM)一整個月。這個VM甚至還有4G的記憶體。這樣的VM絕對能支撐每秒2-5次的臉孔比對,換言之,一整個月可以比對超過7百萬次。而這7百萬次也才略高於35美金。

然而,不應該因為成本的增加,就直接使用EC2 VM。而是應該考慮在符合serverless的架構下,如何解決這個問題。畢竟,當使用了VM,未來在擴增(scale-out)上也會有些麻煩。其實,我們目的很簡單清楚:只是要比對兩張臉孔的相似度。因此,應該使用輕量化Lambda即可。


原本做法

當使用者透過LINE上傳照片給聊天機器人之後,後端系統會執行下列事情:

(1) 先利用AWS Rekognition (detect)查詢基本臉孔資料,例如性別,年紀等等。

(2) 假如判斷是女性,就到AWS S3上選取所有要比對的臉孔,進行比對分析。在這裡,如果有40張臉孔,表示每一次上傳圖片,都要在這個階段額外送出40次分析。即便AWS允許先行儲存圖片特徵,但在比對階段仍然是看次數。

參考程式節錄如下:

    
    rclient = boto3.client('rekognition')
    s3 = boto3.resource('s3')
    bucket = s3.Bucket('sandyifamousface')

    for o in bucket.objects.all():

        #print(o.key)
        response = rclient.compare_faces(
            SourceImage={
                'Bytes': byteArray
        },
            TargetImage={
        
                'S3Object': {
                'Bucket': 'sandyifamousface',
                'Name': o.key,
            }
        },
            SimilarityThreshold = 60
        )
        if len(response['FaceMatches'] ) > 0:
            # DO things if match..



(3) 最後把判斷之後的結果,送回給LINE


改良做法

先將40張圖做臉孔分析,並且把特徵值Landmarks挑出來,儲存在檔案中。未來數量大的話當然可以存在dynamodb。

在這個範例是儲存於json文字檔中。

(1) 與上一段相同

(2) 在Lambda被載入 時,就先讀取文字檔,成為python的dictionary。原本要利用Rekognition做比對,改為使用自己寫的比對函數。在範例中,這個函數是利用landmark的相對距離變化,來判對臉孔相似與否。當然這樣的比對其實很粗糙,而且也沒有考慮臉孔的前側傾角度。不過,和aws本身所附帶的臉孔比對的結果其實已經很接近。

參考程式節錄如下:
def compareLandMark(landmarkList1, landmarkList2):
    distList = []
    compareList = [
                   ('eyeRight','nose') ,
                   ('eyeLeft','nose'),
                   ('mouthLeft','nose'),
                   ('mouthRight','nose'),
                   ('mouthUp','mouthDown'),
                   ('mouthLeft','mouthDown'),
                   ('mouthRight','mouthDown'),
                   ('noseRight','eyeRight'),
                   ('leftPupil','rightPupil'),
                   ('nose','rightPupil'),
                   ('leftPupil','nose'),
                   ('noseRight','noseLeft'),
                   ('eyeRight','eyeLeft') ,
                   ('mouthRight','mouthLeft') ,
                   ('mouthRight','eyeRight') ,
                   ('mouthLeft','eyeRight') ,
                   ('mouthRight','eyeLeft') ,
                  ]

    for (m1,m2) in compareList:
        d1 = getDistanceFromType(landmarkList1, m1, m2)
        d2 = getDistanceFromType(landmarkList2, m1, m2)
        distance = (abs(d1-d2)/d1)
        distList.append(distance)


    lenD = len(distList)
    mD = statistics.mean(distList)
    # stdev and variance could be used in the future.
    mStd = statistics.stdev(distList)
    mV = statistics.variance(distList)
    conf = (1-mD)**2
    return conf*100




(3) 最後把判斷之後的結果,送回給LINE

結果:

在Lambda自行撰寫比對程式,但是其實是利用AWS Rekognition 所給出的landmark (特徵),會讓比對變得簡單而且成本很低。

缺點是,這樣的比對準確度和如何計算特徵有很大的關係。



* 關於LINE聊天機器人,請參考這篇
* 專案程式碼放在這裡
* google的vision api其實價格更貴,請參考這裡




7/26/2017

聊天機器人 - 快速製作在LINE上的人臉辨識應用

名人以及圖片分析 在和LINE聊天機器人之對話中


 聊天機器人(chatbot)作為人機介面,提供人類各種整合性服務是最容易產生的應用。而人臉辨識,一直都是人工智慧與數據分析的整合課題。因此,把LINE聊天機器人加上照片或人臉辨識的功能,似乎也很有趣。
用LINE QR 加小姍為好友 可以測試人臉辨識

以前,在做關於影像的實驗性質的程式時,通常會先考慮opencv。雖然opencv確實是個好工具,但是如果你的目標不是改善演算法,或甚至做出更先進的人臉辨識方式,那麼opencv會過於複雜。

在2016年底,AWS發表另一個雲端服務:Rekognition。這個服務提供了API用以辨識影像,並順便提供了幾個在應用上的api:「比較人臉」「辨別名人」「識別限制級圖案」。(文件請參考這裡)

這些api要運用的最簡單方式之一,就是使用AWS Lambda來驅動AWS內自己的API,再透過API Gateway跟外界 - 也就是chatbot整合。換言之,這仍然符合公有雲廠商(無論是AWS, google還是azure)的所謂serverless的未來方向。雖然這些公有雲廠商,其實只是為了讓客戶更難離開公有雲環境,但不可否認的是,這些api的確有用而且在初期成本也不高。

快速製作在LINE上的人臉辨識,需要幾個步驟:


(1) 對serverless的設計概念有些瞭解


請參考這裡這裡


(2) 對Line聊天機器人申請和製作,以及對AWS Lambda先有基本的瞭解。


可參考這裡這裡


(3) 在LINE webhook的event中處理image id。


在webhook的lambda程式中,特別挑出image的id。LINE的訊息傳遞給chatbot時,有分不同的type,要處理的是image type。LINE並不會真的傳圖片檔案到webhook中,他傳遞的是圖片id,透過這個id,可以用一個URL拿到圖片:


https://api.line.me/v2/bot/message/<id>/content

要取得這個圖片,當然要有Line token


(4) 讀取圖片URL並且以取得bytes


以python為例,首先以requests讀取URL,記得stream必須設為True,因為接下來需要將資料(影像的byte)直接讀取成bytearray。參考程式如下


    imageUrl = 'https://api.line.me/v2/bot/message/{}/content'.format(imageId)
    r = requests.get(imageUrl, headers=headers, stream=True)
    bArray = None
    with r.raw as data:
        f = data.read()

        bArray = bytearray(f)


(5) 使用各種AWS的Rekognition服務。

取得bytearray之後,剩下的事情就很簡單了。
以python為例,可以使用boto3 (最好是1.4.4版本)。先取得rekognition的client物件,直接使用裡面的方法(例如以下範例)。將Image參數都設定成{ 'Bytes': your_byte_array} 就可以取得分析的結果。


    rclient = boto3.client('rekognition')
    response = rclient.recognize_celebrities(
        Image = { 'Bytes':bArray }
    )

要注意的是,分析結果response是一個含有各種標籤與技術數值(例如信心程度)的dictionary物件,所有的標籤都還是英文,必須得自己轉換成中文才行。

範例中的「名人辨識」(celebrities)所查到的名字都是英文。可以利用wiki 英文api搜尋這個英文字,找到對應的中文網頁,在取得中文字。

wiki的英文api可參考這裡

(6) 存取S3之考量


如果看過AWS document應該會發現,使用recognize都可以設定image來源是S3。那麼範例為何不存取S3? 

事實上,的確可以將LINE的影像,先存在S3,然後再進行分析。然而,這樣會多了「存入」S3和取出S3的時間。並且,S3也是要收費的!影像如果只「分析一次」,那麼存在S3其實很不划算,存在Rekognition裡面更是貴。如果會反覆利用,那麼恐怕還是得存在S3中。



目前結果分享


用LINE將小姍加入好友,就可以試用一下目前LINE與AWS人臉辨識整合。


加小姍為好友 ID-> @opn2514f

加小姍為好友 Add Friend


下圖是辨識川普不同的表情,會被辨識出不同的年紀,和不同的心情。




7/18/2017

二氧化碳監測與Raspberry PI


Raspberry PI 或稱樹莓派,是最近幾年蠻有名的微型單版機電腦。最新版本(RPi 3)仍然是約略名片大小,但擁有1G RAM 加上 64bit ARMv8使它能做的事情已經和一般的PC沒有太大的不同。

這對純軟體工程師來說,是一個很容易介入IOT硬體的開始。早期,需要嵌入式系統(Embedded System)或者對各類硬體輸出入有一定了解,才能做一些有趣的應用,而現在由於RPi的關係,讓這些應用的門檻降的非常低。

因為RPi已經可以運行各類Linux Distribution,FreeBSD 甚至Windows10。讓軟體工程師可以直接撰寫有趣的應用程式,降低考慮硬體的問題。

不過,「降低」並不代表完全不需要考慮硬體問題。實際上很多市面上的硬體零件,其規格和輸出入方式各有不同,還是得有基本了解或者「取得範例」,才能達到想要的效果。

以市面上容易買到的「攀藤CO2模組」為例,它的文件相當的「精簡」,也沒有任何範例程式,因此需要自己想像一下官方文件到底在說什麼。

想跳過以下冗長說明的,可以直接看這個python範例

官方文件提及這個模組式需要用標準序列埠Serial Port連結。因此可以想像就是把Raspberry TX/RX 和這個硬體的 RX/TX對接,並且硬體需要5v的電,也要接到Raspberry的5V輸出以及接地,因此就是4, 6, 8, 10這四個pin腳。

接上之後,需要送出指令,這個模組才會運作。根據中文官方文件,你需要知道指令,以及把指令組合成7個bytes然後送出。

但是其實,這個裝置也只有一個指令,也就是0xe3,上面述的DATAH, DATAL其實是填0,而不是如同文件上「打X」。由於只有一個指令,所以校正數字當然就一定也只有一個可能。簡單的說,其實只要(而且也只能)送出以下資料到serial port即可:

[ 0x42, 0x4d, 0xe3, 0x00, 0x00, 1, 114]
#python 範例程式節錄 送出serial port
ser = serial.Serial("/dev/ttyAMA0", 9600)
init_cmd =[ 0x42, 0x4d, 0xe3, 0x00, 0x00, 1, 114]
for c in init_cmd:
     ser.write(chr(c))



上述程式在RPi中會預設serial port已經不作為TTY (終端機)使用,因此才能直接對/dev/ttyAMA0執行輸出入。由於RPi預設serial port(8,10)式作為終端機使用,因此請記得disable它,並且重開機。

接下來,根據文件的內容,需要接收(讀取)一個12個bytes的資料,資料內容也都是固定,真正有意義的是第五和第六個byte,這兩個byte應該組合成一個數字。這個裝置最好的地方在於,它的數字已經是CO2的PPM值,這比某些其他公司的裝置還需要用各種方式換算方便許多。

兩個bytes組成一個數字的方式很多,例如可以把第一個位數利用 << 位移8,然後加上第二的位數。當然也可以把第一個位數*256加上第二個位數。

#python 範例程式部分節錄
 while True:
     count = ser.inWaiting()
     if count >= 12:
         recv = ser.read(count)
         h8 = recv[4]
         l8 = recv[5]
         print(str(ord(h8)*256 + ord(l8))+" PPM,")


最終結果就是,會有個Raspberry PI可以監視並且告知附近環境的CO2含量。
在辦公室監視一整天的結果非常明顯,上班前的CO2含量比較低,人越多的時候CO2含量會快速增加。連續兩日,都是在每日下午5點到達最高峰,接下來逐漸下降至隔天開始上班為止。





7/12/2017

Serverless design for IoT - An example leverage AWS and GrovePi



AWS announced IOT service in about 2015 and gradually release other relative service (for example: IoT Button) for those who need to tackle with the problem on huge amount of increasing response of "The Things". And it is of course the area which cloud provider what to provide a optional solution.

To demonstrate the benefits of leveraging the serverless design and also utilize the power of AWS cloud. I build an example project combines Serverless design, AWS IoT, Respberry Pi, Grove Sensor system and GrovePI. It will provide in door air quality (office) for me if I want to know that before entering office. So that I can have an excuse to work from somewhere else? :)

In this example, a GrovePi mounts in Raspberry Pi (B+) to control Grove's Air Quality Sensor, HCHO sensor and dust sensor. As a software engineer, I assembled all these inside a paper box. See picture below.

RPi and GrovePi are inside the box. 3 sensors are out there.




Reminder: to use AWS service, the most important things is to read official document. AWS has many different services and there are too many out-of-date articles in somebody's blog. It doesn't mean that authors were wrong, it is just out-of-date. Of course, it is the same in Raspberry Pi and all other 3rd party open source library, try to read official document (or official wiki/blog) to have overall view.

The full implementation and design concerns 


(please check all the project detail in github)

(1) Grove's 3 sensors + GrovePi + Raspberry Pi

   The hardware parts. Check GrovePi's official web site to know how to put them together.

    GrovePi might be the easiest way to program Grove's system from Raspberry Pi, if you have more then 2 device in a machine. However, if you have only one sensor, then just use RPi's GPIO.

(2) AWS IoT service

   Although we didn't program anything in side the hardware, we still need to setup things in AWS IoT service. And of course, it will be better to read at least the tutorial.

Screenshot of AWS IoT Tutorial
   AWS IoT pricing model is counting by message (512bytes). At this moment, about $5 per million message. Which means about $5 per 500MB! This is much more expensive than own a EC2 service to serve device message. However, if you don't need to keep all monitoring data transit in AWS every few seconds and you need only monitoring state changes (maybe a few times per day) then a "Device Shadows" is the best for you.

   In this example, we register a "Thing" named: InDoorSensor1 and the most important thing is to have default Shadow Object as below:
{
  "desired": {
    "welcome": "aws-iot",
    "air quality": 43,
    "action": "wait"
  },
  "reported": {
    "welcome": "aws-iot",
    "action": "wait",
    "air quality": 43
  }
}

   The device will keep sync the Shadow in AWS and if the desired state change to "do", it will (a) do a one time air sensor data collection and then (b) update air quality in Shadow object (c) change to "wait" state. In sort, the Shadow and Device will sync the state (wait or do) and the state's sync is the major function provide from AWS.


(3) AWS IoT Python SDK + GrovePi Python library

AWS provides a few SDK for device, in this project, we use Python to do AWS Cloud access (no matter notification or change Shadow state)

In the Raspberry PI B+, you need to:

    (a) install AWSIoTPythonSDK
    # pip install AWSIoTPythonSDK  (also see here)

    (b) consider the protocol (MQTT vs Websocket). In some environment, the MQTT port might be block. AWS SDK provides MQTT via WebSocket which of course allow broker use port 443.

    (c) certificates: please do read AWS IoT Certificate document if you didn't have experience before

If you use Raspberry PI version B+ 2 or 3, then it will be easy to install nodejs/npm and all other fancy stuff.


(4) IoT Shadow


    The Shadow means an identify object of IoT device. This allows client to change the state of a object and then sync to IoT device. In certain scenario, it allows programmer no need to take care of network error handling or any off line case. However, you still need to fully understand what means exactly the "desired" and "reported" state.
   It is possible to edit Shadow state from AWS admin console direct for testing purpose. (you won't want to do so if you have thousands IoT device).



(5) Lambda, API Gateway


    Supposedly, an application will NOT access specific IoT device, it normally access a service and that service provides information or allow meaningful user actions.
    In this case, a lambda service is simple a python program which can (1) retrieve current state and also current air quality value (2) update state to "do". And as always, the Lambda is behind an API Gateway and which means, potentially, all other application could use this API to access necessary (filtered) information.

see the activity hand draw:



Next Project

Hopefully, I can have more budget to purchase Raspberry PI 3 and also CO2 sensor and then also gather data to draw graphic in D3. Also, I am thinking to use LINE to send air quality information to my colleague or neighborhood. 



7/08/2017

企業巫醫 - 得罪老闆怎麼辦 (人際關係的過度重視)



得罪老闆(直屬主管)怎麼辦?

眾多企業巫醫都有不同的說法:

某一類型的企業巫醫以案例和經驗強調「如何不得罪老闆」,試圖就源頭解決問題。然而,大部分的作法,都是為了造就謹言慎行的員工。例如「得罪老闆的六宗罪」「別惹十種人」「與主管相處之道」「職場人緣學七招」。這些說的都沒錯,然而 - 除非是在超大型組織或者公家機關 - 職業生涯的發展,大部分還是取決於能力與實質貢獻,有效溝通與人際關係是其中重要的一環,而非全部。

有很多企業巫醫都會引用這段不實謠言「卡內基美隆大學曾針對畢業的 200 位傑出校友進行一份問卷調查,結果發現,成功的重要因素裡,其中85%來自一個人的態度包括自信、熱忱、領導、溝通以及人際關係的能力,另外的15%才是專業知識。」作為開場白,似乎再再強調人際關係的重要。更隱含著,只要有好的人際關係,就解決了85%的問題。

隨意引用未經實證的事情,是企業巫醫的共同特徵。就如同在部落驅邪一樣,告訴群眾,根據某某以前的巫醫說法,現在就是獻祭品用樹枝鞭打驅邪治病的好時機。

大概也是這個問題太典型,可是真實研究內容又和各企業巫醫所引用的有所出入。因而,卡內基大學的官方Q&A只列出問題,但是並沒有直接說明答案,只說這是1918年某期刊登載之研究,但是太久之前了,請自己去圖書館找(參考這裡)。

在此特別感謝google的paper search 學術搜尋,很快的根據年份跟名稱,找到該研究發表的地方(參考這裡,請直接看106至108頁) 


實際情況是:



(1) 該研究並非針對200個傑出校友,甚至根本也不是針對特定學校的校友。研究對象為美國工程師,實際樣本超過7000人。

(2) 該研究,是以問卷形式,將因素是工程師升遷的重要條件分成六組(Character, Judgment, Efficiency, Understanding of Men, Knowledge, Technique)。結果,認為Character人格特質那組條件,是升遷第一重要依據的人數,是其他組的七倍。 眾多企業巫醫所引用85%,應該引用此依據,再經過時間以訛傳訛的結果。

(3) 該研究開宗明義的指出在1900前後,美國的工程師教育問題,認為過於著重技術教育,而在工程教育體系缺乏對人格特質的強化。然而!該研究的人格特質定義乃是指

common sense, integrity, resourcefulness, initiative, tact, thoroughness, accuracy, efficiency, and understanding of men 」(註1)

光看字眼,也能夠體會到1918年 - 畢竟已經快100年前 - 和今日一般企業巫醫所指的「人際關係」有很大差異。例如:完整,正確,有效率,在現代社會通常是技術的一環,而較少列入人格特質的一環。

過度強調「職場成功85%要靠人際關係」就會讓「得罪老闆該怎麼辦」變成落在自己身上最痛苦的事情。因為,得罪老闆之後就會有「已經失敗了85%」的不實感受。

那麼,已經得罪老闆之後該怎麼辦?和處理問題的基本「事實三步驟」一樣:


(1) 確立事實



(a) 你的市場價值有多少?

必須要取得客觀的事實,而非自己心裡的感想。每個人都認為自己對組織可以產生很多價值,但事實上可能不然。最簡單的方式就是「試著去面試找工作」。在此m,並非鼓勵以換工作解決問題,而是以「測試自己的市場價值」來決定個人價值。如果在3-4個月內,無法找到比現在工作整體薪資高出10%的工作,那麼其實你現在在組織內部的價值是被高估。


其實不管有沒有得罪老闆,只要你受僱者,不是自己開公司當老闆,就應該要確定自己的市場價值。這是最重要最重要最重要,需要知道的事實。也是最大唯一根據。

(b) 得罪的原因是做了錯事,還是只是個性不合接連產生誤解,還是遇到一個糟糕的老闆?

也很有可能你永遠無法知道原因,不過如果有機會知道會比較好。

(c) 職業生涯的目標

(d) 對老闆的依賴程度

(e)...還有很多其他事實






(2) 建立選項


得罪老闆既然為既定事實,就要考慮「應該怎麼做」的選項。在完全被動情況下,人會有無限的壓力,選擇的權力讓有掌控感(不過太多選項也是壓力,參考 註2)。

無論如何,至少給自己產生3個應變選項,以下是一些選項參考。了解或者建立選項,並非一定要做,而是要給自己「清楚可見」的選擇機會。


(a) 不動作


每人都有機會得罪老闆,你不見得是唯一,也不見得是最重要的。不動作指的是不把它當一回事,繼續做好你該做的工作,繼續學習成長。


(b) 大幅提昇績效


如果你的工作績效清楚可見:要注意的是,清楚可見是指「其他人清楚可見」而非自己認為。那麼得罪老闆也並不是很重要的事情,因為你對組織的貢獻的本身,並不會得罪任何人。大幅提昇績效是可行的選項,不過前提是你「做得到才行」。既然你已經看到這篇文章,大概就隱含著這個選項短時間做不到。


(c) 組織內換部門


很多時候,你只是和老闆個性不合八字不合,在大組織內換個部門並非壞事。


(d) 換工作

換工作和內部轉移不太一樣。你必須把換工作當做「自己的選項」而非被動的選項。並且,不要欺騙自己。

有些人是在沒其他選擇的情況下,自己欺騙自己說「其實是我想換做工作」,這容易去找到一個勉強而不見得是自己喜歡的工作。換工作的選項在於,先確定自我價值,知道自己換工作可能犧牲的成本代價,然後視為眾多選項之一。當最後真的執行換工作選項時,在時間上和心態上就有很大的差距。



(e) 建立新技能範圍


自己開公司也屬於這個範圍。換言之,在維持現有工作績效的情況下,額外花時間開創可能性。

以資訊科技來說,主動舉辦workshop,參與opensource專案都可能是建立新技能範圍。然而,那怕是去取得水匠電工丙級執照也都是建立新技能範圍。(不建議直銷保險之類的工作)


(3) 執行選項


即便「不動作」,也是需要認知與執行。執行上有一些要件。

(a) 速度:除了不動作之外,其他的選項在「已經得罪老闆」的情況下,應該是要越快建立越好

越快能建立選項,表示自己掌握了「時間」。不掌握時間的人,就容易被動的被時間掌握。當你覺得每天忙碌不堪,似乎被事情追著跑的時候,表示你需要先改善自己的時間掌握能力。

(b) 建立回饋方式:任何要執行的事項,必須要有自我檢查的方式確定執行的結果是否和預期一樣。因為執行結果有差異的時候,應該「儘速修正」。

(c) 符合最終目的:當得罪老闆這件事發生的時候,你的目的到底是什麼?

你希望「已經獲得老闆原諒了?」
還是「得罪這個老闆已經沒關係了?」
還是「得罪老闆所產生的後果已經最小化」
還是「....」

執行任何解決方式,必須要符合你本來的目的。這目的當然只有你需要知道,而不需讓那些無法幫你解決任何事情的巫醫當作他的「研究個案」或者「參考範例」使用。



參考文章:換工作的面試-軟體工程師如何展現價值


註1 :節錄原文描述人格特質的「項目」,徵求比較好的翻譯
註2:然而,有許多研究顯示太多選擇也反而造成壓力,請參考這裡