最近為了 IROS 的 paper 和碩士論文題目，每天都在想軟體怎麼設計，
還有怎麼配合各項計畫時間排進度。
軟體設計方面，主要是希望可以多用一些 design patter 提高程式的
可讀性，最有機會用到的有 Command 、 Mediator 、 State 這幾個
pattern 。
Command 可以把指令封裝起來，讓機器人各元件間的相依性降低；
Mediator 也可以降低元件的相依性，不過作法差滿多的，
State 則是可以讓機器人在不同的狀態下對同一事件產生不同處理方式
（雖然很 make sense ，不過我目前還沒想到是不是需要這麼複雜…）
另外機器人經常有一些超龐大複雜的 function ，像我如果要把 Tracking
包裝成一個 function ，可能會用到一堆物件和 data ，像是 URG 、 Motor
還有 Camera 、 超音波等等，還需要考慮避障，因此我覺得把複雜的工作
包裝成 class 似乎是個不錯的處理方式，有一堆 sub-function ，
一堆 function 需要的參數也可以直接用 member data 取代。
簡言之，完成一個任務需要很多物件和 sub-function ，剛好 class 裡面
就分成 member data 和 member function ，很適合拿來包裝一個任務。
但我自己還是很難接受「任務物件」這樣的概念就是了。
另外還發現一個問題，就是解決問題的 solution 究竟應該和這個問題
有多高的相依性？相依性高，程式好寫，但是留下來的 code 很難修改
成另一個程式也可以用，相依性低則反之。這也是很難拿捏的問題。
接下來是時間安排的問題。假設實驗只能做到五月底
（留一個月緩衝加寫論文）
該完成的事很多，想完成的事更多，中間可能突然冒出來的事…應該也不少
簡單表列一下
Need to do：
1. IROS 實驗：聽聲辨位、避障、圖像追蹤
2. MFI 實驗：語音人機介面、避障、人追蹤
3. Thesis 實驗：聽聲辨位、語音人機介面、避障、圖像追蹤、人追蹤、
SLAM、圖形人機介面
Want to do：
1. 聽聲辨位效果提昇
2. 仿立體視覺
3. Grid Map 建立程式
4. 紅外線 Docking 機制
本來也想玩玩機械手臂的，看來還是別去想比較好。
我也開始體會為什麼有人會想要繼續唸下去，因為兩年就畢業離開，很難
沒有遺憾。（不過對我來說，在這裡念博班可能會造成一輩子的遺憾…）
