日記的「駄目」プログラミング Yet Another Hacking Life

Willow GarageがROSというロボット開発用ミドルウェア（ROSではメタOSと呼んでいる）を去年から公開していて最近になって話題になりはじめている。俺も最近知って、ドキュメントを流し読みしたりしている。

RTMがコンポーネントのデータ仕様を規定しなかったのに対し、ROSでは規程しているのがアーキテクチャの面での大きな違い。さらに「ロボット作るならこのデータいるよね」っていうロボットのコンフィグなどについてもファイル仕様（XML）を決めたりしている。大きいのはそうやって規定したデータ仕様にそった色々なセンサのドライバ（カーネルレベルのドライバではなく、センサを読み取って他のプロセスへ配信するソフトウェアのこと）を公開しているのが大きな特徴と言える。OpenCVが成功した一番の理由が「CvCaptureで馬鹿でもカメラ画像がとれるから」ということを考えればROSもかなり流行ると思う。流行るかどうかという点では実際ROSのページではROSを用いたロボット・論文の例が多数あげられている。

Matchaは何が違うかというのは危機を感じる問題で、ROSがMatchaのすべてをカバーするならMatcha作るの辞めなければいけない。

Matchaを簡潔に表すと「センサイベントを契機に駆動する、分散プロセスのロボットソフトウェアを開発するためのフレームワーク。およびプロセッシングライブラリとサポートライブラリ」ということになる。

「センサイベントを契機に駆動する」というのは裏にユーザスペースでのポーリングを廃すという意味がある。アプリケーションは純粋にイベントが発生したタイミングで動作を行うことを基本とする。センサやOSの機能の都合によりポーリングが必要になったとしてもドライバクラスで隠蔽する。周期処理が必要ならばタイマクラスを利用できる。

「分散プロセス」については柔軟で高効率なIPCの実装を目標にしている。具体的には搬送路におけるボディのフォーマットを規定しキーバリューコンテナのデータを搬送することで設計のしやすさと仕様変更の容易さ、分散開発の容易さを実現する。高効率なという点はまあ、そういうふうに実装しますよ。と。

「フレームワーク」についてはアプリケーションの実装方法を規定するという意味でAPIではなくフレームワークとなる。GUIフレームワークを使ったアプリケーションを書いたことのある人ならわかると思うが、「このタイミングでこの関数が呼ばれるからこういう風に実装してください」ということをフレームワークが規定する（だが、main()は君たちのものだ）。この点ではRTMに近いかも。ROSもイベントをフックできるけど、サンプルコードではイベントループをアプリケーション開発者が書くという前提だった（Matchaもやろうと思えばできる。アプリケーションクラスはイベント監視クラスを駆動するユーティリティクラスという位置づけになってる）。アプリケーションの実装方法を自由にするかフレームワークで縛るかは思想の問題だな。自由にすれば際限なくクソなコードも書けちゃう。逆にフレームワークに致命的な不自由があるとどうしようもない。

こうしてMatchaの目標を書き連ねると、RTMとROSの中間にいるっぽいな。孤軍奮闘ではあるが、趣味なので長期プレイだな。

フレームワーク部分のロードマップとしては以下になる。

1. シングルプロセスでのイベントモデルの実装 ← いまここ
2. マルチプロセスでの同期通信、非同期通信の実装
3. プロセス間通信のネットワーク透過

道は長い・・・。