Names

グラフリソース名

グラフリソース名は、Nodesや、Parametersや、Topicsや、ServicesなどのようにROSコンピュテーショングラフのすべてのリソースに使用される階層的な命名構造を提供します。これらのグラフリソース名はROSで大きく複雑なシステムを組むにあたって非常に強力かつ中心的なものです。 よって、グラフリソース名がどのように働くか、また、どのように扱えるかを理解することは大切なこととなります。

ここで、いくつかの例を示します。

  • / (the global namespace)

  • /foo

  • /stanford/robot/name

  • /wg/node1

グラフリソース名はカプセル化を提供するためのROSの重要なメカニズムです。 各リソースは名前空間の中で定義されます。それは他の多くのリソースと名前空間を共有するかもしれません。 一般に、リソースはそれらの名前空間の中でリソースを作成できます、そして、それらは名前空間以内かそれら自身の名前空間を超えてリソースにアクセスできます。 異なった名前空間におけるリソースの間でコネクションを作ることができます。しかし、両方の名前空間を統合してしまう危険性を秘めています。 このカプセル化は、アクシデント的に違う場所で間違った名前が使われたり、グローバルが名前をハイジャックしたりすることから分離します。

名前は相対的に保存されます。よってリソースはどの名前空間にいるかを考慮されなくても良いです。この仕組みは、あたかも全てのノードが最上位の名前空間に存在するかのようにそれらが連携して動くプログラミングの手法を単純化します。これらのノードを統合して、より大きなシステムを構築する際、これらのノードはそれらのコードの集まりが定義されている名前空間まで押し込めることができます。例えば、あるケースとして、Stanford demo と Willow Garage demoを利用し、stanfordとwgのサブグラフを含む新しいデモにそれらを合併することができるでしょう。もし両方のデモが、あるノードを'camera'と命名されるものを持っていたとしても、それらは競合しません。ツール(e.g. グラフ可視化)やパラメータ(e.g. demo_name)など、グラフ全体から見える必要があるものは、最上位のノードによって作成することができます。

有効な名前

有効な名前は以下のような特徴を持つ:

  1. 最初の文字はアルファベットの小文字・大文字 ([a-z|A-Z]), チルダ (~), またはスラッシュ(/)

  2. それに続く文字として英数字 ([0-9|a-z|A-Z]), アンダースコア (_), またはスラッシュ (/)

例外: 基底名 (以下に記載) スラッシュ (/) またはチルダ(~) を使用できない.

Resolving

ROSには4つのグラフリソース名がある: base, relative, global, およびprivateは以下の構文を持つ。:

  • base

  • relative/name

  • /global/name

  • ~private/name

初期設定にて, ノードの名前空間は相対的に解決されています. 例えば, ノード /wg/node1/wg を名前空間として持つので, 名前 node2/wg/node2というノードとして解決されます.

名前空間を限定する修飾詞を持たない名前は全て何でも基底名となります. 基底名は実際、 相対名の部分集合で同等の解決ルールを持ちます. 基底名はとても頻繁にノード名を初期化します。

"/"ではじまる名前はglobalです. これらは完全に分離されています. しかし、グローバル名はコードの移植性を制限するため、可能な限りは使用を避けるべきです。

"~"で始まる名前はprivateです. これらはノード名を名前空間に変換します. 例えば、 名前空間/wg/node1はプライベートの名前空間/wg/node1を持っています. プライベート名は、パラメータサーバを経由して、ある特定のノードに対してパラメータを渡す際に有用です.

相対的(デフォルト)名前解決の例:

  • グローバルな名前空間/内のノードnode1がリソースbarにアクセスする時, それは名前/barとして解決される.

  • 名前空間/wg/内のノードnode2がリソースfooにアクセスする時, それは名前/wg/fooとして解決される.

  • 名前空間/wg/内のノードnode3がリソースfoo/barにアクセスする時, それは名前/wg/foo/barとして解決される.

グローバルな名前解決の例:

  • グローバルな名前空間/内のノードnode1がリソース/barにアクセスする時, それは名前/barとして解決される.

  • 名前空間/wg/内のノードnode2がリソースfooにアクセスする時, それは名前/fooとして解決される.

  • 名前空間/wg/内のノードnode3がリソースfoo/barにアクセスする時, それは名前/foo/barとして解決される.

プライベートな名前解決の例:

  • グローバルな名前空間/内のノードnode1がリソース~barにアクセスする時, それは名前/node1/barとして解決される.

  • 名前空間/wg/内のノードnode2がリソース~fooにアクセスする時, それは名前/wg/node2/fooとして解決される.

  • 名前空間/wg/内のノードnode3がリソース~foo/barにアクセスする時, それは名前/wg/node3/foo/barとして解決される.

リマッピング

ROSノード内のあらゆる名前は、端末でノードが立ちあがる時に再配置することができます。この機能についての詳細は, Remapping Argumentsを参照してください.

パッケージリソース名

パッケージリソース名は、ROS内でファイルシステム階層の概念とともに、ディスク上のファイルとデータ型を参照するプロセスを単純化するために使用されています。パッケージリソース名の仕組みはとても単純です: これらは単にリソースが何の中にあるかということとリソースそのものの名前を表す Package の名前を表しています. 例えば, 名前 "std_msgs/String" はパッケージ"std_msgs"の中にあるメッセージタイプ"String"を表しています.

パッケージリソース名を利用している、いくつかのROS関連ファイルが含むもの:

パッケージリソース名は、ファイルパスよりもかなり短く表されるという点を除き、ファイルパスに類似しています. これはROSがディスク上にパッケージを配置する機能によるもので、 それらの中身についてさらなる想定をもたらします. 例えば, メッセージに関する記載は常にmsgサブディレクトリに保存され、.msg拡張子を持つため, std_msgs/Stringpath/to/std_msgs/msg/String.msgの省略表現となります. 同様に, ノード型foo/barは実行可能パーミッションがあるパッケージfoo内のbarというファイル名を持つファイルを検索することに相当します.

Wiki: ja/Names (last edited 2015-10-13 10:47:15 by TakehiroHagiwara)