【課題】ホストコンピュータへの低帯域幅接続を利用してユーザインタフェース装置への高品質な触覚効果を提供する。
【解決手段】本発明の実施形態は、ホストプロセッサとユーザインタフェース装置中のプロセッサとの間の低帯域幅接続を効率的に利用するために高水準メッセージングを採用している。高水準メッセージングを利用することで、ホストコンピュータは、高水準触覚コマンドをユーザインタフェース装置に送り、ユーザインタフェース装置のプロセッサに指令し、アクチュエータを利用して触覚結果を出力する。ユーザインタフェース装置のプロセッサは高水準触覚コマンドを、アクチュエータを駆動するための信号に変換し、出力すべき触覚結果を生じせしめるようにその信号を出力する。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般として、人間とコンピュータとの間のインタフェース装置に関し、特に、ユーザに対して力フィードバックを提供するコンピュータインタフェース装置に関する。
【背景技術】
【０００２】
コンピュータシステムは、多くの異なる産業分野で、コンピュータ制御シミュレーションやゲームやその他のアプリケーションプログラムを実施するため広く用いられている。特に、このようなタイプのゲームやシミュレーションは、家庭消費者の量販市場では非常に一般的である。コンピュータシステムは、通常、ユーザに対して表示画面またはその他の視覚出力装置上に視覚環境を表示する。ユーザは、表示された環境と対話して、ゲームを行い、シミュレーションまたは「仮想現実（バーチャルリアリティ）」環境を体験することができ、あるいは画面上に描かれた事象または画像に影響を与えることができる。このようなユーザインタラクションは、表示された環境を制御するコンピュータシステムに接続されたジョイスティックや、「ジョイパッド」ボタン制御装置、マウス、トラックボール、スタイラスやタブレットなどのヒューマン−コンピュータインターフェース装置を用いて実施することができる。コンピュータは、ジョイスティックハンドルやマウス等の物体（オブジェクト）のユーザによる操作に応じてシミュレーションやゲームを更新し、表示画面、更に通常はオーデイオスピーカを用いてユーザに対するフィードバックを行う。
【０００３】
幾つかのインタフェース装置では、触覚（「ハプティック（haptic）」）フィードバックもユーザに与えられる。これは、より一般的には「力フィードバック」として知られている。このようなタイプのインタフェース装置は、インタフェース装置のオブジェクトを操作するユーザに対して肉体的な感覚を与えることができる。通常は、モータや他のアクチュエータがオブジェクトに結合され、制御コンピュータシステムに接続される。コンピュータシステムは、アクチュエータに制御信号を送ることにより、シミュレーション／ゲームイベントに関係してオブジェクトに力を与えることができ、コンピュータシステムは、ユーザがインタフェース装置のオブジェクトを握ったり触ったりするときに他の供給フィードバックと関連してユーザに肉体的感覚を与えることができる。このようにして、力フィードバックインタフェース装置は、ヒューマン−コンピュータインタラクションに対して全く新規な特徴を与えることができる。?
【０００４】
従来技術の力フィードバック入出力（Ｉ／Ｏ）装置は、最大の触覚忠実度を与えることに集中している。すなわち、触覚フィードバックのリアリズムが最適化されることが望まれていた。これは、力フィードバック装置の殆どが、量販消費者市場ではなく、極めて産業的な用途の特定のニーズに目標を定めているためである。このようなリアリズムを実現するために、小さなサイズと重量、複雑さが少ないこと、プログラミングの互換性、低いコスト、安全性などといった量販市場設計の関心事は、従来技術では犠牲にされている。その結果、通常の力フィードバックインタフェース装置は、精密部品と高価なアクチュエータを要求する複雑なロボット機構を含んでいる。
【０００５】
力フィードバックインターフェース装置に対する重要な関心事は、制御コンピュータとインタフェース装置との間の通信帯域幅である。現実に近い力フィードバックを与えるために、従来技術の複雑な装置は、通常、制御コンピュータがインタフェース装置への力フィードバック信号を迅速に更新することを可能にする高速通信エレクトロニクスを用いる。制御コンピュータがより迅速にインタフェース装置に対して信号を送受することができる程、所望の力をより正確かつ現実に近い状態でインターフェースオブジェクトに加えることができる。更に、高い帯域幅の通信インタフェースを用いると、力フィードバックを、映像画面上の画像などの他の供給フィードバックと、オブジェクトの移動、活性化ボタンなどのユーザ入力と、に正確に調和させることができる。例えば、ユーザはシミュレーションにおいて力フィードバックジョイスティックを握ると共に移動させて車の画像を制御し、画面上に表示された仮想的な凹凸面の上を運転することができる。制御コンピュータは、シミュレーションの設計者が意図した程度に現実に近い凹凸にその表面が感じられるように、十分迅速にジョイスティックのアクチュエータに制御信号を与えるべきである。制御信号が遅すぎるときは、現実に近い凹凸感を与えることが困難になる。また、制御コンピュータは、供給された力を画面上の視覚フィードバック、例えば車が最初に凹凸面に当たるときの画面上の動き、に正確に調和させる高い帯域幅の通信インタフェースを必要とする。この高い速度は、供給された力を、例えば特定の方向に車をステアリングするためのユーザからの入力に正確に調和させる場合にも、同様に必要となる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
問題は、従来の力フィードバックインタフェース装置が量販消費者市場に供給されるときに明らかとなる。殆どのホームコンピュータは、ＲＳ−２３２やＲＳ−４２２インタフェースなどの組込み標準シリアル通信インタフェースを有しており、これは、力フィードバックインタフェース装置などの周辺装置をホストコンピュータに接続するために便利に用いることができる。更に、製造業者は、これらのシリアルインタフェースを用いる周辺装置を提供することを好む。これは、インタフェースカードなどの付加的なハードウェアをこのような周辺装置に取り付ける必要がないからである。従って、周辺装置の製造コストはかなり減らすことができる。しかし、これらの標準シリアル通信インタフェースは、通常、他の通信インタフェースに比べて極めて遅い（すなわち、低い帯域幅を有する）。
このため、制御コンピュータシステムによって、現実に近い正確な力フィードバックを、このようなシリアルインタフェースを介して接続された従来のインタフェース装置に与えることは困難になる。例えば、Ｊ．Ｋｒａｍｅｒによる米国特許第５、１８４、３１９号は、ユーザの胴体部分に力を加える力フィードバック装置を開示している。しかし、このＫｒａｍｅｒの装置は、ホストコンピュータがアクチュエータを直接制御し、インタフェース装置からセンサデータを直接受信するという点で従来技術の典型的なものである。このような装置は、現実に近い力フィードバックを実現する低帯域幅通信インタフェースには適していない。
【０００７】
量販消費者市場における従来の力フィードバックインタフェースを用いた場合の他の問題は、異なるコンピュータで用いられたり同じコンピュータで異なる時刻に用いられる処理速度やコンピュータプラットフォームが多岐にわたることである。力フィードバックインタフェース装置によりユーザに与えられる力の感覚は、これらの異なるコンピュータが異なる速度で稼働するので、異なるコンピュータプラットフォームやマイクロプロセッサ上のユーザには異なって感じられる。例えば、１００ＭＨｚコンピュータにより制御される力フィードバックは、これらの力が同じものを感じるようになされていても、制御信号を処理する速度が異なることに起因して、６０ＭＨｚコンピュータにより制御される力フィードバックとは全く異なる。更に、一つのマイクロプロセッサの実行処理速度は、所定時間にわたって変動し、多数のユーザセッションにわたって一致しない力を与える可能性がある。例えば、マルチタスク動作は、マイクロプロセッサ上で動作する他のプログラムに依存して力フィードバック制御信号のマイクロプロセッサによる管理を変化または遅延させることがある。
【０００８】
更に、力フィードバック装置と通信するための標準化された言語または通信プロトコルは存在しない。ソフトウェアアプリケーションにおいてインタフェースに力フィードバックを与えることを望むソフトウェアの開発者は、一般に、開発者自身の特殊なコマンドおよび／または通信プロトコルを設定しなければならず、また力フィードバック制御命令を低水準で実施しなければならない。これは、力フィードバックインタフェース向けの特徴を含むソフトウェアアプリケーションの開発において不要な時間と費用を要求する。
【０００９】
従って、力フィードバックインタフェースおよび力フィードバック制御パラダイム（paradigm）に代わる、より現実に近く費用効果の大きいものが特定の用途に関して要望されている。
【課題を解決するための手段】
【００１０】
本発明は、ヒューマンコンピュータインタフェース装置を操作するユーザに対して力フィードバックを制御および提供することに関する。このインタフェース装置は、制御用ホストコンピュータに接続されており、このインタフェース装置に対してローカルな個別のマイクロプロセッサを有している。このローカルマイクロプロセッサは、インタフェース装置に対する力の高速制御を可能にし、これにより、ホストコンピュータとの遅い通信インタフェースを介して与えられた力のリアリズムと精度を高める。
【００１１】
より詳細に述べると、ユーザにより操作されるインタフェース装置を制御する本発明のシステムおよび方法は、入力制御信号を受信し、ホスト出力制御信号を供給するホストコンピュータシステムを含む。ホストコンピュータは、入力制御信号に応じてシミュレーションやビデオゲームプロセスなどのホストアプリケーションプロセスを更新する。インタフェース装置に対してローカルでホストコンピュータから分離したマイクロプロセッサは、ホスト出力制御信号を受信すると共にプロセッサ出力制御信号を供給する。アクチュエータは、プロセッサ出力制御信号を受信し、プロセッサ出力制御信号に従ってアクチュエータに結合されたユーザ操作オブジェクトに対する自由度に沿って力を与える。センサは自由度に沿ったオブジェクトの動きを検出し、このオブジェクトの位置と動きを表す情報を含む入力制御信号を出力する。好ましくは、センサは、入力制御信号をローカルプロセッサに出力し、ローカルプロセッサは、ホストコンピュータに入力制御信号を出力する。ユーザオブジェクトは、１以上の自由度でユーザが握って動かすものであることが好ましく、ジョイスティック、マウス、模擬医療器具、スタイラス、または他のオブジェクトのような物品が含まれていてもよい。
【００１２】
あるホスト制御態様では、ホストコンピュータは、入力制御信号中のセンサ情報を受信し、力の値を決定する。従って、ホスト出力制御信号は、マイクロプロセッサを介して直接アクチュエータに中継される決定済直接力コマンドである。第二の「反射（reflex）」態様では、ホストコンピュータは、監視モードでセンサ情報を受信し、力をユーザオブジェクトに印加する必要があるとき又は力を変更する必要があるときは常に、高水準力コマンドをマイクロプロセッサに出力する。マイクロプロセッサは、高水準ホストコマンドに従って、センサおよびタイミングデータを受信し、選択された反射プロセスに従ってアクチュエータに低水準力コマンドを出力する。この反射プロセスは、力方程式を用いるステップ、所定の力値の力プロファイルを記憶装置から読み取るステップ、またはその他のステップを含んでいてもよく、またこの反射プロセスは、センサデータ、タイミングデータ、ホストコマンドデータ、または他のデータに依存していてもよい。このようにして、プロセッサは、ホストコンピュータがユーザオブジェクトに印加される力のタイプを変更するまでホストコンピュータとは無関係に力を制御する「反射」を実施する。
【００１３】
アクチュエータにより与えられる力の大きさは、ホストコンピュータまたはローカルマイクロプロセッサにより決定される。この大きさは、特定の自由度におけるオブジェクトの位置、速度および／または加速を含むパラメータ、ならびにクロックからのタイミングデータにより決定することができる。このようにして、この力は、バネの力、制動力、または慣性力などの異なるタイプの力をシミュレートすることができる。
【００１４】
ホストコンピュータシステムにより更新されたアプリケーションプロセスは、好ましくは、アプリケーションソフトウェアを含んでいる。このアプリケーションソフトウェアは、シミュレーションソフトウェア、ゲームソフトウェア、科学ソフトウェアなどであってもよい。ホストコンピュータシステムは、表示画面などの視覚出力装置上に画像を表示し、画像および視覚事象を、オブジェクトを操作するユーザから入力された位置と動き、並びにオブジェクトに加えられた力に同期させることができる。また、ホストコンピュータは、好ましくは音声フィードバックのタイミングと大きさを力フィードバックに同期させることができる。本発明は、多くのコンピュータに含まれる標準シリアルインタフェースを用いてホストコンピュータシステムをローカルマイクロプロセッサとインタフェースすることができる。あるいは、パラレルインタフェースを用いたり、ホストコンピュータ上の異なるインタフェース、例えばゲームポート、と共にシリアルインタフェースを用いることもできる。クロックは、アクチュエータにより出力された力を部分的に決定するためアクセスすることができるホストコンピュータシステムまたはローカルプロセッサに結合されることが好ましい。
【００１５】
本発明は更に、ホストコンピュータとローカルマイクロプロセッサとの間の力コマンドに対するパラダイム（paradigm）を提供する。ホストコンピュータにより与えられる高水準ホストコマンドは、レート制御および／または位置制御コマンドであってもよく、コマンドパラメータ形式の情報を含んでいてもよい。ひとそろいの力に翻訳される比較的小さな一組のコマンドおよびコマンドパラメータを与えることにより、パラダイムは、演算の負担をホストコンピュータからローカルマイクロプロセッサに更にシフトさせる。ホストコマンドは、復元力や、振動力、質感力、障壁力、吸引／反発力の場、制動力、溝力、およびラケット−ボール力などの力をユーザオブジェクトに与えるコマンドを含んでいてもよい。通常のコマンドパラメータは、アクチュエータにより出力された力を制御する大きさパラメータ、持続時間パラメータ、方向パラメータ、スタイルパラメータ、およびボタンパラメータを含む。これは、ホストコンピュータシステム上で実施される力フィードバックソフトウェアの開発者による効率の良い使用のための高水準標準力フィードバックコマンドプロトコルを与える。
【００１６】
ローカルマイクロプロセッサの機能も、好適に実現される。コマンドプロセスは、ホストコンピュータからのホストコマンドを受信し、ホストコマンドおよび任意の包含コマンドパラメータを処理する。力パラメータはホストコマンドおよびパラメータから導出され、メモリに格納される。好ましくは、全てのホストコマンドは、適当なホストコマンドが受信されたときに更新される一組の力パラメータを伴っている。状態更新プロセスは、ユーザオブジェクトの動きを記述するセンサからのセンサデータを読み取り、適切であれば速度、加速度、または他の時間関連値を計算することもできる。力出力プロセスは、力パラメータおよびセンサデータに従って選択された反射プロセスを用いて力値を計算する。ある場合には、力値は、力パラメータの値およびセンサデータに依存する。力出力プロセスは、計算した力値をアクチュエータに送出することによりユーザオブジェクトに作用する力を出力する。更に、報告プロセスは、適切な場合には、センサデータをホストコンピュータシステムに報告する。好ましくは、複数個のホストコマンドを同時に有効にすることができ、ここで力値は、このような有効状態のホストコマンドの各々に対応する反射プロセスから加算される。更に、パラメータセットのパラメータページは、異なる力環境を選択できるように都合よくメモリに格納することができる。
【００１７】
本発明の制御システムおよび方法は、ホストコンピュータから分離されたインタフェース装置に対してローカルな別個のマイクロプロセッサを含んでいると都合がよい。このローカルマイクロプロセッサは、ホストコンピュータとは無関係にセンサ信号および出力力コマンド信号を読み取り、処理し、これによりホストコンピュータ上における膨大な処理時間を節約することができる。更に、低水準力フィードバックコマンドを処理するローカルプロセッサを使用することにより、ホストおよびインタフェース装置間にシリアル通信インタフェースまたは他の比較的狭い帯域幅の通信インタフェースを用いる場合に、より現実に近く正確な力フィードバックをユーザが操作するオブジェクトに与えることができるようになる。これは、このような低水準力信号は、通信インタフェースを介して送信する必要はないためである。絶対的なタイミング情報の観点で力フィードバックコマンドを生成する場合にクロックを使用すると、異なるホストコンピュータプラットフォームにわたって、また同じホストコンピュータ上の異なるセッションにおいて、ユーザが一致した力感覚を体験することができるようになる。種々の力を指令する特定の高水準ホストコマンドを使用すると、力フィードバックホストアプリケーションを容易に生成できるようになる。これらの改良を加えると、低コストの低帯域幅通信インタフェースを介して正確で現実に近い力フィードバックをコンピュータシステムが与えることができるようになり、従ってホームコンピュータシステムの量販市場に対して理想的である。
【００１８】
本発明の上記および他の利点は、本発明の以下の詳細な説明を読み、図面を参照することによって、当業者にとって明らかになる。
【図面の簡単な説明】
【００１９】
【図１】図１は、ホストコンピュータから力フィードバックインタフェース装置を制御する、本発明に係る制御システムのブロック図である。
【図２】図２は、本発明用の能動アクチュエータに制御信号を与えるアクチュエータインタフェースの概略図である。
【図３】図３は、本発明用の受動アクチュエータに制御信号を与えるアクチュエータインタフェースの概略図である。
【図４】図４は、力フィードバックインタフェース装置を制御する本発明の方法の第一の実施形態を示す流れ図である。
【図５】図５は、力フィードバック装置を制御する本発明の方法の第二の実施形態の流れ図である。
【図６】図６は、インタフェース装置のユーザオブジェクトに２自由度を与える閉ループファイブバーリンケージ機構の概略図である。
【図７】図７は、図６に示したリンケージ機構の好適な実施形態の斜視図である。
【図８】図８は、ユーザオブジェクトに対する機械的インタフェースのスロット付きヨークジョイスティックの斜視図である。
【図９】図９は、本発明のレート制御コマンドを要約する表である。
【図１０】図１０（ａ）〜（ｃ）は、力プロファイルの復元を示す概略図である。
【図１１】図１１（ａ）〜（ｃ）は、ばね力プロファイルの復元を示す概略図である。
【図１２】図１２は、ベクトル力を示す図である。
【図１３】図１３（ａ）〜（ｂ）は、振動力プロファイルを示す図である。
【図１４】図１４は、本発明の位置制御コマンドを要約する表である。
【図１５】図１５は、溝力プロファイルを示す図である。
【図１６】図１６は、障壁力プロファイルを示す図である。
【図１７】図１７（ａ）〜１７（ｉ）は、本発明のラケットコマンドにより制御されるラケットボールインタラクションを示す図である。
【図１８】図１８は、力フィードバックインタフェース装置を力パラメータを含むホストコマンドにより制御する本発明のローカルマイクロプロセッサの実施を示すブロック図である。
【図１９】図１９は、図１８のホスト通信バックグラウンドプロセスを示す流れ図である。
【図２０】図２０は、図１８のコマンドプロセスを示す流れ図である。
【図２１】図２１は、図１８の報告プロセスを示す流れ図である。
【図２２】図２２は、図１８のアクチュエータ制御プロセスおよび力アルゴリズム計算を示す流れ図である。
【図２３】図２３は、本発明で用いた力パラメータおよび一連の力コマンドを示す図である。
【発明を実施するための形態】
【００２０】
図１は、ホストコンピュータシステムにより制御されるインタフェース装置用の本発明の一般的な制御システム１０を示すブロック図である。制御システム１０は、ホストコンピュータシステム１２とインタフェース装置１４を有する。
【００２１】
ホストコンピュータシステム１２は、好ましくは、ＩＢＭ互換パーソナルコンピュータやＭａｃｉｎｔｏｓｈパーソナルコンピュータなどのパーソナルコンピュータ、またはＳＵＮワークステーションやＳｉｌｉｃｏｎＧｒａｐｈｉｃｓワークステーションなどのワークステーションである。例えば、ホストコンピュータシステムは、ＩＢＭ ＰＣ ＡＴスタンダードに従うＭＳ−ＤＯＳまたはＷｉｎｄｏｗｓ動作システムの下で動作するパーソナルコンピュータである。この他に、ホストコンピュータ１２は、テレビジョンセットに一般的に接続された種々のホームビデオゲームシステム、例えばＮｉｎｔｅｎｄｏ、Ｓｅｇａ、Ｓｏｎｙから市販されているシステム、の一つであってもよい。他の態様では、ホームコンピュータシスム１２は、例えばユーザにインタラクティブテレビテレビジョン機能を与えるために使用できる「セットトップボックス」であってもよい。
【００２２】
本実施形態では、ホストコンピュータシステム１２は、周辺装置およびインタフェース装置１４を介して対話するホストアプリケーションプロセスを実施する。ホストアプリケーションプログラムは、例えば、ビデオゲーム、医療用シミュレーション、科学解析プログラム、もしくはオペレーティングシステム、または力フィードバックを利用する他のアプリケーションプログラムである。通常、このホストアプリケーションは、以下に述べるように、表示出力装置に表示される画像を提供し、および／または他のフィードバック、例えば音響信号、を提供する。
【００２３】
ホストコンピュータシステム１２は、好ましくは、ホストマイクロプロセッサ１６、ランダムアクセスメモリ（ＲＡＭ）１７、リードオンリーメモリ（ＲＯＭ）１９、クロック１８、表示画面２０、および音声出力装置２１を有する。ホストマイクロプロセッサ１６は、Ｉｎｔｅｌ、Ｍｏｔｏｒｏｌａ、または他の製造業者から市販されている一連のマイクロプロセッサを有する。マイクロプロセッサ１６は、単一のマイクロプロセッサチップであってもよく、あるいは複数のプライマリプロセッサおよび／またはコプロセッサを含んでいてもよい。好ましくは、マイクロプロセッサは、当業者には周知のように、ＲＡＭ１７およびＲＯＭ１９から命令および他の必要なデータを取り出して格納する。本実施形態では、ホストコンピュータシステム１２は、インタフェース装置１４からバス２４を介してセンサデータまたはセンサ信号を受信し、更に他の情報を受信する。マイクロプロセッサ１６は、マイクロプロセッサ１６とバス２４との間に設けられた標準Ｉ／Ｏエレクトロニクスを用いてバス２４からデータを受信し、更にＩ／Ｏエレクトロニクスを用いて他の周辺装置を制御する。ホストコンピュータシステム１２は、更にバス２４を介してインタフェース装置１４に「力コマンド」を出力して、インタフェース装置に対する力フィードバックをもたらす。
【００２４】
クロック１８は、マイクイロプロセッサ１６およびコンピュータシステムの他の構成要素により用いられる電気信号にタイミングを与えるためにホストコンピュータシステム１２が使用する標準的なクロック水晶または等価な構成要素である。クロック１８は、続いて以下に示すように、本発明の制御プロセスにおいてホストコンピュータシステム１２によりアクセスされる。
【００２５】
表示画面２０は、適切なディスプレイドライバによりホストマイクロプロセッサ１６に結合され、ホストコンピュータシステム１２または他のコンピュータシステムにより生成される画像を表示するために使用される。表示画面２０は、標準的な表示画面、またはＣＲＴ、３−Ｄゴーグル、もしくは他の視覚インタフェースとすることができる。本実施形態においては、表示画面２０は、シミュレーション環境またはゲーム環境の画像を表示する。他の実施形態においては、他の画像が表示される。例えば、仮想バーチャルリアリティシミュレーションやゲームにおけるように、一人称的視野からの観点を記述する画像を表示することができる。或いは、オブジェクト、背景などの第三者的視野を表す画像を表示することもできる。ホストコンピュータ１２およびインタフェース装置１４のユーザ２２は、表示画面２０を見ることにより視覚フィードバックを受けることができる。
【００２６】
本明細書では、コンピュータ１２は、コンピュータ「オブジェクト」または「エンティティ」を表示させるものを指す場合がある。これらのコンピュータオブジェクトは、物理的なオブジェクトではなく、当業者には周知のように、表示画面２０上のコンピュータ１２による画像として表示されるデータおよび／または手順の論理ソフトウェアユニット集合である。例えば、カーソルや第三者的視界の車は、画面を横切って移動できるプレーヤ制御コンピュータオブジェクトと考えることができる。航空機の表示された模擬コックピットも「オブジェクト」と考えることができ、あるいは模擬航空機をコンピュータ制御「エンティティ」と考えることができる。
【００２７】
スピーカなどの音声出力装置２１は、当業者には周知のように、増幅器、フィルタ、および他の回路を介してホストマイクロプロセッサ１６に結合されていることが好ましい。ホストプロセッサ１６は、スピーカ２１に信号を出力し、ホストアプリケーションプログラムの実施の間に「音声事象」が生じるときユーザ２２に音響出力を与える。また、他の種類の周辺装置は、記憶装置（ハードディスクドライブ、ＣＤＲＯＭドライブ、フロッピディスクドライブなど）、プリンタ、その他の入出力装置のようなホストプロセッサ１６に結合されていてもよい。
【００２８】
インタフェース装置１４は、双方向バス２４によりホストコンピュータシステム１２に結合されている。双方向バスは、ホストコンピュータシステム１２とインタフェース装置との間のいずれかの方向に信号を送出する。本明細書では、用語「バス」は、ホストコンピュータ１２およびマイクロプロセッサ２６間などのインタフェースであって、一つ以上の接続線または他の接続部材を通常含み、以下に示すように多くの方法で実施することができるインタフェース、を一般的に指すように意図されている。好適な実施形態においては、バス２４は、シリアル通信プロトコルに従ってデータを供給するシリアルインタフェースである。ＲＳ２３２シリアルインタフェースポートなどのホストコンピュータシステム１２のインタフェースポートは、バス２４をホストコンピュータシステム１２に接続する。他の標準シリアル通信プロトコル、例えばＲＳ−４２２、ユニバーサルシリアルバス（ＵＳＢ）、ＭＩＤＩ、または当業者に周知の他のプロトコル、をシリアルインタフェースおよびバス２４で用いることも可能である。
【００２９】
例えば、ＵＳＢ規格は、高度のリアリズムを備える本発明において力フィードバック信号を供給することができる比較的高速のシリアルインタフェースを与える。ＵＳＢはまた、周辺装置を駆動するより多くの電力のソースとなることもできる。ＵＳＢにアクセスする各々の装置はホストコンピュータにより独自のＵＳＢアドレスを割り当てられるので、これにより複数の装置が同じバスを共有することが可能になる。更に、ＵＳＢ規格は、微分データと共に符号化されるタイミングデータを含んでいる。ＵＳＢは、本明細書の全体を通じて説明するように、本発明に対して有用な特徴を幾つか有している。
【００３０】
本発明の利点は、低帯域幅シリアル通信信号をインタフェース装置１４とのインタフェースに用いることができ、これにより、多くのコンピュータの標準組込みシリアルインタフェースを直接使用することが可能になることである。この他に、ホストコンピュータシステム１２のパラレルポートは、パラレルバス２４に結合することができ、ＳＣＳＩやＰＣパラレルプリンタバスなどの並列プロトコルを用いてインタフェース装置と通信を行うことができる。別の実施形態では、バス２４は、例えば、プラグインカードおよびスロットまたはコンピュータシステム１２の他のアクセスを用いてホストコンピュータシステム１２のデータバスに直接接続することができる。例えば、ＩＢＭＡＴ互換コンピュータでは、インタフェースカードは、ＩＳＡ、ＥＩＳＡ、ＶＥＳＡローカルバス、ＰＣＩ、またはコンピュータのマザーボードに差し込まれる他の周知の標準インタフェースカードとして実装することができ、このインタフェースカードは、コンピュータの主データバスに接続された入力および出力ポートを提供することができる。
【００３１】
他の実施形態においては、ホストコンピュータシステム１２とインタフェース装置１４の間を連絡する追加バス２５が設けられる。通信信号に対する速度要求は力フィードバック信号を出力するために比較的高いので、バス２４と共に用いられる単一のシリアルインタフェースは、現実に近い力フィードバックが得られるほど十分に高い速度で信号をインタフェース装置との間で送受することができない。このような実施形態では、バス２４をホストコンピュータ１２の標準シリアルポートに結合し、追加バス２５をホストコンピュータシステムの第２のポートに結合することができる。例えば、多くのコンピュータシステムは、シリアルＲＳ−２３２ポートの他に、ジョイスティックまたは同様のゲームコントローラをコンピュータに接続するための「ゲーム」ポートを有している。２本のバス２４および２５を同時に用いてデータバス帯域幅を増加させることができる。例えば、マイクロプロセッサ２６は、センサ信号を単方向バス２５とゲームポートを介してホストコンピュータ１２に送出することができ、一方ホストコンピュータ１２は、力フィードバック信号をシリアルポートから単方向バス２４を介してマイクロプロセッサ２６に出力することができる。他の実施形態では、データフロー構成の他の組み合わせを実施することができる。
【００３２】
インタフェース装置１４は、ローカルマイクロプロセッサ２６、センサ２８、アクチュエータ３０、ユーザオブジェクト３４、任意選択センサインタフェース３６、任意選択アクチュエータインタフェース３８、および他の任意選択入力装置３９を有する。インタフェース装置１４は、バス２４上で標準プロトコルを介しての通信のために付加的な電子部品を有する。好適な実施形態では、多数のインタフェース装置１４がバス２４（または多数のバス２４）を介して単一のホストコンピュータシステム１２に結合されており、これにより多数のユーザがホストアプリケーションプログラム（例えば、マルチプレーヤゲームやシミュレーションにおけるもの）と同時にインタフェースすることができる。更に、当業者には周知のように、多数のプレーヤが、ネットワーク化ホストコンピュータ１２を用いてホストアプリケーションプログラムにおいて多数のインタフェース装置１４と対話することができる。
【００３３】
ローカルマイクロプロセッサ２６はバス２４に結合されており、インタフェース装置の他の構成要素との迅速な通信が可能になるようにインタフェース装置１４のハウジング内に含まれていることが好ましい。プロセッサ２６はインタフェース装置１４に対して「ローカル」と考えられる。本明細書では、「ローカル」は、プロセッサ２６がホストコンピュータシステム１２における任意のプロセッサから分離されたマイクロプロセッサであることを意味する。好ましくは「ローカル」は、プロセッサ２６がインタフェース装置１４のセンサＩ／Ｏおよび力フィードバックに専用であり、インタフェース装置用のハウジング内やインタフェース装置１４に密接に結合されたハウジング内のように、プロセッサ２６がセンサ２８およびアクチュエータ３０に密接に結合されることも意味する。マイクロプロセッサ２６には、コンピュータホスト１６からのコマンドまたはリクエストを待機させ、コマンドまたはリクエストを復号し、更にコマンドまたはリクエストに従って入力および出力信号を処理／制御するソフトウェア命令を与えることができる。更にプロセッサ２６は、センサ信号を読み取り、それらのセンサ信号、時間信号、およびホストコマンドに従って選択された反射プロセス（本明細書では「サブルーチン」または「力感覚プロセス」とも呼ばれる）から適切な力を計算することにより、ホストコンピュータ１６とは独立に動作する。ローカルマイクロプロセッサ２６としての使用に適したマイクロプロセッサとしては、例えばMotorola製のMC68HC711E9やMicrochip製のPIC16C74がある。マイクロプロセッサ２６は、一つのマイクロプロセッサチップ、または複数のプロセッサチップおよび／またはコプロセッサチップを含んでいてもよい。他の実施形態においては、マイクロプロセッサ２６はデジタル信号プロセッサ（ＤＳＰ）チップを有していてもよい。ＲＡＭおよび／またはＲＯＭなどのローカルメモリ２７は、好ましくはインタフェース装置１４内のマイクロプロセッサ２６に結合され、マイクロプロセッサ２６に対する命令を格納し、一時データおよび他のデータを格納する。マイクロプロセッサ２６は、センサ２８から信号を受信し、バス２４を介してホストコンピュータ１２により与えられる命令に従ってインタフェース装置１４のアクチュエータ３０に信号を供給する。
【００３４】
更に、ローカルクロック２９は、ホストコンピュータ１２のシステムクロック１８と同様に、タイミングデータを供給するようにマイクロプロセッサ２６に結合されていてもよい。このタイミングデータは、例えばアクチュエータ３０により出力される力（例えば、計算された速度または他の時間依存因子に依存する力）を計算するために必要となる場合がある。ＵＳＢ通信インタフェースを用いた他の実施形態では、マイクロプロセッサ２６に対するタイミングデータをＵＳＢ信号から取り出すことができる。ＵＳＢは、使用可能なデータストリームによって符号化されるクロック信号を有している。この他に、ＵＳＢのIsochronous（ストリーム）モードは、標準データ転送速度からタイミング信号を引き出すことができる。ＵＳＢは、使用可能なSampleClock、Bus Clock、およびService Clockも有している。
【００３５】
例えば、ある実施形態では、ホストコンピュータ１２は、バス２４を介して低水準力コマンドを供給することができる。これらのコマンドは、マイクロプロセッサ２６がアクチュエータ３０に直接供給する。この実施形態は、図４を参照して更に詳細に説明する。異なる実施形態では、ホストコンピュータシステム１２は、バス２４を介してマイクロプロセッサ２６に高水準監視コマンドを供給することができ、マイクロプロセッサ２６は、高水準コマンドに従ってセンサ２８およびアクチュエータ３０に対する低水準力制御（「反射（reflex）」）ループを管理する。この実施形態は、図５を参照して更に詳細に説明する。
【００３６】
マイクロプロセッサ２６はまた、好ましくは、較正パラメータを格納する電気的に消去可能なプログラマブルＲＯＭ（ＥＥＰＲＯＭ）または他の記憶装置２７へのアクセスを有している。この較正パラメータは、同じ製造プロセスから形成された異なるインタフェース装置の部品の異なる物理的特性、例えば物理的寸法、のわずかな製造ばらつきを補償することができる。この較正パラメータは、インタフェース装置１４が販売される前に製造業者により決定および格納され、あるいは任意選択的にインタフェース装置のユーザがこれらのパラメータを決定することができる。これらの較正パラメータは、アクチュエータ３０に対する入力センサ信号および／または出力力値を修正して、多数の製造済インタフェース装置１４においてオブジェクト３４にほぼ同じ範囲の力を与えるために、プロセッサ２６により用いられる。較正パラメータの実施例は、当業者には周知である。
【００３７】
マイクロプロセッサ２６はまた、インタフェース装置１４に含まれる他の入力装置からコマンドを受信し、ホストコンピュータ１２に適当な信号を与えて、入力情報が受信されていることおよび任意の情報が入力情報に含まれていることを示すことができる。例えば、インタフェース装置１４上のボタン、スイッチ、ダイアル、もしくは他の入力制御装置、またはユーザオブジェクト３４は、マイクロプロセッサ２６に信号を供給することができる。
【００３８】
好適な実施形態では、センサ２８、アクチュエータ３０、およびマイクロプロセッサ２６、および他の関連する電子部品は、ユーザオブジェクト３４が直接または間接に結合されるインタフェース装置１４用のハウジングに含まれている。
この他に、マイクロプロセッサ２６および／またはインタフェース装置１４の他の電子部品は、ユーザオブジェクト３４、センサ２８、およびアクチュエータ３０から分離されたハウジング内に設置してもよい。更に、オブジェクト３４に所望の自由度を与えるために、追加の機械構造がインタフェース装置１４内に含まれていてもよい。このような機構の幾つかの実施形態は、図７〜図１２を参照して説明する。
【００３９】
センサ２８は、１以上の自由度に沿ってインタフェース装置１４のユーザオブジェクト３４の位置、動き、および／または他の特性を検出し、これらの特性を表す情報を含む信号をマイクロプロセッサ２６に与える。ユーザオブジェクトの実施例および与えられた自由度内での動きの例は、図７および８を参照して後述する。通常、センサ２８は、オブジェクト３４を動かすことのできる各自由度に対して用意される。この他に、単一の複合センサを用いて多自由度における位置または動きを検出することができる。ここに示した幾つかの実施形態に適したセンサの例は、回転軸のまわりのオブジェクトの位置の変化を検出し、位置の変化を示すデジタル信号を供給するデジタル光学エンコーダである。このエンコーダは、例えば、回転自由度において二つの位相関連信号を生成することによりシャフトの回転に応答する。線形光学エンコーダは、直線自由度に沿うオブジェクト３４の位置の変化を同様に検出し、また直線自由度での直線シャフトの運動に応じて二つの位相関連信号を生成することができる。相対的または絶対的センサのいずれかを用いることができる。例えば、相対的センサは単に相対的角度情報のみを与えるので、通常、相対的角度情報に対する基準位置を与える、ある形式の較正ステップを必要とする。本明細書に示すセンサは、主として相対的センサである。従って、システムの電源投入の後に、暗示較正ステップ（implied calibration step）が存在する。このステップでは、センサシャフトがインタフェース装置内の既知の位置に配置され、また、較正信号がシステムに供給されて上記の基準位置が与えられる。これ以降、センサにより与えられる全ての角度は、その基準位置を基準とするものである。この他に、基準位置を与えることができる既知のインデックスパルスを相対的センサに供給することもできる。このような較正方法は当業者には既知のものであり、従って本明細書では更に詳細な説明は行わない。適切な光学エンコーダは、ワシントン州バンクーバのU.S.Digital製の“Ｓｏｆｔｐｏｔ”である。
【００４０】
センサ２８は、光学センサインタフェース３６に電気信号を供給する。このインタフェースは、マイクロプロセッサ２６および／またはホストコンピュータシステム１２により翻訳可能な信号にセンサ信号を変換するために用いることができる。例えば、センサインタフェース３６は、センサ２８から二つの位相関連信号を受信し、二つの信号を、双方向二進カウンタを駆動する他のクロック信号ペアに変換する。この二進カウンタの出力は符号化されたシャフトの角度位置を表す二進数としてマイクロプロセッサ２６により受信される。このような回路または等価な回路は当業者には周知のものであり、例えばカリフォルニアのHewlettPackard製のQuadrature Chip LS7166は、上記の機能を果たすものである。各々のセンサ２８には、自身のインタフェースが設けられていてもよく、或いは一つのセンサインタフェースが、複数のセンサからのデータを処理してもよい。例えば、センサインタフェースは、入力データを供給する各センサ２８に専用の個別処理チップを有していてもよい。この他に、マイクロプロセッサ２６は、個別センサインタフェース３６を必要とすること無しにこれらのインタフェース機能を実現することもできる。位置値信号は、マイクロプロセッサ２６が用いることができ、また、ホストコンピュータシステム１２に送出される。ホストコンピュータシステム１２は、ホストアプリケーションプログラムを更新し、力制御信号を適切なものとして送出する。例えば、ユーザがステアリングホイールオブジェクト３４を動かすと、コンピュータシステム１２は、この動きを示す位置信号および／または他の信号を受信し、表示されたユーザの視点を、あたかも車両の外を見て車両の向きを変えているかのように移動させることができる。他のインタフェース機構も適当な信号をホストコンピュータシステム１２に供給するために用いることができる。他の実施形態では、センサ２８からのセンサ信号をホストコンピュータシステム１２に直接供給して、マイクロプロセッサ２６をバイパスすることができる。また、センサインタフェース３６は、インタフェースボードまたはカード上におけるように、ホストコンピュータシステム１２内に含まれていてもよい。
【００４１】
この他に、センサ２８の全てまたは幾つかについては、デジタルセンサの代わりにアナログセンサを用いることができる。例えば、オブジェクトの位置ではなくオブジェクト３４に作用する力を測定するひずみケージを接続することができる。また、速度センサおよび／または加速度計を用いてオブジェクト３４に加わる速度および加速度を直接測定することができる。アナログセンサは特定の自由度のユーザオブジェクトの位置／速度／加速度を表すアナログ信号を供給することができる。アナログ−デジタル変換器（ＡＤＣ）は、アナログ信号をデジタル信号に変換することができ、このデジタル信号は、当業者には周知のように、マイクロプロセッサ２６および／またはホストコンピュータシステム１２により受信され、解読される。検出されたオブジェクト３４の動きの分解能は、ＡＤＣの分解能により制限される。しかしながら、ノイズがアナログセンサからのオブジェクト３４の小さな動きをマスクする場合が多く、これにより、本発明の幾つかの実施形態（以下で説明する）にとって重要な遊びが潜在的にマスクされることがある。
【００４２】
他のタイプのインタフェース回路３６も使用することができる。例えば、各々のセンサに対して個別の処理チップを持つ電子インタフェースを用いることができる。このインタフェースは、マウスまたはスタイラスの位置を追跡することを可能にし、センサおよびアクチュエータを用いてスタイラスに力フィードバックを与える。センサインタフェース３６は、センサ２８からの角度信号の読み取り値をマイクロプロセッサ２６に送出する前に前処理する角度決定チップを有する。例えば、データバスにチップイネーブルラインを加えると、角度決定チップのいずれかがマイクロプロセッサと通信できるようになる。角度決定チップのない構成に最適なのは、追加処理なしで角度を直接示す出力信号を有し、これによりマイクロプロセッサ２６に対して要求する計算量を少なくし、従って前処理があっても計算量の少ないてすむ絶対センサを有する実施形態である。センサ２８が、単に角度の変化のみを示し、角度の完全な決定のために追加の処理が必要となる相対センサのときは、角度決定チップが最も適している。
【００４３】
アクチュエータ３０は、マイクロプロセッサ２６から受信された信号に応じて、１以上の自由度に沿って一つ以上の方向にインタフェース装置内１４のユーザオブジェクト３４に力を送る。通常、アクチュエータ３０は、力の送出が望まれる自由度の各々に対して用意される。アクチュエータ３０は、能動アクチュエータと受動アクチュエータの二種類からなる。
【００４４】
能動アクチュエータには、線形電流制御モータ、ステッパモータ、空気圧／油圧能動アクチュエータ、および力を送ってオブジェクトを動かす他の種類のアクチュエータが含まれる。例えば、能動アクチュエータは、回転自由度において軸のまわりに回転シャフトを駆動させることができ、あるいは直線自由度に沿って直線シャフトを駆動させることができる。本発明の能動トランスジューサは、好ましくは双方向であり、これは、これらのトランスジューサが自由度のいずれかの方向に沿って力を選択的に送ることができることを意味している。例えば、ＤＣサーボモータは、力制御信号を受信して、シャフト上に生成されるトルク（力出力）と方向を制御することができる。これらのモータは、シャフトの回転が短い時間帯の間に停止できるようにするブレーキを有していてもよい。印加電圧のパルス幅変調で制御されるステッパモータや、空気圧／油圧アクチュエータ、トルカ（torquer；角度範囲が制限されたモータ）、ボイスコイルアクチュエータなど、当業者に周知の他の種類の能動モータを用いることもできる。
【００４５】
アクチュエータ３０については、受動アクチュエータも使用可能である。モータの代わりに、あるいはモータの他に、磁気粒子ブレーキ、摩擦ブレーキ、または空気圧／油圧受動アクチュエータを用いることができる。受動アクチュエータのみを含む他の好適な実施形態は、モータを含むものほどリアルではないが、受動アクチュエータは、ユーザが生成された力と争う必要がないことから、通常、ユーザに対してより安全である。受動アクチュエータは、通常、動きの程度に対して双方向の抵抗を与えることしかできない。インタフェース装置１４に適切な磁気粒子ブレーキが、カリフォルニア州サンタモニカのForce Limited,Inc.から市販されている。
【００４６】
他の実施形態では、センサ２８およびアクチュエータ３０の全てまたは幾つかは、センサ／アクチュエータ対トランスジューサとして一体的に含まれていてもよい。光学エンコーダおよび電流制御モータの双方を含む本発明に適したトランスジューサは、Maxon製の２０Ｗバスケット巻サーボモータである。
【００４７】
アクチュエータインタフェース３８は、任意選択的にアクチュエータ３０とマイクロプロセッサ２６との間に接続可能である。インタフェース３８は、マイクロプロセッサ２６からの信号を、アクチュエータ３０を駆動するのに適当な信号に変換する。インタフェース３８は、電力増幅器、スイッチ、デジタル−アナログコントローラ（ＤＡＣ）、および他の構成要素を有していてもよい。能動アクチュエータ用のアクチュエータインタフェースの例は、図２を参照して説明する。受動アクチュエータ用のアクチュエータインタフェースの例は、図３を参照して説明する。他の実施形態では、インタフェース３８回路は、マイクロプロセッサ２６内またはアクチュエータ３０内に設けることができる。
【００４８】
他の入力装置３９が任意選択的にインタフェース装置１４に含まれていて、入力信号をマイクロプロセッサ２６に送出するようになっていてもよい。このような入力装置は、ボタン、ダイアル、スイッチ、または他の機構を含むことができる。例えば、ユーザオブジェクト３４がジョイスティックである実施形態では、他の入力装置として、例えばジョイスティックハンドルまたはベース上に設けられ、かつゲームまたはシミュレーションに対するユーザからの入力を補足するために用いられる一つ以上のボタンを挙げることができる。このような入力装置の動作は、当業者には周知である。
【００４９】
電源４０が任意選択的にアクチュエータインタフェース３８および／またはアクチュエータ３０に結合されていて、電力を供給するようになっていてもよい。能動アクチュエータは、通常、個別の電源が駆動されることを要求する。電源４０は、インタフェース装置１４のハウジング内に含まれていてもよく、あるいは例えば電源コードにより接続された別個の構成要素として設けることができる。
【００５０】
この他に、ＵＳＢまたは類似のプロトコルを用いたときは、インタフェース装置１４は、ＵＳＢから電力を引き出すことができ、従って電源４０を必要とはしない。この実施形態は、受動アクチュエータ３０を有する装置１４に最適である。これは、受動アクチュエータが動作のための電源を殆ど必要としないからである。能動アクチュエータは、ＵＳＢから得られるものよりも更に多くの電力を必要とする傾向があるが、この制限は多くの方法で克服できる。一つの方法は、インタフェース１４がホストコンピュータ１２に対する一つ以上の周辺装置に見えるようにインタフェース１４を構成することである。例えば、ユーザオブジェクト３４の所与の自由度の各々は、異なる周辺装置として構成することができ、自身の電力割当分を受け取ることができる。これは、ホスト１２がインタフェース装置１４により多くのパワーを割り当てることを可能にする。この他に、ＵＳＢからの電力は、インタフェース装置１４によって貯蔵および調整することができ、従ってアクチュエータ３０を駆動するために必要なときに使用することができる。例えば、電力は所定時間にわたって蓄積された後、直ちに散逸され、ユーザオブジェクト３４に対してジョルト力を与えることができる。例えば、コンデンサ回路がエネルギを蓄積し、十分な電力が蓄積されたときエネルギを散逸させる。マイクロプロセッサは、力の出力を調整して、蓄積されるべき電力に対して許容される時間を確保する必要がある。この電力蓄積態様は、インタフェース装置１４の非ＵＳＢ形態でも使用することができ、これにより、より小さな電源４０を使用することができるようになる。
【００５１】
安全性のために、安全スイッチ４１がインタフェース装置に含まれていて、ユーザがアクチュエータ３０を無効にして停止することを可能にする機構や、ユーザがアクチュエータ３０を作動させなければならないようにする機構が設けられていることが好ましい。ある種のアクチュエータ、特にモータのような能動アクチュエータは、アクチュエータがユーザオブジェクト３４を強い力で不意に移動させるときは、ユーザに対して安全性の問題を与える。更に、制御システム１０に故障が生じると、ユーザはアクチュエータを素早く停止させてけがを避けようとする。このような選択肢を与えるため、安全スイッチ４１がアクチュエータ３０に結合される。好適な実施形態では、ユーザは、アクチュエータ３０を作動させるインタフェース装置１４の動作中、安全スイッチ４１を絶えず作動させ、あるいは閉じていなければならない。任意の時点で、安全スイッチが停止すると（開かれると）、電源４０からの電力は、安全スイッチが停止している限りアクチュエータ３０に対して遮断される（或いは、アクチュエータが停止状態にされる）。安全スイッチの好適な実施形態は、例えば、ユーザオブジェクト３４（ジョイスティックなど）の上、またはインタフェース装置１４を収容するハウジングの都合のよい面上、に配置された光学スイッチである。ユーザが手または指で光学スイッチをカバーすると、スイッチのセンサは周囲の光の検出を阻止され、スイッチが閉じる。このため、アクチュエータ３０は、ユーザがスイッチを覆っている限り機能する。他の実施形態では、他の種類の安全スイッチ４１を設置してもよい。例えば、静電接点スイッチを用いて接触を検出したり、ボタンやトリガを押したり、異なる種類のセンサスイッチを使用することができる。
【００５２】
ユーザオブジェクト３４は、ユーザが握ったり、或いはユーザが触ったり制御することの可能な装置または物品であって、インタフェース装置１４に結合された装置または物品であることが好ましい。「握る」とは、ユーザがオブジェクトのグリップ部分を或る方法で、例えば手により、或いは障害者の場合は口を使って、開放自在にユーザの指先と係合させることを意味する。ユーザ２２は、オブジェクトを所与の自由度に沿って操作および移動させて、ユーザが表示画面２０上で見ているホストアプリケーションプログラムとインタフェースすることができる。オブジェクト３４は、ジョイスティック、マウス、トラックボール、スタイラス、ステアリングホイール、医療機器（ラパロスコープ、カテーテルなど）、プールキュー、ハンドグリップ、ノブ、ボタン、その他の物品とすることができる。
【００５３】
図２は、インタフェース装置１４の能動アクチュエータ３０用のアクチュエータインタフェース３８の例を示す概略図である。この例では、アクチュエータ３０は、直線電流制御サーボモータである。アクチュエータインタフェース３８は、ＤＡＣ回路４４および電力増幅回路４６を有する。
【００５４】
ＤＡＣ回路４４は、マイクロプロセッサ２６に結合され、好ましくはマイクロプロセッサ２６から力値を表すデジタル信号を受信する。ＤＡＣ４８は、入力デジタル信号を電力増幅回路４６に出力されるアナログ電圧に変換するのに適している。適切なＤＡＣ４８は、National Semiconductor製のＤＡＣ１２２０などの並列ＤＡＣであり、これは外部の一般的なオペアンプ５０と共に動作するように設計されている。オペアンプ５０は、例えば、その入力において、二進数に比例する０から−５ボルトの信号を出力する。オペアンプ５２は、出力電圧を対称バイポーラ範囲に変換する反転加算増幅器である。オペアンプ５２は、オペアンプ５０の出力を反転し、その出力から２．５ボルトを減算することにより−２．５Ｖ〜＋２．５Ｖの出力信号を生成する。この出力信号は、増幅回路４６における電力増幅に適している。例えば、Ｒ１＝２００ｋＷ、Ｒ２＝４００ｋＷである。
勿論、ＤＡＣ回路４４は、デジタル信号を所望のアナログ信号に変換するために用いることができる多くの可能な回路の一つの例として意図されている。
【００５５】
電力増幅回路４６は、ＤＡＣ回路４４からアナログ低電力制御電圧を受け取り、アクチュエータ３０を制御する電圧を増幅する。アクチュエータ３０は、高電力電流制御サーボモータ３０である。入力電圧は、増幅器５４と幾つかの抵抗器とからなるトランスコンダクタンス段を制御する。このトランスコンダクタンス段は、モータ３０を駆動する入力電圧に比例する出力電流を生成し、入力電圧源から微小な電流を引き出す。増幅器５６、抵抗器、およびコンデンサＣを含む第二の増幅段は、モータ３０の第二端子５７の電圧スイングを増強することにより付加的な電流容量を与える。電力増幅回路４６に対する値の例は、Ｒ＝１０ｋＷ、Ｒ２＝５００Ｗ、Ｒ３＝９．７５ｋＷ、およびＲ４＝１Ｗである。勿論、回路４６は、能動アクチュエータ３０を駆動する電圧を増幅するために用いることができる多くの可能な回路の一例として意図されている。
【００５６】
図３は、受動アクチュエータと共に使用できるアクチュエータインタフェース３８′の例を示す概略図である。インタフェース３８′は、アナログ電圧を用いて制御される受動アクチュエータ（ダンパ）、例えば流体制御受動ダンパと共に使用できる可変ソレノイドや磁気粒子ブレーキ、と共に使用するのに適している。インタフェース３８′は、ＤＡＣ回路４４、増幅器６０、トランジスタ６２、および電圧プロテクタ６４を有する。ＤＡＣ回路４４は、マイクロプロセッサ２６に結合されており、ユーザオブジェクト３４に印加されるべき抵抗性力値を表すデジタル信号をコンピュータシステムから受信する。ＤＡＣ回路４４は、このデジタル信号電圧をアナログ電圧に変換する。この電圧は、この後、増幅器６０に出力される。適切なＤＡＣは、Maxim製のMAX５３０ACNGや、図２を参照して上記したＤＡＣ回路４４である。増幅器６０は、ＤＡＣ４４からのアナログ電圧を正の端子で受け取り、この電圧信号をアクチュエータ３０により使用可能な範囲にスケーリングする。増幅器６０は、演算増幅器などとして実施できる。トランジスタ６２は、増幅器６０の出力に結合され、好ましくは、増幅した出力電流をアクチュエータ３０に供給する増幅器として動作する。抵抗器Ｒ１が増幅器６０とトランジスタ６２との間に結合され、また抵抗器Ｒ２が増幅器６０とグラウンドとの間に結合される。例えば、抵抗器Ｒ１とＲ２はそれぞれ１８０ｋΩと１２０ｋΩの値を持ち、回路中に適切なバイアスを与える。電圧プロテクタ６４はトランジスタ６２のエミッタに結合され、誘導性負荷を用いたとき電圧スパイクからの保護を与える。この回路と共に用いられる適切な受動アクチュエータ３０は、可変ソレノイドまたは磁気粒子ブレーキを有する。インタフェース装置で実施されるアクチュエータ３０の各々に対して別個のＤＡＣと増幅器が用いられ、マイクロプロセッサ２６および／またはホストコンピュータシステム１２は各々の所与の自由度に対して個別に各々のアクチュエータを制御することができる。インタフェース３８′は、コンピュータシステムをアクチュエータにインタフェースするために用いることができる多くの可能な回路の一例として意図されている。
【００５７】
他の実施形態では、オン／オフ信号は、例えば流体制御アクチュエータのオン／オフ弁を駆動するソレノイドに対してしか必要とされない可能性がある。このような実施形態では、例えばトランジスタが、そのベース端子においてマイクロプロセッサ２６に電気的に結合され、オン／オフアクチュエータ３０におけるソレノイドの作動を制御する電気スイッチとして動作する。ＴＴＬ論理信号などの力信号がトランジスタを制御するために送出され、電流がソレノイドを流れてソレノイドを作動させオブジェクト４３の自由な運動を可能にするか、あるいは電流が流れないようにしてソレノイドを停止状態にし運動に抵抗を与えるようにする。
【００５８】
図４は、本発明の力フィードバックインタフェース装置を制御する方法７０の第１の実施形態を示す流れ図である。方法７０は、「ホスト制御」態様に対するものである。この態様では、ホストコンピュータシステム１２がマイクロプロセッサ２６にダイレクト低水準力コマンドを与え、また、マイクロプロセッサがアクチュエータ３０にこれらの力コマンドを直接与えてアクチュエータにより出力された力を制御する。
【００５９】
例えば、このホスト制御モードは、ＵＳＢ通信インタフェースを用いた実施形態に適している。データレートは十分高く、ホストが５００Ｈｚ以上で通信することを可能にし、ユーザオブジェクト３４に現実に近い力フィードバックを与える。ＵＳＢのUSB Isochronous Data Transferモードは、必要な高いデータレートを与えるのに適している。
【００６０】
プロセスは７２から始まる。ステップ７４において、ホストコンピュータシステム１およびとインタフェース装置１４は、例えばユーザ作動式電源スイッチによって電源投入される。ステップ７４の後、プロセス７０は二つの並列（同時）プロセスに分岐する。一方のプロセスはホストコンピュータシステム１２上で実施され、他方のプロセスはローカルマイクロプロセッサ２６上で実施される。これらの二つのプロセスは、ステップ７４から、この同時性を示す異なる方向に分岐する。
【００６１】
ホストコンピュータシステムプロセスでは、ステップ７６が先ず実施される。ステップ７６では、アプリケーションプログラムが処理され、更新される。このアプリケーションは、シミュレーション、ビデオゲーム、科学プログラム、または他のプログラムとすることができる。画像がユーザのために出力表示画面２０に表示され、音声フィードバックなどの他のフィードバックが与えられるようになっていてもよい。
【００６２】
二つの分岐はステップ７６を出て、ホストコンピュータシステム１２で同時に実行される二つのプロセスがあることを示している。一つのプロセスでは、ステップ７８が実施される。このステップでは、センサデータがローカルマイクロプロセッサ２６からホストコンピュータにより受信される。以下に示すように、マイクロプロセッサプロセスでは、ローカルプロセッサ２６はセンサ２８から信号を連続的に受信し、生データを処理し、処理したセンサデータをホストコンピュータ１２に送出する。あるいは、ローカルプロセッサ２６は、生データを直接ホストコンピュータシステム１２に送出する。本明細書で用いる「センサデータ」は、１以上の自由度でオブジェクト３４の動きを検出するセンサ２８から得られた位置値、速度値、および／または加速度値を含んでいてもよい。更に、インタフェース装置１４上のボタンがユーザにより作動させられているということを示す信号など、他の入力装置３９から受信された他のデータもステップ７８においてセンサデータとしてホストコンピュータシステム１２により受信される。最後に、用語「センサデータ」は、以前に記録され、速度を計算するために保存された位置値などの値の履歴を含んでいてもよい。
【００６３】
センサデータがステップ７８で読み出された後、プロセスはステップ７６に戻る。ステップ７６では、ホストコンピュータシステム１２は、オブジェクト３４のユーザによる操作およびステップ７８で受信された他のユーザ入力に応じてアプリケーションプログラムを更新し、力が並列プロセスでオブジェクト３４に加えられる必要があるかどうかを判断する。ステップ７８は、ローカルプロセッサ２６からデータを読み取る連続ループで実施される。
【００６４】
ステップ７６からの第二の分岐は、オブジェクト３４を操作するユーザに力フィードバックを与える力コマンドを決定するホストコンピュータのプロセスに関する。これらのコマンドは、本明細書では「低水準」力コマンドとして説明され、図５の実施形態で説明される「高水準」コマンドまたは監視力コマンドと区別される。低水準力コマンドは、特定の大きさの力をアクチュエータが出力するように指令する。例えば、低水準コマンドは、通常、大きさ力値、例えばアクチュエータが所望の大きさ値の力を加えることを命令する等価な信号、を含んでいる。低水準力コマンドはまた、アクチュエータが選択された方向に力を加えることができる場合に力の方向を示し、および／またはアクチュエータにより要求される他の低水準情報を示すことができる。
【００６５】
第二の分岐はステップ８０で始まる。このステップでは、ホストコンピュータシステムが、ユーザオブジェクト３４に加えられた力の変化が要求されているかどうかをチェックする。これは幾種類かの基準により判断される。これらの基準のうちの最も重要なものは、ステップ７８で読み取られたセンサデータ、タイミングデータ、およびステップ７６で更新されたアプリケーションプログラムの実施または「事象」である。ステップ７８で読み取られたセンサデータは、ユーザがアプリケーションプログラムと対話している方法をホストコンピュータ１２に通知する。ホストコンピュータシステム１２は、所定時間にわたって検出されたオブジェクト３４の位置から、いつ力をオブジェクトに印加すべきかを決定する。例えば、ホストコンピュータがビデオゲームアプリケーションを実施している場合は、ゲーム内でのコンピュータ生成オブジェクトの位置によって、力フィードバックの変化が求められているかどうかを判断することができる。ユーザが模擬レースカーを制御しているときは、ユーザオブジェクトジョイスティックの位置によって、レースカーが壁の中を移動しているかどうかが判断され、これにより、衝突力をジョイスティック上に生成すべきかどうかが判断される。更に、ユーザオブジェクトの速度および／または加速度は、オブジェクトに対する力の変化が必要かどうかに影響を与える。ユーザがゲームにおいてテニスラケットを制御しているときは、特定の自由度のユーザオブジェクトジョイスティックの速度によって、テニスボールが打たれたどうかが判断され、これにより、適当な力をジョイスティックに加えるべきかどうかが判断される。更に、インタフェース装置１４においてボタンまたは他の制御装置をユーザが作動させるなどといった他の入力は、それらの制御装置が如何にプログラムされてアプリケーションプログラムに影響を与えるかに応じて、オブジェクト３４に要求される力を変化させることができる。
【００６６】
力の変化が必要かどうかを判断するための他の基準には、アプリケーションプログラム中の事象が含まれる。例えば、ゲームアプリケーションプログラムは、ユーザオブジェクト３４の位置データとは無関係に、ゲーム中の他のオブジェクトがユーザにより制御されたオブジェクトと衝突しようとしていることを（恐らくランダムに）判断することができる。従って、力は、衝撃をシミュレートするこの衝突事象に依存してユーザオブジェクトに加えられるべきである。力は、このような事象とステップ７８で読み取られたセンサデータとの組み合わせに依存して、ユーザオブジェクト上に要求されるようになっていてもよい。アプリケーションプログラムにおける他のパラメータは、ホストコンピュータシステム１２に接続されてアプリケーションプログラムにデータを入力する他の入力装置やユーザインタフェース装置などのユーザオブジェクトに対する力の変化が必要かどうかを決定する（他のインタフェース装置は直接接続してもよいし、ネットワークなどを介して遠隔的に接続してもよい）。
【００６７】
ステップ８０において力の変化が現在のところ要求されていないときは、プロセスはステップ７６に戻ってホストアプリケーションを更新し、ステップ８０に戻って、力のこのような変化が要求されるまで再度チェックを行う。このような変化が要求されると、ステップ８２が実施される。このステップでは、ホストコンピュータ１２は、インタフェース装置１４のアクチュエータ３０に送出される適切な低水準力コマンドを決定する。この力コマンドは、選択された力感覚プロセス、センサデータ、ホストアプリケーション、およびクロック１８に依存する。
【００６８】
この低水準力コマンドは、選択された力感覚プロセスから部分的に決定することができる。本明細書で用いられる「反射プロセス（reflex process）」または「力感覚プロセス（force sensation process）」（「サブルーチン」とも呼ばれる）は、ステップ７８で読み出されたセンサデータやクロック１８からのタイミングデータ等のような他のパラメータに依存する力コマンドを与える一組の命令である。本実施形態では、力感覚プロセスは、幾つかの異なるタイプのステップおよび／または命令を含む。あるタイプの命令は、ホストコンピュータ１２がセンサおよびタイミングデータに基づいて力値を計算またはモデル化するために使用できる方程式を含む力アルゴリズムである。数タイプのアルゴリズムを用いることができる。例えば、力がオブジェクト３４の位置と線形に（または非線形に）変化するアルゴリズムを用いて、ばねのような疑似力を与えることができる。力がオブジェクト３４の速度と共に線形に変化するアルゴリズムを用いて、疑似制動力または他の力を与えることもできる。力がオブジェクト３４の加速度と共に線形に（または非線形に）変化するアルゴリズムを用いて、例えば、質量に関する疑似慣性力を与えたり（線形変化の場合）、疑似重力引張力を与える（非線形変化の場合）ことができる。このような力を計算するために用いられる数タイプの疑似力およびアルゴリズムは、スタンフォード大学デザインリサーチセンターのLouisB.Rosenbergによる「仮想剛性面接触の知覚設計（Perceptual Design of a Virtual Rigid surfacecontact）」（Report number AL/CF-TR-1995-0029、1993年4月）に示されている。この文献は、参照文献として本明細書に組み込まれる。
【００６９】
ユーザオブジェクト３４の速度および加速度に依存する力値に対して、速度および加速度は多様な方法で与えることができる。ステップ７８でホストコンピュータ１２により読み取られたセンサデータは、位置データ、速度データ、および加速度データを含んでいる。好適な実施形態では、速度および加速度データが予めマイクロプロセッサ２６により計算され、次にホストコンピュータ１２に与えられる。かくして、ホストコンピュータは、力値を計算するアルゴリズムにおいて直接速度および加速度データを用いることができる。他の実施形態では、ステップ７８で読み取られたセンサデータは、位置データを含み、速度または加速度データは含まず、従ってホストコンピュータ１２は位置データから速度および加速度を計算する必要がある。これは、過去の位置値を多数記録し、このような位置値の各々がシステムクロック１８を用いて受信された時間を記録し、このようなデータから速度および／または加速度を計算することによって実現される。
【００７０】
例えば、減衰定数を乗じたユーザオブジェクトの速度に基づいて力を計算する運動方程式を用いて、ユーザオブジェクトに対する制動力を計算することができる。この種の方程式は、流体や同様の材料を通過する１自由度に沿ったオブジェクト３４の運動をシミュレートすることができる。例えば、液体などの疑似材料を通過して動くときにオブジェクト３４が遭遇する抵抗の度合を示す減衰定数を最初に選択することができる。ここで、大きな数ほど大きな抵抗を示す。例えば、水は、オイルまたはシロップより低い減衰定数を有する。ホストコンピュータは、ユーザオブジェクト３４の（特定の自由度に沿った）前の位置を呼び戻し、ユーザオブジェクトの現在の位置を調べ、更に位置の差を計算する。差の符号（負または正）から、オブジェクト３４の運動の方向も決定することができる。この後、位置の変化量を乗じた減衰定数に等しくなるように力が設定される。このアルゴリズムに基づいてアクチュエータを制御したコマンドが、ユーザオブジェクトの動きに比例した力を生成して、流体を通過する運動をシミュレートする。他の媒体における動き、例えば凹凸面や傾斜面の上での動きなどは、力を計算する異なる方法を用いて同様にシミュレートする事ができる。
【００７１】
力コマンドの決定は、システムクロック１８からアクセスされたタイミングデータにより影響を受けると好適である。例えば、上記の制動力の例では、ユーザオブジェクト３４の速度は、ユーザオブジェクトの位置の差を計算し、減衰定数を乗じることにより決定される。この計算はデータ点の間に一定の時間間隔を想定している。すなわち、オブジェクト３４の位置データは、ホストコンピュータ１２によって規則的な所定の時間間隔で受信されると仮定されている。しかし、このようなことは、異なるコンピュータプラットフォームの異なる処理速度や、単一ホストマイクロプロセッサ１６での処理変動、例えばマルチタスク、に起因して、実際に生じることはない。従って、本発明では、ホストコンピュータは、好ましくはクロック１２にアクセスして、最後の位置データが受信されてからどれだけの時間が実際に経過したかを求める。制動力の例では、ホストコンピュータは、位置の差を取得することができ、またそれをある時間尺度で除算してタイミングの差を考慮することができる。このように、ホストコンピュータは、ユーザに対する力および力感覚の変調にクロックのタイミングデータを用いることができる。タイミングデータは、本発明の力感覚プロセスや他のアルゴリズムで用いることができ、プラットフォームの種類やホストコンピュータ１２で利用可能な処理時間にかかわらず、反復可能で一貫した力フィードバックを与えることができる。
【００７２】
力感覚プロセスには、他の命令が含まれていてもよい。例えば、所望の方向にのみ力を与えたり、他の特定の状況でのみ力を与えるような条件が含まれていてもよい。例えば、壁などの仮想の障害をシミュレートするためには、力は一方向（単方向）にのみ加えられるべきである。多くの受動アクチュエータの場合、双方向の抵抗力しか加えることができない。単方向の抵抗をシミューレートするために、仮想障害力感覚プロセスに条件が含まれていてもよい。仮想障害力感覚プロセスにおけるこのような条件の例は、図１２を参照して説明する。また、ホストコンピュータ１２（または図５の実施形態におけるマイクロプロセッサ２６）が低水準コマンドまたは力値を出してユーザオブジェクト３４に対してゼロ力を与える（すなわち、全ての力を取り除く）ことを指示する「ヌル」反射プロセスも使用することができる。
【００７３】
他のタイプの力感覚プロセスは、力をモデル化するアルゴリズムを用いないが、代わりに、予め計算され、またはサンプリングされ、更にメモリまたは他の記憶装置にデジタル化「力プロファイル」として格納されている力値を用いる。これらの力値は、上述したように方程式またはアルゴリズムを用いて予め生成され、あるいは力をサンプリングしてデジタル化することより与えられる。例えば、ユーザに特定の力感覚を与えるため、ホストコンピュータ１２は、力感覚プロセスにより命令を受けて、ＲＡＭ、ＲＯＭ、ハードデイスクなどの特定の記憶装置から連続した力値を取り出すことができる。これらの力値は低レベレコマンドで直接アクチュエータに送られ、ホストコンピュータ１２を必要とせずに特定の力を与えることができる。更に、既に格納された力値を他のパラメータに対して出力することができ、これにより、一組の格納力値から異なるタイプの力および力感覚を与えることができる。例えば、システムクロック１８を用いると、格納された力値が、所望の力に依存して変化しうる特定の時間間隔に従って順次に出力されるようにすることができる。或いは、取り出された異なる力値が、ユーザオブジェクト３４の現在の位置に応じて出力されるようにすることができる。
【００７４】
ホストコンピュータ１２は、新たに選択された反射プロセスまたは予め選択された反射プロセスに従って、ステップ８２において力コマンドを決定することができる。例えば、これが２回目以降のステップ８２の反復である場合、ホストアプリケーションプログラムによって決定されたように、パラメータ（オブジェクト３４の位置など）が許すのであれば、前回の反復におけるものと同じ反射プロセスを再度実施することができる。
【００７５】
ステップ８２で決定された力コマンドは、他のパラメータをチェックする命令にも依存する。これらの命令は、上記の反射プロセス内に含まれていてもよいし、反射プロセス外に含まれていてもよい。このようなパラメータの一つは、実施されたホストアプリケーションプログラム（あったとして）により与えられる値である。このアプリケーションプログラムは、特定の力コマンドを出力する必要があること、あるいはこのアプリケーションプログラムまたは他の命令内で生じる事象に基づいて反射プロセスを実施する必要があることを判断することができる。力コマンドまたは力値は、センサデータとは独立にホストアプリケーションプログラムによって与えられる。また、ホストアプリケーションプログラムは、自身の特定の位置データ、速度データ、および／または加速度データを選択反射プロセスに与え、ユーザオブジェクト３４の操作には基づかないがアプリケーションプログラム中の事象をシミュレートするために与えられる力を計算または提供することができる。このような事象には、ユーザ制御コンピュータ画像が仮想面または仮想構造に衝撃を与えるときに生じるような衝突事象が含まれる。更に、ホストコンピュータ１２に接続された他の入力装置は、事象に影響を与え、従ってユーザオブジェクト３４に加えられる力に影響を与える。例えば、単一のホストコンピュータに接続された複数のインタフェース装置１４からのセンサデータは、ホストアプリケーションプログラムのコンピュータ制御画像／オブジェクトおよび事象に影響を与えることにより、他の接続インタフェース装置で感じられる力に影響を与えることができる。
【００７６】
また、ステップ８２で決定された力コマンドは、ホストコンピュータ１２への他の入力、例えばインタフェース装置１４中（またはその外部）のボタンや他の入力装置の作動、に基づいていてもよい。例えば、特定のアプリケーションプログラムは、ユーザがジョイスティックのファイヤボタンを押すときは常にジョイスティックに力が加わることを要求する。
【００７７】
上記の反射プロセスおよび他のパラメータを用い、ユーザオブジェクト３４を介してユーザに種々の触覚を与え、多様な触覚事象をシミュレートすることができる。例えば、一般的な触覚には、仮想的な減衰（上述したもの）、仮想障害、仮想質感が含まれる。仮想障害は、シミューレーション、ゲームなどにおける壁、障害、および他の単方向力をシミュレートするために与えられる。ユーザがコンピュータ画像をジョイスティックにより仮想障害に移動させると、ユーザは、彼または彼女がその方向にジョイスティックを移動させ続けるとき物理的抵抗を感じる。ユーザがオブジェクトを障害から離れるように動かすと、単方向力が除去される。このようにして、画面上に表示された仮想障害が物理的性質を持つという説得力のある感覚がユーザに与えられる。同様に、仮想質感が用いられ、表面状態や同様の質感をシミュレートすることができる。例えば、ユーザがジョイスティックまたは軸に沿う他のユーザオブジェクトを動かすと、ホストコンピュータは、迅速な一連のコマンドを送り、反射プロセスのように、１）その軸に沿って抵抗を加え、２）次に、その軸に沿った抵抗の印加を直ちに停止することを繰り返す。この頻度はジョイスティックハンドルの移動に基づいており、従って空間位置との相関を有している。このため、ユーザは、質感という物理的感覚を感じることができる。この質感は、格子の上でスティックを引きずる感覚と説明することができる。
【００７８】
次のステップ８４では、ステップ８２において決定された低水準力コマンドがバス２４を介してマイクロプロセッサ２６に出力される。この力コマンドは、通常、上記のパラメータに従って決定された力値を有する。この力コマンドは、マイクロプロセッサ２６によって単にアクチュエータ３０に中継される実際の力信号として出力されてもよいし、あるいはアクチュエータ３０に送出される前にマイクロプロセッサ２６によって適当な形式に変換されてもよい。更に、低水準力コマンドは、どのアクチュエータがこの力値を受け取ることになっているかをマイクロプロセッサ２６に示す情報を含んでいることが好ましい（複数のアクチュエータがインタフェース装置１４に含まれている場合）。次に、本プロセスはステップ７６に戻り、ホストアプロケーションプロセスを処理／更新する。このプロセスはステップ８０に続き、ステップ８０では、ホストコンピュータは、異なる力コマンドを上記のパラメータにより決定されたものとして出力すべきかどうかをチェックする。もしそうなら、ステップ８４で新しい力コマンドが決定され、出力される。力の変化が要求されないときは、マイクロプロセッサ２６が前回の力コマンドをアクチュエータ３０に出力し続けることができるので、ホストコンピュータ１２は、他のコマンドを発することはない（この他に、ホストコンピュータ１２は、力の変化が要求されてもコマンドを出力し続けるようになっていてもよい）。ステップ８４における後続の力コマンド出力は、ステップ８２のパラメータに応じて、同じ反射プロセスまたは異なる反射プロセスに従って決定することができる。
【００７９】
更に、ホストコンピュータ１２は、好ましくは、任意の適切な視覚フィードバック、聴覚フィードバック、またはホストアプリケーションに関連する他のフィードバックを、ユーザオブジェクト３４への力の印加に同期させる。例えば、ビデオゲームアプリケーションでは、表示画面２０上でユーザと衝突するオブジェクトなどの視覚事象の立上りまたは開始は、これらの視覚事象に対応し、あるいはこれらの視覚事象を補足するユーザによって感じられる力の立上りまたは開始に同期される必要がある。視覚事象および力事象の立上りは、互いり約３０ミリ秒（ｍｓ）以内に生じることが好ましい。この時間の長さは、同時のものとして事象を知覚する人間の知覚能力の一般的な限界である。視覚事象および力事象がこの範囲外で生じるときは、通常、事象間のタイムラグが知覚される。同様に、ホストアプリケーションにおける聴覚事象の立上りに対応する聴覚信号の出力は、これらの聴覚事象に対応／補足する出力力の立上りに同期して出力される。再び、これらの事象の立上りは、互いの約３０ｍｓ以内に生じることが好ましい。例えば、ホストコンピュータシステム１２は、スピーカ２１からの爆発音を、シミュレーションにおけるその爆発からユーザによって感じられる力に時間的にできるだけ近接して出力することができる。好ましくは、この音の大きさは、ユーザオブジェクト３４により印加された力の大きさに正比例（反比例とは逆）している。例えば、シミュレーションの間、遠い（仮想）距離における爆発の低い音は、ユーザオブジェクト３４に小さな力を生じさせ、大きな「近い」爆発によって大きな音がスピーカから出力され、対応する大きな力がオブジェクト３４に出力されるようになっていてもよい。
【００８０】
ローカルマイクロプロセッサ２６は、ステップ７４から分岐して上記のホストコンピュータプロセスと並列にステップ８６から開始するプロセスを実施する。ステップ８６では、インタフェース装置１４が作動状態にされる。例えば、ホストコンピュータ１２とインタフェース装置１４との間に信号を送出することで、インタフェース装置が現在アクティブであることを知らせてもよい。ステップ８６から、二つのプロセスが分岐して、ローカルプロセッサ２６上で同時に実行される（マルチタスクする）二つのプロセスが存在することを示す。一つのプロセスでは、ステップ８８が実施され、プロセッサ２６がセンサ２８から生データ（センサの読み取り値）を読み取る。このような生データは、好ましくは所与の自由度に沿ってユーザオブジェクトの位置を記述する位置の値を含んでいる。好適な実施形態では、センサ２８は相対センサであり、この相対センサは、最後の位置が読み取られてからの位置の変化を記述する位置値を与える。プロセッサ２６は指示された基準位置からの相対位置を測定することにより絶対位置を決定することができる。他の実施形態では、センサ２８は、オブジェクト３４の生の速度値および加速度値を与える速度センサおよび加速度計を有していてもよい。ステップ８８で読み出された生データは、インタフェース装置１４の作動ボタンや他の制御装置３９からの入力など、他の入力を有していてもよい。
【００８１】
次のステップ９０では、プロセッサ２６は、適当であれば、受信された生データを処理してセンサデータにする。好適な実施形態では、この処理は二つのステップを含む。すなわち、生位置データからの速度値および／または加速度値を計算するステップ（速度および／または加速度が力を計算するのに必要とされるとき）と、計算された速度および加速度データを濾波するステップと、を含んでいる。速度値および加速度値は、ステップ８８で受信された生位置データならびに格納された位置値および時間値から計算される。好ましくは、プロセッサ２６は、一連の位置値と、位置値が受信された時点に対応する時間値と、を格納する。プロセッサ２６は、自身のシステムクロックまたはローカルシステムクロック（図１には図示せず）を用いてタイミングデータを求める。速度と加速度は、当業者には周知のように、格納された位置データとタイミングデータを用いて計算される。次に、計算された速度値および／または加速度値を濾波して、データからノイズ、例えば速度計算においてオブジェクト３４の位置の急速な変化から生じることのある大きなスパイク、を除去することができる。このように、本実施形態におけるセンサデータは、位置、速度、加速度、およびその他の入力データを含んでいる。他の実施形態では、プロセッサ２６に電気的に結合されるがプロセッサ２６から分離した回路が生データを受信し、速度および加速度を決定することができる。例えば、特定用途集積回路（ＡＳＩＣ）やディスクリートな論理回路は、カウンタなどを用いて速度と加速度を決定し、マイクロプロセッサ２６上での処理時間を節約することができる。
【００８２】
この他に、ステップ９０を省略し、プロセッサ２６が生位置データ（および他の入力装置３９からの他の入力データ）をホストコンピュータ１２に供給するようになっていてもよい。これにより、ホストコンピュータ１２が位置データから速度および加速度を濾波して計算することが必要となる。このように、プロセッサ２６がこの処理を実行してホストコンピュータ１２で行われる処理の量を減少させことが好適である。他の実施形態では、濾波がホストコンピュータ１２で行われ、速度および加速度計算はプロセッサ２６で行われる。更に、速度および／または加速度センサを用いて生の速度および加速度データを与える実施形態では、速度および／または加速度の計算は省略できる。ステップ９０の後、ステップ９１が実施される。このステップでは、プロセッサ２６は、処理されたセンサデータをバス２４を介してホストコンピュータ１２に送出する。次に、プロセスはステップ８８に戻り、生データを読み取る。ステップ８８、９０および９１はこのように連続して実施され、現在のセンサデータをホストコンピュータシステム１２に与える。
【００８３】
ステップ８６からの第二の分岐は、アクチュエータ３０を制御して、ホストコンピュータ１２により計算された力をオブジェクト３４に与えるプロセッサ２６に関係する。第二の分岐はステップ９２から開始し、このステップでは、低水準力コマンドがバス２４を介してホストコンピュータ１２から受信されたか否かをプロセッサ２６がチェックする。受信されていない場合、プロセスはこのような力コマンドを連続的にチェックする。力コマンドが受信された場合は、ステップ９４が実施される。このステップでは、プロセッサ２６が低水準プロセッサ力コマンドを指定されたアクチュエータに出力し、出力力を所望の大きさ、方向などに設定する。この力コマンドは、ホストコンピュータからの受信低水準コマンドと同等であってもよいし、あるいは、プロセッサ２６が任意選択的に力コマンドをアクチュエータ３０により使用可能な適当な形態に変換してもよい（あるいは、アクチュエータインタフェース３８がこのような変換を行ってもよい）。次に、プロセスはステップ９２に戻り、ホストコンピュータ１２からの他の力コマンドをチェックする。
【００８４】
図５は、本発明の力フィードバックインタフェース装置１４を制御する方法１００の第２の実施形態を示す流れ図である。方法１００は「反射」形態に対するものである。この形態では、ホストコンピュータシステム１２は、マイクリプロセッサ２６に高水準監視力コマンド（「ホストコマンド」）しか与えず、マイクロプロセッサ２６は、独立した「反射」として低水準力コマンド（力値）をアクチュエータ３０に与えて、アクチュエータによる力出力を制御する。
【００８５】
図５のプロセスは、標準ＲＳ−２３２シリアルインタフェースなどの低速通信インタフェースに適している。しかしながら、図５の実施形態は、ローカルマイクロプロセッサがホストプロセッサ１６からの計算負荷を解放するので、ＵＳＢなどの高速通信インタフェースにも適している。更に、この実施形態は、直送コマンドプロトコルを与えることができる。その例は図９および１４を参照して説明するが、これにより、ソフトウェア開発者がホストアプリケーションにおいて容易に力フィードバックを与えることが可能になる。この実施形態では、例えば、より遅いＵＳＢの「割込みデータ転送」モードを用いることができる。
【００８６】
このプロセスは１０２から始まる。ステップ１０４では、ホストコンピュータシステム１２とインタフェース装置１４が、例えばユーザ作動電源スイッチによって電源投入される。ステップ１０４の後、プロセス１００は二つの並列プロセスに分岐する。一方のプロセスはホストコンピュータシステム１２で実施され、他方のプロセスはローカルマイクロプロセッサ２６で実施される。
【００８７】
ホストコンピュータシステムプロセスでは、ステップ１０６が初めに実施され、そこでアプリケーションプログラムが処理される。このアプリケーションは、シミュレーション、ビデオゲーム、科学プログラム、または他のプログラムであってもよい。画像を出力表示画面２０上に表示してもよく、また音声フィードバックなどの他のフィードバックを提供してもよい。
【００８８】
二つの分岐がステップ１０６を出て、ホストコンピュータシステム１２上で同時に走る（マルチタスクなど）二つのプロセスが存在することを示している。一方のプロセスでは、ステップ１０８が実施される。このステップでは、ユーザオブジェクトからのセンサデータがローカルマイクロプロセッサ２６からホストコンピュータによって受信される。図４のプロセスのステップ７８と同様に、ホストコンピュータシステム１２は、生データ（例えば位置データであり、速度または加速度データは含まない）か処理済センサデータ（位置、速度および／または加速度データ）のいずれかをマイクロプロセッサ２６から受信する。更に、他の入力装置３９から受信された任意の他のデータ、例えばインタフェース装置１４のボタンがユーザによって押されていることを示す信号、も、ステップ１０８においてマイクロプロセッサ２６からホストコンピュータシステム１２によって受信することができる。
【００８９】
図４の前の実施形態とは異なり、ホストコンピュータは、ステップ１０８において受信されたセンサデータから力値を計算することはない。代わりに、ホストコンピュータ１２は、センサデータを監視して、力のタイプの変更が必要となる時点を決定する。これは以下で更に詳細に説明される。勿論、ホストコンピュータ１２は、ホストアプリケーションに対する入力としてセンサデータを用い、これに従ってホストアプリケーションを更新することも行う。
【００９０】
ステップ１０８でセンサデータが受信された後、プロセスはステップ１０６に戻る。このステップでは、ホストコンピュータシステム１２は、オブジェクト３４のユーザの操作およびステップ１０８で受信された他のユーザ入力に応じてアプリケーションプログラムを更新することができる。次に、ローカルプロセッサ２６からセンサデータセットを受信する連続ループにおいてステップ１０８が再び実施される。ホストコンピュータはセンサデータに基づいて直接アクチュエータを制御する必要がないので、センサデータははるかに遅い速度で与えることができる。例えば、ホストコンピュータは、センサデータに応じて表示画面２０上の画像とホストアプリケーションを更新するので、センサデータは、センサ信号から低水準力フィードバック信号を現実的に供給するのに必要な約５００〜１０００Ｈｚ（またはそれ以上）というはるかに高い速度に比べて、６０〜７０Ｈｚ（通常の表示画面のリフレッシュサイクル）で読み出すことしか必要としない。また、ホストコンピュータ１２は、図４を参照して上記したものと同様に、視覚事象、音声事象および力事象に同期していることが好ましい。
【００９１】
ステップ１０６からの第二の分岐は、オブジェクト３４を操作してユーザに力フィードバックを与える高水準力コマンド（「ホストコマンド」）を決定するホストコンピュータのプロセスに関係する。この第二分岐はステップ１１０で開始する。このステップでは、ホストコンピュータシステムが、ユーザオブジェクト３４に加えられる力のタイプの変更が必要かどうかをチェックする。力の「タイプ」は、特定の反射プロセスにより生成された力感覚もしくはプロファイル、またはローカルマイクロプロセッサ２６がホストコンピュータとは独立に実現することができる力値である。ホストコンピュータ１２は、ステップ１０８においてホストコンピュータにより読み取られたセンサデータに依存し、またステップ１０６において更新されたアプリケーションプログラムの事象に依存して、力のタイプの変更が必要がどうかを判断する。図４を参照して説明したように、センサデータは、オブジェクトの現在の位置、速度、および／または加速度に基づいてオブジェクトに力を加えるべき時点をホストコンピュータに通知する。ユーザによるオブジェクト３４の操作により、新しいタイプの力が必要となる場合がある。例えば、ユーザがビデオゲームにおいて仮想の泥のプール内で仮想レースカーを操作している場合、レースカーが泥の中で走行している限りは減衰タイプの力がオブジェクト３４に印加されるべきである。このように、制動力がオブジェクトに連続的に印加される必要はあるが、力のタイプの変更は必要とされない。レースカーが泥のプールから抜けて移動すると、新しいタイプの力（すなわち、この場合では制動力の除去）が必要となる。アプリケーションプログラムの事象も、印加される力のタイプの変更を要求する。例えば、ユーザの車が泥を通って移動し、他の車がユーザの車に衝突するときは、新しいタイプの力（衝突力）がユーザオブジェクトに加えられるべきである。ステップ１０８で読み出されたセンサデータとアプリケーション事象との組み合わせに依存した力がユーザオブジェクトに必要とされる場合がある。また、他の入力、例えばインタフェース装置１４のボタンや他の入力装置３９をユーザが作動させること、により、オブジェクト３４に対して必要とされる力のタイプを変えることがある。
【００９２】
力のタイプの変更がステップ１１０において現在必要でないときは、プロセスはステップ１０６に戻り、ホストアプリケーションを更新し、更にステップ１１０に戻って、このような力のタイプの変更が必要になるまでチェックを行う。このような変更が必要になると、ステップ１１２が実施される。このステップでは、ホストコンピュータ１２が、マイクロプロセッサ２６に送出する適当なホストコマンドを決定する。ホストコンピュータ１２が利用可能なホストコマンドは、マイクロプロセッサ２６により実施される関連反射プロセスにそれぞれ対応する。例えば、制動力、ばね力、重力引力、凹凸表面力、仮想障害力、および他の力を与えるホストコマンドをホストコンピュータ１２が利用できるようにしてもよい。これらのホストコマンドは、オブジェクト３４にこの所望の力を印加する特定のアクチュエータ３０や自由度の指定も含んでいてもよい。これらのホストコマンドは、特定の反射プロセスにより生成される力を変える他のコマンドパラメータ情報を含んでいてもよい。例えば、所望の量の制動力を指示するホストコマンドに減衰定数が含まれていてもよい。また、ホストコマンドは、好ましくはプロセッサ２６の反射動作を無効にし、低水準力値を有していてもよい。好適なコマンドプロトコルおよび一組のホストコマンドは、図９および図１４を参照して詳細に説明される。次のステップ１１４では、ホストコンピュータは、バス２４を介してマイクロプロセッサ２６にホストコマンドを送出する。次に、このプロセスはステップ１０６に戻り、ホストアプリケーションを更新し、更にステップ１１０に戻り、力の他の変化が必要かどうかをチェックする。
【００９３】
ローカルマイクロプロセッサ２６は、ステップ１０４から分岐して上記ホストコンピュータプロセスと並列にステップ１１６から開始するプロセスを実施する。ステップ１１６では、インタフェース１４が作動状態にされる。例えば、ホストコンピュータ１２とインタフェース装置１４との間に信号を送ることで、インタフェース装置が現在アクティブであり、ホストコンピュータ１２により指令を受けることができる状態になっていることを知らせてもよい。ステップ１１６から、二つのプロセスが分岐して、ローカルプロセッサ２６上で同時に実行される（マルチタスクする）二つのプロセスが存在することを示す。一つのプロセスでは、ステップ１１８が実施され、プロセッサ２６がセンサ２８から生データを読み取る。図４のステップ８８で述べたように、プロセッサ２６は、センサ２８から位置データを読み取り、速度または加速度データは読み取らないことが好ましい。他の実施形態では、センサ２８は、オブジェクト３４の速度値および加速度値を与える速度センサおよび加速度計を有していてもよい。ステップ１１８で読み出されたセンサデータは、インタフェース装置１４の作動ボタンや他の制御装置３９からの入力など、他の入力を有していてもよい。
【００９４】
次のステップ１２０では、プロセッサ２６は、受信された生データを処理してセンサデータにする。図４のステップ９０に示したように、この処理は、濾波された位置データから速度および加速度データを計算するステップと、速度および加速度データを濾波するステップと、からなる二つのステップを有していることが好ましい。プロセッサ２６は、自身のローカルクロック２１を使用して速度および加速度を計算するために必要なタイミングデータを求めることができる。更に、前の記録値、例えば位置値や速度値、の履歴を用いてセンサデータを計算することもできる。速度および／または加速度センサが用いられる実施形態では、速度および／または加速度の計算は省略される。次のステップ１２１では、プロセッサ２６が処理済センサデータをホストコンピュータ１２に送出し、また、プロセッサ２６の第二の分岐プロセスに示されるように、力を計算するためのデータを格納する。次に、プロセスはステップ１１８に戻り、生データを読み取る。こうして、ステップ１１８、１２０および１２１が連続的に実施され、プロセッサ２６およびホストコンピュータ１２に現在のセンサデータが与えられる。
【００９５】
ステップ１１６からの第二の分岐は、「アクチュエータプロセス」に関する。このプロセスでは、プロセッサ２６がアクチュエータ３０を制御して、オブジェクト３４に力を与える。第二の分岐はステップ１２２から開始する。このステップでは、プロセッサ２６は、ホストコマンドがバス２４を介してホストコンピュータ１２から受信されているかどうかをチェックする。受信されている場合、プロセスはステップ１２４に続き、ホストコマンドに伴う反射プロセスが選択される。このような反射プロセスは、、マイクロプロセッサ２６に対してローカルに、ＲＡＭやＲＯＭなど（あるいはＥＰＲＯＭ、ＥＥＰＲＯＭなど）のメモリ２７内に格納される。このようにマイクロプロセッサは、この反射プロセスからの制動力がオブジェクト３４に加えられるべきことを高水準コマンドが示したときに、減衰反射プロセスを選択することができる。使用可能な反射プロセスは、図４を参照して上述したものと同様のものであることが好ましく、アルゴリズム、格納された力プロファイルや値、条件などを含んでいてもよい。一部の実施形態では、センサデータを読み取るステップ１１８、１２０、および１２１がマイクロプロセッサ用の反射プロセスに組み込まれていて、反射プロセスが選択されるとセンサデータがの読み出しだけが行われるようになっていてもよい。また、ホストコマンドは、幾つかの場合には、単にアクチュエータ３０に送出されるべき力値を与える低水準力コマンドであってもよく（例えば図４の実施形態）、この場合、反射プロセスを選択する必要はない。
【００９６】
反射プロセスがステップ１２４で選択された後、或いは新しいホストコマンドがステップ１２２で受信されていない場合は、ステップ１２６が実施される。このステップでは、プロセッサ２６は、プロセッサ低水準力コマンド（すなわち、力値）を決定する。この力値は、反射プロセスおよび反射プロセスにより要求される他の任意のデータ、ならびに関連ホストコマンドに含まれるコマンドパラメータから導出される。上記のように、必要なデータには、センサデータおよび／またはローカルクロック２９からのタイミングデータが含まれていてもよい。このように、ステップ１２２で新しい高水準コマンドが受信されなかったときは、マイクロプロセッサ２６は、ステップ１２６で前に使用していた同じ反射プロセスに従って力コマンドを決定する。更に、ホストコマンドは力コマンドを決定するのに必要な他のコマンドパラメータ情報を含んでいてもよい。例えば、ホストコマンドは、自由度に沿った力の方向を示してもよい。
【００９７】
ステップ１２８では、プロセッサ２６は、決定したプロセッサ力コマンドをアクチュエータ３０に出力し、この出力力を所望のレベルに設定する。力コマンドを送出する前に、プロセッサ２６は、力コマンドを、アクチュエータ３０により使用可能な適切な形態に任意選択的に変換することができ、あるいはアクチュエータインタフェース３８がこのような変換を行うことができる。次に、プロセスはステップ１２２に戻り、他のホストコマンドがホストコンピュータ１２から受信されているかをチェックする。
【００９８】
このようにして、マイクロプロセッサ２６のアクチュエータプロセスは（ステップ１１８、１２０、１２２、１２４、１２６、および１２８）は、選択された反射プロセスおよび他のパラメータに従って、オブジェクト３４に作用する力をホストコンピュータ１２とは独立に提供するように動作する。反射プロセスは、マイクロプロセッサ２６により読み取られた最近のセンサデータに基づいてプロセッサ力コマンドを決定する方法を決める。反射プロセスは、ユーザオブジェクト３４の位置および他のパラメータに応じて力を印加する方法を示すので、プロセッサは、低水準力コマンドを発行し、ホストコンピュータを解放してホストアプリケーションを処理し、新しいタイプの力を出力する必要がある時点のみを決定することができる。これにより、ホストコンピュータ１２とインタフェース装置１４との間の通信速度が改善される。
【００９９】
更に、ホストコンピュータ１２は、マイクロプロセッサ２６の反射動作を無効にし、図４を参照して上述したように、計算された値や他の力値を直接与える能力を有している。例えば、ホストコマンドは、アクチュエータ３０に送出すべき力値を単に示すことができる。このオーバライドモードは、反射プロセスとしても実施できる。例えば、マイクロプロセッサ２６は、ホストコンピュータ１２から受信された低水準力コマンドのアクチュエータ３０への中継をマイクロプロセッサに命令する反射プロセスを選択することができる。
【０１００】
図６は、２以上の回転自由度をオブジェクト３４に与えるジンバル機構１４０に結合されたユーザオブジェクト３４の例の概略図である。ジンバル機構１４０は、インタフェース装置１４に結合されていてもよく、あるいはインタフェース装置１４の他の構成要素から個別にセンサ２８およびアクチュエータ３０がジンバル機構１４０取り付けられていてもよい。
【０１０１】
ジンバル機構１４０は、接地面１４２によって支持することができる。この面は、例えばインタフェース装置１４のハウジングの表面（部材１４４の一部として概略図示）とすることができる。ジンバル機構１４０は、接地部材１４４、延長部材１４６ａおよび１４６ｂ、ならびに中心部材１４８ａおよひ１４８ｂを含む５部材リンケージである。接地部材１４４は、機構１４０に対して安定性を与える面またはベースに結合される。ジンバル機構１４０の部材は、軸受またはピボットを用いて回転自在に相互に結合されている。ここで、延長部材１４６は、回転自在に接地部材１４４に結合されていて軸線Ａのまわりを回転することができ、中心部材１４８ａは、回転自在に延長部材１４６ａに結合されていて浮動軸線Ｄのまわりを回転することができ、延長部材１４６ｂは、回転自在に接地部材１４４に結合されていて軸線Ｂのまわりを回転することができ、中心部材１４８ｂは、延長部材１４６ｂに結合されていて浮動軸線Ｅのまわりを回転することができ、中心部材１４８ａは、軸線ＤとＥとが交わる中心点Ｐで回転自在に中心部材１４８ｂに結合されている。軸線ＤとＥは、これらが軸線ＡやＢのように一つの位置に固定されないという意味で「浮動」である。軸線ＡおよびＢは、実質的に互いに直交している。
【０１０２】
ジンバル機構１４０は、５個の部材の閉じた鎖として形成されている。一つの部材の各々の端部は、他の部材の端部に結合されている。５部材リンケージは、延長部材１４６ａ、中心部材１４８ａ、およひ中心部材１４８ｂが第１の自由度において軸線Ａのまわりを回転できるように配置されている。また、このリンケージは、延長部材１４６ｂ、中心部材１４８ｂ、および中心部材１４８ａが第２の自由度において軸線Ｂのまわりを回転できるように配置されている。
【０１０３】
ユーザオブジェクト３４は、直線状軸部材１５０に結合させることができる物理的物体であり、或いは直線状軸部材１５０をオブジェクト３４の一部として考えることができる。直線状部材１５０は、軸線ＤとＥの交差点Ｐにおいて中心部材１４８ａおよび中心部材１４８ｂに結合される。直線状軸部材１５０は、軸線Ｄおよび軸線Ｅによって定められる面から延出するようにジンバル機構１４０に結合される。直線状軸部材１５０は、矢印線１５１として示したように、第１の回転自由度において延長部材１４６ａ、中心部材１４８ａ、および中心部材１４８ｂを回転させることにより軸線Ａ（とＥ）のまわりを回転することができる。部材１５０はまた、矢印線１５２により示されるように、第２の回転自由度において延長部材５０ｂおよび二つの中心部材を軸線Ｂを中心として回転させることにより、軸線Ｂ（とＤ）のまわりを回転することができる。他の実施形態では、直線状軸部材は、中心部材１４８ａおよび１４８ｂの端部に並進自在に結合され、これにより浮動軸線Ｃに沿って直線的に動かすことができ、矢印１５３により示されるような第３の自由度を与える。勿論、軸線Ｃは、部材１５０がこれらの軸線のまわりを回転するのに伴って、軸線ＡおよびＢの一方または双方のまわりを回転することができる。更に、幾つかの実施形態における直線状部材１５０は、矢印１５５により示されるように、軸線Ｃのまわりを回転して追加の自由度を与えることができる。プロセッサ２６／ホストコンピュータ１２がオブジェクト３４の位置／運動を読み取り、上記の自由度で力を印加できるようにするために、これらの追加自由度もセンサおよびアクチュエータを与えることができる。
【０１０４】
センサ２８およびアクチュエータ３０は、装置の部材間のリンク点でジンバル機構１４０に結合させることができ、上述のようにして入力および出力を与える。例えば、センサおよびアクチュエータを延長部材１４６ａおよび１４６ｂに結合させることができる。
【０１０５】
ユーザオブジェクト３４は、機構１４０に結合される。ユーザオブジェクト４４は、ジンバル機構１４０と直線状軸部材１５０により与えられる両自由度（または、３または４の全自由度）で動かすことができる。オブジェクト３４が軸線Ａのまわりを移動するのに伴って、浮動軸線がその位置を変え、オブジェクト３４が軸線Ｂのまわりを移動するのに伴って、浮動軸線Ｅがその位置を変える。
【０１０６】
図７は、ジンバル機構１４０およびインタフェース装置１４の他の構成要素を含み、機械的入力および出力をホストコンピュータシステム１２に与える装置１６０の特定の実施形態の斜視図である。装置１６０は、ジンバル機構１４０、センサ１４１およびアクチュエータ１４３を有している。ユーザオブジェクト３４は、この実施形態ではグリップ部１６２を有するジョイスティックとして示されており、中心部材１４８ａに結合されている。装置１６０は、図６を参照して説明したジンバル機構１４０とほぼ同じ方式で動作する。
【０１０７】
ジンバル機構１４０は、テーブル面や同様の面などの接地面１４２上に装置１６０を支持する。ジンバル機構１４０の部材および継手（「軸受」）は、好ましくはアルミニウムなどの軽量、剛性な金属で形成されるが、他の金属、プラステイックなどの他の剛性材料から形成されていてもよい。ジンバル機構１４０は、研磨部材１４４、キャプスタン駆動機構１６４、延長部材１４６ａおよび１４６ｂ、中心駆動部材１４８ａ、および中心リンク部材１４８ｂを有する。研磨部材１４４は、ベース部材１６６と垂直支持部材１６８を有する。ベース部材１６６は、接地面１４２に結合されている。垂直支持部材１６８は、垂直部材１６８が互いに対してほぼ９０度をなすようにベース部材１６６の外面の各々に結合される。
【０１０８】
キャプスタン駆動機構１６４は、各垂直部材１６８に結合されていることが好ましい。キャプスタン駆動機構１６４は、摩擦やバックラッシをシステムに導入することなく機械的な利点を与えるために、ジンバル機構１４０内に含まれている。
【０１０９】
延長部材１４６ａは、キャプスタンドラム１７０にしっかりと結合され、キャプスタンドラム１７０の回転に従って軸Ａのまわりを回転する。同様に、延長部材１４６ｂは、別のキャプスタンドラム１７０にしっかりと結合され、軸Ｂのまわりを回転できるようになっている。中心駆動部材１４８ａは、延長部材１４６ａに回転自在に結合され、中心リンク部材１４８ｂは、延長部材１４６ｂの端部に回転自在に結合されている。中心駆動部材１４８ａおよび中心連結部材１４８ｂは、軸線Ａと軸線Ｂの交差点Ｐである、ジンバル機構の回転の中心において相互に回転自在に結合されている。軸受１７２は、２つの中心部材１４８ａおよび１４８ｂを交差点Ｐで連結させる。
【０１１０】
ジンバル機構１４０は、回転の中心点Ｐ、またはその付近に配置されたオブジェクト３４に２自由度を与える。点Ｐに位置するオブジェクトまたは点Ｐに結合されたオブジェクトは、軸線ＡおよびＢのまわりを回転することができ、あるいはこれらの軸のまわりの回転運動の組合せを有することができる。他の実施形態では、オブジェクト３４を、他の自由度、例えば軸線Ｃに沿った線形自由度や軸線Ｃのまわりの回転自由度、で回転させたり変換することができる。
【０１１１】
装置１６０とマイクロプロセッサ２６との間に入力信号および出力信号を提供するため、センサ１４１およびアクチュエータ１４３は、ジンバル機構１４０に結合されていることが好ましい。ここで説明する実施形態では、センサ１４１とアクチュエータ１４３とが、接地トランスジューサ１７４と同じハウジング内で結合される。トランスジューサ１７４ａおよび１７４ｂは、光学エンコーダセンサ１４１およびアクティブ直流サーボモータ１４３を備えた双方向トランスジューサであることが好ましい。受動アクチュエータも使用することができる。各接地トランスジューサ１７４ａのハウジングは、垂直支持部材１６８に連結されていることが好ましい。また、このハウジングは、力を付与するか、さもなければ軸線Ａのまわりの第１回転自由度に影響を与えるアクチュエータ１４３と、オブジェクト３４の位置を測定するか、さもなければ軸線Ａのまわりの第１自由度によって影響を受けるセンサ１４１の双方を含んでいることが好ましい。アクチュエータの回転軸１７４ａは、キャプスタン駆動機構１６４の滑車に連結され、第１自由度に沿って入出力を伝達する。接地トランスジューサ１７４ｂは、機能および動作が接地トランスジューサ１７４ａと一致していることが好ましい。トランスジューサ１７４ｂは、他の垂直支持部材１６８に結合され、軸線Ｂのまわりの第２回転自由度に影響を与えるアクチュエータか、軸線Ｂのまわりの第２回転自由度より影響を受けるセンサとなる。
【０１１２】
ここで説明する実施形態のトランスジューサ１７４ａおよびトランスジューサ１７４ｂは、ユーザが取り扱うオブジェクト３４に非常に低い量の慣性を与えるのに都合が良いように配置される。トランスジューサ１７４ａおよびトランスジューサ１７４ｂは減結合され、これにより、これらのトランスジューサは両方とも、接地面１４２に結合された接地部材１４４に直接結合される。すなわち、この接地面は、ユーザが取り扱うオブジェクト３４ではなく、トランスジューサの重量を支えている。トランスジューサ１７４ａおよびトランスジューサ１７４ｂの重量と慣性は、ユーザが取り扱って動かすオブジェクト３４にとっては実質上無視することができる。これにより、より現実に近いインタフェースが仮想現実システムに提供される。これは、コンピュータがトランスジューサを制御することで、これらの動きの程度内でユーザが感じる力の実質的にすべてを与えることができるからである。装置１６０は高帯域幅力フィードバックシステムであり、これにより、トランスジューサ１７４の制御のために高周波信号を使用することができ、これらの高周波信号が、高い精度、確度、信頼性でユーザオブジェクトに与えられるようになる。高い帯域幅のために、ユーザは、オブジェクト３４を扱うときにコンプライアンスまたは「ムッシネス（mushiness）」をほとんど感じることがない。対照的に、典型的な従来の技術による多自由度インタフェース装置では、あるアクチュエータが、リンクおよびアクチュエータのシリアルチェーンにおいて別のアクチュエータの上に「乗る」。この低帯域幅装置を使用すると、ユーザは、オブジェクトを操作するときに、結合されたアクチュエータの慣性を感じることになる。
【０１１３】
オブジェクト３４は、図３では、ユーザが握るためのグリップ部分１２６を備えるジョイスティックとして示されている。ユーザは、ジョイスティックを軸線Ａおよび軸線Ｂのまわりで動かすことができる。このような二つの自由度での動きは、プロセッサ２６およびホストコンピュータシステム１２により検出される。さまざまな触覚をシミュレートするためには、これらの二つ自由度で力を加えることができるようになっていることが好ましい。前述のように、他のオブジェクト３４をジンバル機構１４０に任意選択的に結合することもできる。例えば、医療処置をシミュレーションするために、腹腔鏡ツールやカテーテルなどの医療機器を使用することができる。
【０１１４】
図８は、インタフェース装置１４と共に使用することができるオブジェクト３４および支持機構１８０の異なる実施形態の斜視図である。機構１８０は、当業者に周知のジョイスティックコントローラと共に使用するためのスロット付きヨーク構成を含んでいる。機構１８０は、スロット付きヨーク１８２ａ、スロット付きヨーク１８２ｂ、センサ１８４ａおよび１８４ｂ、軸受１８６ａおよび１８６ｂ、アクチュエータ１８８ａおよび１８８ｂ、ならびにジョイスティック３４を有している。スロット付きヨーク１８２ａは、ヨークの一方の端部がこのヨークを貫通して延びるシャフト１８９ａにしっかりと結合されるとともに、センサ１８４ａにしっかりと結合されている。スロット付きヨーク１８２ａは、ヨークの他方の端部がシャフト１８９ｃにしっかりと結合されるとともに、軸受１８６ａにしっかりと結合されている。スロット付きヨーク１８２ａは軸Ｌのまわりを回転することができ、この動きはセンサ１８４ａによって検出される。アクチュエータ１８８ａは、能動または受動アクチュエータとすることができる。他の実施形態では、軸受１８６ａは、センサ１８４ａのような別のセンサとして実現される。
【０１１５】
同様に、スロット付きヨーク１８２ｂは、一方の端部がシャフト１８９ｂおよびセンサ１８４ｂにしっかりと結合され、他方の端部がシャフト１８９ｄおよび軸受１８６ｂにしっかりと結合されている。ヨーク１８２ｂは、軸線Ｍのまわりを回転することができ、この動きはセンサ１８４ｂにより検出することができる。
【０１１６】
オブジェクト３４は、一方の端部１９２が接地面１９０に軸着されており、他方の端部１９４が、２自由度内で面１９０の上を通常４つの９０度方向（および他の実施形態では更に別の方向）に動くことができるようになっている。ジョイスティック３４は、ヨーク１８２ａおよび１８２ｂ内のスロット１９６および１９８をそれぞれ貫通して延びている。このため、ジョイスティック３４が任意の方向で動かされるのに従って、ヨーク１８２ａおよび１８２ｂはジョイスティックに追従し、軸線Ｌおよび軸線Ｍのまわりを回転する。センサ１８４ａ〜ｄはこの回転を検出するので、ジョイスティック３４の動きを追跡することができる。アクチュエータ１８８ａおよび１８８ｂを使用することにより、ユーザは、ジョイスティック３４を扱うときに力フィードバックを体験できるようになる。この他に、他の種類のオブジェクト３４をジョイスティックの代わりに使用したり、追加オブジェクトをジョイスティックに結合させることも可能である。さらに別の実施形態では、追加自由度をジョイスティック３４に与えてもよい。例えば、ジョイスティックには、矢印１９３によって示されるように、軸線Ｋのまわりでの回転自由度を与えることができる。このような追加自由度のためのセンサおよび／またはアクチュエータが含まれていてもよい。
【０１１７】
他の実施形態では、追加の力をジョイスティック３４に与えるために、アクチュエータをシャフト１８９ｃおよび１８９ｄに結合させてもよい。アクチュエータ１８８ａおよびシャフト１８９ｃに結合されたアクチュエータは、マイクロプロセッサ２６またはホストコンピュータ１２により同時に制御することができ、ベール１８２ａに力をかけたり、ベイル１８２ａから力を解放することができる。同様に、アクチュエータ１８８ｂおよびシャフト１８９ｄに結合されたアクチュエータも、同時に制御することができる。
【０１１８】
インタフェース機器やトランスジューサの他の実施形態をインタフェース装置１４内で用いて、ユーザオブジェクト３４に機械的な入力／出力を与えることもできる。例えば、１〜３（または４以上の）の線形自由度をユーザオブジェクト３４に与えるインタフェース機器を使用することができる。さらに、異なるリフレクトプロセスを実施するために、所定量の「遊び」を有する受動アクチュエータを設けることもできる。
【０１１９】
図９は、図５の実施形態で使用することができる多数の好適なホストコマンドを示す図表３００である。図５の実施形態では、ホストコンピュータ１２が、ローカルマイクロプロセッサ２６に高水準ホストコマンドを送る。このマイクロプロセッサは、ホストコマンドに従って、ローカルリフレクトプロセスまたはリフレクトプロセスを実施する。前述したように、バス２４での低い通信速度（図１）によって、性能、具体的には力フィードバックの正確さやリアリズム、が妨げられる場合がある。ローカルマイクロプロセッサは、ホストコンピュータとは関係なくホストコマンドに基づいてリフレクトプロセスを実施できるため、バス２４を介して伝達する必要のある信号が減少する。好ましくは、ホストプロセッサ１６からローカルプロセッサ２６へのホストコマンドの転送のために、通信言語、すなわち力フィードバックプロトコルを標準化する必要がある。理想的には、図５を参照して説明したように、このフォーマットが、図５のステップ１１４のように、高水準監督コマンド（ホストコマンド）のローカルプロセッサ２６への効率的な伝送を可能にする。ひとそろいの力に変換される比較的小さな一組のコマンドおよびコマンドパラメータを与えることによって、このフォーマットは、計算の負担をホストコンピュータからローカルマイクロプロセッサ２６に更に移行させる。さらに、ホストコンピュータ１２用の力フィ ードバックアプリケーションソフトウェアのプログラマや開発者には、高水準で標準的、効率的な力フィードバックコマンドプロトコルが与えられる。
【０１２０】
ある実施形態では、ホストコマンドは、アクチュエータ３０を制御するために、マイクロプロセッサ２６によって実現される多様な力モデルに対して総称的なコマンドパラメータを含むことが許されている。例えば、力の大きさおよび力の方向は、二つの総称コマンドパラメータである。力の持続期間、すなわち力モデル適用時間は、別の総称コマンドパラメータである。ボタンなどの他の入力装置３９に対してコマンドパラメータを更に定義することが有利である場合もある。ボタンは、作動状態にされると、様々な力や力モデルをトリガすることができる。
【０１２１】
好適な実施形態には、力フィードバックインタフェース装置１４用の動作の二つの主要なモードまたは「制御パラダイム」が含まれる。すなわち、レート制御および位置制御が含まれている。これらのモードは、コマンドパラメータによってパラメータ化されるホストコマンド用の分類体系を暗黙に定義している。ユーザがアプリケーションと対話している間のレート制御と位置制御との差は、一般に、ユーザにとってわずかなものであるが、力フィードバック情報を表すときには差が大きくなる可能性がある。ある種の力フィードバックエンティティは両方の制御モードで実現することができるが、力フィードバックコマンドを２つのセットに分類することがプログラマ間の混乱を回避するために役立つ場合がある。これらのコマンドの一部は、レート制御コマンドまたは位置制御コマンドのどちらかとして使用することができる。
【０１２２】
本発明に係る好適な力フィードバックコマンドを以下に説明する。レート制御力フィードバックコマンドをまず最初に説明し、その後に位置制御コマンドを説明する。もちろん、それ以外の力フィードバックコマンドも、以下のサンプル力フィードバックコマンドに加えて、または以下のサンプル力フィードバックコマンドの代わりに、構築することが可能である。
【０１２３】
レート制御とは、１以上の与えられた自由度に沿ったユーザオブジェクト３４の変位が、制御下のコンピュータシミュレートエンティティ、例えば、飛行機、レーシングカー、または他のシミュレート「プレーヤ」もしくはプレーヤ制御制御グラフィカルオブジェクト、の動きに抽象的にマップされるユーザオブジェクトマッピングを指す。オブジェクトの動きとシミュレートコンピュータエンティティの指令された動きとの間に直接的で物理的なマッピングが存在しないため、レート制御は、力フィードバックをより直感的でないものにする抽象作用である。それにもかかわらず、多くの興味深い力フィードバック感覚をレート制御パラダイム内で実現することができる。対照的に、位置制御は、ジョイスティックハンドルまたはユーザが操作可能な他のオブジェクトの変位がシミュレートコンピュータエンティティの変位を直接示すことにより、ジョイスティックの変位とコンピュータの変位との間に基本的な関係が存在するようなユーザオブジェクトマッピングを指す。このように、大部分のレート制御パラダイムは、ユーザオブジェクト（ジョイスティック）を指定された位置に安定に保持できる一方で、制御下のシミュレートエンティティは指令された所与の速度で動くのに対し、位置制御パラダイムは、ユーザオブジェクトが動いている場合に制御下のエンティティが動くことしか許さないという点で、両者は根本的に異なる。位置制御ホストコマンドは、図１４を参照して以下で詳細に説明するが、レート制御コマンドは、図９を参照して現在説明されている。
【０１２４】
例えば、一般的な形式のレート制御は、速度導出抽象化である。この抽象化では、ジョイスティックハンドルのようなユーザオブジェクトの変位が、シミュレーション環境において、シミュレートコンピュータエンティティ、例えば表示画面２０に表示される乗り物やその他のグラフィカルオブジェクト、の速度を表す。ジョイスティックハンドルの元の位置からの移動が大きいほど、操縦される乗り物またはプレーヤ制御グラフィカルオブジェクトの速度も速くなる。このようなパラダイムは、宇宙船やレーシングカーの速度がジョイスティックの変位により表されるコンピュータゲームでは極めて一般的である。大部分のレート制御パラダイムと同様に、速度制御は、ジョイスティックを指定された位置に安定して保持する一方で、制御下のエンティティが指令された所与の速度で動くことを可能にする。コンピュータゲームで使用される一般的な他のレート制御パラダイムは、加速制御である。加速制御されたパラダイムは、当業者に「スラスト」制御と呼ばれる。速度制御は制御下のエンティティの速度を指示するが、スラスト制御は速度の変化率を指示する。スラスト制御下では、ジョイスティックを静止させ、ゼロ変位で中心に配置することができるが、指令を受けるコンピュータエンティティはそれでも動くことができる。
【０１２５】
力フィードバック機構では、レート制御力フィードバックコマンドは、力フィードバックインタフェース装置１４を介してシミュレート環境により制御される乗り物または他のシミュレートエンティティに作用する力にほぼ一致する。このような力は、乗り物中心力と呼ばれる。例えば、スラスト制御パラダイムでは、ユーザのシミュレートスピードボートが濃厚な泥の中に進入する場合があるが、ユーザは直接的に泥を感じることはないだろう。しかしながら、ユーザは、スピードボートのエンジンがボートの動きに抵抗する力に逆らって最大限に稼働していることは感じるであろう。これらの対抗力は、インタフェース装置１４を介してユーザに伝えられる。シミュレート環境における他のシミュレート特性やオブジェクトは、プレーヤ制御シミュレートエンティティに影響を与えて、ユーザに出力される力に影響を及ぼす場合がある。
【０１２６】
本明細書では、レート制御コマンドは「条件（condition）」および「オーバレイ（overlay）」に分けられる。但し、他の実施形態では、他の分類が使用される場合がある。条件は、シミュレート剛性、シミュレート制動、シミュレート慣性、シミュレート力が減少するデッドバンド、および物理モデルの機能を決める方向の制約を含むユーザオブジェクトについての基本的な物理モデルまたはバックグラウンド感覚を設定する。条件力を効率良く重ね合わせるために、複数の条件を単一のコマンド中で指定することができる。対照的に、オーバレイは、バックグラウンドでの条件に加えて付与される力である。条件力に加えて任意の数のオーバレイを提供できることが好ましい。一つの条件は、一つの条件コマンドまたは複数の条件コマンドによって指定することができる。
【０１２７】
以下では、図表３００に示されるような数タイプの力３０２について説明する。これらの力は、ホストコマンドに基づいてマイクロプロセッサ２６により実現することができる。これらの力には、復元力（restoring force）、ばね復元（restoring spring）、ベクトル力（vector force）、振動（vibration)、緩慢粘着（sluggishstick）、ウォッブル（wobble）、不安定（unstable）、ボタン反射ジョルト（button reflex jolt）、およびラチェット力（ratchetforce）が含まれる。復元力、ばね復元力、緩慢粘着力、および不安定力は、条件力と考えられる。ベクトル力、振動、ウォッブル、ボタン反射ジョルト、およびラチェット力は、オーバレイ力と考えられる。
【０１２８】
図表３００に示される力３０２は、ホストコンピュータ１２によってマイクロプロセッサ２６に与えられるホストコマンドを用いて実現することができる。図表３００に示されるホストコマンドおよびその構文の例３０４が、各種の力３０２に対して示されている。ここで説明する実施形態では、ホストコマンド３０４が、コマンド部分３０６および複数のコマンドパラメータ３０８を含んでいることが好ましい。コマンド３０４は、ホストコンピュータ１２がプロセッサ２６に実現するように指示する力のタイプを示す。このコマンド部分は、プロセッサ２６がメモリ２７から検索して実施することの可能な対応反射プロセスを有していてもよい。このプロセスについては、以下に詳細に説明する。コマンド部分３０６は、他の実施形態では、事実上任意の形式で指定することができる。図表３００では、コマンドは、コマンドが実現する力のタイプをプログラマまたはソフトウェア開発者が容易に認識できるように、通常、英語に近い高水準形式で与えられる。
【０１２９】
コマンドパラメータ３０４は、ホストコンピュータ１２によって与えられ、コマンド部分３０４により示される力のタイプをカスタマイズおよび／または修正する値またはインジケータである。これらのコマンドの多くは、大きさ、持続時間、または方向コマンドパラメータを使用する。頻繁に力の方向を修正するスタイルパラメータを含むコマンドもある。以下に詳細に説明されるように、他の特殊なコマンドパラメータは、特定の力に与えられる。
【０１３０】
以下の好適なレート制御実施形態では、コマンドパラメータの大部分が同じ方法で異なる力を制御する。大きさパラメータ（magnitude parameter）は、アクチュエータ３０により出力可能な最大の力に対応する最大の大きさのパーセンテージである。持続時間パラメータ（durationparameter）は、通常、特定の力モデルを印加するための時間間隔に一致する。しかしながら、これは、力モデルの印加時間を無限に伸ばすために、０や−１のような所定値に設定されることがある。このため、力モデルは、ホストコンピュータ１２が新しいホストコマンドに新しい力を与えるか、クリアコマンドを送るまで、有効なままとなる。スタイルパラメータ（styleparameter）は、力モデルを印加する方向および／または力モデルを印加する自由度を選択することができる。例えば、有効な方向は、通常、一般的なジョイスティックの２本の軸線のうちの１本、またはこの２本の組み合わせとして指定される１本の対角線を含んでいる。言うまでもなく、スタイルパラメータは、任意の自由度または自由度の組み合わせに沿って力の印加を指定することができる。この他に、別個の力コマンドが各自由度または力コマンドに使用される場合もある。スタイルパラメータは、以下に説明されるように、指令された特定の力モデルに応じて変化することができる。
【０１３１】
図９には列挙されていないが、ここに記載される全てのタイプの力３０２は、追加のパラメータを有していたり、列挙されたパラメータに他の特性を組み込んでもよい。「デッドバンド（deadband）」パラメータは、力が小さいかあるいはゼロとなる領域のサイズを指定できる。力がある自由度に沿って双方向なのか単方向なのかを示すパラメータが含まれていてもよい。単方向の力は、正または負の向きのいずれを持つことができる。いくつかのホストコマンドでは、デッドバンドおよび双方向／単方向パラメータが、スタイルパラメータに含まれていてもよい。
【０１３２】
サブクラス３１０は、力３０２のタイプの分類を示している。力３０２は、前述のように、条件またはオーバレイのどちらかとして示される。オーバレイコマンドの前に、条件コマンドを以下で説明する。
【０１３３】
図１０（ａ）〜（ｃ）は、復元力に関して力対変位のプロファイルを示すグラフである。図１０（ａ）のグラフ３１２における力は双方向であり、この場合、垂直軸の右側の力は、ある自由度に沿ってある方向に印可され、垂直軸の左側の力は、その自由度に沿って反対方向で印加される。図１０（ｂ）のグラフ３１４に示される力は、単方向である。好ましくは、力が単方向であるか双方向であるかは、例えば図８の図表３００に示されるコマンド３０６のスタイルパラメータ３０８（および、単方向の場合、特定の方向を示すための正または負の向き）で指定される。さらに、復元力が印加される所望の自由度も、スタイルパラメータで指定されるのが好ましい。例えば、“Ｘ”パラメータは“Ｘ”自由度を示すが、“ＸＹ”パラメータは、ＸおよびＹ自由度の双方に沿った復元力（例えば、斜め復元力）を示すことができる。
【０１３４】
ユーザオブジェクト３４に印加される復元力３４は、ある自由度に沿ってユーザオブジェクトの原点位置Ｏ（つまり「中立位置」）に向かって常に後ろを向いている。例えば、図７および図８に示されるように、ジョイスティックの原点位置が、ジョイスティックの中心位置となる場合がある。大きさコマンドパラメータによって指定される復元力の大きさは、ユーザオブジェクトの自由度に沿った範囲３１６では、いずれの方向でもほぼ一定のままとなる。最大の力の大きさＦは、ジョルトや振動を復元感覚の上にオーバレイできるように（以下に説明）、選択された自由度での最大可能出力力の約７５％に制限されていることが好ましい。オブジェクトは原点位置Ｏに向かって移動するので、印可される力は、ユーザオブジェクトが原点位置のまわりの局所領域Ｒ内に移動するまでは一定である。ユーザオブジェクトが局所領域Ｒにある場合、印可される力はゼロまたは小さな値に急速に低下する。このように、復元力プロファイルは、オブジェクトが範囲３１６内にあるときにユーザオブジェクトを原点位置に押し戻す一定の「復元感覚」を与える。その後、復元力は、オブジェクトが原点位置に近づき、原点位置に到達するに従って減少または消滅する。復元力の方向は、ローカルマイクロプロセッサ２６によって自動的に制御することができる。
【０１３５】
図１０（ｃ）では、印可される力が原点位置のまわりの拡大された領域３１８内でほぼゼロである点を除いて、復元力が図１０（ａ）の力と同様に示されている。領域３１８は「デッドバンド」として知られており、力が印加される前に原点のまわりの短い距離だけオブジェクト３４を動かす自由をユーザが持つことができるようにする。印加される復元力のためのデッドバンド３１８の指定は、例えば、別個のデッドバンドコマンドパラメータとして含まれる値、あるいは復元力ホストコマンドのスタイルパラメータ３０８の一部として含まれる値とすることができる。
【０１３６】
復元力感覚は、レート制御パラダイムで、シミュレート車両をコントロールする間に壁やその他の障害物に衝突する状況に極めて好適に当てはめることができる。復元力は、動き方向の速度を指令することに対する抵抗を示している。ユーザオブジェクトが原点位置に戻されると、ユーザは動き方向の速度を指令しなくなるため、この力は低下する。逆方向に障害物がない場合には、復元力は単方向となる。
【０１３７】
図１１（ａ）〜１１（ｃ）は、ばね復元力についての力対変位のプロファイルを示すグラフである。図１０（ａ）〜１０（ｃ）の復元力によって与えられるように一定の大きさをその正または負の変位にわたって維持するのではなく、ばね復元力は、ユーザオブジェクトの変位の感知可能な部分にわたって線形に変化し、オブジェクト３４の原点位置Ｏからの距離に比例する。ユーザオブジェクトに加えられるばね復元力は、ある自由度に沿って中立位置に向かって常に後ろを向いている。図１１（ａ）〜１１（ｃ）では、ばね復元力は、オブジェクト３４の原点位置Ｏからの最大変位においてその最大値に達する。図１１（ａ）のグラフ３２０は双方向のケースを示し、図１１（ｂ）のグラフ３２２は単方向のケースを示している。デッドバンドパラメータにより指定されるデッドバンドは、図１１（ｃ）のグラフ３２４に示されるように、原点位置のまわりに与えられる。
【０１３８】
ばね復元力に関するパラメータは、例えば、前述の復元力に関するパラメータとほぼ同様であってもよい。あるいは、ばね復元力は、大きさパラメータの代わりに、オブジェクト３４の所望の「剛性」を記述するばね定数パラメータ（spring coefficient parameter）を有していてもよい。ばね定数パラメータは、ユーザオブジェクトに作用する力を計算するための周知の方程式で使用することができる。この定数パラメータか大きさパラメータのいずれかを使用することができる。
【０１３９】
緩慢力は、ユーザオブジェクト３４に対する制動力であって、ユーザによって動かされるときのユーザオブジェクトの速度に比例する大きさを有する力を生じさせる。このタイプの制動力の例は、図４のステップ８２を参照して前述した。緩慢力の「粘度」の度合いは、ホストコマンドにコマンドパラメータとして含まれる粘性減衰定数によって指定できる。緩慢粘着力は直接速度に依存するため、定数コマンドパラメータ（coefficient command parameter）は最大減衰定数のパーセンテージで表すことができ、前述のホストコマンドの大きさパラメータに代わる。緩慢ホストコマンドのスタイルコマンドパラメータは、単方向または双方向の表示だけではなく、緩慢力を加えるための指定自由度を含む場合がある。緩慢粘着力は、例えば、ユーザオブジェクトの動きに不完全に反応する非常に重い乗り物の制御をシミュレートするためのレート制御アプリケーションに特に適している。
【０１４０】
不安定力は、倒立振り子スタイルの不安定性を生じさせる。この他に、不安定力は、負のばね定数（不安定または発散性のばね）を有するばねにモデル化される。力は、オブジェクトの原点位置から離れる方向でユーザオブジェクトに印加され、ユーザオブジェクトが原点位置からさらに遠く離れていくのに従って増加する。これにより、ユーザがオブジェクトを原点位置に運ぶことを困難にする力が生じる。不安定ホストコマンドのコマンドパラメータは、前述の復元力に類似したパラメータを含んでいてもよい。例えば、最大の「不安定性」度のパーセンテージを示すコマンドパラメータを与えることができる。ここで、不安定性は、最大出力力によって定義することができる。この力は、別の乗り物関連の感覚として使用することが可能であり、例えば、シミュレート乗り物誘導制御装置が損傷を受ける場合に、ばね復元力の代わりに用いられることがある。通常、不安定性によって、コンピュータゲームは非常にプレーが難しくなる。
【０１４１】
他の実施形態では、条件力の特性を制御するための多数のパラメータとともにただ１つのホストコマンドを使用することで、前述の条件力を指令することができる。例えば、以下のようなホストコマンド
COND_-X(K+,K-,DB,B+,B-,N_-Offset,Sat+,Sat-,m)
を、ホストコンピュータ１２からマイクロプロセッサ２６に送ることができる。このコマンドは、ユーザオブジェクトのモデルの特定の物理的なパラメータを一つの自由度内で指定する。Ｋパラメータは、ある自由度に沿った二つの方向におけるユーザオブジェクトの変位の比例剛性を示す。ＤＢパラメータは、最大許容デッドバンド距離のパーセンテージでデッドバンド範囲を示す。Ｂパラメータは、ある自由度に沿った二つの方向おけるユーザオブジェクトの速度に対する速度比例制動を示す。Ｎ＿Ｏｆｆｓｅｔパラメータは、（Ｋパラメータにより定義される）ばねのモデル化中立位置からのオフセットとして指定することができる。Ｓａｔパラメータは、ユーザオブジェクトの変位に対する最大（飽和）許容力値を示しており、例えば、可能な最大力の、あるパーセンテージで表される。ｍパラメータは、例えばユーザオブジェクトの重力または慣性力を計算するための物理モデルで利用することができるユーザオブジェクトのシミュレート質量を示す。上記の条件コマンドは、ユーザオブジェクト３４の所与の自由度の各々に対して使用することができる。例えば、ＣＯＮＤ＿Ｘは、ｘ軸のまわりの自由度における条件力を提供することができる。このコマンドは、復元力、ばね復元力、緩慢力、および不安定力を、さまざまなコマンドパラメータを調整することにより実現することができる。
【０１４２】
条件コマンドは、条件力に加えて又は条件力に「かぶせて」オーバレイコマンドが適用される間に、バックグラウンドで提供することができる。例えば、緩慢な制動力をユーザオブジェクトに対するバッグラウンド力として提供し、「ジョルト」オーバレイ力を緩慢力にかぶせて指令して、数秒間にわたってユーザオブジェクトに素早く断続的な動きを与えることができる。言うまでもなく、オーバレイ力は、他の力が印加されていないときに独占的に印加することも可能であるし、望む場合には、オーバレイ力が、過去に指令された他の力を取り消すこともできる。図９に示される例のオーバレイ力については、後述する。
【０１４３】
図１２は、ベクトル力モデルを示すグラフ３２６である。ベクトル力はオーバレイコマンドであるため、前述の条件力に加えて印加することができる。これは、方向コマンドパラメータ（direction command parameter）によって指定される指定方向でジョイスティックに印加される一般的な力である。方向コマンドパラメータは、例えば、２自由度インタフェース機器のＸＹ平面内の角度として与えることができる。条件力コマンドの多くに関しては、ベクトル力の大きさは、大きさの最大値のパーセンテージで指定できる。図１２は、２自由度を持つユーザオブジェクトのＸＹ平面内の例示方向におけるベクトル力の２次元表現を示している。
【０１４４】
図１３（ａ）〜１３（ｂ）は、振動力に関する力対時間のプロファイルを示すグラフである。図１３（ａ）は、双方向の振動力を示すグラフ３２８であるが、図１３（ｂ）は単方向の振動力を示すグラフ３３０である。図９に示される振動コマンドは、大きさ、周波数（frequency）、スタイル、方向、および持続時間コマンドパラメータを受け入れる。周波数パラメータは、最大周波数のパーセンテージとして実現でき、ある期間の時間間隔Ｔｐに反比例している。方向コマンドパラメータは、図１２を参照して前述したように、角度として実現することができる。スタイルパラメータは、振動力が単方向であるのか、双方向であるのかを示すことができる。さらに、デューティーサイクルパラメータは、他の実施形態で提供することができ、振動力が印加される期間のパーセンテージを示す。また、コマンドパラメータは、振動波形の「形状」またはプロファイルを時間軸で指定するために含まれていてもよく、この場合、所定の数の形状のなかから一つを選択することができる。例えば、この力は、正弦波力、鋸歯形力、方形波形力などとして指定することかできる。
【０１４５】
ウォッブル力パラダイムは、ホストコンピュータ１２によって指令することができる別のオーバレイ力である。この力は、ランダムな（あるいは、ユーザにとってランダムに見える）オフバランス力感覚をユーザオブジェクト上に生じさせる。例えば、この力は、損傷を受けた乗り物のふらついた操縦をシミュレートできる。大きさ、持続時間、およびスタイルコマンドパラメータは、前述のホストコマンドのパラメータと同様のものとすることができる。また、スタイルパラメータが、様々なタイプを含む所定のリストからウォッブル力のタイプを指定することもできる。ウォッブル力は、さまざまな方法を用いて実現できる。例えば、事前にプログラムされメモリに格納された「力プロファイル」は、ランダムに見える力感覚を生じさせるように実現することができる。あるいは、正弦波または他の関数に基づいて、あるいはランダムな結果に基づいて力を計算するために、方程式を使用することができる。
【０１４６】
ジョルト力は、通常、ユーザオブジェクト上に出力される短く大きな力であり、例えば、ユーザにコンピュータ環境内のイベントやシミュレートオブジェクトを知らせるために使用することができる。ジョルト力は、有効なあらゆる条件力に加えて感じることができるオーバレイ力として使用することができる。典型的なパラメータは、ジョルト力の大きさ、ジョルトの持続時間、およびジョルトが加えられる方向または自由度（これは、角度または特定の自由度として指定することができる）を含んでいる。大きさコマンドパラメータは、（前述の）任意の他の条件力またはオーバレイ力の大きさに加えて、衝撃力の大きさを指定することが好ましい。つまり、この大きさは、定常状態の力を「超えた」差分大きさである。したがって、アクチュエータ３０によって出力される実際の大きさは、衝撃力の大きさより大きくなることがある。
【０１４７】
ボタン力は、実際の力ではないが、入力装置３９がユーザにより作動されるときに、他の力をトリガするためのコマンドとして使用されることがある。例えば、多くのゲーム状況では、ホストコンピュータ１２で押されたボタンを処理した後にホストコマンドから力を生成するより、インタフェース機器１４上のボタンまたは他の入力装置３９を押すことに対する直接的な反応として力をトリガする方が有利な場合がある。ボタンを押すことによりトリガされる他の力は、ボタンコマンドのコマンドパラメータとして指定できる。この他に、各種の力に対して特殊なボタンコマンドを与えることができる。
【０１４８】
例えば、ボタンコマンドと共に使用する共通の力は、ジョルト力である。指定されたボタンが押されるたびにジョルト力が生じるように、ＢＵＴＴＯＮ＿ＪＯＬＴなどの特定のコマンドを与えることができる。このコマンドには、ボタンコマンドパラメータおよびジョルトコマンドパラメータ（jolt command parameter）が含まれる。この他に、ＪＯＬＴコマンドパラメータを有するボタンコマンドを実現することもできる。ボタンジョルトコマンドがマイクロプロセッサによって受信されると、マイクロプロセッサは、ボタンバックグラウンドプロセスを終了するように指令されるまでバックグラウンドプロセスとしてボタンチェックを実行することができる。このため、マイクロプロセッサ２６が、ユーザがボタンを押したことをセンサデータから判断すると、出力される既存の力にジョルト力を重ねることができる。
【０１４９】
ボタンコマンドは、その他の入力装置３９が作動状態にされているときに力を出力するようにマイクロプロセッサ２６をセットアップする。ボタンコマンドは（ボタンが押されたときに出力される所望の力に固有の任意のコマンドパラメータに加えて）、例えば、ボタンパラメータやオートファイア頻度パラメータを含む多くのコマンドパラメータを受け入れることができる。ボタンパラメータ（button parameter）は、ユーザが作動させたことをマイクロプロセッサ２６がチェックする特定のボタンであって所望の力を与える特定のボタンを選択する。例えば、ジョイスティックが複数のボタンを備える場合があり、ソフトウェア開発者は、それらのボタンのなかのある特定のボタンが押されたときにだけ力を与えることを希望する場合がある。持続時間パラメータは、ボタンが押された後どのくらいの時間にわたってジョルトが持続するのかを決定することができる。「オートファイア」頻度パラメータ（autofirefrequency parameter）は、ユーザがボタンを押し続ける場合に力を繰り返す頻度を指定する。例えば、ユーザがある特定のボタンを押し続ける場合、マイクロプロセッサは、ユーザが最初にボタンを押してから所定の時間間隔が経過すると、自動的にジョルト力を反復することができる。オートファイアパラメータは、オプションとして、特定のボタンに対してオートファイア機能が使用されているかどうか、および反復力が印加される前の希望の時間間隔、を指定することもできる。
【０１５０】
図９の図表に示されていない他のレート制御コマンドも実現することができる。例えば、アクチュエータ３０が受動アクチュエータである場合、ラチェットコマンドおよび適切なコマンドパラメータを送ることにより、「ラチェット」力を与えることができる。このコマンドは、例えば、ユーザが操縦する乗り物を所与の自由度に引っ張る障害物をシミュレートすることができる。このため、ユーザがジョイスティックをある方向で動かすときには力が印加され、それからユーザが反対方向にジョイスティックを動かすときには力が印加されず、ジョイスティックが最初の方向で動かされるときには再度、力が印加される。これは、ラチェット力など、任意の引戻し点における障害力をシミュレートする。このようなコマンドのスタイルパラメータは、固定された障害物またはラチェットスタイルの障害物を表すことができる。
【０１５１】
以上で、レート制御コマンドおよび力モデルの説明を終わりにする。
【０１５２】
図１４は、図５の実施形態で使用できる多くの好ましい位置制御ホストコマンドを示す図表３３２である。ここで、「位置制御」とは、ジョイスティックハンドルまたは他のユーザオブジェクトの変位がコンピュータシミュレートエンティティまたはオブジェクトの変位を直接表すようなユーザオブジェクトのマッピングを指す。マッピングは、任意の縮尺率を有していたり、非線形であってもよいが、ユーザオブジェクト変位とコンピュータオブジェクトまたはコンピュータエンティティの変位との間の基本的な関係は存在しなければならない。位置制御マッピングの下では、コンピュータ制御エンティティは、ユーザオブジェクトが動いていなければ動かない。つまり、静的なユーザオブジェクトが、静的なコマンドをホストコンピュータ１２からマイクロプロセッサ２６に指示する。
【０１５３】
位置制御は、従来のコンピュータには一般的なマッピングではないが、医療処置シミュレーションまたはグラフィカルユーザインタフェースのような他のアプリケーションでは使用されることがある。位置制御は、抽象的な制御パラダイムというよりはむしろ直接的で物理的なマッピングであるため、力フィードバックインタラクションの直感的かつ効果的な比喩である。言い換えれば、ユーザオブジェクトは、コンピュータ内で制御されているエンティティと同じ物理的な操作を経験するため、位置制御を使用すると、物理的なコンピュータシミュレーションを現実的な力フィードバック感覚作用として直接的に反映させることが可能になるのである。コンピュータ環境での位置制御の例としては、ピンポンゲームでのラケットの制御や、ウィンドウデスクトップ環境でのカーソルの制御を挙げることができる。
【０１５４】
レート制御の乗り物中心の力とは対照的に、位置制御力フィードバックは、ユーザによって直接的に知覚される力にほぼ対応する。これが「ユーザ中心」の力である。例えば、表示画面２０に表示され、ユーザによって直接制御されるラケットが、シミュレートされた濃厚な泥を通って動く場合がある。力フィードバックインタフェース装置１４を介して、ユーザは、粘性溶液を通過する動きに結びついた変化する力を知覚するだろう。現実の物理的な状況に対応して、力はジョイスティック（および表示されたラケット）の動きの速度およびラケット面の向きに応じて変化する。
【０１５５】
以下では、図表３３２に示される数タイプの位置制御力３３４を説明する。これらの力は、ホストコマンドに基づいてマイクロプロセッサ２６により実現することができる。これらの力には、ベクトル（vector）、溝（groove）、ディボット（divot）、質感（texture）、障壁（barrier）、フィールド（field）、ラケット（paddle）、およびボタン反射ジョルト（buttonreflex jolt）が含まれる。これらの力に対応するホストコマンドの例３３６の多くは、レート制御パラダイムに関して説明されたように、大きさパラメータおよびスタイルパラメータを使用する。レート制御コマンドでの場合と同様に、同じ名称のコマンドパラメータは、一般的に異なるホストコマンドに対して同じプロパティを持つ。ただし、位置制御力の持続時間は通常ユーザオブジェクトの現在位置に応じて適用されるため、持続時間パラメータは、通常、レート制御コマンドの場合ほどには位置制御コマンドには使用されない。したがって、一般的には、位置制御力モデルは、ホストコンピュータ１２が新しいホスト力コマンドまたはクリアコマンドを発行するまで有効のままである。他の実施形態では、持続時間パラメータを使用してもよい。
【０１５６】
ここで説明する位置制御コマンド用の好ましいパラメータ決定は、図１４にまとめられている。以下に列挙される全ての力は、デッドバンドパラメータのような補助的なコマンドパラメータを含むことができ、あるいは図１４に列挙されるパラメータに他のプロパティを組み込むことができる。図９に示されるホストコマンドと同様に、ホストコマンド３３６は、コマンド部分３３８および多数のコマンドパラメータ３４０を含むことが好ましい。コマンド３３６は、ホストコンピュータ１２がプロセッサ２６に実現するように指示する力のタイプを示す。このコマンド部分は、プロセッサ２６がメモリ２７から検索して実施することができる対応リフレクトプロセスを含んでいてもよい。コマンド部分３３８は、他の実施形態では、事実上任意の形式で指定できる。
【０１５７】
ベクトル力とは、大きさと方向を有する一般的な力である。ベクトル力の極表示については、図１２を参照されたい。ほとんどの位置制御感覚は、ベクトル力コマンドおよび適切な命令およびプログラミング構造を使用して、プログラマ／開発者によって生成される。ホスト１２またはマイクロプロセッサ２６は、時間ではなくユーザオブジェクトの動きに基づいて力を終了または修正できるため、通常、持続時間パラメータは必要でない。
【０１５８】
図１５は、本発明の溝力に関する力対変位の関係を示すグラフ３４２である。溝力は、傾斜３４４によって示されるように、所与の自由度に沿った線形戻り止め感覚を与える。ユーザオブジェクトは、「溝」の中の粘着力を維持するための自由度に沿った復元力が存在する「溝」に捕らえられているように感じられる。この復元力溝は、ホストコマンドが受信されたときのユーザオブジェクトの現在位置に位置する中心溝位置Ｃを中心としている。この他に、中心溝位置の位置は、１以上の自由度に沿ったコマンドパラメータから指定できる。したがって、ユーザがユーザオブジェクトを溝の外に動かそうとすると、抵抗力が印加される。
【０１５９】
大きさ（剛性）パラメータは、印加される力または抵抗の量を指定する。オプションとして、ユーザオブジェクトが距離Ｓで示される所与のスナップアウト距離だけ溝から逸れると溝力が止まる溝反射プロセス内では、「スナップアウト」機能を実現することができる。このため、マイクロプロセッサ２６は、スナップ距離大きさを有する溝コマンドを受信する。マイクロプロセッサは、このスナップ距離外に移動するユーザオブジェクトを検出すると、溝力を止める。このスナップアウト機能は、力を止めるためにクリアコマンドを送るホストコンピュータ１２によっても同様に好適に実現することができる。また、ユーザオブジェクトがデッドバンドコマンドパラメータで指定される中心溝位置Ｃ近くで自由に動くことができるようにするために、デッドバンドＤＢを設定することもできる。スタイルコマンドパラメータは、１以上の自由度に沿った溝の向き（例えば、水平、垂直、斜め）を示す。例えば、水平溝および垂直溝は、ウィンドウ内のスクロールバーに力を与える場合に有用である。グラフィカルユーザインタフェースでカーソルを動かすユーザは、カーソルおよびユーザオブジェクトをスクロールバーの中心に向かって動かす溝力を感じることができる。デッドバンドは、ユーザに、スクロールバー領域内でカーソルを動かすための空間を与える。スナップアウト距離は、カーソルがスクロールバー領域の外に移動した場合にカーソル／ユーザオブジェクトを力から解放するために使用することができる。
【０１６０】
ディボットは、本質的には、２以上の自由度で復元力を与える二つ（または三つ以上）の直交溝である。これは、所与の自由度に沿って点戻り止めの感覚を与える。例えば、ディボットが２自由度で与えられる場合、ユーザオブジェクトは円形の窪みの中に捕えられたように感じられる。ユーザオブジェクトは、ユーザオブジェクトを保持するために双方の軸線に沿った復元力が存在する点に捕捉されている。溝力のスナップアウト機能は、ディボットに関しても実現することができる。さらに、溝のデッドバンド機能もディボットコマンドに提供することができる。
【０１６１】
質感力は、図４を参照して前述したように、表面の特性をシミュレートする。質感とは、例えば棒を格子上で動かすときに感じられる力をシミュレートする（振動、時間変化力とは反対の）空間変化力である。その他のタイプの質感もシミュレートすることができる。ユーザオブジェクトは、質感力を感じるように動かされなければならない。つまり、格子の各「こぶ」は、その自由度において特定の位置を持つ。質感力は、ホストコマンドおよびコマンドパラメータを用いてプログラマ／開発者によって指定される複数の特性を備えている。これらのコマンドパラメータには、大きさ、グリット、およびスタイルが含まれることが好ましい。大きさは、格子の「こぶ」ごとにユーザオブジェクトに印加される力の量を指定する。グリットとは、基本的には、格子のこぶの各々の間の間隔である。スタイルコマンドパラメータは、質感の向きを指定することができる。例えば、スタイルは、水平格子、垂直格子、または斜行格子（またはこれらの格子の重ね合わせ）を指定することができる。さらに、スタイルパラメータは、質感がある自由度に沿って双方向または単方向のどちらで感じられるのかを指定することができる。この他に、質感力の「こぶ」の位置を制御するために補助的なコマンドパラメータを与えることもできる。例えば、こぶ間の距離がある距離にわたって指数的に変化、あるいは指定された公式に従って変化するようにこぶ感の距離を指示する情報が含まれていてもよい。この他に、質感間隔はランダムに変化してもよい。他の実施形態では、コマンドパラメータは、マイクロプロセッサ２６がメモリから取り出すことができる複数の使用可能な標準質感パターンのなかの一つを指定することができる。
【０１６２】
障壁力は、指令が出されると、ユーザオブジェクト空間内の任意の場所に配置される壁または他の障害物をシミュレートする。この障壁力については、図４を参照して上述した。ホストコマンドは、障壁の硬さ（印加される力の大きさ）、自由度に沿った障壁の位置（location）、および障壁のスナップ距離（snap distance）または厚さを指定することができる。希望する場合には、水平障壁と垂直障壁を別個のホストコマンドとして提供することができる。図１６のグラフ３４６に示されるように、障壁力だけが有限の厚さを持っている。力は、ユーザオブジェクトが（Ｂ点を通り過ぎて）障壁に近づいてくるに従って、急激に大きくなる。スナップ貫通距離は、障壁がユーザによって感じられる領域のサイズを限定する。ユーザオブジェクトが障壁の中に入り込んでから、障壁の厚さを通り抜けると、障壁力は止められる。障壁力は、マイクロプロセッサがユーザオブジェクト３４に最大の力を提供する硬い障害物として、または（大きさコマンドパラメータによって指定されるように）より小さな力の大きさが印加されるこぶや比較的柔らかい障壁として動作してもよい。障壁は、取り除かれるか、新しい位置に移動されない限り、長い時間にわたって残っていてもよい。また、自由度に沿って連続して複数の障壁を設けることもできる。
【０１６３】
この他に、障壁力は、２つのコマンドパラメータ、すなわち硬さおよび位置、のみを有するホストコマンドを送ることによって与えることもできる。硬さパラメータは、抵抗力の高さまたは傾斜を指定できる。図１６のグラフ３４８に示されるように、ユーザオブジェクトは、距離軸に沿って左から右に移動できる。ユーザオブジェクトは、Ｂ点で障壁に衝突すると抵抗力を感じる。ユーザオブジェクトがＳ点（スナップ距離）に移動すると、ユーザオブジェクトに対して力が反対方向に印加される（負の大きさの力）。この力は、ユーザオブジェクトが同じ方向で移動するのに伴って減少する。これは、ユーザオブジェクトがこぶの上に移動するまで力が抵抗的であり、なおかつオブジェクトがこぶの他方の側面を降りていくに従って力が補助力になるようなこぶや丘をシミュレートする。
【０１６４】
力場（force field）タイプの力は、特定の位置を基準としてユーザオブジェクトを引き寄せ、あるいは跳ね返す。この力は、フィールドの大きさや力場の印加の基準となる特定のフィールド原点位置（originposition）などのコマンドパラメータによって定義することができる。引力場または斥力場を示すために、向き（sense）パラメータが含まれていてもよい。例えば、力場は、フィールド原点位置とユーザによって制御されるカーソルやグラフィックオブジェクトとの間の重力をシミュレートするための引力場となることがある。フィールド原点位置は重力質量または電荷と考えることができるが、引力は、特定の位置からの変位の逆２乗に依存する必要はない。例えば、力は変位の逆数に依存していてもよい。また、引力場は、ユーザオブジェクトがフィールド原点位置に移動されると、その位置にユーザオブジェクトを維持しようと努める。斥力場は、特定のフィールド原点位置からユーザオブジェクトを押し出すという点を除いて、同様に動作する。さらに、フィールド原点位置のまわりの特定の距離範囲に対する力場の効果を制限するために、追加のコマンドパラメータとして範囲を指定してもよい。
【０１６５】
図１７（ａ）〜１７（ｉ）は、「ボール」コンピュータオブジェクトまたは同様のオブジェクト３５２と相互作用する「ラケット（paddle）」コンピュータオブジェクト３５０の図である。これらのコンピュータオブジェクトは、ホストコンピュータ１６によって表示画面２０上に表示することができる。ボールとラケットとの間の力の相互作用は、後述のように、ホストコマンドを使用してソフトウェア開発者によって制御することができる。ここで説明する例では、ラケットオブジェクト３５０は、ラケットオブジェクト３５０の動きがユーザオブジェクト３４の動きに直接マッピングされるように、位置制御パラダイムによってプレーヤにより制御される。他の実施形態では、ボールオブジェクト３５２または両オブジェクトがプレーヤによって制御されていてもよい。
【０１６６】
図１７（ａ）〜１７（ｈ）は、ボールオブジェクト３５２がラケットオブジェクトと衝突するときに、ラケットオブジェクト３５０が移動するボールオブジェクト３５２とどのように相互作用するのかを示している。図１７（ａ）では、まず、ボール３５２がラケット３５０と衝突する。最初の力は、適切な方向でユーザオブジェクト３４に印加されることが好ましい。図１７（ｂ）および図１７（ｃ）では、ボール３５２が、コンプライアンスのあるラケットまたは「スリング」に入り込んでいる。ボールのシミュレート速度、ラケットのシミュレートコンプライアンス、およびシミュレート重力の強度／方向に適したユーザオブジェクト３４を介してボール３５２のシミュレート質量がユーザによって感じられることが好ましい。これらのパラメータは、適切なパラメータを有するホストコマンドを使用して設定できるようになっていることが好ましい。例えば、以下のホストコマンドを使用することができる。
PADDLE(B_-mass,B_-vel_-x,B_-vel_-y,Gravity,Sense,Compliance_-X,Compliance_-Y)
ここで、コマンドパラメータＢ＿ｍａｓｓはボールのシミュレート質量を示し、Ｂ＿ｖｅｌ＿ｘとＢ＿ｖｅｌ＿ｙはボールの速度であり、ｇｒａｖｉｔｙは重力の強さであり、ｓｅｎｓｅは重力の方向であり、Ｃｏｍｐｌｉａｎｃｅ＿ＸとＣｏｍｐｌｉａｎｃｅ＿Ｙはラケットオブジェクト３４のシミュレートコンプライアンスまたは剛性である。コンピュータ環境やオブジェクトの相互作用の他の物理的な側面を制御するために、他のパラメータが含まれていてもよい。
【０１６７】
図１７（ｄ）では、ボールは、ラケット３４の最大たわみ点に到達し、同じ方向に動くことはできなくなっている。図１７（ｅ）〜図１７（ｇ）に示されるように、ボールは、ラケットのコンプライアンスのために反対方向に押される。さらに、ユーザがユーザオブジェクト３４に力を加えて、ボールを特定の方向に向かせ、ボールの動きをさらに加速させることが好ましい。これにより、ユーザは、精密な制御度を得ることができ、希望の方向にボールを向かわせる上で重要な技能を利用することが可能になる。このように、力フィードバックラケットは、ピンポンタイプや他の同様のビデオゲームの優れた構成要素である。さらに、ラケット３５０は、オプションとして、図１７（ｈ）に示されるように反対方向にたわむこともできる。
【０１６８】
ボール３５２とラケット３５０との間で相互作用する力の概略モデルは、図１７（ｉ）に示されている。ばね定数Ｋによって示されるばね力は、ラケットの弾力性を示すために自由度ＸおよびＹの双方に与えられる。ここで、ｇは重力の方向である。さらに、ボールがラケット３５０と接触すると、ボール３５２の速度を落とすように、減衰定数Ｂによって示される制動力が与えられる。ばね力および制動力は、１自由度で印加することもできる。
【０１６９】
ラケット制御アルゴリズムとは、ボールがラケットを圧縮し、その後ラケットから離れる間の相互作用力をマイクロプロセッサ２６が計算する動的アルゴリズムである。ラケットコマンドは、ボールがラケットに接触すると、ホストコンピュータ１２により送られる。ラケットコマンドは、ホストが相互作用期間中に表示画面２０上に表示されるグラフィックスを更新できるように、ホストコンピュータにボール位置を報告する。現在の好適な実施形態では、更新は、ホストに対して約６０ｈＺで行いさえすればよい。これは、大部分のディスプレイ２０がその速度でしか表示を行えないからである。しかし、相互作用に現実に近い「感覚」を与えるためには、力は約５００Ｈｚまたはそれ以上で計算され、出力される必要がある。したがって、ローカルマイクロプロセッサは、迅速に力を計算する一方で、ときおりラケットのセンサ読取り値をより低い速度でホストに報告することができる。他のタイプのビデオゲームまたはシミュレーション相互作用も、高水準ホストコマンドで同様に指令することができる。以上で、位置制御パラダイムの説明を終わりにする。
【０１７０】
さらに、ホストコンピュータがクリアコマンドを使用できるようになっていると好適である。このコマンドは、特定の自由度を指定するパラメータを含むことができ、指定された自由度における全ての力をホストコンピュータが削除できるようにする。これにより、プログラマが力を重畳することを望まない場合には、他の力が印加される前に力を除去できるようになる。
【０１７１】
また、構成ホストコマンドが与えられていてもよい。このコマンドは、インタフェース装置１４を最初にセットアップして、特定の通信パラメータを受信し、どの入力および出力が特定のアプリケーションに使用されるのかを指定することができる。例えば、ホストコンピュータは、ローカルマイクロプロセッサ２６に命令を与えて特定の情報をホストコンピュータに報告させるとともに、情報を報告する頻度を指示することができる。例えば、ホストコンピュータ１２は、マイクロプロセッサ２６に命令を与えて、特定の自由度からの位置値、インタフェース装置１４の特定のボタンからのボタン状態を報告させるとともに、ホストコンピュータに発生するエラーをどの程度まで報告するのかを指示することができる。製造時にインタフェース装置１４に記憶された情報、例えばシリアル番号、型式番号、スタイル情報、較正パラメータおよび較正情報、センサデータの分解能、力制御の分解能、所与の自由度に沿った動きの範囲、を受信するために、ホストコンピュータ１２によってインタフェース装置１４に「リクエスト情報」コマンドを送ることもできる。この情報は、ホストコンピュータがローカルプロセッサ２６に出力するコマンドを特定のタイプのインタフェース装置１４に対して調整およびカスタマイズできるようにするために、ホストコンピュータにとって必要となる場合がある。ＵＳＢ通信インタフェースが使用される場合、ベンダ識別、装置クラス、電力管理情報など、そのインタフェースに必要なその他の情報が、リクエストコマンドに応じてホストに提供される。
【０１７２】
さらに述べると、前述の力を重ね合わせることも可能である。ホストコンピユータは、過去のホストコマンドが依然として有効な間に新規のホストコマンドを送ることができる。これにより、ユーザオブジェクトに印加される力を、異なる制御コマンドに基づいて組み合わせることができる。マイクロプロセッサ２６またはホストコンピュータは、相反する効果をもたらす一定のコマンド（例えば、復元力とばね復元力）が重ね合わされることを防ぐことができる。例えば、最新の送出済ホストコマンドは、過去のコマンドを、それらの過去のコマンドが新規コマンドと対立する場合に無視することができる。あるいは、対立するコマンドに優先順位を割り当てて、最高の優先順位を有するコマンドが他の対立するコマンドにオーバライドするようにしてもよい。
【０１７３】
前述の高水準コマンドおよびコマンドパラメータは、本発明の力を実現するための例にすぎない。例えば、別個に説明されたコマンドパラメータを、異なる部分を持つ一つのパラメータにまとめることができる。また、複数のレート制御条件力を提供する条件コマンドの例で述べたように、本明細書に示される個々のコマンドをさまざまな方法で組み合わせたり、分離したりすることができる。
【０１７４】
標準ジョイスティックのような１または２の直交自由度または球自由度を持つ一般的なインタフェース装置に加えて、他のインタフェース装置が３または４以上の自由度を備えていてもよい。第３の自由度がスティック自体に沿った軸のまわりである場合、当業者はそれを「スピン」または「ねじり」と呼ぶ。ユーザオブジェクトの各自由度は、自身に専用の高水準ホストコマンドを持つことができる。高水準ホストコマンドを各自由度に独立して関連づけることにより、考えられる多くの位置制御、レート制御およびその他の抽象マッピングの組み合わせを、インタフェース装置で実現することができる。
【０１７５】
例えば、２自由度を有する一般的なジョイスティックの場合、コンピュータゲームは、ジョイスティックが宇宙船の飛行の制御できるようにすることができる。ジョイスティックハンドルの前後の動きは、宇宙船の加速を指示するスラスト制御を実施する。ジョイスティックの左右の動きは、宇宙船の軌道の角速度を指示するスラスト制御を実施する。この特定のスラスト方向パラダイムは、現在のゲームでは特に人気があるが、多くのばらつきがある。例えば、フライトシミュレータでは、ジョイスティックの前後の動きが飛行機のピッチを制御し、左右の動きが飛行機のロールを制御する場合がある。ドライビングゲームでは、スティックの前後の動きが車の加速に対するレート制御マッピングであり、左右の動きが道路の幅方向における車の位置に対する位置制御マッピングである場合がある。
【０１７６】
また、複数の制御パラダイムを単一の自由度に混合することもできる。例えば、ジョイスティックが、ある自由度での原点からの小さな偏差に対する位置制御と同じ自由度での原点からの大きな偏差に対するレート制御とを備える場合がある。このような混合制御パラダイムを、ローカル位置／グローバルレート制御パラダイムと呼ぶことがある。
【０１７７】
図１８は、ホストコマンドおよびコマンドパラメータを処理してユーザオブジェクト３４に力を出力する本発明の機能マイクロプロセッサ２６のインプリメンテーション３８０の例を示すブロック図である。インプリメンテーション３８０は、メモリ２７に格納された命令を使用するマイクロプロセッサ２６上に設けられることが好ましい。マイクロプロセッサ上で操作を実行するプログラム命令の使用は、当業者にとっては周知であり、「コンピュータ読取り可能媒体」に記憶することができる。本明細書では、このような媒体には、一例として、ＲＡＭやＲＯＭなどのメモリ２７、磁気ディスク、磁気テープ、ＣＤＲＯＭのような光学読取り可能媒体、ＰＣＭＣＩＡカードのような半導体メモリなどが含まれている。各々のケースで、媒体は、小型ディスク、ディスケット、カセットなどの携帯物の形を取ることもあれば、ハードディスクドライブのような比較的大きい、あるいは動かすことのできない物品の形を取ることもある。種々のサブプロセス３８２、３８４、３８６、３８７、および３８８は、力フィードバックインタフェース装置１４の応答性を最適化するためにマイクロプロセッサ２６上で並列で実行することが好ましい。これらのプロセスも、本明細書では「プロセッサ」と呼ぶ。好適な実施形態では、さまざまなパラメータおよびデータが、インプリメンテーション３８０のサブプロセスによって共用される。
【０１７８】
インプリメンテーション３８０の以下の説明において、パラメータセットまたはパラメータページは、力の計算および印加の速度を高めるために記憶されていてもよい。本明細書では、パラメータセットは、パラメータページと同義であると考えられる。コマンドが受信されるとすぐにホストコマンドおよびコマンドパラメータ（および／または他のパラメータ）を読み取り、記憶し、適用するのではなく、力環境を定義するコマンドおよびパラメータの全部または一部を記憶し、メモリ２７に記憶されたパラメータページに分類することができる。この力環境は、パラメータページから迅速に読み取られる特定の力を記述することができる。適切な力環境がホストコンピュータによって必要とされる場合、マイクロプロセッサは、メモリからパラメータページを検索することができる。この後、映像表示システムにおけるページスワッピングと同様に、インプリメンテーション３８０は、現在の力環境に対してアクティブページを使用し、構築中のコマンド／パラメータセットに対して「隠し」ページを使用することができる。さらに、予め設定または定義された力環境を検索することもできる。これらの環境は、インタフェース装置１４に与えられる標準化された力環境であるか、あるいはホストコンピュータからインタフェース装置１４にロードできる環境である。好ましい実施形態では、記憶されるパラメータページは、力パラメータおよび報告パラメータを含むことになる。これらのパラメータは、ホストコマンドおよびコマンドパラメータから引き出される内部マイクロプロセッサパラメータである。これらのパラメータについては、後述する。
【０１７９】
ホスト通信・バックグラウンドプロセス３８２は、マイクロプロセッサ２６とホストコンピュータ１２との間の通信を維持する。ホスト通信・バックグラウンドプロセス３８２は、高水準ホストコマンドおよびコマンドパラメータをホスト１２から受信し、このデータをコマンドプロセス３８４に送る。プロセス３８２は、後述される報告プロセス３８７からもセンサデータを受信する。プロセス３８２は、プロセス３８７から受信した情報をホスト１２に中継する。本質的に、プロセス３８２は、マイクロプロセッサ２６とホストコンピュータ１２との間の通信「交換機」として動作する。プロセス３８２（またはプロセス３８４）は、マイクロプロセッサ２６上の入力バッファを管理する。この入力バッファは、ホストコンピュータ１２からの入コマンドおよびデータをバッファするために使用される。この入力バッファは、高い通信速度を有するＵＳＢインタフェースやその他のインタフェースを含む実施形態で特に有用である。
【０１８０】
コマンドプロセス３８４は、ホスト通信・バックグラウンドプロセス３８２を介して伝送されたホスト１２からの入力高水準ホストコマンドおよびコマンドパラメータを処理する。この入力コマンドに基づいて、コマンドプロセス３８４は、報告パラメータおよび力フィードバック制御パラメータを処理する。このようなタイプのパラメータは、マイクロプロセッサ２６の内部パラメータであり、ホストにより送られる高水準ホストコマンド内に含まれるコマンドパラメータ３０８と区別されなければならない。内部パラメータは、コマンドパラメータから引き出され、一部の例では、後述するようにコマンドパラメータと同一である場合がある。
【０１８１】
報告パラメータは、ホストコンピュータ１２に報告するデータおよび報告の速度をマイクロプロセッサ２６に対して指定する内部パラメータである。報告パラメータは、例えば、特定の自由度に関してユーザオブジェクト３４の位置または速度を報告すべきかどうかや、通信速度や、エラーを報告する方法を指定する。報告パラメータは、ホストコンピュータ１２から受信された構成コマンドから引き出され、ステータス更新プロセス３８６および報告プロセス３８７に提供される。これにより、プロセス３８７は、どの情報をホストコンピュータ１２に報告するのかを、ホスト通信・バックグラウンドプロセス３８２を介して知ることになる。
【０１８２】
力フィードバック制御パラメータ（「力パラメータ」）は、コマンドプロセス３８４によって提供または更新され、力アルゴリズム計算・アクチュエータ制御プロセス３８８によって使用される内部パラメータである。この力パラメータは、受信済ホストコマンドに含まれるコマンドパラメータ３０８から引き出される。コマンドプロセス３８４は、他のプロセス３８８および３８６が最も最近の力パラメータにアクセスできるように、コマンドパラメータを調べ、内部力パラメータを更新する。このプロセス３８４により実現される力パラメータの提供／更新のプロセスは、図１９を参照し後述する。
【０１８３】
ステータス更新プロセス３８６は、コマンドプロセス３８４から報告パラメータを受信する。受信されたパラメータに基づいて、プロセス３８６は、センサ２８およびクロック２９を読み取り、センサ読取り履歴およびタイミング履歴を記憶する。プロセス３８６は、センサ位置データ、センサデータ履歴、タイミングデータ、またはこのデータの組み合わせから導出される値、例えば速度値や加速値、を計算することもできる。本明細書では、用語「センサデータ」は、センサから直接受信されるデータ（センサ読取り値）および／またはセンサ読取り値から導出される値を指しており、センサデータの履歴も含んでいる。「タイミングデータ」または「時間データ」は、ある期間を表す特定の値を指しており、タイミングデータの履歴も含んでいる。報告プロセス３８７は、プロセス３８６により提供され記憶されたデータを定期的に読み取る（あるいは、プロセス３８６がプロセス３８７に直接データを送出してもよい）。センサデータおよびタイミングデータは、アルゴリズム計算・アクチュエータ制御プロセス３８８にも「送出」される。本明細書中の用語「送出される（送られる）」または「受信される」は、別のプロセスが最終的に受信するデータを供給する一つのプロセスを指している。プロセス間でデータを送受するための実際のインプリメンテーションは、異なる環境では変化することがある。例えば、送出プロセスが算出データをメモリに記憶し、受信プロセスが独自の速度でメモリからデータを取り出してもよい。
【０１８４】
報告プロセス３８７は、ステータス更新プロセス３８６からセンサデータを受信し、適切な時点に、あるいはホスト１２からバックグラウンドプロセス３８２を介してリクエストを受信した時点で、このデータをホストコンピュータ１２に報告する。この報告パラメータは、コマンドプロセス３８４によりプロセス３８７に送られる。さらに、一般的なステータスおよびエラー情報が、力計算プロセス３８８から報告プロセス３８７に送られる。報告プロセス３８７により実施されるプロセスは、図２１を参照してさらに詳細に説明する。他の実施形態では、報告プロセス３８７は、例えば（「ストリーム」モードで）ホストにデータを通例の速度で報告する場合には、バックグラウンドプロセス３８２とマージされるようになっていてもよい。
【０１８５】
力アルゴリズム計算・アクチュエータ制御プロセス３８８は、コマンドプロセス３８４およびステータス更新プロセス３８６からの力パラメータおよびセンサデータを使用して、ユーザオブジェクト３４に印加される力を計算する。力パラメータは、詳細に上述したように、さまざまな力モデルを特徴付けるコマンドパラメータから導出される。プロセス３８８は、有効な全ての力モデルの影響を組み合わせることにより、アクチュエータ３０に印加される合成力を計算する。
【０１８６】
図１８中のインプリメンテーション３８０内のプロセス３８２、３８４、３８６、３８７、および３８８は、マルチタスク環境を使用することなどによって、マイクロプロセッサ２６上で並列に実行されることが好ましい。これらの全てのプロセスを順次に実行するのでは、ユーザオブジェクト３４のユーザ操作に対する力フィードバック応答が極めて遅くなってしまう。
【０１８７】
図１８に示されるインプリメンテーション３８０は、マイクロプロセッサ２６のさまざまなサブプロセスを理論的な区分に分割する方法の一例に過ぎない。他の実施形態では、他のさまざまなインプリメンテーションを設けて、ここで説明したマイクロプロセッサ２６の機能の一部または全部を結合させたり、分離させることができる。
【０１８８】
図１９は、図１８のコマンドプロセス３８２を詳細に示す流れ図である。このプロセスは、３９０から開始する。最初に、ホストコンピュータは、ステップ３９１でインタフェース装置１４との通信リンクを確立する。これは、インタフェース装置が受信を待っている所定の信号または情報を送ることによって達成できる。この後、インタフェース装置は、コマンドを受信する準備が完了していることを示す応答信号を送ることができる。ＵＳＢ通信インタフェースが使用されている場合には、コマンドプロセス３８２は、ＵＳＢアドレスをホストから要求することが好ましい。このＵＳＢアドレスは、この後、プロセッサ３８２が受信して記憶する。この後データパケットがいつホストから送られても、コマンドプロセッサ３８４は、データパケットのアドレスをチェックし、そのアドレスを記憶されたアドレスと比較して、そのパケットがマイクロプロセッサ２６用であるかどうかを判断することができる。
【０１８９】
さらに、ＵＳＢが実装されている場合、コマンドプロセッサ３８４は、ＵＳＢ通信プロトコル内でデータをチェックすることができ、報告プロセッサ３８７は、このプロトコル内でデータを送出することができる。このプロトコルは、当業者にとっては周知であるように、トークンパケットを含んでいる。トークンパケットの後にはデータパケットが続き、データパケットの後にはハンドシェークパケットが続く。ホストコマンドは、データパケット内で暗号化することができる。
【０１９０】
次のステップ３９２では、特定のインタフェース装置に適した適切な力フィードバックコマンドがホストコンピュータによって与えられるように、ホストコンピュータ１２が、インタフェース装置１４の特徴を必要とする場合がある。これらの特徴としては、例えば、シリアル番号、型式番号、スタイル、ユーザオブジェクトの所与の自由度の数、較正パラメータ、およびインタフェース装置の報告速度を挙げることができる。ホストコンピュータ１２からのこのような情報を求めるリクエスト、例えば「リクエスト情報」コマンド、を受信すると、マイクロプロセッサ２６は、ステップ３９２でホストコンピュータ１２に情報を送る。ホストコンピュータは、通常、電源投入時または力フィードバックの実施開始時にしか、これらの特徴を要求しない。
【０１９１】
次のステップ３９４では、マイクロプロセッサ２６は、ホストコンピュータ１２から構成コマンドを受信し、適切な報告パラメータを設定する。前述のように、この報告パラメータは、センサ読取り値、センサ読取り値から計算された値、および／またはセンサ「履歴」（つまり、以前に記録または計算された多数のセンサ値）を含むセンサデータやクロック時間値のような情報が、ステータス更新プロセス３８６からホストコンピュータ１２に送られるかどうかを判断することができる。このセンサデータには、センサエラーデータ、どのボタンがインタフェース装置上で押されたのかを記述するデータの履歴、ユーザオブジェクトの位置、速度、および／または加速度、どの自由度からのデータがホストコンピュータに報告されるのか、データは照会モードまたはストリームモードのどちらでホストコンピュータに報告されるのか、が含まれていてもよい。このような構成の選択肢により、プログラマは、ホストコンピュータがローカルマイクロプロセッサからどのデータを受信するのかを設定できるようになる。例えば、アプリケーションが、二つの所与の自由度のうちの一つだけでユーザオブジェクト位置データを必要とする場合には、マイクロプロセッサが未使用の自由度の情報をホストコンピュータに送るのは処理時間の無駄である。プログラマはホストコンピュータに必要なデータだけを送るように、構成コマンドを用いて報告パラメータを設定することができる。
【０１９２】
次のステップ３９６では、プロセスは、ホストコマンドが受信されたかどうかをチェックする。受信されていない場合、ステップ３９６は、ホストコマンドが受信されるまで連続的にループする。この後、ステップ３９８が実施される。このステップでは、受信されたコマンドが構成コマンドであるかどうかをプロセスが判断する。構成コマンドは、前述のように、報告パラメータを設定する。コマンドが構成コマンドである場合は、ステップ４００で、適切な報告パラメータが設定し、および／または報告パラメータをリセットして、インタフェース装置の動作中に新しい構成を与える。受信コマンドが構成コマンドではないとステップ３９８で判断された場合は、ステップ３９８は、インタフェース装置１４の力フィードバック機能を制御する力コマンドを検出する。力コマンドには、上記のホストコマンド（例えば、図９や図１４に示されるホストコマンド）が含まれる。これらのホストコマンドは、内部力パラメータに影響を与えるコマンドパラメータを提供する。
【０１９３】
ステップ４０２では、力コマンドおよびコマンドパラメータが、力パラメータ、例えば力コマンドにより指定される特定の力パラダイムまたはモデルの実現に関連する力パラメータ、を設定する。プロセス３８８は、メモリ内のこのような力パラメータにアクセスし、図２２を参照して説明するようにアクチュエータ３０を用いて力を印加する。一例を挙げると、力コマンドおよび力パラメータは、インタフェース装置１４上の特定のボタンを指定し、ジョルト力モデルを指定されたボタンの各々に割り当てる。この後、ユーザが指定されたボタンを押すと、押されたボタンに割り当てられたジョルトが、現在メモリ内にあるあらゆる力パラメータを用いて起動される。力パラメータの例は、図２３を参照して後述する。力パラメータを設定した後、ステップ４０２では、別のホストコマンドの受信を待つために、制御がステップ３９６に戻る。
【０１９４】
さらに、好ましい実施形態では、プロセス３８４は、ホストコンピュータ１２からの「心拍」信号を所定の時間間隔の後に定期的にチェック／受信している。この信号は、ホストコンピュータが依然としてインタフェース装置１４に接続されていること、およびホストが「ＯＫ」ステータスであること、を示すための安全性チェックとなる。心拍信号が時間間隔内に受信されない場合、インタフェース装置１４は停止状態になって、ホストからの初期化コマンドを待機することができる。この「心拍」信号は、通常信号またはホストコマンドであってもよいし、他の信号が時間間隔内に送られない場合にホストコンピュータが送ることができる心拍信号として特に使用される信号であってもよい。信号がステップ３９６で受信された後、信号が特定の記憶場所で受信された時間をプロセス３８４が記憶するようになっていると好適である。プロセス３８８は、この時間を調べることで、時間間隔を超えたかどうかを判断することができる（これについては、後述する）。
【０１９５】
図２０は、図１８のステータス更新プロセス３８６を説明する流れ図である。このプロセスは、ステップ４１０から開始する。ステップ４１２では、プロセス３８６は、コマンドプロセス３８４によって設定された報告パラメータおよび力パラメータを調べる。プロセス３８６は、コマンドプロセス３８４によって更新されたメモリ１７内の報告パラメータおよび状態パラメータを調べる。報告パラメータと力パラメータの両方から、ステップ４１４は、どのセンサが読み取られるのかを決定する。力パラメータは、力を計算するためにプロセス３８８に必要なのはどのセンサデータであるかを判断する。例えば、力パラメータが、ｙ軸のまわりではなくｘ軸のまわりで力を計算する必要があると判断する場合は、ｙ軸センサからのセンサデータは力の計算には必要ない。報告パラメータは、どのセンサデータをホストコンピュータに報告するのかを決定した。したがって、報告パラメータは、ｙ軸センサデータをホストコンピュータに送る必要がないことも指定することができる。これは、ホストコンピュータがその特定データを無視しているからである。このように、ｙ軸データは力を計算するために使用されず、ホスト１２によっても必要とされないため、マイクロプロセッサ２６は、ステップ４１４で、ｙ軸センサを読み取らないことを決定する。
【０１９６】
ステップ４１６は、速度および／または加速度を常に計算するのかどうかを決定する。このステップの結果は、実現される実施形態に依存する。一部の実施形態では、速度／加速度データが力を計算するために必要なのかどうかや、速度／加速度データをホスト１２に送る必要があるかどうかにかかわらず速度データおよび／または加速度データを常に計算するようになっていると、ステップがより単純になり、あまり処理時間を必要としなくなる場合がある。他の実施形態では、速度データ／加速データは、このようなデータが力値の計算に必要な場合や、ホスト１２がこれらの値を必要とする場合にだけ計算してもよい。さらに別の実施形態では、特定のアプリケーションや他の判断要素に応じて、モード（「常に計算」または「必要なときだけ計算」）を設定してもよい。
【０１９７】
速度および加速度を常に計算する実施形態では、ステップ４１８が実施される。このステップでは、センサ読取り値およびタイミングデータを用いて速度値および／または加速度値が計算される。例えば、記録された位置値および関連する時間間隔の履歴を用いて速度を計算することができる。次に、プロセスはステップ４２２に続く。このような実施形態を用いない場合は、ステップ４２０が、速度値および／または加速度値を適切な場合に計算する。プロセス３８６は、ステップ４１４と同様に、力パラメータおよび報告パラメータを調べて、速度値および／または加速度値を計算する必要があるかどうかを判断することができる。
【０１９８】
ステップ４１８または４２０の後、ステップ４２２が実行される。このステップでは、センサ２８、クロック２９から読み出され、ステップ４１８または４２０で計算されたセンサデータおよびタイミングデータを、プロセス３８６がメモリ２７内に格納する。このセンサデータおよびタイミングデータは、他の入力装置３９に関するデータを含んでいてもよい。このようなデータとしては、例えば、ボタンが押されたかどうかに関するもの（センサデータの場合）や、ボタン反復またはボタン保持（「オートファイア」）機能が適切なときに作動できるように、インタフェース装置１４上のボタンがどのくらいの時間押されていたのかに関するもの（タイミングデータの場合）を挙げることができる。上記のように、複数のプロセスが並列に実行（マルチタスキンダ）されているため、プロセス３８６は、マイクロプロセッサ２６の処理時間を共用していることが好ましい。この場合、プロセス３８６は、マイクロプロセッサ２６が利用可能になるまでステップ４２４で待機するか、あるいは故意に別の待機プロセスがマイクロプロセッサ２６を使用できるようにしなければならないことがある。さらに、この待機ステップは、一致した時刻またはより遅い時刻に出力データをメモリ２７に書き込んで、力計算プロセス３８８にメモリから出力データを読み取る上でより大きな柔軟性を与えるようにしなければならない場合がある。
【０１９９】
図２１は、データをホストコンピュータに報告する図１８の報告プロセス３８７を説明する流れ図である。このプロセスは、ステップ４３０から始まる。ステップ４３２は、報告を照会モードで行うのか、あるいはストリームモードで行うのかを、コマンドプロセス３８４によって設定された報告パラメータによって指定されるように決定する。この説明では、照会モードは、ホストコンピュータからの情報を求めるリクエストに基づいた非同期報告方法を使用し、ストリームモードは、所定の時間間隔に基づいた同期報告方法を使用する。
【０２００】
照会報告モードでは、ステップ４３４が、報告を求めるリクエストがホストコンピュータ１２から受信されたかどうかを判断する。リクエストは、報告プロセス３８７が直接受信してもよいし、あるいは、リクエストをコマンドプロセス３８４を介して報告プロセス３８７に中継してもよい。リクエストが受信されると、ステップ４３６は、図２０のステップ４２２で記憶されるセンサデータおよびタイミングデータ、ならびにプロセス３８８からのエラー情報および力値をホストに報告（すなわち送出）する。送出されるデータは、構成コマンドにより指定される報告パラメータおよびホストから受信されるリクエストに依存する。例えば、ホスト１２が特定の情報を要求することができる実施形態もある。その場合、プロセスは、ステップ４３２に戻り、照会モードまたはストリームモードが使用されているかどうかを判断する。このように、ここで説明する実施形態では、データ転送中の任意の時点でモードを切り替えることができる。他の実施形態では、一つの特定の報告モードが唯一の利用可能な選択枝である場合もある。この他に、両方のモードを使用することもできるが、インタフェース装置１４の動作の開始時に一つモードが一度選択されてしまうと、そのモードを切り替えることはできない。
【０２０１】
ストリーム報告モードでは、ステップ４３８は、報告期間が満了したかどうかを判断する。標準報告期間は、インタフェース装置およびホストコンピュータ１２が最初にセットアップされるときに設定されるのが好ましい。期間が満了すると、ステップ４４０は、報告パラメータに従って、図２０のステップ４２２で記憶されたデータを報告する。期間が満了していない場合は、プロセスはステップ４３２に戻って、再び報告モードを決定する。
【０２０２】
図２２は、図１８の力アルゴリズム計算・アクチュエータ制御プロセス３８８を説明する流れ図である。このプロセスは、ステップ４５０から始まる。各自由度における全ての力は、ステップ４５０の前の電源投入時、またはホストコンピュータ１２からのクリアコマンドの受信時にゼロに初期化される。この後、プロセス３８８は、ステップ４５０で開始し、ステップ４５２に進む。ステップ４５２では、力を印加しなければならない軸、すなわち自由度が選択される。本明細書では、「軸」は、インタフェース装置１４によって与えられる自由度と同義である。２本の軸が印可される力を必要としている場合、ステップ４５２では、現在の反復で力が印加されなかった軸が選択されることが好ましい。例えば、力がｘ軸およびｙ軸のまわりで必要とされる場合であって、ループの前回の反復ではｘ軸の力が計算されて印加された場合は、ｙ軸が選択されることが好ましい。さらに、選択された軸における合計力は、ステップ４５２でゼロに初期化される。
【０２０３】
ステップ４５６は、力パラメータに従って選択された次の反射プロセスに応じて選択された軸における力を計算する。このステップには、適切な反射プロセスの選択、必要なセンサデータ、タイミングデータ、および他のデータの検索、ならびに選択された反射プロセスおよび検索されたデータを使用した力値の計算が含まれていることが好ましい。反射プロセスは、力パラメータを調べることによって選択される。力パラメータの現在の値は、現在有効なホストコマンドを反映する。複数のホストコマンド（反射プロセス）が同時に有効となる場合があるので、力を計算するために実行すべき反射プロセスの一つを決定するために、プロセス３８８によって力パラメータが調べられる。このように、プロセス３８８は、力パラメータを調べることにより、ホストコンピュータによってどのコマンドが送られたのかを判定し、どの反射プロセスをそれらのコマンドに従って実行すべきかを決定することができる。図５を参照して前述したように、反射プロセスには、プロセスステップや、方程式や、力プロファイルや、センサデータ、タイミングデータ、コマンドパラメータ、入力装置３９からの他の入力データ、および／または他の関連情報から力を計算する命令のその他の組み合わせ、が含まれていてもよい。コマンドパラメータは、力パラメータ値に反映されている。したがって、プロセス３８８は、必要なセンサデータ、タイミングデータ、力パラメータ、および／または力値を計算するために選択された反射プロセスによって必要とされる他のデータを検索する。
【０２０４】
ステップ４５８では、プロセス３８８は、ステップ４５６で計算された力値をステップ４５２で初期化された軸に対する合計力に加算する。他の実施形態では、プロセス３８８が、合計力値またはステップ４５８で計算される合計力の一部を制限することがある。例えば、プロセス３８８が、どの力値が条件力であり、どの力値がオーバレイ力であるかの軌跡を維持している場合、プロセス３８８は、条件力の総合計を、最大アクチュエータ力出力の所定のパーセンテージ、例えば最大出力の７０％、に制限することができる。これにより、使用可能な力範囲の一部を、条件力の上に加えられることがあるオーバレイ力、例えばボタンジョルトや振動、に使用できるようになる。オーバレイ力を全ての条件力の合計の上に加えることができるように、この制限は、有効な全ての条件力が計算された後に実行されることが好ましい。他の実施形態では、他の力を制限してもよい。
【０２０５】
次のステップ４６０では、プロセス３８８が、現在選択されている軸に関して別の反射プロセスを実行する必要があるかどうかを判断する。別の反射プロセスを実行する必要があるのは、力がまだ計算されず合計力に加算されていない追加ホストコマンドが有効な場合である。この場合、プロセスはステップ４５６に戻り、力パラメータをチェックし、別の反射プロセスを実行して力を計算し、その力を合計力に加算する。ステップ４６０で、選択された軸に関してそれ以上実行しなければならない反射プロセスがない場合は、合計力は、選択された軸上で有効な全ての力を表す。この後、選択された軸に関する合計力は、ステップ４６２でメモリ２７に格納される。
【０２０６】
ステップ４６４では、プロセス３８８が、別の軸（自由度）について合計力値を計算する必要があるかどうかを判断する。必要な場合は、他の軸に関して合計力が計算および記憶されるまで、ステップ４５２、４５６、４５８、４６０および４６２が他の軸に関して繰り返される。
【０２０７】
ステップ４６４が、力を計算する必要のある軸（自由度）がないと判断すると、ステップ４６６は、各軸の合計力を制限することができる。上記で計算された軸の合計力は、インタフェース装置のハードウェア仕様、例えばアクチュエータ力出力、を上回ることがあるため、ステップ４６６は、合計力をハードウェアの設計範囲内になるように設定する。ステップ４６６は、前記で計算された合計力が、エラーフラグによって示されるように、ユーザにとって安全でない可能性がある場合に、その合計力を修正することもできる。例えば、好ましい実施形態では、以下のステップ４６８〜４７２で説明されるように、安全条件が違反されるとエラーフラグがセットされるようになっていてもよい。これにより、出力値はゼロになる。好ましい実施形態では、プロセス３８８は、このような安全条件の後に、滑らかに増大する力をユーザオブジェクト３４に加える。これは、安全条件の前のレベルで力出力に突然ジャンプすると、ユーザにとって危険な場合があるためである。ステップ４６６では、プロセス３８８は、エラータイミング情報を調べることにより、どのくらい前にエラーフラグがセットされたのかチェックすることができ、増大する力の滑らかなランプ関数に従って合計力を求めることができる。
【０２０８】
次のステップ４６８は、ステップ４６６の結果として生じる各軸での合計力に安全条件を適用する。安全条件は、例えば、図１に示されるような安全スイッチ４１が作動するときや、ホストコンピュータ１２によって特定のコマンドが送られたときに違反されることがある。安全条件が違反されると、アクチュエータ３０に加わる力は、ステップ４７０でゼロに送られる。この後、ステップ４７２で違反を示すエラーフラグがセットされ、エラーが発生した時点に関するタイミング情報が書き込まれる。この後、プロセス３８８は、図２０のステップ４２４と同様に、マイクロプロセッサ２６が再び処理を行うための準備が完了するまで、ステップ４７４で待機する。
【０２０９】
さらなる安全機能として、プロセス３８８は、メモリ２７を調べ、ホストの「心拍」信号が要求された時間間隔内で受信されたかどうかを判断することが好ましい。最後の信号が許容される時間間隔の外で受信されたとプロセス３８８が判断した場合、プロセス３８８は、ホストが切断されたかエラーを起こしたと想定する。したがって、適切な初期化コマンドがホストから受信されるまで、アクチュエータ３０への全ての電力は、安全対策として遮断される。
【０２１０】
安全条件がステップ４６８で違反されない場合、各軸に関する合計力が適切なアクチュエータ３０に信号で知らされ、対応する力がユーザオブジェクト３４のそれらの軸に印可される。さらに、プロセス３８８は、あらゆるエラー情報および力値を報告プロセス３８７に送ることができる（エラー情報は、安全条件に関係なくプロセス３８７に送られる）。この報告プロセスは、上述のように、ホストにこれらのデータを送るかどうかを判断する。プロセス３８８は、この情報をメモリに書き込むことが好ましい。報告プロセス３８７は、このメモリからその情報を取り出すことができる。その後、プロセス３８８は、マイクロプロセッサ２６が準備完了になるまでステップ４７４で待機する。ステップ４７４の後、プロセスはステップ４５２に戻り、力の計算および印加の新しい反復のなかで別の軸を選択する。
【０２１１】
次に、インプリメンテーション３８０の応用例を図２３を参照して説明する。この例では、ＳＬＵＧＧＩＳＨホストコマンドを送るホストコンピュータ１２によって、緩慢力（sluggish force）がユーザオブジェクト３４に加えられる。この後、ＳＰＲＩＮＧホストコマンドを使用するばね復元力が指令される。緩慢力モデルおよびばね復元力モデルの双方は、レート制御パラダイムのところで前述しており、図９にも列挙されている。
【０２１２】
図２３の力パラメータ４８０および４８２は、ＳＬＵＧＧＩＳＨコマンドおよびＳＰＲＩＮＧコマンドの力パラメータを記憶するために使用されたメモリ２７中の記憶場所を表す。マイクロプロセッサ２６により実現される各コマンドについての力パラメータを記憶するために一組の記憶場所が同じように割り当てられることが好ましい。ホストコンピュータ１２により送られる各ホストコマンド４８４から生じる力パラメータが示されている。緩慢力パラメータの記憶場所は、正負のＸおよびＹ方向の速度成分に対する減衰定数（Ｂ）によりラベル付けされている。同様に、ばねテーブルの記憶場所は、正負のＸおよびＹ軸のばね定数（Ｋ）およびＸおよびＹ軸のデッドバンドサイズによりラベル付けされている。
【０２１３】
３個のホストコマンド４８４が、図２３に順次に示されている。すなわち、
SLUGGISH(50,X bi)
SLUGGISH(90,X(+)uni)
SPRING(65,X bi,85)
である。
【０２１４】
２個のＳＬＵＧＧＩＳＨコマンドパラメータ３０８は、減衰定数およびスタイルである。この定数は、最大減衰定数のパーセンテージであり、５０％および９０％となっている。第１のＳＬＵＧＧＩＳＨコマンドのスタイルコマンドパラメータは、Ｘ軸上の双方向（bi-directional）の力を示す。第２のＳＬＵＧＧＩＳＨコマンドのスタイルパラメータは、Ｘ軸の正の方向におけるＸ軸上の単方向（uni-directional）の力を示す。
【０２１５】
３個のＳＰＲＴＮＧ力フィードバックパラメータは、ばね定数、スタイル、およびデッドバンドである。ばね定数パラメータは、最大ばね定数の６５％を示している。スタイルパラメータは、力がＸ軸上で双方向であることを示す。デッドバンドは、最大デッドバンドサイズの８５％である。
【０２１６】
図９に示されるように、コマンドが有効である時間の長さを設定するために、持続時間コマンドパラメータがホストコマンド４８４の各々に含まれていてもよい。ただし、この例では、コマンドが無限の持続時間を有するものと仮定されているため、持続時間コマンドパラメータは示されていない。コマンドは、例えば、ホストからのクリアコマンドにより取り消すことができる。この他に、図示のように、コマンドは、同じタイプの別のコマンドによって取消または変更することができる。
【０２１７】
要求されたインタフェース装置情報が図１９のステップ３９２でホスト１２に送られると、ホスト通信・バックグラウンドプロセス３８２が、ステップ３９４またはステップ３９８のどちらかで構成コマンドを受信する。これらの構成コマンドにより適切な報告パラメータが設定される。これらの報告パラメータは、例えば、各許容自由度、他の入力装置３９、位置／速度、照会／ストリームモードなどに応じたフラグとして、上記の装置からホストにデータを報告（および、適切な場合にはモードを選択）するかどうかを示すように実現されていてもよい。最大の効率を得るため、報告パラメータは、Ｘ軸に関してしかフラグがセットされない。これは、Ｙ軸データが必要ないためである。ただし、Ｙ軸センサデータは、他の理由でホストコンピュータによって必要とされることがあるため、Ｙ軸センサデータは、依然としてフラグがセットされて、ホストに報告される場合がある。
【０２１８】
この後、力パラメータ４８０および４８２は、図２３に示されるように、ＳＬＵＧＧＩＳＨおよびＳＰＲＩＮＧホストコマンドならびにこれらが含むコマンドパラメータに基づいて、図１９のステップ４０２で設定される。コマンドＳＬＵＧＧＩＳＨ（５０，Ｘｂｉ）によりステップ４０２は、ｘ軸定数Ｂ_x（＋）およびＢ_x（−）に対応する力パラメータ記憶場所４８６に「５０」を書き込む。最初の緩慢コマンドが電源投入後インタフェース装置１４によって受信される最初のコマンドであると想定されるため、他の全ての力パラメータの残りの記憶場所は全てゼロである。
【０２１９】
他のプロセス３８６および３８８は、力パラメータ４８０および４８２（ならびに、他の反射プロセスに対する他の力パラメータ）を調べ、図２０および図２２に示されるように実施される。このように、状態更新プロセス３８６は、図２０のステップ４１４でどのセンサが読み取られるのかを判断すると、力パラメータ４８０および４８２を調べ、どのコマンドが有効であるのかを判断する。ばね復元力の復元力パラメータ４８２のすべてがゼロであるため、ばね復元コマンドは有効ではない（プロセス３８６および３８８は、力パラメータのサブセットを見てコマンドが有効であるかどうかを判断することしか実際には必要でない）。しかしながら、力パラメータ４８０は、二つの値（“５０”）を含むため有効である。したがって、ｘ軸センサしか読み取る必要がない（ここでは、報告パラメータによって示されるように、ホストはｙ軸情報を必要としていないと想定している）。ステップ４２０（実施されている場合）では、プロセス３８６が、センサ読取り値（および／またはセンサ読取り値の履歴）およびタイミングデータを計算する。これは、緩慢コマンドが、力を計算するために速度値を必要とするからである（この例では、加速度は関係ない）。
【０２２０】
プロセス３８８は、図２２のステップ４５６で力パラメータ４８０および４８２をチェックする。Ｘ軸は、ステップ４５２で選択する唯一の関連軸である。力パラメータ４８２はすべてゼロであるため、プロセス３８８は、ばね復元反射プロセスを実行しないことを知っている。力パラメータ４８０が非ゼロ値を含んでいるため、緩慢反射プロセスは、実行される必要がある。ある例では、反射プロセスは、等式Ｆ＝ＢＶを含んでいる。ここで、Ｂは、記憶場所４８６ａおよび４８６ｂに記憶された定数であり、Ｖは、状態更新プロセス３８６により計算される速度である。Ｆは、軸を中心としてアクチュエータ３０により出力される合計力である。全ての使用可能なホストコマンドが力パラメータを有していることが好ましい。プロセス３８６および３８８は、この力パラメータを同じようにチェックして、どのコマンドが有効であるかを判断する。
【０２２１】
図２３に戻ると、第２コマンドＳＬＵＧＧＩＳＨ（９０，Ｘ＋ ＵＮＩ）は、第１の緩慢コマンドの後にホストコンピュータ１２によって送られる。この第２ＳＬＵＧＧＩＳＨコマンドは正のｘ軸において単方向であるため、Ｂ_x（＋）力パラメータ用の第１記憶場所４８６ａだけが、以前の値に上書きされた新しい定数「９０」を有する。ばね復元力パラメータは、ＳＬＵＧＧＩＳＨコマンドによって変更されない。第１ＳＬＵＧＧＩＳＨコマンドを取り消す一つの方法は、全てのコマンドパラメータをゼロにする第２ＳＬＵＧＧＩＳＨコマンドを送ることである。
【０２２２】
ステータス更新プロセス３８６は、第１ＳＬＵＧＧＩＳＨコマンドに対する場合と同様に、第２ＳＬＵＧＧＩＳＨコマンドに対しても動作する。力アルゴリズム計算・アクチュエータ制御プロセス３８８も、図２２のステップ４５６で選択された緩慢反射プロセスが（５０という定数に基づいた）負のｘ方向ではなく（９０という定数に基づいた）正のｘ方向における速度に関して異なる緩慢力を計算するという点を除いて、同様に動作する。プロセス３８８は、ステータス更新プロセス３８６からのセンサ情報を使用して、ユーザがどの方向にユーザオブジェクトを動かしているのかを判断し、適切な定数を使用する。
【０２２３】
図２３に戻ると、ホスト１２によって送られる第３のコマンドは、ＳＰＲＩＮＧコマンドＳＰＲＩＮＧ（６５，ＸＢＩ，８５）である。このため、図１９のステップ４０２は、Ｋ_x（＋）およびＫ_x（−）に６５を書き込み、ＤＢ_xに８５を書き込むことによって、ばね復元力パラメータ４８２を変更する。ＳＬＵＧＧＩＳＨ力パラメータはＳＰＲＩＮＧコマンドによる影響を受けないため、ＳＬＵＧＧＩＳＨ力パラメータは、以前の値とともに有効のままでいる。プロセス３８８は、緩慢反射プロセスを実行し、力を計算してから、ばね復元反射プロセスを実行し、力を計算する。ばね復元反射プロセスは、例えば、等式Ｆ＝ｋｘにより実施することができる。ここで、ｋは、ばね定数であり、ｘは、原点位置を基準とするユーザオブジェクトの位置である。緩慢反射プロセスおよびばね反射プロセスからの二つの力は、ステップ４５８で加算されて一つになる。したがって、緩慢力モデルおよび復元力モデルは、図２３のＳＰＲＩＮＧコマンドの後に、ユーザオブジェクト３４上で重ね合わされる。これにより、ユーザオブジェクト３４上に粘性の感覚が生じ、同時にユーザオブジェクトの原点位置に向かって力が印加される。
【０２２４】
より一般的に述べると、図２３に示されない他のコマンドシーケンスのために、任意の数の力モデルを重ね合わせることが可能である。例えば、第１のＳＬＵＧＧＩＳＨコマンドのすぐ後にＳＰＲＩＮＧコマンドが続く場合、二つの力を重ね合わせることができる。
【０２２５】
この他に、図２３に示される三つのコマンドが、マイクロプロセッサ２６によって受信され、ＳＰＲＩＮＧコマンドの後に示される全ての力パラメータがメモリ内のパラメータページとして記憶され、「力環境」を形成してもよい。この力環境がユーザオブジェクト３４に適用されることが望まれる場合、力パラメータおよび報告パラメータのページがプロセス３８６および３８８によって検索され、処理される。これは、多数の異なるコマンドを同時に適用することが望まれるときに有効な場合がある。マイクロプロセッサは、各ホストコマンドが受信されたときにそのコマンドを適用することはないが、力環境に関する全ての所望の力パラメータを一度にメモリからロードする。
【０２２６】
以上、幾つかの好適な実施形態の観点から本発明を説明してきたが、その変更、変形および置換は、明細書を読み、図面を参照すれば当業者にとって明らかとなる。例えば、多くの種類のアクチュエータおよびセンサを本発明に使用することができる。また、オブジェクト３４に１以上の自由度を与えるために、多くの種類の機構を含めることができる。さらに、ローカルマイクロプロセッサにホストコンピュータを接続するために、種々のインタフェースを使用することができる。本発明によって、さまざまなタイプの力をユーザオブジェクトに伝達することができる。マイクロコンピュータ上で実行される多くの個々のプロセスで多様なタイプの力モデルを実現することができるが、本明細書には、そのなかの一部のみを記載した。さらに、ローカルマイクロプロセッサ上における反射プロセスの適用は、さまざまな方法で実現することができる。さらにまた、記載を明確にするために特定の専門用語を使用したが、これらの用語は本発明を限定するものではない。したがって、請求の範囲は、本発明の真の趣旨および範囲内に含まれる全ての変更、変形および置換を含むように意図されている。

