ロボット工学のリアルタイムプログラミングはどれくらい成熟していますか？[閉まっている]

編集：理由はわかりませんが、この質問は多くの人を混乱させるようです。いつ/どこで/なぜ/どのようにリアルタイムを使用するかを知っています。リアルタイムのタスクを持っている人が、リアルタイムでそれを実装するのに実際に十分気にするかどうかを知りたいです。

ロボットにとってリアルタイム操作が重要である理由を述べる必要はありません。私の質問は、ロボット工学で実際にどのくらい使われているのですか？

この質問を例に考えてみましょう。リアルタイム機能を備えたプラットフォームについて言及している回答は1つだけであり、トップからはほど遠いものです。ROSは明らかに、リアルタイムではない非常に人気のあるプラットフォームです。

ただし、リアルタイムの世界では、RTAI ¹が唯一の実行可能な無料のリアルタイムプラットフォームです。ただし、Linuxに限定されており（問題はありません）、文書化が不十分で、ゆっくりと開発されています。

それでは、ロボット工学の開発者の間でリアルタイムの振る舞いはどれくらい求められていますか？問題は、リアルタイムの振る舞いが実際に必要なときに、開発者がリアルタイムアプリケーションを作成する傾向があるかどうかです。それほど多くない場合、なぜですか？

たとえば、触覚データに基づく反射行動は、リアルタイムプロパティを失うため、ROSを通過できません。しかし、人々は本当にリアルタイムソリューションを考え出しますか、それともリアルタイムプロパティを無視してROSを使用しますか？

¹または同様のXenomai

あることを覚えておいてくださいリアルタイムにしてありますリアルタイムで。

ハードリアルタイムをハードウェアサポートまたは低レベルのソフトウェアサポートなしで実現することは困難ですが、ハードリアルタイムに対応するためにすべてが必要なわけではありません。ソフト＆ファームリアルタイムレスポンスは、はるかに簡単に実現でき、多くのアプリケーションでは十分すぎる場合があります。

また、システムの異なる部分には、非常に異なるリアルタイム要件があります。ソフトウェアPIDループを実行している場合、実際にはハードリアルタイムの応答が必要です（たとえば、PIDをソフトチューニングするか、ハードチューニングして、時々不安定になるかを選択する必要はありません）。ビジョンシステムには、リアルタイムの応答要件が定められている場合があります。次の決定に間に合うように画像を処理できない場合、パフォーマンスは低下しますが、システムの実行を妨げる必要はありません。この場合、時間内に処理できない場合部分的な結果を捨てて、次のフレームで分析を開始する時間を失うことはありません。最後に、全体的な計画と調整（おそらく最も複雑なロボットシステムの一部）は、ソフトリアルタイムの領域にしっかりと留まることがよくあります。

Windows PCの分野でも、リアルタイムのハードパフォーマンスを得ることができます。カーネルに適切なフックを備えた適切なソフトウェアが必要です。BeckhoffのTwinCatソフトPLCは、Pentiumのマシンサイクルの半分をスライスし、残りの半分をWindows NTに提供することで、非常に喜んで高スキャンレートのPLCを実行しました。AerotechのA3200シリーズのオプションのような最新の制御システムでも、ホストPC上で低レベルのカーネルは、ハードリアルタイム要件に必要なだけのCPU時間を消費し、残りのCPUサイクルをWindows 7に残します使用する！

リアルタイムシステムは、多くの（ほとんどの）ロボット制御システムに実際には必要ありません。十分に速く、十分に低いジッターで実行され、あまり多くのサイクルを逃さない制御ループがある限り、これはロボット制御とサーボ制御に非常に適しています。

この証拠として、PR2とシャドウロボットハンドを紹介します。

このロボットには約20の自由度があり、そのすべてがROSのメインループによってサーボ制御されています。また、20個のDOFに加えて、触覚センサーやその他のセンサーの配列を備え、ROSのメインループを介してサーボ制御されるShadow Robot Handはどうでしょうか。

