ROS2について整理してみた（Basic Concept編）

背景・目的

以前、Autowareについて整理しました。
このAutowareでベースとしている技術である、ROS（ROS2）について特徴を整理します。

まとめ

下記に特徴を整理します。

特徴	説明
ROSとは	Robot Operating Systemの略 ロボット アプリケーションを構築するためのソフトウェア ライブラリとツールのセット ドライバーや最先端の​​アルゴリズムから強力な開発者ツールまで、ROS には次のロボット プロジェクトに必要なオープン ソース ツールがある
Concepts	ROS 2 は、異なるプロセス間でのメッセージ パッシングを可能にする、厳密に型指定された匿名のパブリッシュ/サブスクライブ メカニズムに基づくミドルウェア ROS 2 システムの中心となるのは ROS グラフ ROS グラフとは、ROS システム内のノードのネットワークと、それらのノードが通信する接続を指す
Nodes	・ノードは ROS 2 グラフの参加者 ・クライアント ライブラリを使用して他のノードと通信 ・ノードは、同じプロセス内、別のプロセス内、または別のマシン上の他のノードと通信できる ・ノードは通常、ROS グラフの計算単位。各ノードは 1 つの論理的な処理を実行する必要がある
Discovery	ノードの検出は、ROS 2 の基盤となるミドルウェアを通じて自動的に行われる
Interface	ROS アプリケーションは通常、トピック、サービス、アクションの 3 つのタイプのいずれかのインターフェースを介して通信する ROS 2 では、これらのインターフェースを記述するために、簡略化された記述言語であるインターフェース定義言語 (IDL) を使用する
Topics	トピックは、ROS 2 が提供する 3 つの主要なインターフェース スタイルの 1 つ トピックは、センサー データ、ロボットの状態などの継続的なデータ ストリームに使用する必要がある
Services	サービスはリクエスト/レスポンス通信であり、クライアント (リクエスター) はサーバー (レスポンダー) が短い計算を行って結果を返すのを待つ
Actions	アクションは長時間実行される要求/応答通信であり、アクション クライアント (要求側) はアクション サーバー (応答側) が何らかのアクションを実行して結果を返すのを待機する サービスとは対照的に、アクションは長時間実行 (数秒または数分間) でき、実行中にフィードバックを提供したり、中断したりできる
Parameters	ROS 2 のパラメータは個々のノードに関連付けられる パラメーターは、コードを変更せずに、起動時 (および実行時) にノードを構成するために使用される パラメータの有効期間はノードの有効期間に関連付けられる (ただし、ノードは再起動後に値をリロードするためにある種の永続性を実装できる)
Launch	ROS 2 システムは通常、多くの異なるプロセス (さらには異なるマシン) にわたって実行される多くのノードで構成される これらのノードをそれぞれ個別に実行することも可能ですが、大変。 上記のすべては、Python、XML、または YAML で記述できる起動ファイルで指定され、この起動ファイルは、ros2 launch コマンドを使用して実行でき、指定されたすべてのノードが実行される
Client libraries	クライアント ライブラリは、ユーザーが ROS 2 コードを実装できるようにする API クライアント ライブラリを使用すると、ユーザーはノード、トピック、サービスなどの ROS 2 の概念にアクセスできる クライアント ライブラリはさまざまなプログラミング言語で提供されているため、ユーザーはアプリケーションに最適な言語で ROS 2 コードを記述できる

概要

ROS

下記を基に整理します。

The Robot Operating System (ROS) is a set of software libraries and tools for building robot applications. From drivers and state-of-the-art algorithms to powerful developer tools, ROS has the open source tools you need for your next robotics project.

• Robot Operating Systemの略
• ロボット アプリケーションを構築するためのソフトウェア ライブラリとツールのセット
• ドライバーや最先端の​​アルゴリズムから強力な開発者ツールまで、ROS には次のロボット プロジェクトに必要なオープン ソース ツールがある

Since ROS was started in 2007, a lot has changed in the robotics and ROS community. The goal of the ROS 2 project is to adapt to these changes, leveraging what is great about ROS 1 and improving what isn’t.

