（訳注：最新の情報は原文を参照してください．）
ROS 概観: はじめに | コンセプト | 上位概念 | クライアント ライブラリ | Technical Overview
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 におけるコンピュテーション グラフの基本的なコンセプトは，ノード, マスター, パラメータ サーバ, メッセージ, サービス, トピック, バグで，これらからの全てのデータは別々の経路を経てグラフにもたらされます．
New in Diamondback
ノード: ノードはコンピュテーションを行うプロセスです．ROS は，きめ細やかなスケールでモジュール化するように設計されており，ロボットの制御システムは通常多くのノードで構成されます．例えば，一つのノードが測域センサを制御し，一つのノードが車輪のモータを制御し，一つのノードが位置を計測し，一つのノードが経路を計画し，一つのノードがシステムのグラフィカルな見栄えを提供するなどといったものです．ROS ノードは roscpp か rospy といった，ROS クライアント ライブラリ を用いて記述されています．
マスター: ROS マスターは名前登録とグラフのすき間探索を行います．マスターがないと，ノードは他のノードを探したり，メッセージを交換したり，サービスを要求したりすることができません．
パラメータ サーバ: パラメータ サーバは中心位置のキーによってデータが格納されるようにします．現在はマスターの一部となっています．
メッセージ: ノード同士は メッセージ のやり取りで通信します．一つのメッセージは型フィールドから成る単純なデータ構造です．一般的な基本型（整数型・浮動小数点型・真偽値など）が基本的な配列として提供されています．メッセージは C の構造体のように，任意にネストや配列を含むことができます．
トピック: メッセージは交換器を通じて意味を配信・購読されてやりとりされます．ノードは 配信 で与えられた トピック に従ってメッセージを送信します．トピックとはメッセージの内容を区別するための 名前 です．ある種のデータに興味をもつノードは，それにふさわしいトピックを 購読 します．一つのトピックには多くの配信者と購読者が同時に存在するでしょう．また，一つのノードは複数のトピックで配信したり購読したり，あるいはどちらもするでしょう．普通は配信者も購読者もお互いの存在を意識しません．この発想は情報の生成をその廃棄の手間から解き放つためのものです．理論的には，トピックを強力なメッセージ型の経路と考えることもできます．経路はそれぞれが名前を持っており，正しい型である限り誰でも経路に接続してメッセージを送ったり受け取ったりすることができます．
サービス: 配信と購読のモデルは柔軟な通信の枠組みです．しかしその多対多で一方通行の信号は，発行された（distributedの訳）システムで頻繁に求められるリクエストとレスポンスの通信にはふさわしくありません．リクエストとレスポンスは，リクエストとレスポンスのための一対のメッセージ構造として定義された サービス 経路で行われます．供給側のノードは 名前 を下にサービスを要求し，クライアントはサービスを使用してリクエストを送り，レスポンスを待ちます．ROS クライアント ライブラリには一般的にこのようなやり取りが，プログラマが遠隔で手順を呼び出すために存在します．
バグ: バグは ROS メッセージ データを保存したり再生したりするための書式です．バグは、アルゴリズムの開発およびテストに必要ではあるが集めるのが難しいこともあるデータ（センサーデータなど）を蓄積するための重要な機構です．
ROS コミュニティレベル
ROS コミュニティレベルのコンセプトは異なるコミュニティとソフトウェアと知識を交換することを可能にする ROS の資産です．この資産に含まれるのは:
ディストリビューション: ROS ディストリビューションはあなたがインストール可能な スタック のバージョンのコレクションです．ディストリビューションは Linuxのディストリビューションの役割と似た働きをし，ソフトウェア コレクションのインストールとソフトウェアを超えたバージョン管理を簡易化します．
リポジトリ: ROS はそれぞれ別のロボット ソフトウェア構成を開発・リリースする機関のコード リポジトリで構成されるネットワークに依存しています．
ROS Wiki: ROS コミュニティ - Wiki は ROS についての情報を文書化するための中心的な場所です．誰でもアカウントを作成したり，文書を寄稿したり, コレクションやアップデートを供給したり，チュートリアルを書いたりすることができます．
バグ チケット システム: ファイルのチケットについての情報は チケット を参照してください．
メーリングリスト: ros-users メーリングリスト はフォーラムで ROS ソフトウェアについて質問するのと同様に， ROS 新規アップデートについて話し合うのに一番の場です．
ブログ: Willow Garage のブログ では，通常のアップグレードや写真・動画についても提供されます．
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)など、グラフ全体から見える必要があるものは、最上位のノードによって作成することができます。
有効な名前
有効な名前は以下のような特徴を持つ：
最初の文字はアルファベットの小文字・大文字 ([a-z|A-Z]), チルダ (~), またはスラッシュ(/)
それに続く文字として英数字 ([0-9|a-z|A-Z]), アンダースコア (_), またはスラッシュ (/)
例外: 基底名 (以下に記載) スラッシュ (/) またはチルダ(~) を使用できない.
名前解決
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 |
/bar -> /bar |
~bar -> /node1/bar |
/wg/node2 |
bar -> /wg/bar |
/bar -> /bar |
~bar -> /wg/node2/bar |
/wg/node3 |
foo/bar -> /wg/foo/bar |
/foo/bar -> /foo/bar |
~foo/bar -> /wg/node3/foo/bar |
リマッピング
ROSノード内のあらゆる名前は、端末でノードが立ちあがる時に再配置することができます。この機能についての詳細は, Remapping Argumentsを参照してください.
パッケージリソース名
パッケージリソース名は、ROS内でファイルシステム階層の概念とともに、ディスク上のファイルとデータ型を参照するプロセスを単純化するために使用されています。パッケージリソース名の仕組みはとても単純です: これらは単にリソースが何の中にあるかということとリソースそのものの名前を表す パッケージ の名前を表しています. 例えば, 名前 "std_msgs/String" はパッケージ"std_msgs"の中にあるメッセージタイプ"String"を表しています.
パッケージリソース名を利用している、いくつかのROS関連ファイルが含むもの：
パッケージリソース名は、ファイルパスよりもかなり短く表されるという点を除き、ファイルパスに類似しています. これはROSがディスク上にパッケージを配置する機能によるもので、 それらの中身についてさらなる想定をもたらします. 例えば, メッセージに関する記載は常にmsgサブディレクトリに保存され、.msg拡張子を持つため, std_msgs/Stringがpath/to/std_msgs/msg/String.msgの省略表現となります. 同様に, ノード型foo/barは実行可能パーミッションがあるパッケージfoo内のbarというファイル名を持つファイルを検索することに相当します.
有効な名前
パッケージリソース名は厳密な命名規則を持っており，その規則は自動生成コードで使われます．この理由により，ROSのパッケージはアンダースコア以外の特殊文字が使えず，かつアルファベット文字から始めなくてはなりません．有効な名前は以下の特徴を持ちます．
- 最初の文字はアルファベットの小文字・大文字 ([a-z|A-Z])
それに続く文字として英数字 ([0-9|a-z|A-Z]), アンダースコア (_), またはスラッシュ (/)
スラッシュ (/) は最大1個
Code API
roscpp::names API reference (ROS Indigo)
