2009年6月14日 星期日

期中報告回饋

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

【阿達】閱讀『用於輔助認知障礙者就業之行動定位社會網路』心得
【駿】"用於輔助認知障礙者就業之行動定位社會網路" 閱讀心得
【秉霖】閱讀『用於輔助認知障礙者就業之行動定位社會網路』心得感想
【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這兩部份。

2009年6月8日 星期一

閱讀「認知障礙者自動尋徑室內導航系統」報告心得 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年6月4日 星期四

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