自定義消息

教程描述: 本教程將展示如何使用ROS消息描述語言來定義你自己的消息類型.

教程難度: 中級(jí)

下節(jié)預(yù)告: 在Pyhon中使用C++類

目錄

自定義消息

引用和輸出消息類型

C++

Python

依賴項(xiàng)

自定義消息

自定義一個(gè)消息類型很簡(jiǎn)單，只要將.msg文件放到一個(gè)package的msg文件夾下即可。請(qǐng)參考初級(jí)教程中的創(chuàng)建.msg文件(不要忘記選擇相應(yīng)的編譯構(gòu)建系統(tǒng))。

引用和輸出消息類型

消息類型都被歸屬到與功能包相對(duì)應(yīng)的域名空間下，例如：

C++

#include <std_msgs/String.h>std_msgs::String msg;

Python

from std_msgs.msg import Stringmsg = String()

依賴項(xiàng)

如果你要使用在其他功能包里定義的消息類型，不要忘記添加以下語句：

<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。同時(shí)需要修改CMakeList.txt：

find_package(message_generation) catkin_package(CATKIN_DEPENDS message_runtime) add_message_files(FILES your_msg_file.msg)

教程ROSNodeTutorialC++和ROSNodeTutorialPython展示了使用自定義消息類型來創(chuàng)建talker和listener的C++和Python實(shí)現(xiàn)。

補(bǔ)充說明：

官網(wǎng)還有3個(gè)教程，分別如下：

在python中使用C++類

本教程闡述一種在python中使用C++類的方法。鏈接如下：中文 英文

將ROS項(xiàng)目進(jìn)行打包

本教程介紹如何快速打包和部署ROS項(xiàng)目。鏈接如下：英文

如何編寫教程

本教程介紹在編輯ros.org維基時(shí)，可以用到的模板和宏定義，并附有示例以供參考。鏈接如下：中文 英文

以上內(nèi)容可以查閱對(duì)應(yīng)資料進(jìn)行自主學(xué)習(xí)，至此關(guān)于ROS機(jī)器人操作系統(tǒng)的基礎(chǔ)概念部分（包括安裝、配置、初級(jí)和中級(jí)）就全部結(jié)束了。稍后課程將針對(duì)功能包、接口和庫的學(xué)習(xí)與使用進(jìn)行介紹，以專題設(shè)計(jì)為主線展開。

ROS開發(fā)者說明

目錄

ROS開發(fā)者說明

源代碼管理

Bug追溯

代碼布局

功能包

GUI 工具包

代碼構(gòu)建

證書

版權(quán)

調(diào)試

測(cè)試

文檔匯總

正式發(fā)布

標(biāo)準(zhǔn)化

棄用規(guī)則

大數(shù)據(jù)文件，大測(cè)試文件

---

開發(fā)者說明

ROS是一個(gè)龐大的系統(tǒng)，許多人共同開發(fā)。為了進(jìn)行合理地管理，我們已經(jīng)寫好了開發(fā)指導(dǎo)說明。請(qǐng)按照下面的指導(dǎo)說明，合理布局你的代碼。

參考:

Quality assurance process

ROS C++ Style Guide

ROS Python Style Guide

ROS Javascript Style Guide

Naming Conventions

CommonProcedures

源代碼管理

支持使用Git、Mercurial、Subversion 和Bazaar進(jìn)行代碼管理。由于ROS社區(qū)是分散的，歡迎你將代碼托管到任何公共訪問的地方(比如GitHub、 Bitbucket、Google Code). 主要的ROS基礎(chǔ)代碼會(huì)被發(fā)布到github.com的幾個(gè)組織單元several organization units下面。關(guān)于建議的倉庫使用說明參考RecommendedRepositoryUsage

• 只添加手動(dòng)編寫的源代碼文件，以及必須的構(gòu)建功能包的相關(guān)文件。不要添加機(jī)器自動(dòng)生成的文件，比如目標(biāo)文件(*.o)，庫文件(.a, .so, .dll), 或者自動(dòng)配置腳本文件。
• • svn add 將會(huì)遞歸到子目錄里添加所有文件. 在svn add之前先操作下 make clean。
• • 不要添加大的二進(jìn)制文件: 通過web服務(wù)器上傳，下載到本地的構(gòu)建文件夾去。
• 盡早且經(jīng)常性提交自己的代碼。不在源碼管理范圍內(nèi)的任何文件都應(yīng)該作為草稿（scratch）存儲(chǔ)。
• 盡量保持每次的提交集中到一處特殊的更改，而不是一次提交多方面的更改，這樣更容易回溯代碼。
• 每一次的提交都寫清更改說明。
• 不要打亂構(gòu)建結(jié)構(gòu). 在check in之前確保你的代碼能夠順利編譯。

Bug追溯

