MoriKen's Journal

MoriKen's Journal

アラサー社会人博士による徒然日記。技術についてつらつら。だけだとコンテンツが貧弱なので、会社公認で大学院博士課程に進学した経緯や、独学でTOEICを475→910にしたノウハウを共有します。

【ROS 2】クライアントライブラリについて

ROS 2

ROS 2 公式文書（英語） 日本語訳シリーズです。

本ブログの日本語翻訳版のトップページは以下のリンクを参照下さい。

www.moriken254.com

※2019/05/06 現在のものです。

概要

クライアントライブラリは、ユーザーが自分のROSコードを実装できるようにする API です。例えば、ノード、トピック、サービスなどの ROS のコンセプトにアクセスするためにユーザーが使用するものです。

ユーザー独自のアプリケーションに最適な言語で ROS コードを書くことができるように、クライアントライブラリには様々なプログラミング言語が用意されています。例として、視覚化ツールを Python で作成する方がよい場合があります。これは、プロトタイプ作成のイテレーションが高速になるためです。

一方、システムの効率性に関係する部分では、ノードは C++ 実装された方が 良いパフォーマンスを発揮します。

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

言語固有のコミュニケーションツールに加えて、クライアントライブラリは ROS のコア機能をユーザーに公開します。例えば、これは通常クライアントライブラリからアクセスできる機能のリストです。

  • 名前と名前空間
  • 時間（実機またはシミュレーション）
  • パラメータ
  • コンソールロギング
  • スレッドモデル
  • プロセス内通信

サポートされているクライアントライブラリ

C++ クライアントライブラリ（rclcpp）と Python クライアントライブラリ（rclpy）はどちらも RCL の共通機能を利用するクライアントライブラリです。

C++ と Python のクライアントライブラリは ROS 2 のコアチームによって管理されていますが、ROS 2 コミュニティのメンバーは追加のクライアントライブラリも作成しました。

共通の機能：RCL

クライアントライブラリにある機能のほとんどは、クライアントライブラリのプログラミング言語に依存するものではありません。例えば、パラメータの振る舞いと名前空間のロジックは理想的にはすべてのプログラミング言語で同じであるべきです。

このため、共通の機能を最初から実装するのではなく、クライアントライブラリは、言語固有ではない ROS コンセプトのロジックと動作を実装する共通のコア ROS クライアントライブラリ（RCL）I/F を使用します。その結果、クライアントライブラリは RCL の共通機能を外部関数インタフェースでラップするだけで済みます。

f:id:MoriKen254:20190506214405p:plain

これにより、クライアントライブラリは小規模で済み、開発が容易になります。このため、C 言語は一般にクライアントライブラリがラップするのが最も簡単な言語であるため、一般的なRCL 機能は C 言語の I/F で公開されています。

クライアントライブラリを軽量にすることに加えて、共通のコアを持つ利点は、言語間の動作がより一貫しているということです。たとえば、名前空間など、コア RCL の機能のロジックや動作に変更が加えられた場合、RCL を使用するすべてのクライアントライブラリにこれらの変更が反映されます。

さらに、共通のコアを持つということは、バグ修正に関して複数のクライアントライブラリを維持する負荷も軽減できます。

RCL の API ドキュメントはこちらにあります。

言語固有の機能

言語固有の機能/プロパティを必要とするクライアントライブラリの概念は RCL には実装されていませんが、代わりに各クライアントライブラリで個別に実装されています。たとえば、「spin」関数で使用されるスレッドモデルには、クライアントライブラリの言語に固有の実装があります。

デモ

rclpy を使用しているパブリッシャとrclcpp を使用しているサブスクライバとの間のメッセージ交換について理解を深めたければ、こちらの ROSCon プレゼン（17:25 から）を見ることを勧めます（ここにスライドがあります）。

ROS 1 との比較

ROS 1 では、すべてのクライアントライブラリは「ゼロから」開発されています。これにより、例えば ROS 1 Python クライアントライブラリを純粋に Python で実装できるようになり、コードをコンパイルする必要がないなどの利点がありました。

しかし、命名規則と振る舞いはクライアントライブラリ間で常に一貫しているわけではなく、バグ修正は複数の場所で行わなければなりませんでした。しかも、特定の1つのクライアントライブラリ（UDPROS など）にしか実装されていない機能もたくさんあります。

まとめ

