はじめに
本記事では、2026年度のRoboCup Japan Openで開催する予定の新しい宇宙ロボット競技「RoboCup JapanOpen ＠Space Challenge」の概要や、競技で用いるInt-Ball2シミュレータのチュートリアルについて、Qiita記事でまとめていきます。
本記事は、12/14(日)に開催された日本ロボット学会 インテリジェントホームロボティクス (iHR) 研究会 (第13回) で実施するチュートリアルの内容をまとめています。
また、本記事は、Space ROS Advent Calendar 2025の１つでもあります。Space ROS Advent Calendar 2025の他の記事については、下記のリンクをご参照ください。
RoboCup@Space JP関連情報
ここで、RoboCup@Space JPに関する各種リンクをご紹介します。
まず、RoboCup@Space JPの公式Webサイトです。
特に、2026年度に開催のRoboCup@Space JPに関する情報は、下記のページにまとめています。興味のある方はご参照ください。
次に、RoboCup@Space JPのGitHub Organizationです。RoboCup@Space JPに関する競技プログラムや、競技情報はこのGitHub Organization上で公開していきます。
また、RoboCup@Space JPのコミュニティ用のDiscordサーバーも用意していますので、こちらもぜひご参加ください。
このRoboCup@Space JPに関しては、日本ロボカップ委員会の方々との共著で、日本ロボット学会 学術講演会 (第43回) で発表しています。論文 (予稿) も公開していますので、こちらもご参照ください。
- RSJ2025AC1I1-03 RoboCup JapanOpen @Space Challenge の構想
- RSJ2025AC1I1-04 ISS船内ロボットInt-Ball2による技術実証とRoboCup@Spaceへの展開
RoboCup@Space JPについて
本記事では、まず「第43回 日本ロボット学会学術講演会」で発表した公開資料をもとに、RoboCup@Space JPの開催背景や、競技で用いる宇宙ロボットInt-Ball2の概要などについてお話します。その後、競技で用いるInt-Ball2シミュレータのチュートリアルをまとめていきます。
競技の背景
まず、開催の背景についてお話します。突然ではありますが、みなさん宇宙でのお仕事は想像ができますでしょうか。実際に宇宙で働いている宇宙飛行士の方々の現在の主な業務は、科学実験、設備保守、物資管理などとなっています。ただし、宇宙という特殊な環境で活動する宇宙飛行士のリソースは相当限られており、JAXAの場合、1時間稼働してもらうのに550万円もの費用が発生します (NASAとかだともっと高い)。このような状況なので、宇宙でのお仕事遂行には、より一層の効率化や支援が求められています。
特に、この業務の中でも地上との連携に伴うカメラのセットアップや撮影作業は、業務全体の約15％を占めており、負担も大きなものとなっています。そこで、JAXAではこのタスクを削減するために、Int-Ballというカメラ型の宇宙ロボットを開発し、現在も実際に運用を行っています。このInt-Ball2が、宇宙飛行士のカメラのセットアップや撮影作業を代替えする役割を担っています。
RoboCup@Space JPの開催
このInt-Ball2は、カメラとしての機能以外に、様々な宇宙ロボティクスの技術が実証可能な「技術実証のプラットフォーム」としての機能も備えています。
この機能を使った取り組みとして、JAXA主催の教育を目的としたきぼうロボットプログラミング競技会や、研究開発を目的としたRoboCup@Space JPなどでの使用が検討されています。
特に、このRoboCup@Space JPは、未だ社会で実装されていない技術の実現を目指すことをコンセプトに、宇宙飛行士の撮影業務を支援する自律型飛行ロボットの性能評価を目的とした競技を設定しており、ISS船内環境を模擬した物理的・認知的タスクを通じて、宇宙ロボティクスにおける基盤技術の実証を試みる取り組みになっています。
第1回目となる2026年度の大会は、JAXAが開発したISS搭載ロボットInt-Ball2を用いたシナリオを想定します。まずは、JAXAが開発したInt-Ball2のGazeboシミュレータを活用し、自律的な移動や協調作業といったタスクを競い合うことで、教育と研究の両面から宇宙ロボット開発の裾野を広げることを考えております。第2回目以降で、実際の軌道上にあるISS船内で競技を行うことなども検討しております。
本記事は、このRoboCup@Space JPに向けたチュートリアル記事と位置付けています。
Int-Ball2について
ここで、RoboCup@Space JPの開催に向けて、Int-Ball2の概要についてお話します。
まず、Int-Ball2は、プロペラを用いて位置と姿勢を制御する船内ドローンであり、Visual SLAMを用いて自己位置を推定し、自律的な移動とドッキングステーションへのドッキング等を行う機能を備えています。ちなみに2という数字は2号機のことを指しています。
また、先程も少し登場しましたが、宇宙ロボットの技術実証プラットフォームとして、JAXA内外の幅広いユーザ使ってもらえるような機能も備えており、ロボット開発におけるデファクトスタンダードとなっているROSを導入しています。
ここでは、宇宙機のシステムは書き換えずに、ユーザのプログラムの書き換えができるように、Dockerコンテナを用いたシステムを構築し、ベースとなるOS環境を変化させずに多様な技術実証が可能な構成となっています。
開発したプログラムは、シミュレータや実機での地上試験を通して検証を行っていきます。特に、宇宙開発は、地上でどれだけ宇宙という特殊な環境を再現できるかが重要になっているので、この技術が大切になります。
Int-Ball2では、この地上試験の1つとして、Gazeboのシミュレータを開発しており、JAXAのGitHub上で公開しております。相対運動の方適式であるHILL方程式をはじめ、ISSの姿勢変動やコリオリ力、空調の模擬など、細かい物理まで再現しています。
また、実機を用いた地上試験も行っています。実機を用いた試験では、ロボットの下部から圧縮空気を噴出して、ロボット本体を浮かせることで平面上での無重力を再現する試験装置や、プロペラによる推力を計測して、そのシミュレーション結果の位置と姿勢をロボットアームで再現するHILS試験などを行っています。
このようなプロセスを経て、軌道上での実証を行っております。現在は、各装置の動作確認や、航法誘導制御 (自律移動)、自動ドッキング、技術実証プラットフォームなどの実証を完了し、実際の撮影業務で運用しています。
添付の動画は、実際のISS船内で自動的にドッキングする際の様子を、大西宇宙飛行士が撮影した動画になります。他にも様々な動画を投稿されているので、見てみてください。
RoboCup@Space JPで期待される技術
このように実証が進んでいるInt-Ball2ですが、研究開発を目的としたRoboCup@Space JPの開催に向けては、これまで実証してきた技術のその先となる、将来の宇宙ステーション船内での運用を目標に見据えていく必要があります。そこで、将来の宇宙ステーション船内ロボットに必要な技術について、ここで少しお話させていただきます。
特に、ISS (国際宇宙ステーション) は、これまで20年以上にわたり宇宙での有人活動の中心的な役割を担ってきましたが、老朽化に伴い、既に2030年の退役が決まっています。今後は、国主導の宇宙ステーションから、民間主導の宇宙ステーションの構想が進み、宇宙旅行や商業利用が広がり、ロボットの役割も研究支援から生活支援・運用の自動化へと拡大することが予想されます。早いものでは、来年の2026年に打ち上げを予定している民間の宇宙ステーションがあるような状況です。
このような背景を踏まえると、将来の宇宙ステーション船内における宇宙ロボットには、時々刻々と変化する生活環境に対応する自律移動技術や、人との協働を目指したインタラクション技術、安全性を確保するための異常検知技術などが求められると考えております。
この辺りでは、まだInt-Ball2でも実証できていない技術があるので、研究開発として発展の余地は、たくさんあるように思えます。とはいえ、基本的にこれらに求められることは、地上であろうと宇宙であろうと、人の居住空間での支援を行うという点では、大きな変わりが無いと思うので、地上と相互作用をしながら発展させていけたらと考えております。
RoboCup@Space JP競技
そして、上記のような技術課題を踏まえた上で、RoboCup@Space JPで実際に行う競技の検討を行っています。
現在検討中の競技は、宇宙飛行士が行っている撮影作業を自律的に支援することを目的としています。下記の画像のように、Int-Ball2のような船内ロボットが撮影の準備から撮影、帰還までを一連の流れとして実行することで、宇宙飛行士の作業負担を軽減し、より効率的な運用を実現します。
まず、競技では、目標位置への自律移動を行います。ロボットはドッキングステーションを出発し、指定された撮影地点まで自律的に移動します。このとき、ISS 船内には作業中の宇宙飛行士がいる可能性があるため、立っている宇宙飛行士を障害物として認識し、安全距離を保ちながら回避する必要があります。単に最短経路で移動するのではなく、安全性を最優先にしつつ、安定した姿勢と速度で目的地へ到達することが求められます。
次に、複数視点からの撮影を実施します。ロボットは対象物体をカメラ画像などから検出し、対象が画角の中心に収まるように自身の位置・姿勢を調整しながら撮影を行います。さらに、事前に指定された複数の視点 (複数の撮影地点や角度) に移動して、各視点ごとに画像を取得します。これにより、対象物体を一方向から撮るだけでは得られない情報を収集でき、地上側での確認や記録、解析に役立つ撮影結果を提供できます。
最後に、ステーションへの自律帰還を行います。撮影が完了した後、ロボットはドッキングステーションへ向かって自律的に戻ります。この帰還時も、移動時と同様に立っている宇宙飛行士を回避し、安全な経路で航行する必要があります。ステーションに到着した後は、所定の手順で位置合わせを行い、自律的にドッキングしてタスクを完了します。これにより、撮影支援タスクが終了した後もロボットが安全に待機状態へ復帰でき、次の運用に備えることができます。
地上のロボットと宇宙のロボットの違い
さて、先程は地上と宇宙では、人の居住空間での支援という点で、地上の生活支援ロボットと共通しているところも多く、大きくは変わらないというお話をしましたが、相違点もあるので注意する必要があります。
まず、地上との相違点として、重力があります。宇宙は、無重力かつ抵抗も少ないので、運動が慣性の法則によって維持されやすい環境にあります。特に、ISS船内においては、空気の循環のために強い空調が動いており、ロボットはこれにあらがう必要があります。
また、宇宙開発においては、打ち上げ後の改修・修理は、相当な人的・時間的・金銭的リソースがかかるため、一発勝負が基本となっており、ソフトウェアの確実性や、地上での検証技術が必要になってきます。地上と軌道上とのギャップもあり、自律化に必要なデータセットの取得・作成が難しいのもあるため、汎用的なモデルや、オンラインでの学習などの検討も必要です。
他にも、ISSは完全な閉鎖空間であり、人命の安全が最優先されるため、ハード的にもソフト的にも衝突などによる事故や不具合を起こさない安全な設計が求められます。
さらに、宇宙では時給550万円と人的リソースが極めて貴重であり、地上のように人に頼った運用 (最悪の場合人がロボットを停止したり救助したりできる) は難しいですし、商業ステーションや月周回有人拠点 (Gateway) では、無人運用も想定されるため、人に依存しすぎないロボティクス設計・大会運用が必要になってきます。
競技運営における課題
上記のような点を踏まえつつ、競技を実施していくためには、地上での検証技術などの確立も課題になってきます。
軌道上でロボットを動かすためには、JAXAが行っているようなシミュレータや実機を用いた検証が必要になります。特に、実際は、何度もやり直しができる環境ではないとすると、より確実な動作の検証を行っておく必要があります。
また、人とロボットとのインタラクションに関する統合試験を行うには、実機で直接開発するという手もありますが、Int-Ball2の地上検証モデルはJAXAにしかないので、VRでシミュレータに人が没入することでインタラクションに関するシミュレーションが可能なSIGVerseのような方法も検討する必要があるかと考えています。
このような点を考慮することで、今後も発展させていく予定の宇宙ロボットの技術実証と競技としての成立性を保つことができると考えております。
RoboCup@Space JPについてのまとめ
RoboCup@Space JPについてのまとめになります。RoboCup@Space JPを開催する上では、Int-Ball2の技術を活用しつつ、宇宙利用の多様化・民間参入の拡大に合わせ，次世代宇宙サービスロボットの議論の場となることを期待しています。
特に、人と共存する空間で支援を行う点は、相違はあるものの、地上ロボットと共通する技術も多くあり、地上技術の応用や発展のための実践的な場となり得るかと思います。地上より人的リソースが高いという意味では、需要も高いと思います。
競技会は、学生、社会人問わず参加できますので、ぜひともこの場に参加されているロボットの研究開発の最前線で活動されている方々には、地上技術の宇宙応用ということも念頭に、競技会への参加を検討いただければと思います。
また、RoboCup@Space JPは、皆さんと議論しながら発展させていく研究コミュニティでもあります。ぜひ、今後の宇宙・地上含めた、知能ロボットの在り方について議論しながら、進めていけたらと思います。
Int-Ball2シミュレータ関連情報
次に、RoboCup@Space JPで用いるInt-Ball2のシミュレータのチュートリアルを行います。ここで、このInt-Ball2のシミュレータに関する各種リポジトリをご紹介します。
まず、下記のリンクが、Int-Ball2のGazeboシミュレータ本体になります。シミュレータに加え、フライトソフトウェアや、地上局側の操作端末などのプログラムも格納されています。こちらは、Ubuntu 18.04 ROS MelodicやUbuntu 20.04 ROS Noeticに対応しております。
ただ、上記のシミュレータは、実機の環境に合わせたUbuntu 18.04 ROS MelodicやUbuntu 20.04 ROS Noeticという古いバージョンでしか動作しないので、Dockerコンテナ環境でのセットアップを可能にしたシミュレータ環境も用意しております。こちらは、様々なUbuntuのバージョンで動作可能なため、基本的には、こちらの環境の使用を推奨しています。ちなみにですが、Docker版とそうでないもので、動作しているシミュレータ自体に違いはありません。
また、先述したユーザプログラムが動作可能な技術実証プラットフォームも用意しております。ユーザが直接Int-Ball2のローカル環境やフライトソフトウェアを書き換えられないように、Dockerコンテナを用いたシステムになっています。みなさんが実際にプログラムを開発する際は、このリポジトリを用います。シミュレータやフライトソフトウェアは、Ubuntu 18.04 ROS MelodicやUbuntu 20.04 ROS Noeticの環境でしか動くようにできていませんが、ユーザ側の環境はDockerを用いているため、Ubuntu 22.04 ROS 2 HumbleやUbuntu 24.04 ROS 2 Jazzyなどの環境からBridgeして動かすことも可能になっています。
少し複雑ですが、それぞれの関係性は下記の図のようになっています。
あと、RoboCup@Space JPの競技やチュートリアルでも扱いはしていませんが、一応Int-Ball2のIsaac Simシミュレータもあります。こちらは、Ubuntu 22.04やROS 2に対応しています。ただし、NVIDIA社のIsaac SimはGPUが無いと動作しないので、注意が必要です。
Int-Ball2シミュレータチュートリアル
ここから、RoboCup@Space JPで用いるInt-Ball2のGazeboシミュレータのチュートリアルを行っていきます。
先述した通り、Int-Ball2のGazeboシミュレータ本体は、実機の環境に合わせたUbuntu 18.04 ROS MelodicやUbuntu 20.04 ROS Noeticという古いバージョンでしか動作しないので、本チュートリアルでもDocker版を前提にセットアップを行っていきます。ただし、シミュレータを起動した後の動作は、Docker版とそうでないものに違いはないので、セットアップ後は同じようにチュートリアルを進めていただければと思います。
Int-Ball2 Gazeboシミュレータの全体像
Int-Ball2 Gazeboシミュレータリポジトリは、Ubuntu 18.04 ROS MelodicやUbuntu 20.04 ROS Noeticで、Gazeboを前提にしたシミュレータ環境を提供し、Int-Ball2とISS実験棟内の挙動を模擬します。ユーザが独自ソフトウェアを組み込んで検証できる点と、地上支援装置を含む運用まで再現できる点が特徴です。
実際に、JAXAでInt-Ball2を用いた技術実証を行う際にも、このGazeboシミュレータを使用しています。そのため、このシミュレータ環境上でInt-Ball2を動作させることができると、実機に近い形で運用方法を模擬・体験することができます。
(使いづらいところもあるかと思いますが、様々な理由があり現在の形になっています)
シミュレータのGUI構成
このシミュレータを起動した際は、Gazeboシミュレータ、Rviz、GSE(Ground Support Equipment)の3つのGUIが立ち上がります。
下記の画像がGazeboシミュレータです。こちらで、様々な物理計算を含むシミュレーションが行われます。
そして、下記の画像がRvizです。こちらは、ROSの可視化機能の1つで、ロボットの位置や姿勢、センサーデータ、カメラ映像などを3次元空間に表示する機能となっています。
また、下記の画像が地上支援装置であるGSE(Ground Support Equipment)です。馴染みの無い単語かもしれませんが、こちらはInt-Ball2を地上局から操作するための実際のGUIとなっています。ここから、Int-Ball2の各プログラムや、みなさんが開発したプログラムを起動したり、並進・回転の移動操作をしたり、ロボットの状態を確認したりしています。
これらの機能を使っていくことで、ISS船内でのInt-Ball2の動きを再現していきます。
シミュレータのパッケージ構成
Int-Ball2 Gazeboシミュレータのパッケージ構成を下記に示します。このシミュレータ パッケージは下記リンクのものになります (先述した「Int-Ball2 Gazeboシミュレータ」と同じリンクです)。
このパッケージは、大まかに、Int-Ball2のフライトソフトウェアやGazeboシミュレータの環境などが格納されている「Int-Ball2_platform_simulator」と、GSEのプログラムなどが格納されている「Int-Ball2_platform_gse」で構成されています。
# int-ball2_simulator
Int-Ball2_platform_simulator/
├── 3Dシミュレータ一式（Gazeboモデル・環境・ROSノード・ユーザサンプル）
│
├── src/
│ ├── flight_software/
│ │ ├── 機体側の共通メッセージ・通信処理
│ │ └── trans_communication/
│ │ ├── OBS（機体）⇔ OCS（地上）間のテレコマンド／テレメトリ通信
│ │ └── 設定ファイル：config.yml
│ │
│ ├── platform/
│ │ ├── シミュレータのプラットフォーム機能を束ねるレイヤ
│ │ └── platform_manager/
│ │ ├── Docker・ROS ノードの起動統括
│ │ └── bringup.launch で起動可能
│ │
│ ├── platform_sim/
│ │ └── Gazeboベースのシミュレーション環境・モデル
│ │
│ └── user/
│ └── 技術実証用ユーザプログラム（現在はint-ball2_platform_worksに移行）
│
Int-Ball2_platform_gse/
├── 地上支援装置(GSE)ソフトウェア
│ ├── 軌道上 Int-Ball2 へユーザプログラムを適用
│ └── GUIで選択・実行する運用を模擬
│
docs/
└── PDFマニュアル・図版
└── 環境構築：日本語マニュアル「4. 環境構築手順」に記載
Int-Ball2 Gazeboシミュレータのセットアップ (Docker版)
ここから、実際にDocker版のInt-Ball2のGazeboシミュレータのセットアップを行っていきます。このDocker版のシミュレータ パッケージは下記リンクのものになります (先述した「Int-Ball2 Gazeboシミュレータ (Dockerセットアップ版)」と同じリンクです)。
開発環境の前提条件
まず、int-Ball2のGazeboシミュレータのセットアップをする前に、下記の開発環境を用意してください。
- Ubutu OS (任意のバージョン) 環境の用意
- DockerとDocker Composeのインストール
- Qtアカウント (メールアドレスとパスワード) の用意
Qtは,GUIアプリを作るためのフレームワークで、GSEで用いています。ライセンス登録は無料です。
リポジトリの入手と共有ディレクトリ作成
まず、Docker版のInt-Ball2のGazeboシミュレータである「int-ball2_simulator_docker」リポジトリを、下記のコマンドでダウンロードします。
この際、このリポジトリは任意の作業ディレクトに置いてもらうのですが、今回のチュートリアルでは、これをhome直下に「int-ball2_simulator」というディレクトリを作り、その中で作業することを想定していきます。
mkdir ~/int-ball2_simulator # 任意の作業ディレクトリ
cd ~/int-ball2_simulator # 任意の作業ディレクトリ
git clone https://github.com/jaxa/int-ball2_simulator_docker.git
cd int-ball2_simulator_docker
mkdir -p shared_data_sim
Int-Ball2 GazeboのDockerイメージのビルド
次に、下記のコマンドでInt-Ball2 GazeboのDockerイメージのビルドを行っていきます。
この際、下記のコマンドの引数 your.email@example.com と your_password に、登録したQtアカウント情報を入れて、実行してください。
初回のビルドは、60分以上かかる場合があります。
docker build \
--build-arg HOST_USER_PATH="$(pwd)" \
--build-arg QT_EMAIL=your.email@example.com \
--build-arg QT_PASSWORD=your_password \
-t ib2_simulator:latest .
以上で、基本的なセットアップは完了です。
Int-Ball2 Gazeboシミュレータの起動 (Docker版)
基本的なセットアップが完了したので、Int-Ball2 Gazeboシミュレータの起動と操作を行っていきます。
シミュレータの起動 (Docker Compose)
下記のコマンドで、Docker Composeを用いてInt-Ball2 Gazeboシミュレータを起動します。
DockerコンテナでNVIDIA GPUを用いる場合
DockerコンテナでNVIDIA GPU を用いる場合は、下記のgpus: allまたはruntime: nvidia (Dockerのバージョンによって選択) とNVIDIA_VISIBLE_DEVICES=all、NVIDIA_DRIVER_CAPABILITIES=allのGPU関連の環境変数のコメントを外して有効化します。
https://github.com/jaxa/int-ball2_simulator_docker/blob/main/docker-compose.yml#L5-L6
https://github.com/jaxa/int-ball2_simulator_docker/blob/main/docker-compose.yml#L11-L12
cd ~/int-ball2_simulator/int-ball2_simulator_docker
PWD=$(pwd) docker compose up -d
ターミナル 1 : GSEの起動
まず、下記のコマンドで、Dockerコンテナの中に入ります。
xhost +local:docker
docker exec -it ib2_simulator bash
その後、入ったDockerコンテナ内で、GSEのプログラムを起動します。
source /opt/ros/noetic/setup.bash
source /home/nvidia/IB2/Int-Ball2_platform_gse/devel/setup.bash
roslaunch platform_gui bringup.launch
GSEを起動すると、下記の画像のようなGSEが表示されます。
ターミナル 2 : シミュレータ起動
次に、別のターミナルを開き、下記のコマンドで、再びDockerコンテナの中に入ります。
xhost +local:docker
docker exec -it ib2_simulator bash
そして、入ったDockerコンテナ内で、Int-Ball2 Gazeboシミュレータのプログラムを起動します。これにより、GazeboとRvizが起動します。
source /opt/ros/noetic/setup.bash
source /home/nvidia/IB2/Int-Ball2_platform_simulator/devel/setup.bash
rosrun platform_sim_tools simulator_bringup.sh
GSEを起動すると、下記の画像のようなGazeboとRvizが表示されます。
これで一通りGUIを起動させることができます。
ただし、シミュレーションが始まっているわけではないので、このままではロボットは動きません。Rvizなどにもセンサ情報等が表示されていない状態になっているかと思います。
GSEを用いたInt-Ball2の操作
ここから、Int-Ball2のシミュレーションを開始し、GSEを用いて実際にロボットを動かしていきます。
シミュレーションの実行
まず、Gazeboのウィンドウを開いてください。Gazeboのウィンドウ内は、下記の画像のように「シミュレーション結果」が表示されている箇所の下に、小さな「▶」アイコンがあるかと思います。これがシミュレーションを開始するアイコンになりますので、これをクリックして、シミュレーションを開始していきます (「/gazebo/unpause_physics」のROSサービスのcallでも開始できます)。
次に、Rvizのウィンドウを開いてください。Gazeboのシミュレーションを開始すると、下記の画像のように、Rviz上に「カメラの画像」や「Int-Ball2の位置関係」が描画されるようになるかと思います。Rviz上でのカメラ画像は、Int-Ball2の正面に搭載されているカメラと、側面に搭載されているステレオカメラの画像が描画されています。
この際、Rviz上では、数秒ごとに緑色の球体が描画されるようになっています。これはInt-Ball2の軌跡を表しています。
この状態で、少し放置してみてください。そうすると、Int-Ball2が動いているのが確認できるかと思います。しかし、この時点では、シミュレーションを開始しただけであって、Int-Ball2の制御プログラムはまだ動かしていません。
実は、このIn-tBall2が勝手に動く現象は、冒頭でお話した、ISS船内の空調やISSとの相対運動といった「外乱」が、Int-Ball2に作用していることで発生する現象を再現した結果になっています。このように、実際のISSでは、Int-Ball2の制御をちゃんとしないと、空調などの外乱によって少しずつ流されていってしまうのです。
これで、シミュレーションが開始できたので、Int-Ball2の制御プログラムを動かしていきます。今度は、GSEのウィンドウを開き、下記の画像中の「Navigation」の横にある「OK」アイコンをクリックします。
そうすると、下記の画像のように「Are you sure want to send commnad? Command: Switch the operation tye」という、GSEの操作に対しての確認のメッセージが表示されるので、そのメッセージの下にある「OK」アイコンをクリックします。
正常にGSEで操作したコマンドが実行されると、下記の画像のように「The command has sent.」という、コマンドの送信が完了したことを報告するメッセージが表示されるので、こちらもそのメッセージの下にある「OK」アイコンをクリックします。
また、補足ですが、Gazeboのシミュレーションを開始した直後は、Int-Ball2の制御プログラムが動いていない状態だったので、GSEの左側に黄色い文字で「Int-Ball2's telemetly is not received.」という、Int-Ball2からの情報が出ていないことを警告するメッセージと、黄色い枠が表示されます。このままでも特に動作に問題はありませんが、下記の画像中の「✔」アイコンをクリックすることで、この警告を確認したという意味で、この黄色い枠を消すことが出来ます。
これで、Int-Ball2の制御プログラムが動作し始めます。このGSEの「Navigation」の機能を「ON」にすると、Int-Ball2が位置と姿勢を保持するようになります。実際に、GazeboやRvizのウィンドウを見ると、制御プログラムにより、外乱で動いていたInt-Ball2がピタッと静止している様子が確認できるかと思います。
ここで「Navigation」という言葉が出てきたので、宇宙機とロボットにおける用語の違いについて簡単に説明します。実は「Navigation」は宇宙機とロボットで指す内容が少し異なります。
・ロボットの「自己位置推定」は、宇宙機の「航法(Navigation)」
・ロボットの「経路生成」は、宇宙機の「誘導(Guidance)」
・ロボットの「経路追従 (制御)」は、宇宙機の「制御(Control)」
宇宙機ではこれらをまとめて、GNC (Guidance Navigation and Control) と言います。
GSEの「Navigation」は、宇宙機の航法を指す意味の方です。宇宙機とロボットのどちらの要素も持つ「宇宙ロボット」の場合は、どちらの「Navigation」なのかきちんと定義してあげる必要があります。
GSEの基本操作
Int-Ball2の動作が安定したところで、GSEの基本的な使い方を簡単にご紹介します。下記の画像のとおり、GSEの画面は大きく3つのエリアに分かれています。
画面左側には、Int-Ball2のステータスを表示するエリアがあります。ここでは、プログラムの動作状況やコマンドの受信状態など、各種イベントを確認できます。
画面中央は、Int-Ball2のプログラムを操作するエリアです。先ほど紹介したNavigation機能のON/OFFに加え、皆さんが開発したプログラム (ユーザプログラム) の実行操作などを行えます。
画面右側は、Int-Ball2の移動をGUIから操作するエリアで、いわゆるテレオペレーションを行うための画面です。ここでは、ISS船内の絶対座標系、または相対座標系を用いて、移動目標地点を指定できます。
ここで座標系の話が出てきたので、座標系の定義について説明します。Int-Ball2のGazeboシミュレータでは、下記の画像に示すように、主にドッキングステーション座標系とInt-Ball2座標系の2つが用いられています。
GSEから操作する際に用いるISS船内の「絶対座標系」は、ドッキングステーション座標系を基準として、Int-Ball2座標系までの位置および姿勢を表しています。一方、「相対座標系」は、現在のInt-Ball2座標系を基準とし、将来のInt-Ball2座標系（目標地点）までの位置および姿勢を表します。
これらの座標系はROSのtfとしても定義されており、ドッキングステーション座標系はdock_body、Int-Ball2座標系はbodyというフレーム名になっています。
シミュレータ上のロボット座標系は、ROSで一般的に用いられる右手系を採用しており、正面をX軸、上方向をZ軸としています。
一方、宇宙機ではLVLH座標系がよく用いられます。LVLH座標系は、下記の画像のように、進行方向をX軸、地球中心方向をZ軸とした右手系で定義されます。
Int-Ball2シミュレータでは、ISSの座標系にのみこのLVLH座標系が使われており、ロボット座標系とは上下方向が逆になるため、注意が必要です。
以上を踏まえた上で、GSEを使って実際にInt-Ball2を少し動かしてみたいと思います。
相対座標系を用いた移動
まず、一番わかりやすい相対座標系を用いた移動を行っていきます。
最初に、移動量を設定します。GSEのウィンドウを開き、下記の画像のように、移動量を示す「amount」を「0.50」(m) に設定してください。
次に、移動方向を指定します。下記の画像のとおり、Int-Ball2の上面図に表示されている「∧」アイコンをクリックしてください。
この操作を行うと、先ほどと同様に、GSEの操作内容を確認するメッセージと、送信完了を知らせるメッセージが表示されます。それぞれで「OK」をクリックしてください。
そうすると、下記のRvizウィンドウの画像のように、Int-Ball2が相対座標系で「0.5 m」ほど移動している様子が確認できます。
絶対座標系を用いた移動
次に、絶対標系を用いた移動を行っていきます。
最初に、絶対座標系で目標地点となる位置と姿勢を設定します。GSEのウィンドウを開き、下記の画像のように、絶対座標系でのX軸の位置を示す「X」を「1.00」(m)、Y軸の位置を示す「Y」を「0.00」(m)、Z軸の位置を示す「X」を「-1.00」(m) に設定してください。回転を表す「Roll」「Pitch」「Yaw」は「0」のままで大丈夫です。
次に、その下にある「OK」アイコンをクリックしてください。
この操作を行うと、先ほどと同様に、GSEの操作内容を確認するメッセージと、送信完了を知らせるメッセージが表示されます。それぞれで「OK」をクリックしてください。
そうすると、下記のRvizウィンドウの画像のように、Int-Ball2が絶対座標系の「X 1.0 m、Y 0.0 m、Z -1.0 m」に移動している様子が確認できます。
このようにGSEを操作することで、Int-Ball2を動かすことができます。このシミュレータで、実際のISS船内での運用でも同じGSEを用いているので、実際の運用を体験することができます。
ユーザプログラムを用いたInt-Ball2の操作
次に、Int-Ball2のシミュレーションを開始し、皆さんが開発するユーザプログラムを用いて実際にロボットを動かしていきます。
ROSパッケージ形式のユーザープログラムは、int-ball2_platform_worksパッケージ内のplatform_dockerに配置します。ここにDockerfileと、ユーザのプログラムを置き、GSEからこれらを起動し、Int-Ball2の制御させるという流れです。
今回は、チュートリアルとしてint-ball2_platform_worksであらかじめ用意しているsimple_test.pyというサンプルプログラムを動かして、解説していきます。
プログラムの解説
このプログラムは、先程のGSEからの移動動作をプログラムから実行するノードで、ROSの Topic / Service / Action を使ってInt-Ball２の各ソフトとのやり取りを行います。Topicは3つあり、Subscribeする Topicが1つ、PublishするTopicが2つあります。加えて、Actionを2本叩く(= Action clientとしてgoalを送る) 構造になっています。
下記のようにUserTemplateクラス内の__init__コンストラクタ内で定義しています。
まず、TopicとしてSubscribeしているのは/ib2_user/startです (メッセージ型はplatform_msgs/UserLogic)。このTopicは、GSEからidの情報を入れてPublishできるようになっており、本プログラムでそのTopicをSubscribeすることで、idの情報に応じた動作(ロジック)が開始するようになっています。
/ib2_user/startのTopicを受け取った直後は、まずNavigationを立ち上げるための/sensor_fusion/navigation_start_upのAction Serverが利用可能になるまで待ちます (20秒間)。Action Serverが利用可能になったら、本プログラムからAction Clientとして、NavigationをONにするGoalを送り、結果がON_READYの完了まで待ちます。ここで「航法が動いていて、制御ができる前提が整った」ことを確認します。
下記のようにUserTemplateクラス内の__callback_start関数内で定義しています。
その後、/ib2_user/startのTopicで受け取ったidの情報に応じた動作(ロジック)へと分岐していきます。例えば、id==1なら「絶対座標系での目標地点への移動 → 相対座標系での目標地点への移動を複数回 → 完了通知」という一連処理を順番に実行するように定義しています。また、id==2なら「位置と姿勢を保持する指令を1回だけ送って待つ」という処理を実行します。id==3なら「300秒のカウントアップ → 完了通知」を実行します。このように、GSEから/ib2_user/startのTopicをPublishすることが、本プログラムでInt-Ball2を動かす「スタート」の合図になります。
こちらも、下記のようにUserTemplateクラス内の__callback_start関数内で定義しています。
ここで、id==1のときの絶対座標系での目標地点への移動などについて、少し深堀します。上記のように、id==1の場合は、事前に定義した__process_absolute_target_001関数、__process_relative_target_001関数、__process_relative_target_002関数などの動作関数を、__process_execution関数で順に呼び出す処理を行っています。
__process_absolute_target_001関数や__process_relative_target_001関数といった動作関数は、いずれも同じ手順でInt-Ball2を動かしています。ここでは、下記の__process_absolute_target_001関数を参考に解説していきます。
まず、__process_absolute_target_001関数では下記のように、self.__statusに自分自身の関数名をセットして、現在どの処理を実行しているかを内部状態として更新します。__status自体はこの関数の中でPublishしているわけではありませんが、メインループであるrun関数が1Hzで__statusの値を読み取り、/ib2_user/statusに固定長メッセージとして定期的にPublishしています。
次に、下記のように、実際の動作指令を送る先である/ctl/commandのAction Serverが呼び出し可能かどうかを確認します。具体的には__wait_for_ctl_command関数を呼び、/ctl/commandのAction serverが起動していてgoalを受け付けられる状態になるまで待機します。この待機はstop要求があれば中断できるようになっており、準備が整わない場合には以降の処理に進まずに関数を終了します。
Action Serverの準備が整ったら、下記のように、目標となる位置 (position) と姿勢 (orientation) を作ります。絶対座標系の移動ならMOVE_TO_ABSOLUTE_TARGET、相対座標系の移動ならMOVE_TO_RELATIVE_TARGETといったコマンドに応じた目標値を設定します。
最後に、__generate_ctl_command_goal関数を使って「コマンド種別」と「目標 Pose (PoseStamped)」をまとめたCtlCommandGoalを作成し、それを/ctl/commandのAction Serverに対して、send_goal_and_wait関数で送ります。このsend_goal_and_wait関数は、goalを送信したあと、Actionが完了するまで待機する呼び出しなので、動作関数は「移動や姿勢維持が終わる (成功・失敗・キャンセルのいずれかで完了する) まで戻らない」という振る舞いになります。結果として、id==1のように複数の動作関数を順番に呼ぶシーケンスでは「1つ目の動作が終わってから次の動作に進む」という直列の実行が自然に実現されています。
この際、位置と姿勢を保持するKEEP_POSEのようにPoseを使わないタイプは「typeだけを指定するgoal」を作りつつ、Quaternionは有効な値 (単位回転) を入れて送っています。
idの情報に応じた動作(ロジック)が最後まで終わると、本プログラムでは/ib2_user/completeのTopicで「完了時刻」をPublishします。
最後に停止についてですが、本プログラムで定義した/ib2_user/stopのService Serverが外部から呼ばれると、このプログラム内でstopフラグを立て、動いている/ctl/commandのActionをキャンセルし、状態をリセットします。これにより「途中停止」ができるようにもなっています。
本プログラムで定義している/ib2_user/stopのService Serverが外部のService Clientから呼ばれると、__stop_processing関数内部で停止フラグ (__stop_requested) を立てて処理の継続を止め、実行中の/ctl/commandのActionがあれば、__cancel_ctl_command関数を用いてキャンセルします。さらに、動作シーケンスを実行しているスレッドがあれば終了を待ったうえで、実行中フラグやステータスなどの状態をリセットします。これにより、動作途中でも安全に停止できるようになっています。
簡単にはなりますが、以上がサンプルプログラムの構成になります。
実行ファイル (roslaunch) の解説
次に、先程のプログラムを実行する、下記のサンプルのROSのlaunchファイルについても解説していきます。
まず、launchファイル内の冒頭では、下記のように、実行する各機能モジュールの有効・無効を設定しています。
sensor_fusionは、IMUとVisual SLAMを統合した自己位置推定を行うモジュールで、slam_wrapperはVisual SLAM単体を担当します。ちなみにですが、Visual SLAMの結果は、ドッキングステーション座標系からInt-Ball2本体の座標系までの位置と姿勢が入っています。
ctl_onlyは制御系全体を司るモジュールで、目標値を表す/ctl/commandから力・トルクを表す/ctl/wrenchまでを計算して出力します。
一方、fsmはプロペラ制御を担当し、力・トルクを表す/ctl/wrenchを入力として、各プロペラのduty比を表す/ctl/dutyを出力します。サンプルプログラムでは、これらすべての設定がtrueになっており、各モジュールが有効 (ON) の状態で実行されます。
次に示すパラメータ設定では、camera_leftとcamera_rightのパラメータはいずれも無効 (false) に設定しています。これは、Visual SLAM を担当するslam_wrapperノードが起動している場合、カメラ入力を内部で使用するため、個別にカメラノードを起動すると競合が発生するためです。
また、その下に記述されている設定は、先ほど解説したプログラムのノード指定に対応しています。sample_testsパッケージ内のsimple_test.pyをsimple_testというノード名で起動し、実行時のログを画面 (screen) に出力されるようにしています。
簡単にはなりますが、以上がROSのlaunchファイルの構成になります。
ユーザープログラム用のDockerイメージのビルド
次に、これまで解説してきたユーザープログラムを含んだDockerイメージを作成していきます。下記のコマンドでユーザープログラムを含むDockerイメージをビルドします。
cd ~/int-ball2_simulator # 任意の作業ディレクトリ
git clone https://github.com/jaxa/int-ball2_platform_works.git
cd int-ball2_platform_works/platform_docker/sample_tests
docker build -t ib2_user:0.1 .
ここでビルドしたDockerイメージは、起動するとint-ball2_platform_worksのsample_testsディレクトリにあるユーザプログラムが自動で動くような仕組みになっています。この際、動かしたいプログラムのコマンドは、下記のcmd.sh内に記述していきます。
詳細は後述しますが、ISSでのロボットの運用は、基本的にコマンドを用いて操作するのではなく、GSEからロボット行います。GSEでは、ここでビルドしたユーザプログラム用のDockerイメージを起動することができるので、このcmd.shを設定することで、実質GSEからDockerイメージの起動とユーザプログラムの起動を同時に行うことができる仕組みになっています。
ユーザープログラムの実行方法
Dockerイメージのビルドが完了したら、先程と同じ手順でGazeboとGSEを起動し、GSEウィンドウ内でユーザープログラムの起動設定を行います。
この際、GSEウィンドウ内で、下記の画像のように、「User Node」にはシミュレータ側で起動するノードとして user_nodeを指定し、「User Launch File」にはシミュレータ側で実行するlaunchファイルであるuser_node.launchを選択します。これは、ROSの$ roslaunch user_node user_node.launchコマンドに相当する操作になっています。ちなみにですが、こちらの操作はGSEの操作からユーザプログラムを起動するための設定であって、皆さんが開発するプログラムのノードやlauchファイルとは関係ありません。
次に、「User Container」にユーザープログラムを実行するコンテナとしてib2_user:0.1を指定します。こちらの操作は、皆さんが開発したユーザプログラムを含む任意のDockerコンテナ名を選択し、実行することで、それをGSE側から起動することができます。シミュレータ側のDockerコンテナと、ユーザプログラム側のDockerコンテナで分かれているため、本体側のプログラムを書き換えずに動作確認や開発が行えるようになっています。
さらに、「User Logic」では、先ほど説明したsimple_test.pyの動作を開始するための/ib2_user/startのTopicに送信するid情報を指定します。今回は「1」を設定します。プログラムの解説でもお話しましたが、id == 1が指定された場合「絶対座標系での目標地点への移動 → 相対座標系での目標地点への移動を複数回 → 完了通知」の動作を行います。これは、ROSの$ rostopic pub /ib2_user/start platform_msgs/UserLogic "id: 1"コマンドに相当します。
なお、このようにGSEからlaunchファイルやROS Topicを実行する理由は、実際のISS軌道上の運用では、Int-Ball2の端末を直接操作することを基本的にしないような設計にしているためです。ターミナルを直接操作すると、実行環境を意図せず変更してしまう可能性があるため、運用時はターミナルを自由に触れられない構成になっています。
例外的にターミナル操作を行う場合もありますが、実運用においては、訓練を受けた運用管制官がGSEを介して操作を行います。そのため、私たち開発者自身が実際の運用時にGSEを直接操作することはありません。
ちなみにですが、このGSEでコンテナ名を選択できるようにするためには、int-ball2_simulator内のcontainer_image_list.jsonに記述してもらう必要があります。基本的には、本チュートリアルの手順通りに、ib2_user:0.1という名前でDockerイメージのビルドをしていただければ問題ありません。
その後、「User Container」と「User Logic」のそれぞれの横にある「Start」アイコンをクリックします。この際、他の作業と同様に、GSEの操作内容を確認するメッセージと、送信完了を知らせるメッセージが表示されるので、それぞれで「OK」をクリックしてください。
このようにプログラムを実行すると、裏で冒頭でビルドしたユーザプログラムのDockerイメージとそのプログラムが起動します。この際、GSE下部で、立ち上がったDockerコンテナを確認することができます。
下記のRvizウィンドウの画像のように、「絶対座標系での目標地点への移動 → 相対座標系での目標地点への移動を複数回 → 完了通知」の動作を行っている様子が確認できます。
ちなみにですが、下記の画像にもある「青い球体」と「赤い球体」は、それぞれ「出発地点」と「目標地点」を指しています。
このようにユーザプログラムを設定・実行することで、Int-Ball2を動かすことができます。基本的なチュートリアルはここまでになります。
RoboCup@Space JPの競技に向けて
最後に、RoboCup@Space JPの競技を行うにあたり、Int-Ball2を動かすためのヒントについてまとめます。
Int-Ball2本体のプログラム構成
ここで、大まかなプログラムの構成を下記の画像に示します。各センサなどに対応したROS TopicがPublishされている様子などがわかると思います。ROSのrqtなどでrosnode graphと見比べてみるのも良いかもしれません。
この際、ユーザープログラムによって取得可能な、主なデータは下記の通りです。
| 種類 | ROS定義名 | 概要 |
|---|---|---|
| Topic | /camera_main/image_raw | Int-Ball2正面のメインカメラの画像。 |
| Topic | /camera_left/image_raw | Int-Ball2の左側にあるサブカメラ (左) の画像。 |
| Topic | /camera_right/image_raw | Int-Ball2の左側にあるサブカメラ (右) の画像。 |
| Topic | /imu/imu | IMU (慣性計測ユニット) のセンサ値。 |
| Topic | /slam_wrapper/slam | Visual SLAMによる自己位置推定の結果。 |
| Topic | /sensor_fusion/navigation | IMUとVisual SLAMを融合した自己位置推定の結果。 |
また、ユーザープログラムによって制御可能な、主なデータは下記の通りです。
| 種類 | ROS定義名 | 概要 |
|---|---|---|
| Topic | /ctl/wrench | 力・トルク指令を入力する。 |
| Topic | /ctl/duty | 各スラスターの duty 比（駆動率）を指定する。 |
他にも色々とあるのですが、先程のサンプルプログラムなどを動かしながら、それぞれのノードとのやり取り (データの中身などを含めて) を確認してみてください。これらを駆使することで、自由自在な制御が可能になります。
自由自在な移動
先ほど紹介したサンプルプログラムは、直線的な移動のみが可能でした。このプログラムの大まかな流れは「目標地点の指令 → 軌道の生成 → Int-Ball2本体への力・トルクの指令 → プロペラのduty比」となっています。この流れから、直線的な移動だけではなく、より自由度の高い移動を実現するためには「Int-Ball2本体への力・トルクの指令」までの流れを、別途ユーザプログラムで作成する必要があります。
その際には、チュートリアルで使用した下記のlaunchファイル内の設定を調整します。具体的には、ctl_onlyのみをfalseに設定し、それ以外の項目はtrueのままとします。この設定により、既存の制御系による軌道から力・トルクを出力する機能を無効化し、ユーザ自身で/ctl/wrenchトピックに対して力・トルク指令を直接指令プログラムを動かせるようになります。
この構成では、ユーザ自身が力・トルクを指令することで、より自由自在な移動ロジックを実装することが可能です。ただし、ctl_onlyを無効化すると、その中に含まれている直線移動用のノードも同時に停止します。このノードは、軌道情報から/ctl/wrenchを生成する処理を行っているため、ユーザ自身での独自実装を行う際には、その実装内容を参考にすると良いかと思います。
Int-Ball2は、マニピュレータを持たないので、このような無重力空間での移動方法や、自律的なタスクプランニング等がRoboCup@Space JPの競技で競う技術になってくると思います。上記のような情報を駆使して、競技のプログラムを作成してみてください。
上手くプログラムを作成することで、下記のように、直線だけではない自由な移動ができるようになります。
RoboCup@Space JPチュートリアル
現在、RoboCup@Space JPの競技のデモ環境を整備中。
まとめ
以上、本記事では、2026年度に開催予定の新競技「RoboCup@Space JP」の背景と狙い、競技で用いる宇宙ロボット Int-Ball2の特徴、そして開発・検証の基盤となるGazebo シミュレータ (Docker版) を用いたチュートリアル手順までを一通り整理しました。
具体的には、ISS 船内での運用を模擬するためにGazebo・Rviz・GSEの3つのGUIを用いてシミュレーションを開始し、GSEからNavigationの有効化や絶対/相対座標系での移動指令を送ることで、軌道上運用に近い形でInt-Ball2を操作できることを確認しました。
さらに、ユーザプログラムとしてsimple_test.pyの構造 (Topic/Actionによる起動・制御・完了通知・停止処理) と、それを起動するsimple_test.launchの役割 (各モジュールのON/OFF設定やカメラ競合回避、ノード起動指定) を解説し、ビルドから実行までの具体的な流れもまとめました。
最後に、競技に向けては、取得できるセンサ情報や制御入力 (特に/ctl/wrenchや/ctl/duty) を活用し、直線移動だけでなくより自由度の高い移動ロジックを自作できること、そしてその際にはlaunchのctl_only設定を調整して力・トルク指令レベルでの制御に切り替えられる点を紹介しました。
RoboCup@Space JPは、地上技術の宇宙応用を試し、次世代の宇宙サービスロボットに必要な技術を議論・実証する場としての発展を目指していますので、興味のある方はぜひ関連リポジトリやDiscordも参照しつつ、シミュレータ上での開発に取り組んでみてください。
何かあれば気軽にコメントください。