非常に短い答え:2
センサー
センサーからの読み取りをすべて1つのノードで行うか、個別に行うかについては、次の質問を自問する必要があります。
センサーは他のセンサーなしでは意味がありませんか?
この質問は、センサーが密結合しているかどうかを尋ねます。たとえば、温度に敏感なセンサーがあるとします(そしてそれを補正する必要があります)。温度センサーを追加して、主に他のセンサーの値を修正します。このシナリオでは、両方の値が密結合されているため、両方の値を同時に読み取るのが理にかなっています。実際、温度センサーからの読み取り値がなければ、元のセンサーからの読み取り値は役に立ちません。
一方、センサーが個別に役立つ場合は、必ず別のノードにセンサーを保管してください。これには多くの利点があります。
- ノードは別々のプロセッサで実行できます
- ノードは将来のロボットで再利用できます
- 1つのノードとの通信に失敗しても、システム全体がダウンすることはありません
- 故障したセンサーボードからの取得の再開は、他とは別に行うことができます
実際、もしあなたが 上記の利点のいずれ必要な場合、センサーが密結合されている場合でも、別々のノードする必要がありますが、通常は発生しません。
アクチュエータ
これは類似しています。
アクチュエーターは、他のものがなければ意味がありませんか?
たとえば、ロボットの腱で手首を設計している場合で、各腱について(何らかの理由で)2つのモーターが同時に動作して関節を一方または他方の方向に動かし、同じノードで提供することでより多くのことができます別よりも感覚。
一方、アクチュエーターが独立している場合(一般的な場合)、各アクチュエーターに1つのノードがあることが理にかなっています。その場合、それぞれを異なるノードに配置できます。センサーとまったく同じ利点に加えて、この追加の利点があります。
- 何らかの理由でアクチュエータが停止した場合、他のアクチュエータは引き続き機能します。冗長な自由度がある場合、完全に補償することさえできます。
これには1つの意味があります。アクチュエータが調和して動作する必要がある場合は、同じノードに配置します。これは、単に通信障害が原因ではなく、ノードが異なると遅延が異なるためです。分散システムでは、各ノードはネットワークの異なる部分にあるため、遅延の差があります。集中型システムでは、各プロセスの高CPU負荷で異なる遅延が発生しますでは、スケジューリング運します。
ハンドラーが必要ですか?
答えは「依存する」ですが、多くの利点を備えた一般的なアプローチがあります。名前を変更して、「コントローラー」と呼びましょう。アプローチは「はい、コントローラーが必要です」です。
コントローラーを使用する利点は(多くの場合)です。
- 分離処理:各ノードは、次のことを意味する1つのことを担当します。
- 簡易性:暗示
- より簡単な開発
- 簡単なデバッグ
- 少ないエラー
- 失敗の可能性が少ない
- 再利用性:同じ機能(メッセージとサービスの形式)を持っている場合、異なるセンサーノードで同じコントローラーを使用できるため。
- 個別のハードウェアでの実行:各ノードはネットワーク内で移動できます。たとえば、センサーおよびアクチュエータノードを専用のマイクロコントローラー(Arduinoたとえば(推奨しません))とPCのコントローラーに。
- 極端なさを避けてください:センサーがアクチュエータに直接影響を与えたい場合、結果は単に混乱です。コントローラがないと仮定して、それぞれのケースを見てみましょう。
- 1つのセンサーノード:基本的に、これはセンサーノードとコントローラーが同じノードにまとめられることを意味します。それほど悪くはありませんが、非常に不必要です。
- 多くのセンサーノード:これは混乱です。これは、コントローラーがセンサーノードに分散されることを意味します。そのため、すべてのセンサーノードは、それぞれに関連付けられたアクチュエーターを制御する方法を知るために互いに対話する必要があります。通信の失敗またはさまざまな種類の遅延を想像すると、それがどれほど困難になるかがわかります。これはまったく不要であるため、実行する理由はありません。
これらには、欠点もあります。より多くのノード(コントローラーだけでなく、任意のノード)があるということは、次のことを意味します。
- より無駄な通信:データはネットワークまたは共有メモリを介して標準形式で移動する必要があるため(シリアル化および非シリアル化)、ROSコアはそれらを見て、誰に配信するかなどを決定する必要があります。コミュニケーション中。すべてのノードが1つにある場合、そのコストはゼロである可能性があります。
- 障害の可能性が高い:何らかの理由でネットワークリンクがダウンした場合、またはノードが停止した場合、システムに障害が発生します。準備ができていない場合、システム全体がダウンする可能性があります。現在、これは実際にはシステムの一部ではなくすべてを失うことができるのは一般に良いことですが(グレースフルデグラデーション)、できるだけ回避する必要があるアプリケーションもあります。通信を切断し、すべてのコードを1つのノードに配置すると、実際にはシステムの安定性が向上します。マイナス面はもちろん、システムが正常に動作するか、突然完全に停止します。
- 混timingとしたタイミング:各ノードは独自に実行されます。メッセージが他の人に届くまでにかかる時間は非決定的であり、実行ごとに異なります。ノードが各メッセージにタイムスタンプを付けない限り(副次的注意として:ROSは同期クロックをかなり同期する必要があります)、各受信ノードが遅延を考慮して適切に制御できない限り(これは非常に難しいタスクです)それ自体で)複数のノードを持つことは、データの年齢に関する高い不確実性を意味します。これは、実際、ほとんどのロボットの動きが非常に遅い理由の1つです(多数あります)。それらの制御ループは、すべてのデータが現在の期間に対応することを確認するのに十分に遅くなければなりません。遅延が大きいほど、制御ループが遅くなります。
上記のすべての欠点において、解決策は、ノードの数を、できれば単一のノードに減らすことです。ROSを使用しなくなったので、ちょっと待ってください!丁度。
要約する:
- 遅延が散発的に大きくなる可能性がある非リアルタイムシステムにはROSを使用します。その場合は、自由にROSノードを好きなだけ持つことができます。実際、各ROSノードにたった1つのことを実行させるのは非常に良い習慣です。そうすれば、それらは非常にシンプルになり、非常に再利用可能になります。
- 一方、リアルタイムシステムの場合は、必ずROSを避けてください。あることについてはorocos様および技術のEtherCAT少なからずとは、アドホックソリューション。
最後の言葉として、実際にはROSはうまくいきます。素晴らしくはありませんが、結構です。多くの場合、システムは重大ではなく、障害の可能性は非常に小さいため、時々再起動することは大したことではありません。これはダチョウのアルゴリズムです!