ROS 2 では、共通のコア ROS クライアントライブラリを利用することを述べました。 これにより、種々のプログラミング言語で書かれたクライアントライブラリは、書くのがより簡単になり、挙動の一貫性も担保されるようになりました。

翻訳元文書

index.ros.org

関連記事

www.moriken254.com

www.moriken254.com

www.moriken254.com

【ROS 2】インターフェースについて（公式文書和訳）

ROS 2

ROS 2 公式文書（英語） 日本語訳シリーズです。

本ブログの日本語翻訳版のトップページは以下のリンクを参照下さい。

www.moriken254.com

※2019/05/06 現在のものです。

※以降、インターフェースを I/F と表記します。

1. 背景

ROS アプリケーションは通常、メッセージとサービスの2つのタイプのうちの1つの I/F を介して通信します。 ROS はこれらの I/F を記述するための記述言語を使います。これにより、異なる開発言語でも利用できる I/F 型のソースコードを自動的に生成することができます。

この文書ではサポートされている型の紹介と msg / srvファイルの作り方を説明します。

2. メッセージ記述仕様

メッセージの説明はROSパッケージの msg/ ディレクトリの .msg ファイルに定義されています。.msgファイルは、フィールドと定数の2つの部分で構成されています。

2.1 フィールド

各フィールドは、スペースで区切られたタイプと名前で構成されています。

fieldtype1 fieldname1
fieldtype2 fieldname2
fieldtype3 fieldname3

例：

int32 my_int
string my_string
2.1.1フィールド型

フィールド型は次のとおりです。

  • ビルトイン型
  • “ geometry_msgs / PoseStamped” のように独自に定義されたメッセージ
現在サポートされているビルトイン型
型名 C++ Python DDS における型
bool bool builtins.bool boolean
byte uinit8_t buitins.bytes* octet
char char builtins.str* char
float32 float buitlins.float* float
float64 double builtins.float* double
int8 int8_t builtins.int* octet
uint8 uint8_t builtins.int* short
uint16 uint16_t builtins.int* unsigned short
int32 int32_t builtins.int* long
uint32 uint32_t builtins.int* unsigned long
int64 int64_t builtins.int* long long
uint64 uint64_t builtins.int* unsigned long long
string str::string builtins.str string

各ビルトイン型は配列としても使用できます。

型名 C++ Python DDS における型
static array std::array<T,N> builtin.list* T[N]
unbounded
dynamic array 		std::vector builtin.list* sequence
bounded
dynamic array 		custom_class<T,N> builtin.list* sequence<T,N>
bounded string std::string builtin.str* string

ROS 定義よりも許容度の高い型については、変数範囲や文字列長を強制的に ROS の制約側に合わせるよう調整されます。

配列とサイズ固定型を使ったメッセージ定義の例：

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_string_up_to_ten_characters each
string<=10[<=5] up_to_five_strings_up_to_ten_characters_each
2.1.2 フィールド名

フィールド名は、単語を区切るためのアンダースコアを含む小文字の英数字でなければなりません。開始文字は英字でなければなく、かつアンダースコアで終わってはいけません。アンダースコアを2つ連続で使用してもいけません。

2.1.3フィールドデフォルト値

デフォルト値は、メッセージタイプの任意のフィールドに設定できます。現在のデフォルト値は、文字列配列と複雑な型（つまり、全てのネストされたメッセージに適用される上記のビルトイン型のテーブルに存在しない型）ではサポートされていません。

フィールド定義行に3番目の要素を追加することによって、デフォルト値を設定できます。

書式：

fieldtype fieldname fielddefaultvalue

例：

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

注意：

  • 文字列値は、'または"で定義する必要があります。
  • 現在、文字列値はエスケープされません

2.2 定数

各定数定義は、デフォルト値を持つフィールドの仕様と似てはいますが、この値はプログラムで変更することはできません。この値の割り当ては、等号「=」を使用して示されます。

書式：

constanttype CONSTANTNAME=constantvalue

例：

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

注意

定数名は大文字にする必要があります。

3. サービス記述仕様

サービスの記述は、ROSパッケージのsrv/ディレクトリ内の.srvファイル内に定義されています。

サービス記述ファイルは、リクエストとレスポンスの msg タイプを「-」で区切って構成されています。 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

他のサービスをサービスの中に埋め込むことはできません。

翻訳元文書

index.ros.org

関連記事

www.moriken254.com

www.moriken254.com

www.moriken254.com

