（訳注：最新の情報は原文を参照してください．）

Contents

  1. ROS ファイル システム水準
  2. ROS コンピュテーション グラフ水準
  3. ROS コミュニティ水準
  4. ROS 名前
    1. Names
      1. Graph Resource Names
      2. Package Resource Names

ROS には ファイル システム・コンピュテーション グラフ・コミュニティという3つの水準のコンセプトが存在します．これらの水準とコンセプトについては，以下に要約して説明するとともに，後でROS ユーザ マニュアルにおいてより個々に分け入って詳しく説明します．

3つの水準のコンセプトに加えて，ROS には2種類の名前があります．それはパッケージ リソース名とグラフ リソース名です．以下ではこれらについて話します．

ROS ファイル システム水準

ファイル システム水準のコンセプトは，ディスク内で見つかるROSリソースにあります．それは:

  • パッケージ: パッケージはROSを形成するソフトウェアの主な単位です．一つのパッケージには，ROSのランタイム プロセス（ノード）・ROS依存ライブラリ・環境設定ファイル・その他の一緒に使用すると有用なものが含まれている場合があります．

  • マニフェスト: マニフェストはライセンス情報や依存関係（コンパイラのフラグといった，言語依存項目など）を含めた，パッケージについてのデータを規定します．

  • スタック: スタックはナビゲーション スタックのような機能の寄せ集めを提供するパッケージのコレクションです．スタックはまた，ソフトウェア リリースの単位であり，バージョン番号と関係しています．

  • スタック マニフェスト: スタック マニフェストはライセンス情報や他のスタックとの依存関係を含んだ，スタックについてのデータを提供します．

  • メッセージ (msg) タイプ: メッセージの説明は，my_package/msg/MyMessageType.msgに格納されており，ROS で送られるメッセージのデータ構成が宣言されています．

  • サービス (srv) タイプ: サービスの説明は，my_package/srv/MyServiceType.srvに格納されており，ROS サービス のリクエストとレスポンスのデータ構成が宣言されています．

ROS コンピュテーション グラフ水準

コンピュテーション グラフとは，データを共有して動作している ROS プロセスの Peer-to-Peer ネットワークのことです．ROS におけるコンピュテーション グラフの基本的なコンセプトは，ノード・マスター・パラメータ サーバ・メッセージ・サービス・トピック・バグで，これらからの全てのデータは別々の経路を経てグラフにもたらされます．

  • ノード: ノードはコンピュテーションを行うプロセスです．ROS は，きめ細やかなスケールでモジュール化するように設計されており，ロボットの制御システムは通常多くのノードで構成されます．例えば，一つのノードが測域センサを制御し，一つのノードが車輪のモータを制御し，一つのノードが位置を計測し，一つのノードが経路を計画し，一つのノードがシステムのグラフィカルな見栄えを提供するなどといったものです．ROS ノードは roscpp か rospy といった，ROS クライアント ライブラリ を用いて記述されています．

  • マスター: ROS マスターは名前登録とグラフのすき間探索を行います．マスターがないと，ノードは他のノードを探したり，メッセージを交換したり，サービスを要求したりすることができません．

  • パラメータ サーバ: パラメータ サーバは中心位置のキーによってデータが格納されるようにします．現在はマスターの一部となっています．

  • メッセージ: ノード同士は メッセージ のやり取りで通信します．一つのメッセージは型フィールドから成る単純なデータ構造です．一般的な基本型（整数型・浮動小数点型・真偽値など）が基本的な配列として提供されています．メッセージは C の構造体のように，任意にネストや配列を含むことができます．

  • トピック: メッセージは交換器を通じて意味を配信・購読されてやりとりされます．ノードは 配信 で与えられた トピック に従ってメッセージを送信します．トピックとはメッセージの内容を区別するための 名前 です．ある種のデータに興味をもつノードは，それにふさわしいトピックを 購読 します．一つのトピックには多くの配信者と購読者が同時に存在するでしょう．また，一つのノードは複数のトピックで配信したり購読したり，あるいはどちらもするでしょう．普通は配信者も購読者もお互いの存在を意識しません．この発想は情報の生成をその廃棄の手間から解き放つためのものです．理論的には，トピックを強力なメッセージ型の経路と考えることもできます．経路はそれぞれが名前を持っており，正しい型である限り誰でも経路に接続してメッセージを送ったり受け取ったりすることができます．

  • サービス: 配信と購読のモデルは柔軟な通信の枠組みです．しかしその多対多で一方通行の信号は，発行された（distributedの訳）システムで頻繁に求められるリクエストとレスポンスの通信にはふさわしくありません．リクエストとレスポンスは，リクエストとレスポンスのための一対のメッセージ構造として定義された サービス 経路で行われます．供給側のノードは 名前 を下にサービスを要求し，クライアントはサービスを使用してリクエストを送り，レスポンスを待ちます．ROS クライアント ライブラリには一般的にこのようなやり取りが，プログラマが遠隔で手順を呼び出すために存在します．

  • バグ: バグは ROS メッセージ データを保存したり再生したりするための書式です．バグはデータを保管するために重要な機構です．そのデータはアルゴリズムの開発とテストに必要だが，正確を規することは難しい，センサ データのようなものです．