針對(duì)每一個(gè)功能包，利用單獨(dú)的bug tracker，實(shí)現(xiàn)bug報(bào)告，增強(qiáng)請(qǐng)求，和任務(wù)分配。經(jīng)常性的，在本站的頁面上，你會(huì)看的一些具體的bug tracker的相關(guān)鏈接。

對(duì)于代碼的托管GitHub作為一個(gè)倉庫的通用的bug tracker。

代碼維護(hù)者將會(huì)為每個(gè)報(bào)告的問題創(chuàng)建一個(gè)里程式標(biāo)記(milestone)。當(dāng)問題被定位時(shí)，可以給報(bào)告者一個(gè)合適的反饋。這些里程標(biāo)記就是ROS正式版(比如 Groovy or Hydro) 或者細(xì)分版本(比如 Hydro beta 1). 更多的是，當(dāng)問題沒被修復(fù)時(shí)，會(huì)賦以標(biāo)記untargeted。這可能是由于開發(fā)者的時(shí)間緊迫或者可靠性的考慮。

為了讓用戶表達(dá)自己的想法，針對(duì)已發(fā)布的軟件版本，測(cè)試是否已經(jīng)修復(fù)bug，維護(hù)者應(yīng)該要么，在關(guān)閉問題報(bào)告的時(shí)候，發(fā)布一個(gè)嘗試版本，要么為每一個(gè)更細(xì)化的版本設(shè)置標(biāo)記，在下個(gè)里程標(biāo)記之前，標(biāo)記問題報(bào)告。這樣一來，對(duì)用戶來說，讓所包含的問題本身來決定發(fā)布版的bug是否已經(jīng)被修復(fù)。

當(dāng)你發(fā)現(xiàn)一個(gè)bug時(shí)，開啟一個(gè)指派（ticket）。當(dāng)你需要新功能的時(shí)候，打開一個(gè)指派。郵件或者發(fā)布到answers.ros.org或者郵件列表都有可能被遺忘。但是，指派的方式反而就不會(huì)那么容易忘記。

指派的時(shí)候盡量遵循這些原則.

盡量包含bug重現(xiàn)時(shí)，需要的指令。They should include instructions for reproducing the bug.

盡量描述問題出現(xiàn)時(shí)的，系統(tǒng)運(yùn)行狀態(tài)。（用的什么系統(tǒng)版本，涉及的功能包有哪些。

不要畏懼指派。許多開發(fā)者都會(huì)指派給他們自己，比如利用Trac。

如果你不確定出現(xiàn)問題時(shí)涉及的的功能包或者問題確實(shí)是一個(gè)bug，請(qǐng)首先訪問answers.ros.org。

代碼布局

package功能包由代碼組織而成，而功能包組成一個(gè)單獨(dú)的倉庫responsitory。功能包是作為代碼構(gòu)建的基本單位。

尤其注意！建議，在GitHub上，在倉庫的根目錄創(chuàng)建一個(gè)README.md，用來向用戶說明代碼倉庫的具體細(xì)節(jié)。建議，在ROS wiki頁面設(shè)置鏈接到指定的包含的軟件包。參照 this article 獲取更多的幫助.

功能包

ROS功能包和系統(tǒng)的構(gòu)建依賴于manifest.xml。

每一個(gè)功能包都必須，在功能包所在的頂層目錄，存在一個(gè)manifest.xml文件.

最基本的，manifest必須包含下面的三部分：

• description
• author
• license

下面舉一個(gè)roscpp節(jié)點(diǎn)的一個(gè)模板例子：

<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的一個(gè)例子:

<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工具包

我們已經(jīng)移植了所有最新的GUI到rqt，這些GUI都是QT基礎(chǔ)的GUI框架。在fuerte使用wxWidgets之前，因交叉編譯的兼容性太差，大部分已有的代碼被重建。 因此對(duì)于新的GUI設(shè)計(jì)，考慮使用rqt。開發(fā)說明從這里獲取(including license consideration when writing in python)。

代碼編譯

基本的代碼編譯工具是CMake(more)。

每一個(gè)創(chuàng)建的功能包的頂層目錄都必須存在CMakeLists.txt。

現(xiàn)在，每一個(gè)功能包都必須有一個(gè)Makefile, 短而精巧。那些沒有經(jīng)過構(gòu)建步驟的功能包不需要任何的構(gòu)建文件。

證書

ROS是開源的，旨在讓來自五湖四海的不同的用戶和開發(fā)者們，從學(xué)生到企業(yè)家們，都可以得到幫助獲取支持。

