wifi在client & server之間的溝通- 更正

<request type="get_position">

<Map name="地圖名稱" />

<AP SSID="SSID1" strength="Strength" />

<AP SSID="SSID2" strength="Strength" />

<AP SSID="SSID3" strength="Strength" />

<AP SSID="SSID4" strength="Strength" />

...

</request>

request回應格式:

<Response type="get_position_success">

<Position x="X" y="Y" block_size="區塊大小" />

</Response>

RFID定位目前計畫-更正

1. 
   在資料庫儲存商品在地圖上的x,y座標位置 (假定同樣商品都會放在固定的位置)
   


2. 
   搜尋商品，先讀取兩個商品，以arc_tan((start1.y - start2.y) / (start1.x - start2.x))找出目前行進角度與方向，運算出到達目標商品的最短路徑。 (目前是假定無wifi，等wifi定位完成再想辦法整合)(由client運算)
   


3. 
   在地圖上標示可行進的點，作為計算最短路徑的依據。(須討論地圖的資料表示方式)
   


4. 
   Client將兩個起點與一個終點的座標傳至Server端運算出路徑，並傳回最短路徑陣列(以起點與終點表達單一直線路徑(start, end)，多個直線路徑組成一個完整路徑)。例如，傳入 start1(0,0), start2(0,10) , dest(10, 20)(螢幕左上角為 0,0)，假設走斜線有障礙物，只能走直線與橫線，則傳回 {Path[start(0,0), end(0,20)](先走直線，因目前方向為向南方走), Path[start(0,20), end(10,20)]}
   


5. 
   client請求格式:
   

   <Request type="find_path">
   <Map name="地圖名稱" />
   <Start      x="XX" y="XX" />  ->  目前位置
   <Destination x="XX" y="XX" />  目標商品的位置
   </Request>
   

   request回應格式:
   

   <Response type="find_path_success">
   <Map name="地圖名稱" block_size="區塊大小" />
   <Path>
   <Start x="XX" y="XX" />
   <End x="XX" y="XX" />
   </Path>
   <Path>
   <Start x="XX" y="XX" />
   <End x="XX" y="XX" />
   </Path>
   ...
   </Response>
   

這是目前的計畫，有問題可以提出。

CheckOut 的XML格式-更正

client 向 server 提出 checkout 要求時的XML格式

<Request type="checkout">
　　<account id="會員編號" />
　　<products>
　　　　<product id="編號" amount="數量"/>　
　　　　<product id="編號" amount="數量"/>
　　　　　　　...
　　</products>
</Request>

之後 server 會回傳以下的XML

＜Response type="checkout_success"＞
　　＜cashier id="收銀檯編號" /＞
＜/Response＞

剩餘的工作

1. 測定新的Sample點
   
   • 測定T4五樓的Sample點
   • 將Sample點資料輸入到資料庫
     
     
2. 測定WIFI的訊號精準度
   
   • 測量WIFI block的距離
     
     
3. 結帳部分
   
   • 結帳端圖形介面
     
   • 結帳端程式與圖形介面整合
     
     
4. Server端
   
   • 整合結帳部分程式
   • 完成get_position response：WIFI block 與RFID block的換算
     
     
5. 用戶端
   
   • 整合WIFI訊號偵測程式
   • 完成get_position request
   • 結帳功能
     

Server端的資料

有關於Server端的資料，都放在 ftp://tw-yen.no-ip.org/server裡
推甄有需要用到的，請自行前往下載。
如果需要的資料不在上面，可以跟我要。
如果有要補充的資料，請自行放上去。(可匿名登入)

目前行數:3288行(含註解與空行), 2245行(不含註解)
Server端使用之平台(Windows Server 2003)...比較不會當機
CPU: Intel core 2 E6300, 1.86GHZ
Memory: 4GB

Server端的設計理念是：必須能承受同時多個請求又不過度取用資源，功能方面也必須能夠簡單地擴充。

目前曾對Server端做過5000筆資料的壓力測試，執行至今軟體本身沒有發生過異常(作業系統當機除外)。(可參考之前阿汶做的測試)

曾遇到比較有趣的問題：

1. 多執行緒同步問題。
2. 資料編碼格式問題。(編碼為UTF-8，然而在傳輸時常忘記轉碼)
3. 功能擴充問題。(在軟體設計上獲得解決)
   目前的軟體設計，予許在只更動 MarketRequestType的狀況下，就能新增一個可處理的請求型態。想要新增一個請求型態，只需要先把特定的Responder寫好(實作Responder介面)，並在MarketRequestType類別裡註冊請求型態與處理該型態的Responder即可。

由於處理請求的Responder實作類別還可以不斷擴充，我沒有把這些類別畫進類別圖裡。FTP裡的類別圖只是初稿，後來有經過一些細微修改，但大致上無太大改變。

有問題可以提出。

目前於PDA上開發的諸點困難

RFID Reader -
目前大部份的 Rfid 專案是使用 PC 作為平台，且市面上所見書籍也幾乎是以PC為例

Mysaifu( Java 虛擬機器 )
Mysaifu和原本PC的Java虛擬機器相比，功能有相差或欠缺之處

性能 -
PDA無法完美地使程式運行順暢，記憶體的限制使得程式無法載入所需的複數圖片

連線 -
目前借到的PDA未能解決連線問題

RFID Reader 賣場搜索

===使用SDIO介面(可裝置在PDA上)=====

reader
HF
$13500

===使用USB介面(可能無法裝置於PDA上)=====

reader
HF
$3900

reader
HF
$3150
備註 : 友鵬科技

Production XML 回覆格式變更

增加 "photo"
12/25 增加 x 和 y 的屬性

<Response type="product_found">
    <account level="3" />
    <product id="01010001" name="商品1" onsale="true" price="1000.0" expiration="30" manufacturer="NTUST" detail="" x="0" y="0">
         <photo> 編碼 </photo>
    </product>
</Response>

參考用網址(感謝 Yen )

結帳XML(暫定)

<Request type="checkout">
<account id="??" />
<product id="??" amount="數量"/>
</Request>

傳送帳戶ID與商品ID即可。
同樣的商品若有多個，則設定amount屬性。

確認結帳的必要性再討論。
取消結帳則發送不含商品資料的結帳request即可。

定位組目前規劃

以先前所找到的paper定位方法進行實作:

架構如左圖
由client端偵測user AP強度傳給server端做定位計算

server端程式:
處理定位以及回傳位置的main
三個演算法各一class
以及一個紀錄參考點的database







三個演算法的整合想法如下:
P(x,y) = α Fun(knn) + β Fun(PDF) + γ Fun(RBFS)

目前大概模擬為 γ > α > β

(RBFN耗費以及定位精確度皆為中等 故假設加權最大，PDF計算時間最常精準度最低，到時可能會捨棄)

計劃表:
1.模擬一個database始可模擬演算法
2.先著手 KNN 以及 RBFN 演算法程式 最後PDF
(因RBFN算式較複雜，視狀況而定 可能僅採用KNN演算法( KNN是三者中定位效果最好的))
3.做好計算的main
4.做測量AP的程式(用於建立sample node 以及user的AP偵測)
5.建置sample node，完成database
6.實際測試再行修改

觸發程式時機:
定位系統發現所屬區塊變化時跳出新區塊的特價訊息(選擇性)
---為達此功能 須自動定偵測位置
使用者要求
---傳送要求時執行