第二章 相關研究
2.3 資料交換格式
The Internet of Things (IoT) is a system of physical objects that can be discovered, monitored, controlled or interacted with by electronic devices which communicate over various networking interfaces, and eventually can be connected to the wider Internet.[7]
這段話裡帶出了許多核心，基本的物聯網在於滿足 : 1. 整合由各種硬體設備所形成的獨立網路集合。
2. 要透過單一的協定來接軌各個系統是很難達成的，所以設計上要能兼容多種協定。
3. 有眾多通訊介面待整合，需要 Middleware 的存在來作為溝通的橋梁。
因此在本論文設計的軟體平台中，依照網路集合實現 BLE、Wifi 等短距離通訊網 路的區域內感測信息互聯互通，透過 middleware 兼容不同裝置並和長距離通訊網路連 接，透過不同模組以及定義不同模組間的協定來達成實現互聯、識別和管理的核心平 xml，json 都是這類應用的翹楚格式，此外還有較新的 Protocol Buffers（簡稱 protobuf）。 Protobuf[8]是谷歌的一項新技術，也用於將結構化的數據序列化、反序
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
列化，常用於網絡傳輸。
在本論文穿戴式的設計中，涉及到資料即時性、更新速率和低延遲需求，所以在 資料處理上，需要往減少資料量、縮短資料處理時間的方向走，protobuf 其設計特性 剛好著重在資料更小、處理更快，更重要的是兼容性好，不必擔心因為未來的改變而 造成大規模的代碼重構，所以在資料傳輸以 protobuf 作為傳輸時的資料結構。
表 5 : 交換格式比較
協議 跨語言 傳輸量 性能 可讀性
Xml 大量支援 很大 低 佳
Json 大量支援 一般 一般 佳
protobuf 大量支援 低 高 較差
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
第三章
硬體擴充
第二章中介紹了原本使用的硬體，而在這次研究中將有許多更動，除了各種不同 感測器和反應器，像震動器和 LED 的加入外，還要根據應用的需求能自由裝載反應裝 置。這樣的變動將從體積、成本、耗電量、功能性和擴充彈性作為調整目標。
3.1 評估反應裝置
互動時的各種感覺回饋需要靠反應器來作用，像觸覺的震動器、視覺的 LED，需 要在原有硬體上擴充這些裝置來達成。這次評估了相當多的零件，畢竟市面上的震動 器零零總總加起來就達數十種之多，各種大小厚薄、不同耗電量、類型的裝置一堆，
經過多元測試後，在零件海裡選擇了鈕扣式震動器(圖 6)和全陽三色 LED(圖 7)。同時 透過 Arduino 程式對腳位數位或類比寫出( digitalWrite / analogWrite )來控制裝 置，除了通電外，透過 PWM (Pulse Width Modulation) 讓數位訊號高頻率的切換，
以調整開關的比例，可以模擬出震動和需要的燈光顏色。
表 6 : 震動器規格
圖 6 : 震動器 圖 7 : 全陽 RGB LED 腳位
型號 直徑 厚度 工作電壓 電流 售價(台幣)
MT01 10mm 4mm 3.7V 0.06a - 0.10a 40
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
3.2 評估擴充彈性與體積大小
視需求來自由裝載裝置，得對電路板增加插排設計，需要對 Arduino NANO 各腳位 進行認識 (表 6)，在電路板上保留可插拔的 pin 腳對應 Arduino D4~D12 腳位以及多 增加 3 組 VCC-GND 維持供電，軟體方面則透過配合 Arduino 程式對不同針腳進行不同 操作，就達成擴充裝置的多功能性，也保留高彈性來針對不同目的搭配周邊裝置。最 後設計好的硬體命名為「WISE Item」 (圖 9)。
表 7 : Arduino NANO 的腳位規範
晶片組 Atmel ATmega168 or ATmega328 Digital I/O D0 ~ D12 數位輸出/輸入端
D13 作為 LED 指示用 D0、D1 通常不建議使用 因為常作 Serial Port 傳輸使用 D3, 5, 6, 9, 10, 11 亦是 PWM 腳位 Analog I/O A0 ~ A7 類比輸出/輸入端
當 Digital I/O 不夠時可充當使用，
宣告為 Pin 14 ~ 21
TX / RX 支援 TX / RX 訊號輸出輸入 D0 亦可為 RX 接收端 D1 亦可為 TX 傳送端 輸入電壓 1.8V - 5.5V
‧ 國
立 政 治 大 學
‧
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 度這種不可能的人體姿態。當出現姿態歪斜現像時只能透過校正來 強制矯正，但卻讓表演中擺出校正姿勢的機率增加，也增添了中段表演的可能。
所以針對姿太歪斜進行了設計改進，將原來構成全身的獨立節點也跟著連動設計 進行分組，根據表現分為左上半身、右上半身、左下半身、右上半身四大組，身體中 線幾個重要的點則可以重複出現在不同分組中。當各個節點開始連線時，便會將這些
所以針對姿太歪斜進行了設計改進，將原來構成全身的獨立節點也跟著連動設計 進行分組，根據表現分為左上半身、右上半身、左下半身、右上半身四大組，身體中 線幾個重要的點則可以重複出現在不同分組中。當各個節點開始連線時，便會將這些