ロボット向けRTOSカーネルアーキテクチャ：スケジューリング、割り込み、ハードウェア制御

ロボットには、補正が間に合うタイミングで正しい指令が必要です。**リアルタイムOS（RTOS）**は、計測から駆動までの処理を調整します。センサー入力からハードウェア出力まで、1つの関節補正がRTOSアーキテクチャを通る流れを追います。

1. プロセッサーは高速でも、ロボットの反応が遅れる理由

四足歩行ロボットが段差を検知し、正しい補正を計算する

四足歩行ロボットが、崩れた舗装石に足を乗せます。エンコーダーが関節角度の変化を報告し、慣性計測装置（IMU）が胴体の回転を検知します。コントローラーは補正を計算しますが、その指令が関節に届く間もロボットは動き続けます。

計算が正しいだけでは不十分です。以前の姿勢を前提にした指令は、その姿勢がすでに変わった後に到着することがあります。

ロボットが必要とする時点より後に補正が関節へ届く

この例では、アクチュエーター指令をセンサーサンプルから1ms以内に適用する必要があるとします。答えを0.2msで計算できても、応答全体が収まる証明にはなりません。

平均応答時間が短くても、ときどき更新が遅れることはあります。リアルタイム制御には、経路全体の遅延を十分に抑え、安定したタイミングで実行する必要があります。ROS 2のリアルタイム解説 がこの違いを説明しています。

2. コントローラーが各ステップを調整する仕組み

CPU、メモリ、ドライバーがセンサー値を関節指令へ変える仕組み

マイクロコントローラーを使う組み込みシステムでは、CPUが計測値を読み、目標値を計算してドライバーを呼び出します。ドライバーが周辺機器を設定し、周辺機器がアクチュエーターインターフェースへ信号を届けます。

ロボットハードウェアガイド では、モーター、伝達機構、センサー、関節負荷がアクチュエーターインターフェースをどう形作るかを解説しています。

PWMドライバーはタイマーの比較レジスターに書き込めます。するとタイマーが各エッジをCPUで切り替えなくてもパルスを生成します。バスドライバーの場合は転送を準備し、DMAが補助することもあります。レジスター書き込み、転送完了、指令適用は別々の瞬間です。

命令レベルでは、メモリーマップドレジスターは周辺バスがデコードするアドレスです。CPUのストアは通常のRAM変数ではなく、ハードウェア状態を変えます。タイマーが新しい比較値を取り込むのは、次の更新境界だけの場合があります。STのタイマー・クックブック がこのプリロード機構を説明しています。CAN転送もバスの使用権を待つ必要があります。その後、ドライブが指令を適用する時点を決めます。これらの待ち時間はタスク選択の外側にあります。

一般的なMCUコントローラーの内部アドレスが違えば、役割も違う

保存フラッシュ命令と定数

作業RAMサンプル、スタック、バッファ

制御I/Oレジスター周辺機器の状態と設定

レジスターへの書き込みが物理信号になる

1. 01CPUのストア命令
2. 02タイマーの比較レジスター
3. 03PWM波形
4. 04モータードライブ

制御ピンは信号を運びます。モータードライブが動作電力を供給し、より高速な電流ループを独自に実行することもあります。Physical AIを支えるエレクトロニクス では、その周辺回路と電力経路を追っています。

各タスクには、実行スタックとTCBのためのRAMが必要です。スタックは関数呼び出しの状態と保存レジスターを保持し、TCBはそのコンテキストの場所をカーネルに伝えます。タスクがBlocked（待機）状態でも、スタック用の領域は確保されたままです。

本家のFreeRTOSでは、xTaskCreate()が設定済みアロケーターからスタックとTCBを取得します。xTaskCreateStatic()はアプリケーションが用意した領域を受け取ります。どちらもRAMを消費し、静的生成はこれらのオブジェクトのヒープ割り当てをなくすだけです。本家のFreeRTOSではスタック深さをStackType_tの要素数で指定しますが、ESP-IDFのタスク生成APIはバイト数を使います。スタックサイズを転用する前に、タスクAPI とIDFポートの違い を確認してください。

必要なメモリ容量を見ると、プラットフォームの違いが分かります。小さなFreeRTOSカーネルとLinuxシステムでは搭載するサービスが異なります。チップ選定に使う前に、それぞれの数値に何が含まれるかを比べてください。

