期中報告回饋

謝謝其他專題生的回饋及指教，以下為對我們期中報告的各篇心得連結：

【阿達】閱讀『用於輔助認知障礙者就業之行動定位社會網路』心得
【駿】"用於輔助認知障礙者就業之行動定位社會網路" 閱讀心得
【秉霖】閱讀『用於輔助認知障礙者就業之行動定位社會網路』心得感想
【Juan】用於輔助認知障礙者就業之行動定位社會網路
【Kinmen】用於輔助認知障礙者就業之行動定位社會網路-讀後看法
【JACK】對於吳國志 張道文 期中報告之評論
【CHI】閱讀"用於輔助認知障礙者就業之行動定位社會網路"心得
【Ilikepie】閱讀"用於輔助認知障礙者就業之行動定位社會網路" 報告心得

在這裡對各位的意見做個整理，大家對我們的報告最主要的問題在於格式，如英文摘要不夠長，或是用字之類的問題；再者是對於本報告未來展望還可以更詳細、更具體。

看到大家的回應之後，發覺真的有很多細節是我們沒有注意到的，果真受益良多。經過同儕之間的互動，能夠看得更多，也希望各位老師或學長姐們，對於我們的報告給予建議。

接下來的時間將進入期末考，專題的進度也暫停，待期末考過後再接再厲！

期末考前的程式碼研究

上週六花了些許時間，將Web Service寫出來。

經過之前學長的仔細指導，以及範例指引，已經將Web Service的雛型做出來。我們使用了Subversion(SVN) 搭配Google Code 進行專案管理，並進行版本控管，我先對這部份先行解釋。

版本控管的好處是在於寫程式時，因為不斷的更新修正，一定會出現很多版本出來，利用版本控管，除了能夠可以作Code Review之外，對於在程式碼寫作時的錯誤，可以立即的回覆最近正常的版本。再者，對於多人合作的專案時，利用版本控管，能夠了解夥伴們之間的編寫狀況，並適時討論。而最重要的，除了在家編譯外，在伺服器端也製作一份做為同步，確保檔案為最新版。版本控管的功能還有很多，如可以參考MaoYang的版本控制圖解指引 。

我們選用的SVN為集中式的版本管理系統，近期比較熱門的分散式版本控管如Git或Google Code支援的Mercurial，但是因為使用需求不大，因此還是以SVN為主。

這次的程式碼（點此 ）有三項功能，一個是系統內建的Hello World，另一個是將傳送回來的值製作成xml的FindHelp，還有計算距離的range三個。FindHelp是將GPS送回來的數值儲存為stu_data.xml，再來告知range所限制的範圍後，依照此檔案來進行距離運算，並送回告知有多少位置在符合距離之內。

Server的部份大致上是完成，之後要製作的部份就是PDA上的程式以及Google Maps這兩部份。

閱讀「認知障礙者自動尋徑室內導航系統」報告心得 by 小志

　

前面提及了章節概要，讓閱讀者馬上知道接下來在各章節會得到什麼資訊，這樣的寫法很棒。

說明圖片豐富，對於環境的設計與架構的設定很清楚的表現出來，而這組也很用心的跟學校申請學校建築設計圖，讓實驗規劃上能夠更加幫助。

他們在PDA上設計前，會在電腦端製作測試程式，之後再轉植在PDA上頭。這樣的方式可以讓開發者能夠先對設計出來的程式碼進行檢測，了解系統演算的狀況是否達到正常，之後再來製作PDA的版本。

本報告是目前實驗室專題報告當中，最完備的一組，這組的程式大多完整，現階段是修正與提昇的設計，相信是我們其他組別的模範。

閱讀「具有『多點出發/走失返回/使命必達』功能的新式認知障礙者室內導航系統」報告心得 by 小志

　

這篇是我最早看過的一篇，因為當初在寫報告時曾參考過，所以先謝謝兩位。

整個實驗的架構不難，就是在區域架設藍牙節點，藉由手機讀取各節點了解所在位置，所以整個實驗部份應該著重在程式部份。而這部份也是比較麻煩的，演算法的設計就是很大的重心。文中提及是接收到藍牙資料後撥對應影片，但是如果遇到了方向性的問題時，我想這樣多少會造成一些困難，或許可以找找有沒有辦法計算出使用者與藍牙的距離，藉由距離移動的狀況應該可以分析出使用者的方向移動狀態。

影片部份，我突然有想到，若是支援播放GIF動畫檔案，因為GIF動畫檔案應該會比影片小吧！再配合提示音效，所以你只需要製作一組音效，音效設計方式可以參考PAPAGO等導航軟體的設計方法，或許這樣設計會變得比較簡單。

另外傳來的報告檔案，追蹤編修紀錄都還在，或許在完稿時要把他核對掉會比較恰當。

