データ変換を指向したロボット開発基盤ソフトウェア - Laboratory for Intelligent Dynamics and Representation

概要

本研究開発では，ロボットないしはロボティックなシステムのソフトウェア研究および開発用ミドルウェアを対象とし，より再利用性を向上しつつ，新規導入しやすい基盤ソフトウェアの設計論構築を目標としている．本研究では，従来のミドルウェア群に見られるコンポーネントベースのミドルウェアは，ソフトウェアの再利用性の観点から機能過多ではないか，と考えて設計を進めている．開発中の基盤ソフトウェアは，ソフトウェアの動的な機能側面である「振る舞い (Behavior) 」のうち，「データの変換 (Operation) 」に重点を置いている．これを本プロジェクトではOperation Based Middleware (OBM) と呼ぶ．

デモ動画

はじめに

近年，OROCOS[1], OpenRTM-aist[2]やROS (Robot Operating System) [3]，ROS2のようなロボット用ミドルウェアの利用が広がるにつれ，投稿論文の実装を先行してオープンソースソフトウェアとして公開するなど，知識と技術の共有・再利用が盛んになりつつある．

本研究開発では，上記のようなロボットないしはロボティックなシステムのソフトウェア研究および開発用ミドルウェアを対象とし，より再利用性を向上しつつ，新規導入しやすい基盤ソフトウェアの設計論構築を目標としている．開発中の基盤ソフトウェアは，ソフトウェアの動的な機能側面である「振る舞い (Behavior) 」のうち，「データの変換」に重点を置いている．これを本プロジェクトではOperationと呼ぶこととする．従来のミドルウェア群に見られるコンポーネントベースのミドルウェア (Component-based Middleware) のように静的要素であるコンポーネントを置くことなく，本提案ではOperationの組み合わせによってシステムの基本設計を可能とする．
本提案における基盤ソフトウェアは，従来のコンポーネントベースや，構造ベースのミドルウェアに対応して，Operationベースのミドルウェア (Operation-based Middleware, 以降OBM) と呼ぶこととする．

従来研究

ROSやROS2，OpenRTM-aistは，コンポーネント指向の分散システム構築を前提とした機能提供を行っている．ここでのコンポーネントとは，ソフトウェアの機能と状態をカプセル化し，定義されたインターフェースに従ってその機能を提供するソフトウェアモジュール単位である．OpenRTM-aistでは，Robotic Technology Component (RTC) が，またROSおよびROS2ではNodeという言葉で定義されるソフトウェア単位が基本となり，インターフェース定義言語 (Interface Definition Language, IDL) で定義されたインターフェースに従って，メッセージ指向の通信と遠隔手続き型の通信による機能提供，状態変更による機能調整を行うインターフェースをそれぞれ提供している．

本研究では，上記のようなコンポーネント指向での機能提供が，ソフトウェアの再利用性の観点から機能過多ではないか，と考えて設計を進めた．特にコンポーネントがソフトウェア単位ごとの「状態 (State)」を隠蔽してしまう点は，再利用性を低下させる一つの原因となることが多い．ここで述べる状態は，ソフトウェア全体の動作を代表するような状態変数 (例えばモードなどとも言われるもの) のみでなく，計算の途中経過などを保持している変数等もここでは状態と呼ぶ．コンポーネントの状態は，再利用性を十分に吟味したインターフェースを提供するコンポーネントでは通常，参照が可能だが，コンポーネントの粒度が大きく，またインターフェース設計が不十分な場合は内部変数へのアクセスが制限されるため，再利用性が著しく阻害される．

提案手法

本プロジェクトではOperationを基本要素として扱うOperationベースミドルウェア (OBM)を提案する．OBMではコンポーネントを「データの変換 (Operation)」と「状態 (State)」に分割して提供する方法をとる．OBMではコンポーネントなどの構造要素を前提とせず，Operationそのものとして存在することを許容する点で，これまで挙げたコンポーネント指向のミドルウェアと一線を画す．

Operation

