ros2_control、名前付き状態インターフェースとコマンドインターフェースを公開することで、コントローラーアルゴリズムとハードウェア通信を分離します。ハードウェアプラグインはセンサーの読み取りやアクチュエーターの書き込み方法を知っています。コントローラーはインターフェースを消費し、主張します。コントローラーマネージャーはライフサイクルを調整し、制御更新を実行します。
このアーキテクチャはコントローラーを再利用可能にしますが、ドライバーが決定論的でロボットが安全であるわけではありません。インターフェース名、ユニット、ライフサイクル、所有権、更新タイミング、故障動作はすべて実際のデバイスと一致しなければなりません。ロードされたプラグインは、コミッショニングの始まりに過ぎません。
このガイドは ROS 2 リアルタイムコントロールガイド および ジョイントコントロールモードガイドと一緒に使ってください。デプロイされたROSやros2_controlバージョンに合致するドキュメントのブランチをたどってください。
アーキテクチャを責任の境界として活用する
コントローラはベンダープロトコルの詳細を埋め込むことなく、参照や測定状態からコマンドを計算すべきです。ハードウェアコンポーネントは、ロボットのタスクを決定することなく、物理デバイスと合意されたインターフェース間で変換されるべきです。リソースマネージャーとコントローラーマネージャーはこれらの側面を接続し、ライフサイクルと主張を強制します。
スケーリング、オフセット、飽和、ウォッチドッグ、フォールトリセット、モード遷移をどのレイヤーが所有しているかを文書化してください。2つの層が両方とも極限または変換を適用する場合、シミュレーションとハードウェア間で挙動が異なることがあります。どちらも所有していなければ、有効なコマンドが未確認でデバイスに到達する可能性があります。
読み書き・更新・書き込みのループに従ってください
典型的な制御サイクルでは、ハードウェアの状態を読み込み、アクティブなコントローラを更新し、その結果得られたコマンドを書き込みます。測定された期間は一貫して通過し、制御者がタイミングを管理できるようにすべきです。アップデートで使用される状態は、ソフトウェア呼び出しに先立つ物理的なサンプリング時間に対応します。
計器の読み込み、コントローラの更新、書き込みは別々に行われます。最悪の観測時間、ジッター、オーバーラン、データ年齢を記録します。 ros2_controlアーキテクチャのドキュメント は役割を説明しています。インストールされたドライバーとバスが実際のタイミングを決定します。
| 層 | 所有者 | 暴露しなければならない | 典型的な故障 |
|---|---|---|---|
| ハードウェアコンポーネント | デバイス通信 | 状態インターフェースとコマンドインターフェース | タイムアウトまたは単位エラー |
| リソースマネージャー | 資源とライフサイクル | 利用可能なインターフェースと主張されているインターフェース | 名称または状態の不一致 |
| コントローラーマネージャー | コントローラのライフサイクルとループ | コントローラーの状態とタイミング | 発動またはオーバーラン |
| コントローラー | 制御法則 | 必要なインターフェースと参照 | 無効モードまたは飽和 |
| ロボット応用 | 目標と運営状況 | 妥当性と代替 | 安全でない移行 |
状態インターフェースとコマンドインターフェースは異なる権限を持っています
状態インターフェースは、位置、速度、努力、温度、デバイスの状態などの測定値や派生値を持ちます。コマンドインターフェースは、位置、速度、努力、カスタムデバイスコマンドなどの要求された値を運びます。名前を一致させるだけで単位や符号、範囲、意味の更新にはつながりません。
各関節とセンサーごとにインターフェース契約を作成しましょう。単位、方向、ラップ動作、有効範囲、ソースタイムスタンプ、利用不可の値の動作、物理所有者を含めてください。クローズドループ制御を有効にする前に、静止時および既知の小さな動作中に値を検証してください。
URDF ros2_controlタグは実行可能な契約です
ロボットの説明は、ハードウェアコンポーネントの種類、プラグイン、パラメータ、ジョイント、センサー、インターフェースを特定します。ros2_controlブロック内の関節名は、コントローラーが期待するロボットモデルと一致しなければなりません。スペルの違いでコントローラーがロードされていてもリソースを回収できないことがあります。
xacro生成出力をテスト対象の構成として扱います。レンダリングされた URDF ファイルやパラメータファイルもアーカイブし、ソースマクロだけでなく。実際のアクチュエーターを起動する前に、重複名、プラグインクラス、インターフェースセット、制限値、初期値を検証してください。
ハードウェアトポロジーからシステム、アクチュエータ、またはセンサーを選択できます
システムコンポーネントは、通信や伝送を共有する複雑な多自由度ハードウェアを表すことが一般的です。アクチュエータは、よりシンプルでコマンド可能なデバイスで、多くの場合自由度が1つです。センサーは読み取り専用のデバイス状態を露出します。選択は組織に影響し、身体的能力自体には影響しません。
現在の ハードウェアインターフェースタイプのドキュメント は、これらのカテゴリと URDF 構造を説明しています。APIや機能は進化するので、ブランチをデプロイメントに合わせてください。同じ接続を争うプラグインに分割して、定義されたコーディネーターを持たないでください。
| コンポーネントの種類 | 典型的なハードウェア | 読む | 書く | 設計に関する質問 |
|---|---|---|---|---|
| システム | ロボットアームまたは連結手 | 複数の状態 | 複数コマンド | コミュニケーションは共有されていますか? |
| アクチュエータ | 独立モーターまたはバルブ | 任意または地方国家 | デバイスコマンド | 所有権はモジュール式ですか? |
| センサー | IMU(力センサー) | センサー状態 | 全くありません | 誰がタイムスタンプを付けて認証するのか? |
| モックコンポーネント | シミュレーションまたは積分テスト | 生成状態 | 指揮権の受領 | どの故障がモデル化されているのでしょうか? |
| カスタムトポロジー | ベンダー固有のデバイスセット | 契約依存 | 契約依存 | 共有の故障はどのように抑制されるのでしょうか? |
ライフサイクルは積み込みと安全な運転を分けています
ハードウェアやコントローラはライフサイクル状態を通過します。読み込みはコードと設定がインスタンス化可能であることを証明します。動員は作戦参加を認めます。物理デバイス(ブレーキ、ドライブ有効化、保持コマンドなど)に対して、コンフィギュレーション、アクティベート、無効化、クリーンアップ、エラーの意味を定義してください。
設定失敗、ハードウェアの部分的な可用性、エラー後の再アクティベートをテストします。コントローラーは古い状態や互換性のないドライブモードでアクティブになるべきではありません。HMIにハードウェア状態、コントローラー状態、ロボットの動作状態を別々に表示させてください。
コマンドインターフェースは排他的主張を必要とします
コントローラーは必要なコマンドインターフェースを主張します。2人の独立したコントローラーが同じコマンドリソースを同時に所有することは一般的にできません。複数のコントローラーは、主張が競合しない場合や、サポートチェーンが参照の流れを明示的に定義している場合に共存できます。
切り替え前に、必要および主張されたインターフェースを必ず確認してください。移行時の厳格さ、タイムアウト、フォールバックの行動を定義してください。ポジションコントローラーとエフォートコントローラーは、ソフトウェアの主張を超えて物理的なドライブモード変更を必要とする場合があります。その変化をリミットや検証された状態と調整します。
更新速度はタイミングの保証ではありません
設定された更新率は目標スケジュールです。カーネルのスケジューリング、エグゼキュータ作業、メモリ障害、ドライバーのブロッキング、バス遅延、遅いコントローラが締め切りの有無を決定します。平均的な周波数は正しく見えることがありますが、時折長いサイクルが速い関節を不安定にします。
期間分布と各ループセグメントの完全なログ、ネットワークおよびセンサー負荷を測定します。非リアルタイムのサービスやパラメータ作業を制御パスから分離します。 リアルタイムガイド を使ってメモリ、スケジューリング、データ交換の証拠を設計しましょう。
ハードウェアI/Oは境界され、観察可能に保たれます
読み書きコールには、上限と失敗結果が文書化されているべきです。ネットワークドライバーは締め切り、シーケンス処理、デバイス状態チェックを必要とします。古い状態を新しいもののように返すのは、エラー報告よりも危険です。なぜなら、コントローラーは偽のプレゼントから継続しているからです。
通信年齢、パケットロス、ドライブ障害、飽和状態、温度を適切な状態や診断で暴露し、ループをブロックせずに明らかにしましょう。故障したジョイントが部品を停止させるのか、動作の劣化を許すのかを判断し、その選択をシステム安全分析と整合させてください。
デバッグ名、ライフサイクル、主張、タイミングを順に
ロボットが動かない場合は、まずレンダリングされた URDF の名前とリストされたハードウェアインターフェースを比較します。次に、ハードウェアのライフサイクル、コントローラの種類と状態、必要なインターフェース、実際の主張事項を検査します。所有が正しい場合のみ、調整や軌道上の挙動が主な疑いとなります。
コントローラーマネージャーのドキュメントとROS 2制御CLIはコントローラおよびハードウェアの状態を公開します。出力をログとともに保存し、断続的なアクティベーションや競合を再構築できるようにします。
モックハードウェアからロードモーションへのコミッション
まずスキーマとプラグインテストから始め、次にモックコンポーネントやシミュレーター、アクチュエーションなしのデバイス通信、低消費電力の単一関節の動き、最後に代表的な負荷下での協調運動を行います。各段階は定義された故障を導入し、期待される状態遷移を検証します。
シミュレーションは名前、主張、コントローラーのロジックはテストできますが、バスジッター、エンコーダ配線、ブレーキ、熱限界、実際の故障コードはテストできません。同じインターフェースコントラクトを各段階で保持し、モックが再現しないすべての挙動をリストアップします。
統合ゲートと制御アクセプタンスゲートを別々に作成します
統合受容は、コンポーネントのロード、ライフサイクル、インターフェース値、主張、スイッチング、タイムアウト、再起動、診断を検証します。制御受容は、追跡、擾乱応答、飽和度、限界およびペイロードおよび温度に対する安定性を検証します。それらを分離することで、制御症状が壊れたインターフェースを隠すのを防ぎます。
正確なROS配布、ros2_controlパッケージ、ハードウェアファームウェア、 URDF、パラメータ、テスト結果をアーカイブしてください。各リリースごとに簡潔なコミッショニングチェックリストを使いましょう。
- 表示された名前、ユニット、標識を必ず確認してください。
- ハードウェアとコントローラーのライフサイクル状態を点検してください。
- 必要と主張されたインターフェースを確認してください。
- 負荷時に読み書き・更新・書き込みのタイミングを測定します。
- 通信の注入、再起動、モードスイッチの失敗。
よくある質問
ros2_controlモータードライバーですか？
いいえ。これはコントローラーロジックをハードウェアプラグインに接続するフレームワークです。プラグインまたは下位ライブラリはデバイス通信を実装します。
状態インターフェースとコマンドインターフェースの違いは何ですか？
状態インターフェースは測定値や導出値を公開し、コマンドインターフェースは要求された値を受け入れるため、制御された所有権が必要です。
なぜコントローラーは読み込まれているのにロボットは動かないのですか？
コントローラが非アクティブであったり、インターフェースを主張できなかったり、名前が不一致に接続されたり、非アクティブまたは故障したハードウェアコンポーネントに直面している場合があります。
複数のコントローラーを同時に動かすことはできますか？
はい、インターフェースの主張が互換性がある場合や明示的なチェーン設計がそれを支持している場合にはそうです。指揮官の所有権の対立は解決しなければなりません。
ループupdate_rateリアルタイムにするのでしょうか？
いいえ。目標金利を設定します。制限付きスケジューリング、コードパス、ドライバ、メモリおよびハードウェア通信は別々に測定する必要があります。
ros2_control 統合境界
ros2_controlソフトウェアアーキテクチャとライフサイクルメカニズムを提供します。それだけではリアルタイム性能、コントローラの安定性、ハードウェアの正確性、機能安全を保証するものではありません。