剛剛用 Win32 API 和 C++ 寫了一個 class
之後的程式碼只要繼承這個 class 互相之間就會很容易溝通
剛剛突發奇想 用自己的名字（還是千嫂的也可以）來幫這個 class 命名
這樣以後學弟要是需要繼續用我的 code 就永遠擺脫不了我的陰影
哇哈哈
這樣不失為一種流芳百世（遺臭萬年）的方法…
（這好像某人一定要用自己的名字為機器人命名一樣……真糟糕）
該取什麼好呢…
1. QianSRUT
2. ChienSRUT
3. ChienHaoSRUT
4. old000SRUT
5. YunSRUT
6. QianYunSRUT
7. ChienYunSRUT
苦中作樂啊……
2010年5月2日 星期日
2010年1月26日 星期二
20101025 工作日誌
最近為了 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 機制
本來也想玩玩機械手臂的，看來還是別去想比較好。
我也開始體會為什麼有人會想要繼續唸下去，因為兩年就畢業離開，很難
沒有遺憾。（不過對我來說，在這裡念博班可能會造成一輩子的遺憾…）
還有怎麼配合各項計畫時間排進度。
軟體設計方面，主要是希望可以多用一些 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 機制
本來也想玩玩機械手臂的，看來還是別去想比較好。
我也開始體會為什麼有人會想要繼續唸下去，因為兩年就畢業離開，很難
沒有遺憾。（不過對我來說，在這裡念博班可能會造成一輩子的遺憾…）
2009年11月21日 星期六
[轉錄] 《Top 10 Traits of a Rockstar Software Engineer》：明星程式設計師必備的十項特質
本文轉錄自「猴子靈藥」
##CONTINUE##
1. 真心喜愛程式 (Loves to Code)
2. 把事情完成 (Gets Things Done)
3. 持續地重構程式 (Continuously Refactors Code)
4. 使用設計模式 (Uses Design Patterns)
5. 撰寫測試 (Writes Tests)
6. 善用既存程式碼 (Leverages Existing Code)
7. 專注於可用性 (Focuses on Usability)
8. 撰寫可維護的程式碼 (Writes Maintainable Code)
9. 能夠以任何程式語言撰寫程式 (Can Code in Any Language)
10. 瞭解基礎的電腦科學 (Knows Basic Computer Science)
原文出處：Top 10 Traits of a Rockstar Software Engineer
這是一篇很有意思的短文。文中條列出不多不少、總共十項優秀軟體工程師所應具備的特質，並且很微妙地將軟體工程師比喻成搖滾明星。你是公司的主管嗎？按照這些特質尋找人才就對了！你是在學的學生嗎？按照這十項特質的方向努力學習就沒錯了！
在這十個特質中，我認為最關鍵、同時也是寫得最為貼切的莫過於第一點：Loves to Code。
##CONTINUE##
1. 真心喜愛程式 (Loves to Code)
程式設計，是一種發自於內心、不求回報的付出 (Labor of Love)。如同任何的職業一樣，唯有具備滿滿的熱情，才能完成真正偉大的事情。一般人的誤解，常認為撰寫程式是一種機械化，或者純然科學化的行為。事實上，最棒的軟體工程師是工匠 (Craftman)，能夠將能量、巧思以及創造力注入每一行的程式碼當中。優秀的工程師，知道程式碼區塊何時被琢磨至完美的程度，也知道在大型的系統中，這些區塊何時會如同謎題般巧妙地拼湊組合起來。熱愛撰寫程式的工程師所獲得的喜悅感，就像是作曲家完成一首交響樂所感受到的狂喜；而也正是這種興奮感以及成就感，使優秀的程式設計者們真心熱愛程式設計。
我個人非常、非常地喜歡以上整段的敘述。Labor of Love 是一個非常棒的形容詞，幾乎將我內心最深層的感動，完整無缺地表達了出來。是否有時會覺得累、覺得倦，或是覺得不知所做為何？不妨回頭找找自己最初的本心吧。
2. 把事情完成 (Gets Things Done)
有些技術人喜歡只說不做，而優秀的工程師是會真正去做事的人。有些人為了找出最佳的方法解決問題，會花費數週的時間設計出複雜且多餘的系統架構與函式庫；真正優秀的程式設計者應該問自己：什麼才是解決問題最容易的途徑？
請記得我們身處現實世界中，而非傳說中的理想境界，沒有所謂的完美解決方案存在。做為程式設計者，我們所應當盡力去做的事情，就是利用手邊既有的各種資源，以最有效率的方式完成交派的任務。如果不能夠把事情完成，再神妙的構思與設計都只能活在白日夢，以及那些不著邊際的大話裡。
3. 持續地重構程式 (Continuously Refactors Code)
撰寫程式，與雕刻非常相像。就像藝術家會不斷地改善自己的創作作品，程式設計者也會持續性地改造自己的程式碼，只為了以最好的方法達到需求的目標。
不要變成老舊程式碼的奴隸。當這些程式碼是由其他人撰寫的時候，你或許可以輕易地推卸責任或者怪罪於別人；但是在多數的情況下，當這些可惡的程式碼，是由你自己所撰寫的時候，才是最令自己捶胸頓足、欲哭無淚的時候。請拿出細心、耐心與愛心，勇敢地挑戰那些殘破不堪的老舊程式碼吧。
4. 使用設計模式 (Uses Design Patterns)
所謂的模式 (Pattern)，是不斷重現在自然界與人類行為中的各種情境以及機制；而軟體工程也不例外。優秀的工程師能夠辨認出系統中所使用的設計模式，並且善加利用各種設計模式，同時也不受制於它們。
設計模式是前人智慧的結晶，幫助我們解決重複出現的類似設計難題，同時也成為程式設計者之間的溝通橋樑；但請記得，它們絕對不是程式設計中的萬靈藥：不要為了使用設計模式而使用設計模式；設計模式並不能使原來就很差勁的程式碼變得比較高明。
5. 撰寫測試 (Writes Tests)
有經驗的程式設計師，總是能夠瞭解撰寫測試程式碼的價值所在。測試的存在，能夠證明撰寫完成的系統運作無誤，並且確保過去曾經發生過的臭蟲問題不會再次重現。
為了進行測試而撰寫多餘的、與功能無關的程式碼？專案的進度怎麼辦？還有許多功能項目需要完成？所有的理由都是忽略撰寫測試程式碼的好理由。直到被臭蟲痛咬一口之前都是。花費心力在關鍵的程式碼區塊中撰寫測試，將能夠為你節省下難以計數的除錯時間；但很遺憾地，就我所知，目前台灣的業界並沒有撰寫測試程式碼的風氣，仍然亟待改進。
6. 善用既存程式碼 (Leverages Existing Code)
重新發明輪子一直都是軟體產業中的大問題。優秀的工程師會專注於三種不可或缺的復用 (Reuse) 層面：第一，使用同儕已經撰寫好並且經過測試的系統架構；第二，善用第三方團體所提供的函式庫；最後，則是利用某些網路服務所提供的便利功能。正確地善用既存的程式碼，才能使程式設計者專注於真正重要的任務上，也就是應用程式本身。
不要再寫第一千零一個 Linked List 類別了！不使用其他人撰寫的元件，堅持所有的功能都要由自己親手完成，究竟是自大、自爽、自衛還是自慰？請搞清楚自己的目的、專案的目標，以及核心關鍵的任務。
7. 專注於可用性 (Focuses on Usability)
好程式設計師專注於使用者。無論使用者是事業體或者個人，無論程式設計者為消費性軟體公司或者投資銀行工作，專注的焦點同樣在於可用性。優秀的程式設計者會非常努力地工作，只為了使系統更加簡單並且更為容易使用。他們無時無刻都會想到使用者，不會撰寫出錯綜複雜只有怪咖能夠理解的系統。
這是一項經常被忽略的重要特質。有時候，程式設計者寫得太開心太入迷，往往會忘了撰寫出來的程式，是需要交給其他使用者使用的東西。對於程式設計者來說，使用者的角色其實存在於許多不同的面向中，包括專案中的主程式、企畫設計者，以及遊戲成品的玩家，都是開發過程中需要「常在我心」的使用者。
8. 撰寫可維護的程式碼 (Writes Maintainable Code)
工程師界的小秘密：撰寫好程式碼或者壞程式碼，所花費的時間一樣多！紀律良好的工程師，會從第一行程式碼就開始思考維護性以及程式碼未來的演化。絕對沒有任何理由寫出醜惡的程式碼、橫跨數個頁面的函式，或者帶有稀奇古怪名稱的變數。每一字、每一句、每一行的程式碼，都應該恰如其份地展示出它們原先擁有的意涵。
不要總是認為以後、未來或者某一天，一定會有機會回頭改寫那些從前寫不好的程式碼，因而和自己做出妥協，寫出只是暫時堪用的程式碼。事實上，不遵守紀律的程式撰寫方式，不僅難以節省開發的時程，更無法順利推動專案的進度。重構的觀念與程序並不是偷懶的藉口，也不能拯救一個病入膏肓的系統架構。維持良好的寫作風格、命名規則以及嚴謹的設計架構，都是非常重要的基本守則。
9. 能夠以任何程式語言撰寫程式 (Can Code in Any Language)
優秀的程式設計師或許會有個人喜愛的程式語言，但從不固執迷信於其中。在很多的情境中，程式語言的重要性往往不如那些伴隨程式語言而來的函式庫。優秀的程式設計者能夠體認這項事實，並且願意去學習新的程式語言、新的函式庫以及新的方法以建造出更好的程式系統。
對於知識，要求知若渴；對於自己，要能虛懷若谷。保持開放的心態，對新鮮的事物保持孩子般的好奇心；而不是像個「大人」般被冷漠的態度與嘲諷的言語佔據內心，困守在象牙塔中而不自知。電腦科學與軟體程式設計領域的進展飛快無比，不止要從書本中獲取知識，更要儘可能地從網路、研討會，甚至身邊的同儕，學到那些經過真實歷練的經驗與智慧。
10. 瞭解基礎的電腦科學 (Knows Basic Computer Science)
優秀的工程師需要紮實的基礎。也許你沒有資訊科系的學位，但你不能不認識其中的基礎知識：資料結構與演算法。明星級的程式設計師不但需要瞭解，更要能夠內化這些基本知識，因為擁有這些知識基礎，將能夠幫助我們在軟體系統中做出正確的設計決定。
在 90% 的狀況中，我們不會需要使用複雜可怕的資料結構或令人畏懼的演算法，但是請至少先瞭解其中最基本首要的部分。什麼時候該用 vector？什麼時候可以用 list？如果使用 deque 的話有什麼差別？應該優先考慮執行效能，或者優先考慮記憶體空間，甚至是未來擴充的彈性？不同的資料結構與演算法之間，有沒有不同的取捨？招式是死的，用的人是活的，能夠順應局勢見招拆招，才是好本事！
以上，就是為了成為超級星光大道的 Super Star Programmer 所需具備的十項基本特質。看完上述十點特質之後，是不是覺得好像還少了點什麼？是不是有某個很重要的特質沒有被列入其中？還有什麼樣的態度、能力或特徵，是你認為做為一位優秀的程式設計者所不可或缺的呢？歡迎提出來討論喔～ ^_^
2009年9月27日 星期日
[流水] 20090926 程式宅的內心世界
最近在研究 Win32 API
有鑑於 Windows 系統的強大以及網路上資源豐富
儘管在 programming 的時候可以感覺到這家公司的蠻橫
但是在開發應用程式的時候，衡量優劣之下，還是選 M$ 最好
##CONTINUE##
Win32 應用程式的開發有一個固定的模式需要遵守
1. 先建立視窗（不管你需不需要）
2. 設定訊息處理函式
3. 用視窗接收訊息
也許看到規範就想違背是我個人的劣根性
這樣我自己在寫一些模組化的程式，可重用性就會高很多
不需要依賴視窗，也可以少很多負擔
做了許多功課以後，宣告放棄
因為在 M$ 的設定下，Console 的視窗並沒有辦法接受訊息
所以如果想要利用 Win32 的 event-driven 和 message queue 的功能
一定要另外生一個視窗來做這件事
今天看到的 code 內容
可以不用 Win32 內定的程式進入點 WinMain ，而用一般的 int main
然後另外開視窗來處理訊息
我自己則是希望可以把視窗、訊息處理函式用一個 class 包起來
以後我就還是可以用熟悉的空專案寫程式，又可以用 Win32 的訊息功能
不過至少回國之前我要忍住，不能開始動手寫
2009年2月18日 星期三
國外機器人軟體平台發展介紹
（本文轉錄自機器人世界情報網）
我們是可以預見不遠的未來，機器人會和電腦一樣充滿你我的身旁，這似乎是必然發生的願景。不過，雖然硬體有現成的產品與技術，開發者們卻仍舊苦於機電整合所需花費的功夫，機器人通常由視覺、移動、控制、傳輸、供電等多種不同的模組所組成，光是這些模組間的IO點、訊號表等的整合就是一大工程，而在從事部分模組替換時，更需要一而再再而三地重覆整合動作。
就連軟體方面，由於沒有使用共通的底層平台，不管機器人是在什麼OS上開發，換一組人來修改，幾乎都要重頭到尾完整研究過程式，才能清楚的瞭解整個架構。因此，不同機器人應用軟體開發的經驗也難以順利交流。即使我寫好了某個應用功能（例如導航），拿到別台機器人上之後，由於架構不同，可能整個程式架構都要完全重寫，這些都是不必要花費的精力。
所以對機器人軟體開發人員來說，最重要的就是能夠有一個共通的軟體平台架構，讓所有的開發都能夠依循一定的規定或手法，只要有過一次的開發經驗，看到其他使用同樣架構的機器人，我們也能夠快速的瞭解要去哪邊找或是放入對應的程式碼，在最短的時間、最小的力氣下完成開發與修改。這就像是使用VC 6的程式設計師看的懂彼此的Windows程式，使用BCB、.Net、CVI的也看得懂彼此的程式。
很幸運的，目前世界上已經有多個組織在進行此類共通軟體平台的研發，除了早年就已經開始的各項計畫，2006年中，世界最大的軟體公司Microsoft發表了Robotics Studio 1.0版；而在2007年初，世界最有名的清潔機器人製造公司iRobot也發表了Create系列產品。這些指標性公司的加入在在顯示了他們對機器人共通軟體平台的重視。雖然所謂『共通的』標準依舊很多，但至少使用者可以依據你的硬體設備限制，或是拿手的開發環境來選擇最適合的軟體平台來使用。
一般來說，如果是學術或研究單位所開發出來的軟體平台，通常會使用Open Source的方式，免費提供使用者使用；若是公司行號所發表的，則收費方式不一定。依照這些平台的特性，可以將其分為兩大類：Platform與Middleware。
##CONTINUE##
（一）Platform
Platform指的通常在開發的初期就已經預設要用在某一台特定的機器人或是裝置（Device）上，且對於要如何新增其Device Driver有明確的定義。也比較強調機器人本身的行為特性，如特定的避障、導航、空間定位等功能。
Platform給人的感覺會比較像是一個機器人的SDK（Software Development Toolkit），包含有各種預先設立好的功能可以使用，且彈性可能較低，即有一個完整的規範，使用者不管要新增或是修改任何功能都必須要緊緊綁在既有的架構下去做，未來改變與擴充的彈性較差。
（二）Middleware
Middle的走向通常較為開放，願景中會希望最後的成品不用受到作業系統或是語言的影響，可以完全依照使用者的喜好來開發，同時又能夠達到共通軟體平台『將軟體元件模組化』的需求。
Middleware不會特別指定要在哪一台機器人上使用、或是要具備什麼硬體，其所講求的是泛用性，最好能夠適用在各種類型的機器人上。所以Middleware通常看起來會比較像是一個架構與概念，配合最基本的程式核心，其餘周邊與硬體可以一切交由使用者們去開發與交流；當然，一切都要合乎此Middleware最初設計的SOP Rule，所以整體的彈性也較大，事實上也有些Middleware是由其他Middleware修改後所衍生出來的。
（三）Platform v.s. Middleware
使用Platform就像是我們在一棟建築物中蓋隔間或是裝潢，而使用Middleware則如同在地基上依照施工規範向上蓋，當然有時候也會向旁邊蓋或是跑去裝潢。前者雖然使用者也可以修改，但是要對照現有的水電路圖說，不過不管怎麼施工，對整體結構不會有太大影像；後者則有很高的自由度，但相對的如果使用者水準不一，則有機會蓋出奇形怪狀的房子，但卻可能更符合業主的期望。
就此來看，在這機器人萌芽的階段，尚無法定論孰優孰劣，不過兩者最終的目的相同，使用者應看情況挑選適合的解決方案才是上上之策。下表一為Platform與Middleware之特性比較。
代表性的共通平台軟體介紹：
Platform
（一）Player Project
Player是Brian Gerkey、Richard Vaughan、Kasper Stoy、Andrew Howard在南加大（USC）就讀時，為了實驗室的Pioneer機器人所開發出的 interface/driver abstraction framework。主要透過Linux作業系統開發，適合的開發語言為C、C 跟Python，屬於Open Source的Freeware；採用Client/Server的架構建立，中間則以TCP連線來傳遞Actuator命令及回傳Sensor狀態，並以Configuration File的形式來選定要使用的Device；提供2D Robot模擬環境「Stage」。綜合以上各特色，Player Project只是提供一個硬體抽象層（Hardware Abstraction Layer），而不限定使用者該如何開發自己的應用程式。
（二）ARIA
ARIA是MobileRobots公司（Pioneer機器人的出品公司）為該公司機器人所提供的Object Oriented （OO） Interface。開發環境為Linux或Windows作業系統，適合的開發語言為C ，所以MS Visual C .NET （7.1）或g 3.x是支援的；此軟體平台還提供Robot模擬環境「MOBILESIM」並採用Client/Server的架構。
（三）ERSP
ERSP是Evolution Robotics 公司所發展的一套機器人控制軟體發展工具。所支援的Robot除了該公司的ER1及Scorpion機器人外，也支援MobileRobot的Pioneer機器人。ERSP不同於Player Project和ARIA只提供使用者HAL（Hardware Abstraction Layer）的功能；ERSP提供使用者一個三層架構分別為硬體抽象層HAL（Hardware Abstraction Layer）、行為執行層BEL（Behavior Execution Layer）、以及任務實行層TEL（Task Execution Layer）。
ERSP也有視覺化的編輯程式Behavior Composer，可以將一些建立好的Behavior透過拖曳（Drag and Drop）的方式及屬性頁（Property Panel）的參數編輯方式，連結自己的Behavior Network。Behavior Network簡單的來說就是Task的基礎原型（Primitives）。TEL是以事件驅動（Event driven）的高階控制工作。Tasks可以觸發新的事件（events），並可以平行進行多個Task及設定離開條件（exit conditions）。使用者也可以呼叫Task類別（Class）的API（Application Program Interface）組合成適用的應用程式。ERSP對於新增Resource Driver、Behavior、Task都有相關的範例程式，適用的作業系統有Linux及Windows，適合的開發環境為.NET 2003及g 。
Middleware
（一）MSRS
MSRS是微軟公司跨足機器人領域的產品，於2006/12/16釋出正式版（1.0），並於2007/04/04釋出MSRS 1.5（CTP April 2007），供非商業用途免費使用。如果是商業用途則論套計價，一套約美金400元。此外，微軟公司更在2007/07/12推出了升級版的Robotics Studio平台，新增了對Windows Embedded CE 6.0和Windows Mobile的支援。MSRS 並沒有去定義或安排硬體抽象層（HAL）的設計，以Service為導向來思考並設計這個共用平台，並使用DSSP與CCR的概念。MSRS整合了AGEIA公司的物理計算引擎（PhysX）及繪製方面的DirectX Runtime，提供3D的機器人模擬環境，以及視覺化的Robot程式編輯軟體VPL（Visual Programming Language）。
DSSP（Decentralized Software Services Protocol），是一種簡化的 SOAP-based應用協定，DSSP用來解決Robot分散式應用的問題。另一方面，CCR（Concurrency and Coordination Runtime）為C#2.0所開發的Port-Based concurrency函式庫，用來解決以往的多工問題。使用者不須去撰寫多執行緒（Multi Thread）的程式。
（二）OpenRTM-AIST
OpenRTM-AIST之開發是基於為了構築因應廣泛需要之機器人系統，而推進基盤技術RT Middleware的開發。對於這些模組化的元件稱之為RTComponent，由三個部分構成RTComponent Object、Inport Object、Outport Object。RTComponent以CORBA建構，目前OpenRTM可運行的作業系統為Linux，未來有朝符合Windows作業系統及.NET C 和JAVA的方向進行中。
（三）OROCOS（Open RObot COntrol Software）
主要由the Flanders Mechatronics Technology Center所開發。OROCOS計畫建立一套泛用型的Freeware 可以有模組化的framework能運用於機台或工業機器人的即時（real-time）控制。OROCOS主要有四個C 的函式庫（Library）分別如下：
－Real-Time Toolkit（RTT）
－Orocos Component Library（OCL）
－Kinematics and Dynamics Library（KDL）
－Bayesian Filtering Library（BFL）
（四）ORCA
ORCA等於是OROCOS的相關計畫，因為OROCOS的控制軟體設計強調real time，對於已經開發完成但無關real time 的Component則歸ORCA計畫。ORCA又分為ORCA-1及ORCA-2，差別在於ORCA-1並未設定Component的建構方式，ORCA-2則採用Ice（Internet Communication Engine）。
（五）RSCA（Robotic Software Communications Architecture）
URC（Ubiquitous Robotic Companion）是目前韓國正在進行的機器人發展計畫，參與的團隊為韓國的ETRI、Samsung、KIST and MIC，目的在於將原先的聯網服務（networked service）機器人能整合起來克服目前家用服務機器人所碰到的技術難題。作法是採用SDR（Software Defined Radio）領域中的一個現有中介層軟體架構SCA（Software Communications Architecture），將之衍生運用到URC計畫中，稱之為RSCA。
結論
就如同國與國間要交流，語言和觀念必須能夠互通，未來機器人的開發上若要能夠交流其中的技術與資訊，發展共通的軟體平台是勢在必行。現在已經有多種軟體平台發展出來，這些開路先鋒雖然各有其優劣之處，但是仍舊提供廣大的使用者不同的選擇，使用者應該依照本身環境與能力的需求來選擇適合的軟體平台。
有鑑於國外各機關組織已然發展出多種不同共通平台軟體，在吸收其優劣之處與使用經驗後，目前國內工研院的科專計畫正在發展一套機器人軟體平台，預計在2008年初將會釋出提供合作單位使用，相信屆時必能成為國內機器人的發展的推手之一。
誌謝
本文研究成果主要來自經濟部技術處「智慧機器人技術研究發展」科技專案計畫。
我們是可以預見不遠的未來，機器人會和電腦一樣充滿你我的身旁，這似乎是必然發生的願景。不過，雖然硬體有現成的產品與技術，開發者們卻仍舊苦於機電整合所需花費的功夫，機器人通常由視覺、移動、控制、傳輸、供電等多種不同的模組所組成，光是這些模組間的IO點、訊號表等的整合就是一大工程，而在從事部分模組替換時，更需要一而再再而三地重覆整合動作。
就連軟體方面，由於沒有使用共通的底層平台，不管機器人是在什麼OS上開發，換一組人來修改，幾乎都要重頭到尾完整研究過程式，才能清楚的瞭解整個架構。因此，不同機器人應用軟體開發的經驗也難以順利交流。即使我寫好了某個應用功能（例如導航），拿到別台機器人上之後，由於架構不同，可能整個程式架構都要完全重寫，這些都是不必要花費的精力。
所以對機器人軟體開發人員來說，最重要的就是能夠有一個共通的軟體平台架構，讓所有的開發都能夠依循一定的規定或手法，只要有過一次的開發經驗，看到其他使用同樣架構的機器人，我們也能夠快速的瞭解要去哪邊找或是放入對應的程式碼，在最短的時間、最小的力氣下完成開發與修改。這就像是使用VC 6的程式設計師看的懂彼此的Windows程式，使用BCB、.Net、CVI的也看得懂彼此的程式。
很幸運的，目前世界上已經有多個組織在進行此類共通軟體平台的研發，除了早年就已經開始的各項計畫，2006年中，世界最大的軟體公司Microsoft發表了Robotics Studio 1.0版；而在2007年初，世界最有名的清潔機器人製造公司iRobot也發表了Create系列產品。這些指標性公司的加入在在顯示了他們對機器人共通軟體平台的重視。雖然所謂『共通的』標準依舊很多，但至少使用者可以依據你的硬體設備限制，或是拿手的開發環境來選擇最適合的軟體平台來使用。
一般來說，如果是學術或研究單位所開發出來的軟體平台，通常會使用Open Source的方式，免費提供使用者使用；若是公司行號所發表的，則收費方式不一定。依照這些平台的特性，可以將其分為兩大類：Platform與Middleware。
##CONTINUE##
（一）Platform
Platform指的通常在開發的初期就已經預設要用在某一台特定的機器人或是裝置（Device）上，且對於要如何新增其Device Driver有明確的定義。也比較強調機器人本身的行為特性，如特定的避障、導航、空間定位等功能。
Platform給人的感覺會比較像是一個機器人的SDK（Software Development Toolkit），包含有各種預先設立好的功能可以使用，且彈性可能較低，即有一個完整的規範，使用者不管要新增或是修改任何功能都必須要緊緊綁在既有的架構下去做，未來改變與擴充的彈性較差。
（二）Middleware
Middle的走向通常較為開放，願景中會希望最後的成品不用受到作業系統或是語言的影響，可以完全依照使用者的喜好來開發，同時又能夠達到共通軟體平台『將軟體元件模組化』的需求。
Middleware不會特別指定要在哪一台機器人上使用、或是要具備什麼硬體，其所講求的是泛用性，最好能夠適用在各種類型的機器人上。所以Middleware通常看起來會比較像是一個架構與概念，配合最基本的程式核心，其餘周邊與硬體可以一切交由使用者們去開發與交流；當然，一切都要合乎此Middleware最初設計的SOP Rule，所以整體的彈性也較大，事實上也有些Middleware是由其他Middleware修改後所衍生出來的。
（三）Platform v.s. Middleware
使用Platform就像是我們在一棟建築物中蓋隔間或是裝潢，而使用Middleware則如同在地基上依照施工規範向上蓋，當然有時候也會向旁邊蓋或是跑去裝潢。前者雖然使用者也可以修改，但是要對照現有的水電路圖說，不過不管怎麼施工，對整體結構不會有太大影像；後者則有很高的自由度，但相對的如果使用者水準不一，則有機會蓋出奇形怪狀的房子，但卻可能更符合業主的期望。
就此來看，在這機器人萌芽的階段，尚無法定論孰優孰劣，不過兩者最終的目的相同，使用者應看情況挑選適合的解決方案才是上上之策。下表一為Platform與Middleware之特性比較。
代表性的共通平台軟體介紹：
Platform
（一）Player Project
Player是Brian Gerkey、Richard Vaughan、Kasper Stoy、Andrew Howard在南加大（USC）就讀時，為了實驗室的Pioneer機器人所開發出的 interface/driver abstraction framework。主要透過Linux作業系統開發，適合的開發語言為C、C 跟Python，屬於Open Source的Freeware；採用Client/Server的架構建立，中間則以TCP連線來傳遞Actuator命令及回傳Sensor狀態，並以Configuration File的形式來選定要使用的Device；提供2D Robot模擬環境「Stage」。綜合以上各特色，Player Project只是提供一個硬體抽象層（Hardware Abstraction Layer），而不限定使用者該如何開發自己的應用程式。
（二）ARIA
ARIA是MobileRobots公司（Pioneer機器人的出品公司）為該公司機器人所提供的Object Oriented （OO） Interface。開發環境為Linux或Windows作業系統，適合的開發語言為C ，所以MS Visual C .NET （7.1）或g 3.x是支援的；此軟體平台還提供Robot模擬環境「MOBILESIM」並採用Client/Server的架構。
（三）ERSP
ERSP是Evolution Robotics 公司所發展的一套機器人控制軟體發展工具。所支援的Robot除了該公司的ER1及Scorpion機器人外，也支援MobileRobot的Pioneer機器人。ERSP不同於Player Project和ARIA只提供使用者HAL（Hardware Abstraction Layer）的功能；ERSP提供使用者一個三層架構分別為硬體抽象層HAL（Hardware Abstraction Layer）、行為執行層BEL（Behavior Execution Layer）、以及任務實行層TEL（Task Execution Layer）。
ERSP也有視覺化的編輯程式Behavior Composer，可以將一些建立好的Behavior透過拖曳（Drag and Drop）的方式及屬性頁（Property Panel）的參數編輯方式，連結自己的Behavior Network。Behavior Network簡單的來說就是Task的基礎原型（Primitives）。TEL是以事件驅動（Event driven）的高階控制工作。Tasks可以觸發新的事件（events），並可以平行進行多個Task及設定離開條件（exit conditions）。使用者也可以呼叫Task類別（Class）的API（Application Program Interface）組合成適用的應用程式。ERSP對於新增Resource Driver、Behavior、Task都有相關的範例程式，適用的作業系統有Linux及Windows，適合的開發環境為.NET 2003及g 。
Middleware
（一）MSRS
MSRS是微軟公司跨足機器人領域的產品，於2006/12/16釋出正式版（1.0），並於2007/04/04釋出MSRS 1.5（CTP April 2007），供非商業用途免費使用。如果是商業用途則論套計價，一套約美金400元。此外，微軟公司更在2007/07/12推出了升級版的Robotics Studio平台，新增了對Windows Embedded CE 6.0和Windows Mobile的支援。MSRS 並沒有去定義或安排硬體抽象層（HAL）的設計，以Service為導向來思考並設計這個共用平台，並使用DSSP與CCR的概念。MSRS整合了AGEIA公司的物理計算引擎（PhysX）及繪製方面的DirectX Runtime，提供3D的機器人模擬環境，以及視覺化的Robot程式編輯軟體VPL（Visual Programming Language）。
DSSP（Decentralized Software Services Protocol），是一種簡化的 SOAP-based應用協定，DSSP用來解決Robot分散式應用的問題。另一方面，CCR（Concurrency and Coordination Runtime）為C#2.0所開發的Port-Based concurrency函式庫，用來解決以往的多工問題。使用者不須去撰寫多執行緒（Multi Thread）的程式。
（二）OpenRTM-AIST
OpenRTM-AIST之開發是基於為了構築因應廣泛需要之機器人系統，而推進基盤技術RT Middleware的開發。對於這些模組化的元件稱之為RTComponent，由三個部分構成RTComponent Object、Inport Object、Outport Object。RTComponent以CORBA建構，目前OpenRTM可運行的作業系統為Linux，未來有朝符合Windows作業系統及.NET C 和JAVA的方向進行中。
（三）OROCOS（Open RObot COntrol Software）
主要由the Flanders Mechatronics Technology Center所開發。OROCOS計畫建立一套泛用型的Freeware 可以有模組化的framework能運用於機台或工業機器人的即時（real-time）控制。OROCOS主要有四個C 的函式庫（Library）分別如下：
－Real-Time Toolkit（RTT）
－Orocos Component Library（OCL）
－Kinematics and Dynamics Library（KDL）
－Bayesian Filtering Library（BFL）
（四）ORCA
ORCA等於是OROCOS的相關計畫，因為OROCOS的控制軟體設計強調real time，對於已經開發完成但無關real time 的Component則歸ORCA計畫。ORCA又分為ORCA-1及ORCA-2，差別在於ORCA-1並未設定Component的建構方式，ORCA-2則採用Ice（Internet Communication Engine）。
（五）RSCA（Robotic Software Communications Architecture）
URC（Ubiquitous Robotic Companion）是目前韓國正在進行的機器人發展計畫，參與的團隊為韓國的ETRI、Samsung、KIST and MIC，目的在於將原先的聯網服務（networked service）機器人能整合起來克服目前家用服務機器人所碰到的技術難題。作法是採用SDR（Software Defined Radio）領域中的一個現有中介層軟體架構SCA（Software Communications Architecture），將之衍生運用到URC計畫中，稱之為RSCA。
結論
就如同國與國間要交流，語言和觀念必須能夠互通，未來機器人的開發上若要能夠交流其中的技術與資訊，發展共通的軟體平台是勢在必行。現在已經有多種軟體平台發展出來，這些開路先鋒雖然各有其優劣之處，但是仍舊提供廣大的使用者不同的選擇，使用者應該依照本身環境與能力的需求來選擇適合的軟體平台。
有鑑於國外各機關組織已然發展出多種不同共通平台軟體，在吸收其優劣之處與使用經驗後，目前國內工研院的科專計畫正在發展一套機器人軟體平台，預計在2008年初將會釋出提供合作單位使用，相信屆時必能成為國內機器人的發展的推手之一。
誌謝
本文研究成果主要來自經濟部技術處「智慧機器人技術研究發展」科技專案計畫。
2009年2月15日 星期日
ARIA - 很棒的機器人程式API
今天在網路上找到的，真是有點相見恨晚。
ARIA - MobileRobots' Advanced Robot Interface for Applications
晚上Group Meeting結束後，下載來安裝。
本來只是想看看別人的機器人軟體架構（特別是公司企業級），結果讓我眼睛為之一亮。
不但是 Open Source (GNU License)
而且還有完整的 reference 和 example code。
coding style 也滿平易近人的，沒有用太深奧的語法。
不過畢竟是公司開發的，很多底層的東西似乎還是針對他們自己家的產品。
但就軟體架構而言，已經非常值得我們初窺門徑的研究生參考了。
網頁 http://robots.mobilerobots.com/wiki/ARIA
我另外把說明文件放到自己的空間
http://www2.ee.ntu.edu.tw/~r97921003/ariadoc/
ARIA - MobileRobots' Advanced Robot Interface for Applications
晚上Group Meeting結束後，下載來安裝。
本來只是想看看別人的機器人軟體架構（特別是公司企業級），結果讓我眼睛為之一亮。
不但是 Open Source (GNU License)
而且還有完整的 reference 和 example code。
coding style 也滿平易近人的，沒有用太深奧的語法。
不過畢竟是公司開發的，很多底層的東西似乎還是針對他們自己家的產品。
但就軟體架構而言，已經非常值得我們初窺門徑的研究生參考了。
網頁 http://robots.mobilerobots.com/wiki/ARIA
我另外把說明文件放到自己的空間
http://www2.ee.ntu.edu.tw/~r97921003/ariadoc/
2009年1月30日 星期五
重構─改善既有程式的設計
前陣子逛書局看到的，很心動，但我現在應該還沒那個能力看這本書吧！
之前做 project 就覺得自己針對問題設計軟體的能力還很弱，特別是把已經有輪廓的演算法變成程式碼，老是有一堆想法，卻寫不出一個漂亮的、經典的程式。
API會得不夠多、不會design pattern、code看得太少…
似乎每個缺陷都急迫又重要…
訂閱：
文章 (Atom)