低速（30Hz）システムで高速（200Hz）リアルタイムシステムを制御するにはどうすればよいですか？

現在、複数の制御された自由度とセンサーを備えた移動ロボット+取り付けアームを設計しています。

私は2つの部分でアーキテクチャを検討しています：

1. アームモーターとエンコーダーを制御するための一連のリアルタイムコントローラー（XenomaiなどのRTOSを実行するRaspeberry Piまたはベアメタルマイクロコントローラー）。マイクロコントローラーの数に応じてx = 1,2,3…でこれらのマシンをRTxと呼びましょう。この制御ループは200Hzで実行されます。

2. ROSを実行してSLAM、mocapを計算し、高レベルのロジックを実行する強力なバニラLinuxマシン（ロボットのタスクを決定し、モーターの希望する位置と速度を計算します）。この制御ループは30Hzで実行されます。

より多くのモーター、より多くのセンサー、より多くのPC（外部のモーションキャプチャーなど）を考慮して、フレームワークをスケーラブルにする必要があることを知っています。

私の主な問題は、さまざまなRTxがPC1と通信する方法を決定することです。ロボットアーキテクチャ（HRP2など）に関連する論文を見てきましたが、ほとんどの場合、高レベルの制御アーキテクチャについて説明していますが、低レベルと高レベルでスケーラブルな方法で通信する方法に関する情報はまだ見つかりません。私は何か見落としてますか？

高速RTマシンを接続して、モーター制御をPC1で保証するために、TCP / IP、CAN、およびUARTを検討しました。

• TCP / IP：確定的ではありませんが、簡単に配置できます。非決定性は本当の問題ですか（とにかく遅い30Hzでしか使用されないため）？
• CAN：低速で、非常に信頼性が高く、車をターゲットにしています（ロボットでCANを使用する例がいくつかありますが、エキゾチックに見えました）
• UART：モーター制御用のRTマシンが1つしかなかった場合、UARTを検討していましたが、このポートは多くのRTxでうまくスケールしないと思います。とても使いやすい…

現時点では、私にとって明らかな解決策はありません。また、特定の信頼性が高くスケーラブルなソリューションを使用した深刻なロボットの例は見当たらないため、選択する自信がありません。

誰かがこの点または指摘する文献について明確な見解を持っていますか？ロボットで使用される一般的なまたは主流の通信ソリューションはありますか？

良い第一歩を踏み出したと思います。問題をモバイルプラットフォーム（位置の不確実性があり、ナビゲートする必要がある）とアーム（エンコーダーを介してリアルタイムで位置のかなりの確実性がある）に分割しました。

ロボットアーキテクチャに関連する論文を見てきましたが[...]、低レベルを高レベルとスケーラブルな方法で通信させる方法に関する情報はまだ見つかりません。私は何か見落としてますか？

あなたの説明から、各RTxコントローラをROSを実行しているPC1に直接結び付けようとしているように聞こえます。あなたが見逃しているのは、ROSが異なるレートでデータを生成および消費する可能性のあるアプリケーションのグループを処理するように設計されていることです。

アプリケーションに必要なのは、200HzループとROS環境間の単一のインターフェースである通信ブリッジです。つまり、各RTxコントローラーをPC1に接続する代わりに、すべてのRTxコントローラーを一緒に接続してPC1に接続します。

たとえば、I2Cバスを使用してRTxシステムをリンクし、別のRTxコントローラーを追加して「アームマスター」（AM）にします。AMの仕事は、PC1に適した形式とプロトコルの着信コマンドを受け入れ、それらのコマンドをI2Cメッセージに変換することです。次に、ROSにアプリを作成して、AMにコマンドを送信します。

I2Cでこれを行う別の方法は、PC1にI2Cコントローラーを直接配置し、ROSアプリですべてのアーム制御ロジックを記述することです。これは目標を達成するためのより合理化された方法のように思えるかもしれませんが、システムのモジュール性を削除しているため、デバッグが難しくなります。2つの簡単にテスト可能なコンポーネントではなく、1つの大きな複雑なシステムとしてトラブルシューティングする必要があります。