• ROS が 2007 年に開始されて以来、ロボットと ROS コミュニティには多くの変化があった
• ROS 2 プロジェクトの目標は、これらの変化に適応し、ROS 1 の優れた点を活用し、そうでない点を改善すること

Basic Concepts

ROS 2 is a middleware based on a strongly-typed, anonymous publish/subscribe mechanism that allows for message passing between different processes.

• ROS 2 は、異なるプロセス間でのメッセージ パッシングを可能にする、厳密に型指定された匿名のパブリッシュ/サブスクライブ メカニズムに基づくミドルウェア

At the heart of any ROS 2 system is the ROS graph. The ROS graph refers to the network of nodes in a ROS system and the connections between them by which they communicate.

• ROS 2 システムの中心となるのは ROS グラフ
• ROS グラフとは、ROS システム内のノードのネットワークと、それらのノードが通信する接続を指す

Nodes

A node is a participant in the ROS 2 graph, which uses a client library to communicate with other nodes. Nodes can communicate with other nodes within the same process, in a different process, or on a different machine. Nodes are typically the unit of computation in a ROS graph; each node should do one logical thing.

• ノードは ROS 2 グラフの参加者
• クライアント ライブラリを使用して他のノードと通信
• ノードは、同じプロセス内、別のプロセス内、または別のマシン上の他のノードと通信できる
• ノードは通常、ROS グラフの計算単位。各ノードは 1 つの論理的な処理を実行する必要がある

Nodes can publish to named topics to deliver data to other nodes, or subscribe to named topics to get data from other nodes. They can also act as a service client to have another node perform a computation on their behalf, or as a service server to provide functionality to other nodes. For long-running computations, a node can act as an action client to have another node perform it on their behalf, or as an action server to provide functionality to other nodes. Nodes can provide configurable parameters to change behavior during run-time.

• ノードは、名前付きトピックにパブリッシュして他のノードにデータを配信したり、名前付きトピックにサブスクライブして他のノードからデータを取得したりできる
• 別のノードに代わって計算を実行させるサービス クライアントとして機能したり、他のノードに機能を提供するサービス サーバーとして機能したりすることもできる
• 長時間実行される計算の場合、ノードはアクション クライアントとして機能して別のノードに代わって計算を実行させたり、アクション サーバーとして機能して他のノードに機能を提供したりできる
• ノードは、実行時に動作を変更するための構成可能なパラメーターを提供できる

Nodes are often a complex combination of publishers, subscribers, service servers, service clients, action servers, and action clients, all at the same time.

• ノードは、多くの場合、パブリッシャー、サブスクライバー、サービス サーバー、サービス クライアント、アクション サーバー、およびアクション クライアントの複雑な組み合わせであり、すべて同時に存在する

Connections between nodes are established through a distributed discovery process.

• ノード間の接続は、分散検出プロセスを通じて確立される

Discovery

Discovery of nodes happens automatically through the underlying middleware of ROS 2. It can be summarized as follows:

• ノードの検出は、ROS 2 の基盤となるミドルウェアを通じて自動的に行われる

1. When a node is started, it advertises its presence to other nodes on the network with the same ROS domain (set with the ROS_DOMAIN_ID environment variable). Nodes respond to this advertisement with information about themselves so that the appropriate connections can be made and the nodes can communicate.
2. Nodes periodically advertise their presence so that connections can be made with new-found entities, even after the initial discovery period.
3. Nodes advertise to other nodes when they go offline.

1. ノードが起動すると、同じ ROS ドメイン (ROS_DOMAIN_ID 環境変数で設定) を持つネットワーク上の他のノードにその存在を通知する。ノードは、適切な接続を確立してノードが通信できるように、自分自身に関する情報でこの通知に応答する
2. ノードは、最初の検出期間が経過した後でも、新しく見つかったエンティティとの接続を確立できるように、定期的にその存在を通知する
3. ノードは、オフラインになったときに他のノードに通知する

Nodes will only establish connections with other nodes if they have compatible Quality of Service settings.

