行政院國家科學委員會專題研究計畫 期中進度報告
子計畫四：抗流型水下遙控載具之感應器系統整合(2/3)
計畫類別： 整合型計畫 計畫編號： NSC94-2611-E-110-003- 執行期間： 94 年 08 月 01 日至 95 年 07 月 31 日 執行單位： 國立中山大學海下技術研究所 計畫主持人： 王兆璋 共同主持人： 程啟正，陳信宏 報告類型： 精簡報告 報告附件： 出席國際會議研究心得報告及發表論文 處理方式： 本計畫可公開查詢中 華 民 國 95 年 6 月 1 日
抗流性水下遙控載具(ROV)關鍵性技術開發及系統整合
子計畫四：水下潛航器之感應器系統整合
Integration of Sensory System for Remotely Operated Vehicle
NSC 94-2611-E-110-010 主持人：王兆璋 共 同 主 持 人 ： 程 啟 正 陳信宏 研 究 人 員 ： 羅 世 倫 陳柏棋 周駿宏 摘 要 操控水下遙控潛器時需將感測器資料（磁羅經、深度計及環場聲納等）上傳 至水面，並將命令下傳至受控元件（推進器、攝影機、燈光）。水面控制台與潛 器船載電腦間的通訊，使用序列埠（Serial Port）。受限於可用的 RS232 序列埠 通道數，我們並無法將所有的感測元件資料以一對一的方式上傳，而是利用資料 合流及分流的技巧，僅用一個高速 RS232 通道(Baud Rate 115200)來達成這個需 求。因此相對應於水面控制台而言，由於接收到的是感應器原始資料，所以這個 傳遞的架構相對於使用者而言是透明(transparent)，換言之水面控制器可以對任 一通道做資料處理，而無須考慮資料傳遞的方式。由於水面下的感應器可以隨時 任意變換連接的通道，而不必修改程式，僅需在水面控制器重新指定相對應的通 道即可。因此這個架構提供操控程式維修上的彈性。
一、前言
ROV 操控系統分為水面上控制台子系統 及水下潛器控制子系統。ROV 所處的水下環 境藉由各種感應器探索後將資料上傳；操控 者綜合判斷感應器資料後下達控制命令。我 們並不直接從水面控制潛器上的推進器或燈 光，而是將命令下傳後，再由潛器上的電腦 代為執行。採用直接傳輸的話，一個感應器 需要一個通道，命令也需要一個通道，這樣 的架構訊號纜繩必須預留比較多的蕊數，纜 繩線徑也會因此加粗不利 ROV 航行。另一種 作法是建構一個資料合流及分流的通訊機 制，將所有的感應器資料在潛器端彙整後，再 透過一個高速的 RS232 串列埠或光纖通信上 載。水面端的控制台再依據通信協定分流出各 個感應器通道的原始資料，以供控制程式使 用。資料與命令一來一往的傳輸間，各種資料 的傳輸量與更新率因感測器的規格皆不相同。 所以在整個系統中就會有著好幾種不同的傳輸 頻率、資料流量及更新速率。目前我們規劃的 環境感應器有深度計、高度計、磁羅經、傾角 計與環場掃描聲納。除聲納 BAUD Rate 為 115200 bps 之外，其餘皆為 9600 bps。潛器上 的受控元件有推進器、燈光及攝影機 PZT。圖 3: 資料合分流機制流程
二、硬體配置
水下控制電腦採用 PC104 的規格。它將 一般桌上型主機板所有的 IO 如鍵盤、滑鼠、 多媒體、網路、顯示，甚至 CF 卡等都縮小在 一片面積不到 A4 四分之一大小的電路板實 現，如圖 1 所示。CPU 為 Pentium 1G, 256M RAM. 我們採用的 PC104 上具備有四個序列 埠（Serial Port），我們使用其中一個序列埠 來做 Data Link，其餘的三個序列埠則是接收 ROV 的感測器的資料。如果感測器增加時， 亦可加上一片 RS232 擴充卡以提供另外四個 串列埠。三、資料分流合流機制
我們設計的主要標的是：(1) 感應器的原始資 料可以無誤地中繼至水面上控制台；(2)感應 器所連接的串列埠可以隨意變換而無須修改 程式；(3)感應器啟動的個數或時間無須同步； (4) 各 個 感 應 器 可 以 有 獨 立 Baud Rate 及 Refreshing Rate；(5)命令之傳遞也依循一樣的 邏輯。基於這些目標，我們為感應器資料及命 令傳遞設計以下的合流與分流的通信機制（如 圖二所示）。 圖 1:PC104 實體 感應器資料合/分流 1. 運算核心以即時執行緒(Realtime Thread) 的方式定時中斷，依序對所有的串列埠蒐 集資料。目前我們設定 20Hz，因為以 1024 Bytes 的暫存區而言，在 Baud Rate 115200 bps 的速率下應可穩定擷取。 圖 2:資料上下鏈結 2. 每一個通道所收到的資料，在前後加上 「#?」及「?%」當成識別符號，其中「?」 處代表串列埠的編號。選擇「#」和「%」 當成通道區隔是因為我們所有的感測器資 料格式中並未使用這兩個字元。 3. 串接後的資料流(Data Stream)混雜著不均 勻且不連續的通道資料。控制台解讀程式 將依序尋找資料流中成對出現的「#」和 「%」，像四則運算中的括號運算一樣， 一對括號中夾帶的就是某一通道的部分資 料。資料堆疊到相對通道的暫存器後便呈 現出原來通道資料的原始形式。 以上的感應器資料中繼處理流程如圖 3 所示。控制命令 控制台對潛器的命令有推進器的出力方向及 大小、燈光之開關、攝影機鏡頭之 PZT 轉向 及機器手臂操控。我們設定的命令下載流程 因為資料量少，則是藉由欄位分隔符號和 CRC 檢核碼的方式傳遞。介紹如下： 1. 為了達到資料同步，我們在資料串(Data Packet)的前後加上「$」及「#」當成區 隔，而不同命令間則以「,」分隔。 2. 目前我們的潛器一共配備有五個推進 器，字串中“$”之後以逗號隔開的 5 個整 數為推進器轉速命令。此數值控制 DA 卡輸出類比參考電壓控制推進器轉速。 數值範圍介於 0 到 255，對應到±5V 推進 器命令電壓範圍。 3. 接續的四個數值為攝影機 Pan-Tilt-Zoom 及對焦的控制命令，1, 0 及 2 分別代表正 向調整、反向調整及停。 4. 最後的三個數值為燈光開啟及關閉。數 值 0/1 分別由水下控制電腦 IO Port 輸出 TTL 位準以控制燈光電源繼電器。 5. 最後一個位元組則為 CRC8 檢核碼。 範例 ”$127, 0, 127, 0, 0, 1, 1, 2, 2, 1, 1, 1\126#” 命令解讀程式拆解後，分別為： 推進器 Thruster1: 停止；Thruster2=-5V; Threster3: 停止；Thruster4=-5V; Threster5: -5V 攝影機
Zoom-in, Focus-in, Pan-left and Tilt-Up=2; Focus=2;
燈光:
Light1 開、, Light2 開及 Light3 開。
四、實驗
1. 感應器種類與資料格式 z 磁羅經+傾角儀： $PTNTHPR,130.5,N,-0.1,N,-0.3,N*31\n\r 長度不固定，資料串之間(Data Packet)由「$」 區隔。 z 深度計： +078.50,+123.24\n\r 長度固定為 17 Bytes. z 高度計 100.00m\n\r 長度固定為 9 Bytes. z 環場聲納： 由大量複雜 Binary Data 組成，需要由專用軟 體才能解讀。 資料彙整程式會定時（目前設定 2kHz）查詢各 個感應器通道是否有回傳資料。由於目前的串 列埠大多有 FIFO 暫存器，因此如果資料格式 長度較短時，一次便可將完整資料攫取完畢。 不過有些感應器資料長度超過 FIFO 長度，會 產生資料必須耗費查詢週期才能傳輸完畢的情 形。 2. 辨識符號與資料合流 以符號「#」為開頭符號，接續一位數字通道編 號：符號「%」為結尾符號，前導一個對應的 數字來標示資料結尾之對應通道。由於各個感 應器的資料格式、長度、Baud Rate 及更新速率 皆不同，因此上傳的資料串會有交錯各通道資 料的現象，如下範例。 #3,+123.24\n\r$PTNTHPR,130.6,N,-0.2,N,-0.3,N*31,3%#4+078. 50,+123.244%#3$PTNTHPR,130.6, 3% 可以看出當程式啟動時，並沒有抓到通道 3 的 資料起始位置，而是涵蓋部分前次資料與部分 本次資料於第一次上載通訊中。接續而來交錯 通道 4 的資料，依此類推。這個程序如圖 2 下 半部所示。 3. 辨識符號與資料分流 資料串中繼至水面控制台後，再依據分隔符號 一一拆解堆疊至通道的暫存區。除了程式開始 擷取資料之初可能接收到前一次殘缺的通道資 料外，理論上所有後續的資料都應有成對的起始(#)及結尾($)符號。不過為了確保資料的正 確性，如果通訊出現不同步現象，導致配對 不正確時，則從資料由後向前尋求配對，捨 棄多餘資料。這個程序如圖 2 上半部所示。 資料堆疊至對應的通道暫存區後，控制 器的感應器資料處理程式便可以約定的資料 格式，依序將所需的物理量，如深度、角度 等擷取出來。
