ROS 2エグゼキュータは、利用可能なスレッドでコールバックが実行されるタイミングを決定します。コールバックグループは、同時に実行できるコールバックを制限します。したがって、マルチスレッド実行者は作業が一つの相互排他的グループに留まるとほぼ連続的に動作し、リエントラントグループは安全でない共有状態アクセスを露呈できます。
ロボットのタイミング不具合は、古いセンサーデータ、遅延制御タイマー、またはサービスのブロックとして現れることが多いです。原因としては、コールバック実行、実行前の待ち時間、ロック、同期サービス使用、またはミドルウェアキューなどが挙げられます。スレッド数だけではボトルネックを特定することはできません。
このガイドを ROS 2 リアルタイムコントロールガイド および ROS 2 QoS ガイドと一緒に使ってください。設定を変更する前にデプロイされたエグゼキュータを追跡してください。
執行者をコールバックスケジューラーとして扱う
サブスクリプション、タイマー、サービス、クライアント、待機期限は準備ができれば実行可能なコールバックとなります。エグゼキュータは作業を待ち、適格なコールバックを選択し、実装およびコールバックグループのルールに従って呼び出します。ロボットにとってどの作業が緊急かを自動的に推測するわけではありません。
すべてのコールバックを期待レート、最大実行時間、共有リソース、期限とともにリストアップしてください。同期クライアントや未来で使われる隠れたコールバックを含めましょう。不完全な在庫は、デッドロック分析や応答時間の主張を信頼性に欠落させます。
単一のスレッドでブロッキングが見えるようになります
シングルスレッドのエグゼキュータは一度に1つのコールバックを実行します。長いイメージコールバックやディスク書き込みのブロック、サービス待ちはそのエグゼキュータ内のコールバックの間隔を遅らせます。この単純さは、最悪ケースの複合作業負荷が適合する決定論解析に有用です。
開始準備待ちと開始から終了までの実行を別々に測定してください。タイマーが遅れて始まる場合、タイマーコールバックは短時間になることがあり、別のコールバックがスレッドを所有している場合があります。1回のブロッキングコールが遅延を引き起こす場合、平均CPU使用率は低いまま維持できます。
| 症状 | おそらく層 | 最初の測定 | 共通の原因 |
|---|---|---|---|
| すべてのコールバックが一時停止 | シングルエグゼキュータスレッド | ランニングコールバック時間 | 入出力のブロッキング |
| 連載するのは1つのグループだけです | コールバックグループ | グループトレースとスレッドトレース | デフォルトグループ |
| サービスコールがハングします | 依存サイクル | 将来とグループの所有権 | 自己行き詰まり |
| 新しいメッセージが遅れて届く | キューまたはエグゼキューター | コールバック時のサンプル年齢 | スローコンシューマー |
| 負荷時に締め切りが遅れる | スケジュールと争い | 尾の待ち時間 | 共有ロックまたはCPUプレッシャー |
複数のスレッドが並列コールバックを保証するわけではありません
マルチスレッドエグゼキュータは複数のスレッドで適格なコールバックを実行することができますが、コールバックグループの制限は依然として適用されます。すべてのエンティティがノードのデフォルトの相互排他グループを使用している場合、多数のエキューキュータスレッドが存在しても並列実行できません。
エンティティ作成時にグループ割り当てを確認し、グループが執行者と関連付けられていることを確認します。実装の動作が進化するため、現在の ROS 2 エグゼキュータコンセプト はデプロイされたディストリビューションで読み取るべきです。
保護配列には相互排他的群を用いる
相互排他的コールバックグループは、コールバック同士が同時に実行されるのを防ぎます。これにより、スレッド安全でない状態を別個のロックなしで保護でき、グループ内の順序付けの前提を保持できます。また、重要なタイマーを遅らせることで無関係な長時間の作業を引き起こすこともあります。
コールバックは単にノード単位ではなく、実際の並行要件でグループ化します。シリアライズが必要なデバイストランザクションを一緒に配置しつつ、共有状態設計が許す場合は独立したテレメトリや高価な処理を分離します。なぜ各グループが排他的であるのかを文書化しましょう。
リエントラントグループはスレッドセーフコードを必要とします
リエントラントグループは、同じコールバックの複数のインスタンスを含むコールバックの重複を許可します。独立した作業の同時実行性を向上させることは可能ですが、アクセスされるライブラリやバッファ、デバイスをスレッド安全にするわけではありません。レースコンディションは状態を破損させる一方で、ベンチマークはより速く現れます。
共有変数、パブリッシャー、クライアント、デバイスハンドル、サードパーティライブラリをレビューしましょう。制限付き同期を使用し、I/Oでロックを保持しないようにしましょう。重複するリクエストや、可能な限りスレッドサニタイザーや同等のテストを行ってください。
| グループ選択 | 並行処理 | 有用 | 一次リスク |
|---|---|---|---|
| 相互排他的 | グループでのコールバック1回 | 順序付きデバイスアクセス | 隠しシリアライズ |
| 再入者 | 重複するコールバック | 無国籍の独立労働 | データレース |
| 別々の排他グループ | グループ間の並行 | 独立したシリアル化デバイス | クロスグループ共有ロック |
| 専任執行者 | 別スレッドプール | 臨界経路の隔離 | 調整オーバーヘッド |
| 非ROS労働者 | 明示的なハンドオフ | ブロッキングまたはバッチ作業 | キュー所有権 |
同期自己デッドロックの回避
同期サービス要求を行うコールバックは、同じ相互排他的なグループ内で実行される応答コールバックを待つことがあります。待機中のコールバックはグループの適格性を保持するため、応答は実行できません。未来や行動にも同様のサイクルが起こり得ます。
コールバック内の非同期フローを好む、依存コールバックを互換性のあるグループに配置するか、慎重に設計された別のエグゼキュータを使用する。待ち時間グラフを描いてタイムアウトをテストします。スレッドを追加してもグループレベルの除外サイクルは断ち切れません。
実行および待機分布によるサイズ
各コールバックごとに、呼び出し率、実行時間パーセンタイル、最大観測時間、準備待ち時間を記録します。CPU親和性、スレッド識別、可能であればロック待ちを追加しましょう。スレッドプールは、プロセッサコア数だけでなく、並行処理やブロッキングの動作でサイズを決めるべきです。
シリアライズ、ミドルウェアの取得、メモリ割り当て、ログおよびキャッシュ効果を含めてください。熱スロットリングやバックグラウンドジョブを露呈させるまで、十分な時間実行してください。高スループットの結果は、制御尾の遅延が許容できないと共存することがあります。
優先権は自動的にはありません
エキューキュータ選択だけでは、オペレーティングシステムのスレッド優先度、コールバック優先度、または限定されたプリエンプションを保証するものではありません。クリティカルとベストエフォートのコールバックはワーカースレッドやロックを共有することがあります。実行者の動作によっては、制御タイマーの前に準備された低重要度のコールバックが実行されることがあります。
締め切りが重要な場合は、重要な作業を分離し、スケジューリングやアフィニティを意図的に設定し、ブロッキング操作を除去し、最悪ケースの競合下で測定します。ROS 2リアルタイムデモは、任意のアプリケーションの認証ではなく、支援的な実践を説明しています。
QoS遅延と遺言執行者の遅延を分ける
QoS 互換性、保持率、輸送挙動に影響を与えます。エグゼキュータは、すでに準備が整っているコールバックが実行されるタイミングに影響を与えます。どちらもサンプル年齢を延ばす可能性があります。ReliableをBest Effortに変更すればネットワークのバックログは減りますが、ミューテックスでブロックされたコールバックは修正できません。
ソースのタイムスタンプとシーケンス番号をコールバックに持ち込みます。受信準備状況、コールバック開始、消費時間を記録します。これにより、ミドルウェアの配信前後に遅延を特定し、誤ったレイヤーの調整を防ぎます。
トレースと制御負荷による診断
コールバックの準備完了、開始・終了イベント、実行者スレッド、グループ識別子および関連するロックを追跡します。負荷源を1つずつ追加してください:高速センサー、サービスバースト、遅いI/O、CPU負荷、ネットワーク損失です。設計を変更する前に、故障したトレースを保存してください。
その後、コールバックグループを移動または分割し、同期依存関係を1つ置き換えるか、ブロッキングタスクを1つオフロードします。同じ作業量を繰り返します。適応的測定は、複数のタイミング層を同時に変更する完全な書き換えよりも強力な証拠を提供します。
リアルタイム経路を利便性作業から分離する
可視化、パラメータサービス、診断、バッグ記録、モデル推論は、エグゼキュータスレッド、ロック、メモリを共有すると制御に干渉することがあります。専用のコントロールスレッドやエグゼキューターに移行する際は、境界キューと明示的な所有権を活用しましょう。
隔離しても通信遅延はなくならない。最新の有効状態を定義し、各境界でポリシーとウォッチドッグを落とします。ベストエフォート作業がクリティカルパスで消費されたキューを埋められないか確認してください。
締め切りとデータ年齢による受け入れ
スループットをカウントしますが、受理はコールバック待ち、実行尾、タイマーの遅延期間、使用時のサンプル年齢、過負荷後の回復に基づいています。ソフトウェアとハードウェアの変更後に同じコールバックグラフをテストしてください。
グループ、スレッドプール、スケジューリング、共有ロック、最悪のケースワークロードを含むエグゼキュータ契約を公開します。
- すべてのコールバックや隠れた依存関係を在庫管理してください。
- トレース待ち時間と実行時間を別々に設定してください。
- マップ、コールバックグループや共有リソース。
- CPU、I/O、サービス、センサーの負荷を注入します。
- 締め切りとデータの最新性を基準に受け入れてください。
よくある質問
マルチスレッドエグゼキューターはすべてのコールバックを並列で実行しますか？
いいえ。コールバックグループルール、レディワーク、スレッドカウント、共有ロックが実際の並行性を決定します。
すべてのコールバックはデフォルトのグループに残ることはできますか？
可能ですが、デフォルトの相互排他グループは作業をシリアライズし、意図された並列性を損なう可能性があります。
リエントラントのグループは常に速いのでしょうか？
いいえ。これは重複のみを許可します。競合、レース、余計な同期はパフォーマンスや正確性を低下させる可能性があります。
Best Effort QoS 遺言執行者の遅延を修正できますか？
遅延はコールバックのスケジューリングやロック、ブロッキングコードによるものではなおさらです。両方の層を測定してください。
まず何を測定すべきでしょうか？
各コールバックごとに、ソースデータの年齢、開始待ち時間、実行時間、スレッドおよびコールバックグループを測定します。
遺言執行者のタイミング証拠境界
エキューターのタイミングはROSの配布、RMW、オペレーティングシステム、ハードウェア、コールバックコード、ワークロードに依存します。展開したグラフを測定し、エグゼキュータの設定だけではリアルタイムの保証にはなりません。