• ノードは、互換性のある Quality of Service 設定がある場合にのみ、他のノードとの接続を確立する

Take the talker-listener demo for example. Running the C++ talker node in one terminal will publish messages on a topic, and the Python listener node running in another terminal will subscribe to messages on the same topic.

• トーカー リスナー デモを例に挙げる。
  • 1 つのターミナルで C++ talkerノードを実行すると、トピックに関するメッセージが公開され、別のターミナルで実行されている Python リスナーノードは同じトピックに関するメッセージをサブスクライブする

You should see that these nodes discover each other automatically, and begin to exchange messages.

• これらのノードが自動的に互いを検出し、メッセージの交換を開始することがわかる

Interfaces

Background

ROS applications typically communicate through interfaces of one of three types: topics, services, or actions. ROS 2 uses a simplified description language, the interface definition language (IDL), to describe these interfaces. This description makes it easy for ROS tools to automatically generate source code for the interface type in several target languages.

• ROS アプリケーションは通常、トピック、サービス、アクションの 3 つのタイプのいずれかのインターフェースを介して通信する
• ROS 2 では、これらのインターフェースを記述するために、簡略化された記述言語であるインターフェース定義言語 (IDL) を使用する
• この記述により、ROS ツールは、複数のターゲット言語でインターフェース タイプのソース コードを自動的に生成することが容易になる

In this document we will describe the supported types:

• msg: .msg files are simple text files that describe the fields of a ROS message. They are used to generate source code for messages in different languages.
• srv: .srv files describe a service. They are composed of two parts: a request and a response. The request and response are message declarations.
• action: .action files describe actions. They are composed of three parts: a goal, a result, and feedback. Each part is a message declaration itself.

• msg
  • .msg ファイルは、ROS メッセージのフィールドを記述する単純なテキスト ファイル
  • さまざまな言語でメッセージのソース コードを生成するために使用される
• srv
  • .srv ファイルは、サービスを記述する
  • リクエストとレスポンスの 2 つの部分で構成される
  • リクエストとレスポンスは、メッセージ宣言
• action
  • .action ファイルは、アクションを記述する
  • ゴール、結果、フィードバックの 3 つの部分で構成される
  • 各部分は、メッセージ宣言そのもの

Messages

Messages are a way for a ROS 2 node to send data on the network to other ROS nodes, with no response expected. For instance, if a ROS 2 node reads temperature data from a sensor, it can then publish that data on the ROS 2 network using a Temperature message. Other nodes on the ROS 2 network can subscribe to that data and receive the Temperature message.

• メッセージは、ROS 2 ノードがネットワーク上の他の ROS ノードにデータを送信する手段であり、応答は期待されない
• たとえば、ROS 2 ノードがセンサーから温度データを読み取ると、温度メッセージを使用してそのデータを ROS 2 ネットワークに公開できる
• ROS 2 ネットワーク上の他のノードはそのデータをサブスクライブし、温度メッセージを受信できる

Messages are described and defined in .msg files in the msg/ directory of a ROS package. .msg files are composed of two parts: fields and constants.

• メッセージは、ROS パッケージの msg/ ディレクトリにある .msg ファイルで記述および定義される
• .msg ファイルは、フィールドと定数の 2 つの部分で構成される

Fields

Each field consists of a type and a name, separated by a space, i.e:

• 各フィールドは、スペースで区切られたタイプと名前で構成される
• 書式

  fieldtype1 fieldname1
  fieldtype2 fieldname2
  fieldtype3 fieldname3
  

• 例

  int32 my_int
  string my_string
  

Field types

Example of message definition using arrays and bounded types:

• 配列と境界型を使用したメッセージ定義の例:

  int32[] unbounded_integer_array
  int32[5] five_integers_array
  int32[<=5] up_to_five_integers_array
  
  string string_of_unbounded_size
  string<=10 up_to_ten_characters_string
  
  string[<=5] up_to_five_unbounded_strings
  string<=10[] unbounded_array_of_strings_up_to_ten_characters_each
  string<=10[<=5] up_to_five_strings_up_to_ten_characters_each
  