• 我們傾向自由的開源證書，促進(jìn)代碼的商業(yè)化。
• 傾向建議使用證書BSD 證書。盡可能，新的代碼都應(yīng)該在BSD證書下發(fā)布。
• 所有的ROS代碼都是BSD證書下發(fā)布的選擇BSD的原因 其他任何的OSI促成的證書都是可接受的(fornon-core code)。
• 我們強(qiáng)烈建議使用非對(duì)稱版權(quán)的證書（比如BSD），來進(jìn)行ROS .msg和.srv文件的發(fā)布，所以不妨礙那些自動(dòng)產(chǎn)生的源代碼文件和數(shù)據(jù)結(jié)構(gòu)。
• 工程中的所有文本狀態(tài)的證書都應(yīng)該放到頂層的LICENSES文件目錄下。如果你天劍了一個(gè)并不包括在LICENSE目錄下的證書，添加下證書狀態(tài)即可。
• 每一個(gè)源代碼文件，都應(yīng)該在頂層，包含一個(gè)證書的簡(jiǎn)略版注釋。方便的，LICENSES目錄下也應(yīng)該包含證書的簡(jiǎn)略說明，并且需要不同的語言書寫。
• • 對(duì)于我們發(fā)布的第三方的代碼，證書和版權(quán)會(huì)被予以保護(hù)。
• 我們將嚴(yán)格遵守第三方軟件，例如：
• • 如果庫有證書GPL聲明 or LGPL 聲明，如果你修改了，則你必須發(fā)布修改后的代碼。理想情況下，你必須發(fā)送一個(gè)補(bǔ)丁給庫的維護(hù)者。保持如果修改后的代碼的公共訪問權(quán)限也是必要的。
• • 如果你的功能包使用了GPL'd庫，然后你的功能包也必須進(jìn)行GPL聲明。
• • 如果你的功能包使用了GPL'd庫，那么你就不能使用與GPL不兼容的授權(quán)協(xié)議GPL-incompatible license。 例如，Creative Commons Attribution-Noncommercial-Share Alike 證書是與GPL不兼容的，因?yàn)樗麖?qiáng)加了一些GPL不能做的約束條件(換句話說，就是要求的屬性，禁止商業(yè)使用等).
• 盡可能的，每一個(gè)ROS功能包都以一種單一證書形式予以管理。
• • 一般性的特殊案例：BSD證書代碼（比如 ROS core），在一個(gè)功能包，也會(huì)用到GPL證書聲明的代碼。為了配合GPL，BSD聲明的代碼，是在BSD和GPL多證書下聲明的，用戶可以選擇使用哪個(gè)證書協(xié)議。這當(dāng)然也不是聲明大問題，因?yàn)镚PL增加了一些BSD不要求的一些限制條件。
• ROS功能包和通信系統(tǒng)允許細(xì)致的證書協(xié)議。因?yàn)楣?jié)點(diǎn)通過ROS消息進(jìn)行通信，多節(jié)點(diǎn)通信的代碼不是連接到一起。因此，功能包提供了一種“證書壁壘（license boundary）”。
• • 例外:當(dāng)一個(gè)功能包是庫的形式，并且確實(shí)鏈接到其他的功能包。這種情況下，各個(gè)證書會(huì)被混合聲明在目標(biāo)代碼里。
• 引用: Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers

版權(quán)

遵循Berne Convention版權(quán)，作為作者自動(dòng)擁有版權(quán)，而不管有沒有一個(gè)正式的聲明。無論如何，顯式的版權(quán)聲明有助于長期性項(xiàng)目的管理。

• 每一個(gè)源文件都應(yīng)該在文件頂層上，包含一個(gè)版權(quán)說明注釋，例如 Copyright 2008 Jim Bob。 這個(gè)就是一個(gè)證書的簡(jiǎn)概說明。
• 如果只自己使用，版權(quán)屬于自己。
• 如果受雇于某些人，或者公司（比如Willow Garage），版權(quán)就屬于公司。

調(diào)試

ROS里的調(diào)試工具，包括但不限于：

• GDB
• Oprofile
• Valgrind

一般性建議:

• 如果一個(gè)程序，比如foo、crashes, 首先使用 GDB:可以通過添加一些必要的參數(shù)：

(gdb) run arg1 arg2 arg3

當(dāng)程序崩潰crashes時(shí)，利用gdb的bt指令來進(jìn)行追溯和探究。

• 對(duì)于一些棘手的bug，尤其涉及到內(nèi)存崩潰的。試著實(shí)用工具valgrind:

valgrind -v foo arg1 arg2 arg3

Valgrind可以追蹤所有的內(nèi)存訪問呢，一把可以找到問題的原因。同樣，可以發(fā)現(xiàn)你沒有發(fā)現(xiàn)的其他問題。注意的就是，Valgrind會(huì)拖慢你程序運(yùn)行的節(jié)奏，看起運(yùn)行緩慢。