【ROS 2】QoS 設定について（公式文書和訳）

ROS 2

ROS 2 公式文書（英語） 日本語訳シリーズです。

本ブログの日本語翻訳版のトップページは以下のリンクを参照下さい。

www.moriken254.com

※2019/05/06 現在のものです。

概要

ROS 2 は、ノード間の通信を調整することを可能にする多種多様なサービス品質（QoS）ポリシーを提供します。適切な一連の QoS ポリシーを使用すると、ROS 2 は TCP と同等の信頼性があり、かつ UDP と同程度のベストエフォートが期待できます。

主にTCPのみをサポートする ROS 1 とは異なり、ROS 2 では以下のような状況で、基盤となるDDS転送の柔軟性が発揮されます。

  • 「Best effort」ポリシー（後述）がより適しているような損失の多いワイヤレスネットワーク環境
  • QoS の期限を厳格に守らなければならないような、適切な品質が要求されるリアルタイムコンピューティングシステム（この場合「Reliable」ポリシーが適している。後述。）

QoS「ポリシー」のセットを統合し、QoS「プロファイル」を形成します。ただし、所与のシナリオに対して正しい QoS ポリシーを選択することは容易ではないので、ROS 2 では一般的なユースケース（例：センサデータ）のための所定の QoS プロファイルを一つ提供しています。もちろん、QoS ポリシーの特定のプロファイルをユーザ側で制御することも可能です。

QoS プロファイルは、パブリッシャ、サブスクライバ、サービスサーバ、およびクライアントに対して指定できます。 QoS プロファイルは、前述の実体（ノード）の各インスタンスに個別に適用できますが、異なるプロファイルが使用されていると、接続できない可能性があります。

QoS ポリシー

基本 QoS プロファイルには現在、次のポリシーの設定が含まれています。

History (履歴)

  • keep last：最大 N サンプルまで保存します。N はキューの Depth オプションで設定可能です。
  • keep all：すべてのサンプルを保持します。上限は、基盤ドルウェアの構成済みリソース制限に従います。

Depth (深さ)

  • Size of the queue："keep last" と一緒に使用した場合にのみ有効です。

Reliability (信頼性)

  • Best Effort：サンプルの配信を試みますが、ネットワークが堅牢でないとサンプルを失う可能性があります。
  • Reliable：サンプルが配達されることを保証します。場合のよっては複数回再試行します。

Durability (耐久性)

  • Transient local：パブリッシャは「遅れて参加する」サブスクライバのサンプルを待ちます。
  • Volatile：上記のようなサンプルを待ちません。

各ポリシーには、"system default" というオプションもあります。これは、DDS ベンダーツール（XML 設定ファイルなど）を介して定義される、基礎ミドルウェアのデフォルト値を使用します。 DDS 自体には、設定可能な幅広いポリシーがあります。これらのポリシーは ROS 1 の機能と類似しているため公開されています。将来、ROS 2 ではより多くのポリシーが公開される可能性があります。

ROS 1 との比較

ROS 2 の History ポリシーと Depth ポリシーを組み合わせることで、ROS 1 のキューサイズに似た機能が提供されます。

ROS 2 の Reliability ポリシーは、"best effort" の場合はUDPROS（roscppのみ）、"reliable" の場合はTCPROS（ROS 1のデフォルト）といったイメージです。ただし、ROS 2 の "reliable" ポリシーも UDP を使用して実装されているため、必要に応じてマルチキャストが可能になります。

例えば、Depth を1とし、 Durability ポリシーを有効とすれば、「ラッチ」と同様の挙動をします。

QoS プロファイル

プロファイルを使用すると、QoS 設定を一切気にせずにアプリケーション開発に集中することができます。 QoS プロファイルでは、特定のユースケースでうまく動作することが期待できる一連のポリシーが定義されています。

現在定義されている QoS プロファイルは次のとおりです。

パブリッシャとサブスクライバのデフォルトの QoS 設定

ROS 1からROS 2に移行するには、同様のネットワーク動作で実行することが望ましいです。ROS 2 のデフォルトでは、パブリッシャとサブスクライバのオプションは Reliability を "reliable"に、Durability を "volatile" に、History を "keep last" にしています。

サービス

パブリッシャやサブスクライバと同じように、サービスの Reliability は "reliable" です。また、再起動したサービスサーバーが期限切れの要求を受け取る可能性があるため、サービスの Durability を "volatile" に設定することは特に重要です。