這篇報告的標題改過幾次，最後一次的修正我還蠻震驚的，使命必達這四個字放進來，感覺壓力就好大，不過相信這會讓你們能夠將這個專題做到最好的一個動力吧！大家一起加油！

閱讀「應用RFID實現精障者工作辨識」報告心得 by 小志

　

對報告中所提及的三種演算法感覺很棒，除了類神經比較常聽到之外，其他兩種的演算方式就比較陌生，讓我學到更多的演算方式，一直以來都有想要修演算法課程，不過因為學分不夠及時間都卡到沒辦法去選，但是有機會真的很想學學更多的演算法。

而Tag與Reader的角度差異，在本篇中做了詳細的測試紀錄，不過對於裡面的羅馬數字應該是測試次數吧！因為沒有標記出來，一開使我還以為是不同規格的Tag，若可以在表格左上方加入斜線並填上註解會更好。我也建議可以測試不同材質的障礙物下是否可以使用，如紙張、金屬、玻璃之類的，因為在真正的工作環境下，可能會遇到不同的障礙狀態，所以多這一部份資料相信會幫助你們在規劃實驗時，需要避免的狀況。

報告中所提及的實驗運作方式，我覺得還有很大的改善空間，我稍微仔細看過實驗架構，PDA與RFID Reader純粹是作為偵測使用，所以在PDA上並沒有回饋機制，感覺就像是一個超大型的偵測設備綁在使用者身上，感覺有點大材小用。如果只是為了偵測，曾有看過具備無線藍牙功能的RFID讀取晶片，這樣在使用者身上就不必有更多的負擔，可以查查相關的資料。

對於類似的方法，是有看過有人是將偵測器放在物品端，藉由有動過物品來做偵測，當然這樣的方式跟RFID的相關性就小了一些，但是也是達到相當的成效，所以可以再思考看看，以目前現有的設備能夠做到那些較符合一般人所能接受的使用方式。

閱讀「以ZigBee實現發展遲緩兒童如廁訓練應用」報告心得 by 小志

　

當ZigBee剛進實驗室時，我就想到了曾在醫工系看過用來做與定位相關性的實驗，不過現在所訂定的題目也讓我覺得蠻特別的。

ZigBee算是很多人不熟悉的通訊協定，所以本篇報告對於不同的架設狀況做測試，這樣給閱讀者能夠清楚了解不同環境下所使用的狀況，很快的讓人了解ZigBee的功能與實際效能狀況。

藉由播放音樂的方式讓使用者能夠找到如廁的樂趣，進而培養如廁的習慣感覺很不錯，我想小朋友們會比較喜歡這樣的方式。不過會不會造成說小朋友之間，如果說聽到誰去廁所如廁聽到音樂而造成嬉鬧嘲笑的部份，這個可能要請教一下專業人員。

如果將溼度感測器裝置在小朋友身上，這樣會不會造成小朋友的不便？因為除了安裝感測端外，還有資料發送端與供電電池，這樣對小朋友是否合適可能要再考慮。

感覺RFID的設置有點多餘，用途是記錄小朋友如廁的次數或規律，這部份ZigBee就可以完成吧！因為本身ZigBee就是像是網路節點，跟藍牙的設計有點類似，所以在小朋友上只需要配戴感應器就好了。印象中感應器沒有很大，小朋友的狀態就由伺服器端來做處理就好，或許這部份可以向醫工系請益。

2009/06/03 Meeting紀錄

　
時間：2009.06.03(三)　16:00~17:00
地點：電學Lab517
參與人員：馬瑱賢學長、小志

今天還是請學長親自教學，受益良多，不過先提上次的經過吧！（上次沒有寫紀錄......）

在上次的meeting當中，學長將我在使用Google Maps API編寫上遇到的困難，一起做研討並分析解決，學長會先了解我語法的架構後，提點我有哪些可以做修正、哪些地方在未來使用後會遇到哪些問題等，這樣引導的方式讓我對程式上得學習幫助很多。

這次的meeting，我把上週發現Google推出Maps API V3的實驗版本做測試，分享給學長，這次的改版〝改很大〞，最重要的就是去掉取key的限制，可以直接做取用，而程式碼的架構也改變了，因此未來若是現階段的程式要轉移時，需要大改很多，不過目前由於是實驗版本，因此很多的功能尚未開放改寫，所以目前專題的計畫還是以Maps API V2為主要編寫的語法。

而學長這次將Web Service的部份做詳細解說，從最基礎的網頁架構開始解說，然後進一步做簡單的叫用測試，然後到資料庫的取用、遠端呼叫等，雖然學長講得很明白，步驟看起來不難，但是對於程式碼的編寫方式還需要進一步認識才會。這些細節待我幾天後自己實際測試，再做細部介紹。