RTOSカーネルの内部：タスク、割り込み、スケジューリングの連携

**RTOSはOSの分類です。**FreeRTOSとZephyrは、スケジューリングと同期を提供する実装です。開発者はそれらの仕組みを設定し、アプリケーションタスクを実装します。

FreeRTOSのタスクスケジューリングを追うため、ここではプリエンプティブなシングルコア構成を使います。制御タスクが新しいデータを待つ間、センシングとテレメトリーにはそれぞれ実行コンテキストを割り当てます。

カーネルは**タスク制御ブロック（TCB）**にタスク状態を保存します。pxTopOfStackが保存コンテキストの位置を示し、uxPriorityが優先度を決め、リスト項目が状態リストやイベントリストにつなぎます。RTOSコンテキストスイッチは、保存された実行地点からタスクを再開します。

切り替えが許可されると、実行可能なReadyタスクのうち最も優先度が高いものが選ばれます。高優先度タスクが一度も待機しないと、低優先度の処理が実行機会を失うことがあります。FreeRTOSのタスク実装 を参照してください。

シングルコアモデルでは、Readyリストを優先度別に管理します。キュー待ちでブロックすると、タスクはReady集合から外れ、待機タスクとして登録されます。有限のタイムアウトには遅延リストの管理も必要です。イベントやタイムアウトで再び実行候補になります。カーネルはリスト更新を保護し、割り込みが更新途中のスケジューリング構造を見ないようにします。設定によってはポート最適化ビットマップで優先度を検索しますが、すべてのチップで同じアルゴリズムではありません。

ここでセンサーがデータ準備完了割り込みを発生させます。ここから実行権が引き継がれるまでを追います。Ready（実行可能）になっても、まだRunning（実行中）とは限りません。

Cortex-M4Fポートでは、コンテキストスイッチの要求によって、低優先度例外のPendSVを保留状態にできます。ハードウェアがまず例外フレームを保存し、ポートが残りのタスクコンテキストを保存して別のTCBを選び、そのタスクを復元します。**プロセススタックポインター（PSP）はタスクのスタックを指し、ハンドラーコードはメインスタックポインター（MSP）**を使います。

ポートは次のタスクを選ぶ間にBASEPRIを上げ、カーネルデータへアクセスする可能性がある割り込み優先度をマスクします。より緊急度の高い割り込みは有効なままにできますが、対象のFreeRTOS APIを呼んではいけません。PendSVが保留されていても、実行中の高優先度ハンドラーに割り込んでタスクを切り替えることはできません。これはCortex-M4Fポート に固有の説明で、ESP32のXtensaやRISC-Vアセンブリーの説明ではありません。

プリエンプションはティックの間にも反応できます。タイムスライシングは、同じ優先度のReadyタスクをティックごとに順番に実行します。両者には別々のFreeRTOS設定スイッチ があります。

キュー、セマフォ、ミューテックスがタスクと共有資源を調整する仕組み

ここでのRTOSタスク同期には2つの役割があります。センサーサンプルを届けることと、待機中の制御タスクを起こすことです。受け渡すものの性質に合わせてカーネルオブジェクトを選びます。

サンプルが利用可能になると、待機中の受信タスクをBlocked → Readyへ移せます。次にCPUの実行権が必要です。セマフォが伝えるのは利用可能になったという状態であり、サンプルそのものではありません。ミューテックスには所有権と基本的な優先度継承があります。

FreeRTOS内部のキューは、循環ペイロードバッファー、要素数、送受信を待つタスクのリストを組み合わせます。送信は設定されたバイト数をコピーし、待機中の受信タスクを解放することがあります。セマフォはデータサイズ0の項目でキュー機構を再利用します。重要なのはペイロードバッファーではなく、カウントと待機リストです。ミューテックスは保持者も追跡し、カーネルがその所有者の優先度を一時的に上げられるようにします。キュー実装 で関係を確認できます。

3. 重要な補正が遅れる理由

Readyの制御タスクがすぐ実行できない理由

高優先度のタスクでも、実行候補でありながらCPUを取得できないことがあります。依存関係を待っている場合もあります。タスク優先度を上げるだけでは、どちらの待ちも自動的には解消しません。