Field names

Field names must be lowercase alphanumeric characters with underscores for separating words. They must start with an alphabetic character, and they must not end with an underscore or have two consecutive underscores.

• フィールド名は、単語を区切るためのアンダースコアを含む小文字の英数字である
• フィールド名はアルファベット文字で始まる必要があり、アンダースコアで終わることや、連続した 2 つのアンダースコアを使用することはできない

Field default value

Default values can be set to any field in the message type. Currently default values are not supported for string arrays and complex types (i.e. types not present in the built-in-types table above; that applies to all nested messages).

• デフォルト値は、メッセージ タイプの任意のフィールドに設定できる
• 現在、デフォルト値は文字列配列と複合型 (つまり、上記の組み込み型テーブルに存在しない型。これはすべてのネストされたメッセージに適用されます) ではサポートされていない

Defining a default value is done by adding a third element to the field definition line, i.e:

• デフォルト値を定義するには、フィールド定義行に 3 番目の要素を追加する

  fieldtype fieldname fielddefaultvalue
  

• 例

  uint8 x 42
  int16 y -2000
  string full_name "John Doe"
  int32[] samples [-200, -100, 0, 100, 200]
  

Constants

Each constant definition is like a field description with a default value, except that this value can never be changed programatically. This value assignment is indicated by use of an equal ‘=’ sign, e.g.

• 各定数定義はデフォルト値を持つフィールド記述に似ているが、この値はプログラムで変更できない
• この値の割り当ては等号「=」を使用して示される
• 書式

  constanttype CONSTANTNAME=constantvalue
  

• 例

  int32 X=123
  int32 Y=-123
  string FOO="foo"
  string EXAMPLE='bar'
  

Topics

Topics are one of the three primary styles of interfaces provided by ROS 2. Topics should be used for continuous data streams, like sensor data, robot state, etc.

• トピックは、ROS 2 が提供する 3 つの主要なインターフェース スタイルの 1 つ
• トピックは、センサー データ、ロボットの状態などの継続的なデータ ストリームに使用する必要がある

As stated earlier, ROS 2 is a strongly-typed, anonymous publish/subscribe system. Let’s break down that sentence and explain it a bit more.

• 前述のように、ROS 2 は厳密に型指定された匿名のパブリッシュ/サブスクライブ システム

Publish/Subscribe

A publish/subscribe system is one in which there are producers of data (publishers) and consumers of data (subscribers). The publishers and subscribers know how to contact each other through the concept of a “topic”, which is a common name so that the entites can find each other. For instance, when you create a publisher, you must also give it a string that is the name of the topic; the same goes for the subscriber. Any publishers and subscribers that are on the same topic name can directly communicate with each other. There may be zero or more publishers and zero or more subscribers on any particular topic. When data is published to the topic by any of the publishers, all subscribers in the system will receive the data. This system is also known as a “bus”, since it somewhat resembles a device bus from electrical engineering. This concept of a bus is part of what makes ROS 2 a powerful and flexible system. Publishers and subscribers can come and go as needed, meaning that debugging and introspection are natural extensions to the system. For instance, if you want to record data, you can use the ros2 bag record command. Under the hood, ros2 bag record creates a new subscriber to whatever topic you tell it, without interrupting the flow of data to the other parts of the system.

• パブリッシュ/サブスクライブ システムとは、データのプロデューサー (パブリッシャー) とデータのコンシューマー (サブスクライバー) が存在するシステム
• パブリッシャーとサブスクライバーは、エンティティがお互いを見つけられるようにするための共通名である「トピック」の概念を通じて相互に連絡する方法を知っている
• 同じトピック名にあるパブリッシャーとサブスクライバーは、相互に直接通信できる
• 特定のトピックには、0 個以上の発行者と 0 個以上の購読者が存在する場合がある
  • いずれかのパブリッシャーによってデータがトピックにパブリッシュされると、システム内のすべてのサブスクライバーがデータを受信する