クライアントは複数の応答を受信することはありませんが、サーバーは期限切れの要求を受信するというリスクがあるためです。

センサーデータ

センサーデータの場合、ほとんどの場合、それらすべてを確実に受信するのではなく、適切なタイミングで測定値を受信することが重要です。つまり、開発者はどこかで欠落が生じてしまうリスクを許容しつつ、キャプチャされたらすぐに最新のサンプルを入手する必要があります。そのため、センサーデータプロファイルについては、Reliability を "best effort" に、Depth の "Size of queue" を小さくしてあります。

パラメーター

ROS 2 のパラメータはサービスに基づいているため、サービスと同様のプロファイルを持っていますが、違いがあります。

たとえば、パラメータクライアントがパラメータサービスサーバにアクセスできない場合に、要求が失われないように、パラメータがはるかに大きいキュー項目数を使用することです。（サービスでは逆で、時間切れの要求を破棄している。）

システムのデフォルト

全てのポリシーにおいて、システムデフォルト設定が適用されます。

上記のプロファイルで使用されている特定のポリシーについては、ここをクリックしてください。これらのプロファイルの設定は、コミュニティからのフィードバックに基づいて、さらに調整される可能性があります。

ROS 2 は一般的なユースケースに対していくつかの QoS プロファイルを提供しております。DDS で定義されているポリシーを使用することで、ROS ユーザーは特定のユースケースに対して QoS プロファイルを構成することもできます。そのポリシーは既存の DDS 資料に基づく膨大な知識をベースとしており、この恩恵に預かることができます。

QoSの互換性

注：このセクションではパブリッシャとサブスクライバについて説明しますが、その内容はサービスサーバ・クライアントについても同様に適用されます。

QoS プロファイルは、パブリッシャとサブスクライバに対して個別に設定できます。パブリッシャとサブスクライバ間の接続はペアが互換性のある QoS プロファイルを持っている場合にだけ行われます。

QoS プロファイルの互換性は、「要求 vs 提供者」モデルに基づいて決定されます。要求者側の要求するポリシーが、提供者のポリシーよりも厳しくない場合にのみ接続が行われます。両者のうち、厳しくない方のポリシーが接続で適用されます。

ROS 2 で公開されている QoS ポリシーのうち、互換性に影響を与えるものは、Durability と Reliability のポリシーです。次の表は、さまざまなポリシー設定とその結果の互換性を示しています。

QoS Durabiity プロファイルの互換性：

パブリッシャ
Offerer側 		サブスクライバ
Request側 		接続 結果 備考
Volatile Volatile OK Volatile 両者同一
Volatile Transient
local 		NG 無し Request 側
が厳しい
Transient local Volatile OK Volatile Offerer 側
が厳しい
Transient
local 		Transient
local 		OK Transient local 両者同一

QoS Reliability プロファイルの互換性：

パブリッシャ
Offerer側 		サブスクライバ
Request側 		接続 結果 備考
Best effort Best effort OK Best effort 両者同一
Best effort Reliable NG 無し Request 側
が厳しい
Reliable Best effort OK Volatile Offerer 側
が厳しい
Reliable Reliable OK Transient local 両者同一

接続を確立するには、互換性に影響するすべてのポリシーに互換性がある必要があります。つまり、パブリッシャとサブスクライバのペアが互換性のある信頼性 QoS プロファイルを持っていても、互換性のない耐久性 QoS プロファイルを持っていると、接続は確立されず、その逆も同様です。

翻訳元文書

index.ros.org

関連記事

www.moriken254.com

www.moriken254.com

www.moriken254.com

【ROS 2】対応する様々な DDS/RTPS ベンダ

ROS 2

ROS 2 公式文書（英語） 日本語訳シリーズです。

本ブログの日本語翻訳版のトップページは以下のリンクを参照下さい。

www.moriken254.com

※2019/05/06 現在のものです。

概要

ROS 2 は DDS / RTPS の上にミドルウェアとして構築されており、ミドルウェアは検出、シリアル化、およびデータ転送を提供します。

DDS と ROS の関係

こちらの記事では、DDS 実装や DDS の RTPS ワイヤプロトコルの使用の動機について詳しく説明します。要約すると、DDS はROS システムに関連する機能を提供するエンドツーエンドのミドルウェアです。例えば、分散検出や（ROS 1 のような一元管理型ではない）、データ転送のためのさまざまな「QoS」オプションを管理する機能が挙げられます。

