AR.Drone + Flash + Kinect 連携（ほぼ失敗…）

AR.Drone を Flash をハブにして Kinect と連携させればなんか面白いことが出来るのではないかと思って始めてみたオレオレプロジェクトでしたが…

ひとまずテイクオフまでは出来ました。

というわけで、とりあえずテイクオフだけはできた映像

映像ではテイクオフのカットしか映っていませんが、実はテイクオフまでではなく移動や回転の操作も少しできました。
では、他の操作もできたのになぜテイクオフまでなのかというと…

各アプリケーションと通信の負荷にプラットホームとして使用した Mac が耐えれませんでした…（´・ω・`）

では、何がどう耐えれなかったかということなのですが…
まず今回使用したシステムについて書き出します。

■ 今回の実験で使用したシステム

1. ハードウェア
・Mac : MacBook Air 2011（”13, Core i7）
・Kinect
・AR.Drone

2. ソフトウェア
・OpenKinect を使用した Processing で Kinect のトラッキング座標を取得するアプリ。
・ARDroneForP5 を使用した Processing で AR.Drone を操作できるアプリ。
・OpenKinect からRGB 画像を取得して映像として画面に表示したり、座標情報を取得してジェスチャーに変換して ARDrone 操作アプリと連携して AR.Drone を操作するための Flash アプリ
・上記3つのアプリ間の通信はバイナリソケット。

と、こんな感じでした。

もうこれでだいたい察しは付くかと思いますが、たかが AR.Drone を飛ばすために Processing のアプリ2つと Flash のアプリ1つを使用していること、また、アプリ間のパラメータ送受信のためにソケットを3つも立ち上げていたため Mac の CPU をほぼフルパワー使わないと動かないといけないという悲惨な結果になってしまい…
テイクオフした数十秒後にはアプリケーションが応答しなくなるという「そうりゃそうだよね」的な現象が発生し、Drone が操作不能になってしまいました w

特に AR.Drone を操作する Processing アプリの負荷が大きく、Drone からのカメラ映像を受信していることもあるのか、または Processing は未だによく分かっていない僕がなんかやってはいけないことをやってしまっているのかは分かりませんが、今回使った MacBook Air だと、このアプリだけで CPU の半分近くを食われる結果となってしまいました。

というわけで、このままでは Kinect と連携しつつ Flash でなんか面白い演出をなどといった大それた妄想は実現できそうにありませんので、今回の問題を解消するためには時間がかかるということだけが分かった週末となりました。

ただ、今回の実験の副産物というわけではありませんが、AR.Drone をルータにして接続する WiFi 環境で RTMFP が使えるということが判明しましたので、次からは「AR.Drone と RTMFP を組み合わせて何かやる」実験を行ってみたいと思います。