The EyeTribeのAi-tracker ET-1000

用語：英語のITトラッカー/間欠泉トラッカーからのトレーシングペーパーはあまりよく聞こえませんが、「アイトラッキングデバイス」と「アイトラッキングデバイス」の翻訳は非常に面倒です。 ロシア語にもっと便利な確立された用語があるかどうかわからない-間違えたら教えてください







近年、Kinect（四肢、身体全体）、Siri（音声）、およびLeapMotion（指）は、非接触制御とデータ/テキスト入力が特定のタスクに非常に便利で直感的であることを示しています。 しかし、最近まで、同じタスクに視線を使用する可能性についてはほとんど知りませんでした。 主な理由は2つあります。a）すべてのデバイスが非常に高価（数千および数万ユーロ/ドル）であった、b）視線の方向を決定する精度が率直に足りなかった。 そして、トップ製品の精度がすでにかなり高い場合（約半度-目の改善が必要ですが、目の生物学的特性によりマウスカーソルの位置精度と同じレベルに達することはありません）、未使用の車の価格はこれらを行いましたデバイスは非常にニッチです。市場はマーケティング（ユーザービリティ調査、このトピックに関するHabréの記事がありました）、学術（大学での多様な研究）、医療（患者研究）、および「アクセシビリティ」（i-trackersを使用） 制御手段としての障害者）。



そして数年前、グループPh.D. コペンハーゲン工科大学の学生は、「アクセシビリティ」ニッチをコンピューティングデバイスのすべてのユーザーに拡大しようと試みました。 彼らの最初のi-トラッカーは、従来のウェブカメラのビデオストリームからビューの方向を計算する無料プログラム（ITU GazeTracker）でした。 確かに、赤外線LED自体を設定するか、カメラを購入する必要がありました（選択は非常に控えめでした）。 プログラムは機能しましたが、精度はすべての人に受け入れられず、高い不動性（デンマークで麻痺した人が使用）のみでしたが、これはすべてのフリー/オープンソースAIトラッカーに適用されました 従来の自家製カメラが主なボトルネックでした。





ITU GazeTrackerの作成者（左を除く）およびThe EyeTribeの創設者



ただし、Javier San Agustin Martin TallとHenrik Skovsgaardはこれにとどまらず、Sune Alstrup Johansenと共同でEyeTribeスタートアップを作成し、300万ドル以上の投資（Intelを含む）を受けました。 スタートアップの目標は、20,000ドル、つまり99ドルで販売されているものと同様の品質の手頃な製品を作成することです。 開発者は、9月に予約注文を開始し、12月から1月にデバイスの最初のバッチを送信したため、次のバッチは3月末までに準備できると述べましたが、一般的には終わりはありません。





EyeTribeによるET-1000



Tobii TechnologiesやSensoMotoric Instrumentsなど、iトラッカーの生産を支配している企業は、風が吹いている場所をすでに感じていたことに注意してください。たとえば、Tobii Technologiesは2年前にTobii REXを「開発者向けに排他的に」リリースしました（つまり、禁止されています） 1000ドルの研究またはビジネスでの使用）。 しかし、どうやら、製品はあまり人気がなく、閉鎖され、残りは価格の3分の1で販売されています 。 現在、同じ会社は、 Tobii EyeXを95ドル/€70で集中的に開発することで（今月末までに送付することを約束）、同時に新しいパテントトロールの品質に挑戦することで、The EyeTribeの急成長を維持しようとしています。 ほとんどの場合、ライセンスはTobii REXのライセンスと同じままです-豊富な西部の大学からこのような良いお金を得ることができるのであれば、なぜそれを変更するか...



だから、一ヶ月前、これは受け取られました：





ET-1000



非常に小さい-わずか20 x 2 x 2 cmで、他のメーカーの同様のデバイスよりも小さい。 また、ボックスには小さな三脚と非常に硬くて太いUSB 3.0ケーブルがあります。 ところで、USB 3.0は必要ですが、2番目のバージョンでは動作しません。 これ以上はありませんが、サーバーとSDKを使用してインストールソフトウェアを公式Webサイトからダウンロードできます。 また、他には何もありません、つまり 既製のコンピューター管理プログラムはありません（ Githubにいくつかのデモがありますが、これは開発者向けのチュートリアルにすぎません）。サーバーのGUIバージョンでのみ、検出された視点にカーソルを接続できます。 開発者は、そのようなプログラムの作成は他の人に任されていると書いており、彼ら自身が視点を決定するためにハードとソフトウェアに専念しています。 私は（他からの）彼らの一人であり、PRのシェアはわずかに低いです。



