當前位置：首頁 > 运维知识 > windows >内容正文

windows

ROS机器人操作系统中级教程 5

發布時間：2023/12/29 windows 19 豆豆

生活随笔收集整理的這篇文章主要介紹了 ROS机器人操作系统中级教程 5 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

自定義消息

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

教程難度: 中級

下節預告: 在Pyhon中使用C++類

自定義消息

自定義一個消息類型很簡單，只要將.msg文件放到一個package的msg文件夾下即可。請參考初級教程中的創建.msg文件(不要忘記選擇相應的編譯構建系統)。

引用和輸出消息類型

消息類型都被歸屬到與功能包相對應的域名空間下，例如：

C++

#include <std_msgs/String.h>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開發者說明

源代碼管理

Bug追溯

代碼布局

功能包

GUI 工具包

代碼構建

證書

版權

調試

測試

文檔匯總

正式發布

標準化

棄用規則

大數據文件，大測試文件

開發者說明

ROS是一個龐大的系統，許多人共同開發。為了進行合理地管理，我們已經寫好了開發指導說明。請按照下面的指導說明，合理布局你的代碼。

參考:

Quality assurance process

ROS C++ Style Guide

ROS Python Style Guide

ROS Javascript Style Guide

Naming Conventions

CommonProcedures

源代碼管理

支持使用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的一個例子:

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

版權

如果只自己使用，版權屬于自己。
如果受雇于某些人，或者公司（比如Willow Garage），版權就屬于公司。

調試

ROS里的調試工具，包括但不限于：

GDB
Oprofile
Valgrind

一般性建議:

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

(gdb) run arg1 arg2 arg3

當程序崩潰crashes時，利用gdb的bt指令來進行追溯和探究。

對于一些棘手的bug，尤其涉及到內存崩潰的。試著實用工具valgrind:

valgrind -v foo arg1 arg2 arg3

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个能力
下一篇： echarts改变滚动条的样式