OS の選択が「ヒューマノイド ロボット」の制約によって決定される可能性は低く、特定の「ヒューマノイド ロボット OS」は存在せず、そのようなロボットの高さによって OS が決定されることはありません。;-) ! 重要な要因は次のとおりです。
- リアルタイムの制約 (モーション コントロールのPID更新、センサー/アクチュエーターの反応時間など)
- プロセッサ アーキテクチャ
- システム アーキテクチャ (例:分散処理、対称マルチプロセッシング)
次のような他の要因が重要な場合があります。
- 通信および I/O 要件 (イーサネット、TCP/IP、USB、WiFi など)。
- ファイル システムのサポート
これらはすべての場合において必ずしも OS の本質的な部分である必要はありませんが、サードパーティのプラットフォームに依存しないライブラリが多くの場合に利用可能であるため、それらが必要な場合は、OS との統合が役立つ場合があります。スレッドセーフとリソースのロックを自分で行います。
あなたが提案したオプションのどちらも、私のリストに入る可能性は低い.
Linux ベースのものはすべて MMU を必要とします (uCLinux またはその派生物を使用する場合を除きますが、組み込みシステムで Linux を使用する数少ない正当な理由の 1 つは MMU サポートです)。Linux はリアルタイム OS を意図したものではなく、Linux のリアルタイム サポートはほとんど後付けであり、真の RTOS ほど決定論的であることはめったにありません。FreeRTOS や uC/OS-II などの RTOS カーネルが必要とするのは約 4Kb だけですが、Linux は起動するだけでもかなりのメモリ リソースを必要とし、使用可能なものには最低 4Mb の RAM が必要です。ここではチョークとチーズを比較しています。つまり、ファイル システムやネットワーク サポートなどの Linux ベースの OS のユーティリティはありません (ただし、これらはスタンドアロン ライブラリとして追加できます)。
コグニティブ機能と同じプロセッサでモーション コントロールおよびセンサー/アクチュエータ機能を実行する場合は、決定論的な RTOS が必要です。ただし、プラットフォームが、モーション コントロールやその他のリアルタイム センサー/アクチュエータ I/O を処理する個別のプロセッサを備えた分散システムである場合は、単純な RTOS カーネルを使用するか、I/O プロセッサに OS をまったく使用しないで済む可能性があります。 (これは、より小さく、より強力でないプロセッサでもあります) と、コグニティブ (意思決定および計画) プロセッサの GPOS です。
私は最近 FreeRTOS を評価しました。これは最小限で、シンプルで小さく、基本的なスレッド化、タイミング、および IPC メカニズムのみを提供し、他にはほとんどありません。それは機能しますが、商用および非商用の両方で、他の多くのより魅力的なオプションも機能します. これをKeil の RTX カーネル(同社の MDK-ARM ツール スイートに含まれています) および商用のSegger embOSと比較しました。他の 2 つの候補よりもコンテキスト切り替え時間が大幅に遅くなります (ただし、72MHz Cortex-M3 ではまだマイクロ秒単位であり、Linux で達成できる可能性が高いものよりも高速です)。
uC/OS-II は適切に設計され、文書化されており (Jean Labrosse の本)、RTOS がどのように機能するかを知りたい場合に最適です。その最大の欠点は、非常に制限的な優先度スケジューリング スキームです。これは、非常に小さなターゲットに対しては効率的ですが、希望するほど柔軟ではない可能性があります。各スレッドには個別の優先度レベルを割り当てる必要があるため、非リアルタイムのバックグラウンド タスクに役立つラウンド ロビン スケジューリングはサポートされていません。uC/OS-III ではその欠点が修正されていますが、他の多くのオプションも修正されています。
ターゲット プロセッサに MMU が搭載されている場合は、各スレッドまたはプロセスが他のスレッドまたはプロセスから保護されるような方法で MMU をサポートする OS を使用することを強くお勧めします。システムははるかに堅牢でデバッグが容易になります。チーム。そのような OS では、そうでなければ非決定論的で一般的にデバッグが困難な結果で他のスレッドのリソースを踏みにじる誤ったタスクは、代わりに例外を引き起こし、おそらく後で破損したデータが取得されたときではなく、エラーが発生した場所で停止します。使用済み。
おそらく、無料またはオープンソースの RTOS に制限する必要はありません。多くのベンダーは、教育や評価のために無料で使用することを許可しています。QNX Neutrinoを検討することを強くお勧めします。これは、非営利目的および学術目的での使用は無料で、RTOS で利用可能な最も堅牢な組み込み MMU サポートを備えており、Eclipse ベースの Momentics IDE を含む必要なすべての開発ツールが含まれています。これは、完全な OS に期待されるすべてのサービスのサポートを含む、単なるスケジューリング カーネルではありません。ARM、x86、SH-4 PowerPC、および MIPS アーキテクチャで動作します。x86 での実行は特に便利です。これは、デスクトップ上で実行されている VMでテストおよび評価し、多くのコードを開発することさえできることを意味するためです。
単なるスケジューリングと IPC を超えた OS サービスをサポートしながら、真のハードリアルタイムであるもう 1 つの代替手段は、eCosです。. ネイティブの POSIX および uITRON API、CAN、ADC、SPI、I2C、FLASH、PCI、シリアル、ファイルシステム、USB、PCI などの標準ドライバーを備えており、TCP/IP ネットワークのサポートが含まれています。その意味では完全な OS ですが、Linux とは異なりモノリシックではありません。スケーラブルでアプリケーション コードに静的にリンクされるため、使用しない機能はランタイム バイナリに含まれません。ARM、CalmRISC、Cortex-M、FR-V、FR30、H8、IA32、68K/ColdFire、Matsushita AM3x、MIPS、NEC V8xx、PowerPC、SPARC、および SuperH で動作します。理論的には、PC 上の VM で IA32 (x86) ポートを実行して高レベル コードのテストと開発を行うことができますが、QNX のすぐに使える評価とは異なり、自分で動作させる必要があります。
以下に関して追加：
オペレーティング システム全般についての知識はほとんどありません。まずそれらについて学ぶ必要がありますか。「はい」の場合、このテーマの短い入門書として適切なものは何ですか?
その場合、Linux の学習を開始する時期ではない可能性があります (Linux には、広く親しまれていることとコミュニティ サポートがあるという利点がありますが、必要のないものがたくさんあり、利用可能なサポート リソースの多くはリアルタイムに慣れていません。制御システム アプリケーション。
Labrosse の uC/OS-II ブックの第 2 章では、uC/OS-II だけでなくほとんどの RTOS に適用可能なスケジューリング、同期、IPC などの RTOS の概念の概要を説明しています。EETimesの Jack Ganssle の最近のRTOS Fundamentalsコースで同様の資料が提示されています (Mircium が後援し、ケーススタディとして uC/OS-II を使用しているため、おそらく類似していますが、大部分は同様に一般的です)。
どの教科でもすぐに始めるための私の解決策は、その教科の後に「101」を付けて Google で検索することです (学界で一般的な入門コース番号)。 「RTOS 101」は、確かにさまざまな品質のいくつかの出発点を提供します。ソースの評判を確認してください。それが企業の場合、特定の製品を販売している可能性があります。愛好家の場合、いくつかの洞察があるかもしれませんが、おそらく視野が狭く（多くの場合、特定のお気に入りのハードウェアに関連する）、学術論文のように厳密ではない場合があります。
CONFIG_PREMPT_RT に関して追加:
Linux をハード リアルタイム OS にするわけではありません。一部のアプリケーションに適している場合があります。PID モーション コントロール (専用のコントローラーや別のプロセッサを使用するのではなく)、または閉ループ フィードバック コントロールを使用している場合、このパッチは私の意見では、少なくとも確実ではありません。私はこれを見つけました:
リアルタイム Linux アプローチの比較。CONFIG_PREMPT_RT など、リアルタイム アプリケーションで Linux を使用するためのさまざまなアプローチについて説明します。これらについては、パート C で詳しく説明します。