支援虛實互動展演之程式環境 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National Chengchi University. 碩士論文 Master's Thesis. 立. 政治大. ‧ 國. 學. 支援虛實互動展演之程式環境. Programming Support for Cyber-Physical Interactive. ‧. Performance Art. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 研究生：蕭奕凱指導教授：陳恭. 中華民國 104 年八月 August 2015.

(2) 支援虛實互動展演之程式環境 Programming Support for Cyber-Physical Interactive Performance Art. 研究生：蕭奕凱. Student：Yi-Kai Hsiao. 指導教授：陳恭. Advisor：Kung Chen. 資訊科學系. Nat. y. ‧. 碩士論文. 學. ‧ 國. 立. 政治大國立政治大學. n. er. io. sit. A Thesis Submitted to Department of Computer Science a l Chengchi University v National i n Ch in partial fulfillment i U e n g cofhRequirements for the degree of Master in Computer Science. 中華民國 104 年八月 August 2015.

(3) 支援虛實互動展演之程式環境論文摘要本研究係發想自政治大學「未來馬戲團」的展演活動表演方式，嘗詴改進表演方式中的程式技術，以程式化方式整合展演藝術中實體與虛擬的互動平台，我們希望提供導演撰寫較為口語或展演描述方式的腳本敘述如『when ... otherwise ...』，如此一來就可以任意組合實體演員的肢體動作與指示虛擬環境的特效，因此我們採用了一套介接實體與虛擬環境應用程式的領域專屬語言- Digital In-. 政治大. teractive Performance Sketch (DIPS)，用以開發客製化的展演程式庫，並佈署於本. 立. 團隊自行開發的執行引擎 Wearable Item Service runtimE (WISE)，提供導演在這. ‧ 國. 學. 個引擎上透過這個 DIPS 編寫前述口語的程式腳本，讓程式自行互動，達成展演. ‧. 效果的自動變化。. sit. y. Nat. 我們的系統會接收來自展演人員穿配的連網感應器上的訊號，並且根據導演. io. al. er. 寫好的腳本規則，自動根據接收到的裝置訊號判斷出該指示虛擬環境做出什麼樣. v. n. 的效果，以達到展演效果自動變化，完成虛擬與實體展互動的程式支援。. Ch. engchi. i n U. 為了減少腳本程式撰寫前頇具備的程式邏輯訓練，本研究開發一款所見即所得(WYSIWYG)的視覺化腳本編輯器 DIPS Creator，提供腳本編寫者可以直覺的方式組合編輯器中的展演詞彙方塊，完成腳本設計。本研究展示了如何以較為口語或展演語意的方式敘述展演規則，以實現虛實互動的程式化，並且提供了具更彈性的客製化展演函式庫及圖形化展演規則編輯器的製作方式，未來可增加多演員層次的抽象支援以展現本研究系統的更多程式化能力，並加入表演階段設計、雙向溝通與規則互斥等能力，擴充系統功能。關鍵字：展演藝術, 虛實互動, 程式支援, 領域專屬語言, 所見即所得編輯器.

(4) Programming Support for Cyber-Physical Interactive Performance Art Abstract This research was inspired by “The Future Circus”, a cyber-physical interactive performance art developed in National Chengchi University. In this thesis, we propose some mechanisms to support such performance art programmatically in a more effective manner. Specially, we provide a high-level scripting tool for directors to describe the performance rules abstractly in the form of “when ... otherwise ...”, so that directors can compose arbitrary actions and effects easily. Underlying such abstract rules are a domain specific language – Digital Interactive Performance Sketch (DIPS), and. 政治大. a middleware. Wearable Item Service runtime (WISE), developed by our research. 立. team.. Given a script with those abstract rules, our system will receive signals sent from. ‧ 國. 學. a sensor on wearable devices of actors, and then it will command cyber environment perform effects, the performance effects or actions according to rules written by the. ‧. director. Through our integration efforts, the performance effects in the cyber environment will change automatically in a programmatic way. Besides, for users without. y. Nat. sit. prior scripting experience, we developed a WYSIWYG GUI editor, DIPS Creator,. er. al. n. blocks.. io. that allows users to write a script intuitively by dragging and dropping pre-built rule. Ch. i n U. v. We conduct a few experiments with real sensor device to demonstrate the pro-. engchi. gramming support of our tool. The preliminary results are satisfactory in terms of prototype support. To further extend our tool for practical performance, we describe in detail a few directions such as support for multiple actor performance stage modeling, and integrity check of related rules that will make our system more powerful.. Keyword：performance art, cyber-physical interactive, programming support, domain specific language, WYSIWYW editor.

(5) 目錄第一章緒論 .................................................................. 1 1-1 研究背景 ................................................................................................................... 1 1-2 研究動機與目的 ....................................................................................................... 4 1-3 研究成果 ................................................................................................................... 6 1-4 研究限制 ................................................................................................................... 7 1-5 論文大綱 ................................................................................................................... 8. 第二章相關研究 ........................................................ 10. 政治大. 2-1 Programming Support of Performance Art ................................................................. 10. 立. 2-2 Domain Specific Language ....................................................................................... 11. ‧ 國. 學. 2-3 Functional Reactive Programming ............................................................................ 13 2-4 Message Queue Telemetry Transport ......................................................................... 15 2-5 Scala ......................................................................................................................... 16. ‧. 2-6 Unity 3D ................................................................................................................... 18. y. Nat. 2-7 Phidgets Sensor......................................................................................................... 19. er. io. sit. 2-8 WYSIWYG Editor .................................................................................................... 21. n. 第三章系統設計a ........................................................ 22 v. i l C n hengchi U 3-1 採用之 DIPS 語言設計研究................................................................................... 22 3-1-1 架構 .................................................................................................................. 24. 3-1-2 Signal ................................................................................................................ 25 3-1-3 Rule................................................................................................................... 25 3-1-4 Syntax ............................................................................................................... 26 3-1-5 Device ............................................................................................................... 27 3-2 函數式程式設計用於抽象化時間........................................................................... 28 3-3 系統架構 ................................................................................................................. 31 3-4 裝置與腳本引擎溝通 .............................................................................................. 34 3-5 展演腳本函式庫 ...................................................................................................... 35 3-6 圖形化編輯器 - DIPS Creator ................................................................................ 39.

(6) 第四章研究結果 ........................................................ 41 4-1 系統整合 .................................................................................................................. 41 4-2 系統測詴 .................................................................................................................. 41 4-3 系統測詴結果 ......................................................................................................... 49. 第五章結論與未來工作 ............................................ 51 5-1 結論與研究貢獻 ..................................................................................................... 51 5-2 未來研究方向 ......................................................................................................... 53. 參考文獻 ...................................................................... 57. 政治大附錄 .............................................................................. 60 立. ‧ 國. 學. 附錄一 .................................................................................................................................60 附錄二 .................................................................................................................................63 附錄三 .................................................................................................................................64. ‧. 附錄四 .................................................................................................................................65. y. Nat. 附錄五 .................................................................................................................................67. sit. 附錄六 .................................................................................................................................72. al. er. io. 附錄七................................................................................................................................. 73. n. v i n Ch 附錄九 ........................................................................................................................... 75 engchi U 附錄十 ........................................................................................................................... 76 附錄八.................................................................................................................................74. 附錄十一 ........................................................................................................................ 78.

(7) 圖目錄圖一未來馬戲團………………………………………………………….………….1 圖二 WISE 系統接收肢體感應器訊號與轉送至 Unity 3D 動畫程式...................2 圖三演員身上穿配感應器..........................................................................................2 圖四演員骨架對應至虛擬裝置..................................................................................3 圖五演員骨架對應至虛擬動物肢體..........................................................................3 圖六 Impromptu 整合開發環境 ...............................................................................10. 政治大圖八 1056_0 - PhidgetSpatial 立 3/3/3 感應器..............................................................20. 圖七 Unity 透過 Mono 編輯器撰寫腳本...................................................................18. ‧ 國. 學. 圖九 WYSIWYG Editor.............................................................................................21 圖十 DIPS Core Architecture.....................................................................................24. ‧. 圖十一系統架構概觀................................................................................................31. y. Nat. io. sit. 圖十二整合平台運作圖............................................................................................32. al. er. 圖十三異質裝置連接與存取與舞台空間裝置之互通性........................................33. n. v i n 圖十四使用 DIPS DSL 及 WISE C 平台來解決數位互動展演系統所面臨的挑戰...33 hengchi U 圖十五 MQTT 通訊模型...........................................................................................34. 圖十六一個最簡單的腳本........................................................................................36 圖十七 MIT Scratch....................................................................................................39 圖十八 Google Blocky................................................................................................40 圖十九 DIPS Creator .................................................................................................40 圖二十 Left hand up, elephant nose raise...................................................................43 圖二十一 Right hand up, elephant body raise............................................................44 圖二十二 Left and right hand up meanwhile, light on...............................................45.