このデバイスのテスト（Win7 +で動作し、Andoid、Mac、Linuxのサポートが約束されている）は非常に好印象を与えました。 9ポイントでのキャリブレーション後（これは5ポイントのTobiiほど便利ではありませんが、それでもまだそれ以下は不可能です）、精度は約1度（40-50ピクセル-トップブランドよりわずかに悪い）でしたが、頭部の動きによるわずかな調整がありましたWin7 / 8の「閉じる/最小化」ウィンドウのボタンに入るのは非常に簡単でした。 長い間、私はテストしませんでしたが、これらの3〜4分間で精度は低下せず、目と瞳孔はほとんど常に検出可能なままでした。 照明が異なる別の場所では、目が時々「失われた」ことがありましたが、回復時間は短かったです（人為的、100〜200ミリ秒）。 一般に、これは私のお金にとって非常に価値のある結果であり、私の意見では、精度と信頼性の点で、それはTobii製品よりわずかに悪いだけで、私が一緒に働いたSMI製品に非常に近いです。 精度の正式なテストはまだ実施されていません。おそらくこれは次の記事のトピックです。





両側に6個の赤外線LEDa



次に、SDKについて説明します。 データサーバーと同様に、まだ非常に粗雑です（宣言されたすべての機能が動作するわけではありません）が、積極的に開発されています（2月初旬のバージョン9.20、最後の9.27）。 相互作用のプロセスはソケットを介して行われ、次のようになります。

0. TETサーバーが起動します（EyeTribeの略）。

1.クライアントは127.0.0.1:6555/tcpに接続します

2.クライアントはJSON形式で要求を送信し、クライアントは同じ形式で応答します。 パッケージの内容はここにリストされています 。

3.さらに、クライアントは「ハートビート」パケットを3秒間送信します-彼らは私が生きていると言います（これはTCP接続がなぜ謎なのか）。

4.クライアントは自分でキャリブレーションポイントを描画し、キャリブレーションマトリックスをコンパイルするためにデータの処理を開始および終了するタイミングをサーバーに通知するだけです。

5.プッシュモードでは、クライアントは要求なしで1秒あたり30ポイントの視点を受け取ります（60 Hzモードもありますが、まだチェックしていません）。

5a。 各ポイントに含まれるもの：

-注視点の座標：平均化され、各目について別々に。

-いくつかのローパスフィルターによる平滑化後の視点の座標：平均化され、各目ごとに個別に。

-瞳孔サイズ：各目ごとに個別に（使用されている測定単位はまだわかりません）。

-カメラの視野内の瞳孔の座標。

-コミットフラグ

-サーバーの状態コード。



GithubはすでにC ++およびC＃の開発者向けに一定量のコードを使用しているため、私のように、すべてをゼロから作成する必要はありません。 ただし、パケット形式とデータ型が将来わずかに変更され、このデバイスの古いプログラムがサーバーの新しいバージョンと互換性がなくなる可能性があります。 たとえば、上記のリンクのパッケージの公式説明では、データ型に2つの不正確さがあり、一部のパッケージには説明されていない値が含まれている可能性があることを見つけなければなりませんでした。



これについては、新しい市場の開発と開発を成功させることを望んでいましたが、結論として、1つの問題を共有したいと思います。 それは、i-トラッカーをコンピューターマウスのような互換性のあるデバイスにするための単一のドライバーやインターフェイスがないという事実にあります。 つまり 特定のi-tracker用のソフトウェアを開発した後、別のi-trackerに接続することはできません。新しいモジュールを作成する必要があります。 約12年前、私はこの問題に夢中になり、特定のミドルウェアプラットフォームを作成し、クライアント部分に単一のインターフェースを使用しました。次のi-trackerが手に入ったので、別のモジュール（DLL）を作成し、このプラットフォーム上で視線を使用するように設計されたソフトウェアは、不要なジェスチャーなしですぐにこのデバイスで動作し始めます。 当然、ETU-Driver（私が呼んだように）はすでにET-1000をサポートしています（近い将来-Tobii T60およびX2-60との精度の比較）。 しかし、長年の使用で、その欠点が明らかになりました。まず、送信されるデータのハードフォーマットとCOM形式の実装です。 すべてを最初から書き直そうとする試みがすでにありましたが、実装は他の、おそらくより柔軟性があり、プラットフォームに依存しないものである必要があるという感覚は残していません。 そのようなデバイスにデバイスに依存しないプラットフォームを適切に実装する方法について考えている人がいれば、共有する大きな要望があります。