DDS とは

DDS 自体は業界標準で、RTI の実装である Connext や、 ADLink の実装である OpenSplice RTPS（別名 DDSI-RTPS。DDSがネットワーク上で通信するために使用するワイヤプロトコル。）など、さまざまなベンダーによって実装されています。また、完全な DDS API を満たすものではありませんが、eProsima の実装である Fast RTPS などは、ROS 2 で使用する上で十分な機能を備えています。

ROS 2 で複数の DDS 実装に対応するわけ

ROS 2 は複数の DDS / RTPS 実装をサポートしています。ベンダ/実装の選択に関しては、必ずしも「1サイズがすべてに収まる（ “one size fits all” という諺を引用。）」とは限らないためです。ミドルウェアの実装を選択する際に考慮するべき多くの要因があります（ライセンスのような事業面での考慮事項、プラットフォームの可用性のような技術的な考慮事項、または計算上の制約等）。

ベンダーは、多様なニーズを満たすべく、複数の DDS または RTPS 実装を提供することがあります。たとえば、RTI には、特にマイクロコントローラを対象としたものや、特別な安全性認定を必要とするアプリケーションを対象としたもの（現在、標準デスクトップ版のみサポート）のように、目的が異なる Connext 実装のバリエーションがいくつかあります。

RMW (ROS Middleware Interface) とは

ROS 2 で DDS / RTPS 実装を使用するには、DDS または RTPS 実装の API とツールを使用して抽象 ROS ミドルウェアインタフェースを実装する「ROS Middleware Interface」（別名 rmw インタフェースまたは単に rmw）パッケージを作成する必要があります。 DDSの実装をサポートするために RMW パッケージを実装して維持するのは大変な作業ですが、ROS 2 コードベースが特定の実装に結び付けられないようにするには、少なくとも2、3の実装をサポートすることが重要だと考えております。ユーザがプロジェクトのニーズに応じて実装を切り替えたいと考えることも考慮して。

サポートされている RMW 実装一覧表

Product name License RMW implementation Status
eProsima
Fast RTPS 		Apache 2 rmw_fastrtps_cpp フルサポート。
RMWのデフォルトはこれ。
バイナリリリースでパッケージ化されている。
RTI
Connext 		commercial,
research 		rmw_connext_cpp "フルサポート。
バイナリサポートあり。
ただし、Connext は別途インストールが必要。"
RTI Connext
(dynamic implementation) 		commercial,
research 		rmw_connext_dynamic_cpp サポート終了。
フルサポートは alpha8 まで。*
PrismTech
Opensplice 		"LGPL (only v6.4),
commercial" 		rmw_opensplice_cpp 部分的サポート。
バイナリサポートあり。
ただし、 OpenSplice 別途インストール必要。
OSRF
FreeRTPS 		Apache 2 - 部分的サポート。
開発終了。

「部分的なサポート」とは、rmw インタフェースに必要な1つ以上の機能が実装されていないことを意味します。

複数の RMW 実装の操作に関する実用的な情報については、「複数のRMW実装の操作」のチュートリアルを参照してください。

翻訳元文書

index.ros.org

関連記事

www.moriken254.com

www.moriken254.com

www.moriken254.com

【ROS 2】コンセプトの概要（公式文書和訳）

ROS 2

ROS 2 公式文書（英語） 日本語訳シリーズです。

本ブログの日本語翻訳版のトップページは以下のリンクを参照下さい。

www.moriken254.com

※2019/05/06 現在のものです。

ROS は、異なる ROS プロセス間のメッセージ受け渡しを可能にする、匿名パブリッシュ/サブスクライブ機構に基づくミドルウェアです。

ROS 2 システムの心臓部はROS グラフです。 ROS グラフは、ROS システム内のノードのネットワークとそれらが通信するノード間の接続状態を表します。

グラフ概念の概要

  • ノード：ノードとは、ROS を使用して他のノードと通信する実体です。
  • メッセージ：トピックをパブリッシュまたはサブスクライブするときに使用されるROSデータ型。
  • トピック：ノードはトピックにメッセージをパブリッシュしたり、トピックをサブスクライブしてメッセージを受信したりできます。
  • ノード検出：ノードが互いにどのように相互通信するかを決定する自動プロセス。

ノード