• master和rospy的日志會(huì)默認(rèn)創(chuàng)建到ROS_ROOT/log。但是，roscpp的客戶端節(jié)點(diǎn)日志默認(rèn)不會(huì)創(chuàng)建。如果你正在以nasty模式調(diào)試時(shí)，你可以設(shè)置構(gòu)建的第二個(gè)參數(shù)WRITE_LOG_FILE（伴隨其他的選項(xiàng)ANONYMOUS_NAME等）。其他選擇是，如果你不想重新編譯節(jié)點(diǎn)，你可以在命令行中添加log:=BLAHBLAH，BLAHBLAH可以是任何東西，也可以什么也不是。

測(cè)試

我們進(jìn)行兩個(gè)級(jí)別的測(cè)試:

• 庫: 在庫的層面上，我們使用用標(biāo)準(zhǔn)的單元測(cè)試框架。C++時(shí)，我們使用gtest.,Python時(shí)，我們使用unittest.
• 消息: 在消息層面上，我們使用rostest.建立系統(tǒng)節(jié)點(diǎn)，運(yùn)行一個(gè)測(cè)試節(jié)點(diǎn)，然后逐步拆分系統(tǒng)。我們已經(jīng)構(gòu)建了best practices and policies ，進(jìn)行編寫和運(yùn)行測(cè)試test。

如果你在ROS系統(tǒng)下，開發(fā)ros-pkg 或者wg-ros-pkg，安裝build farm 啟動(dòng)測(cè)試構(gòu)代碼搭建和自動(dòng)測(cè)試在不同的芯片體系下。如果在你提交后，搭建或者測(cè)試停止工作，你應(yīng)該獲得一封郵件來告知相關(guān)的錯(cuò)誤，希望來修復(fù)它。參考AutomatedTesting指導(dǎo)說明。

文檔匯總

所有的代碼都應(yīng)該參照 QAProcess。進(jìn)行文檔匯總。包括:

• 所有外部的可見的代碼級(jí)的API
• 所有外部的可見的ROS級(jí)的API

正式發(fā)布

ROS社區(qū)代碼的發(fā)布流程參考release頁面

標(biāo)準(zhǔn)化

在代碼應(yīng)該用到ROS的服務(wù)的地方，遵循以下規(guī)則

• 調(diào)用rosout打印消息
• 參考Clock應(yīng)用到時(shí)基服務(wù)例程。

棄用規(guī)則

一旦有人使用的你的代碼，你就有責(zé)任不要對(duì)他們所謂的對(duì)代碼大幅改動(dòng)，進(jìn)行釜底抽薪。相反的，使用deprecation,意味著，對(duì)于它的移除用清單的形式，標(biāo)記指定的特性或者內(nèi)容不再支持。給用戶些時(shí)間去適應(yīng)，作為一個(gè)發(fā)布版的過程循環(huán)，就和移除一樣。

棄用發(fā)生在多級(jí)情況下，包括:

• API features : 你想從庫中，刪除一個(gè)方法。首先需要再API文檔中標(biāo)記它被棄用了。在DOxgyen中，使用@deprecated. 如果語言支持相關(guān)語法，也可以在源碼中標(biāo)注。比如C/C++，利用 attribute ((deprecated)). 在下一次的發(fā)布版中，就要注意棄用的標(biāo)記在修改清單中，標(biāo)有未來的發(fā)布版本中你希望刪除的部分。如果代碼未來會(huì)被廣泛應(yīng)用，將其標(biāo)記的明顯些，然后在后面附上注釋。在未來的正式發(fā)布版中，刪除即可。
• Packages : 意思就是，你想刪除一個(gè)功能包。在wiki文檔中標(biāo)記為棄用（比如吧DEPRECATED標(biāo)記在文檔開頭），聲明你想要什么時(shí)候刪除。更改說明，包含那些棄用的聲明，會(huì)被帶到下一次的發(fā)布版中。當(dāng)功能包被廣泛使用的時(shí)候，你就應(yīng)該使用email，盡量將警告發(fā)給那些使用的用戶。

大數(shù)據(jù)文件，大測(cè)試文件

大文件（大小超過1MB）經(jīng)常不屬于*-ros-pkg倉庫代碼，尤其是他們一般僅僅用在單元測(cè)試時(shí)。不管某些人是否構(gòu)建了你的功能包，大的文件會(huì)影響checkout的倉庫的時(shí)間和效率。

大的數(shù)據(jù)文件應(yīng)該被托管到公共的web主網(wǎng)頁。在web服務(wù)器上，你也可以僅僅放置你所需要的文件。文件的托管可以在download.ros.org。請(qǐng)聯(lián)系ros-release@lists.ros.org 獲取更多信息。在你打開上傳請(qǐng)求之前，鼓勵(lì)你去查找是否已存在你所需要的文件。

下載文件，請(qǐng)使用catkin_download_test_data。 如果，你在更早的rosbuild時(shí)候，使用 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)

總結(jié)

以上是生活随笔為你收集整理的ROS机器人操作系统中级教程 5的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。