ROSのメインループには、わずかなジッター、時には100us程度のジッターがあり、サイクルを完全に見逃すことさえあります。しかし、サイクルの99.9％が正常に実行されるかどうかは関係ありません。

ホストPC内で多くのコアを使用するということは、1つのコア全体がメインループの実行専用であるため、他のタスクによって遅延されることはほとんどありません。

ロボットシステムにリアルタイムOSを使用する主な理由は、安全のためです。ロボットが安全上重要な状況で動作している場合、100％の制御稼働時間を保証するのはお客様の責任であり、その一部はリアルタイムの性質を保証することです。

リアルタイムOSを使用するかどうかに関係なく、制御ループが完全に停止した場合、サーボは安全に動作するはずです。この安全システムは、まれに非リアルタイムOSが1サイクル以上スキップする場合にも役立ちます。たとえば、シャドウハンドでは、制御ループが20サイクル（20ms）を超えるとモーターが停止します。私はこれが起こるのを見たことがありません。

追加しました

それについて考える別の方法はこれです：あなたのサーボシステムは実際にどの更新レートを必要としますか？腕が大きく、超高性能、高速位置決めが必要ない場合は、500Hzで十分です。周りを運転するには、おそらく200Hzで十分です。どちらの場合でも、ループが実際に1000Hzで実行されている場合、制御アルゴリズムがループ間の実際の経過時間を考慮する限り、サイクルの遅れや欠落はまったく問題ありません。

ソフトウェアの目的は、厳密にリアルタイムである必要があるかどうかを決定します。

目的が経路計画またはローカリゼーションである場合、多くの場合、10Hzなどの低周波数で十分です。これらの場合、Linux上で実行されるプレーヤー/ステージのセットアップは問題ありません。1つのタイムステップが少し長くても短くても問題はほとんどないことがわかります。

ロボットのダイナミクスが速い場合、厳密にリアルタイムの動作が必要です。たとえば、ロボットアームを動かして位置を追跡したり、オブジェクトを処理/グリップしたり、移動したりします。タイムステップを逃した場合、位置が望ましくなくオーバーシュートする可能性があり、より予測可能な動作が必要になる場合があります。この場合、最大1kHz以上の周波数があります。オペレーティングシステムを使用する場合、リアルタイムのオペレーティングシステムが必要です。

タイマーおよび割り込み（マイクロコントローラーでコンパイルされたCコード）を使用することにより、組み込みアプリケーションでリアルタイムの動作を実現できます。この場合、通常のサンプリング周波数を維持できるように、処理負荷が高すぎないようにする必要があります。

コンピューター/マイクロプロセッサーを使用するロボット（より多くの処理能力が必要なため）は、リアルタイムのオペレーティングシステムを使用して高いサンプリングレートを保証する必要があります。

したがって、リアルタイムの動作が必要かどうかは、開発者がそれを使用する目的によって異なります。

当社は、PICマイクロコントローラーで動作するFreeRTOSを使用してロボットを構築しています。私たちにとって、FreeRTOSを使用する主な理由は、タスクの優先順位の再配置の容易さ、複数の通信回線の同時処理、割り込みハンドラーとメインタスク間の容易な通信です。マイクロコントローラーは、私たちが生産する各ロボットに完全なLinuxマシンを搭載するよりもはるかに安価です。

実際にリアルタイムが必要な場合は、リアルタイムオペレーティングシステムを使用します。安全監視、データ収集、および一定サンプルレート制御ループは、リアルタイムスケジューリングを使用する一般的なサブシステムです。

プログラミングのリアルタイム部分は通常、可能な限り小さくなります。これは、デバッグがより難しく、正確性をチェックするのが簡単なコードが少ないためです。リアルタイムOSのドキュメントは通常、かなり優れています（RTAI / Xenomaiを含む）。