ノードは ROS グラフの登場人物の一人です。 ROS ノードは ROS クライアントライブラリを使って他のノードと通信します。ノードはトピックをパブリッシュまたはサブスクライブすることができます。ノードはサービスを提供または使用することもできます。ノードに関連付けられている設定可能なパラメータがあります。ノード間の接続は、分散検出プロセスを通じて確立されます。ノードは、同じプロセス内、異なるプロセス内、または異なるマシン上に配置できます。これらの概念については、以降のセクションで詳しく説明します。

クライアントライブラリ

ROS クライアントライブラリは、異なるプログラミング言語で書かれたノード同士の通信を可能にします。様々な言語の ROS API に必要な共通の機能を実装するコア ROS クライアントライブラリ（RCL）があります。これにより、言語固有のクライアントライブラリの記述がより簡単になり、より一貫した動作が確保できます。

以下のクライアントライブラリは ROS 2 チームによって管理されています。

  • rclcpp = C++ クライアントライブラリ
  • rclpy = Python クライアントライブラリ

さらに、他のクライアントライブラリは ROS コミュニティによって開発されました。詳しくは ROS 2 クライアントライブラリの記事をご覧ください。

ノード検出

ノードの検出は、ROS 2 の基礎となるミドルウェアを介して自動的に行われます。これは、次のようにまとめることができます。

  1. ノードが起動されると、同じ ROS ドメイン（ROS_DOMAIN_ID 環境変数で設定）を持つネットワーク上の他のノードにその存在を通知します。ノードはこの通知に対して自身に関する情報と共に応答することで、適切な接続を確立し、ノード同士が通信可能となります。

  2. 初期ノード検出期間の後であっても、ノードは定期的に自身の存在を通知して、新しく見つかった対象との接続を確立できるようにします。

  3. ノードはオフラインになると、その状態を他のノードに通知します。

ノードは SoQ 設定について互換性のあるノードとの接続のみを確立します。

サンプル：talker-listener

ターミナルで、トピックに関するメッセージをパブリッシュするノード（C++）を起動します。

ros2 run demo_nodes_cpp talker

別のターミナル上で、同じトピックのメッセージをサブスクライブする2番目のノード（Python）を起動します。

ros2 run demo_nodes_py listener

これらのノードがお互いを自動的に発見し、メッセージを交換し始める様子が確認できます。

翻訳元文書

index.ros.org

関連記事

www.moriken254.com

www.moriken254.com

www.moriken254.com

【ROS 2】コンセプト目次（公式文書和訳）

ROS 2

ROS 2 公式文書（英語） 日本語訳シリーズです。

本ブログの日本語翻訳版のトップページは以下のリンクを参照下さい。

www.moriken254.com

※2019/05/06 現在のものです。

コンセプト目次

ROS 2 の高レベルのドキュメントについてはhttp://docs.ros2.org/ も参照してください。

翻訳元文書

index.ros.org

【ROS 2】ロードマップ（公式文書和訳）

ROS 2

ROS 2 公式文書（英語） 日本語訳シリーズです。

本ブログの日本語翻訳版のトップページは以下のリンクを参照下さい。

www.moriken254.com

※2019/05/06 現在のものです。

このリリースに含まれる予定の詳細については、近日発売予定の Dashing Diademata のページを参照してください。

今後のディストリビューションのスケジュールと情報についてはディストリビューションのページをご覧ください。

ROS 2 の設計に関する詳細は design.ros2.org をご覧ください。 ROS 2 のコアコードは ros2 github Organization にあります。 ROS 2 の設計について議論するための Discourse フォーラム/メーリングリストは ng-ros です。 質問は ROS answers にてお願いします。投稿の際は、ros2タグと、実行中のrosdistroのバージョン（例：ardent）を必ず含めてください。

機能のアイデア（順不同）

設計 / コンセプト

  • IDL（Interface Definition Language）フォーマット：ROS インタフェース（msgs、srv、actions）を指定するために IDL 4.2 を使う
    • メッセージ/サービスでの非 ASCII 文字列のサポート
    • グループ化やさまざまな注釈（コメント、単位）などの新機能の活用
  • .idl ファイル対応：定数や、範囲を指定したパラメータの宣言
  • 移行計画の進捗
  • DDS における ROS ノードの1対1マッピングの再検討
  • ノード名の一意性を確保
  • Python ベースの launch における、オプション設定XML or YAML（フロントエンド向け）

