本記事は、ROSCon JP 2026にてティアフォーのエンジニアである矢野篤志が行った講演内容をまとめたものです。
CIEの設計詳細や性能評価は、リアルタイム系トップカンファレンスであるRTAS 2025に採択された論文「Work in Progress: Middleware-Transparent Callback Enforcement in Commoditized Component-Oriented Real-time Systems」にまとめられています。論文のプレプリントはarXivで見ることができ、IEEEでも公開されています。
実装はGitHubで公開されており、導入手順を解説した公式ドキュメントも整備されています。
なお、CIEの設計と動機については、昨年のROSCon JP 2025でも発表しています。今回の講演は聴講した方が昨年の発表を見ていない前提で構成されており、設計の振り返りは短くまとめ、「CIEをどう使うか」というハンズオンに重点を置いています。
まず前提として、ROS 2アプリケーションの構造を簡単に説明します。ROS 2アプリケーションは、機能単位であるNodeの集合体として構成されます。各Nodeは複数のCallbackを持ち、CallbackはSubscribeしているTopicからメッセージを受け取って処理を実行し、次のTopicへメッセージをPublishします。このPublish/Subscribeのリレーによって、システム全体として複数のデータフローが形成されます。つまり、ROS 2アプリケーションの実体は「複数のCallbackで構成されるデータフロー」です。
このCallbackがいつ・どのCPUコアで実行されるかは、実は2つのスケジューラによって二重に決定されています。
一方、LinuxをはじめとするPOSIX系OSには、スケジューラーの振る舞いを制御するために各スレッドに対してScheduling Attributes（Policy・Priority・Affinity）を設定できます。代表的なPolicyは次の3つです。AffinityはそのスレッドがスケジューリングされるCPUコアを設定できます。
|
Policy |
設定できる属性 |
概要 |
|
EDFスケジューラ （SCHED_DEADLINE） |
runtime / period / deadline |
最も早くdeadlineが来るスレッドを優先する。 |
|
FIFOスケジューラ （SCHED_FIFO） |
priority（99〜1） |
priorityが最も高いスレッドを優先。priorityが同じならFIFO。 |
|
CFS（※Linux kernel version 6.6以降ではEEVDF） （SCHED_OTHER） |
nice（-20〜19） |
すべてのスレッドへのCPU割り当て量をなるべく均等にする。デフォルトのPolicy。 |
問題は、ROS 2標準のExecutorを使う限り、このScheduling AttributesをCallback単位で設定できず、スケジューリングによる最適化が困難であることです。SingleThreadedExecutorは1つのスレッドが複数のCallbackを担当するため、Callbackごとに独立した設定を与えられません。MultiThreadedExecutorはスレッドプール内の複数のスレッドがCallbackへランダムに割り当てられるため、特定のCallbackに特定の設定を効かせることができません（※最近追加されたEventsExecutorはTimer Callbackのリリース遅延を減らすといった別の目的で実装されており、この問題を解決するものではありません）。この構造こそが、ROS 2アプリケーションに対するスケジューリング最適化を阻んできた要因です。CIEはこの問題を解決します。
CIEの設計の核は、CallbackGroupとOSスレッドの間に永続的な一対一対応を構築することです。各CallbackGroupに専用のOSスレッドが与えられるため、そのスレッドにScheduling Attributesを設定すれば、それはそのままCallbackに対する設定になります。ミドルウェアレイヤーのスケジューリングを考慮する必要がなくなり、二重スケジューリングが解消されます。
Scheduling Attributesの設定は、システム全体で1つのYAMLファイルを書くだけで完了します。YAMLフォーマットは自動生成され、ユーザは各プロパティを埋めるだけで済みます。生成方法は後述のハンズオンで説明します。
このYAMLファイルを読み込み、CIEのスレッド群へ実際に設定を反映するのがThread Configurator Nodeです。Thread Configurator Nodeは、nice(2)、sched_setaffinity(2)、setpriority(2)、sched_setscheduler(2)といったシステムコールを用いて、各スレッドのScheduling Attributesを設定します。
CIEの仕組みの全体像
CIEの設計詳細や性能評価に興味のある方は、前述のRTAS 2025論文を参照してください。
ここからが本記事のメインです。サンプルアプリケーションを使って、CIEのインストールからLinuxスケジューリング適用までを6つのステップで説明します。同等の説明は公式ドキュメントにも記載されています。
CIEはCallbackGroup毎にスレッドを割り当てます。そのため、事前準備として、厳密にスケジューリングを制御したいCallbackには、独立したCallbackGroupの作成を推奨します。
// Callbackごとに専用の CallbackGroup を宣言して渡す
group1_ = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive);
group2_ = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive);
timer_ = create_wall_timer(3000ms, std::bind(&SampleNode::timer_callback, this), group1_);
rclcpp::SubscriptionOptions options;
options.callback_group = group2_; // Subscription は options 経由で指定
subscription_ = create_subscription<std_msgs::msg::Int32>("topic_in", 1, cb, options);
CIEは独立したパッケージであり、rclやrclcppへの変更は一切不要です。ROS 2ビルドファームからaptでインストールできます。
sudo apt install ros-$ROS_DISTRO-callback-isolated-executor
本ハンズオンで使用するサンプルアプリケーションもインストールできます。
sudo apt install ros-$ROS_DISTRO-cie-sample-application
なお、CIEはティアフォーが開発しているROS 2互換のゼロコピーミドルウェアであるAgnocastにも同梱されており、Agnocastパッケージ経由でも導入できます。CIEとAgnocastを併用したい方はこちらをご利用ください。
Standalone Nodeの場合は、main関数内のExecutor生成行を書き換えます。通常は1行の変更で済みます。
+ #include "callback_isolated_executor/callback_isolated_executor.hpp"
- auto executor = std::make_shared<rclcpp::executors::SingleThreadedExecutor>();
+ auto executor = std::make_shared<CallbackIsolatedExecutor>();
Composable Nodeの場合は、Launchファイルのcomponent containerを書き換えるだけです。ノードに対するコードの変更は0行です。
- <node_container pkg="rclcpp_components"
- exec="component_container" name="sample_container">
+ <node_container pkg="callback_isolated_executor"
+ exec="component_container_callback_isolated" name="sample_container">
YAMLテンプレートの作成にはCIEのprerun nodeを使用します。prerun nodeを起動した状態で対象アプリケーションを起動すると、prerun nodeが検出したすべてのCallbackGroupを列挙したYAMLテンプレートファイルが自動生成されます。
# Terminal 1
ros2 run cie_thread_configurator prerun_node
# 対象アプリケーションの起動が完了したらctrl+cで終了
# Terminal 2
# 対象のアプリケーションを起動する
生成されるテンプレートは次のような形式です。CallbackGroupのidは「ノード名@そのCallbackGroupに属すCallback」という形式で決定されるため、どのエントリーがどのCallbackGroupに対応するのか一目で分かります。Scheduling Attributesにはデフォルト値が入っています。
callback_groups:
- id: /sample_node@Subscription(/topic_in)
affinity: ~
policy: SCHED_OTHER
nice: 0
- id: /sample_node@Timer(1333000000)
affinity: ~
policy: SCHED_OTHER
nice: 0
- id: /sample_node@Timer(3000000000)
affinity: ~
policy: SCHED_OTHER
nice: 0
生成されたテンプレートの各CallbackGroupに対して、Scheduling Attributesを設定します。CFS・FIFOスケジューラ・EDFスケジューラのそれぞれで、次のように記述します。どのような値を設定すべきかの考え方については、次章「Scheduling Attributesをどう設定するか」で説明します。
callback_groups:
# CFS の例: nice 値と CPU アフィニティを設定
- id: xxxxx
affinity: [0,1]
policy: SCHED_OTHER
nice: -10
# FIFO スケジューラの例: リアルタイム優先度を設定
- id: yyyyy
affinity: [2,3]
policy: SCHED_FIFO
priority: 50
# EDF スケジューラの例: runtime / deadline / period を設定 (単位: ns)
- id: zzzzz
affinity: [0,1]
policy: SCHED_DEADLINE
runtime: 10000000
deadline: 10000000
period: 20000000
Thread Configuratorプロセスから他のプロセスのスレッドのScheduling Attributesを設定するためには、CAP_SYS_NICEというCapabilityを設定する必要があります。方法は2つあります。
方法1： Thread Configuratorをsystemd serviceとして定義し、CAP_SYS_NICEを付与する方法です。これが最も簡単です。
# thread_configurator.service
[Service]
ExecStart=ros2 run cie_thread_configurator thread_configurator_node
AmbientCapabilities=CAP_SYS_NICE
方法2：バイナリにsetcapを実行する方法です。公式ドキュメントにある通り、セキュリティ上の理由で LD_LIBRARY_PATH が無効化されてしまうため、少し手間がかかります。
sudo setcap cap_sys_nice+ep \
$(ros2 pkg prefix cie_thread_configurator)/lib/cie_thread_configurator/thread_configurator_node
特別な権限が必要になるのはこのThread Configuratorという1プロセスのみで、アプリケーション本体には一切権限が要りません。権限範囲を最小化できるという、セキュリティ面の利点があります。
YAMLファイルを読み込んだThread Configuratorノードが立ち上がった状態で、対象のROS 2アプリケーションを起動すると、自動でスケジューリング設定が反映されます。
# Terminal 1 (systemd serviceとして定義している場合は不要)
ros2 run cie_thread_configurator thread_configurator_node --ros-args -p config_file:=<your yaml>
# Terminal 2
# 対象のアプリケーションを起動する
以上の6ステップで、Callback単位のLinuxスケジューリングが動き始めます。アプリケーションコードの変更は、Executorの差し替えだけです。
CIEによってCallback単位でScheduling Attributesが設定可能になりましたが、どのように設定すれば良いのでしょうか？この問いを考える際にはシステムに求められる要件を明確にする必要があります。ほとんどのロボットアプリケーションは、決められた時間内に出力することが求められるリアルタイムシステムです。中でも自動運転システムは、人命に関わるハードリアルタイムシステムです。したがって、限られたコンピューティングリソースの中で全ての時間制約を満たすことが自動運転システムにおける要件です。
この問題は簡単に解けるものでは無いですが、心強いことに、まさにこの問題を扱っているリアルタイムスケジューリングの研究コミュニティが存在します。RTSS・ECRTS・RTASといった国際会議を中心に、数十年にわたる研究資産が蓄積されており、これを活用できます。実際に、ROS 2システムを対象としたリアルタイムスケジューリング研究だけでも、Casiniらによる研究（ECRTS '19）を皮切りに、Executorの改造・Scheduling Attributes割り当てアルゴリズム・エンドツーエンドのタイミング解析など、多くの論文が発表され続けています。これらの多くの手法はROS 2標準Executor、すなわち二重スケジューリングをそのまま解析対象としています。
また、CallbackをVertex・Topic通信をEdgeとみなすと、ROS 2システムはDirected Acyclic Graph（DAG）としてモデル化できます。DAGに対するリアルタイムスケジューリングは2010年頃から現在まで盛んに研究されており、日夜最適なアルゴリズムの探求が進められています。
これまで、こうした研究成果はデプロイされたROS 2システムにほとんど届いていませんでした。二重スケジューリングを前提に構築された解析手法は、実務者が日常的に適用するには過度に複雑であり、理論的なDAGスケジューリングアルゴリズムは二重スケジューリングを前提としていないためです。CIEは二重スケジューリングを構造的に取り除くため、独立してOSスケジューリングされるタスク群について確立されてきた理論を、ROS 2のCallbackへ直接適用できるようになります。つまり、CIEは、ROSコミュニティとリアルタイムスケジューリング研究コミュニティをつなぐ架け橋です。既存の研究資産からあなたのシステムの要件に沿うスケジューリングアルゴリズムを見つけたら、そのアイデア通りにScheduling Attributesを設定するだけで良いのです。
ティアフォーが開発を主導する自動運転用オープンソースソフトウェアのAutowareにおいて、主要なノードのほぼすべてがCIEに置き換わっており（Autoware GitHub Discussion）、今後すべてのノードのExecutorをCIEに置き換える予定です。
実際にティアフォーのロボットタクシーにCIEを適用したうえで、ボトルネックである5つのDAG（Top LiDAR Preprocessing・Localization・Perception・Planning・Control）のScheduling Attributesを最適化した結果を紹介します。優先度割り当てはこの論文を参考に、「より長いパスに属するCallbackほど高い優先度を割り当てる」という戦略を取りました。これによってDAGのクリティカルパスを最速で処理することができます。
以下は、デフォルトのLinuxスケジューラであるCFSを特別な調整なしで実行した場合（灰色線）と比較して、5つのDAGのResponse Time（先頭Vertexのリリース〜末尾Vertexの終了）がどれだけ改善したかを示したものです。ロボットタクシーをお台場の公道で走行させた際の計測結果であり、横軸は経過時間（秒）です。
結果として、最悪時のレスポンスタイムは計測ベースで約3～5倍改善され、ジッタも軽減されました。自動運転システムのように、限られたコンピューティングリソースで高負荷な処理をする必要があるシステムでは、スケジューリングによる性能改善が期待できます。
インストールからスケジューリング適用までは本記事で紹介した6ステップだけです。応答時間やジッタに課題を抱えているROS 2アプリケーションをお持ちの方は、ぜひ今日から試してみてください。
この成果は、国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）の助成事業 グリーンイノベーション基金事業 / 電動車等省エネ化のための車載コンピューティング・シミュレーション技術の開発（JPNP21027）の結果得られたものです。
Atsushi Yano | システムプラットフォーム開発部
株式会社ティアフォーシステムプラットフォーム開発部リアルタイムグループリーダー。自動運転システムのリアルタイム性能を最大化するOS/ミドルウェアの研究開発に従事。埼玉大学 安積研究室 社会人博士課程に在籍し、自動運転システム向けリアルタイムスケジューリング理論を研究。
ティアフォーでは、「自動運転の民主化」というビジョンに共感を持ち、自らそれを実現する意欲に満ち溢れた新しい仲間を募集しています。
募集中の職種
その他にも多くの職種で採用をしています。詳細は、ティアフォーの「求人ページ」をご覧ください。
「どの職種で自分の経験を活かせるかが分からない」「希望する職種が見つからない」などの場合は、ぜひ「キャリア登録」をお願いします。
お問い合わせ先
ソーシャルメディア
X (Japan/Global) | LinkedIn | Facebook | Instagram | YouTube
関連リンク