ROSとRTMの違い：モデルベースなシステムエンジニアリングの視点から

どうも．ysugaです．ちょっと気づいたことをメモしておきますね．

どうも仕事ではROSの方が使用頻度が高くなっていますが，個人的にはRTM (RTミドルウエア) 支持派なので，読む方はそういう視点で書いてることを気に留めて読んでくださいね．

1. はじめに

さて，RTMとROSの基本的なことについては，このウェブサイトの入門記事の最初の内容を読んでもらうとして，すこしモデルベースな行程でロボットシステムを作ろうという視点から比べてみた話です．
結論的には，ROSはモデルベース開発には向いてないかも・・・間違ってたら教えて！・・・という結論．今後に期待してますけど．

モデルベースシステム開発というのは，OMGが推奨している開発行程のスタイルで，SysMLという規格に乗っ取った形でドキュメントを作っていって，そこから自動生成を使ってシステム開発を進めていきましょう．という話．
これをROSでもRTMでもやれるようにしたくて，自作のツールを作ろうとしてたのですが，ROS側には，RTCプロファイルにあたる，ノードの機能を宣言するようなドキュメントや，起動中のノードの機能を取得するイントロスペクションのような機能が少ないので，これが難しいということがわかったので報告しますね．

2. モデルベースシステム開発の利点

モデルベース開発で何がうれしいかというと，それまで作ってたものや，誰かが作ったものを再度掘り起こすときに，ドキュメントが残ってるという点です．開発行程とドキュメント生成を同時に行うことができますので，ツールがそれを意識させません．ここで言うドキュメントというのは，文字がたくさん書かれている説明書，では無くて，そのコンポーネントの入出力を定義した設計図です．

僕は2012年4月から独立して，11月から株式会社として，社員は僕一名ですが，ロボットソフトウエアの受託開発などの仕事をするようになっています．
独立したくらいからゆっくりとSysMLを勉強している程度です．UMLについては学生のときに学びましたが，大学の研究室で，しかも機械系で，UMLを学生と共有して使うには技術的な壁が大きいな，と思いました．
一方で，仕事として開発していると，お客様と会話するためにシステムの俯瞰がどうしても最初に必要です．また，要求仕様に対する検討過程を視覚化することも必要で，これについてもSysMLは要求を図化して構造的にプレゼンテーションすることができる上，僕が使ってるツールのastahでは，そこから対照表を作ってお客様と会話することができるようになっています．おそらくEAでもできるでしょうね．
ただ，仕事的には超短期の仕事が多くて，ツールをかなり使いこなさないと，僕の業務では使えないな，と思っていましたし，今も半分はそう思っています．

ロボットのシステム，とくにソフトウエアのシステムを構築する上で，SysMLのように全体の俯瞰を最初に得られるツールを，ROSでも作っておきたい，というのがモチベーションで，ツールを作ることにしました．

3. 最初の要求仕様

ROSでモデルベース開発するために，RTMと同様の設計過程を経て開発するためのツールを考えました．

僕が知る限りでは，rxDeveloperというツールがこれに近いものを提供しています．
https://code.google.com/p/rxdeveloper-ros-pkg/

起動中のノードからプロファイル（rxDevではspecfileと呼んでます） (.node) を生成したり，システム全体を設計しながらlaunchファイルを作ったり，それのデバッグもツール内でできるらしいです．そこまで使いこなしてませんが．
残念ながらメンテナンスが止まっていますが，catkinに対応させて欲しいところです．とりあえず手元では対応させましたが．
ROSのみの利用なら，このツールで問題ありませんが，SysMLの形にして，RTMでもROSでも独立してシステムを記述できて，プレゼンできるツールが欲しい点で，僕には独自で開発する必要があったわけです．
あ，rxDevはこれはこれでいいんですけどね．

要求としては，