インフラとツール

  • ビルド

    • 「大容量」パッケージ/アーカイブ生成のサポート
    • Windows と Mac OS のパッケージ

  • ドキュメント

    • ドキュメントプラットフォームを改善する
    • ROS 2 buildfarm でのdocジョブのサポート
    • design.ros2.org との統合を検討
    • 3種類のコンテンツを提供 -「デモ」：機能を表示し、テストでカバー -「サンプル」：単純/最小限の使用法の提示（複数の手段がある場合にそれぞれ端的に示す）
      • 「チュートリアル」：Wiki に対するコメントやリンクを含む（推奨される方法の一例を教示する）

新機能

末尾の星は、大まかな成果の大きさを示しています。1つ星が小さい、2つ星が中、3つ星が大です。

  • Pythonでのアクション
  • ログ機能の改善[* / **]
    • ファイルで指定された構成
    • C++ストリーム演算子
    • コンソール出力の色付け
  • パラメータ -コマンドライン引数で個々のパラメータを設定する（yamlファイルを渡す代わりに）
    • 値の範囲を指定
    • 読み取り専用パラメータの定義
  • 追加の Graph API 機能[** / ***]
    • ROS 1 Master API に準拠：ROS/Master_API - ROS Wiki
    • イベントベースの通知
    • 拡張にはrmwインターフェースの知識が必要
  • リマップ[** / ***]
    • Service インタフェースを介した動的なリマップとエイリアス対応
  • 型マスカレード[***]
  • リアルタイムの安全性を強化する[***]
    • FastRTPS の使用
    • サービス、クライアント、およびパラメータ
    • Executor で実行可能ファイルの決定論的順序付けをサポート（公平なスケジューリングの実現）
    • リアルタイムパフォーマンスに関連する QoS パラメータの更なる公開
    • リアルタイムで安全なプロセス内メッセージ通信
  • マルチロボットサポート機能とデモ[***]
    • 全ロボットに関わるノードが全て同一ドメインを共有（+互いに検出）する状態にはしたくない
    • システムを「分割」する方法を設計する
  • Cクライアントライブラリrclcの実装[**]
  • 更なる DDS / RTPS 実装のサポート
    • 動的接続[*]
    • RTI の最小限の実装[*]
    • Eclipse Cyclone DDS（旧ADLINK OpenSplice）[*]
  • セキュリティの向上
    • セキュリティ設定の細分化（認証のみ許可、認証と暗号化を許可、等々）[*]
    • アクセス制御許可生成をサービスに拡張する[*]
    • DDS-Security ロギングプラグインを統合する（セキュリティイベントを集約し、それらを ROS I/F を通してユーザーに報告する方法の統一化）[**]
    • 認証鍵保管のセキュリティ（現状、認証鍵はファイルシステムに格納されているだけ）[**]
    • よりユーザーフレンドリーな I/F（セキュリティ設定の簡単化）。おそらく Qt の GUI？この GUI は、認証鍵の配布にも役立つ [***]
    • 現在実行中の全モジュールに対して鍵とポリシーを自動生成する UI を利用し、「この実行中のシステムを保護してください」とユーザに警告できる機能[***]
    • 鍵を保護したり、暗号化/署名メッセージを高速化するためのハードウェア固有の機能がある場合は、それをまだ使用していないDDS / RTPS 実装に追加するのも面白そう[***]

既存の ROS 1 機能の移植

  • Perception メタパッケージ
    • 画像パイプライン
    • 待ち時間/オーバーヘッドを減らすためプロセス内通信の改善
  • MoveIt
  • RQt
    • もっと多くのプラグインを変換する[*依存性関係に問題がないものから個別に]
  • 診断機能

技術的負債の削減

  • 現在のコードベースに、テストの拡張とデバッグをする
    • 待機セットの不整合
    • コンポーネントよって生じるマルチスレッド問題
    • プロセス内通信のオーバーヘッド/待ち時間を削減
  • 不安定なテストを修正
  • ツールを使用して（すべての）単体テストを実行する機能（例：Valgrind）
  • API レビュー
  • 同期/調整機能の設計ドキュメントと実装
    • プレリリース版の再レビュー（API、ドキュメントなど）
  • 保留中のチケットの宛先指定/分類
  • コード/ドキュメントで TODO 対応

翻訳元文書

index.ros.org

関連記事

www.moriken254.com

www.moriken254.com

www.moriken254.com