Operationは状態を持たない入力と出力の間の変換のみで定義される．本提案ではOperationは出力を一つとり，入力は0から無限大の個数を定義可能とした．複数の出力を持つOperationを定義する場合はタプルとしてまとめて出力し，Splitterで分割してシステムを構成することで提供可能である．

Operationは外部から呼び出し (Call) を行うことができる．CallではOperationの全ての引数を送信し，変換結果を受信することができる非同期なリモート呼び出しサービスを提供する．

また，システムの効率的な運用を可能とするために，入力に直前の入力を保持するバッファを持たせ，バッファの値を使った呼び出しとして「実行 (Exe-cute)」を定義した．ExecuteはCallとは違い，引数を取らない遠隔呼び出しであり，Operationはバッファの値を使うか，もしくは後述するConnectionを使って情報収集をしながらシステムを動作させる．ExecuteについてはConnectionの項で詳説する．

Connection

OBMでは，Operation間は「接続 (Connection)」によって関連が定義され，相互に通信する．ConnectionはOperationの出力と，入力の一つをつなぐことができる構成要素である．
Connectionにはタイプが存在し，それぞれEvent型，Push型とPull型を定義した．Connectionのタイプは，そのConnectionを有するOperationがExecuteされた時に効果が発揮される．

ContainerとContainer Operation

Operationは状態変数を持たない単純な変換であったが，これのみではロボットシステムのソフトウェア構築はできない．特にハードウェアとの連携を前提とした場合，状態や変数の定義は避けられない．これについて提案システムでは「コンテナ (Con-tainer) 」の機能を提供する．ここで述べるContainerとは，単純な変数保持機能のみ提供する器であり，C言語であれば構造体によって提供される．

Containerには，内部の情報にアクセス可能なOperationとして，Container Operationを定義する．これは，Operationのうち，常に呼び出し時の第一引数にContainer内部のデータへの参照が与えられる特別なOperationであると説明できる．

Execution Context

上記までのOperationやContainerの羅列では，これらの機能を実行する主体が含まれていなかった．機能の定義と実行主体を分割して統治する手法についてはOROCOSではExecute Engine，またOpenRTM-aistではExecution Contextとして提供されており，本提案でもこれに倣い実行コンテキスト (Execution Context, EC) の機能を提供することとした．ECの本質はThreadであり，Thread内のループでOperationを実行するものである．

ECは全てSTOPとSTARTの二つの状態を持ち，START状態になることで機能を呼び出すことができる．

ECには種類があることを前提としている．例えば，Timer ECはSTART状態に結び付けられたOperationを，決められた周期で繰り返しExecuteする．また動力学シミュレータと同期するECなどを作ることも可能であるとする．

ジェネリック状態マシンの導入

本提案ではシステム全体の状態マシンを定義し，その変更に従ってECの状態遷移や特定のOperationの呼び出しをするGeneric Finite State Machine (Generic FSM, GFSM)を導入した．GFSMはコードではなくコンフィグファイルなどでスタート時の状態と任意の状態を定義できる．

このようなシステム全体の振る舞いを大きく変更する状態マシンは，システムがビジネスシナリオに従ってサービスを提供する場合に欠かせない機能である．このような状態マシンはバグの温床であり，コンポーネント内で独自のコードで実装した場合にはコンポーネント開発者の力量に左右される．

　状態マシンをフレームワークで提供することで視覚化・管理を行うツールは既に複数提案されている．OpenRTM-aistの準拠するRTC規格では， FSMコンポジットが提案されている．また関山らは状態マシン設計支援ツールZIPCを使ったRTCの設計・実装支援ツールを開発している[4]．ROSにおけるツールとしてはSMACHが提案されている [5]．

本提案のOBMのように要素単位を機能にしてモジュールの粒度を小さくしたことによって，ジェネリックな状態マシンを用意する準備が整った．

GFSMの状態遷移は外部のOperationの出力やツールによって行われることとした．

OBMを使ったシステムの具体例

本節はOBMを使った具体的なシステムの例として，ゲームパッドを使ったロボットの操作システムを挙げる．ハードウェア構成としては，一台のノートブックPCに，小型の移動台車とゲームパッドをUSBで接続した構成を前提とする．

