ROS机器人操作系统中级教程 5
自定義消息
教程描述: 本教程將展示如何使用ROS消息描述語言來定義你自己的消息類型.
教程難度: 中級
下節預告: 在Pyhon中使用C++類
目錄
自定義消息
自定義一個消息類型很簡單，只要將.msg文件放到一個package的msg文件夾下即可。請參考初級教程中的創建.msg文件(不要忘記選擇相應的編譯構建系統)。
引用和輸出消息類型
消息類型都被歸屬到與功能包相對應的域名空間下，例如：
C++
std_msgs::String msg;Python
from std_msgs.msg import Stringmsg = String()依賴項
如果你要使用在其他功能包里定義的消息類型，不要忘記添加以下語句：
<build_depend>name_of_package_containing_custom_msg</build_depend> <run_depend>name_of_package_containing_custom_msg</run_depend> <build_depend>message_generation</build_depend> <run_depend>message_runtime</run_depend>到package.xml。同時需要修改CMakeList.txt：
find_package(message_generation) catkin_package(CATKIN_DEPENDS message_runtime) add_message_files(FILES your_msg_file.msg)教程ROSNodeTutorialC++和ROSNodeTutorialPython展示了使用自定義消息類型來創建talker和listener的C++和Python實現。
補充說明：
官網還有3個教程，分別如下：
在python中使用C++類
本教程闡述一種在python中使用C++類的方法。鏈接如下：中文 英文
將ROS項目進行打包
本教程介紹如何快速打包和部署ROS項目。鏈接如下：英文
如何編寫教程
本教程介紹在編輯ros.org維基時，可以用到的模板和宏定義，并附有示例以供參考。鏈接如下：中文 英文
以上內容可以查閱對應資料進行自主學習，至此關于ROS機器人操作系統的基礎概念部分（包括安裝、配置、初級和中級）就全部結束了。稍后課程將針對功能包、接口和庫的學習與使用進行介紹，以專題設計為主線展開。
ROS開發者說明
目錄
開發者說明
ROS是一個龐大的系統，許多人共同開發。為了進行合理地管理，我們已經寫好了開發指導說明。請按照下面的指導說明，合理布局你的代碼。
參考:
源代碼管理
支持使用Git、Mercurial、Subversion 和Bazaar進行代碼管理。由于ROS社區是分散的，歡迎你將代碼托管到任何公共訪問的地方(比如GitHub、 Bitbucket、Google Code). 主要的ROS基礎代碼會被發布到github.com的幾個組織單元several organization units下面。關于建議的倉庫使用說明參考RecommendedRepositoryUsage
- 只添加手動編寫的源代碼文件，以及必須的構建功能包的相關文件。不要添加機器自動生成的文件，比如目標文件(*.o)，庫文件(.a, .so, .dll), 或者自動配置腳本文件。
-
- svn add 將會遞歸到子目錄里添加所有文件. 在svn add之前先操作下 make clean。
-
- 不要添加大的二進制文件: 通過web服務器上傳，下載到本地的構建文件夾去。
- 盡早且經常性提交自己的代碼。不在源碼管理范圍內的任何文件都應該作為草稿（scratch）存儲。
- 盡量保持每次的提交集中到一處特殊的更改，而不是一次提交多方面的更改，這樣更容易回溯代碼。
- 每一次的提交都寫清更改說明。
- 不要打亂構建結構. 在check in之前確保你的代碼能夠順利編譯。
Bug追溯
針對每一個功能包，利用單獨的bug tracker，實現bug報告，增強請求，和任務分配。經常性的，在本站的頁面上，你會看的一些具體的bug tracker的相關鏈接。
對于代碼的托管GitHub作為一個倉庫的通用的bug tracker。
代碼維護者將會為每個報告的問題創建一個里程式標記(milestone)。當問題被定位時，可以給報告者一個合適的反饋。這些里程標記就是ROS正式版(比如 Groovy or Hydro) 或者細分版本(比如 Hydro beta 1). 更多的是，當問題沒被修復時，會賦以標記untargeted。這可能是由于開發者的時間緊迫或者可靠性的考慮。
為了讓用戶表達自己的想法，針對已發布的軟件版本，測試是否已經修復bug，維護者應該要么，在關閉問題報告的時候，發布一個嘗試版本，要么為每一個更細化的版本設置標記，在下個里程標記之前，標記問題報告。這樣一來，對用戶來說，讓所包含的問題本身來決定發布版的bug是否已經被修復。
當你發現一個bug時，開啟一個指派（ticket）。當你需要新功能的時候，打開一個指派。郵件或者發布到answers.ros.org或者郵件列表都有可能被遺忘。但是，指派的方式反而就不會那么容易忘記。
指派的時候盡量遵循這些原則.
盡量包含bug重現時，需要的指令。They should include instructions for reproducing the bug.
盡量描述問題出現時的，系統運行狀態。（用的什么系統版本，涉及的功能包有哪些。
不要畏懼指派。許多開發者都會指派給他們自己，比如利用Trac。
如果你不確定出現問題時涉及的的功能包或者問題確實是一個bug，請首先訪問answers.ros.org。
代碼布局
package功能包由代碼組織而成，而功能包組成一個單獨的倉庫responsitory。功能包是作為代碼構建的基本單位。
尤其注意！建議，在GitHub上，在倉庫的根目錄創建一個README.md，用來向用戶說明代碼倉庫的具體細節。建議，在ROS wiki頁面設置鏈接到指定的包含的軟件包。參照 this article 獲取更多的幫助.
功能包
ROS功能包和系統的構建依賴于manifest.xml。
每一個功能包都必須，在功能包所在的頂層目錄，存在一個manifest.xml文件.
最基本的，manifest必須包含下面的三部分：
- description
- author
- license
下面舉一個roscpp節點的一個模板例子：
<package><description brief="BRIEF DESCRIPTION">LONGER DESCRIPTION</description><author>You/you@willowgarage.com</author><license>BSD</license><url>http://www.ros.org/wiki/YOURPACKAGE</url><depend package="roscpp"/> </package>下面是rospy的一個例子:
<package><description brief="BRIEF DESCRIPTION">LONGER DESCRIPTION</description><author>You/you@willowgarage.com</author><license>BSD</license><url>http://www.ros.org/wiki/YOURPACKAGE</url><depend package="rospy"/> </package>GUI工具包
我們已經移植了所有最新的GUI到rqt，這些GUI都是QT基礎的GUI框架。在fuerte使用wxWidgets之前，因交叉編譯的兼容性太差，大部分已有的代碼被重建。 因此對于新的GUI設計，考慮使用rqt。開發說明從這里獲取(including license consideration when writing in python)。
代碼編譯
基本的代碼編譯工具是CMake(more)。
每一個創建的功能包的頂層目錄都必須存在CMakeLists.txt。
現在，每一個功能包都必須有一個Makefile, 短而精巧。那些沒有經過構建步驟的功能包不需要任何的構建文件。
證書
ROS是開源的，旨在讓來自五湖四海的不同的用戶和開發者們，從學生到企業家們，都可以得到幫助獲取支持。
- 我們傾向自由的開源證書，促進代碼的商業化。
- 傾向建議使用證書BSD 證書。盡可能，新的代碼都應該在BSD證書下發布。
- 所有的ROS代碼都是BSD證書下發布的選擇BSD的原因 其他任何的OSI促成的證書都是可接受的(fornon-core code)。
- 我們強烈建議使用非對稱版權的證書（比如BSD），來進行ROS .msg和.srv文件的發布，所以不妨礙那些自動產生的源代碼文件和數據結構。
- 工程中的所有文本狀態的證書都應該放到頂層的LICENSES文件目錄下。如果你天劍了一個并不包括在LICENSE目錄下的證書，添加下證書狀態即可。
- 每一個源代碼文件，都應該在頂層，包含一個證書的簡略版注釋。方便的，LICENSES目錄下也應該包含證書的簡略說明，并且需要不同的語言書寫。
-
- 對于我們發布的第三方的代碼，證書和版權會被予以保護。
- 我們將嚴格遵守第三方軟件，例如：
-
- 如果庫有證書GPL聲明 or LGPL 聲明，如果你修改了，則你必須發布修改后的代碼。理想情況下，你必須發送一個補丁給庫的維護者。保持如果修改后的代碼的公共訪問權限也是必要的。
-
- 如果你的功能包使用了GPL'd庫，然后你的功能包也必須進行GPL聲明。
-
- 如果你的功能包使用了GPL'd庫，那么你就不能使用與GPL不兼容的授權協議GPL-incompatible license。 例如，Creative Commons Attribution-Noncommercial-Share Alike 證書是與GPL不兼容的，因為他強加了一些GPL不能做的約束條件(換句話說，就是要求的屬性，禁止商業使用等).
- 盡可能的，每一個ROS功能包都以一種單一證書形式予以管理。
-
- 一般性的特殊案例：BSD證書代碼（比如 ROS core），在一個功能包，也會用到GPL證書聲明的代碼。為了配合GPL，BSD聲明的代碼，是在BSD和GPL多證書下聲明的，用戶可以選擇使用哪個證書協議。這當然也不是聲明大問題，因為GPL增加了一些BSD不要求的一些限制條件。
- ROS功能包和通信系統允許細致的證書協議。因為節點通過ROS消息進行通信，多節點通信的代碼不是連接到一起。因此，功能包提供了一種“證書壁壘（license boundary）”。
-
- 例外:當一個功能包是庫的形式，并且確實鏈接到其他的功能包。這種情況下，各個證書會被混合聲明在目標代碼里。
- 引用: Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers
版權
遵循Berne Convention版權，作為作者自動擁有版權，而不管有沒有一個正式的聲明。無論如何，顯式的版權聲明有助于長期性項目的管理。
- 每一個源文件都應該在文件頂層上，包含一個版權說明注釋，例如 Copyright 2008 Jim Bob。 這個就是一個證書的簡概說明。
- 如果只自己使用，版權屬于自己。
- 如果受雇于某些人，或者公司（比如Willow Garage），版權就屬于公司。
調試
ROS里的調試工具，包括但不限于：
- GDB
- Oprofile
- Valgrind
一般性建議:
- 如果一個程序，比如foo、crashes, 首先使用 GDB:可以通過添加一些必要的參數：
當程序崩潰crashes時，利用gdb的bt指令來進行追溯和探究。
- 對于一些棘手的bug，尤其涉及到內存崩潰的。試著實用工具valgrind:
Valgrind可以追蹤所有的內存訪問呢，一把可以找到問題的原因。同樣，可以發現你沒有發現的其他問題。注意的就是，Valgrind會拖慢你程序運行的節奏，看起運行緩慢。
- master和rospy的日志會默認創建到ROS_ROOT/log。但是，roscpp的客戶端節點日志默認不會創建。如果你正在以nasty模式調試時，你可以設置構建的第二個參數WRITE_LOG_FILE（伴隨其他的選項ANONYMOUS_NAME等）。其他選擇是，如果你不想重新編譯節點，你可以在命令行中添加log:=BLAHBLAH，BLAHBLAH可以是任何東西，也可以什么也不是。
測試
我們進行兩個級別的測試:
- 庫: 在庫的層面上，我們使用用標準的單元測試框架。C++時，我們使用gtest.,Python時，我們使用unittest.
- 消息: 在消息層面上，我們使用rostest.建立系統節點，運行一個測試節點，然后逐步拆分系統。我們已經構建了best practices and policies ，進行編寫和運行測試test。
如果你在ROS系統下，開發ros-pkg 或者wg-ros-pkg，安裝build farm 啟動測試構代碼搭建和自動測試在不同的芯片體系下。如果在你提交后，搭建或者測試停止工作，你應該獲得一封郵件來告知相關的錯誤，希望來修復它。參考AutomatedTesting指導說明。
文檔匯總
所有的代碼都應該參照 QAProcess。進行文檔匯總。包括:
- 所有外部的可見的代碼級的API
- 所有外部的可見的ROS級的API
正式發布
ROS社區代碼的發布流程參考release頁面
標準化
在代碼應該用到ROS的服務的地方，遵循以下規則
- 調用rosout打印消息
- 參考Clock應用到時基服務例程。
棄用規則
一旦有人使用的你的代碼，你就有責任不要對他們所謂的對代碼大幅改動，進行釜底抽薪。相反的，使用deprecation,意味著，對于它的移除用清單的形式，標記指定的特性或者內容不再支持。給用戶些時間去適應，作為一個發布版的過程循環，就和移除一樣。
棄用發生在多級情況下，包括:
- API features : 你想從庫中，刪除一個方法。首先需要再API文檔中標記它被棄用了。在DOxgyen中，使用@deprecated. 如果語言支持相關語法，也可以在源碼中標注。比如C/C++，利用 attribute ((deprecated)). 在下一次的發布版中，就要注意棄用的標記在修改清單中，標有未來的發布版本中你希望刪除的部分。如果代碼未來會被廣泛應用，將其標記的明顯些，然后在后面附上注釋。在未來的正式發布版中，刪除即可。
- Packages : 意思就是，你想刪除一個功能包。在wiki文檔中標記為棄用（比如吧DEPRECATED標記在文檔開頭），聲明你想要什么時候刪除。更改說明，包含那些棄用的聲明，會被帶到下一次的發布版中。當功能包被廣泛使用的時候，你就應該使用email，盡量將警告發給那些使用的用戶。
大數據文件，大測試文件
大文件（大小超過1MB）經常不屬于*-ros-pkg倉庫代碼，尤其是他們一般僅僅用在單元測試時。不管某些人是否構建了你的功能包，大的文件會影響checkout的倉庫的時間和效率。
大的數據文件應該被托管到公共的web主網頁。在web服務器上，你也可以僅僅放置你所需要的文件。文件的托管可以在download.ros.org。請聯系ros-release@lists.ros.org 獲取更多信息。在你打開上傳請求之前，鼓勵你去查找是否已存在你所需要的文件。
下載文件，請使用catkin_download_test_data。 如果，你在更早的rosbuild時候，使用 rosbuild_download_test_data(URL MD5SUM) 宏定義。比如：
catkin_download_test_data(${PROJECT_NAME}_saloon.baghttp://downloads.foo.com/bags/saloon.bagDESTINATION ${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_SHARE_DESTINATION}/testMD5 01603ce158575da859b8afff5b676bf9) rosbuild_download_test_data(http://code.ros.org/svn/data/robot_pose_ekf/zero_covariance.bag test/zero_covariance.bag 0a51b4f5001f446e8466bf7cc946fb86)總結
以上是生活随笔為你收集整理的ROS机器人操作系统中级教程 5的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： IMT愿景建议书定义的13个能力
- 下一篇： ssm+java计算机毕业设计东北的尽头