はじめに
こんにちは，@tainirigelです．
JAXAではSpaceROSに関連した活動として，ROS2とcore Flight System (cFS)という2つのミドルウェアを繋ぐブリッジシステム「RACS2」を開発して公開しています．
RACS2に関する詳細は以下のQiita記事をご参照ください．
RACS2はOSSとしてGitHubで公開しているので，こちらを参考にして頂くのもいいと思います！
さて，そんなRACS2ですが，実は国際宇宙ステーション（ISS）での技術実証を行う機会があり，2025年5月に実際に軌道上での評価を行いました．
試験の結果については今年のROSCon JPで報告していますが，発表内容の振り返りを兼ねて，今回Qiita記事としてもまとめておこうと思います．
また，軌道上実証を踏まえた今後の展望についてもお話ししたいと思います．
あらためてRACS2のモチベーションとは？
地上ロボット開発においてROS/ROS2は広く使われているミドルウェアです．
ROSを活用することで車輪の再発明を減らすことができますし，RVizやGazeboのような周辺ツールが充実していることで，開発が格段にやりやすくなったというのは，皆さんご存じのところかと思います．
一方で宇宙システムにおいても，できる限り過去のソフトウェア資源を再利用してコストを削減したいというモチベーションが次第に高まっていきました．
その結果，NASAはCore Flight System (cFS) と呼ばれる宇宙用フライトソフトウェア用のフレームワークを開発し，オープンソースとして公開しました．
cFSの大きな特徴としては以下のようなものがあります．
- 過去に開発されたソフトウェア資源を利活用（再利用性）
- 多数のミッションで実績を積んだバグの少ないシステム（信頼性）
- OSやハードに依存しない設計（移植性）
NASAのcFSに関する独立検証・評価レポートにはcFSの導入実績が記載されています．
これを見るに，実に多くのアプリケーションでcFSが採用されてきたことが分かります．
そんなcFSですが，そのアーキテクチャにはROSと多くの共通点があります．
例えばPublish/Subscribe型の通信モデルを採用していたり，実行するコンポーネント（ROSで言えばNodeの概念）をランタイムに切り替えられるようになっていたり，イベントやログの管理，可視化ツールといった周辺機能が整備されている等々．．．
そんな2つのミドルウェアですが，宇宙ロボットシステムを作るといった観点で比較してみるとそれぞれに明確な利点が存在します．
前提条件として気軽にポンポン宇宙で実験することはできないため，地上と比べて頻繁に開発サイクルを回すことができません．
結果として地上で綿密な試験を行って，一発勝負で打ち上げて運用する，といったものが多いです（コンステレーション衛星などの例外を除いて）．
失敗のできないプロダクト開発という一面により，フライト実績がある（Flight Provenである）かがかなり重視される傾向にあります．
その観点で言えば長年宇宙プロダクトに組み込まれてきた実績のあるcFSに軍配が上がるでしょう．
一方で宇宙分野への民間参入が加速してきている昨今の状況を見るに，地上で培ったロボティクス技術の宇宙転用は今後ますます活発に行われていくと考えられます．
そういった中で，地上ロボット分野での豊富なソフトウェア資源があるROSを活用できると，導入コストの面で非常にメリットが大きいです．
そこで思いつくのが，ROSとcFSの互いの強みを生かすような仕組み作りができれば，より高度で複雑な宇宙ロボットシステムが実現できるのでは？という話です．
より具体的にユースケースに応じた使い分けを考えてみると以下の通りです．
- ミッションクリティカルな機能 ➡ Flight provenなcFS
- 非クリティカルかつ複雑な機能 ➡ 地上の豊富なソフトウェア資源を活用できるROS
このような機能分担を実現するために開発されたのが，ミドルウェア間のデータ双方向通信用のブリッジシステム「RACS2」です．
RACS2軌道上実証
さて導入が長くなりましたが，RACS2をISSの日本実験棟「きぼう」船内で動作させて実証した結果について紹介したいと思います．
| シナリオ１：PC検出 | シナリオ２：人物検出 |
|---|---|
 |
 |
