1. はじめに¶
重要
このドキュメントに記載されている仕様は予告なく変更される場合があります。このドキュメントは情報提供を目的としたものであり、仕様を保証するものではありません。
説明で使用している画面は一例です。ご使用の環境やアプリケーションのバージョンによって、表示や手順が一部異なる場合があります。
注釈
このドキュメントに記載されている会社名、サービス名、製品名等は、一般に、各社の登録商標または商標です。本文および図表中には、「™」、「®」は明記していません。
1.1. intdash ROS2Bridgeとは¶
Intdash ROS2Bridgeは、エッジデバイスにおいて、ROS2空間とintdash Edge Agentとの間を仲介するソフトウェアです。 intdash ROS2Bridgeを使用することにより、ROS2空間とintdashサーバーとの間で、ROSメッセージのやり取りが可能になります。
intdash ROS2Bridgeは、intdash Edge Agentに対しては1つのデバイスコネクターとして振る舞い、ROS2空間では1つのROS2のノードとして振る舞います。 これにより、ROS2空間から受信したメッセージをintdashサーバーへ送信することができ(アップストリーム)、また、intdashサーバーから受信したメッセージをROS2空間に送信することができます(ダウンストリーム)。
1.2. 主要機能¶
intdash ROS2Bridgeは、以下の機能を提供します。
ROS2空間内のROSメッセージをintdash Edge Agentに渡す(ROS2→intdash)
intdash Edge Agentから取得したメッセージをROS2空間内に流す(intdash→ROS2)
intdash ROS2Bridgeが扱うことができるROS2メッセージの種類は以下のとおりです。
トピック
サービス
サービスリクエスト
サービスレスポンス
パラメータ
パラメータリクエスト
パラメータレスポンス
アクション
アクションゴールリクエスト
アクションゴールレスポンス
アクションフィードバック
アクションリザルト
アクションキャンセルリクエスト
アクションキャンセルレスポンス
ROS2空間とintdashの間のデータ交換では以下のフォーマットを使用します。
CDR(Common Data Representation)
ROS2空間とintdashとの間で双方向の送受信が可能
遠隔のROS2空間同士を接続する際に使用
JSON
ROS2空間からintdashへの送信のみに対応
Data Visualizerでデータを可視化する際に使用
1.3. 動作要件¶
intdash ROS2Bridgeが対応するプラットフォームは以下のとおりです。
AMD64上のUbuntu 20.04
Arm64上のUbuntu 20.04
intdash ROS2Bridgeが動作するROS2のディストリビューションは以下のとおりです。
foxy
intdash ROS2Bridgeは以下のDDS(Data Distribution Service)上で動作することを確認しています。
Fast-RTPS(rmw_fastrtps_cppのみに対応しています。rmw_fastrtps_dynamic_cppはサポートしていません。)
1.4. システム構成¶
intdash ROS2Bridgeを使ってROS2空間をintdash Edge Agentと接続する場合のシステム構成を以下に挙げます。
注釈
本書では、intdashサーバーを介して接続される2つのデバイスをそれぞれ「エッジデバイス1」「エッジデバイス2」と呼びます。
1.4.1. トピックをブリッジする構成¶
エッジデバイス1のROS2ノードがパブリッシュしたトピックを、エッジデバイス2のROS2ノードがサブスクライブする場合の構成は以下のようになります。
エッジデバイス1において:
intdash ROS2Bridge(subscriber)は、ROS2空間内のトピックをサブスクライブします。
intdash ROS2Bridge(subscriber)は、取得したトピックメッセージをintdashデータポイントに変換してintdash Edge Agentに渡します。
intdash Edge Agentは、データポイントをintdash Serverに送信します(アップストリーム)。
エッジデバイス2において:
intdash Edge Agentは、intdash Serverからデータポイントを受信し(ダウンストリーム)、intdash Edge Agentに渡します。
intdash ROS2Bridge(publisher)は、データポイントをトピックメッセージに変換してROS2空間にパブリッシュします。
1.4.2. サービスをブリッジする構成¶
エッジデバイス1のサービスクライアント(ROS2ノード)がサービスリクエストを発行し、エッジデバイス2のサービスサーバー(ROS2ノード)がサービスレスポンスを返す場合の構成は以下のようになります。
エッジデバイス1において:
サービスクライアント(ROS2ノード)がサービスリクエストを発行します。
intdash ROS2Bridge(service server)は、サービスリクエストを受信し、intdashデータポイントに変換してintdash Edge Agentに渡します。
intdash Edge Agentはデータポイントをintdash Serverに送信します(アップストリーム)。
エッジデバイス2において:
intdash Edge Agentは、intdash Serverからデータポイントを受信し(ダウンストリーム)、intdash ROS2Bridge(service client)に渡します。
intdash ROS2Bridge(service client)はデータポイントをサービスリクエストに変換してサービスサーバーに送信します。
service serverはサービスリクエストを処理してサービスレスポンスを発行します。
intdash ROS2Bridge(service client)はサービスレスポンスを受信し、intdashのデータポイントに変換してintdash Edge Agentに渡します。
intdash Edge Agentはデータポイントをintdash Serverに送信します(アップストリーム)。
エッジデバイス1において:
intdash Edge Agentは、intdash Serverからデータポイントを受信し(ダウンストリーム)、intdash ROS2Bridge(service server)に渡します。
intdash ROS2Bridge(service server)はデータポイントをサービスレスポンスに変換して元のサービスクライアントに送信します。
1.4.3. パラメータをブリッジする構成¶
エッジデバイス1のパラメータクライアント(ROS2ノード)がパラメータリクエストを発行し、エッジデバイス2のパラメータサービスサーバー(ROS2ノード)がパラメータレスポンスを返す場合の構成は以下のようになります。
ROS2では、パラメータリクエストとパラメータレスポンスはサービスリクエストとサービスレスポンスと同じ機構を使用しているので、データの流れは サービスをブリッジする構成 と同じです。
1.4.4. アクションをブリッジする構成¶
エッジデバイス1のアクションクライアント(ROS2ノード)がアクションリクエストを発行し、エッジデバイス2のアクションサーバー(ROS2ノード)がアクションを実行しレスポンスを返す場合の構成は以下のようになります。
エッジデバイス1において:
アクションクライアント(ROS2ノード)がアクションゴールリクエストを発行します。
intdash ROS2Bridge(action server)は、アクションリクエストを受信し、intdashデータポイントに変換してintdash Edge Agentに渡します。
intdash Edge Agentはデータポイントをintdash Serverに送信します(アップストリーム)。
エッジデバイス2において:
intdash Edge Agentは、intdash Serverからデータポイントを受信し(ダウンストリーム)、intdash ROS2Bridge(action client)に渡します。
intdash ROS2Bridge(action client)はデータポイントをアクションゴールリクエストに変換してアクションサーバーに送信します。
action serverはアクションゴールリクエストを処理してアクションゴールレスポンスを発行します。
intdash ROS2Bridge(action client)はアクションゴールレスポンスを受信し、intdashのデータポイントに変換してintdash Edge Agentに渡します。
intdash Edge Agentはデータポイントをintdash Serverに送信します(アップストリーム)。
エッジデバイス1において:
intdash Edge Agentは、intdash Serverからデータポイントを受信し(ダウンストリーム)、intdash ROS2Bridge(action server)に渡します。
intdash ROS2Bridge(action server)はデータポイントをアクションゴールレスポンスに変換して、元のアクションクライアントに送信します。
アクションキャンセルリクエストは上記のアクションゴールリクエストと同じ流れでブリッジされます。
また、アクションフィードバック、アクションゴールリザルト、アクションキャンセルレスポンスは、アクションゴールレスポンスと同じ流れでブリッジされます。