クリティカルセクション、割り込みマスク、スケジューラー停止、ISR実行は、FreeRTOSを含めてタスクディスパッチを遅らせます。保護された処理に特別な「最高タスク優先度」があるわけではなく、切り替え可能な時点を一時的に制限します。

PREEMPT_RTを使わないLinuxで、ドライバーがspinlock_tを保持しているとします。有効な割り込みが高優先度の制御スレッドを起こし、再スケジューリング要求を設定できます。割り込みから戻っても、切り替え前にCPUが保護されたドライバー区間を完了しなければならないことがあります。制御スレッドはReadyですが、残りの保護処理も応答時間の予算に含まれます。

FreeRTOSのvTaskSuspendAll()は割り込みマスクとは異なります。ISRは実行できますが、スケジューラーが再開して延期された処理を扱うまでタスク切り替えが遅れます。一方、Cortex-Mのクリティカルセクションはポート固有の割り込みマスクを使います。タスクの優先度を上げても、どちらの仕組みも取り消せません。Linuxのロック規則 が、関連するスピンロックとIRQの違いを説明しています。

優先度継承をサポートするミューテックスでは、所有者が待機中の高優先度タスクの優先度を一時的に継承します。所有者が処理を終えて資源を解放しやすくなります。ただし、クリティカルな処理をなくしたり、デッドロックを解消したり、応答しないデバイスの待ち時間を制限したりするものではありません。

FreeRTOSとデスクトップLinuxの違い、PREEMPT_RTの変更点

RTOSとLinuxを比較するなら、応答経路全体を考慮する必要があります。両方のカーネルがタスク状態、優先度、プリエンプション、割り込みを管理します。違いは、設定したシステムがその経路での干渉をどう制御するかです。

**PREEMPT_RTはLinuxの構成であり、FreeRTOSの機能ではありません。**スレッド化された割り込みと優先度継承（PI）に対応したスリープ可能なロックによって、より多くのカーネル処理をスケジューラーの管理下に置きます。

一般的なスレッド化IRQ経路では、ハード割り込みの短い初期処理で原因を確認またはマスクし、その後IRQスレッドを起こします。IRQスレッドはスケジューリングポリシーと優先度に従って競合します。PREEMPT_RTは通常のspinlock_tをRTミューテックスベースの実装に変えます。ロックを待つスレッドはスリープでき、優先度継承が所有者の処理を進めやすくします。raw_spinlock_t、低レベルの入口経路、明示的に保護された領域はプリエンプト不可のままです。RTカーネルの違い を参照してください。

適切に構成したPC上のリアルタイムLinuxはロボット制御を実行できます。通常のUbuntuが厳しい期限を満たすと仮定できないのと同じく、検証していないFreeRTOSシステムも保証できません。オープンソースライセンスは、タイミングの問題とは別です。

スケジューリングで実行が許可された後でも、メモリが遅延を追加することがあります。仮想メモリでは、ページ割り当て、コピーオンライト、ファイルやスワップの読み込みが必要なため命令の実行中にページフォールトが発生することがあります。ストレージを伴うフォールトは一部だけです。一般的なMCUのFreeRTOSシステムはデマンドページングなしで常駐メモリを使いますが、割り当て、フラッシュ／キャッシュ、バス、デバイスによって処理が一時的に止まることはあります。

Linuxの制御スレッドでは、ループ開始前に重要なバッファーとスタックページを準備し、必要なマッピングに事前アクセスしてページを準備し、エラーと上限を確認しながら適切なメモリーロックを使います。mlockall()が将来の割り当てやコピーオンライトを無害にするわけではありません。PREEMPT_RT自体もページフォールトをなくしません。メモリーロックのマニュアル で制約を確認できます。

ここで補正全体の時間配分を考えます。センシング、干渉、計算、転送、出力適用に別々の上限を置き、計算を中断する高優先度処理も含めます。

待ち時間が120µsなら、この例の合計は600µsで、1,000µsの期限まで400µs残ります。待ち時間が800µsなら、固定処理が同じでも全体は1,280µsとなり、280µs遅れて到着します。これは説明用の値で、ボード上の測定値ではありません。

出力が実際に反映される時点まで測定します。スケジューラー遅延だけではドライブが指令を適用する時点は分かりません。また、1回の実行で観測した最大遅延は最悪値の証明ではありません。

4. ローカル制御から完全なロボットへ

