6自由度デバイスでのLinuxアプリケーション制御を可能にするlibsixdof
という前置きを聞かされたとしても、こうしたデバイスがデスクトップアプリケーションにおいて何の役に立つのかイメージできないという方もおられるだろう。そうした場合はビデオの可変速再生にデバイスの軸回転を、あるいはスライドショーの画像切り替えにデバイスのx軸を割り当てた場合の操作感を想像してみて頂きたい。
とは言うものの、ビデオプレーヤの再生速度を10パーセントに落とす指定などはキーボード操作の1つにマッピングすることは不可能ではないし、スライドショーの画像切り替えなども通常はスペースキーの押し下げに割り当てられているものである。ところが6DOFデバイスの場合はx軸方向の移動1つを取り上げても、こうした操作はオン/オフだけで終わるものにはなっておらず、例えば全ストローク長の25パーセントまで押し込んだ場合よりも目一杯押し込んだ場合は1秒当たりに切り替えるスライド数を多くするといった操作が可能となるのだ。同じくビデオプレーヤの場合も、ダイヤルの最大回転を20倍速再生に割り当てておき、これをニュートラルに戻すだけで通常再生ないし一時停止になるようにすることができる。後者の場合、要は6DOFデバイスをジョグシャトルとして使用させる訳だ。
こうした6DOFデバイスを各種のアプリケーションにて簡単にサポート可能とするために私が作成したのが、本稿で解説するlibsixdofである。libsixdofの開発時に念頭に置いておいたポイントの1つは、6DOFデバイスをサポートさせる上でアプリケーション側に加える変更を必要最小限のものとする（小型のパッチとする）ということであった。その他に想定しておいたのは、各種のアプリケーションの有す様々な機能を制御する関係上、例えばデバイスに装備されたボタンの1つを軸移動と傾き操作の切り替えスイッチに割り当てるなど、6DOFデバイスに対する基本モード以外の細かな設定もできるようにしておくことである。デバイス入力に対するこうした設計思想に関しては眉をひそめる方もおられるかもしれないが、私としては、デバイス側で許された多様なアクションを自分の好みとする方式にて各種アプリケーションの操作に割り当てられるようにしたかったのだ。
libsixdofにて特定アプリケーションをサポートさせる際に行うべき措置は、X Windowをlibsixdofに登録すること、libsixdofにX Eventを認識させてデバイスからのイベントを監視させること、呼び出し可能な関数テーブルの設定をすることの3つである。こうした準備さえ済んでいれば、デバイス側で発生するイベントのアプリケーション側関数へのマッピングおよび、これらの呼び出しについては、libsixdofライブラリが自動的に処理をしてくれるようになる。
libsixdofにて登録できる関数は、トリビアル（trivial）関数および呼び出し可能（callable）関数という2つのタイプに分けられている。このうち前者は引数を伴わない関数であるのに対して、後者は浮動小数点形式の引数を1つだけ使用するようになっており、こうした呼び出し可能関数に渡す浮動小数点値とは、デバイスの各軸がどれだけの力で押し込まれているかを示す情報に他ならない。例えばデバイスのx軸操作をx方向のパン操作（pan-x関数）に割り当てている場合、x軸方向に移動可能な全ストロークの50パーセントが押し込まれた状況にてpan-x関数に渡される引数は0.5という値になるのである。このように引数形式で呼び出し可能関数にデバイスの操作圧力を渡す方式に関しては、この場合の例で言うと、キャンバス上の同一距離をパンする際におけるアプリケーション側の関数呼び出し回数を節約できる効果があり、その分だけlibsixdofを介したパン操作がスムース化されるというメリットを有している。
こうしたデバイス操作に対してアプリケーション側をどのように反応させるかのユーザ設定とは別にlibsixdofでは、デバイスによるX Eventの処理をアプリケーションから独立させておくことで、デバイス操作に対するユーザによる補正および非線形なマッピングが施せるようにしてある。つまりlibsixdofを介した6DOFデバイスによるアプリケーション制御については、最初はアプリケーション開発者の定めたデフォルト設定にて6DOFデバイスを使用し始めてもいいのだが、最終的にどのような感度で利用するかは、アプリケーションの開発者ではなくユーザが調整できるようにしておくという訳である。
ここで先に触れた補正という機能の意味を、LinuxにてGIMPのサポートする/dev/inputデバイスを例にして説明することにしよう。X Windowに6DOFデバイスという組み合わせを使用していない場合、/dev/inputデバイスのリードアクセスについては、GIMPにこのデバイスを監視させ、当該デバイスからのイベント受信時にはInputプラグインを用いて必要なGIMPの機能を実行させるという処理になるはずだ。ところがこのInputプラグインには、デバイス側からの入力を調整するような機能は何もサポートされていないのである。つまりこの状態のままで6DOFデバイスのz軸操作をカレントウィンドウのズームインに割り当てたとしても、このデバイスをどれほど微妙に操作しようが、ユーザの行う繊細なタッチとは無関係に特定レベルのズームインが一気に実行されるだけなのだ。これに対して補正機能をサポートしたlibsixdofを用いた場合は、z軸操作によるズームインをより穏やかなものとするよう、ライブラリを介してユーザが調整を施せるのである。つまりズームインが一気に行われるような反応は敏感すぎるのであり、この場合はそうしたデバイス操作に対する感度を意図的に下げる形でよりスムースなズームイン操作を可能とするのだ。同様に“デバイスのx軸方向に100パーセントのストロークをさせた場合は1秒当たりの画像移動数を5枚にする”という設定もlibsixdofを介することで指定可能となる。
非線形マッピングは今のところ未実装ではあるが、その基本的な考え方は1つの軸で行う操作を非線形な対応関係でアプリケーションに伝達させるというもので、これにより例えばx軸で急激な操作をした場合は、実際の変動分を大幅に増幅させた形でアプリケーション側の関数呼び出しを行えるようになるのである。
libsixdofのユーザ設定は、各自のhomeディレクトリに置かれる.libsixdofrcファイルにて行うようになっている。このファイル中には制御対象とする各アプリケーションのセクションを設けて、デバイス側の各アクションにアプリケーション側のどの機能を割り当てるかという指定をlibsixdofに認識させなくてはならない。下記に抜粋したのはlibsixdofrcファイルの一部で、この冒頭部に置かれているのはグローバルなデバイス設定情報であり、axis_で始まる行がデバイスに対する補正を指定している部分である。これらのうちaxis_move_minval_cutoffという設定は、いずれの自由度の軸操作についても全ストロークの40パーセント未満のものはlibsixdofにて切り捨てさせ、アプリケーション側には伝達させないという指示を意味している。つまりこのサンプルにおける比較的高めに設定されたaxis_move_minval_cutoffの役割は、仮に操作に不慣れな初心者ユーザが目的とする軸を40パーセント動かした際に隣接する軸を意図せず10パーセント程度動かすことがあっても、後者に対応する関数呼び出しは行わせないようにすることなのである。
axisおよびbuttonsとされた各セクションは、デバイス側で操作する個々の軸およびボタンに対する名称の設定部である。Linuxにとっては“第7軸の移動”という情報でも構わないかもしれないが、人間にとってはそうした無機質な番号よりも“yaxisback”などの名称の方が覚えやすいので、ここでは個々のデバイス操作を関数にマッピングする際の負担を軽減させる一環として、番号指定の代用となる名称を使えるようにしておいた。特に6DOFデバイスの中には10個以上のボタンが装備されている製品もあるので、例えばボタン17はデバイスの左側にあるボタンといった情報については、それを反映した名称で代用させられるようにしたのである。以下、この設定ファイルの後半部では、こうした軸とボタンに割り当てた名称を用いた指定が行えるようになっている。
使用するアプリケーションについては、この設定ファイルにてそれぞれ専用のセクションを設けなくてはならない。例えばこのサンプル設定においてはfehというイメージビュワーの制御指定が記述されており、各種の軸操作に対してアプリケーション側の諸機能がどのように割り当てられているかという様子が見て取れるはずだ。ここで使われているperiodという引数は1秒間における関数呼び出しの最大回数をlibsixdofに指定するためのもので、デバイス側の軸操作をアプリケーション側の動作に反映させる感度はこの数値によって調整できるようになっている。サンプル中には表示されていないが、ボタン操作に関する機能割り当てもこれらと同じ位置に記述しておけばいい。こうしたappセクションは、libsixdofを介して制御する各アプリケーションごとに個別に設定していくことになる。
version=1
axis_move_minval_cutoff=0.40
axis_max_per_second_neg={ 46000, 46000, 21000, 25000, 25000, 35000 }
axis_max_per_second_pos={ 57000, 57000, 28000, 25000, 25000, 18000 }
axis
{
number=6 name=xaxisleft
number=0 name=xaxisright
number=7 name=yaxisback
number=1 name=yaxisforward
number=8 name=zaxisup
number=2 name=zaxisdown
number=9 name=xtiltaway
number=3 name=xtilttowards
number=4 name=ytiltleft
number=10 name=ytiltright
number=11 name=zrotationanti
number=5 name=zrotationclock
}
buttons
{
number=17 name=left
number=18 name=right
}
app=feh
{
axis=xaxisright period=10 function=slideshow-next
axis=xaxisleft period=10 function=slideshow-prev
axis=yaxisforward period=6 function=yaxis
axis=yaxisback period=6 function=yaxis
axis=zaxisdown period=10 function=zoom-in
axis=zaxisup period=10 function=zoom-out
axis=xtilttowards period=20 function=move-up
axis=xtiltaway period=20 function=move-down
axis=ytiltleft period=20 function=move-left
axis=ytiltright period=20 function=move-right
axis=zrotationclock period=6 function=rotate-clockwise
axis=zrotationanti period=6 function=rotate-anticlockwise
}
こうしたlibsixdofにおける関数テーブルの役割としては、アプリケーションに割り当てられた各機能の説明を書き留めておくという意味も有している。将来的な展望としてこうした情報については、操作性に優れたグラフィカルインタフェースを介して開発者側からユーザに提示するようにすべきだろう。
マルチウィンドウ型のアプリケーションの場合、libsixdofに登録したアプリケーションの各ウィンドウごとに名称割り当てを行うことになるが、この設定ファイルの将来的な拡張として、appセクション内部にサブセクションを追加するようにし、1つのアプリケーションにて管理対象とする各ウィンドウごとにデバイス割り当てを個別設定をできるようにすることも検討している。
まとめ
libsixdofをサポートしたfehは現状でCVS版の段階に置かれており、またKDE 3.xのKPhotoAlbumについてはサポート用パッチが存在している。その他MPlayerおよびGIMPもパッチ作成のリストに載せられてはいるが、実際のリリース時期は開発活動にどの程度の時間を割けるかで左右されるはずである。
本稿で解説したlibsixdofおよび同様のライブラリの開発が今後進んでいけば、6自由度デバイス（6DOFデバイス）のサポートもより一般化するであろう。そうした暁には、この種のデバイスをコンピュータ本体に接続するだけで、ミュージックプレーヤやビデオプレーヤだけでなくWebブラウザなどの操作も行えるようになるはずである。また、呼び出し可能な関数を介してアプリケーションの内部的な機能にアクセス可能とするDBusなどのテクノロジを取り込むことができれば、本稿で解説したサポート対象のアプリケーションに対するlibsixdofの設定負担も大幅に軽減できるかもしれない。
Ben Martinは10年以上にわたってファイルシステムに取り組んでおり、博士課程の修了後、現在はlibferris、ファイルシステム、検索ソリューションを中心としたコンサルティング業に従事している。
