2011-03-23

Kinectプログラミングはじめの一歩 ~OpenNiインストールメモ~

本ラボでもついに、Kinectに手を出します。さっそく試してみたのですが、導入で結構つまずきました。Kinectプログラミングをする際のライブラリとして世間では
  • OpenKinect
  • OpenNi
が代表的のようですが、ここでは後者のOpenNiのインストールについてメモ書きします。なお、インストール環境は、Windows7です。64bit/32bitの両方での動作を確認しました。

必要なファイル
の3つです(ファイル名のバージョンは変わってくるでしょう)。ここで重要なのは、これらのライブラリにはいろいろなバージョンがあるのですが、すべて stable または unstableに統一しておかないと、エラーがでるようです。ダウンロードする際は、自分がどのバージョンを選択しているのかよく確認しましょう。

1.ドライバのインストール
SensorKinectの中にドライバがあります。(avin2-SensorKinect-b7cd39d\Platform\Win32)。デバイスマネージャーを利用してこのディレクトリを指定することで、デバイスのPrimeSensor内に
  • Kinect Camera
  • Kinect Motor
がデバイスとして表示されます。

2.OpenNiのインストール
OPENNI-Win32-1.0.0.23.exeを実行し、OpenNiをインストールします。

3.SensorKinectのインストール
avin2-SensorKinect-b7cd39d\Bin内にあるSensorKinect-Win32-5.0.0.exeを実行してインストールします。

4.PrimeSenseNiteのインストール
NITE-Win32-1.3.0.17.exeを実行してインストールします。インストールをする際に、ライセンスキーの入力を求められますので、「0KOIk2JeIBYClPWVnMoRKn5cdY4=」と入力すればOKです。


以上により、とりあえずサンプルプログラム(C:\Program Files\OpenNI\Samples\Bin\Debug)は動くはずです。他のサイトを見るといろいろ設定ファイルの修正等や環境変数の設定などが書いてますが、私の環境では、特に設定しなくても動きました(同じようなことを書いているサイトもありました)。例えば、NiSimpleView.exeは動きました。動かない場合は、各種設定ファイルを修正も試してみてください。修正のポイントは、設定ファイル内にあるライセンスキーの追記などです。
それと、もしかすると上記のインストールの順番も関係してくるかもしれません(未確認)。上に書いてある順番が正しいかどうかは実は不明です。

なお、私も今回はいろいろ試行錯誤したのですが、一番のポイントは、最初に書いたようにバージョンの統一です。私はstable版で統一しました。ダウンロードサイトがいまいち分かりにくく、違うファイルをダウンロードする恐れもありますので、上記のファイル名を参考にしてみてください。


2010年度卒業式を終えて

(おくれましたが)卒業おめでとうございます。

3/19に本ラボからは9名が巣立ちました。大学院に進学する者、就職する者、就職活動を続けている者、、、進路はいろいろありますが、皆さんに共通して言えることは、「これから新しい人生のステージが始まる」ということ。そしてそれは、コンピュータゲームのようにリセットされたものではなく、今までの生き方の続きであるということ。4月から急に全てが変わるというわけではありません。全ては継続なのです。

2名が各賞を受賞
さて、本ラボからは、学部長賞、学科同窓会賞の受賞者がそれぞれでました。


学部長賞を受け取るイチシマ君。



学部同窓会賞を受け取るタニグチ君

二人とも、4年間での学業の努力が認められました。

卒業生への言葉
学科卒業証書授与式において、学科長のお話はなかなか興味深い話でした。それを踏まえて私なりに、卒業生に送る言葉を書いてみます。

近年の日本では、システムのトラブルが話題になることが多いですが、この度の地震とそれにともなう原発のトラブルから、日本の産業(社会)に潜む大きな問題がみえてきます。それは、
  • リスク対応能力の欠如とその要因となる産業の構造
です。

日本の社会は、敗戦の後に奇跡的な復興と遂げ、経済大国になりました。敗戦後65年経った今、私たちの社会は、年輩の方々が作り上げたシステムの上で成り立っており、そのシステムを土台にして社会・経済を発展させているわけです。私たちは既に作られたシステムのブラックボックスの上にいるわけです。私自身もシステム開発(プログラミング)をする際には、全くゼロから作るわけではなく、既存のライブラリをよく利用します。ライブラリの中身はブラックボックスといえます。研究上、プロトタイプシステムの開発効率を挙げるためのテクニックとも言えます。

しかし、それはブラックボックスのままでいいのでしょうか?特に実社会で動いているシステムならば、ブラックボックスの部分にバグがあったりすると、その中身について対処しなければいけません。今、日本ではブラックボックスを創り上げた人たちは、もう第一線から退いています。もし、なにか大きなトラブル、それもブラックボックスの部分にトラブルが生じた時、それに対応できないという状況が今の日本に起きている気がします。

これは、過去から続いているシステムだけの話ではありません。新規の製品開発においても、自社開発をせず、アウトソーシングにより対応するケースは多いと思います。これもシステムのブラックボックス化です。昔と比べるとシステムの規模が膨大になっているわけですから、そうせざるをえないという状況は理解できますが、ブラックボックスの技術に無知なままでシステムを販売・運用していくと、大きなトラブルに対応できなくなるおそれがあります。

心配しすぎ、、、と思うかもしれませんが、個人的にはなんとなくこれからの日本は、様々な面でシステムの歪みが表面化し、トラブルやエラーが多発してくる時代がやってきているのではないかという気がしてます。そのために、「自らモノを造る」という原点に帰って、より高品質なシステムにつくり直すことが求められるのではないかと、、、そのためにも、ものづくりの「技術」の大切さを忘れないで欲しいと思います。