制御ファームウェアを構築し、カスタムSDKで公開する

FreeRTOSとLinuxの選択は、センシングと動作を担うハードウェアから始まります。RAM、CPUアーキテクチャ、周辺ドライバー、タイミング要件が、その仕事を担えるソフトウェアを決めます。以下は対応ターゲットでの選択例で、各プラットフォームに2つの選択肢を示します。

センシングとフィードバック制御には、明示的な起床条件、優先度、実行時間の上限、十分なスタックを与えます。解析、ネットワーク通信、ログ、ストレージがクリティカルループの資源を保持し続けないようにします。

カーネルはスケジューリングと同期を提供します。ファームウェアは制御動作とドライバーを提供し、カスタムSDKが指令と測定状態を公開します。

先ほどの割り込み引き渡しを、小さなFreeRTOSパターンで表します。要素数1のキューで最新の完全なサンプルを保持します。割り込みを有効にする前にキューとタスクを作成し、上限を定めたハードウェア経路でサンプルを取得します。

void sample_isr(void) {
  BaseType_t wake = pdFALSE;
  Sample s = read_ready_sample();
  xQueueOverwriteFromISR(
    sample_q, &s, &wake);
  portYIELD_FROM_ISR(wake);
}

void control_task(void *arg) {
  Sample s;
  for (;;) {
    xQueueReceive(sample_q, &s,
                  portMAX_DELAY);
    Target t = target_snapshot();
    Command u =
      control_step(s, t);
    actuator_write(u);
  }
}

ISRは完了したサンプルをコピーし、必要なら切り替えを要求します。タスクはCPUを消費せずに待機し、整合性のある目標値のスナップショットを読み、次の出力を計算してドライバーを呼びます。複数フィールドの目標は、メッセージパッシングまたは上限を定めたタスクレベルのロックで整合性を保った状態でまとめてコピーし、遅いI/Oの間はロックを保持しません。

周期ループでは、相対遅延を繰り返して処理時間を積み上げるのではなく、適切なタイマーやxTaskDelayUntil()を使います。ティック分解能は周期に合っていなければならず、ティック未満の要件には適切なハードウェアタイミング源が必要です。

既存のカーネル設定項目を使って、configUSE_PREEMPTION、優先度範囲、割り当て方式、スタックサイズを設定します。続いてタスクと同期を実装します。通常はReadyリストの選択を自分で書くのではなく、スケジューラーを設定して移植します。対応するデュアルコアESP-IDF構成でESP32上のFreeRTOSを動かす場合、スケジューラーはコアアフィニティーも考慮します。タスクを固定しても共有メモリやバスは分離されず、ローカル割り込みマスクで他方のコアを止めることもできません。共有データにはターゲットがサポートするコア間同期が必要です。

単位、受け入れ範囲、タイムスタンプ、シーケンス番号、確認応答、鮮度、タイムアウト動作を定義します。受信したことは、物理的に実行された証拠ではありません。

通信境界では、フィールド幅、バイト順、フレーミング、必要な完全性チェックを含むシリアライズを明示します。ホストによってパディングが異なる可能性のあるC構造体をそのまま送らないでください。コントローラーはパケットを検証し、完全な目標を公開し、実際に適用したシーケンスを報告します。タイムアウト時には、機構に適した保持、減速、故障応答を定義して選択できます。SDKは受信を動作の成功と混同せず、その状態を公開すべきです。

カスタムロボットでは、センシングとアクチュエーター統合とともに、これらのインターフェースの範囲を定めます。VoicePingのカスタムロボット開発 は、タスクと動作環境から始まります。

**カーネルが製品プラットフォームになる仕組み。**カスタマイズはカーネルポート、アプリケーションファームウェア、外部SDK境界のいずれでも行えます。独自のコントローラーを作るために、企業がスケジューラーを書き直す必要はありません。

Espressifはハードウェア固有のFreeRTOS実装と統合を文書化しています。BitcrazeのCrazyflieは別の一般的な構成を示しています。FreeRTOSタスクを使い、センサーから推定器、コントローラー、モーターへ至るパイプラインを追加します。安定化のドキュメント とファームウェアソース でアプリケーション層を確認できます。