• たとえば、データを記録する場合は、ros2 bag record コマンドを使用できる
  • 内部的には、ros2 bag record は、システムの他の部分へのデータの流れを中断することなく、指定したトピックに新しいサブスクライバーを作成する

Anonymous

Another fact mentioned in the introduction is that ROS 2 is “anonymous”. This means that when a subscriber gets a piece of data, it doesn’t generally know or care which publisher originally sent it (though it can find out if it wants). The benefit to this architecture is that publishers and subscribers can be swapped out at will without affecting the rest of the system.

• ROS 2 は「匿名」
  • サブスクライバーがデータを取得するとき、通常、最初にどのパブリッシャーがデータを送信したかを知らない。そして気にもしないことを意味する (ただし、知りたければ知ることはできる）
• このアーキテクチャの利点は、システムの残りの部分に影響を与えることなく、パブリッシャーとサブスクライバーを自由に交換できること

Strongly-typed

Finally, the introduction also mentioned that the publish/subscribe system is “strongly-typed”. That has two meanings in this context:

1. The types of each field in a ROS message are typed, and that type is enforced at various levels. For instance, if the ROS message contains:

• ROS メッセージの各フィールドのタイプは型指定されており、そのタイプはさまざまなレベルで適用される

uint32 field1
string field2

Then the code will ensure that field1 is always an unsigned integer and that field2 is always a string.

• コードは、field1 が常に符号なし整数であり、field2 が常に文字列であることを保証する

2.The semantics of each field are well-defined. There is no automated mechanism to ensure this, but all of the core ROS types have strong semantics associated with them. For instance, the IMU message contains a 3-dimensional vector for the measured angular velocity, and each of the dimensions is specified to be in radians/second. Other interpretations should not be placed into the message.

• 各フィールドのセマンティクスは明確に定義されている
• これを保証する自動メカニズムはないが、すべてのコア ROS タイプには強力なセマンティクスが関連付けられている
• 例）IMU メッセージには測定された角速度の 3 次元ベクトルが含まれており、各次元はラジアン/秒で指定されている。他の解釈をメッセージに含めるべきではない

Services

Services are a request/response communication, where the client (requester) is waiting for the server (responder) to make a short computation and return a result.

• サービスはリクエスト/レスポンス通信であり、クライアント (リクエスター) はサーバー (レスポンダー) が短い計算を行って結果を返すのを待つ

Services are described and defined in .srv files in the srv/ directory of a ROS package.

• サービスは、ROS パッケージの srv/ ディレクトリにある .srv ファイルで記述および定義される

A service description file consists of a request and a response msg type, separated by ---. Any two .msg files concatenated with a --- are a legal service description.

• サービス記述ファイルは、--- で区切られたリクエストとレスポンスのメッセージ タイプで構成される
• --- で連結された 2 つの .msg ファイルは、有効なサービス記述
• 書式

  string str
  ---
  string str
  

• 複雑に定義できる

  # request constants
  int8 FOO=1
  int8 BAR=2
  # request fields
  int8 foobar
  another_pkg/AnotherMessage msg
  ---
  # response constants
  uint32 SECRET=123456
  # response fields
  another_pkg/YetAnotherMessage val
  CustomMessageDefinedInThisPackage value
  uint32 an_integer    
  

Actions

In ROS 2, an action refers to a long-running remote procedure call with feedback and the ability to cancel or preempt the goal. For instance, the high-level state machine running a robot may call an action to tell the navigation subsystem to travel to a waypoint, which may take several seconds (or minutes) to do. Along the way, the navigation subsystem can provide feedback on how far along it is, and the high-level state machine has the option to cancel or preempt the travel to that waypoint.

• アクションは長時間実行される要求/応答通信であり、アクション クライアント (要求側) はアクション サーバー (応答側) が何らかのアクションを実行して結果を返すのを待機する
• サービスとは対照的に、アクションは長時間実行 (数秒または数分間) でき、実行中にフィードバックを提供したり、中断したりできる
• 例

  int32 order
  ---
  int32[] sequence
  ---
  int32[] sequence
  

In ROS 2, actions are expected to be long running procedures, as there is overhead in setting up and monitoring the connection. If you need a short running remote procedure call, consider using a service instead.

Actions are identified by an action name, which looks much like a topic name (but is in a different namespace).
An action consists of two parts: the action server and the action client.

• ROS 2 では、接続の設定と監視にオーバーヘッドがあるため、アクションは長時間実行されるプロシージャになることが予想される
• 短時間のリモート プロシージャ コールを実行する必要がある場合は、代わりにサービスの使用を検討する
• アクションはアクション名によって識別される
• アクションは、アクション サーバーとアクション クライアントの 2 つの部分で構成される

Action server

The action server is the entity that will accept the remote procedure request and perform some procedure on it. It is also responsible for sending out feedback as the action progresses and should react to cancellation/preemption requests. For instance, consider an action to calculate the Fibonacci sequence with the following interface:

• アクション サーバーは、リモート プロシージャ リクエストを受け入れ、それに対して何らかのプロシージャを実行するエンティティ
• アクションの進行に応じてフィードバックを送信する責任もあり、キャンセル/プリエンプション要求に反応する必要がある
• たとえば、次のインターフェイスを使用してフィボナッチ数列を計算するアクションを考える

int32 order
---
int32[] sequence
---
int32[] sequence

The action server is the entity that receives this message, starts calculating the sequence up to order (providing feedback along the way), and finally returns a full result in sequence.

• アクション サーバーは、このメッセージを受信するエンティティであり、順序に至るまでシーケンスの計算を開始し (途中でフィードバックを提供)、最終的にシーケンス内の完全な結果を返す

There should only ever be one action server per action name. It is undefined which action server will receive client requests in the case of multiple action servers on the same action name.

• アクション サーバーは、アクション名ごとに 1 つだけ存在する必要がある
• 同じアクション名に複数のアクション サーバーがある場合、どのアクション サーバーがクライアント リクエストを受信するかは未定義

Action client

An action client is an entity that will request a remote action server to perform a procedure on its behalf. Following the example above, the action client is the entity that creates the initial message containing the order, and waits for the action server to compute the sequence and return it (with feedback along the way).

• アクション クライアントは、リモート アクション サーバーに代わって手順を実行するように要求するエンティティ
• 上記の例に従うと、アクション クライアントは、注文を含む最初のメッセージを作成するエンティティであり、アクション サーバーがシーケンスを計算してそれを返すのを待つ (途中でフィードバックが含まれる)

Unlike the action server, there can be arbitrary numbers of action clients using the same action name.

• アクション サーバーとは異なり、同じアクション名を使用する任意の数のアクション クライアントが存在できる

Parameters

Overview

Parameters in ROS 2 are associated with individual nodes. Parameters are used to configure nodes at startup (and during runtime), without changing the code. The lifetime of a parameter is tied to the lifetime of the node (though the node could implement some sort of persistence to reload values after restart).

• ROS 2 のパラメータは個々のノードに関連付けられる
• パラメーターは、コードを変更せずに、起動時 (および実行時) にノードを構成するために使用される
• パラメータの有効期間はノードの有効期間に関連付けられる (ただし、ノードは再起動後に値をリロードするためにある種の永続性を実装できる)

Parameters are addressed by node name, node namespace, parameter name, and parameter namespace. Providing a parameter namespace is optional.

• パラメータは下記により指定される
  • ノード名
  • ノード名前空間
  • パラメータ名
  • パラメータ名前空間(オプション)

Each parameter consists of a key, a value, and a descriptor. The key is a string and the value is one of the following types: bool, int64, float64, string, byte[], bool[], int64[], float64[] or string[]. By default all descriptors are empty, but can contain parameter descriptions, value ranges, type information, and additional constraints.

• 各パラメータは、キー、値、および記述子で構成される
• キーは文字列で、値は下記のいずれかの型になる
  • bool
  • int64
  • float64
  • string
  • byte[]
  • bool[]
  • int64[]
  • float64[]
  • string[]
• デフォルトではすべての記述子は空
• パラメータの説明、値の範囲、型情報、および追加の制約を含めることが可能

Introspection with command line tools

ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system.

• ROS 2 には、ROS 2 システムをイントロスペクトするための一連のコマンドライン ツールが含まれている

Launch

A ROS 2 system typically consists of many nodes running across many different processes (and even different machines). While it is possible to run each of these nodes separately, it gets cumbersome quite quickly.

• ROS 2 システムは通常、多くの異なるプロセス (さらには異なるマシン) にわたって実行される多くのノードで構成される
• これらのノードをそれぞれ個別に実行することも可能ですが、すぐに面倒になる

The launch system in ROS 2 is meant to automate the running of many nodes with a single command. It helps the user describe the configuration of their system and then executes it as described. The configuration of the system includes what programs to run, where to run them, what arguments to pass them, and ROS-specific conventions which make it easy to reuse components throughout the system by giving them each a different configuration. It is also responsible for monitoring the state of the processes launched, and reporting and/or reacting to changes in the state of those processes.

• ROS 2 の起動システムは、単一のコマンドで多数のノードの実行を自動化することを目的としている。これは、ユーザーがシステムの構成を説明し、説明どおりに実行するのに役立つ
• システムの構成には、どのプログラムを実行するか、どこで実行するか、どのような引数を渡すか、および各コンポーネントに異なる構成を与えることでシステム全体でコンポーネントを簡単に再利用できるようにする ROS 固有の規則が含まれる
• 起動されたプロセスの状態を監視し、それらのプロセスの状態の変化を報告したり、それに対応したりする責任もある

All of the above is specified in a launch file, which can be written in Python, XML, or YAML. This launch file can then be run using the ros2 launch command, and all of the nodes specified will be run.

• 上記のすべては、Python、XML、または YAML で記述できる起動ファイルで指定される
• この起動ファイルは、ros2 launch コマンドを使用して実行でき、指定されたすべてのノードが実行される

Client libraries

Overview

Client libraries are the APIs that allow users to implement their ROS 2 code. Using client libraries, users gain access to ROS 2 concepts such as nodes, topics, services, etc. Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their application. For example, you might prefer to write visualization tools in Python because it makes prototyping iterations faster, while for parts of your system that are concerned with efficiency, the nodes might be better implemented in C++.

• クライアント ライブラリは、ユーザーが ROS 2 コードを実装できるようにする API
• クライアント ライブラリを使用すると、ユーザーはノード、トピック、サービスなどの ROS 2 の概念にアクセスできる
• クライアント ライブラリはさまざまなプログラミング言語で提供されているため、ユーザーはアプリケーションに最適な言語で ROS 2 コードを記述できる
• たとえば、視覚化ツールはプロトタイプの反復を高速化するために Python で記述する方がよい場合があるが、システムの効率が重要な部分では、ノードを C++ で実装する方がよい場合がある

Nodes written using different client libraries are able to share messages with each other because all client libraries implement code generators that provide users with the capability to interact with ROS 2 interface files in the respective language.

• すべてのクライアント ライブラリは、それぞれの言語で ROS 2 インターフェイス ファイルと対話する機能をユーザーに提供するコード ジェネレーターを実装している
• そのため、異なるクライアント ライブラリを使用して記述されたノードは相互にメッセージを共有できる

In addition to the language-specific communication tools, client libraries expose to users the core functionality that makes ROS “ROS”. For example, here is a list of functionality that can typically be accessed through a client library:

• Names and namespaces
• Time (real or simulated)
• Parameters
• Console logging
• Threading model
• Intra-process communication

• クライアント ライブラリは、言語固有のコミュニケーション ツールに加えて、ROS を「ROS」たらしめるコア機能をユーザーに公開します
• たとえば、通常クライアント ライブラリを通じてアクセスできる機能
  • Names and namespaces
  • Time (real or simulated)
  • Parameters
  • Console logging
  • Threading model
  • Intra-process communication

考察

今回、ROS2のBasic Conceptについて整理してみました。現時点ではリアリティがありませんが
今後もインプットとハンズオンを継続して実施していきたいと思います。

参考