１．既存のノードの機能を記述するプロファイルが自動生成できること
２．SysMLとノードのプロファイルをマップして，SysMLのブロック定義図でROSのシステムを記述・検討できること
３．ブロック定義図からlaunchファイルおよびノードのひな形が生成できること

んで，Python版のみの対応をとりあえずのスタートポイントとしました．

ちなみにRTMにはすでにこれと同じ機能があります．
開発時に作ったRTコンポーネントプロファイルが，そのままRTCがどのような入出力があるのか，それぞれのポートにどのような機能が割り当てられているのかわかるようになっており，実際の行程では，RTCプロファイルからRTCのコードのひな形を生成することができるので，開発行程＝ドキュメント生成のような形になっとります．実際にはツールがそれをあまり意識させませんが．

んで，そのRTCプロファイルを使って，システムの全貌を最初に俯瞰することができます．このサイトでも解説していませんが，RTシステムエディタのオフラインシステムエディタなどがその機能を持っています．後述しますが僕もそういうツールを開発しています．

そもそもRTM界隈では以前からMBSEは盛り上がっていて，astah* SysMLというツールからRTシステムのひな形を生成することができるようになるらしいです．これはチェンジビジョンさんが開発してるとか．そもそもOMGで規格化してるわけですから，こういう話とは親和性が高い訳で，そこについては期待通りでした．

ロボット開発におけるSysMLの活用（株式会社チェンジビジョン　岩永 寿来） http://robopedia.sakura.tv/robot_contents/technologies/think/software/1710

UMLについてもastah，というかJUDEの時から使ってるので，使い慣れたツールがRTMに対応ということでかなりうれしい話なのです．

4. 理想と現実

結論から言うと，ROSのノードには実行時の情報からノードプロファイルを生成することはできません．問題は，
１．ParameterはROSMasterが一括で持つパラメータになっていて，それがどのノードで消費されるのかを追跡する機能がありません．
２．サービスの消費側を追跡できません．
上記２点から，完全なノードのプロファイルを実行時に生成することができませんでした．

１．には，そもそもMasterAPIにこの機能が無いので，ROSMasterに手を加えるしかなさそうです．これはめんどい．
２．はもう思想の違いですね．サービスに関しては場当たり的に消費することが前提としてあるので．

トピックだけを使ってる分には良いです．ノードがどのようなトピックを読み書き（出版購読）するのかが実行時にわかります．

rxDevでは，あらかじめamclやgmappingなどの一般的なノードのプロファイルを用意してあります．
たしかに，これで十分かもしれませんが，ちょっとイレギュラーな使い方をする人には不十分．

RTMはこれができます．できないように意地悪することもできますが(笑)，ほぼ実用十分なRTCプロファイルを実行中に情報収集して生成することができます．
たとえば，コードの改変時に変更されたポートやサービスについて，実行中にソースコード中のRTCプロファイルと対照確認することが可能です．

僕が作ってるwasanbonというツールでは，RTコンポーネントのgithubやbitbucket上のコードをリポジトリとして収集管理する機能を実装しています．
github上からRTCプロファイルだけダウンロードする機能もサポートしたので，あとはGUIを作るだけで，いまはブラウザで実行できるものを開発しています．
wasanbon_on_webとでも命名しましょうか．

RTシステムエディタやRTCビルダは，すでに産総研の原さんがブラウザ対応したものを作ってらっしゃいますから，これとマージするか，近いものを作れれば良いな，と思っています．
最終的には，Simulinkみたいに，リポジトリからRTCをD&Dで配置して設計できるものを作ります．

5. おねがい

上記２つの機能について，良いアイディアがあれば教えてほしいです．
とりあえずは，Parameterについては，Masterのパラメータをクリーンアップしてから，ノードを単体起動して，差分を取る，
サービスについてはあきらめる

という感じを考えています．

とはいえ，トピックだけでもあらかじめドキュメント化して生成できるツールは有用なので，気が向いたら作ります．