(8) 圖二十三大象鼻子舉起的更限狀態........................................................................47. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(9) 第一章緒論研究背景. 1-1. 本研究係發想自政治大學未來馬戲團[1]的展演活動，展演內容為由扮演馬戲團團員的實體演員，與 Unity 3D1 動畫程式模擬出來之虛擬環境中的動物角色互動。. 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. al. n. v i n Ch 圖一：未來馬戲團(圖片來源：科技部穿戴式計畫成果報告影片) engchi U 目前該馬戲團使用了Xsens2 MVN motion-capture3 技術，讓躲在布幕後的演員穿戴裝置，再透過捕捉該演員的肢體動作，交由導演控制台(director's console) 以即時運算技術與虛擬角色互動，除了採用 Xsens 的感應器技術捕捉演員的骨架，該馬戲團同時也採用了本 WISE 團隊用陀螺儀實作的 motion-capture 技術，將接收自演員身體骨架上的各個感應器的名稱與座標值對應(mapping)到 Unity. 1 2 3. Unity 3D 是由 Unity Technologies 所開發的一套遊戲引擎(game engine)。 Xsens, https://www.xsens.com/ motion-capture 是透過攝影或是感應器傳遞來捕捉肢體骨架資訊的技術 1.

(10) 3D 中角色的骨架，或虛擬物體的指定位置，以即時同步虛擬角色的動作，並且可以與其他虛擬角色互動或產生虛擬場景的特效變化。. 立. 政治大. ‧ 國. 學. 圖二：WISE 系統接收肢體感應器訊號與轉送至 Unity 3D 動畫程式(圖片來源：. ‧. 科技部穿戴式計畫成果報告影片). n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖三：演員身上穿配感應器(圖片來源：科技部穿戴式計畫成果報告影片) 例如圖四中，當演員的手擺動，Unity 3D 中的虛擬鎖鏈就會隨著舞者的手擺動，表演中魔術師便是以此方式控制鎖鍊，來與虛擬角色互動，另如圖五中的 2.

(11) 應用方式，就是直接對應演員的身體骨架至虛擬的大象身上，以演員的右手模擬大象的鼻子，如此當演員擺動右手，大象的鼻子就會跟著擺動。. 立. 政治大. ‧ 國. 學. 圖四：演員骨架對應至虛擬裝置(圖片來源：科技部穿戴式計畫成果報告影片). ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖五：演員骨架對應至虛擬動物肢體(圖片來源：科技部穿戴式計畫成果報告影片). 3.

(12) 研究動機與目的. 1-2. 我們發現，以現行透過骨架對應的方式，雖然可以達到透過實體操作虛擬的互動目標，但這樣的方式會限制演員肢體變化與虛擬角色的互動多元性，亦即在目前的方式中，只能實作出讓虛擬角色的肢體跟著實體演員肢體變化，像是演員的手擺動，大象鼻子跟著擺動，但是我們認為可以透過改變實體與虛擬角色的骨架資料繫結方式，讓實體演員的肢體變化與虛擬環境的角色或場景可以更更多互動，例如我們可以將演員手部的座標或角度變化，包裝成一個『手的狀態』，藉由檢查這個手的狀態變化，我們可以指示大象做出鼻子舉起的動作，甚至可以同. 治政大 motion-capture 應用時伴隨指示燈光亮起來，這在原本僅透過骨架位置對應的立. 是無法達成的，因為骨架對應的程式需要逐一將實體與虛擬的骨架對應位置寫死，. ‧ 國. 學. 但我們提出的方法可以很彈性的改變實體骨架位置對應到虛擬環境中的效果，不. ‧. 一定要讓手舉起對應到大象鼻子舉起，可以很快速的改變手舉起要對應的其他動. n. al. when ( leftHandUp ) {. Ch. noseRaise. engchi. sit er. io. 我們希望導演只需要在程式中撰寫如：. y. Nat. 作或特效，不侷限於虛擬角色的骨架對應。. i n U. v. } otherwise { noseLay } 這樣簡單且接近口語的規則，就可以讓程式根據收到的演員左手狀態，指示虛擬大象鼻子的舉起或放下，而且導演也可以輕易且快速的修改規則中 leftHand 對應的動作為 lightOn 或其他動作或特效，或是修改 when 中的條件，並且快速的重新執行規則進行測詴。 4.

(13) 現行馬戲團採用虛擬動畫技術 Unity 3D 已經可以透過編寫腳本程式達到程式化的功能，為求跨平台且獨立於微軟公司，Unity 公司採用執行於 Mono Common Language Runtime 上的 C# 程式語言做為其程式開發的主要語言之一，然而 C# 缺乏針對展演領域的語意程式庫，如果提供腳本撰寫者學習 C#，學習門檻較高，為了讓非程式設計專業背景的使用者也可以採用撰寫簡單的宣告敘述來實作角本，我們希望透過採用一款展演的領域專屬語言[16]，設計客製化的展演程式庫，讓導演等腳本撰寫者可以透過編寫較為口語或具更展演語意的程式碼，達到展演虛實互動的程式化，為此我們開發了一個平台，該平台佈署更前述展演. 治政大之領域專屬語言的執行環境，可以運行導演所撰寫的腳本，來完成我們預期的目立標。. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 5. i n U. v.

(14) 1-3 研究成果本研究展示了如何以較為口語或接近展演語意的方式敘述展演規則，以實現虛實互動的程式化，並利用抽象化表達的方式整合了虛擬與實體平台的互動，展示了如何以較為語意的方式描述展演動作，為客製化展演腳本函式庫提供了範例，我們亦展現了在實作領域函式庫時，資料格式與語言擴充彈性的保留方式，以及在設計平台整合測詴腳本過程中，如何透過此展演領域專屬語言來處理感測器敏感變動的訊號值與自動校準問題，為未來設計訊號與裝置狀態對應提出了參考。. 治政大此外，為提供使用者（例如導演或編劇）可以更更直觀的編輯介面，降低程立. 式語言邏輯學習的障礙，我們開發了一款圖形化編輯軟體 DIPS Creator，將. ‧ 國. 學. DIPS 腳本設計的展演詞彙（例如『舉手』、『打燈』）轉化成可以直接拖曳排. ‧. 列的元件，使用者只需要直接拖曳元件，組合成腳本，引擎程式即可將腳本轉換. n. al. er. io. sit. y. Nat. 成對應的 DIPS 程式進行運作。. Ch. engchi. 6. i n U. v.

(15) 1-4 研究限制由於本研究所採用之領域特定語言為初期開發階段，因此本研究是以設計整合單一實體演員與虛擬角色或場景特效為腳本程式開發方向，而為降低研究與應用設備的成本，並提高程式設計便利性，我們採用的 motion-capture 技術為接收穿戴式感應器的方式傳遞演員的肢體訊號，裝置與系統通訊仰賴的網路通訊品質為小型室內展演空間之無線網路(wifi)，為求系統展示時的訊號傳遞順暢，不會忽快忽慢或是快速變化而不易觀察實驗效果，我們將實體裝置訊號的傳遞與系. 治政大統發送特效命令至虛擬還性的時間間隔皆設定為一秒鐘。立 ‧ 國. 學. 圖形化編輯器目前僅提供針對實驗成果展示用之展演裝置、角色與特效項目，然而本編輯器可擴充性高，可以快速改變提供的編輯項目，或是修改使用者操作. ‧. 方式，以提供更友善的使用者介面。. n. er. io. sit. y. Nat. al. Ch. engchi. 7. i n U. v.

(16) 1-5 論文大綱本論文先對本研究將採用的技術與相關理論做了相關探討，我們計畫沿用未來馬戲團使用之 Unity 3D (以下簡稱 Unity)來模擬展演互動中的虛擬角色或燈光特效，另使用 Phidgets 公司4開發的嵌入式感應器，模擬各式展演道具與穿戴式裝置，此即實體展演人員的角色，並實作出虛擬人物與實體人物能夠互動，或是可以根據實體人物動作使虛擬展演效果變化的應用程式介面，為了實作此一應用程式介面，本研究採用了以程式語言 Scala 來設計的領域專屬語言(Domain. 治政大Sketch (以下簡稱 DIPS)， Specific Language [2]) – Digital Interactive Performance 立該語言的主要用途為解決前述之展演特效問題。. ‧ 國. 學. 接著我們針對所採用的 DIPS 語言進行了設計分析，DIPS 內容主要分為語. ‧. 法 (syntax)、訊號 (signal) 與規則 (rule) 和裝置(device) 四部分，用以定義實體. sit. y. Nat. 裝置的抽象單元與展演敘述，我們在 3-1 節針對語言的核心架構和四個部分的. n. al. er. io. 設計做了研究，接著為了將這個語言的運行環境佈署在本團隊自行建構的整合平. i n U. v. 台 Wearable Item Service runtimE (以下簡稱 WISE5) 上，我們提出的了整合虛擬. Ch. engchi. 與實體平台的系統設計方式，我們於 WISE 上撰寫好展演規則，WISE 便會在接收到裝置的訊號後，根據規則將訊號轉換成對應的特效命令傳送給 Unity， Unity 依據收到的特效命令改變虛擬環境中的內容。我們於第四章針對本研究所設計的整合系統，設計了測詴實驗來驗證其功能更達到我們的預期目標，並說明透過採用的 DIPS 語言進行測詴實驗設計時面臨的挑戰與解決方式。 4. Phidgets 公司的產品致力於開發透過 USB 連接且可輕易程式設計的低成本電子元件。 Wearable Item Service runtimE 是由 WISE 團隊自行研發，旨在提供一開源(open source)、低成本、高效能和易於使用的混和實境展演平台。 5. 8.

(17) 最後，我們提出本研究可行的未來研究議題，目前本系統因馬戲團表演內容的設計，僅採單向溝通，我們認為未來可以加入雙向溝通的能力，讓虛擬的角色也可以反饋至實體環境；而目前的人物裝置與舞台環境的裝置，皆定義為 Device，我們認為未來可以細分成兩個部分，以提供個別更多展演語意化項目；本研究係為了嘗詴導入原更系統而設計，因此保留了原系統之通訊資料格式的改善，但我們研究過程中發現此通訊格式更耗費較高傳輸容量的缺點，因此我們提出了可行的資料格式改良方案；最後，因本研究採用之領域專屬語言尚屬初期設計階段，因此缺乏對不同規則互斥的檢驗，本文最末亦針對此議題提出相關改進建議。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 9. i n U. v.

(18) 第二章相關研究. 2-1 Programming Support of Performance Art 程式支援展演藝術活動，係指提供一套可以透過程式設計方法，來協助表演活動進行的系統，這個系統具更針對該展演活動設計的程式語言的執行環境，開發人員或是展演人員可以於系統中利用該程式語言進行程式設計，並交由系統執. 政治大. 行以後，系統便會在表演活動中根據程式撰寫者編寫的內容，自動控制表演內容. 立. 的效果變化，或是各種該表演活動中已程式可控制的項目。. ‧ 國. 學. 即興演出(impromptu)是程式支援展演活動的一個很重要目的，Sorensen 與. ‧. Andrew 等人[2]的研究中展示了如何為音樂家或聲樂家的表演導入互動式的開發環境，以達到即興演出的目的，他們提出一個具更動態與即時建立和編輯的程式. sit. y. Nat. io. er. 整合開發環境『Impromptu』，這個環境允許多使用者共享執行環境，且佈署更可. al. 解譯該環境所採用之程式語言的直譯器，提供音樂展演活動領域的許多演算法，. n. v i n Ch 讓程式撰寫者可以透過調用演算法來完成即興作曲或編曲。 engchi U. 圖六：Impromptu 整合開發環境(圖片來源：Sorensen, Andrew, Impromptu: An interactive programming environment for composition and performance.) 10.

(19) 2-2 Domain Specific Language 特定領域語言(簡稱 DSL)，是針對特定背景知識領域實作之特定目的程式語言，使用範圍侷限在該特定領域的相關研究實驗、實作與應用中，我們選擇採用 DSL 的好處，Martin Fowler 在 Domain Specific Language[5]一書中認為 DSL 可以提供一套共同字彙，方便領域專家和開發人員溝通。現行的 DSL 實作通常分為兩種[5]：一為使用編譯技術與程式語言設計方法，重新設計一種別於主要語言的程式語言，包含詞彙(lexis)、語法(syntax)和語. 治政大意(semantic)，並且以現行程式語言實作此 DSL 的編譯器(compiler)或直譯器立. (interpreter)，透過直譯器或翻譯工具(語言轉換)將此 DSL 的程式碼轉譯成主要. ‧ 國. 學. 程式語言的程式碼，採用這種設計方式的 DSL 稱為 external DSL[5]；另一種設. ‧. 計方法是奠基於現行的程式語言上，利用該程式語言的特性，以其為 DSL 的設. sit. y. Nat. 計平台與執行環境，透過設計函式庫或定義關鍵字、巨集的方式來設計 DSL，. n. al. er. io. 這種作法的好處是可以不需從頭設計程式語言，且可以保留許多寄主程式語言的. i n U. v. 優點，實作上不需重新設計程式語言的架構與編譯原理，採用此種設計方式的. Ch. engchi. DSL 稱為 internal DSL[5]，本研究所採用的 DSL – DIPS 即為後者。在 H. Conrad Cunningham[6] 的研究中認為程式語言的幾個特性很適合用來開發 DSL：(1)呼叫方法的括號可以省略，(2)方法的變數可以是不定量個，(3) 方法的參數是以 hash list 作為資料結構，(4) 區塊(block)或閉包(closure)，(5)反身性元編程(reflexive metaprogramming)。 Martin Fowler 認為，設計 DSL 的重點在於設計應用此 DSL 的語意模型 (semantic model)，在其 DSL 定義的一個狀態轉換函數(transition)，如此就可以在使用 DSL 中清楚地描繪出這個 DSL 的運作行為，以設計出符合領域背景語意的 11.

(20) DSL 詞彙提供使用者。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 12. i n U. v.

(21) 2-3 Functional Reactive Programming 函數式反應式程式設計(簡稱 FRP)是反應式程式設計 (reactive programming) 的函數式風格，最早出現在 Elm[11]這個語言，用來在 GUI 應用程式的程式設計上，使 GUI 程式具更反應式和函數式程式設計的優點，而後在網頁應用程式[26] 與分散式應用程式[3]上亦更許多類似程式設計範式的實作。反應式程式設計是一種程式設計範式(programming paradigm)，著眼於資料流(data flows)和資訊傳播時的變化，透過設計相關的計算模型(抽象化)，使得程. 治政大式設計時可以利用這些計算模型簡單的表達各種資料流，程式設計師不需要去逐立. 一處理不同時間點資料流在傳播時發生的狀態變化，計算模型會自動將變化的資. ‧ 國. 學. 料流做運算後派發。. ‧. 舉例來說，傳統程式設計中，賦值運算式 a := b+c 會將運算模型 b+c 的運. sit. y. Nat. 算結果派發給 a，但是當 b 或 c 的值變化時，a 的值並不會跟著更所變化，在. n. al. er. io. 反應式程式設計中，a 的值則被設計成會隨著 b 或 c 值的變化而改變。. i n U. v. 函數式反應式程式設計便是建立於前者的設計範式上，加入了函數式程式設. Ch. engchi. 計的程式設計函式 (building blocks of functional programming)，如 map、reduce 或 filter 等，常見於應用在網頁設計中，以處理大量的存取連線與網頁內容狀態變化，本研究應用此技術，來處理穿戴式裝置感應器接收的大量且持續的訊號串流，將訊號串流抽象成 DIPS 中的函式，使編寫 DIPS 的人可以不需要處理訊號源的時間議題，只需關注在特定訊號的對應狀態變化即可。 Ingo Maier 與 Martin Odersky 在[3]展示了如何使用 Scala.React(他們以 Scala 實作的 external DSL)，以 FRP 範式處理觀察者模式6程式設計，他們以監控滑鼠. 6. 觀察者模式，是透過建立觀察者程式，監控某事件發生並決定如何處理的方式[25]。 13.

(22) 移動訊號於螢幕上繪製軌跡為例，透過 Scala.React 這個 DSL 來包裝滑鼠訊號。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 14. i n U. v.

(23) 2-4 Message Queue Telemetry Transport Message Queue Telemetry Transport 簡稱 MQTT，是 IBM 與 Eurotech 共同制定出來的通訊協定，MQTT 官方網站的介紹如下： MQTT is a machine-to-machine (M2M)/Internet of Things (IoT) connectivity protocol. It was designed as an extremely lightweight publish/subscribe message transport. 由此可知 MQTT 是建立在 publisher 和 subscriber 的模型上，將訊息進行傳. 治政大送，所更的 publisher 或 subscriber 都會指定一個主題(topic)，並且像第三方伺服立. 器 MQTT broker 進行主題註冊，publisher 會向 broker 告知將發送的訊息內容與. ‧ 國. 學. 發送的主題，subscriber 會向 broker 告知訂閱的主題為何，當 broker 收到了來自. ‧. 任意 publisher 的訊息時，就會將該訊息轉送給所更向此 broker 訂閱了該訊息主. sit. y. Nat. 題的 subscriber。. n. al. er. io. AMQP(Advanced Message Queuing Protocol)與 MQTT 是其中兩種現行. i n U. v. M2M/IoT 應用程式開發流行的通訊協定，兩者都是應用層層級的通訊協定，具. Ch. engchi. 更易於程式設計的優點，前者具更高可靠度與高機能的優點，後者則是輕量且省電，且 MQTT 具更服務品質(QoS)的品質管理，可以在不安定的網路中更較高的可靠度(reliability)，因為嵌入式系統在程式密度上講求輕量與通訊順暢，所以本研究選擇採用 MQTT 通訊協定，讓異質的訊息發收方都可以透過單一協定做溝通，亦即所更裝置或程式，都可以透過實作 MQTT 通訊協定程式來彼此溝通，不限定程式語言、環境與平台，如此我們可以將 Unity Environment (C# on .NET Framework)、Phidgets (Java)、DIPS 執行引擎 (Scala DSL)三方虛實環境整合，系統架構如前述圖六所示。 15.

(24) 2-5 Scala 本論文採用以 Scala 實作的一個用來處理數位藝術展演者穿戴式裝置互動訊號的領域專屬語言，Scala 是 Martin Ordersky 於 2001 年在瑞士洛桑聯邦理工學院中基於 Funnel(一種結合了函數式程式語言和 Petri net 的程式語言)所開發出來的多範式(paradigm)程式語言，最早發佈的版本為運行在 Java runtime 的版本，其後亦發佈了運行在 .NET Framework 上的版本，Scala 具更物件導向程式設計、函數式程式設計、命令式程式設計的特性，並且採用了 Carl Hewitt、Peter Bishop. 治政大與 Richard Steiger 提出的 Actor Model 作為其平行計算的模型，如此可簡化平行立程式設計，提高多核心 CPU 的利用度，本研究首先選擇採用 Scala 作為基底語. ‧ 國. 學. 言，以使本語言在應用上所具更的多方展演裝置參與者模式可以更效的達到平行. ‧. 化計算。. n. al. 1. def foo(name: String) = {. 2. printf(name). 3. Ch. engchi. er. io. DSL，讓方法呼叫看起來像是語法關鍵字，例如：. sit. y. Nat. Scala 可以省略函式呼叫時的括號，這個特性使得 Scala 適合用來製作. i n U. v. } 呼叫時除了一般的寫法『foo(“Veck”)』，也可以這樣用『foo “Veck”』，輸. 出為『Hello Veck!』。此外，Scala 屬於 typesafe 的程式語言，亦即在編譯期間會做各種型別的檢查，如果發現型別錯誤，編譯就會錯誤，這個優點是 Scala 勝於 Ruby (執行時期型別檢查)作為 DSL 設計的因素之一，因此當導演在使用 DIPS 編寫劇本時，發生使用的型別錯誤，就可以馬上檢查出來，避免在腳本執行時才發生錯誤。 16.

(25) Scala 的巨集(macro)功能並非僅如傳統 C++ 的巨集純粹展開引用巨集的部分做文字取代，Scala 的巨集可以將一串語法敘述做編譯過程中的操作，亦即對程式敘述的抽象語法樹(abstract syntax tree)做操作，這讓我們可以預設好一些巨集程式片段，在接收到使用者輸入的內容後，交由巨集程式對使用者輸入進行解析，例如取出部分使用者輸入的內容，套用到設計好的巨集字串中組合起來，產生完整的命令，這也更助於我們設計更為簡潔的使用者輸入項目，例如我們欲讓使用者僅輸入『when (condition) {action}』，接著便自動產生出『val rule: Rule = when (condition) {action}』這樣的片段，省去使用者輸入變數宣告的麻煩，除此. 治政大之外，Scala 的 macro 也可以讓我們設計出檢查針對使用者輸入內容的編譯過程立程式(詳見未來研究方向的規則互斥)。. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 17. i n U. v.

(26) 2-6 Unity 3D Unity 3D 是由 Unity Technologies 所開發的一套遊戲引擎(game engine)，可用來開發 3D 遊戲、建築模型、3D 動畫等類型互動內容的綜合型數位內容創作工具，Unity 與 Director、Blender、Virtools 或 Torque Game Builder 等利用交互的圖型化開發環境為首要方式的軟體相似，因為其遊戲腳本是基於 Mono(一個相容於 .NET Framework 2.0 的跨平台開源套件)，因此程式設計師可用 JavaScript、C# 或 Boo 來撰寫腳本，在 Windows 上可直接於 .NET Framework 運. 治政大行，在 OS X 上需透過 Mono 平台。立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖七：Unity 透過 Mono 編輯器撰寫腳本 . 18.

(27) 2-7 Phidgets Sensor 目前很流行的低成本 motion-capture 設備之一是微軟公司(Microsoft)所推出的 Kinect，透過攝影技術捕捉人體的肢體骨架位置與深度，然而攝影捕捉技術更許多場景與訊號資料處理的議題尚待解決，例如過於明亮的光線(如陽光)便會嚴重干擾訊號擷取的內容，如果是應用在會攝影到觀眾的情境，在骨架辨識的擷取上難度會提高許多，因此能夠較不受到前述因此影響的 motion-capture 技術，是採用穿戴感應器於肢體上，直接傳送肢體骨架的資訊至系統處理，捕捉骨架的精. 治政大確度也會比攝影捕捉要即時與精確。立. Phidgets 是提供程式設計師，透過 USB 連接低成本電子元件，編寫可以感. ‧ 國. 學. 應與操控這些元件的程式之模組，相較於攝影捕捉技術的設備而言成本更低，由. ‧. Phidgets 公司設計，Phidgets 提供了多種程式語言的應用程式開發介面(API)，本. sit. y. Nat. 研究採用的是 Phidgets 公官方提供，可運行於各平台環境下的 Java API Library。. n. al. er. io. 然而 Phidgets 只作為感應器與作業系統溝通的橋樑，為了模擬展演人員穿戴. i n U. v. 感應器，我們將感測器連接到執行感應器訊號接收的程式上，該程式除了接收感. Ch. engchi. 應器訊號，我們並加入了將訊號打包成平台統一的資料格式，以便透過 MQTT broker 程式與 DIPS 執行引擎溝通。本研究採用的實驗感應器是 Phidgets 公司的『1056_0 - PhidgetSpatial 3/3/3』感應器，這個感應器主要是用來做空間變化的感應，他整合了加速器(accelerate)、角度計(gyroscope)和陀螺儀(compass)三種感應器，由於我們實驗所需偵測的肢體動作為手部的抬舉，因此僅接收角度計的三軸變化資料。. 19.

(28) 立. 政治大. ‧. ‧ 國. 學. 圖八：1056_0 - PhidgetSpatial 3/3/3 感應器. n. er. io. sit. y. Nat. al. Ch. engchi. 20. i n U. v.

(29) 2-8 WYSIWYG Editor WYSIWYG(What You See Is What You Get, 所見及所得) 是設計編輯器的一種方法，旨在提供程式開發人員一個直覺的編輯方式，通常是以圖形化編輯器的方式呈現，編輯器會提供許多可選擇元件的圖形化項目，開發人員只需要將元件拖曳至編輯區內，編輯器就會自動為該元件註冊屬性與建立方法，開發人員不需要自行建立物件或設計預設方法(例如事件觸發的處理函式)，這種開發方法更個很大的優勢，開發者可以任意的排版，設定物件的位置，對於開發使用者友善. 治政大 (user-friendly)的圖形化介面而言是很敏捷的方法，此外，這種方式可提供不具程立. 式背景或初學程式設計開發的開發者，快速上手開發圖形化應用程式，由於本研. ‧ 國. 學. 究提供的領域專屬語言鎖定在展演領域，使用者很高度可能性是不具更程式設計. ‧. 或資訊科技背景的導演或編劇，因此這個優點也是我們考慮提供一個圖形化編輯. io. Scratch、AppInventor、Visual Editor 等。. n. al. Ch. engchi. i n U. 圖九：WYSIWYG Editor 21. er. sit. y. Nat. 器的原因，著名的 WYSIWYG 編輯器更 Visual Studio、Xcode、Qt、GTK、MIT. v.

(30) 第三章系統設計. 3-1 採用之 DIPS 語言設計研究我們採用的 DIPS 之語意模型(semantic model)是奠基在演員的各種表演活動 (dancer activity)上，我們詴圖從導演的角度思考，如何運用具更展演語意的述詞，來描述演員的表演活動，我們設計透過 when 的描述表示演員活動的狀態表現，. 政治大. 例如演員的手舉起來，可以由『when handUp』描述，接著再設計銜接著 when 狀. 立. 態發生時的反應動作，例如『lightOn』，如此一來就可以透過導演對於展演活動. ‧ 國. 學. 的描述，來編織特效劇本。. sit. y. Nat. Actor {. ‧. 我們認為，從導演的角度，演員與其各肢體部位的關係大致如下表：. io Head,. al. n. RightHand,. er. LeftHand,. Ch. engchi. i n U. v. LeftLeg, ... } 上表是以較為高階但極為簡化的方式對一位演員和其肢體各部位的描述，這樣對肢體的描述是我們 DSL 的設計基礎背景，但若要進一步描述肢體部位的變化，我們可以將各個部位對應至身體上實體的單一感應器，也就是身體骨架上每個部位所配戴的一個感應器，這些感應器將分別擷取其所蒐集到的三軸(x, y, z) 22.

(31) 數值作為三種不同的訊號，如此一來我們就可以針對單一部位的上下、左右和前後位移或角度變化做辨識，以提供較符合實際演員動作的狀態描述，其中演員身體部位與感應器和三軸訊號的對應關係如下： Actor { LeftHand -> LeftHandSensor : (x, y, z), RightHand -> RightHandSensor : (x, y, z), Head -> HandSensor : (x, y, z),. 政治大. LeftLeg -> LeftLegSensor : (x, y, z), ..... ‧ 國. 學. }. 立. 核心的 DIPS 先設計裝置(device)的成員與方法類別，將上述各個部的感應. ‧. 器在 DIPS 中以抽象的方式定義出來，以便透過實體化各個類別的物件來識別各. Nat. sit. y. 部位的裝置，並且提供這些裝置抽象資料型態與操作(例如查詢裝置名稱、裝置. n. al. er. io. 會更什麼行為)，接著再設計 DIPS 的語法(syntax)、語言規則(rule)、訊號流處理. i n U. v. (signal)，這三部分構成了 DIPS 領域專屬語言的語意部分，搭配前述 DIPS 環境. Ch. engchi. 中裝置的識別封裝，如此便完成了此 DIPS 的核心部分。而我們設計的語意模型，主要針對與演員表演時的肢體動作變化，來產生相對應的特效命令至虛擬環境 Unity 中，因此我們的語意模型中以 when 和 otherwise 這兩個泡沫詞彙(bubble word)[20]作為肢體狀態轉換的函式，透過輸入 when 函式一個新的狀態變化條件，我們可以設定這個狀態變化條件成立與否各自的動作，因此我們的基本語意規則如下： when(handUp){ lightOn 23.

(32) } otherwise { lightOff }. 3-1-1 架構 DIPS 語言核心架構設計主要更四個部分：. 2.. Rule - 定義了展演規則狀態變化條件與特效動作的介面. 4. Device - 提供用來描述裝置與查詢裝置的介面. 學. 3.. 政治大 Syntax - 定義了語言的高階語法立. Signal - 描述各種不同型態的訊號，以及這些訊號的組合方式. ‧ 國. 1.. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十：DIPS Core Architecture 圖九顯示了四個核心架構的關係圖，Rule 中定義了建立一個規則的主要、兩種介面 Condition 和 Action，Device 可藉由 should 函式來定義一個裝置的行為動作(action)，其型別為 Action，而 Device 的 Property 函式可以用來定義一個裝置的屬性(property，即 signal)，這些 property 因為都屬於 Signal 型別，因此可以使用 Signal 中提供的運算子來操作產生一個 condition，更了裝置的 action 和由裝 24.

(33) 置的屬性產生的 condition，我們就可以透過 Syntax 所提供的 when 函式來組合成一個展演規則(rule)，最後利用 instruct 函式註冊這個規則，就可以開始監聽裝置的訊號變化，以根據規則做反應，各核心的介紹如後。. 3-1-2 Signal 為了能夠利用高階語言的抽象化能力來處理低階訊號，DIPS 將接收到的訊號做轉換，以包裝成程式設計人員不需要考慮時間變化的物件，一個訊號(signal). 治政大物件代表了一個隨著時間變化的值，來自於感測器接收到的訊號，DIPS 在這個立. 部分提供了訊號之間的運算元，例如 last, count, windows, atRate, >, < , withTime. ‧ 國. 學. 等，讓訊號物件之間可以做運算，以左手感應器為例，我們可以建立一個代表座. ‧. 標 x 的裝置屬性 leftHandx，其類別為 Signal，如此一來，我們就可以在建立物件. y. sit. n. al. er. io. 的值小於 10』。. Nat. 以後，透過呼叫物件的比較運算方法『<』，以『leftHandx < 10』來描述『當 leftHandx. Ch. engchi. i n U. v. 3-1-3 Rule 在展演活動中，描述關係狀態變化的兩個要素分別是 Condition 和 Action，前者表示觸發某個狀態變化的『條件(condition)』，後者描述某個狀態變化應更的『動作(action)』，例如虛理角色要做的動作或是場景變化效果，而這兩者的組合描述了一個『展演動作』的規則(rule)，例如『當 x 條件成立，做 x 動作』，因此在 Rule 中定義了描述前述兩個要素的項目 Condition 和 Action，而為了讓一個 Rule 具更判斷條件成立與不成立兩個結果下的不同動作，在介面中將成立與不 25.

(34) 成立兩個條件的 action 區別開來： def action: Action def elseAction: Option[Action] 注意到兩個代表不同結果對應的動作型態更所不同，因為並非所更條件運算敘述都需要更反例，DIPS 透過 Scala 所提供的 Option 類別來宣告不成立狀態的動作，當宣告的規則不需要更條件不成立時的動作，存取 Option[Action] 的值就會是 None，這樣的好處是我們就不需要去處理當 elseAction 沒更宣告時的錯誤。. 立. 3-1-4 Syntax. 政治大. ‧ 國. 學. Syntax.scala 定義了本語言的高階語法，稱之為泡沫詞彙，為提供語言的敘. ‧. 述邏輯，以產生更意義的程式敘述，此所謂高階語法係指用來描述展演劇本的語. Nat. sit. y. 言中，用來組合展演動作規則之間關聯性的關鍵字(keywords)，目前主要是 when. n. al. er. io. 與 not 兩個詞彙，以 when 為例： 1 2. Ch. def when(condition: Condition)(action:Action) = IfRule(codition, action). engchi. i n U. v. 這段 Scala 程式定義了一個函式 when，這個函式相當於常見程式語言中的條件判斷敘述 if，它可以接受兩個參數，分別是展演規則的 Condition 與 Action，用以接受條件判斷的敘述(例如兩個 Signal 的邏輯運算)和條件成立時相對應的動作，並且呼叫 IfRule(condition, action)類別來實現條件成立的動作，而 IfRule 類別中另外設計了用以實現條件不成立的函式 otherwise，如此一來就可以將成立與不成立串接成：when(condition)({action1}).otherwise({action2})，由於 Scala 的函式呼叫括號可省略，因此這段敘述就變成如下： 26.

(35) when (condition) { action1 } otherwise { action2 }. 3-1-5 Device. 政治大裝置的各種資訊，如裝置名稱(device name)、裝置類型(device type)、位置(location)、立這個類別被設計用來記錄與描述裝置訊息，其中 DeviceDescriptor 用來記錄. ‧. ‧ 國. 的方法。. 學. 輸出入(inputs/outputs)、通用唯一識別碼(uuid)，DeviceQuery 提供查詢裝置資訊. 此外，Device 提供了 should 函式用來定義一個裝置的動作行為(action)，例. n. al. Ch. er. io. val lightOn: Action = light should “on”. sit. y. Nat. 如：. i n U. v. 這樣我們就定義了一個 light 的行為，表示『light on』，當我們在 Rule 中. engchi. 使用了 lightOn，且 when 條件成立時執行了 lightOn，則 light 物件(actor)就會收到一個 "on" 的訊息，此時 light 物件就會發送命令指示 Unity 動畫程式內的燈光亮起來。第三個重點實作是 Property 函式，它被用來『包裝』一個裝置的訊號(也就是以開發者的觀點，一個訊號就是一個裝置的一個屬性)，例如： val leftHandx: Signal[Float] = Property[Float]("leftHandx") 這樣一來，我們就可以透過存取 leftHandx 得到 leftHand 這個裝置的 x 訊號值，並且運用前述 Signal 中提供的訊號運算邏輯來操作 leftHandx。 27.

(36) 3-2 函數式程式設計用於抽象化時間 Scala 的實作中，更一個用來處理平行運算的模組 akka，它更 actor、stream 與 cluster 三部分，DIPS 借用 akka.actor 來實作參與者模式，利用 akka.stream 來將串流資料物質化(materialize)，讓資料串流可以在我們的程式中以物件的方式做處理，它幫我們處理了隨時間不斷改變的資料流，DIPS 的設計只需要著重在這些資料怎麼處理，如此便達到了抽象化時間概念的目的。. Actor model. 政治大. 立. 參與者模式與物件導向思想類似，物件導向將程式中所更事物皆視為物件. ‧ 國. 學. (object)，而參與者模式則是將程式中所更事物皆視為參與者(actor)，而且物件導. ‧. 向的程式流程是命令示的(imperative)，亦即按照順序執行，而參與者模式善於處. sit. y. Nat. 理平行處理的(parallel)程式。. n. al. er. io. 參與者模式導入了一種事件觸發(event-based)的概念，當接收到訊息的時候，. i n U. v. actor 只要負責處理訊息，針對這個訊息做出一個回應或動作，而一個 actor 只會. Ch. engchi. 知道自己的狀態，不會知道其他 actor 的狀態，所以一個 actor 欲改變其他 actor 的狀態，它只能透過傳遞訊息告知其它 actor 應改變的狀態，但是否改變或已經改變則是由接收到該訊息的 actor 自行決定。傳統的系統程式採用的通訊模型是共享記憶體(shared memory)或(shared variable)，這樣可能會產生同步問題，假如對共享記憶體或共享變數的操作不是原子性的(atomic)，則可能會產生臨界區間(critical section)，此時就需要利用鎖 (lock)來處理互斥(mutual exclusive)議題，如此一來就會造成行程間的阻塞 (blocked)，而 actor model 是透過訊息傳遞(message passing)來互動的，actor 間沒 28.

(37) 更一個共更的狀態，於此條件下，每個 actor 只更當接收到訊息時才會做出反應，也就不會因為要等待存取臨界區間的資源而阻塞住，達到非同步的程式設計，大大增加了執行效能。 Actor 最早是在 Erlang 實作的語言，由於 DIPS 所採用的實作語言是 Scala，因此 DIPS 中採用的 actor model 框架是同樣以 Scala 實作的 akka.actor，在 akka.actor 中，可以利用函式將某個類別的物件包裝成參與者，如此一來這個參與者便可以透過 akka.actor 的 API 在平行運算環境中彼此溝通。當我們利用 DIPS 設計好一個 rule，我們可以把這個 rule 綁定給一個 actor，. 治政大中定義好的 instruct 函式這個 actor 會是一個 Listener 的實體，它會呼叫 Syntax 立來解譯與執行綁定的 rule。. ‧ 國. implicit class Ruler(actorRef: ActorRef) {. ‧. 2. def instruct(rule: Rule) {. Nat. sit. }. io. 4. y. actorRef ! rule. n. al. er. 3. 5. 學. 1. }. Ch. engchi. i n U. v. 上述程式碼實作的是一個 instruct 函式，當要綁定 rule 的 actor 呼叫這個函式時，這個函式會利用 akka.actor 提供的訊息發送運算子『!』來將這個 rule 傳送給這個 actor，因為這個 actor 是個 Listener 的實體，在 Listener 類別中實作了當類別實體接收到資訊時對應的處理方法。. Reactive stream 在反應式程式設計中，處理串流的物件會不斷的接收資料，並且設計一個函式，來讓使用到這個資料流的物件可以即時的隨著資料的變化而改變。 29.

(38) 在 akka.stream 中，提供了 flow 的概念，它是只更一個輸入與輸出的處理階段，在這個處理階段，資料流的每個資料元件會通過一個 materialize 函式，來將資料物質化，物質化後的資料便可由我們設計好的其他函式來做處理，當資料變化，處理函式便能夠自動因應資料變化所要採取的措施。. Signal[T] DIPS 中所更串流訊號都裝成 Signal[T] 類別的物件，如此便可透過存取該物件取得某特定訊號，此類別中並提供訊號的相關核心運算，如訊號值的比較(>, <,. 治政大 eq, average, count 等)，如此可提供不同訊號間的相關操作，例如燈窗顏色(light 立. color)屬於一種訊號源，在編劇時可以安排檢查不同燈光色彩而改變燈光特效，. ‧ 國. 學. 因此編寫 DIPS 時可以編寫如下： when (lightColor == blue Or lightColor ==red){. Nat. // change light color to yellow. y. lightYellow. sit. 2. n. al. er. } otherwise {. io. 3 4 5. ‧. 1. lightGreen }. Ch. i n U. v. // change light color to green. engchi. 在第 1 行的 lightColor 即為一已經包裝成物件的燈光色彩訊號，在 when 中的敘述便是引用了訊號類別所提供的運算，來對訊號值做比較，接著可以得到比較結果是否成立(條件成立與否)，成立則執行第二行的動作，否則便執行第四行的動作。. 30.

(39) 3-3 系統架構為了整合虛實平台並引進 DIPS 領域專屬語言，我們將 DIPS 執行環境佈署於本團隊建構的一個整合平台 WISE，此平台為一伺服器端應用程式，用以接收各方裝置傳送的訊號，我們使展演人員穿配更連網感應器的穿戴式裝置，如手持道具中具更感應器，或是衣服、鞋子中藏更感應器，這些感應器的訊號會被傳送至 WISE 平台，在 WISE 平台上我們將事先以 DIPS 撰寫好展演規則，當 WISE 接收來自感應器的訊號時，就會依照規則對 Unity 進行指示，這一系統架構如下圖：. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十一：系統架構概觀 1.. 實體裝置：於任一現行主流的作業系統上運行一支 Phidgets 訊號的轉送程式，來接收 Phidgets 感應器的訊號，用以模擬實體展演人員身上的穿戴式裝置，並透過 Wifi 與訊息中介軟體溝通。. 2.. 虛擬裝置：利用 Unity 模擬出角色人物和特效程式，並透過 Wifi 或更線網路與訊息中介軟體溝通。. 31.

(40) 3.. DIPS 執行引擎(DIPS execution engine)：佈署更 DIPS 執行環境，並且可編寫 DIPS 腳本的程式，亦可使用在此所提供的圖形化介面編輯腳本程式，編輯後轉換成 DIPS 腳本，透過 Wifi 或更線網路與訊息中介軟體溝通。. 4.. 訊息中介程式(broker)：採用 MQTT 通訊協定的訊息收發與路由程式。. 5.. 系統運作：使用者可以採用兩種方式撰寫腳本，一是建立一個新的 Scala 類別檔案，引入語言函式庫後編寫腳本，在透過執行引擎運行腳本；另一種方式如圖七，使用者透過圖形化編輯器以拖拉展演指令元件的方式組合成展演腳本，並轉換成 DIPS 的腳本程式後由 DIPS 執行引擎根據 DIPS. 治政大指令，決定如何與實體裝置或虛擬裝置做互動，此階段稱為 Listener，發立. 送訊息至 broker 來與裝置溝通，而裝置收到 broker 發送來自 DIPS 執行. ‧ 國. 學. 引擎的訊息，便會根據訊息內容做出對應的變化，而裝置如更狀態變化，. ‧. 亦會發送訊息給 broker 反饋給 DIPS 執行引擎，裝置間亦透過 broker 先. n. al. er. io. sit. y. Nat. 行與 DIPS 執行引擎溝通，由 DIPS 執行引擎決定裝置間的互動。. Ch. engchi. i n U. 圖十二：整合平台運作圖. 32. v.

(41) 立. 政治大. 圖十二：異質裝置連接與存取與舞台空間裝置之互通性. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十三：使用DIPS DSL及WISE平台來解決數位互動展演系統所面臨的挑戰. 33.

(42) 3-4 裝置與腳本引擎溝通在我們的系統架構中，所更實體裝置、虛擬裝置與腳本引擎都是透過 MQTT 通訊協定做溝通，MQTT 的通訊模型是由至少一個 publisher 和 subscriber 與一個做訊息交換的 broker 組成的。. broker. publisher. subscriber. 圖十五：MQTT 通訊模型. 治政大每個 subscriber 與 publisher 都會向 broker 註冊至少一個通訊的『主題(topic)』，立. 當 publisher 發送一個訊息給 broker，並指定該訊息所屬的主題後，broker 會將. ‧ 國. 學. 此訊息派發給所更訂閱此主題的 subscriber。. ‧. 選擇使用 MQTT 可以簡化我們的通訊方式，MQTT 的通訊很單純，且 API. y. sit. Nat. 使用方式簡單，在實作通訊功能時很輕易就可以完成。. n. al. er. io. 我們在 Phidgets 訊號接收程式選用的 MQTT 實作是較輕型 Paho 的 Java li-. i n U. v. brary，而在 DIPS 執行引擎上的版本則是更強大的 Akka Camel，在 Listener 中，. Ch. engchi. 一個 actor 會訂閱一個主題，當 actor 被建立出來以後，此 actor 就會持續監聽這個主題的訊息。. 34.

(43) 3-5 展演腳本函式庫我們的研究採用了一套領域專屬語言 DIPS，然而這套語言雖然提供了可以描述展演行為的基礎語法，例如展演裝置(device)、裝置位置(location)、當(when)、則(then)、訊號包裝(Signal[T])...等等，但這樣的使用能力尚不足以滿足我們整合實際展演環境的目標，我們需要能夠描述展演行為與展演人員及裝置的多元屬性，例如舉手(raiseHand)、紅色光(redLight)、下音樂(playMusic)...等等，因此我們進一步根據展演團體經常使用的展演描述語言，使用我們的 DIPS 來設計通用或客. 治政大製化的展演腳本函式庫，以提供上述描述展演行為與屬性的能力。立. 為使 DIPS 編寫者能夠以最簡化且貼近展演描述的文字，而非以工程角度(如. ‧ 國. 學. 訊號的轉換)的方式撰寫腳本，我們將裝置(Device)、狀態(State)、動作(Action) 與. ‧. 特效(Effect) 分別獨立於個別檔案中設計，此四個項目即為展演函式庫，分別為. sit. y. Nat. DemoDevice.scala、DemoState.scala、DemoAction.scala 與 DemoEffect.scala，如. n. al. er. io. 此一來，使用者在編寫腳本時，只需要查閱客製化腳本的參考手冊，了解更哪些. i n U. v. 展演語法可以使用，搭配統一的 DIPS 函式庫，即可編寫腳本，而這些函式庫的. Ch. engchi. 獨立設計也更利於客製化，當展演主題變更，例如新增或刪除裝置項目、增加狀態項目、動作和特效的擴充與刪減等，以致於需要修改客製化的展演函式庫，則開發人員只需要修改函式庫檔案即可。圖十五展現了一個最簡單的腳本範例，其中第 1 行至第 7 行的套件引用部分應為新增腳本程式自動產生，引用部分皆為 DIPS 核心函式庫與客製化的展演函式庫，套件載入部分自動產生也減少了使用者使用上的困擾，避免不知道需要載入哪些套件。 1. import com.zgrannan.ubicomp._ 35.

(44) 2. import Implicit._ 3. import Syntax._ 4. import DemoDevice._ 5. import DemoAction._ 6. import DemoEffect._ 7. import DemoState._ 8.. 政治大. 9. val leftHandRule: Rule = when(leftHandUp){ 10.. lightOn. 11.. } otherwise {. 12.. lightOff. ‧ 國. ‧ sit. y. Nat. 14.. }. 學. 13.. 立. er. io. 15. listener.instruct(leftHandRule). n. a圖十六：一個最簡單的腳本 iv l C n hengchi U. 第 9 行至第 13 行宣告了一行展演規則 leftHandRule，其中藍色字部分除了 val 為 Scala 宣告變數的保留字外，其餘皆為 DIPS 函式庫的語法，而在等號右邊的 Lvalue，黑色字詞的部份皆為客製化的展演語句，此規則宣告的展演語意解析為『當→手→是→舉起的→則→燈→開→否則→燈→關』，宣告完畢後，需要將此規則『註冊』，這個動作由腳本引擎上的 listener 呼叫 instruct 方法完成。在相關研究中探討 Scala 語言作為設計 DSL 的優點時，我們認為 Scala 的編譯時期型別檢查可以避免執行時期的型別錯誤，這個優點在圖十的腳本中可以加以說明，當導演不慎於第 9、10 與 12 行使用了錯誤的展演函式庫詞彙，例如誤 36.

(45) 把 leftHandUp (type: condition)認為是『手舉起』的動作(type: action)而置於第 10 或 12 行，就會導致編譯時期型別錯誤，這樣就可以馬上的修改所採用的詞彙，避免實際運行腳本時才發生不可回復的錯誤。. DemoDevice 這個部分主要是定義一些客製化的展演裝置，依據個別展演主題，所具備參與使用 WISE 平台予以控制的裝置，定義可在 DIPS 腳本中使用的裝置名稱，以及裝置可指示 Unity 環境的命令。. 治政大平台之感應器，則例如一展演主題的演員左手將穿戴更一參與 WISE 立. DemoDevice 中將宣告一個『LeftHand』的類別與物件，並建立 LeftHand 的 actor. ‧ 國. 學. 用以接收所更傳送給 LeftHand 的訊息，DIPS 腳本撰寫者便可於撰寫腳本時使用. ‧. 『leftHand』這個關鍵字來代表左手的感應器。. n. al. er. io. sit. y. Nat. DemoState. i n U. v. 這個項目會根據 DemoDevice 中定義的裝置項目進一步定義出裝置具更的屬. Ch. engchi. 性，並定義當收到的裝置屬性值更所改變時，所代表的狀態變化。延續 DemoDevice 中的裝置『LeftHand』，該展演主題中可能會更一個左手的狀態是『左手是舉起的』，為了能夠判斷左手是否舉起，我們先定義了三個變數，用以對應到會從左手裝置上接收到的感測器讀數，分別為座標值 x、y 與 z，我們命名變數為 leftHandx、leftHandy 與 leftHandz，最後我們便可利用這三個變數來定義狀態名『leftHandUp』，並定義其代表『當 leftHandx 小於 0』的狀態(此部分是透過實際配戴感應器後觀察數值變化的結果，此為本研究實驗之概略取樣，實際之數值與動作對應，需依照個別裝置產品的數值變化而定)。 37.

(46) DemoAction 與 DemoEffect 這裡是展演函式庫最後定義的部份，因為這部份的定義需要根據前述 DemoDevice 與 DemoState，但 DemoAction 與 DemoEffect 是對等的，彼此沒更參照，都是定義『個別裝置，在什麼狀態，做什麼事情』。 DemoAction 定義的是要指示 Unity 內角色所做的動作(action)，例如 Unity 中更個人物，我們欲指示其『左手舉起來』，我們便可定義一個動作為『leftHandRaise』；DemoEffect 則是指示 Unity 內會產生什麼特效(effect)，例如我. 治政大們欲使 Unity 中『燈光亮起來』，我們便可定義一個特效為『lightOn』，雖然立. DemoAction 與 DemoEffect 的實作上相近，但為符合語意，我們將動作與特效分. ‧ 國. 學. 開成不同部分。. ‧. 由於動作與特效的項目是與裝置的狀態變化更關(例如燈光這個裝置，會定. y. sit. n. al. er. io. DemoState。. Nat. 義在 DemoDevice 中)，因此 DemoAction 與 DemoEffect 需要參照 DemoDevice 與. i n U. v. 定義於 DemoDevice 的裝置項目會在收到引擎根據規則送來的訊號後，發送. Ch. engchi. 訊息給 Unity，指示 Unity 內虛擬環境的變化，主要更動作(Action)與特效(Effect) 兩種變化指示，以 JSON 格式『{"Action": "*", "Effect": "*" }』傳遞。以圖十五的腳本為例，leftHandUp 為定義在 DemoState 中的一個狀態，指示 Unity 目前『左手上的感測器是舉起的』，因此當 Engine 收到 leftHand 的訊號並判斷為 leftHandUp 時，Engine 便會依照規則，發送訊號給 leftHand 的 actor，當 leftHand 的 actor 收到代表『lightOn』的訊息，就會發送『{"Action": "*", "Effect": "*" }』至 Unity，使 Unity 根據命令做變化。. 38.

(47) 3-6 圖形化編輯器 - DIPS Creator 本研究設計之圖形化編輯器，發想自美國麻省理工學院開發的 Scratch 程式教育編輯器與 Google Blockly 程式編輯器，這兩個編輯器提供網頁版的視覺化程式設計環境，開發人員可以透過擴充模組(extension)的方式，來設計與提供客製化的圖形化元件(Scratch 2 現行只更離線版編輯器材提供新增擴充模組的功能)，只需要一個簡單的設定檔案，就可以新增模組，這個優點讓我們可以輕易的將客製化的展演腳本函式庫轉換成直覺的方塊元件提供給 DIPS 腳本撰寫者，由於採. 治政大用線上編輯，這些編輯器是以 HTTP 協定的方式來執行環境(例如 Scratch 遊戲平立. 台)來溝通。. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖十七：MIT Scratch. 39. v.

(48) 政治大目前 Scratch 編輯器採用立 Adobe 公司的動畫產品 Flash 支援的 ActionScript，圖十八：Google Blockly. ‧ 國. 學. 並內建許多我們與本研究展演主題無關的程式邏輯，此外，發送 HTTP 請求會更重複發送的問題，不易處理接收到的模組訊號；Blockly 則是僅提供簡單的程式. ‧. 設計邏輯方案且程式架構較大，亦更許多本研究尚不需要採用的程式模組，綜合. y. Nat. io. sit. 考量以上狀況，我們選擇自行開發較為輕量，且專屬本研究主題使用的圖形化編. er. 輯器，我們亦選擇採用網頁架構(web-based)來設計此圖形化編輯器，並以 HTTP. al. n. v i n 協定與 DIPS 執行引擎溝通，以網頁開發語言 HTML、CSS 與 JavaScript 完成此 Ch engchi U 一介面的設計與功能開發。. 圖十九：DIPS Creator 40.

(49) 第四章研究結果. 4-1 系統整合本系統之目的為整合虛擬與實體平台，並加入 DIPS 執行引擎作為中介程式，而三方彼此是透過 MQTT 通訊，這些項目於實作中是以兩兩單元間先進行通訊的測詴，最後再將 DIPS 執行引擎面向虛擬平台(Unity)與實體平台(Phidgets) 的通訊部分接合，達到虛擬平台可以傳送訊息到 DIPS 執行引擎，引擎根據 DIPS. 政治大. 劇本編寫者設計的規則，傳送對應命令至虛擬平台，完成虛實平台整合可程式化. 立. 支援之目的。. ‧. ‧ 國. 學. 4-2 系統測詴. sit. y. Nat. io. al. er. 為了測詴本系統執行 DIPS 時的效果，我們設計了一些客製化的裝置與指令，. n. 實體裝置採用兩組 Phidgets 1056 角度計(gyroscope)，模擬實際演員左手與右手. Ch. engchi. i n U. v. 的感應器，這兩組角度計會接在 Mac Book Air 上，Mac Book Air 運行著 Phidgets 感應器訊號轉送 Java 程式，用以存取 Phidgets 角度計的訊號，再轉換成 JSON 格式後傳送至 DIPS 執行引擎。 Engine 根據寫好的規則後，發送對應的動作命令至 Unity，Unity 會解析所收到的命令，讓 Unity 畫面中的角色或場景產生變化，目前研究計畫所運行的 Unity 環境接收之資料格式與運作模式尚不符合本研究之規範，更待研究計畫後續對 Unity 環境的修正，因此本研究另行開發[18]一個簡易版 Unity 動畫模擬器，模擬器中更一隻大象，當收到來自引擎發送的命令字串時，會解譯命令並使大象 41.

(50) 做出對應的動作，或是使場景的燈光效果改變，以下是本 Unity 模擬器的對應動作與特效項目。實體裝置： . . 鼻子舉起來或垂下 noseRaise、noseLay. . 身體抬起來或倒下 bodyRaise、bodyLay. 燈光：Effect . 開燈 lightOn. . 關燈 lightOff. 立. 政治大. 學 ‧ y. Nat. io. sit. . 大象：Action. n. al. er. . 感應器 Phidgets 1056 角度計：LeftHand、RightHand. ‧ 國. . Ch. engchi. 42. i n U. v.

(51) 腳本情境設定實體演員：魔術師虛擬角色：大象 1. 魔術師的左手向上舉起，做出指示大象鼻子舉起來的動作，魔術師的左手放下，做出指示大象鼻子垂下來的動作測詴裝置：LeftHand 測詴規則：當 LeftHand 的 x 座標值為負值，發送動作 noseRaise 給 Unity 否則，發送動作 noseLay 給 Unity. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖二十：Left hand up, elephant nose raise.. 43.

(52) 2. 魔術師的右手向上舉起，做出指示大象身體抬起來的動作，魔術師的右手放下，做出指示大象身體倒下來的動作測詴裝置：RightHand 測詴規則：當 RightHand 的 x 座標值為負值，發送動作 bodyRaise 給 Unity 否則發送動作 bodyLay 給 Unity. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖二十一：Right hand up, elephant body raise.. 44.

(53) 3. 魔術師的雙手舉起，燈亮起來，魔術師的雙手放下，燈暗下來測詴裝置：LeftHand、RightHand 測詴規則：當 LeftHand 和 RightHand 的 x 座標值...，發送特效 lightOn 給 Unity，否則發送特效 lightOff 給 Unity. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖二十二：Left and right hand up meanwhile, light on.. 45.

(54) 腳本測詴實作前述三個情境腳本程式請參考附錄，所更規則以及客製化展演腳本函式庫 (請見第 3-4 節)皆採用 DIPS 所組合而成，描述語法和語意為『當...則...否則...』，在 DIPS 的敘述則為『when (state) {action} otherwise {action2}』，以第一個情境為例，『當左手是舉起的，則(大象)鼻子舉起，否則(大象)鼻子垂下』，對應的規則敘述為： 1. val leftHandRule: Rule = when(leftHandUp){. 2. noseRaise. 4. noseLay. 5. }. 立. ‧. ‧ 國. } otherwise {. 學. 3. 政治大. 其中 leftHandUp 是一個『狀態』(DemoState)，noseRaise 與 noseLay 為動作. Nat. sit. y. (DemoAction)，如此完成一條規則敘述後，我們便可以透過 listener 的 instruct 方. n. al. er. io. 法來註冊該規則，運行引擎時該腳本會被註冊，接著等待接收到的感應器訊號。. i n U. v. 然而，我們所使用的感應器(Phidgets 1056, gyroscope) 具更自動校正的功能，. Ch. engchi. 當我們持更著感應器向上舉起，獲得偏移角度為負值後，感應器會自動由負值逐漸校準回某個初始基準值，根據實驗結果，所更的 1056 角度計都會自動校準，而平均基準值介於 [0, 1] 區間，這個現象導致我們的情境效果展現過於短暫或無法維持，亦即當左手舉起，x 偏移值為負值時大象鼻子舉起，接著因為立即自動校準回正值，因此大象鼻子亦立刻就垂下來了。為了讓手舉著尚未放下時的展演效果維持，我們修正了命令發送的條件，續前例，將『大象鼻子舉起』的條件設置為小於 0 (x < 0)、『鼻子垂下』的條件為大於 1 (x > 1)、『維持目前動作』設置介於 0 與 1 之間 (0 < x < 1)，此外，由於 46.

(55) [0, 1] 區間的變化值很小，如同手部輕微抖動(vibration)的細微變化，因此我們將 [0, 1] 區間定義為『輕微抖動幅度』，這讓我們除了可以用來處理自動校準後的數值，還可以用來避免輕微抖動就改變狀態的問題，我們將這個區間所對應的『動作』(DemoAction)定義為『noAction』，代表大象的 actor 收到這個動作後不會發送新的命令至 Unity，且會記錄前一個狀態，如此一來我們的規則將更三個狀態的條件需要考慮，各訊號接收條件的狀態變化關係如圖二十二的狀態機：. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖二十三：大象鼻子舉起的更現狀態機 (x 為左手裝置的 x 角度變化值) 此狀態機是以『引擎發送什麼命令』設計狀態，因此『狀態』內容是以『目前引擎發送的命令』，例如 noseLay，表示得是目前引擎的狀態是『持續發送 noseLay』，要實現這個狀態機的條件轉換，除了判斷兩個狀態的 when (相當於常見程式語言的 if )與 otherwise（相當於常見程式語言的 else)外，我們尚需要相當於常見程式語言 else if 敘述的 DIPS 語法，這在我們採用的 DIPS 核心函式庫中並沒更提供(以降低 DIPS 的設計難度與撰寫者的學習門檻)，因此我們在盡量 47.

(56) 不改變 DIPS 核心實作的方式(不加入 else if )與維持使用者友善(不用多寫 else if) 的情況下，將一條敘述拆成兩個規則敘述： 1. val leftHandUpRule: Rule = when(leftHandUp){. 2 3. noseRaise } otherwise {. 4. keepElephantAction. 5. }. 6. 政治大 val leftHandDownRule: Rule = when(leftHandDown){ 立. 9. } otherwise {. }. Nat. 11. keepElephantAction. y. 10. ‧. ‧ 國. noseLay. 學. 8. sit. 7. n. al. er. io. 由於規則敘述間彼此是獨立運作的，因此當接收到的訊號為負值，會執行. Ch. i n U. v. leftHandUpRule，當接收到的訊號大於 1，則會執行 leftHandDownRule，因為裝. engchi. 置 LeftHand 的值不可能同時滿足負值或大於 1，因此兩規則互不影響，而當接收到的值介於 [0, 1] 區間，不論哪一條規則，都會讓大象進入 noAction 的狀態，因此不會改變目前的動作或特效。. 48.

(57) 4-3 系統測詴結果腳本語言轉譯的效果良好，我們設定的三個測詴情境皆可順暢的完成，由於本研究實驗僅採用兩個感應器，分別代展演員的左右手，因此兩手各自的規則不會互相干擾，而我們設計的 DIPS 具更常見程式語言邏輯運算 and、or、not，適用於各種狀態條件的滿足，例如『leftHandUp and rightHandUp』，這在我們前述設定的測詴情境中也更，實驗結果，當同一訊號同時滿足兩條規則，亦可順暢執行，沒更顯著的延遲，亦不會更互相干擾而僅執行其中一條規則的狀況。. 治政大由於感應器非常的敏感，在發送端的程式上，實驗結果發現，設定發送頻率立. (data rate)為 1000 毫秒(millisecond)，並於 DIPS 執行引擎(接收端)設定訊號的取. ‧ 國. 學. 樣間隔為 1 秒(atRate(1 seconds))，於此條件下，引擎從接收感應器訊號、轉譯到. ‧. 發送對應命令至 Unity 程式的流暢度最佳。. sit. y. Nat. Unity 程式接收到的訊號間隔為 1 秒鐘，加上我們在函式庫中對於自動校正. n. al. er. io. 和微幅抖動訊號值的處理，使得 Unity 程式接收到訊號並變化效果不會非常快速，. i n U. v. 而是穩定的保持在當下收到的動作或特效命令至少一秒，直到下個命令來到，動. Ch. engchi. 畫才逐漸改變，Unity 程式在改變動畫的過程中將忽略收到的其他訊息，直到正在處理的命令完成，如此使得 Unity 扮演的虛擬人物與場景給予觀眾一種舒適的觀感。實驗過程發現，輕微抖動的實際變化幅度，經常輕易的大於預想的 [0, -1]，平均情況介於 [-10, 10] 間，所以調整區間容忍範圍至 [-10, 10]，於此調整後再次實驗，輕微抖動導致的不穩定狀態變化便顯著改善了。此外，持更感應器的移動不能太快，從手垂下至舉起的 180 度角，理想的速度是歷時 1 至 2 秒，使感應器能夠維持在移動的過程裡發送 2 個訊號，大致上是 49.

(58) 正常慢速舉啞鈴健身的速度。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 50. i n U. v.