【特許請求の範囲】
【請求項１】
グラフィック環境を実行するホストコンピュータと通信する触覚フィードバックコンピュータ周辺機器であって、
前記触覚フィードバックコンピュータ周辺機器上のユーザ操作可能オブジェクトであって、少なくとも１つの自由度で前記ユーザによって可動のユーザ操作可能オブジェクトと、
前記触覚フィードバックコンピュータ周辺機器内の少なくとも１つのセンサであって、前記ユーザ操作可能オブジェクトの位置または動きを検出するセンサと、
前記触覚フィードバックコンピュータ周辺機器内の少なくとも１つのアクチュエータであって、制御信号に基づいて力を出力するようになっているアクチュエータと、
前記触覚フィードバックコンピュータ周辺機器に対してローカルなコントローラであって、
前記少なくとも１つのセンサからの信号を読み取って、前記センサの状態を表わすデータを、通信チャンネルを介してホストコンピュータへ報告し、
前記通信チャンネルを介して前記ホストコンピュータから送られる複数の異なるホストコマンドを受け、前記ホストコマンドのうちの少なくとも１つが、前記グラフィック環境内でのイベントまたは相互作用に応じて前記ホストコンピュータによって送られる力コマンドであり、
前記触覚フィードバックコンピュータ周辺機器のユーザによって感じとられる１つ以上の力を生み出すために前記力コマンドに応じて前記少なくとも１つのアクチュエータを制御する、
ことができるコントローラと、
を備え、
前記力コマンドは、前記イベントまたは相互作用と関連付けられており前記１つ以上の力によって引き起こされるべき触感を表わし、
前記ホストコマンドは、前記触感を識別するためのコマンド識別子と、前記触感を特徴付ける少なくとも１つのコマンドパラメータとを含み、
前記少なくとも１つのコマンドパラメータは、前記自由度のうちの１つのデッドバンド領域のサイズを指定するデッドバンドパラメータを含み、
前記ユーザ操作可能オブジェクトがデッドバンド領域にある間は、出力される力の大きさがほぼゼロとなっており、前記デッドバンド領域は、前記ユーザ操作可能オブジェクトの基点位置の周囲にほぼ中心付けられる、
触覚フィードバックコンピュータ周辺機器。
【請求項２】
前記ホストコマンドによって表わされる前記触感は、前記デッドバンド領域をその中心領域として有する溝感覚である、請求項１に記載の触覚フィードバックコンピュータ周辺機器。
【請求項３】
前記中心領域の両側で復元力が前記ユーザ操作可能オブジェクトを付勢し、前記付勢が前記中心領域へ向かっている、請求項２に記載の触覚フィードバックコンピュータ周辺機器。
【請求項４】
前記復元力は、前記中心領域からの所定のスナップアウト距離によって決定される領域内でのみ適用される、請求項３に記載の触覚フィードバックコンピュータ周辺機器。
【請求項５】
前記中心領域の中心は、前記触覚フィードバックインタフェース機器と通信するホストコンピュータによってグラフィック環境内に表示されるグラフィックオブジェクトとほぼ位置合わせされる、請求項２に記載の触覚フィードバックコンピュータ周辺機器。
【請求項６】
前記溝感覚は、前記ホストコンピュータによって実行されるホストソフトウェアを用いる位置制御パラダイムで与えられる、請求項２に記載の触覚フィードバックコンピュータ周辺機器。
【請求項７】
グラフィック環境を実行するホストコンピュータと通信する触覚フィードバックコンピュータ周辺機器であって、
前記触覚フィードバックコンピュータ周辺機器上のユーザ操作可能オブジェクトであって、少なくとも１つの自由度で前記ユーザによって可動のユーザ操作可能オブジェクトと、
前記触覚フィードバックコンピュータ周辺機器内の少なくとも１つのセンサであって、前記ユーザ操作可能オブジェクトの位置または動きを検出するようになっているセンサと、
前記触覚フィードバックコンピュータ周辺機器内の少なくとも１つのアクチュエータであって、制御信号に基づいて前記ユーザ操作可能オブジェクトに対して力を出力するようになっているアクチュエータと、
前記触覚フィードバックコンピュータ周辺機器に対してローカルなコントローラであって、
前記少なくとも１つのセンサから信号を繰り返し読み取り、
前記センサの状態を表わすデータを、通信チャンネルを介してホストコンピュータへ繰り返し報告し、
前記通信チャンネルを介して前記ホストコンピュータから送られる複数の異なるホストコマンドを受け、前記ホストコマンドのうちの少なくとも１つが、前記グラフィック環境内の少なくとも２つのオブジェクト間の衝突に応じて前記ホストコンピュータによって送られる力コマンドであり、前記オブジェクトのうちの１つが前記センサの状態を表わす前記データによって影響され、
前記触覚フィードバックコンピュータ周辺機器のユーザによって感じとられる１つ以上の力を生み出すために前記力コマンドに応じて前記少なくとも１つのアクチュエータに対して前記制御信号を与える、
ことができるコントローラと、
を備え、
前記力コマンドは、前記衝突と関連付けられると共に相関され且つ前記１つ以上の力によって引き起こされるべき触感を表わし、
前記ホストコマンドは、前記触感を識別するためのコマンド識別子と、前記触感を特徴付ける少なくとも１つのコマンドパラメータとを含む、
触覚フィードバックコンピュータ周辺機器。
【請求項８】
前記少なくとも１つのコマンドパラメータは、前記自由度のうちの１つにおける前記触感のための最大力出力を指定する飽和パラメータを含む、請求項７に記載の触覚フィードバックコンピュータ周辺機器。
【請求項９】
前記飽和パラメータは、前記ユーザ操作可能オブジェクトの変位に対する前記最大力出力を指定し、前記触感がバネ力感覚である、請求項８に記載の触覚フィードバックコンピュータ周辺機器。
【請求項１０】
前記飽和パラメータは、前記少なくとも１つのアクチュエータの最大力出力のパーセンテージとして表わされる、請求項８に記載の触覚フィードバックコンピュータ周辺機器。
【請求項１１】
前記触感が条件力感覚である、請求項８に記載の触覚フィードバックコンピュータ周辺機器。
【請求項１２】
前記触感は、前記ユーザ操作可能オブジェクトに対して加えられ且つ前記ユーザ操作可能オブジェクトの障壁領域への動きに伴って直線的に増大する抵抗力を与える障壁触感である、請求項８に記載の触覚フィードバックコンピュータ周辺機器。
【請求項１３】
前記ホストコマンドは、前記ユーザ操作可能オブジェクトが前記障壁領域内にあるときに前記ユーザ操作可能オブジェクトに対して加えられる抵抗力の大きさを示す硬さパラメータも含む、請求項１２に記載の触覚フィードバックコンピュータ周辺機器。
【請求項１４】
前記ホストコマンドは、前記ユーザ操作可能オブジェクトの前記自由度での前記障壁領域の位置を示す位置パラメータも含む、請求項１２に記載の触覚フィードバックコンピュータ周辺機器。
【請求項１５】
前記ユーザ操作可能オブジェクトが前記障壁領域を通って移動する直後に補助力が前記ユーザ操作可能オブジェクトに対して加えられる、請求項１２に記載の触覚フィードバックコンピュータ周辺機器。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【公開番号】特開２０１０−６１６６７（Ｐ２０１０−６１６６７Ａ）
【公開日】平成２２年３月１８日（２０１０．３．１８）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−２０７１０７（Ｐ２００９−２０７１０７）
【出願日】平成２１年９月８日（２００９．９．８）
【分割の表示】特願平９−５１３５９９の分割
【原出願日】平成８年９月２５日（１９９６．９．２５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
【出願人】（５０６００５３３０）イマージョン　コーポレイション (3)
【Ｆターム（参考）】