はじめに

こんにちは。

まずはじめに、RACS2を知らない方は、先に以下の記事で RACS2 について簡単に学んだあとに読むことを推奨します。

RACS2 は、ROS2のトピックとcFSのメッセージを繋げるOSSです。
※ROS2はロボットソフトウェアのフレームワーク、cFSは宇宙機ソフトウェアのフレームワークです。

BRASHとは

BRASHは、アメリカのtraclabsというロボット開発会社が開発しているOSSです。

BRASHは、ROS2アプリと宇宙ハードウェアのブリッジをするというコンセプトを持ちます。

フライトソフトウェアだけでなく、地上システムも含めた包括的なエコシステムを意識して開発されています。その詳細は、公式ドキュメントに埋め込まれたYouTube動画をご参照ください¹。

そんなBRASHの機能の一つに、ROS2トピックとcFSメッセージのブリッジ機能があります。
つまり、RACS2とほぼ同じ機能があるというわけですね。

↑ BRASH
↓ RACS2

そこで本記事では、RACS2とBRASHを比較してみよう、というものです。特に、ROS2 ⇔ cFS のブリッジ機能に注目します。
※優劣を論じようとするものではありません。

使い方の違い

インストール手順は、公式の手順にお従いください。

RACS2のインストール手順
- RACS2のクローンまで進めたら、まずはExampleを動かす方がわかりやすいかもしれません。
BRASHのインストール手順

以降この記事では、ブリッジする（＝ ROS2⇔cFS間の通信を担う）アプリケーションを、RACS2でもBRASHでも共通で ブリッジャ と呼ぶことにします。

RACS2 の使い方

【コーディング時の手順】
例えばROS2→cFSの向きにメッセージを渡したい場合、ROS2側のコードで送信相手となる cFSのmessage IDと送信するデータのサイズを指定するだけです（逆もほぼ同じ）。受信側はコードに何も書き加えなくてOKです。

【ビルド時の手順】
ブリッジさせたいROS2アプリとcFSアプリのそれぞれと一緒にビルドするために、RACS2のブリッジャのソースコードをコピーするだけでOKです。

【実行時の手順】
ソースコードにコピーしたRACS2のROS2、cFSそれぞれのブリッジャを立ち上げましょう。

ビルド時の手順、実行時の具体的な手順については、Example をやるのが良いと思います。

BRASH の使い方

BRASHはRACS2より手順が多いです。
公式の具体的な説明はコチラです。

【コーディング時の手順】
なんと、ブリッジのためにAPIをコード上で呼び出す必要はありません！ただし、cFSアプリ側で定義されたメッセージに合わせてROS2 msgを自動生成するため、ブリッジしたいデータはその自動生成msgを使う必要があります²。自動生成の詳細については、メカニズムの章でざっくり説明します。

【ビルド時の手順】
cFSアプリの実行ファイルとライブラリファイルを全て読み込みます (juicer_utilノード)。
ここで、cFSアプリ内で定義されているmessageを抽出し、それに応じたROS2 msgファイルを生成します。

これによって生成されたmsgを確認し、cFSアプリ側とブリッジしたいmsgを見つけましょう。
コード上では、ROS2アプリ内でそのmsgを含むトピックをpublishすれば、ブリッジャが自動的にcFSアプリの対応したmessageとしてもpublishされます。逆も然り。

【実行時の手順】
実行時は、BRASHのブリッジャを立ち上げましょう。BRASHはブリッジャが１つだけです。

メカニズムの違い

RACS2 のブリッジメカニズム

ブリッジしたいメッセージをシリアライズして³、ソケットで送受信しているだけです。
だから、APIでは送信相手を特定するIDとデータサイズを指定するわけですね。

BRASH のブリッジメカニズム

BRASHのメカニズムは、少しややこしいです。

ビルド前に juicer を用いて、cFSアプリのバイナリファイルからmessageを読み出し、SQLiteのDBファイルとして保存 (juicer_util ノード）
ROS2側に実装されたBRASHの cfe_msg_converterノードを用いて、DBに抽出されたcFS messageのそれぞれに対応するROS2 msgを作成
実行時は、BRASHのブリッジャが抽出されたmsgを検出して自動的にブリッジしてくれます

やっていることの概要図を以下に示します。
上半分がビルド時の手順でやっていることを表し、下半分が実行時の通信構成を示しています（図中のブリッジノード＝ブリッジャ）。

juicerとは？
→ elf形式の実行ファイルまたはオブジェクトファイルから、struct、array、enumeration、intrinsic typesを抽出し、SQLite DBに保管するOSSです。
詳しくは、下記の折りたたみを展開してみてください。

juicerの詳細

juicerは、ELF形式の実行ファイルまたはオブジェクトファイルから、struct、array、enumeration、intrinsic typesを抽出し、SQLite DBに保管するOSSです。

https://github.com/WindhoverLabs/juicer

アメリカのWindhover Labsが開発元となっています。

ELFとは？
→ Unix系システムで広く使用される実行ファイルおよびオブジェクトファイルのフォーマット。

ELFはExecutable and Linkable Formatの略。
cFSが作成するオブジェクトファイルも例にもれず、ELF形式。

ELF形式のファイルには、DWARF (Debug With Arbitrary Record Format) 形式でデバッグ情報が埋め込まれています。juicerはこれを読み取っています。
C言語のデバッガであるGDBもDWARF形式で埋め込まれたデータを利用しています。つまり、C/C++のコードをコンパイルするときに -g オプションを付ければ、それによって生成された実行ファイルまたはオブジェクトファイルは、juicerを用いて型などのデバッグ情報を抽出し、SQLite DBファイルにできます。

必要要件の違い

RACS2 に必要なもの

Protocol Buffers
Websocket

BRASH に必要なもの

vcstool
juicer
traclabsがforkしたcFS
（オプション）sqlitebrowser
- これは、juicerがcFSから読み取ったSQLiteファイルの内容をGUIで見たかったら、これが使えますよというもの

さいごに

今回は、以前の記事で紹介したRACS2に似た機能を持つものとして、簡単にBRASHの紹介をしました。

もっとBRASHのことが気になったら、公式ページを読み、実際に使ってみてください！

この動画は FSW (Flight Software Workshop) という、フライトソフトウェアに関する発表が集う、毎年開催のワークショップの動画です。 ↩
したがって、ROS2アプリとcFSアプリを両方同時に設計する場合に向いていると思います。 ↩
シリアライズ／デシリアライズには Protocol Buffers（プロトコルバッファ）を用いています。デフォルトではintやarray、byteなどの決まった型（とはいえ大抵の用途では困らないですが）のデータでないとブリッジできませんが、プロトコルバッファをちょちょっと勉強すれば、RACS2のプロトコルバッファの設定ファイルをいじって、カスタム型のデータをブリッジできます。 ↩