第三章 硬體擴充
3.3 耗電量
國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 8 : WISE Item 電路圖與實體照
此外，擴充的腳位不僅能支援反應器，同時也擴增了 BLE 傳輸器的連接數量，BLE 需要 4 個連接腳位 : 傳輸腳位 TX、接收腳位 RX、VCC 電源位、GND 接地位，在容納多 組 BLE 後可以開始利用多組 BLE 進行 RSSI 等資料的計算，進一步提升裝置的應用性。
3.3 耗電量
因應裝置的增加，耗電量也是調整重點。在接滿並持續開啟反應器和 BLE 的狀態 下，原有的 3.7V , 300 mah 的電池僅能支撐 3~4 小時左右，已不敷使用，所以將電 池更換為 3.7V , 600 mah，電池大小放大為 30mm X 60mm X 3.5mm，雖然增加了些體 積，但在可接受範圍內，換上新型電池後，裝置能持續運作 6~8 小時。
圖 9 : 3.7V 600 mah 電池
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
第四章 系統架構
硬體的發展一代淘汰一代，現在的硬體在未來某天也會被取代，因此本論文多著 墨於軟體方面。軟體架構依照功能分類為數個模組，負責從終端穿戴式裝置、中介平 台、後端平台到顯示模組中的資料蒐集、解析、控制、交換和呈現等功能，並透過不 同模組的組合來完成異地間的資料交換(圖 10)。
圖 10 : 架構圖
4.1 WISE Item
作為穿戴式的核心，每個 WISE Item 都是獨立的節點，Item 和 Item 間互不影響，
‧
讀取 MPU6050 的資料透過 BLE 傳輸到 WISE Middleware。每個節點會主動從 MPU6050 讀取 Yaw、Pitch、Roll 三軸姿態資料，這些數值原始數值範圍介於正負 180 之間，透過 Arduino 將資料加上 360，使得產生的數值皆為正整數，這樣傳送資料時
5mins 10mins 15mins 20mins 25mins 30mins
6 Bytes 8 Bytes
圖 11 : 兩種資料量的 PPS 比較
‧
5mins 10mins 15mins 20mins 25mins 30mins
< 1M
接收 WISE Middleware 傳送來的指令並控制反應器。本論文在 Arduino 程式中開 始實作 BLE 接收資料的程式，而實驗中遇到了亂碼的情形，當傳送數據的間距小於 200 ms 時，位於接收端的 Arduino 會隨機出現亂碼，這使得控制指令失去準確的控制，開 始出現無法開啟/關閉反應器的情形。因此我們改良了控制指令，首先讓每個指令長度 相同，再來精簡化為 5 個相同的字元，像: 00000, 11111...等，然後收到的訊息 會先確認，當有超過 3 個字元是相同的，才會連接到相關的控制程式去作動反應器。
‧
者，所以程式中有防呆機制，透過 Arduino 函式庫內的 TimerOne ，定時讓反應器停 止或定時進行監測功能。讓這些反應器被限制為每作動一段時間後將休息一段時間，
避免裝置不斷產熱。
4.2 WISE Middleware
從距離實驗中 BLE 的連線容易因為使用者遠離的情形而呈現不穩定狀態，而且基 於物聯網的 WISE.Item 是非 IP 網路，所以需要一個方便能放在身上充當 BLE 和無線 /有線網路多方轉傳功能的中介服務器，我們稱之為 WISE Middleware，其由軟硬體共 同構成。作為中介裝置的硬體要能同時支援 BLE 和多種連線方式，現成設備選擇為樹
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 13 : 模型關節部位名稱圖
‧
WISE Middleware 的核心功能在軟體部分的處理資料和節點監控，要能收集各個 WISE Item 經過 BLE 傳送來的資料轉化成規範好的格式，透過無線或有線網路傳送至 WISE Platform；或是透過紀錄各個節點的 MAC Address 反過來傳送反應指令至特定的 WISE Item。傳輸資料方面，樹莓派上的藍牙接收器會在不同的時間點，分別收到各個 WISE Item 所傳來的資料，其中並沒有固定的順序與頻率，在收集彙整好資料後會轉 好格式，再將整理好的資料傳輸出去。
4.2.1 連線速度問題
BLE Dongle 的特性一次僅容許一個 BLE 進行連線，也就是說連線時是 singleton 模式，其他 BLE 需要等正在連線的裝置連線完成後才能搶著唯一權利來連線，而從連 pitch, Roll，進到步驟二後會開始進行連線判斷。
4.2.2 連線中斷問題
無線訊號容易受外在因素的干擾而導致連線中斷，每次的中斷將使得呈現出來的 動畫不流暢，甚至出現姿態扭曲。因此需要在最短時間內即時恢復連線，所幸藍牙 4.0 不需要配點，能快速建立連線，在 WISE Middleware 程式中實作了自動重新連線的機 制。接收程式在 loop 迴圈中不斷執行，當發現 300 ms 內沒有接收到新資料時，就判 斷連線已中斷，然後重新連線。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
4.2.3 Protobuf 和傳輸協定
原有的資料以 Json 格式傳輸，但格式上多餘的 ", {, }, : 等字元增加了相當多 overhead，以公式來計算每秒資料傳輸量(Bytes)
每秒傳輸量 Bytes ＝ 資料大小 ( header ( createTime, id 等資訊佔用的 Bytes ) + wiseItem 組數 x 每筆 json 資料大小(Bytes) ) X 每秒資料數
18 組 WISE Items 每秒 60 筆資料來計算
( 68 Bytes + 18 * 36 Bytes ) x 60 ＝ 42.96 KBps
在 1M ( 128 KB/sec ) 網路頻寬會造成約 330 ms 的 delay，加上 json String 的 處理時間約為 10~20 ms ,故單筆資料即產生了 340~350 ms 的延遲，遠高於資料產生 的速度(16 ms)，雖然因應網路頻寬的提升可以降低影響，但整體計算並不適合用來異 地傳輸。
圖 15 : Json 格式
相同的資料用 protobuf 序列化後的大小大約是 json 格式的十多分之一，xml 格
‧
現制定出新的協定 spec 用於 WISE Middleware 和 WISE Platform 的結構化溝通。參考 HTTP 的封包格式來設計協定，並以物件導向中封裝的概念來實現所有動作，
只有兩種動作 GET 和 SET ，但搭配不同的行為設定可達成各種動作，像傳輸 WISE Item 資料，獲得 WISE Item PPS、連線狀態甚至是進行校正，反應回饋這樣較複雜的 行為，也進一步達成發現、監查、控制和互動這些在物聯網常見的行為。
表 9 : 協定結構
標頭欄位 內容值 描述 必頇欄位
Header wear/1.0
seq=${序列號}
‧
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
4.2.5 姿態歪斜問題
每組 WISE Item 都是獨立的，所產生的資料只代表每個節點的轉動情形，所以需 要透過影像模型將這些節點連接起來才能產生出全身的動畫，這種行為我們稱為『連 動』。透過連動將各組關節點連接起來，才能讓真實反應使用者各種姿態動作，像舉手 時，從上手臂、前手臂到手腕的提升便是連動功能產生出來。
但這樣的連動造成一個問題，如果連動組合中有某一節點突然斷線，其他節點仍 然正常產出資料時，連動效果的運算便會出現錯誤，這會造成整個姿態模型呈現歪斜 甚至擺出反轉 180 度這種不可能的人體姿態。當出現姿態歪斜現像時只能透過校正來 強制矯正，但卻讓表演中擺出校正姿勢的機率增加，也增添了中段表演的可能。
所以針對姿太歪斜進行了設計改進，將原來構成全身的獨立節點也跟著連動設計 進行分組，根據表現分為左上半身、右上半身、左下半身、右上半身四大組，身體中 線幾個重要的點則可以重複出現在不同分組中。當各個節點開始連線時，便會將這些 節點加入到連動組合中，WISE Middleware 傳輸資料時是向連動組合索取資料，當組 合判斷資料齊全時便正常傳出資料，反之則阻塞資料，這樣當節點斷線或無法取得資 料時，畫面會突然停住後再恢復正常，有效避免了姿態歪斜，讓使用者在表演中不必 擔心姿太歪斜而加入多餘的校正動作，而可以順利的進行演出。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 16 : 姿體模型四種分組
4.3 WISE Platform
WISE Middleware 負責管理和 WISE Item 的連接，然後和 WISE Platform 透過協 定進行管理溝通和數據傳輸。WISE Platform 分成四大模組: 分別是管理區域內裝置 的 WISE.local.coordinator, 不同區域間資料交換的 WISE.cloud.exchanger, 區域 內資料儲存管理的 WISE.local.broker 以及監控用的 WISE.local.monitor.
4.3.1 WISE.local.coordinator
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
線，和 WISE.local.coordinator 進行協定的交握。以約定好的協定開始資料溝通，
完成獲得設定檔、和 WISE Item 連線到傳輸姿態資料這完整的動作。
透過 WISE.local.coordinator 負責管理區域內所有的 WISE Middleware，透過人 眼可讀的 Json 設定檔(圖 17)，來設定增減底層的 WISE Item，設定檔中最外層以陣列 來進行多組設定，並透過預先定好的各個頻道 : "localTopic", "localAction",
"localPosition" 將姿態資料、感覺回饋資料、位置資料區分開來，讓各自的資料有 專屬的頻道來完成高性能即時傳輸。
圖 17 : WISE Item 設定檔案
除了管理各組 WISE Item 外，校正姿態也是重要的設定資料，可以視校正動 作來進行調整。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 18 : 校正姿態設定檔案
當然 Json 的配置和 protobuf 全然不同，無法直接傳給 WISE Middleware，因此 WISE.local.coordinator 也權當轉譯器，將 Json 和 protoBuf 雙邊的資料進行轉 換。Json 轉譯後的 protobuf 資料會透過協定通知 WISE Middleware 進行感覺回饋的 分發，而從 protobuf 轉譯成的 json 則放入 WISE.local.broker 發佈。
4.3.2 WISE.cloud.exchanger
當兩組以上的穿戴式裝置在不同區域執行時，會先透過 WISE.local.coordinator 將區域內的資料收集起來，在讓資料開始交換前會形成互不相連的獨立網路拓撲(圖 19)，要讓彼此間互動就必頇進行區域間資料交換，也開始牽涉到網路配置:
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 19 : 分開的各區域 圖 20 : Fully connected mesh topology
1. Public IP 間直接溝通 : 每組穿戴式的網路環境都配置一組 Public IP，直 接和其他區域進行連線與資料交換，當人數增加後會形成複雜 Fully connected mesh topology (圖 20)。從整體傳輸量評估，將每個區域視為一個網路節點，假設 N 個區 域即有 N 個節點，每個節點資料量都是 M Bytes ，交換資料時每個節點傳送 N-1 次資 料給其餘節點，這樣 N 個節點每次交換資料就有 N * ( N - 1) * M Bytes 的資料在 網路間傳輸，以整個網路環境管控、傳輸成本和向網路連線服務公司(Internet Service Provider)申請 public IP 的難度來說太高，所以忽略此方法。
2. 指定一個區域為公開的主節點，透過其進行交換資料 : 網路拓樸會因此形成 Star Topology(圖 21)，比起全節點設置 public IP，只配置主節點一個 public IP 相對來說容易。而整體傳輸量同樣假設 N 個區域 N 個節點，每個節點資料量都是 M Bytes。交換資料時每個節點傳送一份資料到中央節點，由中央節點統整資料後傳送 N - 1 次至中央節點外的節點，這樣 N 個節點每次交換資料時將有 ( N-1 ) * ( M + ( N-1 )
* M ) Bytes 的資料在網路間傳輸，可以感覺得出雖然傳輸量不變，但只需 N-1 條連
* M ) Bytes 的資料在網路間傳輸，可以感覺得出雖然傳輸量不變，但只需 N-1 條連