ディレクトリ
4.1.2 启动node : rosrun, roslaunch
4 ROS通信アーキテクチャ
ノード：
ROSの世界では、プロセスの最小単位はノードです。ソフトウェアパッケージには複数の実行可能ファイルを含めることができます。実行可能ファイルは、実行されるとプロセスになり、このプロセスはROSではノードと呼ばれます。チェンから
手続きの観点から見ると、nodeは実行可能ファイルです（通常、C ++コンパイル、Pythonスクリプトによって生成された実行可能ファイル）。
実行され、メモリにロードされます。機能の観点からは、通常、ノードロボットを担当する単一の個人
機能。ロボットの機能モジュールは非常に複雑であるため、すべての機能をノードに集中させないことがよくあります。
分散アプローチを使用します。たとえば、シャーシホイールの動きを制御するノード、カメラを駆動して画像を取得するノード、LIDARを駆動するノード、センサー情報に基づいて経路を計画するノードなどがあります。
主人：
マスターは、ネットワーク通信アーキテクチャ全体における管理センターに相当し、各ノードを管理します。ノードは最初にマスターに登録され、次にマスターはROSプログラム全体にノードを含めます。ノード間の通信も最初にマスターによって「プル」されるため、ポイントツーポイント通信をペアで実行できます。ROSプログラムが開始すると、最初のステップはマスターを最初に開始することであり、ノードマネージャーはノードを処理し、ノードを順番に開始します。
4.1マスターとノードを起動する
4.1.1マスターを起動します：roscore
ROSを開始するときは、最初にroscoreコマンドを入力してマスターを開始します。
$ roscore
この時点で、ROSマスターが開始され、rosoutとパラメーターサーバーも開始されます。
ログ出力のノード。その役割は、出力システムエラー、警告などを含む現在のシステムステータスをユーザーに通知することです。
など、ログファイルにログインします。パラメータサーバーはパラメータサーバーであり、ノードではありません
パラメータ設定を保存するサーバーです。ROSノードを実行するたびに、マスターを起動して、ノードを起動して登録できるようにする必要があります。
4.1.2 启动node : rosrun, roslaunch
あなたはrosrun、roslaunchを使うことができます
rosrun コマンドの詳細な使用法は次のとおりです。
$ rosrun [--prefix cmd] [--debug] pkg_name node_name [ARGS]
rosrunは、PACKAGEの下でEXECUTABLEという名前の実行可能プログラムを探し、オプションのパラメーターARGSを渡します。
roslaunch コマンド：
roslaunch pkg_name file_name.launch
マスターと複数のノードを同時に起動できます。roslaunchコマンドは、システムのroscoreが実行されているかどうか、つまりノードマネージャーが実行されているかどうかを自動的に検出します。マスターが起動されていない場合は、roslaunchが最初にマスターを起動します。次に、起動のルールに従います。
4.1.3 rosnodeコマンド
- rosnodeリストは、現在実行中のノード情報をリストします
- rosnode info node_nameはノードの詳細情報を表示します
- rosnode kill node_nameノードを終了します
- rosnode pingテスト接続ノード
- rosnode machineは、特定のマシンまたはリストマシンで実行されているノードをリストします。
- rosnodeクリーンアップは到達不能ノードの登録情報をクリアします
rosnodeは、rosnodeコマンドの使用法を表示するのに役立ちます。
4.2 ROS通信方式
ROSの通信方式はROSの中核をなす概念であり、ROSの通信方式には4種類あります。
- トピック
- サービス
- パラメータサービス
- Actionlibアクションライブラリ
4.2.1トピック
ROSの通信方法の中で、トピックは一般的に使用されるものです。リアルタイムの定期的なメッセージの場合、トピックを使用して送信することをお勧めします。トピックは一種のポイントツーポイント一方向通信方式であり、「ポイント」はノードを指します。つまり、トピックを介してノード間で情報を転送できます。トピックでは、次の手順の初期化プロセスを実行する必要があります。最初に、パブリッシャーノードとサブスクライバーノードの両方がノードマネージャーに登録する必要があります。次に、パブリッシャーがトピックをパブリッシュし、サブスクライバーがマスターのコマンドでトピックにサブスクライブして、サブパブを確立しますコミュニケーション。プロセス全体が一方向であることに注意してください。サブスクライバーは、メッセージを受信すると処理します。通常、このプロセスはコールバックと呼ばれます。いわゆるコールバックは、処理関数を事前に定義すること（コードで記述）です。メッセージがあると処理関数をトリガーし、関数はメッセージを処理します。
トピック通信は、一方向の非同期通信方式です。
その構造の概略図を以下に示します。
4.2.1.1 rostopicコマンド：
- rostopicリストは、現在のすべてのトピックをリストします
- rostopic info topic_nameは、トピックの属性情報を表示します
- rostopic echo topic_nameはトピックの内容を表示します
- rostopic pub topic_name ...トピックにコンテンツを公開する
- rostopic bw topic_nameトピックの帯域幅を表示する
- rostopic hz topic_nameトピックの頻度を表示する
- rostopic find topic_typeトピックのタイプを見つける
- rostopic type topic_nameトピックのタイプを表示（msg）
4.2.1.2 msgファイル
メッセージは、トピックコンテンツのデータタイプであり、トピックのフォーマット標準とも呼ばれます。サフィックス.msgが付いたファイルで定義されます。
基本的なmsgデータ型には、bool、int8、int16、int32、int64（およびuint）、float、float64、string、time、duration、header、可変長配列array []、および固定長配列array [C]が含まれます。
msg sensor_msg / imageなどの特定のmsgを使用して、場所はsensor_msgs / msg / image.msgに格納されます。その構造は次のとおりです。
std_msg / Headerヘッダー
uint32 seq
タイムスタンプ
文字列frame_id
uint32の高さ
uint32の幅
文字列エンコーディング
uint8 is_bigendian
uint32ステップ
uint8 []日付
4.2.1.3 rosmsgコマンド：
- rosmsg listは、システム上のすべてのメッセージをリストします
- rosmsg show msg_nameメッセージの内容を表示する
4.2.2サービス
サービス通信は双方向であり、メッセージを送信できるだけでなく、フィードバックも送信できます。したがって、サービスには2つの部分が含まれます。1つはリクエスター（Clinet）で、もう1つはレスポンダー/サービスプロバイダー（サーバー）です。このとき、リクエスタ（クライアント）はリクエストを送信し、サーバーが処理するのを待って応答を返すため、「リクエスト/レスポンス」と同様のメカニズムを通じてサービス通信全体が完了します。
ノードBは/サービスと呼ばれるサービスインターフェースを提供するサーバー（レスポンダー）です。通常、トピックと同様に、文字列型を使用してサービスの名前を指定します。ノードAはノードBへの要求を開始し、処理後にフィードバックを受け取りました。
サービスは同期通信方式です。いわゆる同期とは、ノードAが要求を発行した後、ノードAが応答するまで応答を待機することを意味します。
ノードBが要求を処理して応答を完了した後、ノードAは実行を継続します。ノードAは待機中です
ブロックされた通信。この通信モデルは、頻繁なメッセージング、競合、高いシステムリソース占有を持たず、リクエストを受け入れるときにのみサービスを実行します。これはシンプルで効率的です。
4.2.2.1トピックVSサービス
4.2.2.2 rosserviceコマンド
- rosserviceリストサービスリストの表示
- rosservice infoサービス情報を出力します
- rosserviceタイプ
- rosservice uri印刷サービスROSRPC uri
- rosservice findサービスタイプによるサービスの検索
- rosservice呼び出しは、提供された引数を使用してサービスを呼び出します
- rosservice args印刷サービスパラメータ
4.2.2.3 srvファイル
srvファイルは、サービスを記述するために使用されます（サービスデータタイプ、サービス通信のデータ形式は* .srvで定義されています。これは、要求部分と応答部分を含むサービスを宣言します。
フォーマット宣言は次のとおりです。例：
msgs_demo / srv / DetectHuman.srv
bool start_detect
---
my_pkg / HumanPose [] pose_data
msgs_demo / msg / HumanPose.msg
std_msgs / Headerヘッダー
文字列uuid
int32 number_of_joints
my_pkg / JointPose [] joint_data
msgs_demo / msg / JointPose.msg
文字列joint_name
geometry_msgs /ポーズポーズ
floar32信頼
srvファイルの形式は非常に固定されており、最初の行は要求された形式で、中央が---で区切られています。3番目の行は応答の形式です。この例では、要求は検出を開始するかどうかであり、応答は配列であり、配列の各要素は人のジェスチャー（HumanPose）です。人間のジェスチャーに関しては、これは実際にはmsgであるため、srvはmsgにネストできますが、srvにネストすることはできません。
4.2.2.4 rossrvコマンド
- rossrv show show service description
- rossrv listすべてのサービスを一覧表示します
- rossrv md5表示サービスmd5sum
- rossrvパッケージはパッケージ内のサービスをリストします
- rossrvパッケージはサービスを含むパッケージをリストします
4.2.3パラメータサーバー
パラメータサーバーは、特殊な「通信方式」とも言えます。特別な点は、パラメーターサーバーは、ノードがパラメーターを格納し、パラメーターを構成し、パラメーターをグローバルに共有する場所であるということです。パラメータサーバーはインターネット送信を使用し、ノードマネージャで実行されて通信プロセス全体を実現します。
パラメータサーバーは、ROSの別のデータ送信方法として、トピックやサービスとは異なり、より静的です。パラメーターサーバーは、さまざまなパラメーターと構成を格納するデータディクショナリを維持します。
パラメータサーバーを保守するには、次の3つの方法があります。
- コマンドラインのメンテナンス
- 起動ファイルを読み書きする
- ノードのソースコード
4.2.3.1コマンドラインのメンテナンス：rosparam
- rosparam set param_key param_value Setパラメータ
- rosparam get param_key表示パラメータ
- rosparam load file_nameロードパラメータをファイルから
- rosparam dump file_nameパラメータをファイルに保存
- rosparam delete deleteパラメータ
- rosparam listはパラメータ名をリストします
ロード＆ダンプ文件
ロードおよびダンプファイルはYAML形式に準拠する必要があります。YAML形式の具体例は次のとおりです。
名前： '張山'
年齢：20歳
性別： 'M'
スコア{中国語：80、数学：90}
score_history：[85,82,88,90]
4.2.3.2起動ファイルの読み取りと書き込み
起動ファイルには多くのタグがあり、パラメータサーバーに関連するタグは2つだけです。1つは<param>で、もう1つは
<rosparam>です。
4.2.3.3ノードのソースコード
ROSソースコード、つまりAPIを使用してパラメーターサーバーを操作します。以下の章を学習した後、具体的な内容を紹介します。
4.2.4アクション
ActionlibはROSで非常に重要なライブラリです。サービス通信メカニズムと同様に、actionlibもリクエストレスポンスメカニズムです。
通信方式、actionlibは主にサービス通信の欠点を補います。つまり、ロボットが長期間のタスクを実行する場合です。
その際、サービス通信方式を使用すると、パブリッシャーが長時間応答を返さず、通信が発生する
邪魔。サービス通信がタスクをうまく完了できない場合、actionlibは長期通信に適しています。
プロセス、actionlib通信プロセスはいつでも表示でき、プロセスの進行も終了できます。このような機能により、
それはいくつかの特別なメカニズムで高い効率を持っています。
4.2.4.1アクションの動作原理
アクションの動作原理は、クライアントサーバーモードであり、これは双方向通信モードでもあります。ROSでの通信相手
アクションプロトコルでは、データ交換と通信はメッセージを介して行われます。クライアントとサーバーはユーザーにシンプルな
ターゲットをリクエストする（クライアント側で）、または関数呼び出しとコールバックを介してターゲットを実行する（サーバー側で）API。
作業モードの概略図は次のとおりです。
クライアントはターゲット命令とキャンセルアクション命令をサーバーに送信し、サーバーはリアルタイムのステータス情報、結果情報、フィードバック情報などをクライアントに送信できるため、サービスでは実行できない部分を完了できます。
4.2.4.2アクションファイル
リクエストレスポンスにアクションライブラリを使用します。アクションのコンテンツ形式には、目標、フィードバック、結果の3つの部分を含める必要があります。
- 対象
ロボットがアクションを実行するとき、いくつかのパラメータ、方向、角度、速度などの設定を含む、明確な移動ターゲット情報が必要です。ロボットがモーションタスクを完了できるようにします。
- フィードバック
アクションの過程で、サーバー実装者へのリアルタイムのステータス情報フィードバックがあり、実装者にアクションの完了ステータスを通知する必要があります。これにより、実装者は正確な判断を下してコマンドを変更できます。
- その結果
動作が完了すると、アクションサーバーは運動の結果データをクライアントに送信します。これにより、クライアントは、ロボットの動作の長さや最終姿勢など、アクションのすべての情報を取得できます。
アクション仕様ファイルのサフィックス名は.actionで、そのコンテンツ形式は次のとおりです。
＃目標を定義する
uint32 dishwasher_id＃使用したい食器洗い機を指定
---
＃結果を定義する
uint32 total_dishes_cleaned
---
＃フィードバックメッセージを定義する
float32 percent_complete