ROS/Concepts/ROS_basic_concepts.png

ROS コミュニティ水準

ROS コミュニティ水準のコンセプトは異なるコミュニティとソフトウェアと知識を交換することを可能にする ROS の資産です．この資産に含まれるのは:

  • ディストリビューション: ROS ディストリビューションはあなたがインストール可能な スタック のバージョンのコレクションです．ディストリビューションは Linuxのディストリビューションの役割と似た働きをし，ソフトウェア コレクションのインストールとソフトウェアを超えたバージョン管理を簡易化します．

  • リポジトリ: ROS はそれぞれ別のロボット ソフトウェア構成を開発・リリースする機関のコード リポジトリで構成されるネットワークに依存しています．

  • ROS Wiki: ROS コミュニティ　Wiki は ROS についての情報を文書化するための中心的な場所です．誰でもアカウントを作成したり，文書を寄稿したり，コレクションやアップデートを供給したり，チュートリアルを書いたりすることができます．

  • バグ チケット システム: ファイルのチケットについての情報は チケット を参照してください．

  • メーリングリスト: ros-users メーリングリスト はフォーラムで ROS ソフトウェアについて質問するのと同様に， ROS 新規アップデートについて話し合うのに一番の場です．

  • ブログ: Willow Garage のブログ では，通常のアップグレードや写真・動画についても提供されます．

ROS 名前

Contents

  1. Names
    1. Graph Resource Names
      1. Valid Names
      2. Resolving
      3. Remapping
    2. Package Resource Names
      1. Valid Names

Names

Graph Resource Names

Graph Resource Names provide a hierarchical naming structure that is used for all resources in a ROS Computation Graph, such as Nodes, Parameters, Topics, and Services. These names are very powerful in ROS and central to how larger and more complicated systems are composed in ROS, so it is critical to understand how these names work and how you can manipulate them.

Before we describe names further, here are some example names:

  • / (the global namespace)

  • /foo

  • /stanford/robot/name

  • /wg/node1

Graph Resource Names are an important mechanism in ROS for providing encapsulation. Each resource is defined within a namespace, which it may share with many other resources. In general, resources can create resources within their namespace and they can access resources within or above their own namespace. Connections can be made between resources in distinct namespaces, but this is generally done by integration code above both namespaces. This encapsulation isolates different portions of the system from accidentally grabbing the wrong named resource or globally hijacking names.

Names are resolved relatively, so resources do not need to be aware of which namespace they are in. This simplifies programming as nodes that work together can be written as if they are all in the top-level namespace. When these Nodes are integrated into a larger system, they can be pushed down into a namespace that defines their collection of code. For example, one could take a Stanford demo and a Willow Garage demo and merge them into a new demo with stanford and wg subgraphs. If both demos had a Node named 'camera', they would not conflict. Tools (e.g. graph visualization) as well as parameters (e.g. demo_name) that need to be visible to the entire graph can be created by top-level Nodes.