図１にOBMで構成したソフトウェア・システムの例を示す．図中の楕円はOperationであり，オレンジ色の矩形はContainerを指す．Containerとの間を，中抜き円矢印で接続された楕円はContainer Opera-tionを示し，図中矢印はOperation間のConnectionとその方向を示している．本例では Connectionは全てEvent型とする．図中の黄色い矩形は読者の理解のために置いたConnectionを流れるデータのラベルであり，システムの構成要素ではない．

図中緑色の矩形はECを表し，START状態を表す内部の矩形からの矢印は，START状態への遷移が行われた場合にJoystick Get DataをExecuteすることを表している．

図中最上段の青い矩形はGFSMを示しており，図中の例ではRUNNINGとSTOPPEDの二つの状態を持つ．それぞれの状態から伸びる矢印は，接続先のOperationをExecuteすること，ないしは接続先の任意の状態に遷移させることを表している．

図中左のJoystick Get Dataは，コンピュータに接続されたゲームパッドのボタン状態 (Joystick Data) を出力する．図中真ん中のJoyToVelは，入力であるJoyStick DataおよびConfiguration Data (例えばスティックの倒し量とロボットの速度 [m/sec] の比) について処理を行い，Velocity2Dのデータを出力する．図中右のRobot Vehicle要素は，ロボットに指定された速度での移動を指示する．

図中においてJoyToVelのみが純粋なOperationである．オブジェクト指向の影響の強いシステムでは状態を持たない変換であっても，変換を提供する主体であるクラスやコンポーネントを定義しなければならないが，本来，単純な入出力変換であればクラスが提供する機能は冗長である．本提案では単純な変換であれば，図のように主体を定義せずにシンプルな変換であるOperationを提供することができるものとする．

図中左のJoystick Initialize, Joystick Get DataやVehicle Set VelなどはContainer Operationである．Joystick Initializeは，Joystick Containerに格納されている構造体を初期化する．通常は，デバイスファイルのパスを入力として受け取り，ファイルをオープンしてContainer内の構造体にファイルディスクリプタを格納する．Joystick Get Dataは，Joystick Containerに格納されたファイルディスクリプタでゲームパッドからデータを取得してJoystick Dataに整形して出力する．Vehicle Initializeは移動ロボットに指令値を送るデバイスファイルの初期化を行いVehicle Containerに格納し，Vehicle Set Velは，入力されたVelocity2D型のデータを変換し，Vehicle Containerに格納されたファイルにアクセスしてロボットハードウェアに命令を送信する．

図中のECではSTART状態に結び付けられた機能を周期的に実行するTimer Execution Context (Timer EC) を配置しているため，ECがSTARTになれば，周期的にJoystick Get Dataが呼び出されるシステムが実現されている．

図中のGFSMではRUNNINGとSTOPPEDの2つの状態を定義した．初期状態ではSTOPPEDにあるものとし，外部からのコマンドでRUNNING状態になると図中の矢印で接続されたOperationであるJoystick InitializeとVehicle Initializeを実行し，Timer ECをSTART状態にする．Timer ECは周期実行を繰り返しつつJoystick Get DataをExecuteし，出力されたデータが順番にJoyToVel, Vehicle Set VelをExecuteすることで，ロボット台車にジョイスティックで指示された目標速度が設定されることとした．

以上のように，実行コンテキストおよびジェネリック状態マシンを導入したことで，振る舞い指向ミドルウェアで簡易ながらも実際のロボットシステムを実行可能な設計が整った．

発表

菅佑樹，森裕紀，尾形哲也：データ変換に着目したミドルウェアモデルにおけるデバイス類の位置の扱いに関する議論，計測自動制御学会システムインテグレーション部門講演会SI2020，3A1-01，2020年12月18日．
菅佑樹，森裕紀，尾形哲也：データ変換を指向したロボットミドルウェアの提案，日本ロボット学会第38回学術講演会, 3K1-01, オンライン, 2020年10月11日.