3.4 輪式機器人運動路徑設定
3.4.2 SVM 障礙物偵測與碰撞法
使用 SVM 判斷障礙物偵測並根據實驗 1 之方法作為行走角度之依據(有碰撞 偵測)，規則如下：
1. 通知 base 端發出聲音，得到六個頻率之 phase-difference 參數，將其丟入 SVM 計算，判斷機器人對於聲源為 LOS 或是 NLOS。如為 LOS，機器人 根據聲源相對於機器人之角度θ旋轉，並前行如過程有碰撞，則往後退，
並進入 step 2，無碰撞則判斷是否到達 base 端，未到重複 step 1。如為 NLOS，進入 step 2。
2. 根據θ角旋轉，並紀錄旋轉方向α ，再次通知 base 端發聲，得到 phase- difference 在由 SVM 判斷 LOS 或 NLOS。如為 LOS，則代表前次判斷可 能誤判，進入 step 3，如為 NLOS，則確定確實有障礙物在前方，進入 step 4。
3. 機器人根據 LOS 判斷出之角度θ 旋轉1 θ 角，並前行。回到 step 1。 1 4. 根據旋轉方向α 旋轉 10 度，在往前行l=30公分，如有碰撞，則後退在旋
轉α 方向 10 度，在前行，紀錄次數 count，直到無碰撞發生，進入 step 5。
5. 依旋轉方向α 之反方向旋轉回10×count，回到 step 1。
為能夠改善實驗 1 需要經過碰撞之後才能知道障礙物的存在，加入 SVM 的 判斷，使機器人能夠在撞到障礙物之前即能知道已經面對障礙物。當機器人判斷 不在障礙物附近，即使機器人直接根據 phase-difference 所算出角度方向前進。當 機器人在障礙物附近，根據實驗 1 的行走方法。行走過程如圖 13：
Step 1 Step 1 Step 2
Step 3 Step 4
Step 4
Step 4 Step 1
Ｌ Ｏ Ｓ Ｌ
Ｏ
Ｓ ＬＯＳ
N
前行 轉回θ+10*count
Ｌ Ｏ Ｓ
N
Ｌ Ｏ
Ｓ ＬＯＳ
圖 13 平台行走示意圖(2)
SVM 碰撞行走流程圖：
θ旋轉，然後再要求聲源發聲一次，計算第二次聲源位置，如果此次角度在90±10 以內，那代表我們正確的找到聲源了，如果不是則代表初始時移動平台可能背對 聲源或其他情況，此時就使移動平台往右旋轉90±θ，再重新判斷一次，直至找 到聲源為止。規則如下：
1. 通知聲源發聲，並計算出相對角度± (正代表平台往右轉，負代表平台往θ 左轉)，平台根據θ 旋轉。
2. 再通知聲源發聲一次，計算出第二次相對角度，如果此時角度在 10± 度以 內，代表找到聲源，就往前進，回到 step 1。
3. 如角度超越了 10± 度，代表第一次旋轉有問題，未能讓移動平台正對聲 源，此時讓動平台往右旋轉90±θ，然後再回到 step 1.
重複上面的動作，就能夠讓移動平台在 LOS 的行況下，往聲源移動。流程圖 如圖 15 所示：
start
計算角度 並旋 轉θ
， 通知聲源再發聲一次 判 斷角度是否在 度以內±10
?
±10
往右旋轉 90±θ Yes
No
圖 15 LOS 聲源判斷流程圖
3.5 基地端
基地端基地端基地端(base)與輪式機器人結合動作與輪式機器人結合動作與輪式機器人結合動作 與輪式機器人結合動作 3.5.1 全方位運動平台分析全方位運動平台分析 全方位運動平台分析 全方位運動平台分析
全方位運動平台使用特殊結構的輪子，一般稱為全向輪(omni-directional wheel or omni-wheel)；它可以將地面作用於輪子上的摩擦力之中平行於輪軸的部 分，藉由滾子的轉動而分散掉；因而，造就了全向輪平台所擁有的獨特運動模式。
實際上，全向輪的構想早在 1910 年就發表於美國的專利文件中，截至目前，
為了提高效率及改善震動的缺點，已有許多改良的全向輪被發明使用，而現今也 已被使用在搬運車、輪椅或輪式足球機器人等方面。圖 16 中共列出三種不同型 式的全向輪，(c)是目前我們正在使用的全向輪。從平行於輪軸的方向看過去，其 形狀就像是一般傳統的輪子。
(a) (b) (c) 圖 16 不同型態的全相輪
我們的機器人平台共使用三顆全向輪，較使用傳統輪子的二輪或四輪式的機 器人擁有較高的運動自由度；經由三顆輪子所產生的多種合力組合，共可以產生 多達五種運動模式，包括：原地旋轉、對頭直行、對頭差速轉彎、平移、平移且 自轉。
在此平台中使用三顆全向輪，如圖 17 所示，三輪之間各夾 120 度角，為這 個移動平台最大的一個特點，這種構造使得這個平台得以呈現較一般輪式平台更 多樣化的運動模式，在此將詳細探討這種構造的運動學理論[15-18]。
圖 17 全向輪平台簡圖
圖 18 全向輪簡圖 在圖 17 及圖 18 中，各項符號的意義表示如下：
(a) x、y、z：定義在平台上的座標系，下面推導中的向量皆相對於本座標系。x、
y 如圖所示，而 z 軸為指出紙面為正。
(b) vv
：希望平台移動之速度向量。
(c)
ω
v：希望平台轉動之角速度向量，且定義沿著反時針方向旋轉為正。(d) Fn
v
：垂直於各輪軸之單位向量，n = 1,2,3。
( )
0 1, 0, 0
F = − v
1
1 3
, , 0
2 2
F = −
v
(28)
2
們可知，同是表示各輪軸心端點速度的Yn
馬達 馬達
(a) Rotation (b) Go ahead
馬達 馬達 馬達
(c) Differential Turning (d) Translation
(e) Translation and rotation 圖 19 運動模式示意圖
3.5.2 結合運動設計
結合運動設計 結合運動設計 結合運動設計
在平台根據聲音判斷順利的靠近 base 端，即進行平台與 base 的結合。為了 能夠讓平台在結合後能夠載動 base 端行走，因此我們設計平台使用上下結合的方 式，並分別在兩邊的結合面上，佈上一圈的磁鐵，讓他們在結合後可以更為穩固。
由上一節所提到的全向輪運動方式，將會使用在結合過程中。結合的過程主要分 為兩個部分，第一部分為移動平台進入 base 前與 base 端的對準，第二部分為移 動平台在進入 base 後，兩方上下位置的對準，在進行提升結合動作結合。
為了偵測移動平台是否到達 base 端附近，我們於 base 門口的左右邊各放置 一個紅外線感測器，當平台從 base 端的左邊靠近被偵測到時，base 將通知平台往 右邊行走一個弧線，直到平台走到 base 端的中間為止。此時可以確定平台在 base 前面，但是不能確定平台是否正對著門口。於是我們在 base 端正中間加上一個光 敏感測器，平台正前方放置發光二極體，做面對門口的校正。當平台畫完弧線以 後，在往左旋轉40 ，然後開始往右邊旋轉掃描光敏感測器是否有變化，如偵測o 到變化，即停止旋轉。
接下來進行結合的部分。為了讓平台與 base 能夠大概的上下對齊，我們於 base 中央部份佈了一圈光敏感測器(8 個)，移動平台正中間放置發光二極體，利用光 的特性來做對正。如圖 20 所示：
當平台進入 base 端，位於 base 端的光敏感測器會有如圖 21(a)之變化，此時 平台便利用全向輪特有的移動方式，平移來做微調的動作，使光敏感測器得到較 為平均的受光量，如圖 21(b)。如此可以確保機器人上下兩端中心位置已經大約 對準，接著移動平台便將自己的外殼升起，與 base 端結合。
1 2 3 4 5 6 7 8
20 30 40 50 60 70 80 90 100
Sensor numbr
intensity
ideal
sensor
1 2 3 4 5 6 7 8
20 30 40 50 60 70 80 90 100
Sensor number
intesity
ideal
sensor
(a) (b) 圖 21 光敏感測器感測圖
第四章 第四章 第四章
第四章 系統軟硬體設計與實現 系統軟硬體設計與實現 系統軟硬體設計與實現 系統軟硬體設計與實現
4.1 整體系統架構
整體系統架構整體系統架構整體系統架構系統大致分為三個部分，由一台 PC、全方位移動平台、base，所組成，如圖 22 所示：
圖 22 整體系統示意圖
PC 端主要功能為撥放複頻聲音訊號，移動平台上有由 TI 所發行的嵌入式系 統實驗板 OMAP 5912 OSK，主要演算皆在此實現，於 base 端上設置有 Access Point，用以連接三方的通訊，互相傳遞控制訊號與感測器資訊。詳細系統架構圖 如圖 23 所示：
Power Supply
Wireless LAN card
Two channel
Mic array AIC32
Motor
controller Optical flow controller UART
USB
ARM DSP
Battery
PIC ethernet PIC ethernet Access Point
Wireless LAN Card Play Sound
IR sensor Photo resistance
IR controller Photo controller
圖 23 系統架構圖
4.2 實驗平台
實驗平台實驗平台實驗平台整體系統主要以 TI 所發行的 OMAP 5912 OSK 為實驗核心平台。OMAP 5912 為 Dual-Core 處理器，包含了一個 GPP(General Purpose Processor)：ARM926EJ-S，
與一個 DSP(Digital Signal Processor)：TMS320C55x。所謂 DSP 與一般的 Processor 架構上有所不同。訊號處理上，常需要有大量的乘法運算或者重複的運算過程一 直發生，使用 GPP 做運算會浪費許多時間，因此造成了 DSP 的產生。DSP 使用
硬體設計實現單週期乘法運算，相對於 GPP 的多週期乘法快上許多。因此有了 Dual-Core Processor 的整合。圖 24 為 OMAP 5912 之硬體架構。
圖 24 OMAP 5912 架構圖
OMAP 5912 對 ARM 926 與 TMS320C55x 做了高度的整合，使兩個處理器能 夠做彈性的分工，擁有高處理效能與低耗電的特性。
圖 25 OMAP 5912 OSK外觀
表 2 OMAP 5912 OSK Hardware list
4.2.1 軟體開發環境
軟體開發環境 軟體開發環境 軟體開發環境
爲了使程式能夠順利於 OMAP 端執行，需要以下幾個工具，為其建立開發環 境：
1. PC 端 Linux 作業系統 2. Cross-compiler[19]
3. DSP-Gateway[20]
4. Code Composer Studio(CCS)
Linux 作業系統
一般來說嵌入式系統受限於 processor 速度與記憶體大小，程式開發者不可能 直接於嵌入式系統板上直接開發程式，因此我們需要一個平台作為 OMAP ARM
端程式的開發環境。程式開發者有兩種選擇為自己準備開發環境，若手邊有多餘 的 PC，則直接於 PC 上架設一 Linux 系統即可。若無多餘的電腦，使用 VMware 虛擬機器軟體是另一個選擇。VMware 可以模擬 x86 架構的電腦系統，除了執行 x86 指令外，還可以模擬其他週邊設備，如：網路卡、序列埠、串列埠，等等。
也就是說使用 VMware 就可以在作業系統中，模擬另一個 PC，如此就可以在同 一台電腦上擁有多個不同的作業系統。
在此我們直接架設一台 PC 作為開發 OMAP ARM 端程式所用，使用 Fedora Core 5.0 Linux 作為作業系統。
Cross-compiler
如上所提，嵌入式平台不會有多餘的記憶體來直接編譯程式，因此需要由其 他機器產生嵌入式系統端的程式執行檔，在放進嵌入式系統上執行。在這裡我們 的發展平台為 x86 架構的 PC，與目的端 OMAP 5912 的 ARM 處理器使用不同的 指令集，並不能直接使用發展平台裡的 GCC 作為 compiler。因此需要一套可以編 譯出 ARM 端指令集的 Cross-compiler 來為我們做編譯程式的動作。
我們使用 arm-linux-gcc-3.3.2 工具組作為我們的 cross-compiler。
DSP-Gateway
如同一開始所提，OMAP 5912 為一 Dual-Core processor，包含了 ARM926 處 理器與 TMS32055x 數位訊號處理器。而 DSP-Gateway 則是讓在 ARM 端執行的 Linux 能與 DSP 溝通的一套軟體。
ARM 與 DSP 的溝通主要透過下列三種形式：
1. Mailbox
ARM 與 DSP 可以透過 Mailbox 的中斷來做資料的交換，當 ARM 把資 料寫進 DSP 時，DSP 會收到一個 Mailbox 中斷，DSP 借由中斷即可拿取 ARM 寫進來的資料。因為透過這個方法資料流量不能太大，不適合做大 量的資料傳輸，通常拿來作為通訊協定、傳送命令、參數等。
2. MPU Interface(MPUI)
MPUI 可以讓 ARM 存取整個 DSP 的記憶體空間與 DSP 的周邊匯流 排，因此 ARM 可以擁有 DSP 輸出輸入空間的完整存取權限。ARM 便是
MPUI 可以讓 ARM 存取整個 DSP 的記憶體空間與 DSP 的周邊匯流 排，因此 ARM 可以擁有 DSP 輸出輸入空間的完整存取權限。ARM 便是