Unitreeは公開インターフェース層の例です。SDK2 Go2の例 は低レベルのモーター指令を公開し、状態を購読します。Python SDKはCyclone DDSを文書化 しています。これは拡張可能なロボットインターフェースを示しますが、非公開の関節コントローラーがFreeRTOSを使うことを示すものではありません。文書化されたSDKの動作と、内部ファームウェアへの推測を分けて扱います。

四足歩行ロボットやドローンでローカルRTOS制御とROS 2を接続する

このコントローラーをロボット全体の構成に組み込みます。ホストが動作を計画する間、ローカルコントローラーがフィードバックループを閉じ、関節ドライブが電流を制御します。各ループはタイミングを検証できる場所に割り当てます。

四足歩行ロボットの構成例必要な時間条件を満たせる場所に各ループを置く

目標値 →← 実測フィードバック

ホストLinux + ROS 2動作を計画

コントローラーローカルRTOSフィードバックループを実行

関節ドライブドライブのファームウェア電流と電力を制御

**ROS 2はミドルウェアであり、RTOSはOSカーネルまたはプラットフォームです。**役割が異なり、組み合わせて使うことが多くあります。選択したループを適切なLinux/PREEMPT_RTホストで実行することもできます。ROS 2のリアルタイム設計の議論 がアプリケーションレベルの制約を説明します。

Linuxはプロセス、カメラ／ネットワークドライバー、ロボットライブラリー、デプロイツールを提供するため、ホストに適しています。PREEMPT_RTはそのプラットフォームを保ったままカーネルの応答性を高めます。ROS 2のコールバックにも適切なエグゼキューター／スレッドポリシー、上限を定めた処理、準備済みメモリが必要です。RTカーネルだからといって、すべてのコールバックが自動的にリアルタイムになるわけではありません。FreeRTOSはローカルファームウェア向けの小さな実行環境であり、ホストのLinuxソフトウェア全体を置き換えるものではありません。

**カーネルより先にタイミング要件を決めます。**ビジョンやマッピングのホストは、別のMCUが高速ループを閉じる間、スループットと幅広いドライバースタックを必要とする場合があります。厳しい制御期限をLinuxホストが直接担うなら、適切なリアルタイム構成とエンドツーエンド検証が必要です。PCはPREEMPT_RTを実行できますが、通常のデスクトップ処理に同じ厳しいレイテンシー目標が必要とは限りません。

これらのコストはワークロードに依存します。IRQスレッドと優先度継承ロックは管理処理を増やし、CPU配置とドライバーの前提を見直す必要があります。深いスリープや周波数変更を無効にすると、応答時間と引き換えに電力効率が下がることがありますが、これはPREEMPT_RTの自動的な効果ではなく調整の選択です。Canonicalのレイテンシーガイド が実務上のトレードオフを説明します。CPUを占有し続けるリアルタイムスレッドは、非RTカーネルでも他の処理から実行機会を奪うことがあります。

この共存は開発者調査にも表れます。以下の2つのカテゴリは異なるハードウェア役割を扱っており、どちらもベンチマークでも特定MCUへの推奨でもありません。

「制約がある」という言葉は、アプリケーションに使えるRAM、フラッシュ、CPU、電力、I/Oの範囲に照らして捉えます。ESP32クラスのコントローラーとLinuxエッジコンピューターでは制約が異なります。調査でLinuxの利用率が高くても、デスクトップLinuxがESP32に合うことは示しません。実際のボードで、メモリ容量、MMU対応、ドライバー、測定したループ時間を確認する必要があります。

同じ構成はドローンの安定化にも使われます。対応するフライトボードでは、PX4は一般にNuttXを使い、多くのSTM32ターゲットでArduPilotはChibiOSを使います。PX4フライトスタック概要 、システムアーキテクチャ 、ArduPilot移植ガイド を確認してください。

四足歩行ロボットに戻る

これで、段差への補正が関節に届くまでを追えます。カーネルは実行順序を管理しますが、間に合うかどうかを決めるのは計測、制御、駆動の経路全体です。

次のコントローラーでは、1つのセンサーイベントを物理出力まで追跡します。期限を明示し、各待ち時間を計上し、出力が反映される時点までハードウェアで検証してください。

そのコントローラーをアプリケーションに展開するには、VoicePingのロボット開発アプローチ を確認し、ハードウェア、制御インターフェース、受け入れ基準を一緒に定義してください。