Valid Names

A valid name has the following characteristics:

  1. First character is an alpha character ([a-z|A-Z]), tilde (~) or forward slash (/)

  2. Subsequent characters can be alphanumeric ([0-9|a-z|A-Z]), underscores (_), or forward slashes (/)

Exception: base names (described below) cannot have forward slashes (/) or tildes (~) in them.

Resolving

There are four types of Graph Resource Names in ROS: base, relative, global, and private, which have the following syntax:

  • base

  • relative/name

  • /global/name

  • ~private/name

By default, resolution is done relative to the node's namespace. For example, the node /wg/node1 has the namespace /wg, so the name node2 will resolve to /wg/node2.

Names with no namespace qualifiers whatsoever are base names. Base names are actually a subclass of relative names and have the same resolution rules. Base names are most frequently used to initialize the node name.

Names that start with a "/" are global -- they are considered fully resolved. Global names should be avoided as much as possible as they limit code portability.

Names that start with a "~" are private. They convert the node's name into a namespace. For example, node1 in namespace /wg/ has the private namespace /wg/node1. Private names are useful for passing parameters to a specific node via the parameter server.

Relative (default) name resolution examples:

  • If node node1 in the global / namespace accesses the resource bar, that will resolve to the name /bar.

  • If node node2 in the /wg/ namespace accesses the resource foo, that will resolve to the name /wg/foo.

  • If node node3 in the /wg/ namespace accesses the resource foo/bar, that will resolve to the name /wg/foo/bar.

Global name resolution examples:

  • If node node1 in the global / namespace accesses the resource /bar, that will resolve to the name /bar.

  • If node node2 in the /wg/ namespace accesses the resource /foo, that will resolve to the name /foo.

  • If node node3 in the /wg/ namespace accesses the resource /foo/bar, that will resolve to the name /foo/bar.

Private name resolution examples:

  • If node node1 in the global / namespace accesses the resource ~bar, that will resolve to the name /node1/bar.

  • If node node2 in the /wg/ namespace accesses the resource ~foo, that will resolve to the name /wg/node2/foo.

  • If node node3 in the /wg/ namespace accesses the resource ~foo/bar, that will resolve to the name /wg/node3/foo/bar.

Remapping

Any name within a ROS Node can be remapped when the Node is launched at the command-line. For more information on this feature, see Remapping Arguments.

Package Resource Names

Package Resource Names are used in ROS with Filesystem-Level concepts to simplify the process of referring to files and data types on disk. Package Resource Names are very simple: they are just the name of the Package that the resource is in plus the name of the resource. For example, the name "std_msgs/String" refers to the "String" message type in the "std_msgs" Package.

Some of the ROS-related files that may be referred to using Package Resource Names include:

Package Resource Names are very similar to file paths, except they are much shorter. This is due to the ability of ROS to locate Packages on disk and make additional assumptions about their contents. For example, Message descriptions are always stored in the msg subdirectory and have the .msg extension, so std_msgs/String is shorthand for path/to/std_msgs/msg/String.msg. Similarly, the Node type foo/bar is equivalent to searching for a file named bar in Package foo with executable permissions.

Valid Names

Package Resource Names have strict naming rules as they are often used in auto-generated code. For this reason, a ROS package cannot have special characters other than an underscore, and they must start with an alphabetical character. A valid name has the following characteristics:

  1. First character is an alpha character ([a-z|A-Z])

  2. Subsequent characters can be alphanumeric ([0-9|a-z|A-Z]), underscores (_) or a forward slash (/)

  3. There is at most one forward slash ('/').

Wiki: ja/ROS/Concepts (last edited 2010-01-11 17:38:34 by KentaYonekura)

Except where otherwise noted, the ROS wiki is licensed under Creative Commons Attribution 3.0.