(57)【要約】【課題】宇宙機向けソフトウェア基盤において、地上標準ソフトウェア基盤で開発されたソースコードを実行可能とするインターフェースプログラム、および変換プログラムを提供する。【解決手段】地上標準ソフトウェア基盤で動作可能に開発されたアプリケーションを宇宙機向けソフトウェア基盤で動作可能にするインターフェースプログラムであって、コンピュータで実行されたときに、前記アプリケーションから前記宇宙機向けソフトウェア基盤を介して送信される前記アプリケーションとは異なる他のアプリケーションへの実行要求メッセージを一時的に保持し、一時的に保持される前記メッセージの送受信を制御する、インターフェースプログラム。【選択図】図１
2019211854.tif 000002
【特許請求の範囲】
【請求項１】
地上標準ソフトウェア基盤で動作可能に開発されたアプリケーションを宇宙機向けソフトウェア基盤で動作可能にするインターフェースプログラムであって、コンピュータで実行されたときに、
前記アプリケーションから前記宇宙機向けソフトウェア基盤を介して送信される前記アプリケーションとは異なる他のアプリケーションへの実行要求メッセージを一時的に保持し、
一時的に保持される前記実行要求メッセージの送受信を制御する、
インターフェースプログラム。
【請求項２】
前記コンピュータで実行されたときに、
前記宇宙機向けソフトウェア基盤のメッセージ送信規則に基づいて前記実行要求メッセージの送受信を制御する、
請求項１に記載のインターフェースプログラム。
【請求項３】
前記地上標準ソフトウェア基盤はロボット用ＯＳであり、前記アプリケーションがロボットアプリケーションである、
請求項１または２に記載のインターフェースプログラム。
【請求項４】
コンピュータで実行されたときに、
請求項１から３のいずれか一項記載の地上標準ソフトウェア基盤で動作可能に開発されたアプリケーションのソースファイルを受け付け、
前記ソースファイルを、請求項１から３のいずれか一項に記載のインターフェースプログラムおよび宇宙機向けソフトウェア基盤において実行可能なソースファイルに変換する、
変換プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターフェースプログラム、および変換プログラムに関する。
【背景技術】
【０００２】
近年、ロボット研究分野において、オープンソースの制御ソフトウェア開発プラットフォームとして種々のロボット制御ミドルウェアが登場し、開発者が独自の技術を組み入れたアプリケーションを容易に開発できる環境が浸透している。例えば、オープンソースミドルウェアであるＲＯＳ（Robot Operating System；登録商標）は世界中に広く普及しており、デファクトスタンダードとなっているといえる。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】中本他「宇宙ロボット向けミドルウェアの設計と組込み計算機における検証結果」第５７回宇宙科学技術連合講演会講演集ＩＭ１０，２０１３
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一方、宇宙機（例えば、人工衛星や、宇宙船の曝露部）に備わるロボットアーム等に用いるロボット制御ミドルウェアは、一般のロボット制御ミドルウェアと比較して、より高い信頼性、安全性および自律性が求められる。例えば、ＮＡＳＡゴダード宇宙飛行センターが開発したオープンソースの宇宙機ミドルウェアである、ｃＦＥ（core Flight Executive）／ＣＦＳ（Core Flight System）には異常監視を行うフェイルセーフ機能等が組み込まれている。一方、ＲＯＳにはｃＦＥと同様のフェイルセーフ機能が組み込まれていないため、ＲＯＳをそのまま宇宙機ミドルウェアに転用することは困難である。
【０００５】
ＲＯＳを宇宙機に導入することができれば、一般ロボティクス技術を迅速に取り入れることができ、豊富なソースコード・パッケージや、ロボット研究者・開発者の知見を直接利用したり、大規模宇宙ミッションの実施性を高めたり、ソフトウェア検証効率を改善したりすることができることから、その導入が望まれていた。
【０００６】
本発明は、このような事情を考慮してなされたものであり、既存の宇宙機向けソフトウェア基盤において、地上標準ソフトウェア基盤で開発されたソースコードを実行可能とするインターフェースプログラム、および変換プログラムを提供することを目的の一つとする。
【課題を解決するための手段】
【０００７】
本発明の一態様は、地上標準ソフトウェア基盤で動作可能に開発されたアプリケーションを宇宙機向けソフトウェア基盤で動作可能にするインターフェースプログラムであって、コンピュータで実行されたときに、前記アプリケーションから前記宇宙機向けソフトウェア基盤を介して送信される前記アプリケーションとは異なる他のアプリケーションへの実行要求メッセージを一時的に保持し、一時的に保持される前記メッセージの送受信を制御するインターフェースプログラムである。
【発明の効果】
【０００８】
本発明は、既存の宇宙機向けソフトウェア基盤において、地上標準ソフトウェア基盤で開発されたソースコードを実行可能とすることによって、地上標準ソフトウェア基盤による宇宙機向けアプリケーションの開発を可能にすることで、地上標準ソフトウェア基盤によって開発された地上ロボティクス技術を宇宙機向け開発により平易に取り入れることができ、宇宙機向けシステム開発の仕様共通化および標準化を推進することができる。
【図面の簡単な説明】
【０００９】
【図１】プラットフォーム１の一例を示す概略構成図である。
【図２】インターフェース装置１００の構成図である。
【図３】インターフェース装置１００における中継処理の一例を示すフローチャートである。
【図４】インターフェース装置１００および変換装置５００の利用環境を示す図である。
【図５】変換装置５００の構成図である。
【図６】変換装置５００における変換処理の一例を示すフローチャートである。
【図７】インターフェース装置１００および変換装置５００の利用環境の他の一例を示すユースケース図である。
【図８】プラットフォーム１Ａを示す概略構成図である。
【発明を実施するための形態】
【００１０】
以下、図面を参照して、本発明に係るインターフェースプログラム、および変換プログラムの実施形態について説明する。
【００１１】
［プラットフォーム］
図１は、プラットフォーム１の概略構成図である。プラットフォーム１は、宇宙機に搭載されるターゲットボード上で実現される。プラットフォーム１は、例えば、インターフェース装置（Ｉ／Ｆモジュール）１００と、ｃＦＥ２００と、１以上のロボットアプリケーション３００を備える。ｃＦＥ２００は、「宇宙機向けソフトウェア基盤」の一例である。ロボットアプリケーション３００は、例えば、ＲＯＳ開発環境で生成されたアプリケーションである。また、ＲＯＳは、「地上標準ソフトウェア基盤」の一例である。
【００１２】
インターフェース装置１００は、ｃＦＥ２００上でロボットアプリケーション３００が実現されるよう、ｃＦＥ２００とロボットアプリケーション３００との間の実行要求メッセージの入出力を中継するインターフェースプログラムを実行する。ロボットアプリケーション３００は、他のロボットアプリケーション３００に対して実行要求メッセージを送信する場合、ｃＦＥ２００を介してメッセージの送受信を行い、ロボットアプリケーション３００同士が直接通信することはない。これは、ロボットアプリケーション３００が実行要求メッセージを送受信する際に、ｃＦＥ２００での動作が保証されるＣＦＳ標準アプリケーションによるテレメトリ管理機能や時刻管理機能を用いることにより、ｃＦＥ２００のフェイルセーフ機能を実現するためである。テレメトリ管理機能とは、遠隔地にある計測器などのデータを、通信回線を使って収集する機能のことである。
【００１３】
以下、ｃＦＥおよびＲＯＳのメッセージ送受信機能について説明した後、インターフェース装置１００の構成例、およびインターフェース装置１００によるメッセージの中継処理について説明する。
【００１４】
［ｃＦＥのメッセージ送受信機能］
ｃＦＥは、衛星データシステムおよび機器用のフライトソフトウェアのソフトウェア基盤として使用される、プラットフォームに依存しない再利用可能なソフトウェアフレームワークである。ｃＦＥは、ＯＳ（Operating System）との間のＯＳＡＬ（OS Abstraction Layer）と呼ばれるレイヤを実装することで、Ｌｉｎｕｘ（登録商標）等の汎用的なＯＳ上で動作させることが可能である。ｃＦＥ上で動作する個別の標準アプリケーションはオープンソースとして公開されており、例えば、ソフトウェア・バス（Software Bus）という実行要求メッセージを送信するメッセージ通信機能が公開されている。
【００１５】
ソフトウェア・バスは、ｃＦＥにおけるアプリケーション間のメッセージ通信を実現する。ｃＦＥは、アプリケーションがメッセージ送受信により起動されるイベントドリブン型のアーキテクチャであり、メッセージ送受信は１対多のパブリッシュ・サブスクライブ（Publish-Subscribe）方式をとっている。すなわち、ｃＦＥ上で実現されるアプリケーションは、ｃＦＥ上で実現される他のアプリケーションにメッセージ通信する場合、ソフトウェア・バスを介してその実行要求メッセージが受信されるまで、実行要求メッセージの送り手と受け手が送受信の完了するタイミングを共有する。なお、上述のメッセージ通信方式は、「メッセージ送信規則」の一例である。
【００１６】
［ＲＯＳのメッセージ送受信機能］
一方、ＲＯＳにもソフトウェア・バスと同様に、メッセージ通信機能が存在する。ＲＯＳの周期動作機能（ｓｐｉｎ関数およびｓｐｉｎＯｎｃｅ関数）、およびトピックメッセージ送受信機能（ｐｕｂｌｉｓｈｅｒ関数およびｓｕｂｓｃｒｉｂｅｒ関数）ではｃＦＥのソフトウェア・バスとは異なり、ＲＯＳ上で実現される他のアプリケーションにメッセージ通信する場合、その実行要求メッセージが受信されるまで待機することなく送信を終了し、実行要求メッセージの送り手と受け手が送受信の完了するタイミングを共有しない。
【００１７】
［インターフェース装置］
インターフェース装置１００は、上述のようなｃＦＥとＲＯＳとのメッセージ送受信の仕様の違いを解消するための中継処理を行う。以下、インターフェース装置１００の構造およびインターフェース装置１００の中継処理について説明する。
【００１８】
図２は、インターフェース装置１００の構成図である。インターフェース装置１００は、例えば、受信部１１０と、仲介部１２０と、送信部１３０と、制御部１４０とを備える。受信部１１０は、ロボットアプリケーション３００により出力される実行要求メッセージを受信し、仲介部１２０に出力する。実行要求メッセージは、送り先（例えば、他のロボットアプリケーション３００や、ＣＦＳ標準アプリケーション）の情報を含む。仲介部１２０は、受信部１１０により出力された実行要求メッセージを一時的に保管する。送信部１３０は、仲介部１２０に蓄えられた実行要求メッセージを、送り先に出力する。制御部１４０は、送信部１３０により仲介部１２０に一時保管された実行要求メッセージを送信するタイミングを制御した上で、送信部１３０に、仲介部１２０に一時保管された実行要求メッセージを送り先に送信させる。インターフェース装置１００の各機能部は、ＣＰＵ（Central Processing Unit）などのプロセッサが、プログラムメモリなどに記憶されたプログラムを実行することで実現される。
【００１９】
なお、上述のインターフェース装置１００は、宇宙機に搭載されるマイクロプロセッサ上で実現されることから、利用できるメモリ容量が制限される。したがって、制御部１４０は、仲介部１２０が一時的に保管する実行要求メッセージの容量が所定の容量以上とならないように、その送受信のタイミングを制御する。また、制御部１４０は、仲介部１２０が一時的に保管する実行要求メッセージの容量が所定の容量以上となった場合に、受信部１１０に新たな実行要求メッセージを受信させないように制御する。
【００２０】
図３は、インターフェース装置１００における中継処理の一例を示すフローチャートである。図３に示すフローチャートのステップＳ１０４およびＳ１１０は、ｃＦＥ２００によって制御されるメッセージ送受信タイミングで実施される。
【００２１】
まず、インターフェース装置１００の受信部１１０は、ロボットアプリケーション３００により出力される実行要求メッセージを受信する（ステップＳ１００）。次に、仲介部１２０は、受信部によって受信された実行要求メッセージを一時保管する（ステップＳ１０２）。次に、制御部１４０は、仲介部１２０に保管される実行要求メッセージがあるか否かを判定する（ステップＳ１０４）。制御部１４０は、実行要求メッセージがあると判定した場合、仲介部１２０から送信部１３０に実行要求メッセージを出力させ、送信部１３０から実行要求メッセージの送り先に実行要求メッセージを送信させる（ステップＳ１０６）。制御部１４０は、実行要求メッセージがあると判定しなかった場合、ステップＳ１００に処理を戻す。
【００２２】
ステップＳ１０６の処理の後、制御部１４０は、送信が完了したと判定した場合、仲介部１２０に保管される実行要求メッセージが他にもあるか否かを判定する（ステップＳ１０８）。制御部１４０は、実行要求メッセージが他にもあると判定した場合、ステップＳ１０６に処理を戻す。制御部１４０は、実行要求メッセージが他にもあると判定しなかった場合、本フローチャートの処理を終了する。
【００２３】
上述のように、インターフェース装置１００がｃＦＥとＲＯＳとのメッセージ授受の仕様の違いを解消するための中継処理を行うことによって、ロボットアプリケーション３００の開発者はｃＦＥの処理規則を意識することなく、ＲＯＳによるロボット制御に特化した機能を開発することができる。また、インターフェース装置１００は、ロボットアプリケーション３００を実行する際に、ＣＦＳ標準アプリケーションによるログ出力機能やメモリ管理機能、異常値検出機能等を用いることができることから、プラットフォーム１全体のログ出力等の仕様共通化および標準化を推進することができる。
【００２４】
［変換装置］
図４は、インターフェース装置１００および変換装置５００の利用環境を示す図である。図４に示すように、上述のインターフェース装置１００をプラットフォーム１で実行するにあたり、図１に示したロボットアプリケーション３００の備えるソースファイルは、開発者がＲＯＳの開発環境で生成したソースファイルや、ＲＯＳの開発環境で生成したソースファイルが参照するＲＯＳのライブラリ（インクルードファイル）をｃＦＥ上で実行可能な実行形式に変換する必要がある。実行形式に変換するとは、例えば、ＲＯＳでは実行可能であるがｃＦＥでは実行できない形式の数式をｃＦＥで実行可能な数式に置換したり、ＲＯＳの開発環境で生成したソースファイルが参照するＲＯＳのライブラリをｃＦＥ上で実行可能な実行形式に変換したりといった処理の後に、コンパイル等の処理を行いパッケージングすることである。パッケージングとは、複数のソースコードファイルを、1つまたは複数のファイルにまとめることである。開発者は、例えば、ＲＯＳの開発環境で生成したソースファイルを変換装置５００で変換した後にパッケージングし、開発者の用いる開発環境とは異なる結合試験環境または宇宙機の備えるコンピュータの記憶部に記憶させることで、ロボットアプリケーション３００の実現される環境を整備する。
【００２５】
以下、ＲＯＳの開発環境で生成したソースファイル、およびＲＯＳの開発環境で生成したソースファイルが参照するＲＯＳのライブラリをｃＦＥ上で実行可能な実行形式に自動変換する変換プログラムを実行する変換装置５００について説明する。
【００２６】
図５は、変換装置５００の構成図である。変換装置５００は、例えば、受付部５１０と、変換部５２０と、出力部５３０とを備える。受付部５１０は、開発者がＲＯＳの開発環境で生成したソースファイルや、ＲＯＳの開発環境で生成したソースファイルが参照するＲＯＳライブラリの入力を受け付ける。ＲＯＳライブラリには、例えば、メッセージの送受信に用いるＡＰＩ（Application Programming Interface）を呼び出す関数の定義を記載した、メッセージ定義ファイルが含まれる。受付部５１０は、受け付けたソースファイルおよびＲＯＳライブラリを変換部５２０に出力する。変換部５２０は、受付部５１０により出力されたソースファイルおよびＲＯＳライブラリをｃＦＥ上で実行できる実行形式に変換し、出力部５３０に出力する。出力部５３０は、変換部５２０により変換されたソースファイルおよび変換されたＲＯＳライブラリを出力する。変換装置５００の各機能部は、ＣＰＵなどのプロセッサが、プログラムメモリなどに記憶されたプログラムを実行することで実現される。
【００２７】
図６は、変換装置５００における変換処理の一例を示すフローチャートである。まず、受付部５１０は、変換前のＲＯＳ開発環境で生成されたソースファイルを受け付ける（ステップＳ２００）。次に、変換部５２０は、受付部５１０により受け付けられたソースファイルを、ｃＦＥ上で実行可能なソースファイルに変換する（ステップＳ２０２）。以上、本フローチャートの処理を終了する。
【００２８】
上述の変換装置５００は、例えば、開発者の利用するＰＣ（Personal Computer）等の端末上で実現される実行ファイルとして開発者に提供される。開発者は、ＲＯＳの開発環境で生成したソースファイルを、端末上で変換装置５００に入力することで、ｃＦＥ上で実行可能な実行形式に自動変換することができ、開発者がＲＯＳの開発環境で生成したソースファイルをｃＦＥ形式に変換する際に要するコストを削減することができる。また、変換装置５００は、ＲＯＳの開発環境で生成したソースファイルをｃＦＥ上で実行可能な実行形式に自動変換することで、手作業で変換した場合に発生する可能性の高い変換間違い等を抑止することができ、ロボットアプリケーション３００の仕様共通化および標準化することができる。
【００２９】
［利用環境］
図７は、インターフェース装置１００および変換装置５００の利用環境の他の一例を示すユースケース図である。
【００３０】
プラットフォーム管理者は、ロボットアプリケーション３００の開発ガイドライン、変換装置５００のユーザマニュアル、および変換装置５００をロボットアプリケーション３００の開発者に提供する。ロボットアプリケーション３００の開発者は、プラットフォーム管理者によって提供されたロボットアプリケーション３００の開発ガイドラインおよび変換装置５００のユーザマニュアルに基づいて、ＲＯＳ開発環境でロボットアプリケーションを開発し、ソースファイルを作成する。開発者は、作成したソースファイルおよび作成したソースファイルが参照するＲＯＳメッセージ定義ファイルを、変換装置５００によってｃＦＥ２００上で実行可能なソースファイルをパッケージングする。
【００３１】
プラットフォーム提供者は、結合試験環境（例えば、Ｌｉｎｕｘ等によって実現される）にインターフェース装置１００を提供する。開発者は、結合試験環境においてロボットアプリケーション３００がｃＦＥ２００上で想定通り制御されることを確認する。結合試験により品質を担保されたロボットアプリケーション３００は、宇宙機に搭載されるターゲットボード上で実現されるリアルタイムオペレーティングシステム（Real-time operating system；ＲＴＯＳ）と併せて宇宙機の備えるプロセッサの記憶部に記憶される。
【００３２】
［利用例］
図８は、プラットフォーム１Ａを示す概略構成図である。図８は、インターフェース装置１００が利用される一例である、スペースデブリ捕獲機能を有する宇宙機のプロセッサに搭載されるプラットフォーム１Ａである。
【００３３】
図８に示すプラットフォーム１Ａは、例えば、ＣＦＳ標準アプリケーションであるＨＫ（Housekeeping）アプリケーション２５０を備える。ＨＫアプリケーション２５０は、ｃＦＥ２００上で実行されるＣＦＳ標準アプリケーションおよびロボットアプリケーション３００のログ情報を収集し、テレメトリデータを作成する、ＣＦＳ標準アプリケーションである。ＨＫアプリケーション２５０は、「データ生成部」の一例である。
【００３４】
また、図８に示すプラットフォーム１Ａは、例えば、ロボットアプリケーション３００として、メイン制御アプリケーション３００−１、およびロボットアーム制御アプリケーション３００−２を備える。
【００３５】
以下、メイン制御アプリケーション３００−１およびロボットアーム制御アプリケーション３００−２によるロボットアーム制御処理について説明する。まず、メイン制御アプリケーション３００−１がロボットアーム制御アプリケーション３００−２に実行要求メッセージを送信する処理について説明する。
【００３６】
メイン制御アプリケーション３００−１は、ロボットアーム制御アプリケーション３００−２に対する実行要求メッセージを、ｃＦＥ２００を介してロボットアーム制御アプリケーション３００−２に送信する。このとき、インターフェース装置１００は、メイン制御アプリケーション３００−１により出力されるロボットアーム制御アプリケーション３００−２に対する実行要求メッセージを一時保管する。インターフェース装置１００は、ｃＦＥ２００のメッセージ送受信タイミングに応じて、一時保管したロボットアーム制御アプリケーション３００−２に対する実行要求メッセージを、ｃＦＥ２００に送信する。ｃＦＥ２００は、メッセージ送受信タイミングに、インターフェース装置１００により送信されたロボットアーム制御アプリケーション３００−２に対する実行要求メッセージを、ロボットアーム制御アプリケーション３００−２に送信する。
【００３７】
次に、メイン制御アプリケーション３００−１およびロボットアーム制御アプリケーション３００−２によるロボットアーム制御処理について説明する。なお、以下の説明において、上述の実行要求メッセージを送信する処理と同様の処理については、「実行要求送信処理」と称する。ロボットアーム制御アプリケーション３００−２は、ロボットアーム制御アプリケーション３００−２の制御対象であるロボットアームの関節情報（例えば、ＲＯＳのsensor msgs/JointState型メッセージ）を含む実行要求メッセージを、インターフェース装置１００およびｃＦＥ２００を介して、メイン制御アプリケーション３００−１に送信する実行要求送信処理を行う。
【００３８】
メイン制御アプリケーション３００−１は、ロボットアーム制御アプリケーション３００−２により送信された実行要求メッセージを受信した後、実行要求メッセージに含まれる関節情報を解読してロボットアームに行わせる動作に関する制御演算を実行する。メイン制御アプリケーション３００−１は、ロボットアームに行わせる動作に関する制御演算の実行結果である、関節制御に関する指令（例えば、std msgs/Float64MultiArray型メッセージ）を含む動作指令メッセージを生成し、ロボットアーム制御アプリケーション３００−２に送信する。
【００３９】
ロボットアーム制御アプリケーション３００−２は、メイン制御アプリケーション３００−１により送信された関節制御に関する指令を含む動作指令メッセージを解読して、ロボットアーム制御アプリケーション３００−２の制御対象であるロボットアームに関節制御に関する指令を実行させる。ロボットアーム制御アプリケーション３００−２は、ロボットアームに実行させた制御結果を反映した関節情報を再生成し、ロボットアームの関節情報を含む実行要求メッセージを、メイン制御アプリケーション３００−１に再度送信する。
【００４０】
メイン制御アプリケーション３００−１およびロボットアーム制御アプリケーション３００−２は、上述のロボットアーム制御処理のような実行要求メッセージの送受信を繰り返すことによって、ロボットアーム制御を実現する。以上説明したように、ＲＯＳで開発されたアプリケーション間の実行要求メッセージの送受信をｃＦＥ２００上で実現する場合に、インターフェース装置１００を介して実行要求メッセージの送受信を行わせることで、ｃＦＥとＲＯＳとのメッセージ送受信の仕様の違いを解消することができる。
【００４１】
なお、ＨＫ送信アプリケーション２６０およびＨＫ受信アプリケーション２７０は、ＣＦＳ標準アプリケーションであるＨＫアプリケーション２５０を中継して実行要求メッセージを送受信するＲＯＳで開発されたアプリケーションである。ＨＫ送信アプリケーション２６０は、上述の実行要求送信処理と同様に、図８に示すプラットフォーム１Ａにおいて、インターフェース装置１００、ｃＦＥ２００およびＨＫアプリケーション２５０を介して、ＨＫ受信アプリケーション２７０に実行要求メッセージを送信することができる。このように、インターフェース装置１００は、ＲＯＳで開発されたアプリケーションと、ＣＦＳ標準アプリケーションとの間の実行要求メッセージの送受信を可能にすることができる。
【００４２】
上述のＲＯＳによるロボットアームを制御するアプリケーションは、開発事例が多数存在しており、ＲＯＳ開発者およびＲＯＳ研究者の知見は豊富であるといえる。インターフェース装置１００および変換装置５００によって、ＲＯＳ開発環境により開発されたロボットアプリケーションをｃＦＥ２００上で実行されるロボットアプリケーション３００が実現することで、ＲＯＳ開発者およびＲＯＳ研究者の知見を宇宙機にも転用することができる。
【００４３】
以上説明した実施形態のインターフェース装置１００によれば、仲介部１２０がロボットアプリケーション３００から他のロボットアプリケーション３００に対してｃＦＥ２００を介して送信される実行要求メッセージを一時的に保持し、制御部１４０が仲介部１２０によって一時的に保持される実行要求メッセージの送受信を制御することによって、ＲＯＳで開発されたロボットアプリケーションをｃＦＥ２００で動作可能となり、既存の宇宙機向けソフトウェア基盤において、ＲＯＳで開発されたソースコードを実行可能とすることによって、ＲＯＳによって開発されたロボティクス技術を宇宙機向け開発により平易に取り入れることができ、宇宙機向けシステム開発の仕様共通化および標準化を推進することができる。
【００４４】
以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【符号の説明】
【００４５】
１、１Ａ…プラットフォーム、１００…インターフェース装置、１１０…受信部、１２０…仲介部、１３０…送信部、１４０…制御部、２００…ｃＦＥ、２５０…ＨＫアプリケーション、２６０…ＨＫ送信アプリケーション、２７０…ＨＫ受信アプリケーション、３００…ロボットアプリケーション、３００−１…メイン制御アプリケーション、３００−２…ロボットアーム制御アプリケーション、４００…ＰＣ、４５０…ＯＳ、５００…変換装置、５１０…受付部、５２０…変換部、５３０…出力部
【図１】
2019211854.tif 000003
【図２】
2019211854.tif 000004
【図３】
2019211854.tif 000005
【図４】
2019211854.tif 000006
【図５】
2019211854.tif 000007
【図６】
2019211854.tif 000008
【図７】
2019211854.tif 000009
【図８】
2019211854.tif 000010