DE10082696B3 - Verfahren zur Bereitstellung von Krafteffekten mittels einer Kraftrückkopplungsvorrichtung und Vorrichtung hierfür - Google Patents

Verfahren zur Bereitstellung von Krafteffekten mittels einer Kraftrückkopplungsvorrichtung und Vorrichtung hierfür Download PDF

Info

Publication number
DE10082696B3
DE10082696B3 DE10082696T DE10082696T DE10082696B3 DE 10082696 B3 DE10082696 B3 DE 10082696B3 DE 10082696 T DE10082696 T DE 10082696T DE 10082696 T DE10082696 T DE 10082696T DE 10082696 B3 DE10082696 B3 DE 10082696B3
Authority
DE
Germany
Prior art keywords
force
effect
force effect
memory
effects
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE10082696T
Other languages
English (en)
Other versions
DE10082696T1 (de
Inventor
Adam C. Braun
Jonathan L. Beamer
Dean C. Chang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Immersion Corp
Original Assignee
Immersion Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Immersion Corp filed Critical Immersion Corp
Publication of DE10082696T1 publication Critical patent/DE10082696T1/de
Application granted granted Critical
Publication of DE10082696B3 publication Critical patent/DE10082696B3/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/016—Input arrangements with force or tactile feedback as computer generated output to the user
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/011—Arrangements for interaction with the human body, e.g. for user immersion in virtual reality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/03—Arrangements for converting the position or the displacement of a member into a coded form
    • G06F3/033—Pointing devices displaced or positioned by the user, e.g. mice, trackballs, pens or joysticks; Accessories therefor
    • G06F3/0354—Pointing devices displaced or positioned by the user, e.g. mice, trackballs, pens or joysticks; Accessories therefor with detection of 2D relative movements between the device, or an operating part thereof, and a plane or surface, e.g. 2D mice, trackballs, pens or pucks
    • G06F3/03543—Mice or pucks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/03—Arrangements for converting the position or the displacement of a member into a coded form
    • G06F3/033—Pointing devices displaced or positioned by the user, e.g. mice, trackballs, pens or joysticks; Accessories therefor
    • G06F3/0354—Pointing devices displaced or positioned by the user, e.g. mice, trackballs, pens or joysticks; Accessories therefor with detection of 2D relative movements between the device, or an operating part thereof, and a plane or surface, e.g. 2D mice, trackballs, pens or pucks
    • G06F3/03548—Sliders, in which the moving part moves in a plane
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2203/00—Indexing scheme relating to G06F3/00 - G06F3/048
    • G06F2203/01—Indexing scheme relating to G06F3/01
    • G06F2203/013—Force feedback applied to a game
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2203/00—Indexing scheme relating to G06F3/00 - G06F3/048
    • G06F2203/01—Indexing scheme relating to G06F3/01
    • G06F2203/014—Force feedback applied to GUI
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2203/00—Indexing scheme relating to G06F3/00 - G06F3/048
    • G06F2203/033—Indexing scheme relating to G06F3/033
    • G06F2203/0333—Ergonomic shaped mouse for one hand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Abstract

Verfahren zur Bereitstellung von Krafteffekten mittels einer Kraftrückkopplungsvorrichtung mit einer örtlichen Steuerung der Ausgabe von Kraftempfindungen, wobei die Kraftrückkopplungsvorrichtung an einen Host-Computer gekoppelt ist und das Verfahren umfasst: – Empfangen eines Krafteffekt-Ladebefehls von einem Anwendungsprogramm, wobei der Krafteffekt-Ladebefehl die Daten zur Speicherung eines Krafteffektes in einem Gerätespeicher anweist; gekennzeichnet durch; – Erzeugen einer Gerätespeicherdarstellung, wobei der Gerätespeicher auf der Kraftrückkopplungsvorrichtung vorgesehen ist und die Darstellung im Speicher des Host-Computers abgelegt wird, wobei das Anwendungsprogramm auf dem Host-Computer läuft; – Speichern der Daten für den Krafteffekt in der Gerätespeicherdarstellung, wobei in der Darstellung eine größere Anzahl dieser Krafteffekte gespeichert werden kann als in dem Gerätespeicher; – Bestimmen, ob der Gerätespeicher den Krafteffekt speichern kann, durch Überprüfen der Gerätespeicherdarstellung, wobei das Bestimmen auf einer Priorität des Krafteffekts im Vergleich zu Prioritäten geladener Krafteffektdaten basiert, die in der Speichervorrichtung gespeichert sind; und – falls der Gerätespeicher den Krafteffekt...

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich allgemein auf Schnittstellenvorrichtungen und Verfahren hierfür, die es dem Menschen ermöglichen, mit Computersystemen in Verbindung zu treten, und insbesondere auf Computer-Schnittstellenvorrichtungen, die es dem Benutzer ermöglichen, eine Eingabe an Computersysteme und eine Kraftrückkopplung (Force Feedback) an den Benutzer bereitzustellen. Verfahren und eine Vorrichtung mit den oberbegrifflichen Merkmalen der Patentansprüche 1, 8, 25 und 28 sind aus der US 5,734,373 A bekannt.
  • Rechnersysteme werden in großem Umfang zur Realisierung vieler Anwendungsformen eingesetzt, wie z. B. Textverarbeitung, Datenverwaltung, Simulationen, Spiele und andere Aufgaben. Ein Rechnersystem zeigt einem Benutzer typischerweise eine Bildumgebung auf einem Bildschirm oder anderen Bildausgabegerät an. Benutzer können mit der angezeigten Umgebung in Dialog treten, um Aufgaben am Computer zu erfüllen, ein Spiel zu spielen, eine simulierte Umgebung zu erleben, ein computerunterstütztes Konstruktions-(CAD)-System zu verwenden etc.. Eine besonders verbreitete Bildumgebung ist eine graphische Benutzeroberfläche (GUI), wozu u. a. Systeme gehören, wie das Betriebssystem WindowsTM Von der Firma Microsoft Corporation, das Betriebssystem MacOS Von der Firma Apple Computer, Inc. und X-Windows für das Betriebssystem Unix. Die meisten GUIs sind gegenwärtig zweidimensional, wie auf einem Computerbildschirm angezeigt; es können jedoch auch dreidimensionale (3D-)GUIs mit 3D-Umgebungen bereitgestellt werden. Andere graphische Umgebungen beinhalten Spiele, Simulationen, CAD-Umgebungen, World Wide Web/Internet-Schnittstellen etc., die interaktive 2D- oder 3D-Umgebungen darstellen, die der Benutzer bearbeiten kann. Solche Systeme sind z. B. in der EP 1 036 390 B1 beschrieben.
  • Den Dialog mit der Rechnerumgebung und deren Bedienung erreicht der Benutzer unter Verwendung einer beliebigen von vielen verschiedenen Arten von Mensch/Computer-Schnittstellenvorrichtungen, die mit dem Rechnersystem verbunden sind, das die angezeigte Umgebung steuert. In den meisten Systemen aktualisiert ein auf dem Host-Computer laufendes Anwendungsprogramm die Umgebung unter Ansprechen auf die Betätigung des Benutzers eines Benutzer-Handhabungsgeräts, das in der Schnittstellenvorrichtung enthalten ist, z. B. eine Maus, ein Joystick-Griff, eine Rollkugel, ein Steuerrad, eine Spielunterlage (Gamepad) etc.. Der Computer liefert dem Benutzer unter Verwendung des Bildschirms eine Rückkopplung (Feedback).
  • Derartige sog. Force-Feedback-Schnittstellenvorrichtungen (die auch taktile und kinästhetische Kraftvorrichtungen enthalten können) ermöglichen es einem Benutzer, basierend auf Dialogen und Ereignissen innerhalb der angezeigten graphischen Umgebung Kräfte auf dem Handhabungsgerät zu spüren. Kraftrückkopplungsvorrichtungen können in vielen Formen realisiert sein, z. B. als Joystick, Maus, Steuerrad, Spielunterlage (Gamepad) etc.. Typischerweise werden rechnergesteuerte Aktuatoren verwendet, um in bereitgestellten Freiheitsgraden Kräfte auf den Benutzergegenstand und/oder das Gehäuse der Vorrichtung auszugeben und damit verschiedene fühlbare Empfindungen und Kraftempfindungen zu simulieren, wie z. B. eine Hemmkraft, wenn ein Positionsanzeiger in eine Wand bewegt wird, eine Erschütterungskraft, wenn ein virtueller Rennwagen von einer Rennstrecke abkommt oder eine Federkraft zur Vorspannung eines Positionsanzeigers, damit er sich zu einer Ausgangsposition der Feder zurückbewegt.
  • Die Befehlssteuerung der Ausgabe von Kraftempfindungen auf das Gerät erfolgt gewöhnlich durch das auf dem Hauptrechner bzw. Host-Computer laufende Anwendungsprogramm. Die meisten Kraftrückkopplungsvorrichtungen für den Normalverbraucher weisen einen Mikroprozessor und einen Speicher auf, um Host-Steuerbefehle zu analysieren und verschiedene Kraftrückkopplungseffekte örtlich an dem Gerät zu speichern und zu verwalten. Der Gerätemikroprozessor kann Benutzereingaben und andere Bedingungen basierend auf Steuerbefehlen von dem Hauptrechner bzw. Host prüfen und kann Kraftempfindungen unter Verwendung der im örtlichen Speicher gespeicherten Kraftempfindungsdaten ausgeben. Die örtliche Verwaltung von Kraftempfindungen auf dem Gerät erhöht die Natürlichkeit erzeugter Kraftempfindungen infolge der Ansprechempfindlichkeit der Geräteverarbeitung erheblich; wenn der Host alle Eingaben verarbeiten und alle Kräfte generieren müßte, würde die Datenübertragung zwischen Host und Gerät Verzögerungen bei der Ansprechempfindlichkeit verursachen, die die Qualität der Kraftempfindungen stark herabsetzen würden. Daher ist die Vorrichtung zum Speichern von Kraftempfindungsdaten und zur unabhängigen Befehlssteuerung dieser Kraftempfindungen mit Gewähr in Bezug auf eine realistische Kraftrückkopplung nur eingeschränkt tauglich.
  • Beim Bereitstellen von Kraftrückkopplungsempfindungen auf einer Kraftrückkopplungsvorrichtung ergeben sich mehrere Probleme in Bezug auf die Handhabung von Kraftrückkopplungsempfindungen. Ein Problem ist, daß der Speicher auf der Kraftrückkopplungsvorrichtung aus Kostengründen begrenzt ist. Ein Gerät mag nur in der Lage sein, eine gewisse limitierte Anzahl von Kraftempfindungsdaten (”Krafteffekte”) zu speichern, bevor der örtliche Speicher voll ist. Ein Anwendungsprogramm kann jedoch die Ausgabe einer großen Anzahl von unterschiedlichen Krafteffekten während unterschiedlicher Bedingungen und Ereignisse in dem Programm erfordern. Beispielsweise kann bei einem Spieleprogramm für ein Rennen die Ausgabe von zwanzig unterschiedlichen Krafteffekten für verschiedene Rennbedingungen während eines Spiels erwünscht sein; das Gerät ist jedoch vielleicht nur in der Lage, Daten für zehn Krafteffekte gleichzeitig zu speichern.
  • Da die Daten für einen Krafteffekt örtlich an dem Gerät gespeichert werden sollten, bevor die Kraft ausgegeben wird, muß das Anwendungsprogramm zuerst versuchen, Effektdaten an dem Gerät zu speichern. Eine Möglichkeit, Krafteffekte an einem Gerät zu speichern, besteht darin, daß die Hostanwendung eine Aufforderung an das Gerät sendet, einen ganz bestimmten Krafteffekt im Gerätespeicher zu speichern. Das Gerät bestimmt, ob genügend Speicher verfügbar ist und antwortet dem Host entweder, daß der angefragte Krafteffekt in dem Gerätespeicher gespeichert wurde oder daß der angefragte Krafteffekt aus Platzmangel nicht gespeichert werden konnte. Falls der Effekt nicht gespeichert werden konnte, kann die Hostanwendung einen ”Lösch-”Befehl an das Gerät senden, um einen gegenwärtig unbenutzten Krafteffekt aus dem Gerätespeicher zu entfernen, um genügend Raum für den angefragten Krafteffekt freizumachen, und kann dann die Aufforderung zum Speichern des neuen Krafteffektes erneut schicken. Dieses Verfahren kann jedoch eine gewisse Herabsetzung der Kraftqualität an der Vorrichtung verursachen, da Gerät und Host die Daten mehrmals hin- und herschicken müssen, um den Gerätespeicher freizumachen und einen neuen Krafteffekt zu speichern.
  • Da der Gerätespeicher zudem gewöhnlich nicht alle Krafteffekte speichern kann, die eine Hostanwendung verwenden möchte, muß die Hostanwendung Verarbeitungszeit für Speicherverwaltungsaufgaben aufbringen. Beispielsweise muß die Hostanwendung bestimmen, ob ein alter Krafteffekt im Gerätespeicher mit einem neuen Krafteffekt überlagert werden soll und dann den Steuerbefehl erteilen, daß solch ein Überlagern stattfindet. Die Anwendung muß verfolgen, wieviel Platz im Gerätespeicher verfügbar ist und welche Krafteffekte gegenwärtig ausgegeben werden. Eine derartige Extraverarbeitung durch die Hostanwendung kann die Gesamtleistung der Anwendung schmälern und zwingt den Gestalter der Anwendung, sich auf niedrigere Verarbeitungen zu konzentrieren, wodurch der vorformatierte Kraftgestaltungsprozeß beeinträchtigt wird.
  • WESEN DER ERFINDUNG
  • Die vorliegende Erfindung ist auf die Speicherverwaltung von Krafteffekten und andere Handhabungen von Kraftempfindungen für ein Kraftrückkopplungssystem gerichtet. Es werden Ausführungsformen offenbart, die für eine effiziente Verwaltung des Gerätespeichers und der Krafteffektausgabe sorgen.
  • Gemäß einem Aspekt der vorliegenden Erfindung beinhaltet die Handhabung der Speicherung von Krafteffekten in einem Kraftrückkopplungssystem das Empfangen eines Krafteffekt-Erstellungsbefehls durch ein auf einem Host-Computer laufendes Treiberprogramm. Der Steuerbefehl kommt von einem auf dem Host-Computer laufenden Anwendungsprogramm und gibt Anweisung, daß bestimmte Krafteffektdaten für einen bestimmten Krafteffekt im örtlichen Speicher einer mit dem Host-Computer verbundenen Kraftrückkopplungsvorrichtung gespeichert werden sollen. Dann wird bestimmt, ob der örtliche Speicher genügend Platz zum Speichern der bestimmten Krafteffektdaten hat. Wenn genügend Platz vorhanden ist, werden die bestimmten Krafteffektdaten an die Kraftrückkopplungsvorrichtung gesendet, um in dem örtlichen Speicher gespeichert zu werden. Falls nicht genügend Platz vorhanden ist, werden die bestimmten Krafteffektdaten in einem im Host-Computer-Speicher implementierten Cache-Speicher anstelle des örtlichen Speichers gespeichert. Wenn später von dem Treiber ein Steuerbefehl zur Ausgabe des im Cache-Speicher gespeicherten Krafteffektes an einen Benutzer der Kraftrückkopplungsvorrichtung erhalten wird, überlagert der Treiber die bestimmten Krafteffektdaten mit geladenen Krafteffektdaten in dem örtlichen Speicher und weist die Kraftrückkopplungsvorrichtung an, den bestimmten Krafteffekt auszugeben.
  • Vorzugsweise erzeugt der Treiber eine Darstellung des örtlichen Speichers in dem Host-Computer-Speicher, und die Darstellung kann auf genügend Platz für den Krafteffekt überprüft werden. Alternativ kann die Kraftrückkopplungsvorrichtung abgefragt und eine Antwort dahingehend erhalten werden, ob genügend Platz verfügbar ist. Zudem kann bestimmt werden, ob ein Krafteffekt geladen werden kann, indem eine Priorität des bestimmten Krafteffektes mit einer Priorität eines oder mehr geladener Krafteffekte verglichen wird, wobei die größere Prioritätswirkung in den Gerätespeicher geladen werden kann. Die Priorität des/der geladenen Krafteffekte(s) kann zumindest teilweise basierend darauf bestimmt werden, ob der geladene Krafteffekt gegenwärtig von dem Gerät ausgegeben wird, auf der Zeitspanne, seit der geladene Krafteffekt zuletzt von dem Gerät ausgegeben wurde, und/oder darauf, ob der geladene Krafteffekt wahrscheinlich basierend auf einer Bewegungsrichtung eines Handhabungsgeräts der Kraftrückkopplungsvorrichtung in einem Nutzraum des Handhabungsgeräts der Vorrichtung ausgegeben wird. Die Priorität kann auch vordefiniert sein, z. B. durch das Anwendungsprogramm. Des weiteren können Krafteffekte in Kategorien eingruppiert werden, um bei der Bestimmung zu helfen, welche geladenen Krafteffekte mit im Cache gespeicherten Krafteffekten überlagert werden können. Eine Vorrichtung zur Leitung der Speicherung von Effekten unter Verwendung eines Host-Cache-Speichers arbeitet wie oben beschrieben.
  • Gemäß einem anderen Aspekt der vorliegenden Erfindung werden Kräfte von einer an einen Host-Computer gekoppelten Kraftrückkopplungsvorrichtung ausgegeben. Der Host-Computer empfängt einen Krafteffekt-Wiedergabebefehl, der ihn anweist, daß ein bestimmter Krafteffekt durch die Kraftrückkopplungsvorrichtung ausgegeben werden soll. Die Daten für den bestimmten Krafteffekt und Daten für zumindest einen anderen Krafteffekt sind in einem örtlichen Speicher der Kraftrückkopplungsvorrichtung gespeichert. Eine Kennzeichnung des bestimmten Krafteffektes ist in einer Spielliste in dem örtlichen Speicher bezeichnet. Wenn eine Kraft auszugeben ist, wird die Spielliste überprüft, um festzustellen, welche der gespeicherten Krafteffekte ausgegeben werden sollen. Dann wird basierend auf den in der Spielliste bezeichneten Krafteffekten eine Kraft bestimmt und die Kraft an einen Benutzer der Kraftrückkopplungsvorrichtung ausgegeben. Vorzugsweise basiert die Ausgabekraft auf einer Summe von Beiträgen aus den in der Spielliste bezeichneten Krafteffekten. Im örtlichen Speicher kann eine Zahl gespeichert sein, die angibt, wie viele der im örtlichen Speicher gespeicherten Krafteffekte gegenwärtig zur Ausgabe bestimmt sind. Dies ermöglicht einen effizienten Zugriff nur auf die Spiele-Krafteffekte auf dem Gerät.
  • Gemäß noch einem Aspekt der vorliegenden Erfindung wird die Kraftausgabe an einen Benutzer einer Kraftrückkopplungsvorrichtung nur in vorbestimmten Zeitintervallen bereitgestellt. Eine erste durch Aktuatoren der Kraftrückkopplungsvorrichtung auszugebende Kraft wird bestimmt und dann zu einem ersten Zeitpunkt ausgegeben, der gekommen ist, wenn ein vorbestimmtes Zeitintervall vergangen ist. Dann wird eine zweite auszugebende Kraft bestimmt. Falls das vorbestimmte Zeitintervall noch nicht vergangen ist, wenn die zweite Kraft bestimmt wird, dann wartet die Vorrichtung ein zweites Zeitintervall ab und gibt die zweite Kraft zu einem zweiten Zeitpunkt aus. Falls das vorbestimmte Zeitintervall vergangen ist, wenn die zweite Kraft bestimmt wird, was bedeutet, daß die Verarbeitung der Kraft länger gedauert hat als ein Zeitintervall, dann wartet die Vorrichtung ein folgendes Zeitintervall nach Ablauf einer ganzzahligen Anzahl der vorbestimmten Zeitintervalle ab und gibt zu dem folgenden Zeitpunkt eine dritte Kraft aus. Die dritte Kraft ist dem folgenden Zeitpunkt angepaßt. Dies ermöglicht die Verwendung eines kurzen Zeitintervalls und damit ein schnelleres Aktualisieren der Ausgabekräfte; während der seltenen Intervalle, in denen die Kraftverarbeitung länger dauert als ein Zeitintervall, kann die Kraft bei späteren Intervallen ausgegeben werden.
  • Die vorliegende Erfindung stellt mehrere Ausführungsformen zur Abwicklung des Krafteffektes und Kraftausgabe in einem Kraftrückkopplungssystem bereit. Eine Ausführung des Gerätespeichers ist vorzugsweise im Host-Computer-Speicher enthalten, um dem Host-Computer die Möglichkeit zu geben, effizient zu bestimmen, wann Effekte in den Gerätespeicher geladen werden können. Die Speicherung von Krafteffekten im Host-Cache läßt das Anwendungsprogramm so funktionieren, als ob das Gerät eine fast unbegrenzte Anzahl von Effekten speichern könnte, wodurch die Anwendung von der Abwicklung niedrigerer Verarbeitungen und vom Überlagern von Krafteffekten befreit wird. Die Spielliste und Einzelintervall-Kraftausgabe an der Kraftrückkopplungsvorrichtung ermöglicht eine effiziente Ausgabe von Kraftempfindungen mit hoher Wiedergabetreue.
  • Diese und andere Vorteile der verschiedenen Ausführungsformen der vorliegenden Erfindung werden Fachleuten auf diesem Gebiet beim Lesen der folgenden Beschreibung der Erfindung und beim Studium der einzelnen Figuren der Zeichnung klar werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockdiagramm zur Darstellung eines Kraftrückkopplungssystems, das zur Verwendung mit der vorliegenden Erfindung geeignet ist;
  • 2 ist ein Blockdiagramm zur Darstellung einer Hierarchie von Programmen, die auf dem Host-Computer in dem Kraftrückkopplungssystem gemäß 1 laufen;
  • 3 ist eine schematische Darstellung eines Beispiels einer Krafteffektstruktur, die in der vorliegenden Erfindung verwendet werden kann;
  • 4 ist eine schematische Darstellung einer Organisation des Gerätespeichers in der Kraftrückkopplungsvorrichtung des Systems nach 1;
  • 5 ist ein Flußdiagramm zur Darstellung eines Verfahrens der vorliegenden Erfindung zur Host-Abwicklung von Krafteffekten unter Verwendung einer Host-Gerätespeicherdarstellung;
  • 6 ist ein Flußdiagramm zur Darstellung eines Verfahrens zum Ausgeben von Kräften auf der Kraftrückkopplungsvorrichtung;
  • 7 ist ein Flußdiagramm zur Darstellung eines Verfahrens der vorliegenden Erfindung zur Host-Abwicklung von Krafteffekten unter Verwendung einer Gerätespeicherdarstellung und Host-Cache-Speicherung von Krafteffekten;
  • 8 ist eine schematische Darstellung einer graphischen Benutzeroberfläche und eines Positionsanzeigers zur Darstellung der räumlichen Cache-Speicherung der vorliegenden Erfindung;
  • 9a und 9b sind schematische Darstellungen des Gerätespeichers, der Host-Darstellung davon und der in jedem gespeicherten Krafteffekte; und
  • 10 ist eine schematische Darstellung des Gerätespeichers und einer Spielliste der vorliegenden Erfindung.
  • DETAILLIERTE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
  • 1 ist ein Blockdiagramm zur Darstellung eines Kraftrückkopplungssystems 10, das zur Verwendung mit der vorliegenden Erfindung geeignet ist. Das System 10 weist einen Host-Computer 18 und eine Force-Feedback-Schnittstellenvorrichtung 11 auf. Ein ähnliches System ist im US-Patent Nr. 5,734,373 detailliert beschrieben.
  • Der Host-Computer 18 ist vorzugsweise ein Personalcomputer oder Arbeitsplatzrechner (Workstation), wie z. B. ein PC-kompatibler Computer bzw. Macintosh-Personalcomputer, oder eine Workstation von SUN oder Silicon Graphics. Alternativ kann das Host-Rechnersystem 18 eines aus einer Vielfalt von Heimvideo-Spielsystemen sein, die üblicherweise an ein Fernsehgerät angeschlossen sind, wie z. B. Konsolensysteme, die von Nintendo, Sega oder Sony erhältlich sind. In anderen Ausführungsformen kann das Host-Rechnersystem 18 ein ”Aufsetzkasten” sein, der beispielsweise dazu verwendet werden kann, interaktive Fernsehfunktionen an den Benutzer bereitzustellen, oder ein ”Netzwerk-” oder ”Internet-Computer”, der es Benutzern ermöglicht, unter Verwendung von Standard-Verbindungen und -Protokollen, wie sie z. B. für das Internet und das World Wide Web benutzt werden, mit einem örtlichen oder globalen Netzwerk in Dialog zu treten.
  • Der Host-Computer 18 weist üblicherweise einen Host-Mikroprozessor 108, einen Direktzugriffsspeicher (RAM) 110, einen Festspeicher (ROM) 112, eine Eingabe/Ausgabe-(I/O)-Elektronik 114, einen Taktgeber 116, eine Anzeigevorrichtung 20 und eine Akustikausgabevorrichtung 118 auf. Der Host-Mikroprozessor 108 kann eine Vielfalt von verfügbaren Mikroprozessoren von Intel, AMD, Motorola oder anderen Herstellern aufweisen. Der Mikroprozessor 108 ruft vorzugsweise Befehle und andere notwendige Daten aus dem RAM 110 und ROM 112 ab und speichert sie, wie Fachleuten auf diesem Gebiet gut bekannt ist. In der beschriebenen Ausführungsform kann der Host-Computer 18 Meßfühlerdaten oder ein Meßfühlersignal von Meßfühlern des Geräts 11 und andere Informationen über einen Bus 120 empfangen. Der Mikroprozessor 108 kann Daten vom Bus 120 unter Verwendung der I/O-Elektronik 114 empfangen und kann die I/O-Elektronik, den Bus 120 und/oder andere Busse zur Steuerung anderer Peripheriegeräte wie Diskettenlaufwerke, Magnetplattenlaufwerke, CD-ROM, DVD-ROM, Permanentspeicher etc. verwenden. Der Host-Computer 18 kann über den Bus 120 auch Steuerbefehle an die Schnittstellenvorrichtung 11 ausgeben, um eine Kraftrückkopplung für das System 10 zu veranlassen.
  • Der Computer 18 kann unter den Betriebssystemen Windows, MacOS, Unix oder anderen und auch mit anderer Software arbeiten. Der Host-Computer 18 implementiert vorzugsweise ein oder mehr Anwendungsprogramme (”Anwendungen”), mit denen ein Benutzer über eine Maus 12 und ggf. andere periphere Geräte im Dialog ist und die eine Kraftrückkopplungsfunktion einschließen können. Beispielsweise können die Host-Anwendungen eine Simulation, ein Videospiel, eine Web-Seite oder einen Browser einschließen, der HTML- oder VRML-Befehle realisiert, ein Textverarbeitungssystem, Zeichenprogramm, Tabellenkalkulation, wissenschaftliches Analyseprogramm oder anderes Anwendungsprogramm einschließen, das Benutzereingaben von der Vorrichtung 11 verwendet und Force-Feedback-Steuerbefehle an die Vorrichtung 11 ausgibt. In der bevorzugten Ausführungsform können vielfache Anwendungen zugleich in einer Multitask-Umgebung des Host-Computers laufen. Der Computer 18 kann hierin auch als Anzeigeeinheit für ”graphische Gegenstände” oder ”Computerobjekte” bezeichnet werden. Diese Objekte sind keine körperlichen Gegenstände, sondern logische Sammlungen von Daten und/oder Verfahrensabläufen, die vom Computer 18 als Bilder auf dem Bildschirm 20 angezeigt werden können, wie Fachleuten auf diesem Gebiet gut bekannt ist. Ein angezeigter Cursor (Positionsanzeiger) oder ein simuliertes Cockpit eines Flugzeugs könnte als graphisches Objekt angesehen werden. Geeignete Software-Treiber, die solche Anwendungen über eine Schnittstelle mit Computer-Eingabe/Ausgabe-(I/O)-Vorrichtungen verbinden, sind von der Firma Immersion Corporation, San Jose, Kalifornien, erhältlich.
  • Die Anzeigevorrichtung 20 kann im Host-Computer 18 eingeschlossen sein und ein Standardbildschirm (LCD, CRT etc.), eine 3D-Brille oder irgendeine andere Bildausgabevorrichtung sein. Typischerweise liefert die Hostanwendung Bilder, die auf der Anzeigevorrichtung 20 angezeigt werden sollen. Beispielsweise kann der Bildschirm 20 Bilder von einer GUI von einem beweglichen Standpunkt der eigenen Person in der virtuellen Realität eines Spiels aus, aus der Perspektive eines Dritten von Gegenständen, Hintergründen, einer Simulation (z. B. medizinische Simulation) etc. anzeigen.
  • Der Taktgeber 116 ist ein Standard-Taktquarz oder ähnliches Bauteil, das vom Host-Computer 18 dazu verwendet wird, die Taktung der vom Host-Mikroprozessor 108 und anderen Teilen des Computers 18 verwendeten elektrischen Signale bereitzustellen. Die Akustikausgabevorrichtung 118, wie z. B. Lautsprecher, kann über Verstärker, Filter und andere Fachleuten auf diesem Gebiet gut bekannte Schaltsysteme an den Host-Mikroprozessor 108 angeschlossen sein. Der Host-Prozessor 108 gibt Signale an den Lautsprecher 118 aus, um eine Tonausgabe an den Benutzer bereitzustellen, wenn während der Implementierung des Host-Anwendungsprogramms ein ”Tonereignis” stattfindet. Auch andere Arten von Peripheriegeräten können mit dem Host-Prozessor 108 verbunden sein, z. B. Speichervorrichtungen (Festplattenlaufwerk, CD-ROM-Laufwerk, Diskettenlaufwerk etc.), Drucker und andere Ein- und Ausgabevorrichtungen.
  • Die Kraftrückkopplungsvorrichtung 11 ist durch einen bidirektionalen Bus 120 an das Host-Rechnersystem 18 angeschlossen. Der bidirektionale Bus sendet Daten in beide Richtungen zwischen dem Host-Rechnersystem 18 und der Schnittstellenvorrichtung 11. Der Bus 120 kann ein bitserieller Schnittstellenbus sein, der Daten gemäß einem seriellen Kommunikationsprotokoll bereitstellt, ein paralleler Bus, der ein paralleles Protokoll verwendet, oder ein anderer Bustyp. Ein Schnittstellenanschluß des Host-Rechnersystems 18, beispielsweise ein bitserieller USB- oder RS232-Schnittstellenanschluß, verbindet den Bus 120 mit dem Host-Rechnersystem 18. Alternativ kann ein Firewire (auch IEEE 1394 genannt) als Bus 120 verwendet werden; oder der Bus kann zwischen einer Schnittstellenkarte im Host-Computer 18 sein, wobei die Schnittstellenkarte Teile der Vorrichtung 11 wie den Mikroprozessor 130 enthält. In anderen Ausführungsformen können Signale zwischen der Schnittstelle 114 und dem Computer 18 durch drahtlose Übertragung/Empfang gesendet werden.
  • Die Kraftrückkopplungsvorrichtung 11 weist eine elektronische Schnittstelle 26, einen mechanischen Abschnitt 24 und ein Handhabungsgerät oder ”Benutzergegenstand” 12 auf. Die elektronische Schnittstelle 26, der mechanische Abschnitt 24 und der Benutzergegenstand 12 können auch gemeinsam als Kraftrückkopplungsvorrichtung 11 angesehen werden.
  • Der Elektronikteil 26 der Schnittstelle kann den Mechanikteil 24 der Schnittstelle mit dem Host-Computer 18 verbinden. Der Elektronikteil 26 ist vorzugsweise im Gehäuse der Vorrichtung 11 enthalten, oder das Elektronikteil kann alternativ im Host-Computer 18 enthalten sein oder als separate Einheit mit einem eigenem Gehäuse vorliegen. Die elektronische Schnittstelle 26 weist einen örtlichen Mikroprozessor 130, einen örtlichen Taktgeber 132, einen örtlichen Speicher 134, eine Sensorschnittstelle 136 und eine Aktuatorschnittstelle 138 auf. Die Schnittstelle 26 kann auch zusätzliche Elektronikbauteile zur Kommunikation über Standardprotokolle auf dem Bus 120 aufweisen. In verschiedenen Ausführungsformen kann die elektronische Schnittstelle 26 oder Teile davon in dem Mechanikteil 24, dem Host-Computer 18 oder in einem eigenen separaten Gehäuse enthalten sein.
  • Der örtliche Mikroprozessor 130 ist vorzugsweise an den Bus 120 angeschlossen und kann eng mit dem Mechanikteil 24 verbunden sein, um eine schnelle Kommunikation mit anderen Teilen der Schnittstellenvorrichtung zu ermöglichen. Der Prozessor 130 wird als ”örtlich” zur Schnittstellenvorrichtung 11 betrachtet, wobei ”örtlich” sich hier auf den Prozessor 130 bezieht, der ein von allen anderen Prozessoren 108 im Host-Computer 18 unabhängiger Mikroprozessor ist. ”Örtlich” bezieht sich vorzugsweise auch auf den Prozessor 130, der für die Kraftrückkopplung und Sensor-Ein-/Ausgabe des Systems 10 reserviert ist, und eng mit den Meßfühlern und Aktuatoren des Mechanikteils 24 verbunden ist, wie z. B. innerhalb des Gehäuses oder in einem eng mit dem Teil 24 verbundenen Gehäuse. Der Mikroprozessor 130 kann mit Software-Befehlen ausgestattet sein, so daß er auf Steuerbefehle oder Anfragen vom Computer-Host 18 wartet, den Steuerbefehl oder die Anfrage analysiert/decodiert, und Eingabe- und Ausgabesignale gemäß dem Steuerbefehl oder der Anfrage abhandelt/steuert. Außerdem arbeitet der Prozessor 130 vorzugsweise unabhängig vom Host-Computer 18, indem er Sensorsignale liest und aus diesen in Übereinstimmung mit einem Host-Steuerbefehl gewählten Sensorsignalen, Zeitsignalen und Kraftprozessen entsprechende Kräfte berechnet, und entsprechende Steuersignale an die Aktuatoren ausgibt. Ein geeigneter Mikroprozessor zur Verwendung als örtlicher Mikroprozessor 130 ist u. a. beispielsweise der 8X930AX von Intel oder alternativ der MC68HC711E9 von Motorola oder der P1C16C74 von Microchip. Der Mikroprozessor 130 kann einen Mikroprozessorchip oder Mehrfach-Prozessoren und/oder Coprozessorchips aufweisen. In anderen Ausführungsformen kann der Mikroprozessor 130 eine digitale Signalprozessor-(DSP)-Funktionsvielfalt aufweisen oder als Statuslogik oder Schaltsystem implementiert sein.
  • In einer Ausführungsform einer örtlichen Steuerung, die den Mikroprozessor 130 verwendet, liefert der Host-Computer 18 höhere Kontrollsteuerbefehle über den Bus 120 an den Mikroprozessor 130, und der Mikroprozessor 130 wickelt niedrigere Kraftsteuerschleifen an die Meßfühler und Aktuatoren in Übereinstimmung mit den höheren Steuerbefehlen und unabhängig vom Host-Computer 18 ab. Der Mikroprozessor 130 kann eingegebene Sensorsignale verarbeiten, um entsprechende Ausgabe-Aktuatorsignale zu bestimmen, indem er den Befehlen eines ”Kraftprozeßablaufs” folgt, der im örtlichen Speicher gespeichert sein kann und Rechenbefehle, Formeln, Kraftgrößen oder andere Daten enthält. Der Kraftprozeßablauf kann ausgeprägte Kraftempfindungen wie Vibrationen, Strukturen, Rucke oder sogar simulierte Wechselwirkungen zwischen angezeigten Objekten steuern. Der Mikroprozessor kann mit den notwendigen Befehlen oder Daten ausgestattet sein, um Meßfühlerablesungen zu prüfen, Positionen graphischer Objekte zu bestimmen und Ausgabekräfte unabhängig vom Host-Computer 18 zu bestimmen. Der Host kann ggf. Programmfunktionen (wie z. B. das Anzeigen von Bildern) implementieren, und es können Synchronisierungsbefehle zwischen dem Mikroprozessor und dem Host 18 übertragen werden, um den Mikroprozessor mit den Host-Prozessen zu korrelieren. Vom Mikroprozessor 130 empfangene und verwendete Sensorsignale (und/oder verarbeitete Sensorsignale) werden auch dem Host-Rechnersystem 18 mitgeteilt, der das Host-Anwendungsprogramm aktualisiert. Derartige Steuerbefehle und die betroffene Funktionsvielfalt ist im US-Patent Nr. 5,734,373 näher erörtert. Der Host kann dem örtlichen Prozessor eine räumliche Anordnung von Objekten in der graphischen Umgebung zur Speicherung im örtlichen Speicher 134 senden, so daß der Mikroprozessor eine Abbildung von Standorten der graphischen Objekte wie Einfassungen bzw. Rahmen besitzt und Wechselwirkungen mit dem Positionsanzeiger örtlich bestimmen kann. Alternativ kann der Computer 18 Kraftrückkopplungssignale direkt an den Mikroprozessor 130 senden, die dann direkt an die Aktuatoren ausgegeben werden und Kräfte auf dem Benutzergegenstand 12 bereitstellen. Die in graphischen Umgebungen verwendete Kraftrückkopplung ist im US-Patent Nr. 5,825,308 näher beschrieben. In einer anderen Ausführungsform kann der Host-Computer 18 über den Bus 120 niedrige Kraft-Steuerbefehle bereitstellen, die der Mikroprozessor 130 direkt an die Aktuatoren überträgt.
  • Zur Bereitstellung von Taktdaten kann an den Mikroprozessor 130 ein örtlicher Taktgeber 132 angeschlossen sein, der dem Systemtaktgeber 116 des Host-Computers 18 ähnlich ist; die Taktdaten könnten beispielsweise zur Berechnung der von den Aktuatoren 64 ausgegebenen Kräfte (z. B. von berechneten Geschwindigkeiten, Beschleunigungen oder anderen zeitabhängigen Faktoren abhängige Kräfte) erforderlich sein. In alternativen Ausführungsformen mit Verwendung der USB-Kommunikations-Schnittstelle oder einem anderen Bus mit Synchronisierungssignal können Taktdaten für den Mikroprozessor 130 von der USB-Schnittstelle abgerufen werden.
  • Vorzugsweise ist an den Mikroprozessor 130 an der Schnittstelle 26 ein örtlicher Speicher 134 angeschlossen, beispielsweise ein RAM und/oder ROM, um Kraftempfindungen (”Krafteffekte”), andere Befehle für den Mikroprozessor 130 sowie temporäre und andere Daten zu speichern. Der Mikroprozessor 130 kann auch Kalibrierungsparameter in einem örtlichen Speicher 134 speichern. Der Speicher 134 kann auch zum Speichern des Status der Kraftrückkopplungsvorrichtung einschließlich einer Bezugsposition, eines gegenwärtigen Steuermodus oder einer Konfiguration etc. verwendet werden. Speicherverwaltungstechniken der vorliegenden Erfindung für den örtlichen Speicher 34 sind nachstehend näher beschrieben.
  • Wahlweise kann in der elektronischen Schnittstelle 26 eine Sensorschnittstelle 136 enthalten sein, um Sensorsignale in Signale umzusetzen, die vom Mikroprozessor 130 und/oder Host-Rechnersystem 18 interpretiert werden können. Solche oder gleichwertige Schaltungen sind Fachleuten auf diesem Gebiet gut bekannt. Alternativ kann der Mikroprozessor 130 oder Host 18 diese Schnittstellenfunktionen durchführen. Die Aktuatorschnittstelle 138 kann fakultativ zwischen die Aktuatoren 64 und den Mikroprozessor 130 geschaltet werden, um Signale vom Mikroprozessor 130 in Signale umzusetzen, die zum Antreiben der Aktuatoren geeignet sind. Die Schnittstelle 138 kann Leistungsverstärker, Schalter, Digital-Analog-Steuereinrichtungen (DAC), und andere Komponenten aufweisen, die Fachleuten auf diesem Gebiet gut bekannt sind. In alternativen Ausführungsformen kann das Schaltsystem der Schnittstelle 138 innerhalb des Mikroprozessors 130 oder in den Aktuatoren vorgesehen sein. Zur Leistungszufuhr an die Aktuatoren 64 und anderen Komponenten kann eine Stromversorgung 140 verwendet werden. Die Leistung kann auch vom Host-Computer über den USB 120 geliefert werden.
  • Das Mechanikteil 24 ist mit dem Elektronikteil 26 verbunden und weist vorzugsweise Meßfühler 62, Aktuatoren 64 und einen Mechanismus 40 auf. Die Meßfühler 62 fühlen die Position, Bewegung und/oder andere Eigenschaften des Handhabungsgeräts 12 entlang einem oder mehr Freiheitsgraden ab und liefern Signale an den Mikroprozessor 130, die diese Eigenschaften darstellende Informationen enthalten. Für jeden Freiheitsgrad des Handhabungsgeräts 12 ist ein Meßfühler 62 vorgesehen, oder es kann ein Einzelkomponentensensor für vielerlei Freiheitsgrade verwendet werden. Beispiele für Meßfühler, die für die hierin beschriebenen Ausführungsformen geeignet sind, sind rotierende optische Codeumsetzer, wie oben beschrieben, lineare optische Codeumsetzer, analoge Meßfühler wie Potentiometer, oder berührungslose Meßfühler wie Hall-Effekt-Magnetsensoren oder ein optischer Meßfühler wie eine Seitenwirkung-Photodiode mit einem Emitter/Detektorpaar. Darüber hinaus können Geschwindigkeitsmeßfühler (z. B. Tachometer) und/oder Beschleunigungsmeßfühler (z. B. Beschleunigungsmesser) zum Messen der Beschleunigung verwendet werden. Des weiteren können entweder relative oder absolute Meßfühler verwendet werden.
  • Die Aktuatoren 64 übertragen Kräfte zu dem Benutzergegenstand 12 in einer oder mehr Richtungen entlang einem oder mehr Freiheitsgraden unter Ansprechen auf vom Mikroprozessor 130 und/oder Host-Computer 18 ausgegebene Signale, d. h. sie sind ”computergesteuert”. Typischerweise ist ein Aktuator 64 für jeden Freiheitsgrad vorgesehen, längs dem die Übertragung von Kräften erwünscht ist. Die Aktuatoren 64 können elektromagnetische Aktuatoren wie Gleichstrommotoren sein oder andere aktive Aktuatoren wie lineare Stromregelmotoren, Schrittmotoren, pneumatische/hydraulische aktive Aktuatoren, ein Drehmomenterzeuger (Motor mit begrenzter Winkelreichweite), Schwingspulenmotoren oder passive Aktuatoren wie Magnetpulverbremsen, Reibungsbremsen oder pneumatische/hydraulische passive Aktuatoren, passive Dämpferelemente, ein elektrorheologischer Fluidaktuator oder ein magnetorheologischer Fluidaktuator. In einigen Ausführungsformen können alle oder einige der Meßfühler 62 und Aktuatoren 64 zusammen als Sensor/Aktuatorpaar-Wandler enthalten sein.
  • Der Mechanismus 40 kann ein beliebiger von mehreren Arten von Mechanismen sein. Beispielsweise können die in den US-Patenten Nr. 6,028,593 ; 6,024,576 ; 5,828,197 ; 5,623,582 ; 5,767,839 ; 5,721,566 und 5,805,140 offenbarten Mechanismen verwendet werden.
  • Der Benutzergegenstand 12 ist ein körperliches Objekt, das ein Benutzer vorzugsweise greifen oder fassen und betätigen kann. Mit ”greifen” ist gemeint, daß der Benutzer einen Teil des Gegenstands in irgendeiner Form körperlich festhalten kann, z. B. mit der Hand, den Fingerspitzen etc.. Mit dem Verfahren und der Vorrichtung der vorliegenden Erfindung kann ein große Anzahl von Arten von benutzerbetätigbaren Gegenständen verwendet werden. Zu solchen Gegenständen gehören beispielsweise eine Maus, eine Kugel, ein Puck, ein Joystick, würfelförmige oder anders geformte Handgriffe, eine Druckknopffassung zur Aufnahme eines Fingers oder Stiftes, eine flache, ebene Fläche wie eine Plastikkarte mit gummierter, umrandeter und/oder holperiger Oberfläche, eine Spielunterlage (Gamepad), ein Steuerrad, ein Billard-Queue, eine Fernbedienung, die zum Steuern von Web-Seiten oder anderen Vorrichtungen verwendet wird, oder andere Gegenstände.
  • Wahlweise können andere Eingabevorrichtungen 141 in dem System 10 enthalten sein und Eingangssignale an den Mikroprozessor 130 und/oder Host-Computer 18 senden. Solche Eingabevorrichtungen können Tasten, Schalter, Wählscheiben, Knöpfe oder andere Steuerungen sein, die zur Ergänzung der Eingabe von dem Benutzer an ein Anwendungsprogramm verwendet werden. Auch Hardware zur Spracherkennung (mit vom Host 18 implementierter Software) oder andere Eingabemechanismen können verwendet werden. Vorzugsweise ist in der Schnittstellenvorrichtung ein Sicherheits- oder ”Totmann”-Schalter 150 enthalten, um einen Mechanismus bereitzustellen, der es einem Benutzer ermöglicht, die Aktuatoren 64 aus Sicherheitsgründen auszuschalten. Der Benutzer muß den Sicherheitsschalter 150 während der Betätigung des Benutzergegenstands ständig schließen, um die Aktuatoren 64 zu aktivieren. Zum Abfühlen, ob der Benutzer tatsächlich mit dem Benutzergegenstand in Kontakt ist, kann ein kapazitiver Kontaktsensor, mechanischer Schalter, elektrostatischer Kontaktschalter oder optischer Schalter, ein z-Achsen-Kraftmeßfühler, piezoelektrischer Meßfühler, kraftempfindlicher Widerstand, ein Dehnungsmesser oder ein Handgewicht-Sicherheitsschalter verwendet werden.
  • Force-Feedback-Architektur des Host-Computers
  • In der vorliegenden Erfindung steht der Host-Computer 18 in Dialog mit der Schnittstellenvorrichtung 11 und benutzt dazu eine Reihe von unterschiedlichen Ebenen von Steuereinheiten. Diese Steuereinheiten sind vorzugsweise in der Software implementiert, z. B. Programmbefehle oder Codes, und so ist es auch bei der hier beschriebenen Ausführungsform; die Steuereinheiten können jedoch auch ganz oder teilweise in der Hardware implementiert sein, wobei die Funktionalitätsumsetzung von Software in Hardware Fachleuten auf diesem Gebiet gut bekannt ist. Die hier beschriebene Architektur ist auf die Bereitstellung einer Kraftrückkopplungsfunktion für ein System ausgerichtet, das einen mit einer Force-Feedback-Schnittstellenvorrichtung verbundenen Host-Computer aufweist, wobei die Schnittstellenvorrichtung Kraftinformationen vom Host speichert und Steuerbefehle zur Implementierung von Kräften basierend auf den gespeicherten Informationen von dem Host erhält. Die beschriebene Architektur ist überaus geeignet für Computer wie einen PC, Macintosh, Arbeitsplatzrechner (Workstation) etc. und ist nicht so geeignet für andere Host-Computer wie Konsolenspielsysteme. Solche anderen Systeme weisen jedoch oft äquivalente Steuerebenen zu vielen der beschriebenen Steuerebenen auf. Beispielsweise kann ein Spielprogramm auf einer Konsole als Anwendung betrachtet werden und eine Bibliothek auf der Konsole, auf die Funktionsaufrufe von dem Spielprogramm zugreifen, kann das Äquivalent der Anwendungsprogramm-Schnittstelle (API) und/oder Übersetzungsebenen sein.
  • 2 ist ein Blockdiagramm einer bevorzugten Architektur für den Host-Computer zur Kommunikation mit einer Force-Feedback-Schnittstellenvorrichtung 11 und deren Steuerung. Auf dem Host-Computer 18 können ein oder mehr Anwendungsprogramme 202 und 204 laufen (gleichzeitig, falls mehr als eine Anwendung in Betrieb ist). Falls mehr als eine Anwendung in Betrieb ist, läuft eines der Anwendungsprogramme aktiv in einem Betriebssystem als ”aktives” Anwendungsprogramm (auch bekannt als Anwendungsprogramm, das ”im Brennpunkt” steht oder das ”Tastaturzentrum” aufweist). Auf einer graphischen Benutzeroberfläche (GUI) ist das aktive Fenster typischerweise das zuoberst angezeigte Fenster, in das die Eingabe des Benutzers unter Verwendung des mausgesteuerten Positionsanzeigers, einer Tastatur oder anderen peripheren Vorrichtung bereitgestellt wird. Die anderen Anwendungen sind insofern ”inaktiv”, als sie keine Eingabe vom Benutzer empfangen (obwohl ein Fenster davon in der GUI angezeigt sein kann, das auf dem Bildschirm aktualisiert werden kann). Die inaktiven Anwendungen können auch von anderen Quellen, z. B. peripheren Geräten, Eingaben empfangen oder Ausgaben senden. Beispielsweise stellt das Betriebssystem WindowsTM von Microsoft Corp. eine Multitaskbetrieb- oder Pseudomultitaskumgebung bereit, in der Programme gleichzeitig ablaufen; auch andere Betriebssysteme wie Unix bieten Multitaskbetrieb. Beispielsweise kann ein Textverarbeitungssystem die aktive Anwendung sein und Eingaben von der Tastatur erhalten sowie eingegebene Zeichen in einem angezeigten aktiven Fenster auf dem Bildschirm 20 anzeigen, während ein inaktives Kommunikationsprogramm gerade Daten über ein Netzwerk empfängt und die Daten in einer Speichervorrichtung speichert oder Daten zum Drucken herausschickt. Wenn der Benutzer den Positionsanzeiger über ein inaktives Fenster bewegt und eine Befehlsgeste macht, wie z. B. das Anklicken einer Taste auf einer Maus, wird das inaktive Fenster zum aktiven Fenster und das frühere aktive Fenster wird inaktiv. Alternativ kann das aktive Anwendungsprogramm die Steuerung des ganzen Bildschirms übernehmen; beispielsweise kann ein aktives Spielprogramm seine Umgebung ausschließlich auf einem Vollbildschirm anstatt in einem Fenster der GUI anzeigen. Im Gegensatz zu den nachstehend beschriebenen Hintergrundanwendungen sind die aktiven und inaktiven Anwendungen auch als ”Vordergrund”-Anwendungen bekannt.
  • Auf dem Host-Computer 18 kann auch eine Hauptanwendung 206 laufen, auf die als ”Hintergrund”-Force-Feedback-Anwendung Bezug genommen wird. Diese Anwendung ist vorzugsweise ein Allzweckprogramm, das immer inaktiv im Betriebssystem läuft und dessen Sammlung angewiesener Kräfte immer zur Ausgabe und Steuerung an der Schnittstellenvorrichtung 11 und/oder anderen Vorrichtungen verfügbar ist. Ein Beispiel für ein Schnittstellenfenster für eine Hauptanwendung ist ein ”Schreibtisch”-Bedienungsfeld zur Kraftrückkopplung. Die möglichen Arten von Kräften, die das Gerät ausgeben kann, sind in den US-Patenten Nr. 6,020,876 und 5,734,373 näher beschrieben.
  • Die von der Hintergrundanwendung bestimmten Kraftempfindungen werden standardmäßig von der Kraftrückkopplungsvorrichtung ausgegeben, außer ein anderes Vordergrund-Anwendungsprogramm deaktiviert die Kraftempfindungen oder ersetzt eine Kraftempfindung durch eine eigene. Beispielsweise wird auf alle Menüs aller in der GUI laufenden Anwendungsprogramme vorzugsweise eine hintergrundspezifizierte Schlagkraft angewendet, da dies ein Hintergrund-Krafteffekt ist. Falls das vordergrundaktive Anwendungsprogramm eigene Kraftempfindungen aufweist, die definieren, daß die Menüs dieser Anwendung einen Stoß anstelle eines Schlages aufweisen sollen, dann wird der Stoß über den Schlag gelegt, bis das aktive Anwendungsprogramm die Hintergrundkraft/-kräfte deaktiviert. Im allgemeinen kann ein bestimmtes aktives Anwendungsprogramm nur Kräfte auf seine eigenen Objekte steuern, z. B. eigene Menüs, Fenster, Rollbalken, Icons (Bildsymbole), Fensterränder etc. dieser Anwendung.
  • Ein Benutzer kann mehrfache Hintergrund-Kraftempfindungen für jedes graphische Objekt festlegen. Dies ermöglicht das Übereinanderlegen der Mehrfach-Kraftempfindungen, bis das Anwendungsprogramm eine oder mehr der überlagerten Kräfte außer Kraft setzt. Auf diese Weise kann ein Benutzer den Rollbalken eine Dämpfungskraftempfindung und eine ”Teilungs”-Kraftempfindung zuweisen, und allen Rollbalken bleiben diese Kräfte zugeordnet, bis sie vom Vordergrund-Anwendungsprogramm außer Kraft gesetzt werden. Andere Steuerungen in der Hintergrundanwendung können eine Geräteverbesserung zur Einstellung des Prozentsatzes der Maximalgröße für alle Kräfte der Hintergrundanwendung beinhalten.
  • Die Anwendungsprogramme 202, 204 und 206 kommunizieren mit einer Schnittstelle für das Programmieren von Kraftrückkopplungsanwendungen (”API”) 208, die im Hauptspeicher des Host-Computers ständig gespeichert ist und einem gegebenen Anwendungsprogramm die Kommunikation mit niedrigeren Treibern und anderen Force-Feedback-Funktionen ermöglicht. Im Betriebssystem Windows werden APIs beispielsweise üblicherweise dazu eingesetzt, um es einem Entwickler eines Anwendungsprogramms zu ermöglichen, Funktionen auf einer höheren Ebene zur Verwendung mit dem Anwendungsprogramm abzurufen, ohne sich um die niedrigeren Details beim tatsächlichen Implementieren der Funktion zu kümmern.
  • Die API der vorliegenden Erfindung weist eine Reihe von Software-”Objekten” auf, die zum Steuern einer Force-Feedback-Schnittstellenvorrichtung 11 aufgerufen werden können. Die Objekte sind eine Reihe von Befehlen und/oder Daten, die von einem Zeiger und/oder Feldnamen und Parametern zur Implementierung einer bestimmten Funktion aufgerufen werden können. In einer bevorzugten API-Implementierung sind beispielsweise drei Arten von Objekten vorgesehen: Schnittstellenobjekte, Geräteobjekte und Effektobjekte. Jedes dieser Objekte macht von einem oder mehr Force-Feedback-Gerätetreibern Gebrauch, die als Objekte in der API 208 implementiert sind.
  • Schnittstellenobjekte stellen die API an der höchsten Ebene dar. Ein Anwendungsprogramm (auf das als ”Client” der API Bezug genommen wird) kann ein Schnittstellenobjekt generieren, um auf niedrigere Objekte und Codes zuzugreifen und diese Force-Feedback-Gerätefunktionalität zu implementieren. Beispielsweise ermöglicht es das Schnittstellenobjekt einem Anwendungsprogramm, Informationen über einzelne Vorrichtungen einzeln aufzuführen und zu empfangen und niedrigere Objekte für jede von dem Anwendungsprogramm benutzte Vorrichtung zu erzeugen.
  • Geräteobjekte stellen jeweils eine körperliche Kraftrückkopplungsvorrichtung (oder andere kompatible Vorrichtung oder periphere Vorrichtung) dar, die mit dem Host-Computer 18 in Verbindung steht. Die Kraftrückkopplungsvorrichtung 11 wäre beispielsweise als ein einziges Vorrichtungsobjekt dargestellt. Die Geräteobjekte greifen auf die Anordnung von Force-Feedback-Routinen zu, um Informationen über ein zugeordnetes körperliches Gerät zu erhalten, die Merkmale des körperlichen Gerätes festzulegen, Ereignissteuerprogramme zu verzeichnen (falls Ereignisse auf dem Host implementiert sind) und Effektobjekte zu erzeugen.
  • Effektobjekte stellen jeweils eine vom Anwendungsprogramm definierte Kraftrückkopplungswirkung dar, die unter Verwendung einer Kraftrückkopplungsvorrichtung ein- oder mehrmals an den Benutzer ausgegeben werden soll. Die Effektobjekte greifen auf die Reihe von Force-Feedback-Routinen zu, um Krafteffekte auf die Kraftrückkopplungsvorrichtung herunterzuladen, die Ausgabe von Krafteffekten durch die Kraftrückkopplungsvorrichtung zu starten und zu beenden sowie die Parameter der Effekte zu modifizieren.
  • Ein ”Krafteffekt”, wie er hierin genannt ist, ist eine Definition für eine Kraft oder eine Serie von Kräften, die innerhalb der API gesteuert werden können. Der Krafteffekt hat typischerweise einen Namen (Feldname) zu seiner Identifizierung und einen oder mehr Parameter zur Charakterisierung des wunschgemäßen Krafteffektes. Es sind beispielsweise mehrere Arten von Krafteffekten definiert, darunter Vibrationen, Einfassungen, Gitter, Strukturen, Wände, Dämpfungseinrichtungen, Schlagempfindungen, Schwingungen, Kreise, Ellipsen etc.. Ein Vibrationskrafteffekt kann beispielsweise die Parameter Dauer, Frequenz, Größe und Richtung aufweisen. Die an den Benutzer ausgegebenen Kraftempfindungen können von einem oder mehr Krafteffekten abgeleitet sein (z. B. können Krafteffekte übereinandergelegt sein). Krafteffekte wiederum können auch aus einem oder mehr Basiskraft-Prototypen bestehen, so z. B. Federn, Dämpfungseinrichtungen und Vektorkräfte.
  • In einigen Ausführungsformen steht ein Client-Anwendungsprogramm mit der API 206 in Dialog, indem es zuerst einen Hinweis auf eine speicherresidente Force-Feedback-Schnittstelle erhält; beispielsweise weist eine bevorzugte Schnittstelle Verfahren auf, die vom Komponentenobjektmodell (COM) von Microsoft Windows spezifiziert sind, einem objektorientierten Modell zum Konstruieren von Schnittstellen (Ausführungsformen, in denen der Host-Computer 18 beispielsweise ein Konsolenspielsystem ist, können andere Software-Architekturen verwenden). Das Anwendungsprogramm führt die Kraftrückkopplungsvorrichtungen unter Verwendung der Force-Feedback-Schnittstelle einzeln auf dem Rechnersystem 18 auf. Das Anwendungsprogramm wählt eine gewünschte der Kraftrückkopplungsvorrichtungen aus und erzeugt ein dieser Vorrichtung zugeordnetes Geräteobjekt. Unter Verwendung der Force-Feedback-Schnittstelle erfaßt dann die Anwendung die Vorrichtung, rüstet die Vorrichtung mit Installations- und Standardparametern aus und erzeugt Effektobjekte und Ereignisobjekte während der Ausführung des Anwendungsprogramms zu Zeiten, die vom Entwickler der Anwendung bestimmt werden. Zu gegebener Zeit steuert das Anwendungsprogramm dann die Erstellung/Löschung von Krafteffekten und Anfang, Ende oder Pause der Wiedergabe von Krafteffekten durch Zugriff auf die entsprechenden Schnittstellenbefehle, die dem gewünschten Effekt zugeordnet sind. Falls zweckmäßig (siehe unten), kann die API einen Kontexttreiber 210 darauf hinweisen, einen ”Sinnzusammenhang” (d. h. ”Effekt-Satz”) für ein Anwendungsprogramm zu erstellen und sendet Effekte und Ereignisse zum Zuordnen zu diesem Kontext. Ein ”Kontext” ist eine Gruppe oder Anordnung von Effekten und Ereignissen, die einem bestimmten Anwendungsprogramm zugeordnet sind.
  • In Ausführungsformen mit der Möglichkeit, mehrerlei Anwendungsprogramme zugleich auf dem Host laufen zu lassen, kann jedes Anwendungsprogramm seinen eigenen Satz von Kraftempfindungen zur Ausgabe an die Kraftrückkopplungsvorrichtung aufweisen. Da die Vorrichtung infolge Kosten- und Hardwarebeschränkungen nicht alle Kraftempfindungen zur gleichen Zeit realisieren kann, müssen die von jeder Anwendung angewiesenen Kräfte von der Architektur organisiert werden, um diesen Einschränkungen Rechnung zu tragen.
  • Der Kontexttreiber 210 wird zur Implementierung von Krafteffekten für mehrerlei Anwendungsprogramme verwendet. Der Kontexttreiber 210 erhält Kontexte 222 und Gerätemanipulations- bzw. Vorrichtungsbetätigungsdaten 223 von der API 208. Der Kontexttreiber ist auf einer Ebene unter der API vorgesehen, um Kontexte für die auf dem Host-Computer laufenden Anwendungen 202 und 204 zu organisieren. In der bevorzugten Ausführungsform sind die Effekte und Ereignisse in einem Kontext dem Anwendungsprogramm selbst nicht bekannt; vielmehr erstellt der Kontexttreiber 210 einen Kontext für eine Anwendung intern. Eine Anwendung gibt also den Steuerbefehl, daß eine bestimmte Kraftempfindung als Reaktion auf unterschiedliche Wechselwirkungen oder Vorkommnisse, z. B. einen Dialog eines Positionsanzeigers mit einem Gegenstand oder Bereich, ausgegeben wird, oder bestimmt die Ausgabe einer Kraft basierend auf anderen Kriterien (Zeit, empfangene Daten, Zufallsereignis etc.). Die API sendet den/die angewiesenen Effekt(e) zum Kontexttreiber 210, und der Kontexttreiber speichert die Effekte in dem für dieses Anwendungsprogramm erstellten Kontext.
  • Da jede Anwendung eine ganz unterschiedliche Gruppe von Krafteffekten auszugeben haben kann, muß jeder Kontext mit seinem bestimmten Anwendungsprogramm verbunden sein. In der bevorzugten Ausführungsform gibt es zwei Kontextarten: Vordergrundkontexte und Hintergrundkontexte. Ein Vordergrundkontext ist dem momentan im Betriebssystem aktiven Anwendungsprogramm 202 oder 204 zugeordnet. Andere Vordergrundkontexte können die Effekte und Ereignisse für inaktive Anwendungsprogramme enthalten. Ein Hintergrund-(Primär)-Kontext enthält Effekte für das Hauptanwendungsprogramm 206. Darüber hinaus kann ein ”Globalkontext” vorgesehen sein, der fast immer von Anwendungsprogrammen verwendete allgemeine Effekte enthält (z. B. ein Puffkraft) und automatisch auf die Kraftrückkopplungsvorrichtung heruntergeladen werden kann. Effekte aus dem Globalkontext brauchen nicht in einzelnen Kontexten für bestimmte Anwendungsprogramme gespeichert werden.
  • Wenn ein Anwendungsprogramm zum ersten Mal durch den Host-Computer ausgeführt und in den Speicher geladen wird, wird die Anwendung, wenn sie zum Steuern einer Kraftrückkopplungsvorrichtung in der Lage ist, nach der API 208 fragen. Sobald die Verbindung errichtet ist, kontaktiert die API den Kontexttreiber 210, um eine Einsprungstelle für ein Kontext-Set für das initiierte Anwendungsprogramm zu schaffen.
  • Der Kontexttreiber 210 empfängt einzelne Effekte und Ereignisse, wie sie vom Anwendungsprogramm unter Verwendung der API 208 erzeugt werden und speichert die Effekte und Ereignisse in einer Kontextliste 212, wobei jeder Kontext in einem anderen Speicherelement im Host-Speicher oder in irgendeiner anderen Art Speichervorrichtung gespeichert wird. Ein Kontext kann von einem aktiven oder inaktiven Anwendungsprogramm erstellt und gespeichert werden, aber nur der Kontext der aktiven Anwendung wird zur Kraftrückkopplungsvorrichtung gesendet. Der Kontexttreiber 210 kann einen Feldnamen in einem erzeugten Effekt oder Ereignis prüfen, um zu bestimmen, welches Anwendungsprogramm damit verbunden ist und auf diese Weise den Effekt oder das Ereignis an der richtigen Speicherstelle speichern. Der Kontexttreiber setzt Ablesemarken auf die Kontexte sowie auf die Effekte und Ereignisse in den Kontexten, um darauf zuzugreifen. Ein Effekt kann ganz am Anfang erstellt werden, wenn das Anwendungsprogramm zum ersten Mal ausgeführt wird, bevor irgendwelche Kräfte befohlen werden, oder der Effekt kann später während der Anwendungsausführung erzeugt und dann sofort zur Wiedergabe durch die Kraftrückkopplungsvorrichtung angesteuert werden. Jeder Kontext weist vorzugsweise auch einen Eingang in eine Gerätestatusstruktur auf. Dieser Eingang beherrscht den ”Zuwachs” oder Kraftpegel für alle Effekte in dem Kontext. Beispielsweise können alle Kräfte in dem Kontext auf 50% ihrer vollen Größe beschnitten werden, indem ein Wert von 50 in der Gerätestatusstruktur gespeichert wird. Einer der in der Liste 212 gespeicherten Kontexte 214 ist ein Primärkontext 216, der die Liste von Effekten und Ereignissen darstellt, die von der Hauptanwendung 206 oder ”Hintergrund”-Anwendung verwendet werden.
  • Zu einem späteren Zeitpunkt, nachdem der Kontexttreiber die Kontexte in der Liste 212 gespeichert hat, kann ein Anwendungsprogramm die API anweisen, eine bestimmte Kraftempfindung auszugeben oder ”abzuspielen”. Die API überprüft, ob das Anwendungsprogramm aktiv oder im Hintergrund (primär) ist; falls nicht, sendet die API keinerlei Daten an die Vorrichtung und/oder den unteren Treiber. Alternativ können die Steuerbefehle von einer inaktiven Vordergrundanwendung gespeichert und dann an die Vorrichtung gesendet werden, wenn die Anwendung aktiv wird. Falls die Anwendung aktiv oder Hintergrund ist, sendet die API die Startinformationen zum Kontexttreiber 210 und gibt das Anwendungsprogramm an, das den Steuerbefehl für die Kraft erteilt hat und die bestimmten Krafteffekte, die anzuweisen sind. Der Kontexttreiber 210 verbindet dann das befehlende Anwendungsprogramm mit einem Kontext 214 in Liste 212 und sendet die Effekte aus dem Kontext an die Kraftrückkopplungsvorrichtung (falls nicht schon vorher gesendet). Falls beispielsweise ein Kontext für ein bestimmtes Anwendungsprogramm einen Federeffekt, einen Dämpfereffekt und einen Vibrationseffekt beinhaltet und das Anwendungsprogramm befiehlt, die Vibration auszugeben, dann wählt der Kontexttreiber die an die Vorrichtung auszugebenden Vibrationseffekte aus. Die diesen Effekt beschreibenden Daten werden dann durch den Kontexttreiber 210 ausgegeben. In ähnlicher Weise kann das Anwendungsprogramm einen Steuerbefehl senden, um bestimmte Krafteffekte zu stoppen, die Effekte pausieren zu lassen, Statusinformationen von einem Effekt zu erhalten oder einen Effekt zu zerstören. Einige dieser Befehle werden nachstehend näher beschrieben. Daher ”glaubt” das Anwendungsprogramm, daß es als einziges die Kraftrückkopplungsvorrichtung benutzt, obwohl in Wirklichkeit der Kontexttreiber basierend auf der aktiven Anwendung einen bestimmten Satz aus einem Vielfach-Set von Krafteffekten verwendet. Als Auswirkung ergibt sich eine virtuelle Kraftrückkopplungsvorrichtung, die für jedes laufende Anwendungsprogramm reserviert ist.
  • Daher ist es für einen Kontext nur zulässig, Kräfte mit der Kraftrückkopplungsvorrichtung auszuüben, wenn dieser Kontext aktiviert ist, d. h. einem aktiven Anwendungsprogramm oder der Hintergrundanwendung zugeordnet ist. In der beschriebenen Ausführungsform kann immer nur ein Vordergrundkontext aktiv sein. Eine Anzahl von Hintergrundkontexten kann aber zugleich aktiv sein; jedoch gibt es eine geräteseitige Beschränkung der Anzahl von zu erzeugenden Hintergrundkontexten. Beispielsweise kann die Vorrichtung 11 nur immer das Erzeugen eines Hintergrundkontextes zulassen, was die bevorzugte Ausführungsform bildet. Falls daher ein inaktives (nicht im Brennpunkt stehendes) Vordergrundanwendungsprogramm befiehlt, eine Kraft auszugeben, wird die API den Steuerbefehl ignorieren, nachdem festgestellt wurde, daß die befehlende Anwendung nicht aktiv ist (oder der Steuerbefehl wird nur dann an die Vorrichtung gesendet, wenn jene Anwendung aktiv wird).
  • Wenn das aktive Anwendungsprogramm inaktiv wird (oder aus dem Host-Speicher entfernt wird) und eine unterschiedliche Anwendung aktiviert wird, dann zeigt die API dies dem Kontexttreiber 210 an, welcher dann den mit jenem Anwendungsprogramm verbundenen Kontext deaktiviert und die Effekte aus dem neu aktivierten Kontext zur Kraftrückkopplungsvorrichtung 11 lädt. Ebenso teilt die API dem Kontexttreiber mit, den zugeordneten Kontext zu aktivieren, wenn das ursprüngliche Anwendungsprogramm wiederum aktiv wird, und lädt die entsprechenden Effekte zur Kraftrückkopplungsvorrichtung.
  • Vom Kontexttreiber 210 werden auch Vorrichtungsbetätigungsdaten 223 empfangen. Diese Daten 223 werden, wie nachstehend beschrieben, dazu verwendet, einen allgemeinen Vorrichtungszustand an der Kraftrückkopplungsvorrichtung einzustellen, wobei diese Informationen unmodifiziert an die Translationsebene weitergegeben werden.
  • Manche Ausführungsformen können nicht gleichzeitig vielfache Anwendungsprogramme auf jede Steuerkraft zulassen; es ist nur eine aktive Anwendung möglich, die die Vorrichtung 11 nutzt. Beispielsweise kann in solch einer Implementierung ein Kraftrückkopplungsspiel auf dem Host laufen, wobei kein anderes Anwendungsprogramm zur Kraftsteuerung an der Vorrichtung 11 zugelassen wird. Bei solch einer Implementierung ist der Betrieb des Kontexttreibers 210 nicht erforderlich; Befehle von der API können direkt an die Translationsebene 218 weitergegeben werden, wie nachstehend beschrieben. In solch einem Fall würde die Translationsebene auf eine einzelne Kontextliste 220 zugreifen, d. h. daß die Bereitstellung von Vielfach-Kontexten 214 nicht erforderlich ist.
  • Die Translationsebene 218 leitet das Senden der Effekte an die Vorrichtung 11, empfängt Informationen von der Vorrichtung an den Host (in einigen Ausführungsformen) und hält eine Darstellung oder ein Speichermodell der Vorrichtung 11 aufrecht. Die Translationsebene 218 empfängt einen individuellen Effekt 219 für das aktive (oder Hintergrund-)Anwendungsprogramm und die Vorrichtungsbetätigungsdaten 223, die vom Kontexttreiber 210 gesendet werden (oder von der API 208, wenn kein Kontexttreiber 210 benutzt wird). Die Translationsebene stellt den Effekt von einer Kontextliste 220 einzelner Effekte 222 (die Liste 220 stellt einen Kontext 214 dar) bereit. In jedem Kontext 214 der Liste 212 wird eine unterschiedliche Kontextliste 220 bereitgestellt. Jeder Effekt 222 in der Liste 220 definiert eine Kraft oder Kräfteserie, die durch die Kraftrückkopplungsvorrichtung 11 am Benutzergegenstand 12 ausgegeben wird. Wenn diese Effekte durch die Anwendung auf die Vorrichtung 11 geladen (”erzeugt”) werden sollen, werden sie ausgewählt und Kopien durch die Translationsebene an die Vorrichtung abgegeben. Vorzugsweise wird jeder Effekt durch die Translationsebene abgegeben, sobald dieser von der Ebene 218 empfangen wird. Jeder in der Liste 220 gespeicherte und von der Translationsebene geprüfte Effekt ist an der Kraftrückkopplungsvorrichtung 11 verfügbar, d. h. der örtliche Mikroprozessor 130 würde den Effekt erkennen und fähig sein, den entsprechenden Effekt sofort, oder wenn die Bedingungen dies verlangen, auszugeben.
  • Wenn in einem Vielfach-Anwendungssystem eine aktive Anwendung inaktiv wird, wird die Translationsebene vom Kontexttreiber 210 angewiesen, die Effekte dieses Kontexts der bislang aktiven Anwendung von der Kraftrückkopplungsvorrichtung zu ”entladen”, (z. B. den Speicherplatz für diese Effekte als frei zu kennzeichnen), die Effekte der nun aktiven Anwendung zu empfangen und diese Effekte auf die Kraftrückkopplungsvorrichtung 11 zu laden (die Effekte für die Hintergrund- bzw. Primär-Anwendung werden vorzugsweise nie entladen).
  • Die Translationsebene handhabt vorzugsweise auch Ereignisse. Wenn beispielsweise eine Bildschirmposition von der Vorrichtung 11 empfangen wird, kann die Translationsebene überprüfen, ob irgendwelche Bedingungen/Auslöser der aktiven Ereignisse erfüllt sind. Falls dies zutrifft, wird eine Nachricht gesendet, die ggf. das zugeordnete aktive oder Hintergrundanwendungsprogramm erreicht. In alternativen Ausführungsformen kann der Mikroprozessor 130 in der Vorrichtung 11 Ereignisse überprüfen und über die Translationsebene 218 Mitteilungen über das Auftreten zum Anwendungsprogramm senden.
  • Die Translationsebene kann auch einen Vorrichtungszustand 224 im Speicher abspeichern. Vorrichtungsbetätigungsdaten 223 von der aktiven Anwendung und der Hintergrundanwendung bestimmen den Vorrichtungsszustand. Dies ist der Zustand, der von dem aktiven Anwendungsprogramm an die Vorrichtung angelegt werden soll, falls vorhanden. Beispielsweise kann eine Gesamtbedingung gespeichert sein, wie z. B. eine Einschaltung oder Ausschaltung für alle Kräfte, so daß bei Ausschaltung aller Kräfte durch die Vorrichtung keine Kräfte ausgegeben werden. Auch kann ein Gesamtzuwachs eingestellt werden, um alle Ausgabekraftgrößen auf einen gewünschten Pegel oder Prozentsatz der Maximalausgabe zu begrenzen.
  • Die Translationsebene gibt Vorrichtungsmitteilungen 225 (Befehle) an die Vorrichtung 11 mittels der nächsten Ebene ab. Die Mitteilungen können abzugebende Krafteffekte und/oder andere Informationen wie z. B. Vorrichtungs-Kennzeichnungsnummern oder Befehle vom Kontexttreiber für einen Effekt (Start, Stop, Pause, Rücksetzung, usw.) beinhalten. Die Translationsebene gibt die Mitteilungen 225 an den Vorrichtungstreiber 226 ab.
  • Der Vorrichtungskommunikationstreiber 226 kommuniziert direkt mit der Kraftrückkopplungsvorrichtung. Der Treiber 226 empfängt die Vorrichtungsmitteilungen 225 von der Translationsebene 218 und überträgt die Mitteilungen über den Bus 120, z. B. einen USB, in einer Form, die die Vorrichtung 11 ”verstehen” kann, direkt an die Kraftrückkopplungsvorrichtung. Der Treiber 226 wird in der bevorzugten Ausführungsform als Standard-Vorrichtungstreiber implementiert, um über solch einen seriellen Anschluß des Host-Computers 18 zu kommunizieren. In anderen Ausführungsformen können auch andere Treiberarten und Kommunikationsschnittstellen verwendet werden.
  • Speicherverwaltung von Krafteffekten
  • 3 veranschaulicht eine beispielhafte Datenstruktur für einen Krafteffekt. Ein wichtiger Aspekt der vorliegenden Erfindung ist, daß ein Modell oder eine Darstellung des Speichers 134 an der Vorrichtung 11 durch die Translationsebene (oder die API oder andere Treiber) auf dem Host-Computer 18 bereitgehalten wird. Dadurch weiß die Translationsebene genau, wenn ein Effekt auf die Vorrichtung 11 heruntergeladen und dort gespeichert werden kann und wenn dort nicht genügend Speicher vorhanden ist, um einen bestimmten Effekt abzuspeichern. Die Größe der Effektliste 220 auf dem Host-Computer sollte gleich (oder kleiner) dem verfügbaren Speicher für solch eine Liste in der Kraftrückkopplungsvorrichtung sein, so daß die Translationsebene weiß, wenn der Speicher der Kraftrückkopplungsvorrichtung voll ist. Falls der Speicher 134 voll ist, kann die Translationsebene die Ausgabe von zusätzlichen Effekten verzögern, bis genügend Speicherplatz verfügbar ist (vgl. z. B. die Effekt-Cache-Speicherung gemäß 7) oder den Effekt einfach nicht beachten.
  • Eine Beispiels-Datenstruktur 240 kann mehrere Felder beinhalten, wie z. B. die Dauer 242, die den Zeitrahmen des abzuspielenden Krafteffektes angibt, die Richtung 244, die die Richtung in einem oder mehreren Freiheitsgrad(en) der anzulegenden Kraft angibt, einen Hüllzeiger 246, der auf eine Hüll-Datenstruktur 248 zeigt, und einen Typzeiger 250, der auf eine Typ-Datenstruktur zeigt. Die Felder für die Dauer 242 und Richtung 244 können einfach einen oder mehrere, diesen Eigenschaften zugeordnete(n) Wert(e) speichern. Die Hüll-Datenstruktur 248 kann entweder null sein, falls der Krafteffekt keine Hülle (z. B. eine Bedingungskraft) verwendet, oder die Datenstruktur 248 kann mehrere Werte beinhalten, die eine ”Hülle” für eine periodische Welle definieren, wie z. B. Impulszeit 252, Impulspegel 254, Abklingzeit 256 und Abklinggrad 258. Die Wellengestaltung unter Verwendung solcher Parameter ist im US-Patent Nr. 5,959,613 näher beschrieben. Der Typzeiger 250 kann auf eine von vielfach möglichen, unterschiedlichen Datenstrukturen, abhängig vom Krafteffekttyp, hinweisen. Falls es beispielsweise ein konstanter Krafteffekt ist, wird auf die Datenstruktur 260 mit einem Größen-Parameter 262 hingewiesen, (welcher zugewiesen sein kann). Falls es ein periodischer Effekt ist, wird die Datenstruktur 264 herangezogen, die mit den Werten Größe 266, Versatz 268, Phase 270 und Periode 272 den periodischen Effekt definiert. Falls es ein Bedingungseffekt ist, wie z. B. eine Federung oder Dämpfung, dann wird die Datenstruktur 274 angesprochen, die Werte für Versatz 276, Totzeit 278, Konstante 280 (z. B. Federkonstante oder Dämpfungskonstante) und Sättigung 282 aufweist.
  • Wie durch 3 beispielhaft dargestellt, weisen unterschiedliche Krafteffekte unterschiedliche Speicherungsanforderungen auf. Einige Krafteffekte benötigen keine Speicherung von Hülldaten aus der Struktur 248, während einige periodische und konstante Effekte zusätzlich Platz erfordern, um die Hüll-Informationen zu speichern. Die Bedingungskrafteffekte benötigen einen anderen Speicherplatz für Daten in der Struktur 274 als konstante Krafteffekte für Daten in der Struktur 260. Da ein Modell des Gerätespeichers auf dem Host-Computer bereitgehalten wird, weiß der Host, wieviel Speicher an der Vorrichtung verfügbar ist, d. h. ob ein bestimmter Effekt von der Vorrichtung gespeichert werden kann oder nicht.
  • 4 veranschaulicht ein weiteres Beispiel einer Anordnung des in der Vorrichtung 11 vorgesehenen Gerätespeichers 134, der auf dem Host-Computer abgebildet ist. Ein Effektspeicherblock 300 kann im Speicher (sowohl Host als auch Gerätespeicher) abgelegt sein, um Daten zur Kennzeichnung von ausgeprägten Krafteffekten zu speichern. Jeder im Effektblock 300 abgespeicherte Krafteffekt besitzt die gleiche Größe. Beispielsweise kann gemäß 4 die Vorrichtung 11 sechs Krafteffekte im Block 300 speichern, nämlich einen Effekt auf jedem Effektplatz 302 eines Gitters. Jeder Effektplatz 302 hält einen Hinweis auf dem bestimmten, den Krafteffekt definierenden Parameter bereit. Der Parameter kann in einem Parameterblock 304 des Speichers 134 gespeichert sein. Da der Parameter für unterschiedliche Krafteffekte in Anzahl und Größe differieren kann, gibt es keine konstante Speicherplatzgröße in dem Parameterblock, die jedem Krafteffekt zugewiesen wäre. Vielmehr muß der von jedem Parametersatz beanspruchte Platzbedarf (z. B. der jeweilige Speicherversatz) erfaßt werden, so daß zusätzliche Parameter um vorhandene Parameter gespeichert werden können und es bekannt ist, wenn der Speicher voll ist. Des weiteren wird der Parameterblock 304 dazu verwendet, während der Wiedergabe eines Krafteffektes benutzte Arbeitswerte zu speichern; daher wird oft zusätzlicher Platz zu demjenigen, der zur einfachen Speicherung des Parameters erforderlich wäre, benötigt. In anderen Ausführungsformen können der Effektblock und der Parameterblock zu einem einzigen Speicherblock kombiniert werden, ähnlich der Ausführungsform für einen einzigen Kontext 220 gemäß 2. Beispielsweise können Parameter für einen Effekt direkt nach den Identifizierungsinformationen gespeichert werden.
  • Wie vorstehend erläutert, hält die Translationsebene auf dem Host-Computer vorzugsweise ein Modell des Gerätespeichers 134 bereit, um festzustellen, wo Parameter zu speichern sind und ob der Speicher voll ist. Anfänglich, z. B. beim Starten der Vorrichtung 11, fragt der Host vorzugsweise die Vorrichtung nach relevanten Informationen ab, um den Speicher abzubilden, wie z. B. die Größe der verfügbaren Effekt- und Parameterblöcke, ebenso die Anzahl von Effekten, die im Effektblock 300 (der je nach Vorrichtung 11 variieren kann) gespeichert werden können. Einige Vorrichtungen 11 können auch fähig sein, den Host zu informieren, wieviel Platz jedem Effektschlitz 302 zugewiesen werden muß, über Parameter für einen Effekt, und/oder wie die Verwendung von Parameterzeigern zu spezifizieren ist.
  • 5 ist ein Flußdiagramm zur Darstellung eines grundlegenden Speicherverwaltungsverfahrens 310 zur Verwendung mit einem einzigen Anwendungsprogramm und einer Kraftrückkopplungsvorrichtung. Dieses Verfahren wird vom Standpunkt eines einfachen Programms auf dem Host (hier allgemein als ”Treiber” bezeichnet) beschrieben, wie z. B. der Translationsebene, der API, einer Bibliothek (z. B. Bibliothekfunktionen und -verfahren) oder anderer Treiber, die jedoch in anderen Ausführungen auch auf anderen Ebenen der Host-Architektur implementiert sein können. Das Verfahren 310 kann verwendet werden, egal ob das Anwendungsprogramm das einzige Programm ist oder ob das Programm eines von vielen Programmen ist, die gleichzeitig auf dem Host laufen. Es sei angemerkt, daß die Reihenfolge der nachstehend beschriebenen Schritte nur zu erläuternden Zwecken angegeben wird und daß die verschiedenen Schritte, Überprüfungen und Ereignisse bei verschiedenen Ausführungen auch in unterschiedlicher Abfolge oder parallel (Multitaskbetrieb) erfolgen können. Beispielsweise können viele der Überprüfungen als Funktionsaufrufe oder Interrupts implementiert sein, wobei zugeordnete Schritte in einfacher Weise verarbeitet werden können, wenn diese unbeachtlich der jeweiligen Stufen anderer Abläufe aufgerufen werden.
  • Das Verfahren 310 beginnt bei 311. Im Schritt 312 erzeugt der Host 18 unter Verwendung von Informationen aus der Vorrichtung 11 ein Speichermodell. Beispielsweise kann ein Kontext 220 geschaffen werden, wie dies obenstehend mit Bezugnahme auf 2 erläutert wurde. Die in 4 verwendete Abbildung kann auch benutzt werden; auf dieses Modell bezieht sich die folgende Erläuterung. Wie obenstehend erklärt, kann die Vorrichtung dem Host 18 Informationen senden, wie z. B. die Größe des Speichers und Anzahl von Effekten, die gespeichert werden können.
  • Im Schritt 314 bestimmt das Verfahren, ob das Anwendungsprogramm (z. B. durch eine Funktionsaufforderung an die API oder Bibliothek) befiehlt, irgend welche Krafteffekte auf der Vorrichtung 11 zu erzeugen oder zu zerstören. Die Erstellung von solchen Effekten erfolgt typischerweise, wenn das Anwendungsprogramm zum ersten Male auf dem Host-Computer durchgeführt wird, kann aber auch zu anderen Zeiten während der Anwendungsausführung erfolgen. Wenn beispielsweise ein Spielprogramm zum ersten Male durchgeführt wird, besitzt das Programm einen Satz von Krafteffekten, welche dazu ausgelegt sind, von und mit dem Spiel verwendet zu werden. Das Spiel erzeugt typischerweise die Krafteffekte an der Vorrichtung 11 beim Starten des Spiels, so daß die Effekte sofort zur Ausgabe verfügbar sein werden. Unterschiedliche Effekte können auch später während des Spiels erzeugt werden, falls gefordert. Wenn eine GUI auf dem Host ausgeführt wird, kann die GUI sofort Hintergrund- bzw. Primär-Krafteffekte auf der Vorrichtung 11 schaffen, so daß solche Effekte sofort verfügbar sind.
  • Wenn die Anwendung im Schritt 314 nicht die Schaffung oder Beseitigung von Effekten an der Vorrichtung befohlen hat, schreitet das Verfahren zum Schritt 324 fort, wie nachstehend beschrieben. Falls die Anwendung die Erzeugung eines Effektes an der Vorrichtung wünscht, dann bestimmt der Host im Schritt 316, ob überhaupt Gerätespeicher verfügbar ist, um den Effekt zu speichern. Der Host-Treiber (z. B. die Translationsebene oder alternativ die API) prüft das Hostmodell des Gerätespeichers, um zu bestimmen, ob genügend Platz vorhanden ist. Vorzugsweise erfolgt die Prüfung des Host-Treibers auf genügend Platz sowohl im Effektblock 300 als auch im Parameterblock 304; dabei sollte in beiden Blöcken genügend Platz vorhanden sein. Falls dies nicht zutrifft, wird in Schritt 318 der Krafteffekt mißachtet, um nie benutzt zu werden; vorzugsweise wird das Anwendungsprogramm informiert, daß der Effekt nicht erzeugt werden konnte, d. h. daß der Erstellungsbefehl mißlungen ist (in einer alternativen Ausführungsform der vorliegenden Erfindung, die nachstehend beschrieben wird, kann der Effekt auch vom Host zwischengespeichert werden). Das Verfahren fährt dann mit Schritt 334 fort, wie nachstehend beschrieben. Falls genügend Speicher für den erstellten Effekt in Schritt 316 vorhanden ist, dann speichert der Host in Schritt 320 den Effekt in seinem Speichermodell und sendet auch einen oder mehrere Erstellungsbefehl(e) an die Vorrichtung, um den Effekt in den aktuellen Gerätespeicher zu laden. Es sei angemerkt, daß bei Ausführungsformen mit vielfachen bzw. gleichzeitig laufenden Anwendungsprogrammen die Vorrichtung 11 in ihrem Speicher eine Anzahl von standardisierten Effekten beinhalten kann, die implementiert werden können, falls diese Effekte innerhalb des aktiven oder Hintergrundkontextes stattfinden. Solche Effekte brauchen nicht vom Host heruntergeladen und in einem Effektschlitz gespeichert werden.
  • Als Beispiel werden nachstehend ein Befehlssatz und entsprechende Parameter angegeben, um einen periodischen Effekt an der Vorrichtung zu schaffen:
    SETZE_HÜLLE (offset1, Werte)
    SETZE_PERIODE (offset2, Werte)
    SETZE_EFFEKT (Effekt_index, Werte, flags, offset1, offset2)
  • Der SETZE_HÜLLE-Steuerbefehl liefert einen ”msg_id”-Wert, der seinen Steuerbefehltyp (Feldname) angibt. Der Offset-Wert ”offset1” gibt das sog. ”offset” im Parameterblock 304 an, bei dem die begleitenden Werte zu speichern sind. Die Werte können in diesem Beispiel die Hüllparameter in der in 3 gezeigten Datenstruktur 248 sein, wie z. B. Impulszeit, Impulspegel, Abklingzeit und Abklinggrad. Alternativ kann für andere Krafteffektarten (z. B. Bedingungen) der Hüllparameter null sein oder der Hüll-Steuerbefehl überhaupt nicht gesendet werden. Der SETZE_PERIODE-Steuerbefehl liefert in ähnlicher Weise einen Feldnamen und einen zweiten Offset-Wert ”offset2” (unterschiedlich vom ”offset1”), bei dem die Werte in dem Periodenbefehl zu speichern sind. Der Host 18 weiß daher, wieviel Speicherplatz von jedem Effekt und Parameter eingenommen wird und kann daher die entsprechenden ”offsets” bestimmen, bei denen die Effektdaten im Gerätespeicher zu speichern sind, ohne andere Werte zu überschreiben. Beispielsweise weiß der Host, wieviel Platz der Hüllparameter des SETZE_HÜLLE-Steuerbefehls einnimmt und kann damit das ”offset2” berechnen, um entsprechend im Parameterblock angesiedelt zu sein. Die Werte für einen periodischen Steuerbefehl können diejenigen sein, die in der Datenstruktur 264 der 3 als Beispiel gezeigt sind.
  • Der SETZE_EFFEKT-Steuerbefehl liefert die Daten, die in den Effektblock 300 des Gerätespeichers zu speichern sind. Nach einem Feldnamenwert gibt der ”Effekt_index”-Wert den Effektschlitz 302 an, in dem der Effekt gespeichert werden soll. Da der Host den Gerätespeicher abbildet, weiß der Host, welche Effektschlitze verfügbar sind, z. B. offen oder nicht mehr benutzt werden. Die Werte können diejenigen sein, die in der Struktur 240 der 3 als Beispiel gezeigt sind. Offset1 und Offset2 geben an, wo der Hüllparameter bzw. periodische Parameter im Parameterblock gespeichert sind (wenn diese Parameter nicht verwendet werden, dann können die Offset-Werte null sein).
  • Es sei angemerkt, daß der Host in seinem Speichermodell entweder die tatsächlichen Daten für den Effekt oder nur die Stelle und Größe des Speicherplatzes speichern kann, die dieser Effekt einnimmt. Dies ist so, da bei einer Grundausstattung der Host nur den verfügbaren Gerätespeicher nachverfolgt und die aktuellen Effektdaten nicht benötigt. In einer bevorzugten Ausführungsform speichert der Host jedoch die tatsächlichen Effektdaten in dem Speichermodell. In einigen Ausführungsformen erlaubt dies dem Host-Treiber, die Effektdaten zu prüfen und Entscheidungen darüber zu treffen, ob ein Steuerbefehl an die Vorrichtung zu senden ist. Beispielsweise kann die Anwendung befehlen, daß ein neuer Effekt zu erstellen ist, der eine periodische Welle mit einer Frequenz von 20 Hz ist. Der Host-Treiber könnte die Daten für die gegenwärtig geladenen Effekte in seinem Speichermodell prüfen und herausfinden, daß auf der Vorrichtung bereits eine periodische Welle mit einer Frequenz von 25 Hz geladen ist. Der Host-Treiber könnte dann entscheiden, daß die neue 20 Hz-Periode in Hinblick auf die 25 Hz-Periode redundant ist, und daher den Erstellungsbefehl ignorieren (und den 25 Hz-Effekt benutzen, wenn der 20 Hz-Effekt zum Spiel angefordert wird). Diese Art der Host-Treiber-Auslegung kann nur durchgeführt werden, wenn aktuelle Effektdaten in dem Host-Speichermodell gespeichert sind. Des weiteren muß diese Art der ”intelligenten” Effekt-Handhabung in Hinblick auf zusätzliche Verarbeitungszeit und die Absichten der Anwendungsentwickler abgewogen werden. Falls beispielsweise die Anwendung ”glaubt”, daß vielfache (redundante) Effekte in der Vorrichtung gespeichert sind und eine zusätzliche Kraftausgabe bereitstellen will, dann wird der Host-Treiber nicht einfach einen vorhandenen Effekt modifizieren, sondern sollte einen neuen Effekt erzeugen. Auch kann die bei der Effektspeicherung erreichte Effizienz in manchen Fällen nicht die zusätzliche Verarbeitungszeit für die intelligente Handhabung der Effekte wettmachen. Nach Schritt 320 schreitet das Verfahren zum Schritt 334 weiter, wie nachstehend beschrieben.
  • Wenn die Anwendung im Schritt 314 die Zerstörung eines Effektes befohlen hat, dann wird im Schritt 323 ein Effektschlitz im Host-Speichermodell freigemacht. In der bevorzugten Ausführungsform braucht in den meisten Fällen die Vorrichtung 11 nicht angewiesen werden, einen Effekt im Gerätespeicher zu vernichten; vielmehr können die alten Effektdaten in dem Gerätespeicher in einfacher Weise mit neuen Effektdaten überschrieben werden, wenn die neuen Daten zum Laden fertig sind. Der Host muß jedoch in seinem eigenen Speichermodell Speicherplatz freimachen, um zuzulassen, daß andere Effekte gespeichert werden können, und daher sollte der Treiber zur Effektzerstörung angewiesen werden, um die Effektdaten in dem Speichermodell zu löschen. Nach Erhalt eines Zerstörungs-Steuerbefehls weiß der Host-Treiber, daß der Schlitz des vernichteten Effektes verfügbar ist, um einen anderen Krafteffekt zu speichern, der in Zukunft durch das Anwendungsprogramm erstellt werden kann.
  • In manchen Fällen muß die Vorrichtung darüber informiert werden, daß ein Effekt vernichtet worden ist. Beispielsweise kann ein Auslöseeffekt in den Gerätespeicher geladen werden und eine Kraft abgeben, falls eine bestimmte Auslösebedingung auftritt, wie z. B. ein gedrückte Taste an dem durch einen Benutzer betätigbaren Gegenstand. Falls ein Auslöseeffekt in dem Gerätespeicher gespeichert ist und durch die Anwendung zerstört wurde, kann dieser Auslöseeffekt nicht einfach im Gerätespeicher verbleiben, bis dieser überschrieben wird, da eine Auslösebedingung auftreten kann, bevor die Auslösung überschrieben wurde; statt dessen muß die Vorrichtung sofort informiert werden, daß der Auslöseeffekt vernichtet oder entsprechend gekennzeichnet werden sollte. In ähnlicher Weise sollte die Vorrichtung sofort informiert werden, falls ein gerade gespielter Effekt zerstört werden soll, so daß diese den Effekt abschalten kann. Nach dem Schritt 323 fährt der Ablauf zum Schritt 334 weiter, wie nachstehend beschrieben.
  • Wenn im Schritt 314 kein Erstellungs- oder Zerstörungs-Steuerbefehl erhalten wird, prüft das Verfahren im Schritt 324, ob das Anwendungsprogramm auf dem Host eine Änderung eines Effektzustandes befiehlt. Hierbei ist ein Effektzustand der gegenwärtige Status des Effekts, z. B. ”Spielen”, ”Stop”, ”Pause” etc.. Falls kein Effektzustand angewiesen wird, fährt der Ablauf zum Schritt 334 weiter, wie nachstehend beschrieben. In einer bevorzugten Ausführungsform sind die Schritte 314 und 324 tatsächlich Funktionsaufrufe an die API und von dieser implementiert, welche jederzeit durchgeführt werden können, so daß die Schritte 314 und 324 nicht in der gezeigten Abfolge implementiert sein brauchen.
  • Wenn im Schritt 324 der befohlene Effektzustand ”Spiel” oder ”Start” (Ausgabe) eines bestimmten Krafteffektes an den Benutzer ist, dann wird im Schritt 326 ein entsprechender ”Spiel”-Steuerbefehl vom Host-Treiber an die Vorrichtung gesendet. Beispielsweise kann der Steuerbefehl SETZE_EFFEKT_ZUSTAND (Effekt_index, Zustand, Schleifen_Anzahl) sein. Der Effekt_index-Wert gibt den Schlitz in dem Effektblock im Gerätespeicher an und damit den bestimmten abzuspielenden Krafteffekt. Der Zustand-Wert gibt an, den bezeichneten Effekt zu ”spielen”. Der Schleifen_Anzahl-Wert kann wahlweise verwendet werden, um eine Anzahl zu bestimmen, wie oft die Vorrichtung das Abspielen des gesamten Krafteffektes wiederholen soll. Im Schritt 328 ”kennzeichnet” der Host (z. B. die Translationsebene) in seinem Speichermodell den Effekt (d. h. setzt ein Kennzeichen), so daß der Host weiß, welche Effekte gegenwärtig an der Vorrichtung abgespielt werden (die Vorrichtung kennzeichnet den Effekt ebenfalls, wie dies unter Bezugnahme auf 6 näher beschrieben wird). Das Verfahren kehrt dann zum Schritt 314 zurück.
  • Wenn im Schritt 324 ein Effektzustand angewiesen wird, das Abspielen eines bestimmten Krafteffektes zu stoppen, dann wird im Schritt 330 ein entsprechender Steuerbefehl vom Host zur Vorrichtung gesendet. Solch ein Steuerbefehl kann ähnlich sein wie der vorstehend beschriebene Wiedergabebefehl, außer daß der Status angibt, das Abspielen des bezeichneten Effekts zu stoppen. Im Schritt 332 wird der bezeichnete Effekt vom Host in seinem Modell des Gerätespeichers ”umetikettiert”, d. h. das Kennzeichen für den bezeichneten Effekt entfernt. Das Verfahren kehrt dann zum Schritt 314 zurück. In anderen Ausführungsformen können auch zusätzliche Änderungen der Effektzustände angewiesen werden, wie z. B. einen Krafteffekt pausieren zu lassen und wieder aufzunehmen etc..
  • Im Schritt 334 kann der Host prüfen, ob irgendein Abspieleffekt abgelaufen ist oder beendet wurde, z. B. ob ein Effekt in voller Länge abgespielt wurde. Die Vorrichtung verfolgt vorzugsweise die Effektdauer, da diese tatsächlich die Ausgabe der Kräfte implementiert. Um den Host vom Ablauf eines Effekts zu unterrichten, sendet die Vorrichtung vorzugsweise einen Zustandsbericht an den Host, welcher im Schritt 334 überprüft wird. In einigen Ausführungsformen kann der Host auch unabhängig davon die Dauer eines Krafteffektes für Speicherverwaltungszwecke nachverfolgen, d. h. es kann für den Host zweckmäßig sein, unabhängig zu bestimmen, wann das Abspielen eines Krafteffektes beendet ist, um bei der Bestimmung zu helfen, welche zwischengespeicherten Effekte geladen werden können. Des weiteren kann der Host seine aufgezeichneten Dauern wieder synchronisieren, falls festgestellt wird, daß die Host- und Vorrichtungsdauern nicht synchron sein sollten. Wenn kein Effekt abgeschlossen ist, kehrt das Verfahren zum Schritt 314 zurück. Falls zumindest ein Effekt abgelaufen ist, dann fährt der Ablauf zum Schritt 336 weiter, um den abgeschlossenen Effekt im Host-Speichermodell ”umzuetikettieren”. Das Verfahren kehrt dann zum Schritt 314 zurück.
  • Der Host kann auch Zustandsberichte von der Vorrichtung 11 in periodischen Intervallen erhalten und/oder wenn sich der Status von Krafteffekten und anderen Bedingungen ändert, wie z. B. daß ein Effekt mit Abspielen beginnt oder endet, ein Totmannschalter betätigt wurde, die Leistungsversorgung unterbrochen wurde etc..
  • 6 veranschaulicht ein auf der Vorrichtung 11 laufendes Verfahren 350, das bezeichnete Krafteffekte für die Vorrichtung erstellt und abspielt. Das Verfahren beginnt bei 351, und bei 352 prüft das Verfahren, ob es vom Host-Computer 18 einen Steuerbefehl erhalten hat. In der bevorzugten Ausführungsform ist das Vorrichtungsverfahren in Wirklichkeit durch ein ”Ereignis” oder eine Unterbrechung gesteuert, so daß bei Erhalt eines Host-Steuerbefehls ein Ereignis aufgetreten ist und die Vorrichtung dieses sofort verarbeiten wird, anstatt empfangene Befehle zu überprüfen. Zu beachten ist, daß diese Art von Ereignissen vom Host an die Vorrichtung geliefert wird, nicht von der Vorrichtung zum Host. (Die Vorrichtung kann auch Ereignisse an den Host senden, wie z. B. bei der Bewegung des Benutzergegenstands in einen Bereich, der einem graphischen Objekt entspricht, und Zustandsberichte an den Host in periodischen Intervallen oder wenn Ereignisse auftreten). Wenn im Schritt 352 kein Steuerbefehl vom Host empfangen wurde (z. B. falls kein Steuerbefehlereignis aufgetreten ist), dann fährt der Ablauf zum Schritt 362 weiter, wie nachstehend beschrieben.
  • Wenn ein Host-Steuerbefehl von der Vorrichtung erhalten worden ist und jener Steuerbefehl einen Krafteffekt an der Vorrichtung erstellt, dann schreibt das Verfahren im Schritt 354 die Effektdaten in den Gerätespeicher in den Effektschlitz, der vom Befehl bezeichnet wurde, d. h. der Feldname und die Parameter werden im Gerätespeicher 134 gespeichert. Beispielsweise kann der örtliche Mikroprozessor 130 den msg_id-Wert (Feldname) jedes Steuerbefehls analysieren, um den Befehlstyp zu bestimmen. Sobald die Vorrichtung den Befehlstyp kennt, weiß sie auch, wie jeder der nachfolgenden Parameter in dem Befehl zu speichern und zu verarbeiten ist. Daher weiß die Vorrichtung, daß der zweite Wert in dem SETZE_EFFEKT-Steuerbefehl den Effektschlitz in dem Effektblock 302 angibt, in dem die nachfolgenden Werte zu speichern sind. Die Vorrichtung weiß auch, wie die Werte an entsprechenden ”Offsets” zu speichern sind, die in den Perioden- und Hüll-Befehlen bereitgestellt werden. Der Ablauf fährt dann zum Schritt 362 weiter, wie nachfolgend beschrieben.
  • Wenn ein Steuerbefehl zum Ändern des Zustandes eines bereits auf der Vorrichtung erstellten Effektes empfangen wurde, dann analysiert das Verfahren im Schritt 356 den Steuerbefehl, um zu prüfen, ob der Steuerbefehl ein ”Abspiel”-Befehl ist. Wenn dies so ist, dann kennzeichnet die Vorrichtung im Schritt 358 den im Befehl bezeichneten Effekt. Das Kennzeichen ist ein Hinweis (wie z. B. ein ”flag”), daß der Effekt gespielt werden soll, um später vom Verfahren geprüft zu werden, wie nachstehend erläutert. Der Ablauf fährt dann zum Schritt 362 weiter.
  • Wenn der im Schritt 356 empfangene Steuerbefehl kein ”Abspiel”-Befehl ist, dann ist es ein ”Stop”-Steuerbefehl, um das Abspielen des bezeichneten Krafteffektes zu stoppen. In anderen Ausführungen können auch zusätzliche Befehle implementiert sein, wie z. B. ”Pause”, was das Abspielen eines Krafteffektes im gegenwärtigen Zustand unterbricht; nachdem ein ”Wiederaufnahme”- oder ”Pause-beenden”-Steuerbefehl erhalten wird, würde der Effekt von dem Punkt aus weiterspielen, an dem er gestoppt wurde, anstatt neu zu beginnen; oder ein ”Stop_alle”-Steuerbefehl, der das Abspielen aller Effekte beendet; oder ein ”Modifizier”-Befehl, der nur die Parameter eines vorher geladenen Effekts modifiziert. Im Schritt 360 markiert das Verfahren den im Befehl bezeichneten Effekt um, d. h. gibt an, daß der bezeichnete Effekt nicht abgespielt werden soll. Der Ablauf fährt dann zum Schritt 362 weiter.
  • Im Schritt 362 prüft das Verfahren, ob das Zeitintervall beendet ist, d. h. ob ein Zeitereignis aufgetreten ist. In der beschriebenen Ausführungsform der vorliegenden Erfindung arbeitet die Vorrichtung gemäß einem Zeitintervall, das von einem Taktgeber gemessen wird. Bei jedem Zeitintervall sollte die Vorrichtung 11 eine Kraft pro Intervall abgeben, wie dies für jeden abgespielten Krafteffekt vorgesehen ist. Beispielsweise kann das Zeitintervall 1 Millisekunde betragen, wenn von der Vorrichtung erwartet wird, daß jegliche erforderliche Information und Kraftausgabe an den Benutzergegenstand 12 jede Millisekunde bearbeitet wird. Wenn das Millisekunden-Zeitintervall vorbei ist, wird dies als ein Ereignis betrachtet, das den Mikroprozessor veranlaßt, eine Kraft abzugeben. Wenn daher im Schritt 362 kein Zeitintervall abgelaufen ist, kehrt das Verfahren zum Schritt 352 zurück, z. B. fährt der Mikroprozessor fort, auf ein Ereignis zu warten, wie z. B. einen Steuerbefehl oder ein Zeitintervall. Bevor das nächste Ereignis auftritt, kann die Vorrichtung andere Aufgaben durchführen, wie z. B. den Betrieb bis zum nächsten Ereignis aufschieben, eingegebene Meßfühler-Werte verarbeiten, die nächsten Kräfte berechnen, Mitteilungen an den Host-Computer aufbauen und senden und/oder die Kraftausgabe von den Aktuatoren aktualisieren.
  • Wenn ein Zeitintervall abgelaufen ist, dann sollte eine Kraft abgegeben werden und das Verfahren zum Schritt 363 weiterfahren, um die Implementierung der Kraftausgabe zu starten. Im Schritt 363 wird eine Variable N auf 1 gesetzt. N weist auf den Index oder Schlitz eines Effektes im Effektblock des Gerätespeichers hin. Im Schritt 364 prüft das Verfahren den Effekt(N), d. h. den am Schlitz(N) gespeicherten Effekt. Wenn im Schritt 366 der überprüfte Effekt dazu bestimmt wurde, ummarkiert zu werden, dann wird N in Schritt 368 inkrementiert. Im Schritt 370 prüft das Verfahren, ob N > M, wobei M die Anzahl von Effekten ist, die die Vorrichtung 11 speichern kann. Wenn N > M, dann wurden alle Effekte überprüft, und der Ablauf fährt zum Schritt 372 weiter, wie nachstehend erläutert. Wenn N nicht größer als M ist, dann prüft das Verfahren im Schritt 364 den nächsten Effekt im Gerätespeicher. Für ein alternatives Verfahren zum Prüfen von Effekten im Speicher wird auf die ”Spielliste” der Ausführungsform gemäß 10 hingewiesen.
  • Wenn im Schritt 366 bestimmt wurde, daß der Effekt(N) markiert wird, dann berechnet der Geräte-Mikroprozessor 130 im Schritt 374 eine Kraft basierend auf den Daten für den Effekt(N), z. B. die Parameter wie Größe, Richtung und dergleichen. Der Mikroprozessor 130 kann dazu örtlich gespeicherte Kraftprozesse, Kraftalgorithmen, gespeicherte Kraftgrößen, Raum- und/oder Zeitfunktionen, eine Historie von gespeicherten Bewegungswerten des Benutzergegenstands und/oder andere Befehle verwenden, um die Kraft zu berechnen, wie dies obenstehend unter Bezugnahme auf 1 erläutert wurde. Beispielsweise kann der Mikroprozessor die Grobverteilung der Ausgabekraft vom Effekt berechnen und einen Hüllmaßstab (detailliert im US-Patent Nr. 5,959,613 ) anlegen. Im Schritt 376 wird die berechnete Kraft zu einer Summe von für die anderen Abspieleffekte berechneten Kräften addiert. Bei der Bestimmung der Gesamtsumme kombiniert die Vorrichtung vorzugsweise alle konstanten Kräfte (z. B. Bedingungen und zeitbasierte Kräfte) und begrenzt die konstante Kraftsumme auf eine vorbestimmte Größe, kombiniert dann alle dynamischen Kräfte und begrenzt die dynamische Kraftsumme auf eine vorbestimmte Größe. Die dynamischen Kräfte sind jene Kräfte, die auf einer simulierten, mit dem Benutzergegenstand gekoppelten Masse in einem simulierten körperlichen System basieren. Die beiden Summen werden dann zusammengezählt und die Gesamt-Kraftsumme von den Aktuatoren der Vorrichtung 11 abgegeben. Alternativ können alle Kräfte gleich behandelt und zusammengerechnet werden. Des weiteren können die Schritte 374 und 376 zusammen abgearbeitet werden oder beim Bestimmen der Effektkraft und der Gesamtkraft vermischt werden.
  • Im Schritt 378 werden jegliche Arbeitswerte im Parameterblock 304 aktualisiert. Beispielsweise können solche Werte einen Zeitwert beinhalten, der die Zeitdauer angibt, die für den gegenwärtigen Krafteffekt verstrichen ist. Falls der Mikroprozessor 130 bestimmt hat, daß der Zeitwert für den Effekt das Zeitdauerlimit für den Effekt erreicht hat, markiert der Mikroprozessor 130 vorzugsweise den Effekt um, so daß dieser nicht länger abgespielt wird. Die Parameter für den Effekt können auch aktualisiert werden, falls ein Steuerbefehl dies gefordert hat. Nach Schritt 378 fährt der Ablauf zum Schritt 368 weiter, wo N inkrementiert wird, und dann zum Schritt 370, wo N mit M verglichen wird, wie oben beschrieben, um zu bestimmen, ob alle Effekte in dem Gerätespeicher geprüft worden sind. Falls N > M, wird Schritt 372 implementiert, wo die Gesamtkraft durch die Vorrichtung an den Benutzer abgegeben wird. Die Gesamtkraft ist die Summe aller Kräfte, die von allen spielenden Krafteffekten beigesteuert werden. Das Verfahren gibt Kraftsignale an einen oder mehrere Aktuator(en) ab, um eine Kraft in die entsprechende Richtung mit der entsprechenden Größe anzulegen. Das Verfahren kehrt dann zum Schritt 352 zurück, um auf das nächste Steuerbefehlereignis zu warten oder in Schritt 353 auf das nächste Zeitintervall. Die Vorrichtung sendet auch vorzugsweise Zustandsberichte über den Status von Effekten an den Host, wobei diese Zustandsberichte periodisch und/oder bei Statusänderung eines Effektes gesendet werden. Selbstverständlich werden auch andere Daten und Bedingungen der Vorrichtung an den Host berichtet (Meßfühlerdaten, Tastaturdaten, ob Leistung erhalten wird, Zustand des Totmannschalters, etc.), welche im Verfahren 350 nicht näher dargestellt sind.
  • Die mit Bezug auf 5 und 6 beschriebenen Verfahren sind sehr effizient. Da der Host die Speicherausstattung und was gegenwärtig dort gespeichert ist, kennt, braucht der Host nur einen Steuerbefehl senden, um neue Effekte zu laden; der Host weiß bereits, wann Effekte erstellt werden können oder nicht. In früheren Ausführungsformen müßte der Host die Vorrichtung fragen und auf eine Antwort von der Vorrichtung warten, ob ein Effekt erstellt werden könnte, wodurch Kommunikation und Reaktion der Vorrichtung verlangsamt werden und möglicherweise Verwirrung stiften, wenn Mehrfach-Anwendungsprogramme laufen und Kräfte anweisen.
  • Ein Aspekt der vorliegenden Erfindung betrifft das Zeitintervallereignis und dessen Implementierung, wie oben für den Schritt 353 beschrieben. Eine Art zur Implementierung des Zeitintervalls ist die Wahl einer ausreichend langen Zeitspanne, die es dem Mikroprozessor ermöglicht, eine beliebige potentiell benötigte Berechnung durchzuführen und dabei noch bei jedem Zeitintervall eine Kraft auszugeben. Eine andere Implementierung der vorliegenden Erfindung kann ein kleineres Zeitintervall bereitstellen, das gewöhnlich lang genug ist, um eine Kraftausgabe bei jedem Intervall zu ermöglichen, aber unter bestimmten Umständen eine ungenügende Länge haben kann. Falls das Zeitintervall in einem bestimmten Fall zu kurz ist, wartet der Mikroprozessor 130 mit der Ausgabe der Kraft dann vorzugsweise bis zum nächsten diskreten Zeitintervall, anstatt die Kraft auszugeben, sobald sie bestimmt worden ist. Dies ermöglicht die Einhaltung einer konsistenten Kraftausgabeperiode. Vorzugsweise ist die Kraftausgabe am zweiten Intervallpunkt diesem Intervall angemessen und ist nicht notwendigerweise die Kraft, die an dem übersprungenen Intervallpunkt hätte ausgegeben werden sollen. Falls das Zeitintervall beispielsweise als 1 ms bestimmt ist, ist die Vorrichtung gewöhnlich in der Lage, Berechnungen anzustellen und jede Millisekunde eine Kraft auszugeben. In einigen Fällen jedoch, wie z. B. wenn ein komplexer Steuerbefehl erhalten wird, wenn Berechnungen für mehrere und/oder komplexe Krafteffekte vorgenommen werden oder eine andere Bedingung auftritt, die mehr Verarbeitung erfordert, könnte die Extraverarbeitung eine Verzögerung bei der Ausgabe der Kraft über den Intervallpunkt von 1 ms hinaus verursachen. Anstatt die Kraft auszugeben, wenn die Berechnung abgeschlossen ist, verzögert das Verfahren die Ausgabe der Kraft bis zum nächsten Einzelintervallpunkt, d. h. bis nach Ablauf einer ganzzahligen Anzahl von Zeitintervallen. Des weiteren berechnet das Verfahren auch die Kraft, die lieber beim zweiten Intervall als beim ersten abgegeben werden sollte. Wenn die Kraft beispielsweise auf einer periodischen Funktion basiert, dann kann die beim zweiten Intervall abzugebende Kraft unter Verwendung der Periodenfunktion bestimmt werden. Dies hält die Genauigkeit der Kraftempfindung an den Benutzer aufrecht und ist wichtig für Effekte auf Zeitbasis. Dieses Verfahren ermöglicht ein schnelleres Aktualisierungsintervall mit nur gelegentlichen Kraftausgabeverzögerungen und stellt auf diese Weise eine bessere Gesamt-Kraftausgabequalität bereit, als wenn ein längeres Zeitintervall verwendet wird.
  • Effekt-Cache-Speicherung auf dem Host-Computer
  • Eine Einschränkung von Kraftrückkopplungsvorrichtungen ist die relativ geringe Speichermenge, die in den Vorrichtungen enthalten ist. Zur Schaffung einer realistischen, eintauchfähigen Umgebung sollte ein Anwendungsprogramm viele verschiedene Krafteffekte ausgeben. Gewöhnlich kann jedoch nur eine kleine Anzahl von Effekten auf einer Kraftrückkopplungsvorrichtung gespeichert werden, oft weniger als das Anwendungsprogramm einsetzen möchte. Falls in gegenwärtigen Implementierungen ein Anwendungsprogramm einen Steuerbefehl zur Erstellung von mehr Krafteffekten erteilt, als von der Vorrichtung gespeichert werden können, werden die Effekte, die nicht gespeichert werden können, einfach abgelegt und nicht ausgegeben, und das Anwendungsprogramm wird von dem Ausfall in Kenntnis gesetzt (das Anwendungsprogramm kann auf den Ausfall auf jede mögliche Art reagieren, die der Entwickler wünscht). Eine Umgehung der Einschränkung besteht darin, ein ”intelligentes” Anwendungsprogramm bereitzustellen, das nur eine kleine Anzahl von Krafteffekten auf einmal ausgibt, die alle auf der Vorrichtung gespeichert werden können; wenn die Anwendung einen neuen, anderen Krafteffekt erstellen und ausgeben möchte, zerstört sie einen vorher verwendeten Effekt und befiehlt einen neuen Krafteffekt. Idealerweise sollte das Anwendungsprogramm jedoch in der Lage sein, so viele Krafteffekte auszugeben, wie es will, ohne die Speicherbeschränkungen der Kraftrückkopplungsvorrichtung berücksichtigen zu müssen und ohne zusätzliche Verarbeitungszeit für die Überlagerung der Krafteffekte aufbringen zu müssen.
  • Die Effekt-Cache-Speicherung durch den Host ist eine Möglichkeit, über den begrenzten Gerätespeicher hinaus vom Host-Speicher Gebrauch zu machen, um so viele Krafteffekte zu speichern, wie ein Anwendungsprogramm braucht. Der Host-Speicher wird als Überlauf-Cache-Speicher für die Vorrichtung verwendet, um alle Effekte zu speichern, die nicht auf der Vorrichtung gespeichert werden können. Aus der Sicht des Anwendungsprogramms sind alle angewiesenen Effekte auf der Vorrichtung gespeichert worden, so daß das Anwendungsprogramm nie eine Störungsmitteilung erhalten braucht, daß der Gerätespeicher voll wird. Ein Treiberprogramm auf dem Host (wie z. B. die Translationsebene, API oder eine andere Bibliothek oder auch ein niedrigerer Treiber) wickelt die gesamte Effekt-Cache-Speicherung auf einer niedrigeren Ebene als das Anwendungsprogramm ab.
  • 7 ist ein Flußdiagramm zur Darstellung eines Speicherverwaltungsverfahrens 400 vom Standpunkt des Host aus (z. B. die Translationsebene oder andere Ebenen der Host-Architektur in anderen Ausführungsformen), wobei ein Host-Cache-Speicher verwendet wird, um Effekte zu speichern. Der Begriff ”Cache-Speicher-Effekt” bezieht sich hierin auf einen Effekt, dessen Daten im Host-Speicher gespeichert werden, aber nicht im Gerätespeicher gespeichert werden, weil der Gerätespeicher voll ist. Der Host speichert den Krafteffekt im Cache-Speicher, wenn das Anwendungsprogramm (über die API) die Erstellung eines Krafteffektes auf der Vorrichtung anfordert und die Vorrichtung keine Effektschlitze zum Speichern des Effektes verfügbar hat. Anstatt eine ”Fehler”-Mitteilung an das Anwendungsprogramm zurückzugeben, speichert der Host den Krafteffekt im Cache-Speicher des Speichers des Host. Vorzugsweise geschieht dies durch einen Treiber auf dem Host, so daß das Anwendungsprogramm glaubt, die Vorrichtung habe alle Effekte geladen. Es sei darauf hingewiesen, daß die Reihenfolge der nachstehend beschriebenen Schritte nur ein Beispiel ist und daß die verschiedenen Kontrollen und Ereignisse zu jeder Zeit oder in unterschiedlichen Abfolgen als Funktionsaufrufe, Unterbrechungen und/oder parallel (Multitaskbetrieb) in verschiedenen Ausführungsformen vorkommen können.
  • 7 veranschaulicht ein auf dem Host 18 laufendes Verfahren 400. Das Verfahren 400 ist dem Verfahren 310 gemäß 5 in vielen Schritten ähnlich. Das Verfahren 400 beginnt bei 402, und in Schritt 404 erstellt der Host 18, ähnlich wie im Schritt 312 von 5, ein Speichermodell. In Schritt 406 bestimmt das Verfahren, ob das Anwendungsprogramm (z. B. durch die API) gerade irgendwelche Krafteffekte auf der Vorrichtung 11 erzeugt oder zerstört. Falls die Anwendung gegenwärtig keine Effekte auf der Vorrichtung erzeugen oder zerstören möchte, dann wird der weiter unten erläuterte Schritt 418 initiiert. Wenn die Anwendung einen Krafteffekt durch Erzeugen eines Effektes auf der Vorrichtung abändern möchte, dann prüft der Host in Schritt 408 das Hostmodell des Gerätespeichers, um zu bestimmen, ob ein Gerätespeicher zum Speichern des Effektes zur Verfügung steht. Falls nicht, wird der Krafteffekt in Schritt 412 im Cache-Speicher in dem Host-Speicher gespeichert, aber nicht in den Gerätespeicher geladen. Da der Host-Speicher im Vergleich zum Gerätespeicher für viele praktische Zwecke unbegrenzt ist, sollte der Host-Cache-Speicher in der Lage sein, alle Krafteffekte zu speichern, die das Anwendungsprogramm erzeugt. Die im Cache-Speicher gespeicherten Krafteffekte sind vorzugsweise im gleichen Gerätespeichermodell enthalten wie die eigentlichen geladenen Effekte (siehe 9a und 9b). Das Verfahren geht dann weiter zu Schritt 438, der weiter unten beschrieben ist. Wenn in Schritt 408 genügend Speicher für den erstellten Effekt vorhanden ist, dann werden in Schritt 410 ein oder mehr Erstellungsbefehle an die Vorrichtung gesendet, um den Effekt an der Vorrichtung zu laden, und der Effekt wird auch im Host-Speichermodell gespeichert. Das Verfahren geht dann weiter zu Schritt 438, das weiter unten beschrieben wird.
  • Wenn die Anwendung in Schritt 406 die Zerstörung eines Effektes befohlen hat, dann wird in Schritt 414 ein Effektschlitz auf dem Host freigemacht, wodurch ein offener Schlitz in dem Gerätespeichermodell geschaffen wird. Im nächsten wahlweisen Schritt 416 kann der Host einen Erstellungsbefehl zum Laden eines Cache-Speicher-Effektes in den leeren Schlitz im Gerätespeicher an die Vorrichtung senden. Da es einen leeren Schlitz im Gerätespeicher gibt und da der Host-Cache-Speicher Effekte einschließen kann, von denen das Anwendungsprogramm annimmt, daß sie auf der Vorrichtung geladen sind, kann es effizient sein, alle Schlitze im Gerätespeicher füllen zu lassen. Der Host kann einen Cache-Speicher-Effekt basierend auf der Reihenfolge laden, in der er im Cache gespeichert wurde, z. B. hat der Effekt die höchste Ladepriorität, der zuerst im Cache gespeichert wurde. Alternativ kann der Host die im Cache gespeicherten Effekte in gewisser Weise priorisieren und den Effekt mit der höchsten Priorität laden. Beispielsweise kann Auslöseeffekten eine höhere Priorität zugestanden werden als anderen Effekten. Den Effekten kann auch eine Priorität basierend auf mehreren Faktoren wie Effektgröße, Typ, Dauer oder Alter und/oder eine gewichtete Kombination aus mehreren dieser Faktoren zugeordnet werden. In anderen Ausführungsformen wird der Schritt 416 nicht realisiert, und der Host kann Cache-Speicher-Effektdaten zu der Zeit in die Vorrichtung laden, wo der Steuerbefehl zum Abspielen des Effektes erfolgt, wie in Schritt 432 unten. Das Verfahren geht dann weiter zum nachstehend beschriebenen Schritt 438.
  • Falls in Schritt 406 kein Erstellungs- oder Zerstörungsbefehl erfolgt, prüft das Verfahren in Schritt 418, ob das Anwendungsprogramm auf dem Host einen Effektzustand befiehlt. Wenn in Schritt 418 ein ”Stop”-Befehl erfolgt, dann sendet der Host in Schritt 420, ähnlich wie im Schritt 330 von 5, einen Stopbefehl an die Vorrichtung. In Schritt 422 markiert der Host den Effekt im Host-Speichermodell ähnlich wie im Schritt 332 von 5 um. Der nächste Schritt 423 ist ähnlich wie der oben beschriebene Schritt 416, wo der Host einen Erstellungsbefehl an die Vorrichtung senden kann, um einen Cache-Speicher-Effekt auf den Speicherplatz zu laden, der von dem Effekt besetzt war, dessen Stop befohlen wurde. Wie oben erläutert, kann der Host bestimmen, welcher der Cache-Speicher-Effekte die höchste Ladepriorität aufweist. Der Schritt 423 weist jedoch zusätzlich den Schritt auf zu prüfen, ob irgendein Cache-Speicher-Effekt, wie z. B. der Cache-Speicher-Effekt mit der höchsten Priorität, eine größere Priorität aufweist als der gestoppte Effekt. In einigen Fällen kann der gestoppte Effekt eine höhere Priorität aufweisen als alle anderen Cache-Speicher-Effekte und sollte daher im Gerätespeicher bleiben, z. B. kann in einer Implementierung, die eine hohe Priorität auf Auslöseeffekte legt, der gestoppte Effekt ein Auslöser sein, und die Cache-Speicher-Effekte können regelmäßig wiederkehrende Effekte mit geringerer Priorität sein. Die Priorität von Effekten ist nachstehend im Hinblick auf Schritt 434 beschrieben. Das Verfahren geht dann weiter zum weiter unten beschriebenen Schritt 438.
  • Wenn in Schritt 418 ein ”Abspiel”-Befehl erfolgte, dann prüft das Verfahren in Schritt 424, ob der befohlene Effekt bereits an der Vorrichtung geladen wurde. Der Host kann eine Liste fuhren, die angibt, welche der Effekte in die Vorrichtung geladen wurden und welche im Cache auf dem Host gespeichert wurden, wie in 9a und 9b gezeigt. Wenn der angewiesene Effekt vorher an der Vorrichtung geladen wurde, dann wird in Schritt 426, ähnlich wie in Schritt 326 von 5, der Wiedergabebefehl an die Vorrichtung gesendet, und der Effekt wird, ähnlich wie in Schritt 328 von 5, in Schritt 428 im Host-Speichermodell gekennzeichnet, (die Vorrichtung kennzeichnet den Effekt ferner, wie im Hinblick auf 6 naher beschrieben). Das Verfahren geht dann weiter zu Schritt 438.
  • Wenn der/die befohlene(n) Effekt(e) nicht an der Vorrichtung geladen wurde(n), d. h. im Cache auf dem Host gespeichert wurde(n), dann prüft das Verfahren in Schritt 430, ob es einen offenen Schlitz in dem Gerätespeicher gibt, in den der Cache-Speicher-Effekt gespeichert werden kann. Ein offener Schlitz weist keine darin gespeicherten Effektdaten auf. Wenn es einen offenen Schlitz gibt, dann geht das Verfahren weiter zu Schritt 432.
  • Wenn bestimmt wird, daß der angewiesene Effekt (oder ein wartender Effekt; in Schritt 414 kann jeder wartende Effekt, der geladen werden soll, als ”befohlener Effekt” angesehen werden) auf die Vorrichtung geladen werden kann, dann sendet der Host in Schritt 432 einen Erstellungsbefehl an die Vorrichtung, daß sie den angewiesenen Effekt in Schritt 416 in dem verfügbaren Effektschlitz des Gerätespeichers speichert, der Effekt wird z. B. im Effektblock und Parameterblock gespeichert (falls eine derartige Speicherstruktur verwendet wird), wie mit Bezug auf Schritt 320 gemäß 5 erläutert. Das Verfahren geht dann weiter zu Schritt 426, um den ”Spiel”-Befehl für den erstellten Effekt zu senden, wie oben erläutert. Nachdem der Effekt in Schritt 428 auf der Vorrichtung und dem Host gekennzeichnet ist, geht das Verfahren weiter zu Schritt 438, der weiter unten beschrieben ist.
  • Wenn es in Schritt 430 keinen offenen Schlitz auf der Vorrichtung gibt, dann prüft das Verfahren in Schritt 434, ob irgendeiner der geladenen Effekte mit dem angewiesenen Effekt ”überlagert” werden kann, z. B. ob der geladene Effekt in seinem Gerätespeicherschlitz entladen (überschrieben) und der angewiesene Effekt an seiner Stelle gespeichert werden kann.
  • Das Verfahren kann viele verschiedene Kriterien verwenden, um zu bestimmen, ob irgendwelche Schlitze im Gerätespeicher verfügbar sind. In einer Ausführungsform prüft das Verfahren, ob alle geladenen Effekte gegenwärtig abgespielt werden; die Schlitze aller geladenen Effekte, die gegenwärtig nicht abgespielt werden, könnten als verfügbare Schlitze angesehen werden. Der Host kann den befohlenen Effekt einfach in den ersten verfügbaren Speicherschlitz schreiben.
  • In einigen Ausführungsformen können Kriterien auf Zeitbasis (temporäre Kriterien) verwendet werden. Beispielsweise kann eine lange Zeitspanne vergangen sein, seit ein geladener Effekt zuletzt abgespielt wurde, so daß dieser Effekt als entbehrlich und der Schlitz, den er einnimmt, als verfügbar für den neu befohlenen Effekt angesehen werden kann. Ein solcher entbehrlicher Effekt ist eventuell nicht mehr in unmittelbarem Gebrauch durch das Anwendungsprogramm und kommt daher am ehesten dafür in Frage, entladen zu werden. Der geladene Effekt mit der längsten Zeit seit dem letzten Abspielen kann als am ehesten zum Abstoßen in Frage kommend angesehen werden.
  • In anderen Ausführungsformen können anstelle oder zusätzlich zur Verwendung solcher Kriterien auf Zeitbasis Kriterien auf Raumbasis zur Bestimmung der Schlitzverfügbarkeit verwendet werden. Dieses Verfahren sagt die Bewegung des Benutzergegenstands 12 durch den Benutzer voraus, um bestimmen zu helfen, welche Effekte an der Vorrichtung geladen werden sollten. 8 veranschaulicht eine Verwendungsform einer räumlichen Cache-Speicherung. In einer auf dem Bildschirm 20 angezeigten GUI 450 kann der Benutzer der Vorrichtung 11 einen Positionsanzeiger 452 zu verschiedenen Feldern der GUI bewegen. Viele Krafteffekte werden basierend auf dem Standort des Positionsanzeigers in der GUI abgegeben. Beispielsweise kann ein anziehendes Schwerkraftfeld ausgegeben werden, um den Positionsanzeiger/Benutzergegenstand zu einem Bildsymbol 454 vorzuspannen, wenn der Positionsanzeiger innerhalb eines Außenbereiches 455 um das Bildsymbol herumbewegt wird. Oder es kann eine Schlagkraft ausgegeben werden, wenn der Positionsanzeiger sich über eine Fenstereinfassung 464 des Fensters 462 hinüberbewegt.
  • Bei Verwendung der räumlichen Kriterien können diejenigen Krafteffekte als wesentlicher angesehen werden, die graphischen Objekten in der momentanen Bewegungsbahn des Positionsanzeigers zugeordnet sind, da es wahrscheinlicher ist, daß sie in unmittelbarer Zukunft ausgegeben werden müssen, wenn der Positionsanzeiger sich zu den zugeordneten graphischen Objekten bewegt. Diejenigen Effekte, die graphischen Objekten abseits des momentanen Wegs des Positionsanzeigers zugeordnet sind, sind entbehrlicher, da es weniger wahrscheinlich ist, daß ihre unmittelbare Ausgabe erforderlich ist. Demnach kann der Host die momentane Richtung (und Geschwindigkeit, falls gewünscht) des Positionsanzeigers 452 festlegen, um zu bestimmen, welche graphischen Objekte und Effekte in der momentanen Bewegungsbahn des Positionsanzeigers liegen und welche graphischen Objekte und Effekte weit abseits der momentanen Bewegungsbahn liegen. Der Effekt, der dem graphischen Objekt zugeordnet ist, das am weitesten vom Positionsanzeigerweg entfernt ist, kann als entbehrlichster Effekt angesehen und entladen und durch einen Effekt ersetzt werden, der dichter an der Bewegungsbahn des Positionsanzeigers liegt.
  • Beispielsweise ist in 8 vom Host bestimmt worden, z. B. durch Überprüfen einer Historie von zwei oder mehr Positionsanzeigerstellungen, daß der Positionsanzeiger 452 sich gegenwärtig in die Richtung 466 bewegt. Der Positionsanzeiger bewegt sich wahrscheinlich in die Richtung 468 (die Geschwindigkeit des Positionsanzeigers kann diese Bestimmung wahlweise beeinflussen; falls der Positionsanzeiger sich schnell bewegt, ist es wesentlich wahrscheinlicher, daß er in derselben Richtung 466 weiterfährt, als wenn er langsamer bewegt oder gerade angehalten wird). Daher liegen die Bildsymbole 454 und 456 und das Fenster 458 abseits vom wahrscheinlichen Weg des Positionsanzeigers, und irgendwelche diesen Objekten zugeordnete Krafteffekte werden wohl in unmittelbarer Zukunft nicht ausgegeben werden müssen. Der Positionsanzeiger kann jedoch direkt auf das Bildsymbol 460 zusteuern; da das dem Bildsymbolbereich 461 zugeordnete Anziehungsfeld möglicherweise sehr bald ausgegeben werden muß, hat der Effekt des Anziehungsfeldes eine viel höhere räumliche Priorität als die Effekte, die den Objekten 454, 456, 458 zugeordnet sind. Das Fenster 462 liegt nicht im direkten Weg des Positionsanzeigers wie das Bildsymbol 460, aber da es nahe am Weg 468 liegt, sollten die dem Fenster 462 zugeordneten Effekte eine höhere räumliche Priorität aufweisen als die Effekte der Objekte 454, 456 und 458 und sollten anstelle eines der Effekte mit niedriger Priorität geladen werden.
  • In einem allgemeineren Sinn kann der Host die Bewegung des Benutzergegenstands 12 überwachen und Mehrfach-Effekte auf der Vorrichtung mit Cache-Speicher-Effekten überlagern, deren Ausgabe in unmittelbarer Zukunft wahrscheinlicher ist. Zur Bestimmung der Speicherschlitzverfügbarkeit können auch Kriterien auf Raumbasis in Verbindung mit Kriterien auf Zeitbasis verwendet werden.
  • Unter Rückbezug auf 7 kann ein Prioritätssystem auch dazu verwendet werden zu bestimmen, welcher Effekt am besten abgestoßen oder ausgelagert und durch einen Cache-Speicher-Effekt ersetzt wird. Beispielsweise kann jeder Krafteffektart eine Priorität in einem absoluten Prioritätssystem zugeordnet sein, wobei jedem Effekt ein Rang in einer Prioritätsliste gemäß der Art des Effektes gegeben wird. Beispielsweise kann die Priorität eines Dämpfungseffektes als niedriger angesehen werden als die eines periodischen Vibrationseffektes, der für den Benutzer auffälliger sein mag. Ein ”Auslöse”-Effekt hat vorzugsweise eine höhere Priorität als Nicht-Auslöseeffekte. Ein Auslöseeffekt ist ein Effekt, der nicht immer läuft, der aber sofort ausgegeben werden muß, wenn sich vorher festgelegte Ereignisse oder Bedingungen ereignen. Beispielsweise kann jedesmal ein Auslöseeffekt für einen Gewehrrückstoß abgespielt werden, wenn der Benutzer eine Taste auf der Vorrichtung 11 drückt. Da Auslöseeffekte schnell gespielt werden müssen, sollten sie möglichst im Gerätespeicher geladen bleiben. Des weiteren kann ein gegenwärtig abgespielter Effekt eine höhere Priorität aufweisen als gerade nicht gespielte Effekte (einschließlich gegenwärtig nicht abgespielter Auslöseeffekte), da es eine gewaltsame Unterbrechung für einen Benutzer sein kann, wenn ein Effekt plötzlich stoppt, bevor er zu Ende ist. Dies kann jedoch nicht der Fall sein, wenn die räumliche Cache-Speicherung verwendet wird, da ein gegenwärtig spielender Effekt sofort ausgeschaltet werden kann, wenn der Benutzer den Benutzergegenstand 12 zu einem anderen Ort bewegt.
  • Die Priorität des angewiesenen Effektes wird mit den Prioritäten der geladenen Effekte verglichen; der erste Effekt mit einer niedrigeren Priorität kann zweckmäßigerweise mit dem angewiesenen Effekt überlagert werden. Alternativ können alle geladenen Effekte überprüft werden, und der Effekt mit der niedrigsten Priorität kann zweckmäßigerweise durch den angewiesenen Effekt ersetzt werden, wenn der befohlene Effekt eine höhere Priorität hat als dieser Effekt. In einigen Ausführungsformen werden nur Effekte auf Verfügbarkeit überprüft, die gegenwärtig nicht spielen; alternativ können alle geladenen Effekte, ob sie gegenwärtig abgespielt werden oder nicht, überprüft und der Effekt mit der niedrigsten Priorität abgestoßen werden.
  • Des weiteren können in einigen Ausführungsformen die Effektprioritäten zu Cache-Speicherzwecken durch ein Betriebssystem, eine Anwendung oder ein anderes Programm oder durch den Benutzer geändert werden. Beispielsweise kann ein Entwickler eines Kraftrückkopplung-Anwendungsprogramms in einigen Ausführungsformen bestimmten Effekten Prioritäten zuordnen, so daß der Entwickler die Flexibilität besitzt, die Bedeutung verschiedener Effekte für sein bestimmtes Anwendungsprogramm festzulegen. Beim Urladevorgang des Anwendungsprogramms könnte ein Prioritätssystem für eine bestimmte Anwendung an den Host-Treiber geliefert werden. Ein derartiges Prioritätssystem könnte in einem Kontext für dieses Anwendungsprogramm gespeichert werden, wie beispielsweise für 2 beschrieben. In einem derartigen System sollte der Entwickler in der Lage sein, jedem gewünschten Effekt die größtmögliche Priorität zuzuordnen, was dann einen angewiesenen Effekt mit einer derartigen Priorität erstellt, daß er immer an der Vorrichtung geladen wird, egal, welche Effekte bereits geladen sind. Dies ermöglicht es der Anwendung, die Kraftrückkopplung an der Vorrichtung direkt und ohne Rücksicht auf den Erhalt von Fehlermeldungen zu steuern.
  • Außerdem können Effekte in verschiedene Kategorien oder ”Garnituren” eingeteilt werden, wo den Effekten in einer Kategorie Prioritäten zugeordnet werden und/oder nur bestimmte Kategorien zu einer bestimmten Zeit in Gebrauch sein brauchen. Dies ermöglicht das Löschen von Effekten aus anderen ”inaktiven” Kategorien aus der Vorrichtung und das Laden von Effekten, die in der ”aktiven” Kategorie enthalten sind. Die Prioritäten können in einigen Fallen vom Entwickler eines Anwendungsprogramms zugeordnet sein. Beispielsweise kann ein Entwickler einer Spielanwendung eine Kategorie ”An Land” schaffen, die einen Kollisionseffekt und einen Waffenfeuereffekt als Priorität 1, ein Maschinenrattereffekt als Priorität 2, und einen Effekt ”leichtes Lüftchen” als Priorität 3 einschließt. Der Entwickler kann auch eine Kategorie ”Im Wasser” erstellen, die einen Wasserwiderstands-(Dämpfungs-)Effekt und einen Explosionseffekt als Priorität 1, einen Effekt ”starke Strömung” als Priorität 2 und ”Auftreffen auf Seetang” als Priorität 4 einschließt. Das Anwendungsprogramm ruft die API an, um den Host-Treiber in Kenntnis zu setzen, welche Kategorie gegenwärtig in Gebrauch ist und wann die Kategorien umgeschaltet werden sollen. Wenn der Benutzer im Spiel ein Fahrzeug so steuert, daß es sich vom Land ins Wasser bewegt, gibt das Anwendungsprogramm an, daß die Effektkategorie ”An Land” auf die Effektkategorie ”Im Wasser” umgeschaltet werden sollte. Der Host-Treiber weiß dann, daß alle ”An Land”-Effekte zur Löschung aus dem Gerätespeicher freigegeben sind und daß die ”Im Wasser”-Effekte geladen werden sollten. Da ferner jedem Effekt eine Priorität zugeordnet worden ist, weiß der Host-Treiber, daß – falls nicht genügend Schlitze da sind, um alle ”Im Wasser”-Effekte zu speichern – die Wasserwiderstands- und Explosionseffekte vor den Effekten mit niedrigerer Priorität geladen werden sollten.
  • Das oben beschriebene Prioritätssystem kann auch mit anderen Kriterien kombiniert werden, beispielsweise den oben beschriebenen Kriterien auf Zeitbasis und/oder Raumbasis. Zum Beispiel kann eine Priorität einem geladenen Effekt basierend auf mehrfachen Faktoren zugeordnet werden, wie z. B. dem Effekttyp, der anwendungszugeordneten Priorität, den Kriterien auf Zeitbasis und/oder den Kriterien auf Raumbasis. Einige Krafteffekte können beispielsweise ”Einmal”-Effekte sein, die einmal gespielt und dann nicht benutzt werden. Diese Effekte könnten eine anfänglich hohe Priorität aufweisen; sobald sie abgespielt sind, kann ihre Priorität auf Null gehen. In einigen Ausführungsformen kann dem Effekt basierend auf diesen Faktoren und allen den Faktoren zugeordneten Gewichtungen eine gesamtgewichtete Priorität zugeordnet sein. Die gewichtete Priorität des geladenen Effektes kann dann mit der (gewichteten) Priorität des angewiesenen Effektes verglichen werden, um zu bestimmen, ob der geladene Effekt mit dem angewiesenen Effekt überlagert werden kann.
  • Des weiteren können auch andere Kriterien bestimmen, ob der angewiesene Effekt geladen werden kann. Bei der Implementierung noch höherentwickelter Vergleiche, Gewichtungen etc. sollten die Verknüpfungen zwischen verfügbarer Host-Verarbeitungsleistung und Gewinnen bei der Cache-Speicherleistung berücksichtigt werden.
  • Eine weitere Überlegung ist, ob der befohlene Effekt tatsächlich in den durch einen bestimmten geladenen Effekt besetzten Speicherplatz passen kann. Im Effektblock 300 nehmen alle Effekte denselben Platzumfang ein, aber im Parameterblock 304 nehmen unterschiedliche Effekte einen unterschiedlichen Platzumfang ein, basierend darauf, wie viele Parameter verwendet werden und wieviel Nutzraum für einen Effekt benötigt wird. Wenn der angewiesene Effekt nicht auf den Platz paßt, der von dem geladen Effekt mit der niedrigsten Priorität besetzt ist, dann sollte dieser geladene Effekt vom Vergleich ausgeschlossen werden, und andere geladene Effekte werden auf ihre Eignung überprüft. Falls alternativ der überprüfte geladene Effekt nicht genügend Platz für den befohlenen Effekt einnimmt, kann der geladene Effekt immer noch abgestoßen oder zerstört werden. Das Verfahren überprüft dann noch einen geladenen Effekt mit niedriger Priorität und stößt auch diesen Effekt ab; dieses Verfahren kann so weitergehen, bis genügend Platz für den angewiesenen Effekt freigemacht ist.
  • Wenn in Schritt 434 bestimmt wird, daß der angewiesene Effekt über einen geladenen Effekt geladen werden kann, dann wird in Schritt 432 ein Erstellungsbefehl oder -befehle an die Vorrichtung gesendet, um die Daten für den angewiesenen Effekt auf den Platz des entbehrlichen Effektes zu laden. Es sei darauf hingewiesen, daß der entbehrliche Effekt immer noch zur Steuerung durch die Anwendung verfügbar ist, da er sich immer noch im Host-Cache-Speicher und dem Speichermodell befindet. Das Verfahren geht dann weiter zu Schritt 426, um einen Wiedergabebefehl an die Vorrichtung zu senden und den befohlenen Effekt abzuspielen, wie oben beschrieben.
  • Wenn in Schritt 434 bestimmt wird, daß der angesteuerte Effekt nicht geladen werden kann, dann wird dem Steuerbefehl in Schritt 436 ein Fehlerstatus erteilt, und der befohlene Effekt wird nicht in die Vorrichtung geladen. Natürlich ist nur der ”Spiel”-Befehl selbst fehlgeschlagen; die Effektdaten befinden sich immer noch im Host-Cache-Speicher und dem Speichermodell. In einigen Ausführungsformen braucht das Anwendungsprogramm nicht über den Ausfall informiert werden; dies ermöglicht dem Anwendungsprogramm zu glauben, daß der Krafteffekt ordnungsgemäß abgespielt wird, und einen weiteren Wiedergabebefehl für diesen Effekt zu einem späteren Zeitpunkt ohne Unterbrechung oder zusätzliche Verarbeitung auszugeben (und der spätere Steuerbefehl kann erfolgreich sein); zudem verhindert dies, daß die Anwendung auf den Ausfall überreagiert. In anderen Ausführungsformen kann es wünschenswert sein, das Anwendungsprogramm von einem Fehlschlag beim Abspielen eines Effektes zu unterrichten, so daß das Anwendungsprogramm den Ausfall auf andere Weise kompensieren kann. Das Anwendungsprogramm kann mit wechselnden Informationsgraden versehen sein; beispielsweise, daß der Effekt im Cache gespeichert, aber nicht abgespielt wurde, oder daß der Effekt einfach nicht abgespielt wurde. Das Verfahren geht weiter zu Schritt 438, der weiter unten beschrieben ist.
  • In einer alternativen Ausführungsform kann das Verfahren einen fehlgeschlagenen, im Cache gespeicherten angesteuerten Effekt als ”im Wartezustand” markieren. Effekten, die den Status ”im Wartezustand” aufweisen, kann eine hohe Priorität gegeben werden, so daß sie geladen werden, falls sich bei künftigen Wiederholungen für irgendeinen der Effektschlitze auf der Vorrichtung ein Zugang ergeben sollte. Der Host kann die Dauer des Effektes während des Wartestatus aufrechterhalten, so daß der Host weiß, ob der wartende Effekt noch ausgegeben werden soll, wenn sich ein Effektschlitz auftut, und falls ja, an welcher Stelle seiner Dauer.
  • Demzufolge brauchen nur Effekte einen Wartestatus bekommen, die eine relativ lange Dauer haben. Falls beispielsweise ein periodischer Effekt mit einer Dauer von vier Sekunden darauf wartet, auf die Vorrichtung geladen zu werden, behält der Host die Dauer im Auge; wenn zwei Sekunden vergangen sind, bevor ein Effektschlitz verfügbar ist, befiehlt der Host dem periodischen Effekt, mit der dritten Sekunde anzufangen. Falls vier Sekunden vergangen sind, bevor ein Effektschlitz verfügbar wird, sollte der Host den Effekt stornieren, da seine Dauer dann abgelaufen ist. In einer Warteausführungsform kann das Verfahren prüfen, ob irgendwelche wartenden Effekte auf die Vorrichtung geladen werden können, nachdem ein Effektkennzeichen im Schritt 422 entfernt oder in Schritt 414 zerstört wird; falls ja, kann der Erstellungsbefehl gemäß Schritt 416 oder Schritt 423 den wartenden Effekt kommen lassen (falls die Priorität des wartenden Effektes hoch genug ist), und es kann ein Wiedergabebefehl gesendet werden, falls zweckmäßig, um den früher wartendenden Effekt abzuspielen. In den Schritten 430 und 434 kann einem wartenden Effekt auch eine Priorität zugeordnet werden oder seine vorhandene Priorität aufgrund des Wartestatus heraufgesetzt werden, und der wartende Effekt kann vor einem gegenwärtig angesteuerten Effekt geladen werden, falls seine Priorität höher ist. Es sei darauf hingewiesen, daß ein derartiger Wartestatus in vielen Implementierungen unnötig ist, da die Dauer vieler Krafteffekte zu kurz ist, um die erforderliche Extraverarbeitung zu rechtfertigen. Außerdem können Vorrichtungen mit mehreren Effektschlitzen gewöhnlich selbst dann realistische Kräfte aufrechterhalten, wenn einige Krafteffekte weggefallen sind.
  • In Schritt 438 kann der Host ähnlich wie in Schritt 334 gemäß 5 prüfen, ob irgendein Spieleffekt abgelaufen ist. Falls keine Effekte abgelaufen sind, kehrt das Verfahren zu Schritt 406 zurück. Falls zumindest ein Effekt abgelaufen ist, geht das Verfahren weiter zu Schritt 440, um den abgeschlossenen Effekt im Host-Speichermodell umzuetikettieren. In anderen Ausführungsformen können die Schritte 438 und 440 weggelassen werden. Dann kehrt das Verfahren zu Schritt 406 zurück.
  • Die Speicherung des Krafteffektes im Cache auf dem Host kann neben der oben beschriebenen Implementierung, wo der Host ein Gerätespeichermodell unterhält, auch in anderen Speicherverwaltungsparadigmen nützlich sein. Falls beispielsweise nur die Vorrichtung weiß, ob ein befohlener Krafteffekt im Gerätespeicher gespeichert werden kann, wird die Vorrichtung vom Host befragt. Falls die Vorrichtung mitteilt, daß sie keine Effekte mehr speichern kann, kann ein Treiber auf dem Host den Effekt erstellen und im Cache speichern und das Anwendungsprogramm informieren, daß sein Effekt erstellt wurde, anstatt anzugeben, daß der Erstellungsbefehl fehlgeschlagen ist.
  • Es ist von Bedeutung festzuhalten, daß das oben beschriebene Verfahren vorzugsweise auf einer niedrigeren Ebene auf dem Host-Computer implementiert ist als das Anwendungsprogramm, das die Kräfte steuert. Das Anwendungsprogramm besitzt daher keine Kenntnis von der gesamten eventuell vor sich gehenden Effektverarbeitung. Dies entbindet das Anwendungsprogramm davon, bestimmen zu müssen, welche Effekte zerstört und welche zu anderen Zeiten erstellt werden sollten, und ermöglicht es dem Entwickler der Anwendung, sich auf andere wichtige Aspekte der Anwendungs- und Kraftgestaltung zu konzentrieren.
  • 9a und 9b sind schematische Darstellungen des Speichers des Host und der Vorrichtung bei der Cache-Speicherung eines Krafteffektes, wie in 7 erläutert. Im Beispiel gemäß 9a weist eine Vorrichtung fünf Effektschlitze 480 auf, und alle fünf Schlitze wurden mit einem Krafteffekt gefüllt, wie gezeigt. Zwei der Effekte spielen zur Zeit (gekennzeichnet), wie in Spalte 482 gezeigt. Der Host speichert unterdessen ein Speichermodell 484, das sieben Krafteffekte 485 enthält. Dies ist deshalb so, weil das Anwendungsprogramm sieben Krafteffekte erzeugt hat und glaubt, daß alle sieben Effekte auf der Vorrichtung erstellt wurden. Deshalb wurden zwei der erstellten Krafteffekte vom Host in einem Cache gespeichert, weil die Vorrichtung nur fünf Effekte speichern kann.
  • Wie in Spalte 486 gezeigt, behält der Host-Treiber im Auge, welche Krafteffekte tatsächlich auf der Vorrichtung erzeugt (geladen) wurden. Der Host-Treiber verfolgt auch in Spalte 488, welche Krafteffekte gegenwärtig spielen, d. h. an den Benutzer ausgegeben werden. In dem gezeigten Beispiel weiß der Host also, daß die Effekte in den Schlitzen 1, 3, 4, 5 und 6 des Host in den verfügbaren Schlitzen der Vorrichtung geladen sind. Die Schlitze von Host und Vorrichtung brauchen nicht übereinstimmen, da der Host während der Anwendungsausführung unterschiedliche Effekte aus der Vorrichtung lädt und entlädt; der Host-Treiber braucht jedoch nicht wissen, in welchen Schlitzen der Vorrichtung die Effekte gespeichert sind, so daß das richtige Verzeichnis in den Effektblock an die Vorrichtung gesendet werden kann. Der Host weiß auch, daß die Effekte in den Schlitzen 3 und 4 des Host gegenwärtig auf der Vorrichtung spielen. Wenn die Anwendung das Abspielen eines Cache-Speicher-Effektes befiehlt, wie z. B. den Federeffekt in Schlitz 7 des Host, dann kann der Host die beladenen Effektschlitze 480 überprüfen, um festzustellen, in welchen Schlitz der Federeffekt geladen werden kann. Beispielsweise spielen auf der Vorrichtung die Effekte Periode1, Auslösekraft und Periode2 nicht; da Auslöseeffekte ein hohe Priorität besitzen, könnte wahrscheinlich der Effekt Periode1 oder Periode2 ausgeladen und der Effekt Feder2 in den verfügbaren Schlitz geladen werden, abhängig von den verwendeten Verfügbarkeits- und Prioritätsbedingungen. Darüber hinaus kann der Host in einigen Ausführungsformen auch ein ”Prioritäts”-Feld für jeden Effekt im Modell 485 unterhalten, um einen Vergleich von Prioritäten zu Ladezwecken zu ermöglichen.
  • 9b veranschaulicht eine Ausführungsform 490, die das oben beschriebene Wartemerkmal als Alternative zum Schritt 436 in 7 bereitstellt. Der Host behält im Auge, welche Krafteffekte ”warten”, wie in Spalte 492 gezeigt. In dem gezeigten Beispiel wurden demzufolge die Effekte in den Schlitzen 1, 3, 4, 5 und 6 der Vorrichtung auf die Vorrichtung geladen und sind alle gekennzeichnet, was bedeutet, daß sie gegenwärtig alle ausgegeben werden. Das Anwendungsprogramm hat den Effekt Konstantkraft1 in Schlitz 2 des Host zum Abspielen angesteuert, aber es gibt keinen verfügbaren Effektschlitz zum Speichern des befohlenen Effektes. Der Host markiert daher den angesteuerten Effekt als ”wartend” und überwacht den Gerätespeicher, um zu bestimmen, ob der angewiesene Effekt später auf die Vorrichtung geladen und abgespielt werden kann. Der Host hält die Dauer des Effektes Konstantkraft1 intern aufrecht, um die richtige Kraftgröße, Richtung etc. zu dem Zeitpunkt auszugeben, wo der wartende Effekt tatsächlich auf die Vorrichtung geladen werden kann.
  • 10 ist eine schematische Darstellung einer alternativen Ausführungsform einer ”Spielliste” des Gerätespeichers der Vorrichtung 11. In den obigen Ausführungsformen hat die Vorrichtung 11, wie in den Schritten 362 bis 378 gemäß 6 gezeigt, jeden Effektschlitz der Reihe nach überprüft und geprüft, ob jeder Effekt gekennzeichnet war (gerade spielte); falls der Effekt gekennzeichnet war, wurde eine auf diesem Effekt basierende Kraft zu einer Gesamtkraft addiert, die auf den durch einen Benutzer betätigbaren Gegenstand 12 ausgegeben wurde. 10 veranschaulicht ein alternatives Verfahren, in dem eine Spielliste 500 im Gerätespeicher gespeichert ist. Ein Effektblock 502 ist auf der Vorrichtung und dem Host gespeichert, wie oben erläutert (ein Parameterblock (nicht gezeigt) kann ebenfalls gespeichert sein). Wenn ein Effekt durch das Verfahren 310 gekennzeichnet wird (z. B. in Schritt 328 gemäß 5), wird ein Hinweiszeiger auf diesen Effekt oder dieses Verzeichnis in den Effektblock in den nächsten verfügbaren Schlitz in der Spielliste 500 gespeichert. Auf diese Weise werden vorzugsweise nur die obersten Schlitze der Spielliste gefüllt, mit eventuell offenen Schlitzen am Ende der Liste. Die Gesamtzahl gekennzeichneter Effekte wird als Zahl an einer Speicherstelle 504 gespeichert und jedesmal aktualisiert, wenn ein Effekt gekennzeichnet oder umetikettiert wird. In den meisten Implementierungen kann die Anzahl von Schlitzen in der Spielliste 500 geringer sein als die Anzahl von Effektschlitzen, die in dem Effektblock 502 implementiert sind, da die Anzahl spielender Effekte wahrscheinlich kleiner ist als die Gesamtanzahl der auf der Vorrichtung gespeicherten Effekte. Beispielsweise kann die Vorrichtung in der Lage sein, 30 Effekte zu speichern, aber die Spielliste könnte nur 10 Schlitze benötigen.
  • Wenn ein Effekt zu Ende ist oder durch einen Steuerbefehl gestoppt wird, wird der Effekt aus der Spielliste entfernt. Wenn andere noch spielende Effekte da sind, die sich weiter unten als der entfernte Effekt in der Liste befinden, dann können ein oder mehr dieser späteren Effekte verschoben werden, um eine durchgängige Spielliste ohne Lücken aufrechtzuerhalten. Beispielsweise kann der letzte Effekt in der Spielliste auf den Platz geschoben werden, wo der entfernte Effekt einmal gespeichert war. Zusätzlich wird nach Entfernen des Effektes aus der Spielliste die Gesamtzahl der Effekte an der Stelle 504 herabgesetzt.
  • Die Effizienz der Spielliste 500 wird demonstriert, wenn das Spielverfahren 350 gemäß 6 den Gerätespeicher überprüft, um zu bestimmen, welche Effekte als Kräfte ausgegeben werden. Anstelle einer sequentiellen Überprüfung aller Schlitze in dem Effektblock 502, wie in 6 beschrieben, überprüft das Verfahren statt dessen einfach die Speicherstelle 504 auf die Anzahl von Effekten, die gegenwärtig gekennzeichnet sind (spielen). Sobald diese Zahl T bekannt ist, schaut sich das Verfahren dann die obersten Einträge T in der Spielliste 500 an, um zu bestimmen, welche bestimmten Effekte gerade spielen, und berechnet Kräfte für diese Effekte. Dies ist wesentlich effizienter, als das Kennzeichnungsfeld für jeden Eintrag in dem Effektblock 502 zu überprüfen, besonders wenn viele Effekte im Effektblock 502 vorhanden sind. Des weiteren wird keine Verarbeitungszeit zur Prüfung jedes Schlitzes in der Effekttabelle vergeudet, falls gerade keine Effekte oder nur eine kleine Anzahl von Effekten spielt.
  • Zwar ist diese Erfindung bezogen auf mehrere bevorzugte Ausführungsformen beschrieben worden, es wird jedoch erwartet, daß diesbezügliche Veränderungen, Vertauschungen und Äquivalente für Fachleute auf diesem Gebiet beim Lesen der Beschreibung und Studieren der Zeichnungen offensichtlich werden. Auch können die verschiedenen Merkmale der Ausführungsformen hier auf verschiedene Arten kombiniert werden, um zusätzliche Ausführungsformen der vorliegenden Erfindung bereitzustellen. Des weiteren ist die bestimmte Terminologie zum Zwecke der darstellerischen Klarheit verwendet worden und nicht zur Einschränkung vorliegenden Erfindung. Daher sollen die folgenden angehängten Ansprüche alle solche Änderungen, Vertauschungen und Äquivalente einschließen, die unter den eigentlichen Erfindungsgedanken und Schutzbereich der vorliegenden Erfindung fallen.

Claims (34)

  1. Verfahren zur Bereitstellung von Krafteffekten mittels einer Kraftrückkopplungsvorrichtung mit einer örtlichen Steuerung der Ausgabe von Kraftempfindungen, wobei die Kraftrückkopplungsvorrichtung an einen Host-Computer gekoppelt ist und das Verfahren umfasst: – Empfangen eines Krafteffekt-Ladebefehls von einem Anwendungsprogramm, wobei der Krafteffekt-Ladebefehl die Daten zur Speicherung eines Krafteffektes in einem Gerätespeicher anweist; gekennzeichnet durch; – Erzeugen einer Gerätespeicherdarstellung, wobei der Gerätespeicher auf der Kraftrückkopplungsvorrichtung vorgesehen ist und die Darstellung im Speicher des Host-Computers abgelegt wird, wobei das Anwendungsprogramm auf dem Host-Computer läuft; – Speichern der Daten für den Krafteffekt in der Gerätespeicherdarstellung, wobei in der Darstellung eine größere Anzahl dieser Krafteffekte gespeichert werden kann als in dem Gerätespeicher; – Bestimmen, ob der Gerätespeicher den Krafteffekt speichern kann, durch Überprüfen der Gerätespeicherdarstellung, wobei das Bestimmen auf einer Priorität des Krafteffekts im Vergleich zu Prioritäten geladener Krafteffektdaten basiert, die in der Speichervorrichtung gespeichert sind; und – falls der Gerätespeicher den Krafteffekt speichern kann, Senden der Daten für den Krafteffekt an die Kraftrückkopplungsvorrichtung zur Speicherung in dem Gerätespeicher, wobei die Kraftrückkopplungsvorrichtung die Daten zur Steuerung einer Kraftausgabe an einen Benutzer der Kraftrückkopplungsvorrichtung verwendet.
  2. Verfahren nach Anspruch 1, wobei ferner das Senden des Krafteffektes an die Kraftrückkopplungsvorrichtung verzögert wird, wenn der Gerätespeicher voll ist und den Krafteffekt nicht speichern kann.
  3. Verfahren nach Anspruch 1, wobei die Daten für den Krafteffekt zumindest einen Parameter zur Kennzeichnung des Krafteffektes einschließen.
  4. Verfahren nach Anspruch 1, ferner umfassend: – Empfangen eines Krafteffekt-Wiedergabebefehls von dem Anwendungsprogramm, wobei der Krafteffekt-Wiedergabebefehl die Ausgabe des geladenen Krafteffektes an den Benutzer durch die Vorrichtung anweist; und – Senden des Krafteffekt-Wiedergabebefehls an die Kraftrückkopplungsvorrichtung, wobei die Kraftrückkopplungsvorrichtung die Kraft auf Basis des geladenen Krafteffektes ausgibt.
  5. Verfahren nach Anspruch 4, ferner umfassend: – Empfangen eines Krafteffekt-Stopbefehls von dem Anwendungsprogramm, wobei der Krafteffekt-Stopbefehl die Ausgabe des Krafteffektstops an den Benutzer durch die Vorrichtung anweist; – Senden des Krafteffekt-Stopbefehls an die Kraftrückkopplungsvorrichtung, wobei die Kraftrückkopplungsvorrichtung die Ausgabe der Kraft entsprechend dem gesteppten Krafteffekt stoppt.
  6. Verfahren nach Anspruch 4, wobei eine Vielzahl von Krafteffekten in der Darstellung und in dem Gerätespeicher gespeichert ist, wobei alle von dem Anwendungsprogramm zur Ausgabe befohlenen Krafteffekte summiert werden, um eine Gesamtausgabekraft bereitzustellen.
  7. Verfahren nach Anspruch 1, wobei wenn von dem Anwendungsprogramm ein ganz bestimmter der Krafteffekte zur Wiedergabe befohlen wird, der in der Darstellung, aber nicht in dem Gerätespeicher gespeichert ist, dieser bestimmte Krafteffekt an den Gerätespeicher geschickt wird, um einen in dem Gerätespeicher gespeicherten Krafteffekt zu ersehen.
  8. Verfahren zur Handhabung der Speicherung von Krafteffekten in einem Kraftrückkopplungssystem, wobei das Kraftrückkopplungssystem eine mit einem Host-Computer verbundene Kraftrückkopplungsvorrichtung einschließt und das Verfahren umfasst: – Empfangen eines Krafteffekt-Erstellungsbefehls durch einen auf dem Host-Computer laufenden Treiber, wobei der Steuerbefehl von einem auf dem Host-Computer laufenden Anwendungsprogramm geschickt wird und der Krafteffekt-Erstellungsbefehl die Speicherung bestimmter Krafteffektdaten für einen bestimmten Krafteffekt in einem örtlichen Speicher der Kraftrückkopplungsvorrichtung anweist; gekennzeichnet durch: – Bestimmen, ob der örtliche Speicher genügend Platz hat, wobei das Bestimmen das Vergleichen einer Priorität des bestimmten Krafteffekts mit einer Priorität des geladenen Krafteffekts einschießt, – falls der örtliche Speicher tatsächlich genügend Platz hat, Senden der bestimmten Krafteffektdaten an die Kraftrückkopplungsvorrichtung zur Speicherung in dem örtlichen Speicher; und – falls der örtliche Speicher nicht genügend Platz hat, Speichern der bestimmten Krafteffektdaten in einem im Speicher des Host-Computers implementierten Cache-Speicher anstatt in dem örtlichen Speicher.
  9. Verfahren nach Anspruch 8, ferner umfassend das Empfangen eines Steuerbefehls von dem Anwendungsprogramm durch den Treiber zur Ausgabe des bestimmten Krafteffektes an einen Benutzer der Kraftrückkopplungsvorrichtung, wobei wenn die bestimmten Krafteffektdaten in dem Cache-Speicher gespeichert sind, der Treiber die bestimmten Krafteffektdaten mit geladenen Krafteffektdaten in dem örtlichen Speicher überlagert und die Kraftrückkopplungsvorrichtung zur Ausgabe des bestimmten Krafteffektes anweist.
  10. Verfahren nach Anspruch 9, wobei der Treiber eine Darstellung des örtlichen Speichers in dem Speicher des Host-Computers erzeugt.
  11. Verfahren nach Anspruch 10, wobei die Darstellung und der Gerätespeicher jeweils einen Effektblock und einen Parameterblock einschließen, wobei ein Feldname des bestimmten Krafteffektes in dem Effektblock gespeichert wird und zumindest ein Parameter für den bestimmten Krafteffekt in dem Parameterblock gespeichert wird.
  12. Verfahren nach Anspruch 10, wobei das Bestimmen, ob der örtliche Speicher genügend Platz hat, das Überprüfen der Darstellung auf genügend Platz einschließt.
  13. Verfahren nach Anspruch 9, wobei das Bestimmen, ob der örtliche Speicher genügend Platz hat, das Abfragen der Kraftrückkopplungsvorrichtung und Empfangen einer Antwort mit der Angabe, ob genügend Platz verfügbar ist, einschließt.
  14. Verfahren nach Anspruch 1, wobei die Priorität des bestimmten Krafteffektes mit jeder Priorität der Vielzahl von in dem Gerätespeicher geladenen Krafteffekten verglichen wird.
  15. Verfahren nach Anspruch 1, wobei die Priorität des geladenen Krafteffektes zumindest teilweise basierend darauf bestimmt wird, ob der geladene Krafteffekt gegenwärtig von der Vorrichtung ausgegeben wird.
  16. Verfahren nach Anspruch 15, wobei die Priorität des geladenen Krafteffektes zumindest teilweise basierend auf der Zeitspanne bestimmt wird, seit der geladene Krafteffekt zuletzt von der Vorrichtung ausgegeben wurde.
  17. Verfahren nach Anspruch 1, wobei die Prioritäten des bestimmten Krafteffektes und des geladenen Krafteffektes zumindest teilweise basierend darauf ausgegeben werden, ob der geladene Krafteffekt wahrscheinlich auf der Basis einer Bewegungsrichtung eines Handhabungsgeräts der Kraftrückkopplungsvorrichtung in einem Arbeitsraum des Handhabungsgeräts ausgegeben wird.
  18. Verfahren nach Anspruch 17, wobei die Ausgabewahrscheinlichkeit der bestimmten und geladenen Krafteffekte auch auf einer Geschwindigkeit des Handhabungsgeräts der Kraftrückkopplungsvorrichtung in dem Arbeitsraum basiert.
  19. Verfahren nach Anspruch 17, wobei das Handhabungsgerät einen Weg eines Positionsanzeigers in einer von dem Host-Computer angezeigten graphischen Benutzeroberfläche steuert.
  20. Verfahren nach Anspruch 1, wobei die Priorität des geladenen Krafteffektes zumindest teilweise auf einer dem geladenen Krafteffekt zugeordneten vordefinierten Priorität basierend bestimmt wird.
  21. Verfahren nach Anspruch 20, wobei die vordefinierte Priorität basierend auf einem Typus des Krafteffektes zugeordnet wurde.
  22. Verfahren nach Anspruch 20, wobei die vordefinierte Priorität durch das Anwendungsprogramm zugeordnet wurde.
  23. Verfahren nach Anspruch 8, wobei der Krafteffekt-Erstellungsbefehl bestimmt, dass zumindest einer aus einer Vielzahl von Krafteffekten in eine Kategorie eingruppiert wird, und wobei der Erstellungsbefehl die Speicherung von Krafteffektdaten für diese Kategorie von Krafteffekten im örtlichen Speicher der Kraftrückkopplungsvorrichtung anstelle einer vorhandenen Kategorie geladener Krafteffekte anweist.
  24. Verfahren nach Anspruch 9, wobei wenn der örtliche Speicher nicht genügend Platz hat, der bestimmte Krafteffekt einen Wartestatus erhält, so dass die Krafteffektdaten für den bestimmten Krafteffekt zu einem späteren Zeitpunkt an den Gerätespeicher geschickt werden.
  25. Vorrichtung zur Handhabung der Speicherung von Krafteffekten in einem Kraftrückkopplungssystem, wobei das Kraftrückkopplungssystem eine mit einem Host-Computer verbundene Kraftrückkopplungsvorrichtung einschließt und die Vorrichtung umfasst: – Mittel zum Empfangen eines Krafteffekt-Erstellungsbefehls durch einen auf dem Host-Computer laufenden Treiber, wobei der Steuerbefehl von einem auf dem Host-Computer laufenden Anwendungsprogramm geschickt wird und der Krafteffekt-Erstellungsbefehl die Speicherung bestimmter Krafteffektdaten für einen bestimmten Krafteffekt im örtlichen Speicher der Kraftrückkopplungsvorrichtung anweist; gekennzeichnet durch: – Mittel zum Bestimmen, ob der örtliche Speicher genügend Platz hat, wobei die Mittel zum Bestimmen Mittel zum Vergleichen einer Priorität des bestimmten Krafteffekts mit einer Priorität des geladenen Krafteffekts einschließen, wobei, falls der örtliche Speicher tatsächlich genügend Platz hat, die bestimmten Krafteffektdaten an die Kraftrückkopplungsvorrichtung zur Speicherung in dem örtlichen Speicher geschickt werden, und wobei, falls der örtliche Speicher nicht genügend Platz hat, die bestimmten Krafteffektdaten in einem im Speicher des Host-Computers implementierten Cache-Speicher anstatt in dem örtlichen Speicher gespeichert werden; und – Mittel zum Empfangen eines Steuerbefehls von dem Anwendungsprogramm durch den Treiber zur Ausgabe des bestimmten Krafteffektes an einen Benutzer der Kraftrückkopplungsvorrichtung, wobei wenn die bestimmten Krafteffektdaten in dem Cache-Speicher gespeichert sind, der Treiber die bestimmten Krafteffektdaten mit geladenen Krafteffektdaten in dem örtlichen Speicher überlagert und die Kraftrückkopplungsvorrichtung zur Ausgabe des bestimmten Krafteffektes anweist.
  26. Vorrichtung nach Anspruch 25, wobei der Treiber eine Darstellung des örtlichen Speichers in dem Speicher des Host-Computers erzeugt, wobei die Mittel zum Bestimmen, ob der örtliche Speicher genügend Platz hat, Mittel zum Überprüfen der Darstellung auf genügend Platz einschließen.
  27. Vorrichtung nach Anspruch 25, wobei der Krafteffekt-Erstellungsbefehl bestimmt, dass zumindest einer aus einer Vielzahl von Krafteffekten in eine Kategorie eingruppiert wird, und wobei der Steuerbefehl die Speicherung von Krafteffektdaten für diese Kategorie von Krafteffekten im örtlichen Speicher der Kraftrückkopplungsvorrichtung anstelle einer vorhandenen Kategorie geladener Krafteffekte anweist.
  28. Verfahren zur Ausgabe von Krafteffekten von einer an einen Host-Computer gekoppelten Kraftrückkopplungsvorrichtung, wobei das Verfahren umfasst: – Empfangen eines Krafteffekt-Wiedergabebefehls von dem Host-Computer, wobei der Wiedergabebefehl die Ausgabe eines bestimmten Krafteffektes durch die Kraftrückkopplungsvorrichtung anweist, wobei der bestimmte Krafteffekt in Form von Daten in einem örtlichen Speicher der Kraftrückkopplungsvorrichtung gespeichert wird und der örtliche Speicher auch Daten für zumindest einen anderen Krafteffekt speichert: gekennzeichnet durch; – Speichern einer Kennzeichnung des bestimmten Krafteffektes in einem Schlitz in einer Wiedergabeliste in dem örtlichen Speicher; – Überprüfen der Wiedergabeliste zum Bestimmen, welche aus einer Vielzahl von gespeicherten Krafteffekten zur Ausgabe vorgesehen sind; – Bestimmen einer Kraft basierend auf den in der Wiedergabeliste bezeichneten Krafteffekten und Ausgeben der Kraft an einen Benutzer der Kraftrückkopplungsvorrichtung; und – Entfernung der Kennzeichnung des bestimmten Krafteffektes aus dem Schlitz in dar Wiedergabeliste.
  29. Verfahren nach Anspruch 28, wobei die Kraft, die basierend auf den in der Wiedergabeliste bezeichneten Krafteffekten bestimmt wird, ehe Summe der bezeichneten Krafteffekte ist.
  30. Verfahren nach Anspruch 28, wobei ferner in dem örtlichen Speicher eine Zahl gespeichert wird, die angibt, wie viele der in dem örtlichen Speicher gespeicherten Krafteffekte gegenwärtig zur Ausgabe vorgesehen sind.
  31. Verfahren nach Anspruch 30, wobei die Überprüfung der Wiedergabeliste das Überprüfen dieser Zahl einschließt, um zu bestimmen, wie viele Krafteffekte in der Wiedergabeliste sind.
  32. Verfahren nach Anspruch 31, wobei die Krafteffekte in der Wiedergabeliste in fortlaufenden Schlitzen in der Wiedergabeliste bereitgestellt sind.
  33. Verfahren nach Anspruch 28, ferner umfassend: – Empfangen eines Krafteffekt-Erstellungsbefehls von dem Host-Computer vor Empfangen des Krafteffekt-Wiedergabebefehls, wobei der Erstellungsbefehl Krafteffektdaten zur Kennzeichnung eines Krafteffektes einschließt; und – Speichern der Krafteffektdaten in dem örtlichen Speicher der Kraftrückkopplungsvorrichtung an einer durch den Erstellungsbefehl angegebenen Stelle.
  34. Verfahren nach Anspruch 1, wobei das Bestimmen, ob die Speichervorrichtung die Krafteffekte speichern kann, umfasst: – Bestimmen der Priorität des Krafteffekts, – Identifikation eines geladenen Krafteffektes, der in der Speichervorrichtung gespeichert ist und eine geringere Priorität als der bestimmte Krafteffekt hat; und – falls die bestimmte Speichervorrichtung ungenügend Platz hat, um den bestimmten Krafteffekt zu speichern: – Löschen des gespeicherten Krafteffektes geringerer Priorität aus der Speichervorrichtung, und – Senden der Daten des bestimmten Krafteffekts an die Kraftrückkopplungsvorrichtung zur Speicherung in der Speichervorrichtung.
DE10082696T 1999-05-05 2000-05-05 Verfahren zur Bereitstellung von Krafteffekten mittels einer Kraftrückkopplungsvorrichtung und Vorrichtung hierfür Expired - Lifetime DE10082696B3 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/305,872 US6252583B1 (en) 1997-11-14 1999-05-05 Memory and force output management for a force feedback system
US09/305,872 1999-05-05
PCT/US2000/012225 WO2000067245A1 (en) 1999-05-05 2000-05-05 Memory and force output management for a force feedback system

Publications (2)

Publication Number Publication Date
DE10082696T1 DE10082696T1 (de) 2002-01-31
DE10082696B3 true DE10082696B3 (de) 2012-12-27

Family

ID=23182727

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10082696T Expired - Lifetime DE10082696B3 (de) 1999-05-05 2000-05-05 Verfahren zur Bereitstellung von Krafteffekten mittels einer Kraftrückkopplungsvorrichtung und Vorrichtung hierfür

Country Status (5)

Country Link
US (4) US6252583B1 (de)
AU (1) AU4701000A (de)
DE (1) DE10082696B3 (de)
GB (1) GB2353116B (de)
WO (1) WO2000067245A1 (de)

Families Citing this family (128)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5691897A (en) * 1995-05-30 1997-11-25 Roy-G-Biv Corporation Motion control systems
US20060206219A1 (en) * 1995-05-30 2006-09-14 Brown David W Motion control systems and methods
US20100131081A1 (en) * 1995-05-30 2010-05-27 Brown David W Systems and methods for motion control
US6300936B1 (en) 1997-11-14 2001-10-09 Immersion Corporation Force feedback system including multi-tasking graphical host environment and interface device
US6411276B1 (en) 1996-11-13 2002-06-25 Immersion Corporation Hybrid control of haptic feedback for host computer and interface device
US6956558B1 (en) * 1998-03-26 2005-10-18 Immersion Corporation Rotary force feedback wheels for remote control devices
US6996096B2 (en) * 1997-02-14 2006-02-07 Canon Kabushiki Kaisha Communication apparatus and a method of controlling a communication apparatus
US20010032278A1 (en) 1997-10-07 2001-10-18 Brown Stephen J. Remote generation and distribution of command programs for programmable devices
US6252583B1 (en) * 1997-11-14 2001-06-26 Immersion Corporation Memory and force output management for a force feedback system
IL123073A0 (en) 1998-01-26 1998-09-24 Simbionix Ltd Endoscopic tutorial system
US6878066B2 (en) * 1998-02-13 2005-04-12 Freedom Wave Llc Wireless game control units
US20100131078A1 (en) * 1999-10-27 2010-05-27 Brown David W Event driven motion systems
US8032605B2 (en) * 1999-10-27 2011-10-04 Roy-G-Biv Corporation Generation and distribution of motion commands over a distributed network
US6976215B1 (en) * 1999-12-20 2005-12-13 Vulcan Patents Llc Pushbutton user interface with functionality preview
US7965276B1 (en) * 2000-03-09 2011-06-21 Immersion Corporation Force output adjustment in force feedback devices based on user contact
US7181693B1 (en) * 2000-03-17 2007-02-20 Gateway Inc. Affective control of information systems
US8160863B2 (en) 2000-03-28 2012-04-17 Ionipas Transfer Company, Llc System and method for connecting a logic circuit simulation to a network
US7266490B2 (en) 2000-12-28 2007-09-04 Robert Marc Zeidman Apparatus and method for connecting hardware to a circuit simulation
US7917869B2 (en) * 2000-05-06 2011-03-29 Anderson Thomas G Human-computer interface incorporating personal and application domains
US6710764B1 (en) * 2000-05-09 2004-03-23 Logitech Europe S.A. Method and system for processing force feedback effects generated at a host for playback at a physical interaction device
US7084854B1 (en) 2000-09-28 2006-08-01 Immersion Corporation Actuator for providing tactile sensations and device for directional tactile sensations
US8641644B2 (en) 2000-11-21 2014-02-04 Sanofi-Aventis Deutschland Gmbh Blood testing apparatus having a rotatable cartridge with multiple lancing elements and testing means
US20070016396A9 (en) * 2000-12-28 2007-01-18 Zeidman Robert M Apparatus and method for connecting a hardware emulator to a computer peripheral
US6641480B2 (en) * 2001-01-29 2003-11-04 Microsoft Corporation Force feedback mechanism for gamepad device
US20020135615A1 (en) * 2001-01-31 2002-09-26 Microsoft Corporation Overlaid display for electronic devices
US20020101457A1 (en) * 2001-01-31 2002-08-01 Microsoft Corporation Bezel interface for small computing devices
WO2002071241A1 (en) * 2001-02-09 2002-09-12 Roy-G-Biv Corporation Event management systems and methods for the distribution of motion control commands
US7904194B2 (en) * 2001-02-09 2011-03-08 Roy-G-Biv Corporation Event management systems and methods for motion control systems
US9226699B2 (en) 2002-04-19 2016-01-05 Sanofi-Aventis Deutschland Gmbh Body fluid sampling module with a continuous compression tissue interface surface
US9427532B2 (en) 2001-06-12 2016-08-30 Sanofi-Aventis Deutschland Gmbh Tissue penetration device
US7025774B2 (en) 2001-06-12 2006-04-11 Pelikan Technologies, Inc. Tissue penetration device
US9795747B2 (en) 2010-06-02 2017-10-24 Sanofi-Aventis Deutschland Gmbh Methods and apparatus for lancet actuation
US6937033B2 (en) * 2001-06-27 2005-08-30 Immersion Corporation Position sensor with resistive element
US7056123B2 (en) 2001-07-16 2006-06-06 Immersion Corporation Interface apparatus with cable-driven force feedback and grounded actuators
WO2003019397A1 (en) * 2001-08-31 2003-03-06 Roy-G-Biv Corporation Motion services protocol accessible through uniform resource locator (url)
US7623114B2 (en) 2001-10-09 2009-11-24 Immersion Corporation Haptic feedback sensations based on audio output from computer devices
US6703550B2 (en) 2001-10-10 2004-03-09 Immersion Corporation Sound data output and manipulation using haptic feedback
JP4785320B2 (ja) * 2002-01-31 2011-10-05 キヤノン株式会社 記憶装置
US7547287B2 (en) 2002-04-19 2009-06-16 Pelikan Technologies, Inc. Method and apparatus for penetrating tissue
US8579831B2 (en) 2002-04-19 2013-11-12 Sanofi-Aventis Deutschland Gmbh Method and apparatus for penetrating tissue
US8784335B2 (en) 2002-04-19 2014-07-22 Sanofi-Aventis Deutschland Gmbh Body fluid sampling device with a capacitive sensor
US8702624B2 (en) 2006-09-29 2014-04-22 Sanofi-Aventis Deutschland Gmbh Analyte measurement device with a single shot actuator
US9795334B2 (en) 2002-04-19 2017-10-24 Sanofi-Aventis Deutschland Gmbh Method and apparatus for penetrating tissue
US9248267B2 (en) 2002-04-19 2016-02-02 Sanofi-Aventis Deustchland Gmbh Tissue penetration device
US7713214B2 (en) 2002-04-19 2010-05-11 Pelikan Technologies, Inc. Method and apparatus for a multi-use body fluid sampling device with optical analyte sensing
US9314194B2 (en) 2002-04-19 2016-04-19 Sanofi-Aventis Deutschland Gmbh Tissue penetration device
JP3986885B2 (ja) * 2002-05-16 2007-10-03 アルプス電気株式会社 力覚付与装置
CN100349112C (zh) * 2002-09-05 2007-11-14 中兴通讯股份有限公司 对数字接口进行多功能测试的方法及设备
DE10245354A1 (de) * 2002-09-27 2004-04-08 Philips Intellectual Property & Standards Gmbh Fernsteuerung
US7350590B2 (en) * 2002-11-05 2008-04-01 Weatherford/Lamb, Inc. Instrumentation for a downhole deployment valve
US7103526B2 (en) * 2002-10-16 2006-09-05 Agilent Technologies, Inc. Method and apparatus for adapting a simulation model to expose a signal internal to the model to a client application
US8574895B2 (en) 2002-12-30 2013-11-05 Sanofi-Aventis Deutschland Gmbh Method and apparatus using optical techniques to measure analyte levels
JP2004252756A (ja) * 2003-02-20 2004-09-09 Fujitsu Ltd 物体干渉表現装置
US20040194153A1 (en) * 2003-03-24 2004-09-30 Sony Corporation And Sony Electronics Inc. Conservation of system resources by efficiently activating/de-activating applications
JP2004325828A (ja) * 2003-04-25 2004-11-18 Namco Ltd シミュレータ、プログラム及び情報記憶媒体
WO2006001797A1 (en) 2004-06-14 2006-01-05 Pelikan Technologies, Inc. Low pain penetrating
US6836982B1 (en) 2003-08-14 2005-01-04 Caterpillar Inc Tactile feedback system for a remotely controlled work machine
US20070022194A1 (en) * 2003-09-25 2007-01-25 Brown David W Database event driven motion systems
US8027349B2 (en) 2003-09-25 2011-09-27 Roy-G-Biv Corporation Database event driven motion systems
US20060064503A1 (en) * 2003-09-25 2006-03-23 Brown David W Data routing systems and methods
WO2005033659A2 (en) 2003-09-29 2005-04-14 Pelikan Technologies, Inc. Method and apparatus for an improved sample capture device
EP1680014A4 (de) 2003-10-14 2009-01-21 Pelikan Technologies Inc Verfahren und gerät für eine variable anwenderschnittstelle
EP1690173A4 (de) * 2003-11-17 2010-04-21 Roy G Biv Corp Befehlsverarbeitungssysteme und -verfahren
US7982711B2 (en) * 2003-12-19 2011-07-19 Immersion Corporation Haptic profiling system and method
US7791588B2 (en) * 2003-12-22 2010-09-07 Immersion Corporation System and method for mapping instructions associated with haptic feedback
US7742036B2 (en) 2003-12-22 2010-06-22 Immersion Corporation System and method for controlling haptic devices having multiple operational modes
US7667687B2 (en) * 2003-12-30 2010-02-23 Immersion Corporation Resistive and hybrid control schemes for haptic feedback interface devices
US8668656B2 (en) 2003-12-31 2014-03-11 Sanofi-Aventis Deutschland Gmbh Method and apparatus for improving fluidic flow and sample capture
US20050210416A1 (en) * 2004-03-16 2005-09-22 Maclaurin Matthew B Interactive preview of group contents via axial controller
SE526936C2 (sv) * 2004-04-01 2005-11-22 A2 Acoustics Ab Anordning för vibrationsstyrning i motorfordon på så sätt att önskad vibrationskaraktär i ratten erhålles
US20050257150A1 (en) * 2004-05-11 2005-11-17 Universite Des Sciences Et Technologies De Lille Ground-based haptic interface comprising at least two decoupled rotary finger actuators
WO2006011062A2 (en) 2004-05-20 2006-02-02 Albatros Technologies Gmbh & Co. Kg Printable hydrogel for biosensors
EP1765194A4 (de) 2004-06-03 2010-09-29 Pelikan Technologies Inc Verfahren und gerät für eine flüssigkeitsentnahmenvorrichtung
US9775553B2 (en) 2004-06-03 2017-10-03 Sanofi-Aventis Deutschland Gmbh Method and apparatus for a fluid sampling device
US7765333B2 (en) 2004-07-15 2010-07-27 Immersion Corporation System and method for ordering haptic effects
WO2006042309A1 (en) 2004-10-08 2006-04-20 Immersion Corporation Haptic feedback for button and scrolling action simulation in touch input devices
GB2422692B (en) * 2005-01-31 2009-08-12 Hewlett Packard Development Co Software updates for electronic appliances
US8355804B2 (en) * 2005-09-15 2013-01-15 Honda Motor Co., Ltd. Interface for sensor query and control
US8700791B2 (en) 2005-10-19 2014-04-15 Immersion Corporation Synchronization of haptic effect data in a media transport stream
WO2007047986A1 (en) * 2005-10-21 2007-04-26 Wisconsin Alumni Research Foundation Method and system for delivering nucleic acid into a target cell
US7750593B2 (en) * 2006-10-26 2010-07-06 Honeywell International Inc. Active human-machine interface system without a force sensor
US20090262074A1 (en) * 2007-01-05 2009-10-22 Invensense Inc. Controlling and accessing content using motion processing on mobile devices
US8250921B2 (en) 2007-07-06 2012-08-28 Invensense, Inc. Integrated motion processing unit (MPU) with MEMS inertial sensing and embedded digital electronics
US7934423B2 (en) * 2007-12-10 2011-05-03 Invensense, Inc. Vertically integrated 3-axis MEMS angular accelerometer with integrated electronics
US8141424B2 (en) 2008-09-12 2012-03-27 Invensense, Inc. Low inertia frame for detecting coriolis acceleration
US8047075B2 (en) 2007-06-21 2011-11-01 Invensense, Inc. Vertically integrated 3-axis MEMS accelerometer with electronics
US8462109B2 (en) * 2007-01-05 2013-06-11 Invensense, Inc. Controlling and accessing content using motion processing on mobile devices
US7796872B2 (en) * 2007-01-05 2010-09-14 Invensense, Inc. Method and apparatus for producing a sharp image from a handheld device containing a gyroscope
US8952832B2 (en) 2008-01-18 2015-02-10 Invensense, Inc. Interfacing application programs and motion sensors of a device
US8508039B1 (en) 2008-05-08 2013-08-13 Invensense, Inc. Wafer scale chip scale packaging of vertically integrated MEMS sensors with electronics
US20100071467A1 (en) * 2008-09-24 2010-03-25 Invensense Integrated multiaxis motion sensor
US20090265671A1 (en) * 2008-04-21 2009-10-22 Invensense Mobile devices with motion gesture recognition
US8020441B2 (en) * 2008-02-05 2011-09-20 Invensense, Inc. Dual mode sensing for vibratory gyroscope
US8098234B2 (en) * 2007-02-20 2012-01-17 Immersion Corporation Haptic feedback system with stored effects
US8315652B2 (en) * 2007-05-18 2012-11-20 Immersion Corporation Haptically enabled messaging
MX2008014783A (es) * 2008-02-05 2009-08-27 Krueger Int Inc Armazon para silla con soporte hueco ergonomico integral.
US8271951B2 (en) * 2008-03-04 2012-09-18 International Business Machines Corporation System and methods for collecting software development feedback
BRPI0804355A2 (pt) * 2008-03-10 2009-11-03 Lg Electronics Inc terminal e método de controle do mesmo
US20110029706A1 (en) * 2008-04-09 2011-02-03 Nxp B.V. Electronic device and method for controlling an electronic device
EP2265324B1 (de) 2008-04-11 2015-01-28 Sanofi-Aventis Deutschland GmbH Integriertes System zur Messung von Analyten
US8749495B2 (en) * 2008-09-24 2014-06-10 Immersion Corporation Multiple actuation handheld device
US8690575B1 (en) 2008-11-03 2014-04-08 ACME Worldwide Enterprises, Inc. Apparatus and method for a weapon simulator
US20100167820A1 (en) * 2008-12-29 2010-07-01 Houssam Barakat Human interface device
KR101650371B1 (ko) * 2008-12-30 2016-08-24 삼성전자주식회사 중력에 의해 이동되는 감각적 효과를 나타내는 포인터를 이용한 ｇｕｉ 제공방법 및 이를 적용한 전자장치
US9375169B2 (en) 2009-01-30 2016-06-28 Sanofi-Aventis Deutschland Gmbh Cam drive for managing disposable penetrating member actions with a single motor and motor and control system
TWI423032B (zh) * 2009-04-30 2014-01-11 Ralink Technology Corp 提升資料傳輸效能的方法
US8009022B2 (en) * 2009-05-29 2011-08-30 Microsoft Corporation Systems and methods for immersive interaction with virtual objects
JP5847407B2 (ja) * 2010-03-16 2016-01-20 イマージョン コーポレーションＩｍｍｅｒｓｉｏｎ Ｃｏｒｐｏｒａｔｉｏｎ プレタッチ及びトゥルータッチのためのシステム及び方法
US8965476B2 (en) 2010-04-16 2015-02-24 Sanofi-Aventis Deutschland Gmbh Tissue penetration device
US8407608B1 (en) 2010-05-27 2013-03-26 Amazon Technologies, Inc. Touch input assist
US8386927B1 (en) * 2010-05-27 2013-02-26 Amazon Technologies, Inc. Gravity-based link assist
US9132352B1 (en) 2010-06-24 2015-09-15 Gregory S. Rabin Interactive system and method for rendering an object
US8798534B2 (en) 2010-07-09 2014-08-05 Digimarc Corporation Mobile devices and methods employing haptics
US8564535B2 (en) * 2010-10-05 2013-10-22 Immersion Corporation Physical model based gesture recognition
US9056244B2 (en) 2012-09-12 2015-06-16 Wms Gaming Inc. Gaming apparatus incorporating targeted haptic feedback
KR20140068410A (ko) * 2012-11-28 2014-06-09 삼성전자주식회사 물리 엔진 기반의 사용자 인터페이스를 제공하는 방법 및 그 전자 장치
ITMI20130495A1 (it) * 2013-03-29 2014-09-30 Atlas Copco Blm Srl Dispositivo elettronico di controllo e comando per sensori
US20150113452A1 (en) * 2013-10-17 2015-04-23 Cyan Inc. Graphical user interface
US9164587B2 (en) * 2013-11-14 2015-10-20 Immersion Corporation Haptic spatialization system
US9619029B2 (en) 2013-11-14 2017-04-11 Immersion Corporation Haptic trigger control system
US9838009B2 (en) 2014-08-27 2017-12-05 Continental Automotive Systems, Inc. Switch with user feedback
US10185396B2 (en) 2014-11-12 2019-01-22 Immersion Corporation Haptic trigger modification system
US9174134B1 (en) 2014-11-12 2015-11-03 Immersion Corporation Peripheral device with haptic diminishment prevention component
US10613629B2 (en) 2015-03-27 2020-04-07 Chad Laurendeau System and method for force feedback interface devices
JP2016225692A (ja) * 2015-05-27 2016-12-28 ヤマハ株式会社 音信号処理装置
US11175738B2 (en) 2016-12-13 2021-11-16 Immersion Corporation Systems and methods for proximity-based haptic feedback
US11494177B2 (en) * 2019-09-30 2022-11-08 SlackTechnologies, LLC Method, apparatus, and computer program product for organizing the booting operation of a group-based communication browser session
US20220291946A1 (en) * 2021-03-15 2022-09-15 International Business Machines Corporation Software container configuration

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5734373A (en) * 1993-07-16 1998-03-31 Immersion Human Interface Corporation Method and apparatus for controlling force feedback interface systems utilizing a host computer
EP1036390B1 (de) * 1997-11-14 2004-11-03 Immersion Corporation Methode der Steuerung einer Kraft-Rückkopplung-Vorrichtung in einer multi-tasking grafischen Wirtsumgebung

Family Cites Families (154)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3157853A (en) 1957-12-06 1964-11-17 Hirsch Joseph Tactile communication system
GB958325A (en) 1962-07-08 1964-05-21 Communications Patents Ltd Improvements in or relating to ground-based flight training or simulating apparatus
US3497668A (en) 1966-08-25 1970-02-24 Joseph Hirsch Tactile control system
US3517446A (en) 1967-04-19 1970-06-30 Singer General Precision Vehicle trainer controls and control loading
US3903614A (en) 1970-03-27 1975-09-09 Singer Co Apparatus for simulating aircraft control loading
US3919691A (en) 1971-05-26 1975-11-11 Bell Telephone Labor Inc Tactile man-machine communication system
US3902687A (en) 1973-06-25 1975-09-02 Robert E Hightower Aircraft indicator system
US4160508A (en) 1977-08-19 1979-07-10 Nasa Controller arm for a remotely related slave arm
FR2411603A2 (fr) 1977-12-19 1979-07-13 Zarudiansky Alain Dispositif et procede d'enregistrement de restitution et de synthese de sensations tactiles
US4236325A (en) 1978-12-26 1980-12-02 The Singer Company Simulator control loading inertia compensator
US4599070A (en) 1981-07-29 1986-07-08 Control Interface Company Limited Aircraft simulator and simulated control system therefor
DE3380420D1 (en) 1982-01-22 1989-09-21 British Aerospace Control apparatus
US4560983A (en) 1982-09-17 1985-12-24 Ampex Corporation Dynamically interactive responsive control device and system
US4477043A (en) 1982-12-15 1984-10-16 The United States Of America As Represented By The Secretary Of The Air Force Biodynamic resistant control stick
JPS6029833A (ja) 1983-07-28 1985-02-15 Canon Inc 画像表示装置
US4604016A (en) 1983-08-03 1986-08-05 Joyce Stephen A Multi-dimensional force-torque hand controller having force feedback
US4581491A (en) 1984-05-04 1986-04-08 Research Corporation Wearable tactile sensory aid providing information on voice pitch and intonation patterns
IT1175678B (it) * 1984-08-31 1987-07-15 Mangnaghi Oleodinamica Spa Gruppo servoattuatore ridondante particolarmente per l'azionamento di organi di controllo di volo in velivoli
US4782327A (en) 1985-01-02 1988-11-01 Victor B. Kley Computer control
JPH0537531Y2 (de) 1985-06-11 1993-09-22
US5078152A (en) 1985-06-23 1992-01-07 Loredan Biomedical, Inc. Method for diagnosis and/or training of proprioceptor feedback capabilities in a muscle and joint system of a human patient
US4713007A (en) 1985-10-11 1987-12-15 Alban Eugene P Aircraft controls simulator
US5275174B1 (en) 1985-10-30 1998-08-04 Jonathan A Cook Repetitive strain injury assessment
NL8503096A (nl) 1985-11-11 1987-06-01 Fokker Bv Simulator van mechanische eigenschappen van een besturingssysteem.
US4934694A (en) 1985-12-06 1990-06-19 Mcintosh James L Computer controlled exercise system
US5103404A (en) 1985-12-06 1992-04-07 Tensor Development, Inc. Feedback for a manipulator
US4891764A (en) 1985-12-06 1990-01-02 Tensor Development Inc. Program controlled force measurement and control system
JPH085018B2 (ja) 1986-02-26 1996-01-24 株式会社日立製作所 遠隔マニピユレ−シヨン方法及び装置
NL8602624A (nl) 1986-10-20 1988-05-16 Oce Nederland Bv Invoerinrichting met taktiele terugkoppeling.
US4800721A (en) 1987-02-13 1989-01-31 Caterpillar Inc. Force feedback lever
JPS643664A (en) 1987-06-26 1989-01-09 Hitachi Ltd Laser beam marking device
JPH0778659B2 (ja) 1987-06-26 1995-08-23 キヤノン株式会社 弾性回転体及びそれを有する定着装置
US4823634A (en) 1987-11-03 1989-04-25 Culver Craig F Multifunction tactile manipulatable control
AU616213B2 (en) * 1987-11-09 1991-10-24 Tandem Computers Incorporated Method and apparatus for synchronizing a plurality of processors
US5038089A (en) 1988-03-23 1991-08-06 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Synchronized computational architecture for generalized bilateral control of robot arms
NL8801653A (nl) 1988-06-29 1990-01-16 Stork Kwant Bv Besturingsstelsel.
US5116180A (en) 1988-07-18 1992-05-26 Spar Aerospace Limited Human-in-the-loop machine control loop
JP2926721B2 (ja) 1988-10-20 1999-07-28 スズキ株式会社 スタビライザ取付構造
US4930770A (en) 1988-12-01 1990-06-05 Baker Norman A Eccentrically loaded computerized positive/negative exercise machine
US4965717A (en) * 1988-12-09 1990-10-23 Tandem Computers Incorporated Multiple processor system having shared memory with private-write capability
US5044956A (en) 1989-01-12 1991-09-03 Atari Games Corporation Control device such as a steering wheel for video vehicle simulator with realistic feedback forces
US4949119A (en) 1989-01-12 1990-08-14 Atari Games Corporation Gearshift for a vehicle simulator using computer controlled realistic real world forces
US5186695A (en) 1989-02-03 1993-02-16 Loredan Biomedical, Inc. Apparatus for controlled exercise and diagnosis of human performance
US5019761A (en) 1989-02-21 1991-05-28 Kraft Brett W Force feedback control for backhoe
US4983901A (en) 1989-04-21 1991-01-08 Allergan, Inc. Digital electronic foot control for medical apparatus and the like
US5076517A (en) 1989-08-14 1991-12-31 United Technologies Corporation Programmable, linear collective control system for a helicopter
US4961038A (en) 1989-10-16 1990-10-02 General Electric Company Torque estimator for switched reluctance machines
US5022407A (en) 1990-01-24 1991-06-11 Topical Testing, Inc. Apparatus for automated tactile testing
US5184319A (en) 1990-02-02 1993-02-02 Kramer James F Force feedback and textures simulating interface device
GB9004690D0 (en) 1990-03-02 1990-04-25 Black & Decker Inc Flange mounting arrangement
US5247648A (en) * 1990-04-12 1993-09-21 Sun Microsystems, Inc. Maintaining data coherency between a central cache, an I/O cache and a memory
US5035242A (en) 1990-04-16 1991-07-30 David Franklin Method and apparatus for sound responsive tactile stimulation of deaf individuals
JPH0685820B2 (ja) 1990-04-25 1994-11-02 株式会社エポック社 体感ゲーム機
JPH047371A (ja) 1990-04-25 1992-01-10 Canon Inc 画像記録用インク
GB9014130D0 (en) 1990-06-25 1990-08-15 Hewlett Packard Co User interface
US5547382A (en) 1990-06-28 1996-08-20 Honda Giken Kogyo Kabushiki Kaisha Riding simulation system for motorcycles
US5197003A (en) 1990-08-01 1993-03-23 Atari Games Corporation Gearshift for a vehicle simulator having a solenoid for imposing a resistance force
US5181181A (en) 1990-09-27 1993-01-19 Triton Technologies, Inc. Computer apparatus input device for three-dimensional information
US5132927A (en) * 1990-10-09 1992-07-21 Tandem Computers Incorporated System for cache space allocation using selective addressing
US5209661A (en) 1990-10-29 1993-05-11 Systems Control Technology, Inc. Motor control desired dynamic load of a simulating system and method
US5193963A (en) 1990-10-31 1993-03-16 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Force reflecting hand controller
NL194053C (nl) 1990-12-05 2001-05-03 Koninkl Philips Electronics Nv Inrichting met een rotatiesymmetrisch lichaam.
US5223776A (en) 1990-12-31 1993-06-29 Honeywell Inc. Six-degree virtual pivot controller
US5212473A (en) 1991-02-21 1993-05-18 Typeright Keyboard Corp. Membrane keyboard and method of using same
US5334027A (en) 1991-02-25 1994-08-02 Terry Wherlock Big game fish training and exercise device and method
US5354162A (en) 1991-02-26 1994-10-11 Rutgers University Actuator system for providing force feedback to portable master support
US5240417A (en) 1991-03-14 1993-08-31 Atari Games Corporation System and method for bicycle riding simulation
WO1992016922A1 (en) 1991-03-21 1992-10-01 Atari Games Corporation Vehicle simulator including cross-network feedback
US5341459A (en) 1991-05-09 1994-08-23 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Generalized compliant motion primitive
WO1992021117A1 (en) 1991-05-23 1992-11-26 Atari Games Corporation Modular display simulator
US5146566A (en) 1991-05-29 1992-09-08 Ibm Corporation Input/output system for computer user interface using magnetic levitation
US5185561A (en) 1991-07-23 1993-02-09 Digital Equipment Corporation Torque motor as a tactile feedback device in a computer system
US5186629A (en) 1991-08-22 1993-02-16 International Business Machines Corporation Virtual graphics display capable of presenting icons and windows to the blind computer user and method
US5235868A (en) 1991-10-02 1993-08-17 Culver Craig F Mechanism for generating control signals
US5220260A (en) 1991-10-24 1993-06-15 Lex Computer And Management Corporation Actuator having electronically controllable tactile responsiveness
US5889670A (en) 1991-10-24 1999-03-30 Immersion Corporation Method and apparatus for tactilely responsive user interface
US5271290A (en) 1991-10-29 1993-12-21 United Kingdom Atomic Energy Authority Actuator assembly
US5309140A (en) 1991-11-26 1994-05-03 The United States Of America As Represented By The Secretary Of The Navy Feedback system for remotely operated vehicles
JP2812598B2 (ja) 1992-01-21 1998-10-22 株式会社日立ビルシステム 昇降路内機器揚重装置
US5589828A (en) 1992-03-05 1996-12-31 Armstrong; Brad A. 6 Degrees of freedom controller with capability of tactile feedback
US5457793A (en) * 1992-03-30 1995-10-10 International Business Machines Corporation Software cache management of a shared electronic store in a supplex
US5189355A (en) 1992-04-10 1993-02-23 Ampex Corporation Interactive rotary controller system with tactile feedback
US5366376A (en) 1992-05-22 1994-11-22 Atari Games Corporation Driver training system and method with performance data feedback
US5296871A (en) 1992-07-27 1994-03-22 Paley W Bradford Three-dimensional mouse with tactile feedback
US5428748A (en) 1992-09-24 1995-06-27 National Semiconductor Corporation Method and apparatus for automatically configuring a computer peripheral
US5264768A (en) 1992-10-06 1993-11-23 Honeywell, Inc. Active hand controller feedback loop
US5286203A (en) 1992-10-07 1994-02-15 Aai Microflite Simulation International Simulating horizontal stabilizer trimming in an aircraft
US5790108A (en) 1992-10-23 1998-08-04 University Of British Columbia Controller
US5629594A (en) 1992-12-02 1997-05-13 Cybernet Systems Corporation Force feedback system
US5389865A (en) 1992-12-02 1995-02-14 Cybernet Systems Corporation Method and system for providing a tactile virtual reality and manipulator defining an interface device therefor
US6131097A (en) 1992-12-02 2000-10-10 Immersion Corporation Haptic authoring
US5769640A (en) 1992-12-02 1998-06-23 Cybernet Systems Corporation Method and system for simulating medical procedures including virtual reality and control method and system for use therein
EP0607580A1 (de) 1993-01-21 1994-07-27 International Business Machines Corporation Taktiler Rückführungsmechanismus für Zeigersteuerung
US5785630A (en) 1993-02-02 1998-07-28 Tectrix Fitness Equipment, Inc. Interactive exercise apparatus
US5907640A (en) 1993-03-25 1999-05-25 Live Picture, Inc. Functional interpolating transformation system for image processing
JP3686686B2 (ja) 1993-05-11 2005-08-24 松下電器産業株式会社 力覚呈示デバイス、データ入力装置、及びデータ入力デバイス装置
US5405152A (en) 1993-06-08 1995-04-11 The Walt Disney Company Method and apparatus for an interactive video game with physical feedback
US5396266A (en) 1993-06-08 1995-03-07 Technical Research Associates, Inc. Kinesthetic feedback apparatus and method
US5513100A (en) 1993-06-10 1996-04-30 The University Of British Columbia Velocity controller with force feedback stiffness control
US5477237A (en) 1993-06-24 1995-12-19 Dell Usa, L.P. Positioning device reporting X, Y and yaw motion
US5466213A (en) 1993-07-06 1995-11-14 Massachusetts Institute Of Technology Interactive robotic therapist
US5701140A (en) 1993-07-16 1997-12-23 Immersion Human Interface Corp. Method and apparatus for providing a cursor control interface with force feedback
US5767839A (en) 1995-01-18 1998-06-16 Immersion Human Interface Corporation Method and apparatus for providing passive force feedback to human-computer interface systems
US5805140A (en) 1993-07-16 1998-09-08 Immersion Corporation High bandwidth force feedback interface using voice coils and flexures
US5721566A (en) 1995-01-18 1998-02-24 Immersion Human Interface Corp. Method and apparatus for providing damping force feedback
US5739811A (en) * 1993-07-16 1998-04-14 Immersion Human Interface Corporation Method and apparatus for controlling human-computer interface systems providing force feedback
US5414620A (en) 1993-08-09 1995-05-09 Honeywell Inc. Synthetic friction algorithm for a hand control element
US5491477A (en) 1993-09-13 1996-02-13 Apple Computer, Inc. Anti-rotation mechanism for direct manipulation position input controller for computer
US5625576A (en) 1993-10-01 1997-04-29 Massachusetts Institute Of Technology Force reflecting haptic interface
WO1995020788A1 (en) 1994-01-27 1995-08-03 Exos, Inc. Intelligent remote multimode sense and display system utilizing haptic information compression
WO1995020787A1 (en) 1994-01-27 1995-08-03 Exos, Inc. Multimode feedback display technology
CA2140164A1 (en) 1994-01-27 1995-07-28 Kenneth R. Robertson System and method for computer cursor control
US6047356A (en) * 1994-04-18 2000-04-04 Sonic Solutions Method of dynamically allocating network node memory's partitions for caching distributed files
US6004134A (en) 1994-05-19 1999-12-21 Exos, Inc. Interactive simulation including force feedback
US5915129A (en) * 1994-06-27 1999-06-22 Microsoft Corporation Method and system for storing uncompressed data in a memory cache that is destined for a compressed file system
US5623582A (en) 1994-07-14 1997-04-22 Immersion Human Interface Corporation Computer interface or control input device for laparoscopic surgical instrument and other elongated mechanical objects
US6422941B1 (en) 1994-09-21 2002-07-23 Craig Thorner Universal tactile feedback system for computer video games and simulations
US5570111A (en) 1994-10-03 1996-10-29 International Business Machines Corporation Graphical user interface cursor positioning device having a negative inertia transfer function
US5642469A (en) 1994-11-03 1997-06-24 University Of Washington Direct-drive manipulator for pen-based force display
US5766016A (en) 1994-11-14 1998-06-16 Georgia Tech Research Corporation Surgical simulator and method for simulating surgical procedure
US5666138A (en) 1994-11-22 1997-09-09 Culver; Craig F. Interface control
JP3236180B2 (ja) 1994-12-05 2001-12-10 日本電気株式会社 座標指示装置
DE69622101T2 (de) 1995-03-13 2003-02-13 Koninkl Philips Electronics Nv 3-d-eingang durch vertikale verschiebung von maus oder rollkugel
US5882206A (en) 1995-03-29 1999-03-16 Gillio; Robert G. Virtual surgery system
US5736978A (en) 1995-05-26 1998-04-07 The United States Of America As Represented By The Secretary Of The Air Force Tactile graphics display
US5691898A (en) 1995-09-27 1997-11-25 Immersion Human Interface Corp. Safe and low cost computer peripherals with force feedback for consumer applications
US5589854A (en) 1995-06-22 1996-12-31 Tsai; Ming-Chang Touching feedback device
DE19528457C2 (de) 1995-08-03 2001-03-08 Mannesmann Vdo Ag Bedieneinrichtung
US5999168A (en) 1995-09-27 1999-12-07 Immersion Corporation Haptic accelerator for force feedback computer peripherals
US5959613A (en) 1995-12-01 1999-09-28 Immersion Corporation Method and apparatus for shaping force signals for a force feedback device
US5825308A (en) 1996-11-26 1998-10-20 Immersion Human Interface Corporation Force feedback interface having isotonic and isometric functionality
US6100874A (en) 1995-11-17 2000-08-08 Immersion Corporation Force feedback mouse interface
WO1997020305A1 (en) 1995-11-30 1997-06-05 Virtual Technologies, Inc. Tactile feedback man-machine interface device
US6028593A (en) 1995-12-01 2000-02-22 Immersion Corporation Method and apparatus for providing simulated physical interactions within computer generated environments
US5956484A (en) 1995-12-13 1999-09-21 Immersion Corporation Method and apparatus for providing force feedback over a computer network
US6078308A (en) 1995-12-13 2000-06-20 Immersion Corporation Graphical click surfaces for force feedback applications to provide user selection using cursor interaction with a trigger position within a boundary of a graphical object
US5760764A (en) 1995-12-13 1998-06-02 Altra Computer display cursor controller with serial interface
DE19646226A1 (de) 1996-03-19 1998-05-14 Bayerische Motoren Werke Ag Bedienvorrichtung für menügesteuerte Funktionen eines Fahrzeugs
US6111577A (en) 1996-04-04 2000-08-29 Massachusetts Institute Of Technology Method and apparatus for determining forces to be applied to a user through a haptic interface
US5802353A (en) 1996-06-12 1998-09-01 General Electric Company Haptic computer modeling system
US6125385A (en) 1996-08-01 2000-09-26 Immersion Corporation Force feedback implementation in web pages
US6084587A (en) 1996-08-02 2000-07-04 Sensable Technologies, Inc. Method and apparatus for generating and interfacing with a haptic virtual reality environment
US5990869A (en) 1996-08-20 1999-11-23 Alliance Technologies Corp. Force feedback mouse
US5694013A (en) 1996-09-06 1997-12-02 Ford Global Technologies, Inc. Force feedback haptic interface for a three-dimensional CAD surface
GB9622556D0 (en) 1996-10-30 1997-01-08 Philips Electronics Nv Cursor control with user feedback mechanism
US6111562A (en) 1997-01-06 2000-08-29 Intel Corporation System for generating an audible cue indicating the status of a display object
KR100287137B1 (ko) * 1997-04-11 2001-04-16 윤종용 휴대형 정보 단말기의 버전 관리방법
US6020876A (en) 1997-04-14 2000-02-01 Immersion Corporation Force feedback interface with selective disturbance filter
US6005551A (en) 1997-04-25 1999-12-21 Microsoft Corporation Offline force effect rendering
US6088019A (en) 1998-06-23 2000-07-11 Immersion Corporation Low cost force feedback device with actuator for non-primary axis
US6252583B1 (en) * 1997-11-14 2001-06-26 Immersion Corporation Memory and force output management for a force feedback system
US6295608B1 (en) * 1998-02-17 2001-09-25 Microsoft Corporation Optimized allocation of data elements among cache lines
US6219034B1 (en) 1998-02-23 2001-04-17 Kristofer E. Elbing Tactile computer interface
KR20070046797A (ko) 2004-07-01 2007-05-03 솔베이 어드밴스트 폴리머스 엘.엘.씨. 방향족 폴리아미드 조성물 및 이로부터 제조된 제품

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5734373A (en) * 1993-07-16 1998-03-31 Immersion Human Interface Corporation Method and apparatus for controlling force feedback interface systems utilizing a host computer
EP1036390B1 (de) * 1997-11-14 2004-11-03 Immersion Corporation Methode der Steuerung einer Kraft-Rückkopplung-Vorrichtung in einer multi-tasking grafischen Wirtsumgebung

Also Published As

Publication number Publication date
GB2353116B (en) 2004-03-31
DE10082696T1 (de) 2002-01-31
US6343349B1 (en) 2002-01-29
WO2000067245A1 (en) 2000-11-09
US6252583B1 (en) 2001-06-26
AU4701000A (en) 2000-11-17
GB0010833D0 (en) 2000-06-28
US20040104924A1 (en) 2004-06-03
GB2353116A (en) 2001-02-14
US6715045B2 (en) 2004-03-30
US7299321B2 (en) 2007-11-20
US20020095224A1 (en) 2002-07-18

Similar Documents

Publication Publication Date Title
DE10082696B3 (de) Verfahren zur Bereitstellung von Krafteffekten mittels einer Kraftrückkopplungsvorrichtung und Vorrichtung hierfür
US9582077B2 (en) Providing force feedback to a user of an interface device based on interactions of a user-controlled complaint paddle with a simulated object in a graphical environment
US6750877B2 (en) Controlling haptic feedback for enhancing navigation in a graphical environment
US6169540B1 (en) Method and apparatus for designing force sensations in force feedback applications
US6424356B2 (en) Command of force sensations in a forceback system using force effect suites
US6054991A (en) Method of modeling player position and movement in a virtual reality system
US7027032B2 (en) Designing force sensations for force feedback computer applications
US7091948B2 (en) Design of force sensations for haptic feedback computer interfaces
US6219033B1 (en) Method and apparatus for controlling force feedback interface systems utilizing a host computer
EP1012697B1 (de) Verfahren und gerät zumentwerfen und kontrollieren von kraftempfindungen in kraft-feedback-rechneranwendungen
JPH09505426A (ja) ユーザがプログラムできる触覚のフィードバックを有する仮想作業領域
DE10122385A1 (de) Verfahren und System zum Verarbeiten von Kraftrückkopplungseffekten, die an einem Hauptrechner erzeugt werden, zur Wiedergabe an einer physischen Dialogvorrichtung
CA2297514A1 (en) Designing force sensations for computer applications including sounds
JP2001517347A (ja) 多人数の触覚仮想環境
DE60308976T2 (de) System und Methode zur Choreographie von Videosequenzen
WO2002057885A2 (en) Controlling haptic feedback for enhancing navigation in a graphical environment
EP0545684A2 (de) Kostengünstiges System zur Modellierung von Spielerpositionen und -bewegungen in einem System der virtuellen Realität
CN115068929A (zh) 游戏信息获取方法、装置、电子设备和存储介质
DE112021004019T5 (de) Informationsverarbeitungseinrichtung, System zur Bereitstellung einer taktilen Sinneserfahrung und Programm
Kirner et al. Simulation of real-time systems: an object-oriented approach supported by a virtual reality-based tool
DK1548558T3 (en) Process for graphical and behavioral, three-dimensional modeling of at least two objects
WO2000067246A1 (en) Command of force sensations in a force feedback system using force effect suites
He et al. Implementation of an Intelligent Force Feedback Multimedia Game

Legal Events

Date Code Title Description
8128 New person/name/address of the agent

Representative=s name: FIENER, J., PAT.-ANW., 87719 MINDELHEIM

8110 Request for examination paragraph 44
8125 Change of the main classification

Ipc: G06F 13/10 AFI20051017BHDE

R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final

Effective date: 20130328

R071 Expiry of right