配線の複雑さ、決定性、および決定性のために、多数の通信ノード（センサーまたはアクチュエーター）が必要なアプリケーションは、システムバスとして実装することで恩恵を受けます（UARTやイーサネットなどのポイントツーポイントリンクとは対照的）モジュール性。

制御システムには高度な確定性が必要であり、高帯域幅チャネル（イーサネットなど）は通常貧弱です（特に、大量のスケジューリングジッターを導入する汎用OSで使用する場合、スケジューリングの確定性に関する議論については、次のリンクを参照してください））。また、アプリケーションプロセッサ（Raspberry PiのARM11など）も、リアルタイムシステムには適していない可能性があります（割り込みレイテンシや命令パイプラインなどの影響により）。ARMアプリケーションコアとマイクロコントローラのリアルタイムの動作を比較する次の詳細な説明を参照してください。

統合されたCANの可用性がUART（RS-485）やI2C（まだ）ほど普及していないのは残念です。分散センシングと作動の問題を本当に単純化できると思うからです。通常の1 Mbpsは遅いように見えますが、通常はすべてのバスメンバーのリフレッシュレートを計算すると十分です（そして、バスの長さ、インピーダンス、およびトランシーバが許可するかどうかに応じて、伝送レートを常に上げることができます）。また、最悪の応答時間を基本的に保証する素晴らしいシミュレーションソフトウェアも利用できます（たとえば、Real-at-workにはRTaW-Simと呼ばれる無料のCANバスアナライザーがあります）。そして最後に、統合されたCANを備えたMEMSセンサーの可用性はかなり低いように思われます。

アクチュエーターがバス（またはリング）として構成される別の例は、ダイナミクセルAXおよびMXシリーズで、各モーターはUARTリンクを介して次のデイジーチェーンに接続されます。これにより、アクチュエータが大量にある場合、システム設計が大幅に簡素化されます。

しかし、実際の質問に戻るために、コマンドではなくリアルタイムの設定点としてシステムを説明すると（たとえば、goto角度などのコマンドを指示するよりもむしろ連続的にモーター角度をブロードキャストする）、 200 Hzおよび30 Hzのループ。

一度に解決しようとしている2つの別個の（ただし関連する）問題があるようです。難問を小さな断片に分けましょう：

1. どのようにしてください通信、高速コントローラ（200Hzの）に遅いシステム（30Hzの）からのコマンドを、どのように私はデータが私の30Hzののシンクタンクには200Hzのバックで受信された通信を行うのですか？
2. 30Hzで何をすべきかをロボットに伝えることができるのに、200Hzで何が起きているかを制御するにはどうすればよいですか？

元の質問が指摘しているように見えるため、項目1はハードウェアで解決できます。データを200Hzでキューに入れ、30Hzでパケットを上位システムに送信できます。これはTCP / IPで行うことができますが、送信するデータの量に応じてCANで行うこともできます。ハードウェアが異なると、最大データレートも異なります。他の投稿で提案されているように、ROSのようなアーキテクチャレベルを通信ブリッジ/アービターとして機能するように追加することも役立ちます。

項目2は、ハードウェアだけでは解決できない制御理論の問題です。希望するSLAM、位置と速度の決定、およびタスクの決定は、情報を頻繁に送受信しないため、よりスマートである必要があります。おそらく2つの制御ループが必要になります。1つは200Hzで、もう1つは30Hzです。

フィードフォワード、フィードバック、およびPID制御ループをカバーする他の多くの質問がありますが、拡張性について具体的に尋ねました-ほとんどの巨大なシステムのスケーリング方法は、最小限の必要な情報があらゆるハードウェアに渡るように制御ループとロジックを階層化することですで終わる。たとえば、トップレベルのコントローラーは、1秒間に30回速度を変更せずに、より低いレベルの目標位置ポイントと平均目標速度のみを与える場合があります。