QNXとRTAI-> Xenomaiをさまざまな実際のロボットプロジェクトで使用しました。私はQNXを好みましたが、Xenomaiも同様に効果的でした。

Orocosは、成熟したリアルタイムロボット制御ソフトウェアフレームワークです。ハードリアルタイムの要件で高速ロボットマニピュレーターを正常に制御するために使用されるのを見てきました。ROS、通信、構成、シリアル化、コンポーネントベースのパッケージングと同じフレームワークレベルのコンポーネントが多数あります。

複数のCPUとリアルタイムの質問シフトの観点からロボットについて考え始めます。2輪バランサー、クアッドコプタースタビライザー、サーボパルス出力など、高速で信頼性の高いフィードバックを必要とするアルゴリズムがある場合、リアルタイムが非常に重要ですが、タスクも非常に制約されます。

このような制御ループを、Arduinoクラスのデバイスにある安価な8ビットAVRやローエンド32ビットARMなどの専用リアルタイムCPUにオフロードできます。専用の制御ループを実行するこれらの小さなMCUを何十も追加することを妨げるものは何もありません。USBデバイスの列挙によってこれも簡単になります。

タイミングに敏感な制御ループが専用CPUによって処理されるようになったので、LinuxのROSやKinect for Windowsなどのコンポーネントを使用してハイエンドロジックを実行できるロボットの「頭脳」のリアルタイムニーズを緩和できます。

「いつ/どの場合に」リアルタイムシステムが使用されるかに対する応答として：

私の経験では、モーションコントロールはリアルタイムシステムのメインアプリケーションです。モーターを制御するには、高周波（100hz、1000hzなど）と低ジッター（時間変動）が重要です。ここでは安全性が大きなポイントです。人間の中のロボットを考えてみましょう。たとえば、特定の時間枠/距離でロボット（腕）が停止することを確認する必要があります。

パスプランニングなどの他のタスクでは、ビジョン処理とリアルタイムシステムの推論はそれほど重要ではなく、開発時間とハードウェアコストのオーバーヘッドのために回避されることがよくあります。

現在、PR2などの大型ロボットは両方の世界を組み合わせています。RT対応オペレーティングシステム（Linux + Xenomaiなど）のリアルタイムコンテキストでは、モーションコントロールが行われ、非リアルタイムパート（ユーザーランド）では、ビジョン処理と計画がROSなどのシステムに組み込まれています。どちらも同じコンピューターで実行できます。

質問が明確になったら、この回答を編集させていただきます。:-)

はい、ハードウェアリソースがタイミング要件（十分な処理能力、十分に低いレイテンシー）を満たすことができると仮定すると、スケジューラーがプロセスとスレッドを適切にシーケンスできない場合、リアルタイムスケジューラーを使用します。これは通常、これの課題。ハードウェアドライバーは、リアルタイムの状態に合わせて最適化することもできます。

はい、必要な時間の制約内でソフトウェアが仕事をすることが保証できない場合、リアルタイムのアプローチを使用します。

1つの良い解決策は両方を行うことです。私が使用する設計では、小型のマイクロコントローラー、タイトなサーボ制御ループなどに「ハード」リアルタイム機能を配置しています。次に、別のより大きなCPUがあり、LinuxとROSを実行しています。ROSに高レベルのタスクを処理させ、uPにステッピングモーターの制御やPIDループの実行などを処理させます。

上記で他の人が言ったように、非リアルタイムOSで1KHzの制御ループを実行できますが、これが機能するには、アイドルループでほとんどの時間を費やす、過剰なサイズのコンピューターが必要です。Linux / ROSコンピューターをほぼ100％のCPU使用率で実行すると、リアルタイムのパフォーマンスが低下します。2層設計を使用すると、常に非常に優れたRTパフォーマンスを得ることができ、小型で電力消費の少ないコンピューター（おそらくPi2の高レベルのタスク）を使用できます。現在、uPはOSを実行していませんが、FreeRTOSに移行しています