WO2018065986A1

WO2018065986A1 - Orientation and motion tracking controller

Info

Publication number: WO2018065986A1
Application number: PCT/IL2017/051129
Authority: WO
Inventors: Matteo PISANI; Marco DE FALCO
Original assignee: Remoria Vr S.R.L.; Friedman, Mark
Priority date: 2016-10-06
Filing date: 2017-10-04
Publication date: 2018-04-12

Abstract

The present invention provides a controller apparatus and method, along with systems, that efficiently transfer data in a single packet for an operational cycle, between a controller apparatus and a smartphone, where the smartphone is being used in a virtual or augmented reality headset or other gaming headset, to administer and display video games and other video entertainment and content.

Description

Orientation And Motion Tracking Controller

CROSS-REFERENCES TO RELATED APPLICATIONS

This patent application is related to and claims priority from commonly owned U.S. Provisional Patent Application Serial No. 62/404,784, entitled: Orientation and Motion Tracking Controller, filed on October 6, 2016, the disclosure of which is incorporated by reference in its entirety herein.

TECHNICAL FIELD

The present invention is directed to apparatus with orientation and motion tracking features for use with mobile computing devices, such as smart phones.

BACKGROUND

Contemporary joysticks, joypads and controllers for mobile devices, such as those which use Bluetooth®, have long latency times, between when input is sent and then received and processed by a mobile computing device, such as a smart phone. This long latency time is a problem in virtual reality applications as the frame rate per second must be extremely high, e.g., 60 fps (frames per second) and above, to avoid motion sickness. Also, a controller needs to send the input to the device at a high speed, to keep up with the screen of the mobile device refreshing.

SUMMARY

The present invention provides apparatus and methods that reduce the long latency times, presently experienced between joysticks, joypads, controllers, and the respective smart phone, for example, the smart phone being used in a virtual or augmented reality headset or other gaming headset, in video games and other video entertainment and content. Once the smart phone receives the input packet from the apparatus of the invention, the drivers of the smart phone or other computing device start to process the received input packet. The drivers are operable with platforms, such as Apple® iOS, Android®, MS Windows®, Apple macOS and Linux.

The present invention provides a device which utilizes a combination of sensors, which allow the controller to transmit signals and data corresponding to its orientation in space and motion to a smart phone or other computerized device. This transmission is faster, at reduced latency times than with contemporary devices, at about 100 packets per second, or any application that needs fast inputs. By transmitting at this high speed, a virtual or augmented reality experience is much more fluid and responsive to a user, providing a better user experience, than is presently available with contemporary Bluetooth® LE (Low Energy) controllers.

Embodiments of the invention are directed to a method for providing the status of a controller apparatus to a computing device administering an event, the computing device responsive to signals from the controller apparatus. The method comprises: obtaining orientation data for the controller apparatus; obtaining status data for the status of control actuators; obtaining power data for the status of the power in the controller apparatus; and, providing the orientation data for the controller apparatus, the status data for the status of control actuators, and, power data for the status of the power in the controller apparatus, into a single packet of 20 bytes or less, for transmission from the tracking control apparatus to the computing device administering the event.

Optionally, the single packet is in accordance with a Bluetooth® standard.

Optionally, the method additionally comprises: transmitting the single packet from the controller apparatus to the computing device at a predetermined interval.

Optionally, the predetermined interval is approximately 10 milliseconds. Optionally, the obtaining the orientation data includes: obtaining Euler angle data from the movement of the controller apparatus, converting the Euler angle data to a sequence of characters; and, reducing the number of characters of the sequence of characters.

Optionally, the method additionally comprises: sampling data from an inertial measurement unit (EVIU), comprising an accelerometer, a gyrometer and a magnetometer, to obtain the Euler angle data from the movement of the controller apparatus.

Optionally, the reducing the number of characters of the sequence of characters compresses the orientation data to 12 bytes or less for the single packet.

Optionally, the obtaining the orientation data includes: obtaining quaternion data, expressed by variables x, y, z, w, from raw data for movement of the controller apparatus, based on roll, pitch and yaw of the controller apparatus; converting the quaternion data to a sequence of characters; and, reducing the number of characters of the sequence of characters.

Optionally, the reducing the number of characters of the sequence of characters compresses the orientation data to 4 bytes or less, of the single packet.

Optionally, the method additionally comprises: sampling data from an inertial measurement unit (EVIU), comprising an accelerometer, a gyrometer and a magnetometer, to obtain the quaternion data from the movement of the controller apparatus.

Optionally, the data from the inertial measurement unit (IMU) being sampled includes raw data corresponding to raw coordinates of the controller apparatus in space; and, encoding the raw data in 11 bytes or less for the single packet.

Optionally, the method additionally comprises: sampling raw data from the accelerometer and the gyrometer of an inertial measurement unit (IMU) at a first sampling time; and, sampling the raw data from the accelerometer and the magnetometer of the inertial measurement unit (IMU) at a second sampling time. Optionally, the first sampling time is at intervals different than the second sampling time.

Optionally, the method additionally comprises: adjusting the gyrometer based on the sampled raw data from the accelerometer and the magnetometer of the inertial measurement unit (IMU) at the second sampling time.

Optionally, the control actuators include one or more of: at least one button; and, a joystick. Optionally, the at least one button includes a plurality of buttons.

Optionally, the method additionally comprises: encoding coordinates of the joystick and encoding of the input of the at least one button.

Optionally, the encoded coordinates of the joystick include two Bytes of the single packet, and the encoded input of the at least one button includes two Bytes of the single packet.

Optionally, the event control actuators include one or more of a joystick; and, at least one button, where the at least one button includes a plurality of buttons, and the method additionally comprises encoding coordinates of the joystick and encoding of the input of the at least one button, such that the encoded coordinates of the joystick include two Bytes of the single packet, and the encoded input of the at least one button includes one Byte of the single packet.

Optionally, the method additionally comprises: encoding the power data from a power source associated with the controller apparatus such that the power data includes one Byte of the single packet.

Optionally, the method additionally comprises: providing the single packet with an end of packet indicator of one Byte.

Optionally, the end of packet indicator includes an ASCII character.

Optionally, the ASCII character includes a bar. Embodiments of the invention are directed to a controller apparatus (for example, an orientation tracking controller or control device) for operating with a computing device administering an event. The controller apparatus comprises: a measurement device configured for providing orientation data associated with the controller apparatus; control actuators; at least one power source; at least one processor configured for obtaining: a) the orientation data, b) first status data for the status of control actuators, and, c) second status data for the power in the at least one power source; and, at least one encoder configured for converting the: a) the orientation data, b) the first status data, and, c) the second status data, into packet data to create a single packet of 20 bytes or less, for transmission to the computing device administering the event.

Optionally, the at least one encoder provides an end of packet indicator into the packet data.

Optionally, the controller apparatus additionally comprises: a transmitter for transmitting the single packet to the computing device administering the event.

Optionally, Optionally, for the controller apparatus, the created single packet of 20 bytes or less is in accordance with a Bluetooth Standard.

Optionally, the measurement device includes an inertial measurement unit (IMU) comprising: an accelerometer; a gyrometer; and, a magnetometer.

Optionally, the control actuators include one or more of: at least one joy stick; and, at least one button.

Optionally, the power source includes a battery.

Optionally, the at least one processor obtains the a) the orientation data, b) the first status data, and, c) the second status data, by sampling the IMU, control actuators and at least one power source at a predetermined time defining an operational cycle. Optionally, for the controller apparatus, the operational cycle includes a first time interval, and the processor obtains the orientation data by sampling an accelerometer and a gyrometer of the lMU.

Optionally, the encoder creates the single packet, and the transmitter transmits the single packet within the first time interval.

Optionally, for the controller apparatus, the operational cycle includes a second time interval, and the processor obtains the orientation data by sampling an accelerometer and a magnetometer of the IMU.

Optionally, for the controller apparatus, the second time interval is greater than the first time interval.

Optionally, the at least one processor is additionally configured for adjusting the gyrometer based on the orientation data samples from the accelerometer and the magnetometer.

Optionally, for the controller apparatus, the first time interval is approximately 10 milliseconds.

Optionally, for the controller apparatus, the second time interval is approximately 5 minutes.

Other embodiments of the invention are directed to computer usable non-transitory storage medium having a computer program embodied thereon for causing a suitable programmed system to provide the status of a controller apparatus to a computing device administering an event, the computing device responsive to signals from the controller apparatus, by performing the following steps when such program is executed on the system. The steps comprise: obtaining orientation data for the controller apparatus; obtaining status data for the status of control actuators; obtaining power data for the status of the power in the controller apparatus; and, providing the orientation data for the controller apparatus, the status data for the status of control actuators, and, power data for the status of the power in the controller apparatus, into a single packet of 20 bytes or less, for transmission from the tracking control apparatus to the computing device administering the event. Optionally, the computer usable non-transitory storage medium is such that the single packet is in accordance with a Bluetooth® standard.

Optionally, the computer usable non-transitory storage medium is such that the steps additionally comprise: transmitting the single packet from the controller apparatus to the computing device at a predetermined interval.

This document references terms that are used consistently or interchangeably herein. These terms, including variations thereof, are as follows.

A "computer" includes machines, computers, computer and computing devices, and computing or computer systems (for example, physically separate locations or devices), servers, computer, computing, and computerized devices, processors, processing systems, computing cores (for example, shared devices), and similar systems, workstations, modules and combinations of the aforementioned. The aforementioned "computer" may be in various types, such as a personal computer (e.g., laptop, desktop, tablet computer), or any type of computing device, including mobile devices that can be readily transported from one location to another location (e.g., smartphone (cellular and network linked), smart band, smart watch, virtual and augmented reality headsets, personal digital assistant (PDA)).

An "application", includes executable software, and optionally, any graphical user interfaces (GUI), through which certain functionality may be implemented.

A "driver" is a computer program, typically software, that operates or controls a particular type of device that is attached to or associated with a computer.

Unless otherwise defined herein, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein may be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

BRIEF DESCRIPTION OF DRAWINGS

Some embodiments of the present invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

Attention is now directed to the drawings, where like reference numerals or characters indicate corresponding or like components. In the drawings:

FIG. 1 is a diagram of an exemplary environment for the system in which embodiments of the disclosed subject matter are performed;

FIGs. 2A and 2B are respective side views of the apparatus in accordance with the present invention;

FIG. 3A is a block diagram of an exemplary apparatus and a device adapted for use with the apparatus, the apparatus and device of FIG. 1;

FIG. 3B is a block diagram of an alternative exemplary apparatus to that of FIG. 3A, and a device adapted for use with the apparatus;

FIG. 4A is an operational schematic diagram of the apparatus of FIG. 3; FIG. 4B is a flow diagram for the decoding by the decoder of FIG. 4A; FIG. 5 is a diagram of the software aspects of the invention; FIG. 6A is a flow diagram of an exemplary process in accordance with the invention;

FIG. 6B is a flow diagram of the encoding and packetizing data of the process of FIG. 6A;

FIG. 7A is a diagram of joystick position for encoding a joystick event;

FIG. 7B is a table for encoding button events;

FIG. 8 is a diagram of an orientation packet in accordance with the present invention; FIG. 9 is a diagram of a motion packet in accordance with the present invention; FIG. 10 is a diagram of packet transmissions; FIG. 11 is a flow diagram for motion packets;

FIG. 12 is a schematic diagram of an exemplary device in accordance with the present invention;

FIGs. 13A and 13B are a diagram of another embodiment of a firmware architecture in accordance with the present invention;

FIG. 14 is a diagram of the encoder of FIGs. 13A and 13B;

FIG. 15 is a flow diagram of the encoding for the IMU raw data of ROLL, PITCH and YAW; FIG. 16A is a diagram for the encoding of Joystick data;

FIG. 16B is an example encoding of a Joystick position using the encoding diagram of FIG. 16A;

FIG. 17 is a flow diagram of the process performed by the firmware of FIGs. 13A, 13B and 14 in operation with the computing device, for an operational cycle thereof; FIG. 18A is a block diagram of another embodiment of an exemplary apparatus and a device adapted for use with the apparatus;

FIG. 18B is a block diagram of an alternative exemplary apparatus to that of FIG. 18 A, and a device adapted for use with the apparatus;

FIG. 19 is a diagram of another embodiment of a firmware architecture in accordance with the present invention, as used with the apparatus of FIGs. 18A and 18B;

FIG. 20A is a diagram used for encoding the joystick for the firmware of FIG. 19;

FIG. 20B is a diagram showing data for encoding the buttons of the apparatus of FIGs. 18A and 18B; and,

FIG. 21 is a flow diagram performed by the firmware of FIG. 19.

Appendix A, Appendix B, Appendix C and Appendix D are attached to this document.

DETAILED DESCRIPTION OF THE DRAWINGS

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings. The invention is capable of other embodiments or of being practiced or carried out in various ways.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more non-transitory computer readable (storage) medium(s) having computer readable program code embodied thereon.

Throughout this document, numerous textual and graphical references are made to trademarks, and domain names. These trademarks and domain names are the property of their respective owners, and are referenced only for explanation purposes herein.

Reference is now made to FIG. 1, which shows an example environment in which the apparatus 100 of the invention is operating. The apparatus 100 is operating as an orientation tracking controller or controller apparatus (the terms "apparatus", "orientation tracking controller" and "controller apparatus" are used interchangeably herein, such that the orientation tracking controller is indicated by the element 100 hereinafter). The orientation tracking controller 100 couples with a computing device 102, which administers an event, such as a game or displaying content (e.g., video, audio or both). The orientation tracking controller 100 is designed and configured to operate with and/or control the event administered by the computing device 102 (e.g., smartphone 103) of the headset 104, for example, by the orientation tracking controller 100 moving, and/or having its joystick 202 and/or buttons 204, 208, 210 manipulated. The computing device 102, is, for example, a smartphone 103 or other mobile computing device, mobile computer, mobile device, or device, these terms used interchangeably herein, in a headset 104, worn by a user 106 when participating in an event, such as playing a video game or experiencing other entertainment or content.

The headset 104 is, for example, a virtual reality (VR) or augmented reality (AR) headset, gaming headset, a headset which connects to a mobile device, such as a smartphone, with the headset becoming a hub for the smartphone, or a dedicated headset. The orientation tracking controller 100 is linked to the device 102, for example, via Bluetooth®, e.g., Bluetooth® LE, so that these two components 100, 102 are linked to each other, in electronic and/or data communication, for example, via signals, packets, and the like. The orientation tracking controller 100, along with the device 102, as seated in the headset 104, form an orientation tracking system.

Turning also to FIGs. 2A and 2B, the orientation tracking controller 100 includes a joystick or joypad 202, which is, for example, analog, and buttons 204, 208,210, which are, for example, digital. The buttons include, for example, a first button "A" 204 on one side 206a, with a second "B" button 208 and a third "C" button 210, on the opposite side 206b of the orientation tracking controller 100 100. The buttons 204, 208, 210 may be arranged in any desired order, and while three buttons, A 204, B 208 and C 210, are shown, there may be up to eight buttons associated with the orientation tracking controller 100, as detailed below, and shown in FIG. 20B. The joystick 202 and buttons 204, 208, 210 are collectively referred to as control actuators (or tracking control actuators).

FIG. 3A shows a diagram of an orientation tracking management system 300 in accordance with the present invention, formed of the orientation tracking controller 100, and a device 102 (as seated in the headset 104). The device 102 is adapted for use with the orientation tracking controller 100.

The orientation tracking controller 100 includes a computing system 100' for performing the various operations, methods and processes of the invention. A controller (also known as a computing controller) 302 controls all computing operations of the orientation tracking controller 100, in order to perform the processes and methods of the invention.

The controller 302 includes a CPU 302a of processors, including microprocessors. The controller 302, for example, is an 8 MHz microcontroller, such as an Atmel® 8-bit Microcontroller, as described in Atmel® ATmegal6U4/32U4 DATASHEET SUMMARY of April 2016 (Atmel-7766JS-USB-ATmegal6U4-32U4-Datasheet_0472016), attached hereto as Appendix A. The CPU 302a is typically associated with storage/memory, e.g., RAM (random access memory) 302b which store machine executable instructions for execution by the CPU 302a to control operation of the controller 302 as well as perform processes of the invention. There is also ROM (read only memory) 302c, which includes firmware 500, which includes instructions for the CPU 302a to perform the processes (methods) of the invention, as detailed below. The controller 302 links to various components detailed below. "Linked" as used herein includes both wired and/or wireless links between elements (structures), which place the elements in electronic and/or data communication with each other, either directly or indirectly.

The joystick 202 and buttons 204, 208 and 210 are shown linked to the controller 302. The joystick 202 and buttons A 204, B, 208, and C 210, are collectively referred to herein and known as "tracking control actuators" or "control actuators". The joystick 202 links to the controller 302 via an analog port 310, which receives X and Y coordinates. Buttons A 204, B 208 and C 210 are linked to a digital port 312, which is in turn links to the controller 302.

The controller 302 links to a power source 314, via a port 315. The power source 314 is, for example, a battery (e.g., Li-Po 3.7v ~ 250 mah), and is controlled by a switch 316, with a manually controlled ON/OFF button 316a.

The controller 302 also links to measurement device, such as an inertial measurement unit (IMU) 318. The IMU 318 serves to measure and report the specific force, angular rate, e.g., orientation and motion of the apparatus 100. This is achieved through a magnetometer (M) 322, gyrometer or gyroscope (G) 324, and accelerometer (Ac) 326, are in electrical and/or data communication with each other and electrically and/or data linked to processors associated with the IMU 318.

A vibration motor 330 is linked to the controller 302. For example, the vibration motor 330 functions to provide vibrations to the buttons A 204, B 208, C 210, to indicate a long press, or the like.

The controller 302 links to a transceiver 332, through which signals, including packets, are transmitted out from the apparatus 100, for example, to the device 102 (e.g., and received by the transceiver 370 of the device 102), as illustrated by the arrow 333. The transceiver 332 is, for example, a Bluetooth LE (low energy) 4.1 Nordic RF 51822 Module (detailed in Appendix B), and operative in accordance with, Bluetooth® LE Standards, including Bluetooth® LE 4.1 and 4.2 Standards. Example Bluetooth® LE standards, including those for Bluetooth® LE 4.1 and 4.2 are detailed in: BLUETOOTH® SPECIFICATION Volume 0, Master Table of Contents & Compliance Requirements, Covered Core Package Version 1.2, Publication Date: 05 November 2003; BLUETOOTH® SPECIFICATION Volume 2, Core System Package [Controller volume], Version 1.2, Publication Date: 05 November 2003; and, BLUETOOTH® SPECIFICATION Volume 0, Master Table of Contents & Compliance Requirements, Covered Core Package Version 4.2, Publication Date: Dec 02 2014 (all three documents available at www.bluetooth.org). These three documents are incorporated by reference herein. The Bluetooth® module, for example, uses a U.A.R.T. (Universal Asynchronous Receiver Transmitter) data protocol, for example, as detailed in UART RAW protocol and UART HCI protocol, attached hereto as Appendix C.

The controller 302 also links to a USB (universal serial bus) port 336, such as a micro USB port, allowing for wired attachment to devices, and through which the power source 314 is charged.

The controller 302, ports 310, 312, 315, IMU 318, vibration motor 330, transceiver 332, and USB Port 336, for example, reside on a main board 340. This main board 340 is, for example, a printed circuit board (PCB).

The device 102 is, for example, a smartphone 103 (FIG. 1), for example, as used, for example, in a gaming, VR or AR headset 104 (FIG. 1). The device 102 includes a display 362, such as a display screen and applications 364, for playing the various games and/or entertainment. The device 102 includes applications(s) 364, which includes an application 364a (FIG. 13B) for sending data to the receiver 332c (FIG. 13B) of the transceiver 332 to signal the vibration motor 330 to activate and cause vibrations in the orientation tracking controller 100, lOOx (an alternative orientation tracking controller lOOx may be used in place of orientation tracking controller 100, as shown in FIGs. 1, 2A and 2B).

There are also drivers 366, adapted for Android and iOS operating systems (OS) 368 of the device 102, which allow for the decoding of the data received in the packets transmitted from the orientation tracking controller 100, lOOx, which are received by the transceiver 370 of the device 102.

The device 102 also includes other hardware and software 372 for performing all other device 102 operations.

FIG. 3B shows an alternative apparatus as an orientation tracking controller lOOx with a computing system lOOx', for operating and communicating with the device 102. The alternative orientation tracking controller lOOx and computing system lOOx' are similar in construction and arrangement to the orientation tracking controller 100 and computing system 100', except that the ON/OFF switching is controlled by a hardwired component (HWC) 316x, which is electrically coupled to a button, for example, Button A 204 and the switch 316. The HWC 316x is such that when switching ON (from OFF) is desired, the HWC 316x detects a "long press" of Button A, for example, of at least three seconds, When this "long press" of Button A has been determined to be of a sufficient time length, the orientation tracking controller lOOx and computing system lOOx' are turned ON or otherwise activated. When the orientation tracking controller lOOx is ON, any "long press" of Button A will be part of the orientation tracking controller lOOx operating as a relay and gaming device and will not function in the ON/OFF mode.

FIGs. 4 A and 4B show an example operation between the orientation tracking controller 100, lOOx and a device 102. The components germane to this exemplary operation are discussed. Initially, the orientation tracking controller 100, lOOx, via the firmware 500 encodes a packet 402, which is transmitted by the transceiver 332, which includes a Bluetoooth® LE (Low Energy) or BLE, as detailed above. The transmission is indicated as T_x.

The packet 402, e.g., a raw packet, is received by a Bluetoooth® Low Energy receiver (BLE) of the transceiver 370. The reception is indicated as R_x. The driver 366 receives the packet 402 from the transceiver 370. Within the driver is a decoder 366a, a packet reconstruction module 366b and an application 366c. The raw packet 402 is processed by the decoder 366a, in accordance with the process of FIG. 4B, performed, for example by software.

This decoding process is such that the raw packet is received, at block 380. The packet is then reconstructed, at block 382, resulting in a clean packet, at block 384.

The clean packet is processed by a packet reconstruction module 366b, which initializes a string variable. This string variable is in turn filled one byte at a time with American Standard Code for Information Interchange (ASCII) characters until it reaches the "pipe" ( | ) character, which defines the end of the packet (shown, for example, in FIG. 8 at field 810 and FIG. 9 at field 910). With processing complete, the reconstructed packet moves to the application 366d, where it is interpreted and attributed to the target object to control. This process continues for as long as there are packets to process in succession. FIG. 5 shows a block diagram of the interaction between the firmware 500 and the hardware, e.g., the controller 302, which performs the instructions of the firmware 500. The firmware 500 operates on the inputs 502, which include x, y, z coordinates from the IMU 318 (obtained from the sensors 503-the magnetometer (M) 322, gyrometer (G) 324 and accelerometer (Ac) 326, collectively), joystick 202, buttons 204, 208, 210, and battery 304. The firmware 500 encodes and packetizes these inputs, into packets for orientation, based on data and processes of libraries 504, specific for the IMU 318 (e.g., provided by the IMU 318 manufacturer). The packets for orientation are output 505, and transmitted by the transceiver 312. The transmitted packets reach the driver 366 of the device 102. The driver 366 decodes the packet, and applies the decoded data to its application 364.

FIG. 6A details the process 600 performed by firmware 500, as executed by the controller 302, as well as the drivers 366 of the device 102, to which the orientation tracking controller 100, lOOx, is transmitting packets. The aforementioned process is shown as a flow diagram, detailing computer-implemented processes in accordance with embodiments of the disclosed subject matter. Reference is also made to elements shown in FIGs. 1-5. The aforementioned processes and sub-processes can be, for example, performed manually, automatically, or a combination thereof, and, for example, in real time.

The process 600 begins at block 602, where a sampling point is determined. At this time of the sampling point, inputs are encoded and packetized, at block 604. These inputs include, for example, data from the IMU 318, joystick 202, buttons A 204, B 208, C 210, and the power source, e.g., battery 314.

Next, the process moves to block 604, where data from the IMU 318, joystick 202, buttons 204, 208, 210 and battery 314 is encoded and packetized.

The IMU 318 includes x, y, z coordinates from each of the gyrometer (G) 322, magnetometer (M) 324 and accelerometer (Ac) 326, each of the x, y, z coordinates being a set. Each x, y, z, coordinate set is processed by firmware 500 that includes IMU (C++) specific library's 504 set of instructions (FIG. 5), to obtain a resultant set of X, Y, Z, coordinates, for encoding, into fields the first 801, second 802, and third 803 fields respectively, of the orientation packet 800 of FIG. 8. The joystick 202, for example, defines eight positions for joystick events, having values 1-8 (with the value "0" serving as a default or initial/final position), as shown in FIG. 7A. This value for the event at the sampling point is encoded in the orientation packet 800 in the fourth field 804.

The A 204, B 208 and C 210 buttons have values for encoding button events, based on which buttons are depressed at the sampling point, in accordance with the table of FIG. 7B. This value for the button event is encoded in the orientation packet 800 in the fifth field 805.

The battery 314 has an encoding value of "1" if discharged (below a certain voltage), and "0", if charged (above a certain voltage). This value is encoded in the orientation packet 800 in the sixth field 806.

FIG. 8 shows the orientation packet 800. This packet 800 is formed of fields 801-806, each field 801-806 is separated by a separator 808, which is readable by a driver of the device. The packet 800 also ends in an end of packet (EOP) indicator 810, readable by the aforementioned driver. A second field 802 is for the "Y" resultant coordinate value from the IMU 318. A first field 801 is for the "X" resultant coordinate value from the IMU 318. A second field 802 is for the "Y" resultant coordinate value from the IMU 318. A third field 803 is for the "Z" resultant coordinate value from the IMU 318.

A fourth field 804 is for the encoded joystick value of 1-8, while a fifth field 805 is for the encoded value of 0-7 (0 being a default when no buttons are depressed) for the buttons 204, 208, 210. A sixth field 806 is for the encoded values of "1" "discharged" or "0" "charged" for the power source 314, e.g., battery.

The orientation packet 800 is of a length of not more than 20 bytes. This 20 byte length is the maximum length under the Bluetooth LE 4.1 and 4.2 Standard. The aforementioned encoding allows for this small packet length (size). Additionally, this packet length of not more than 20 bytes, is within the standard for Bluetooth LE 4.1 and 4.2 transmissions. Such Bluetooth low energy transmissions allow for a minimum of one packet transmission every 200 milliseconds, however, the transceiver 332, which, for example, includes a Bluetooth LE transmitter, is programmed to transmit packets at, for example, one packet every 10 milliseconds. The order and content of the fields 801-806 may be changed, provided the drivers are programmed to decode these packets 800 in accordance with the changed field order.

FIG. 9 shows a motion packet 900, which is based on gestures made by the user on the apparatus 100. The packet 900 includes fields of a header 901, which simply is an ASCII string. The next three fields 902, 903 and 904 are based on inputs from the accelerometer 326. These fields are for the gestures on the apparatus 100 of, Up/Down 902, Left/Right 903 and Front/Back 904. Each field 901-904 is separated by a separator 908, which is readable by a driver of the device. The packet 900 also ends in an end of packet (EOP) indicator 910, readable by the aforementioned driver.

Similar to the orientation packet 800, the motion packet 900 is of a length of not more than 20 bytes, as detailed for the motion packet 800 above. These motion packets 900 are, for example, transmitted at a rate of one packet approximately every 10 milliseconds. The order and content of the fields 901-904 may be changed, provided the drivers are programmed to decode these packets 900 in accordance with the changed field order.

Block 604 is shown in detail in FIG. 6B. In this flow diagram, IMU 318 values are read into the controller 302, at block 604a- 1, and encoded at block 604a-2, as detailed above. Next, joystick 202 values are read for the joystick event at the sampling point, at block 604b- 1, and encoded at block 604b-2 (FIG. 7A). Button values are read for the button evens at the sampling point, at block 604c- 1 and encoded at block 604c-2 (table of FIG. 7B). Next, power source (e.g., battery) 314 values (e.g., voltage) are read at the sampling point, at block 604d- 1, and encoded at block 604d-2. Next, a motion gesture is encoded, by reading accelerometer 326 values at the sampling point, at block 604e-l, and encoding Up/Down movement, at block 604e-2, encoding Left/Right movement, at block 604e-3, and encoding Front/Back movement at block 604e-4. This is only an example order, as any order which performs all of the aforementioned processes/subprocesses is also permissible.

Returning to FIG. 6A, the packets, orientation 800 and motion 900, are transmitted by the transceiver 332 to the driver 366 of the destination device 102, at block 606. At block 606, packets are compressed so as to be transmitted without redundancy. Turning to FIG. 10, at an initial time P_t=i, a full packet 1002 is present. In this full packet 1002, the fields, going from left to right are: X, Y, Z for the sensors (magnetometer (M) 322, gyrometer (G) 324 and accelerometer (Ac) 326), J, for Joystick 202, BUT for buttons 204, 208, 210, BAT, for the power source, e.g., battery 314. Following an event, for example, a change in joystick 202 position, for example, from value "0" to value "1" (FIG. 7A), and the battery is discharging, hence a value of "1", at time P_t=_m-3, a time after, e.g., at least 10 milliseconds after, the initial time P_t=i, The packet produced at time P_t=m-3 is a full packet 1004, as the fields J, BUT, and BAT include values.

At a subsequent time P_t=m-2 the packet 1006 is present. A concordance check is now made, where the three fields J, BUT, BAT are compared in the packets 1004 and 1006. If the values in the J, BUT and BAT fields are identical, the relation P_t=m-3 = P_t=_m-2 · A counter is set to TRUE, and the next packet issued is packet 1008, which includes empty space, for fields, J, BUT, and BAT. This empty packet is transmitted from the orientation tracking controller 100, lOOx to the device 102, as shown in FIGs. 3A, 3B and 4A.

At a subsequent time, for example, P_t=_m-i, which is within 10 milliseconds of P_t=_m-2, an EVENT 1009 occurs, where the joystick 202, represented by the field J, has a changed value to "7", indicative of a joystick 202 position change. This change is indicated in packet 1010. A concordance check is made, where the three fields J, BUT, BAT are compared in the packets 1006 (the last full packet) and 1010. Here, at least one of the three values in the J, BUT and BAT fields are different, such that the relation P_t=m-2 ≠ P_t=_m-i . The counter is set to FALSE, and packet 1010, a full packet is sent or transmitted from the orientation tracking controller 100, lOOx to the device 102, as shown in FIGs. 3A, 3B and 4A.

By handling the packet transmissions in this manner, rapid processing of packets occurs by the drivers 366, as additional or otherwise redundant packets are not processed. Hence, computing resources operate fast and efficiently. The process moves to block 608, where the packets are decoded immediately on their arrival at the transceiver 372 of the device 102, for example, in chronological order, the order in which the packets are received.

The process moves to block 610, where the data decoded from the packets 800, 900 is applied to the application 364 on the device 102. Since small packets, of lengths not more than 20 bytes are transmitted rapidly, for example, one packet approximately every 10 milliseconds, data from the apparatus 100 reaches the device 102 fast, and the small packet size allows for rapid decoding, such that action on the device 102 occurs significantly faster (e.g., every approximately 10 milliseconds), with minimal latency, when compared to contemporary systems. The process of blocks 602-610 is then repeated for the next sampling point. Sampling points are, for example, at regular intervals, for example, of approximately 10 milliseconds.

The gesture or motion packets 900 are created in accordance with the example process of FIG. 11. Initially, by a user of the orientation tracking controller 100, lOOx depressing a button, for example the "A" button 204for a predetermined time, for example, greater than 500 milliseconds, this depression for the predetermined time is received in the controller 302 by the CPU 302a, at block 1102. This depression for a time greater than the predetermined time is known as a "long press." A motion sensitive sampler, of the firmware 500 is now activated.

The process moves to block 1104, where the firmware 500 samples raw data from the IMU 318 sensors 503 (magnetometer (M) 322, gyrometer (G) 324, accelerometer (Ac) 326) to track directional movements in the three dimensional (3D) space. With the sampling complete, the process moves to block 1106, where the motion packet 900 is generated, by the raw data analysis, which identifies the direction of the movement. The motion packet 900 is now sent, at block 1108 by, for example, the Bluetooth™ Low Energy transmitter of the transceiver 332 of the orientation tracking controller 100, lOOx, to the device 102, as shown for example in FIGs. 3A, 3B and 4A, for processing in accordance with the applications of the device 102. FIG. 12 shows an example of the orientation tracking controller 100/computing system 100', in the form of a schematic. In this schematic, numbering of the components is the same as that for FIG. 3A, as described above, except where indicated. For example, the controller 302 is a Feather32U4 Bluefruit from Adafruit®, and the IMU 318 is a 9-DoF IMU.

FIGs. 13A, 13B and 14 show another embodiment of a firmware architecture 1300 operable in the ROM 302c, as shown in FIGs. 3A and 3B and as described above for these drawing figures. This firmware 1300 is also operable as described in FIGs. 4A, 4B, 5 and 6A, with the firmware 500 replaced by firmware 1300 and the packet 402 replaced by the packet 1320.

The firmware 1300 architecture includes a processor 1302, for example, an ATMEL 32u4 8MHz Micro Processor. The processor 1302, functions as the computing controller (controller) 302 for the orientation tracking controller/computing systems 100/100' and ΙΟΟχ/ΙΟΟχ', and is electronically linked or coupled to the IMU 318, joystick 202, for example, an analog joystick, coupled to the processor 1302 via a port 310, a digital port 312 (coupled to the processor 1302) for buttons 204, 208, 210, for example digital buttons, Button A 204, Button B 208, and Button C 210, a power source (e.g., battery) 314, all of which link to an encoder 1310. The encoder 1310 creates an encoded data packet 1320, for example, a packet of twenty (20) bytes, and moreover, not more than twenty (20) bytes, which is, for example, a single packet. This twenty (20) bytes packet length (size) is the maximum length/size under the Bluetooth LE 4.1 and 4.2 Standards. These twenty (20) bytes include an extra data portion 1320a of two bytes, which is a fixed size, with an encoded data portion 1320b of 18 bytes, which is, for example, a fixed size. The extra data portion 1320a is configured, for example, as a free slot 1320al, which may be used for future functionalities. The encoded data portion 1320b is such that all of the data necessary for one operational cycle of the computing device is contained therein.

A transceiver 332 is electrically linked or otherwise coupled to the processor 1302 of the controller 302. The transceiver 332 is the component through which signals, including packets, are transmitted out from the orientation tracking controller 100, lOOx, for example, to the computing device 102 (e.g., and received by the transceiver 370 of the device 102), as illustrated by the arrow 333, of FIGs. 3A and 3B. The transceiver 332, is, for example, a Bluetooth LE (low energy) chipset, with a controller 332a of a processor such as a Nordic nRF51822 Module (detailed in Appendix B), and operative in accordance with, Bluetooth® LE Standards, including Bluetooth® LE 4.1 and 4.2 Standards. Example Bluetooth® LE standards, including those for Bluetooth® LE 4.1 and 4.2 are detailed in: BLUETOOTH® SPECIFICATION Volume 0, Master Table of Contents & Compliance Requirements, Covered Core Package Version 1.2, Publication Date: 05 November 2003; BLUETOOTH® SPECIFICATION Volume 2, Core System Package [Controller volume], Version 1.2, Publication Date 05 November 2003; and, BLUETOOTH® SPECIFICATION Volume 0, Master Table of Contents & Compliance Requirements, Covered Core Package Version 4.2, Publication Date: Dec 02 2014 (all three documents available at www.bluetooth.org), as listed above. The Bluetooth® module, for example, uses a U.A.R.T. (Universal Asynchronous Receiver Transmitter) data protocol, for example, as detailed in UART RAW protocol and UART HCI protocol, attached hereto as Appendix C.

The transceiver 332 includes a transmitter (TX) 332b, which transmits the encoded data packet 1320, for example at regular intervals, such as one of the aforementioned 20 byte packets 1320 every 10 or approximately 10 milliseconds (100 packets per second). By transmitting, from the transmitter (TX) 332b, a uniform or fixed size (length) packet, e.g., one (a single) twenty (20) byte packet, at regular intervals, e.g., every 10 milliseconds, all necessary data to perform an operation in the computing device 102, in a single operational cycle of the computing device (device) 102, is provided. The data is provided efficiently, as it is in a single delivery of a uniform packet length, allowing for rapid operation of the computing device 102 in a single operational cycle. This renders latency as extremely low or eliminates latency altogether, such that the firmware architecture 1300 operates such that orientation tracking controller 100, lOOx movements and actions (by the user (player) 106 (FIG. 1) holding the orientation tracking controller 100, lOOx, are in complete synchronization with the operation, e.g., game being played and viewed, on the computing device 102.

The transceiver 332 also includes, for example, a receiver component (RX) (receiver) 332c, through which a software application 364a (for example, residing on the device 102) sends data to the receiver 332c (FIG. 13B) of the transceiver 332. This received data is input to signal the vibration motor 330 to activate and cause vibrations in the orientation tracking controller 100, lOOx. The receiver 332c is electrically connected to a haptic vibration motor (vibration motor) 330. The haptic vibration motor 330 is also electrically connected to the processor 1302 (functioning as the computing controller). The receiver component (RX) 332c signals to the haptic vibration motor 330, in order to vibrate at different intensities corresponding to the various action of the game being played. These vibrations provide the user (player) 106 with additional feedback from the operation of the computing device 102, e.g., the game being played.

Turning also to FIG. 14, the encoder 1310 and its encoding process is shown for the firmware 1300. Raw data, on the left side, is input into the encoder 1310. The raw data is sent to a mapper 1404, with is programmed with an encoding scheme based on Euler angles (https://en.wikipedia.org/wiki/Euler_angles) for each type of raw data (minimum 1406 and maximum 1408 input data), and minimum 1410 and maximum 1412 output values, which are the encoded values. The encoded values are shown on the right side of the encoder 1310. Example code used by the mapper 1404 is as follows: var mapper(var curren t_value, var in_min, var in_max, var out_min, var out_max)

{

return (value - in_min) * (ou t_max - out_min) / (in_max - in_min) + out_min;

}

The processor 1302 (functioning as the computing controller (controller)) links to the inertial measurement unit (IMU) 318. The IMU 318 serves to measure and report the specific force, angular rate, e.g., orientation, and acceleration, of the orientation tracking controller 100, lOOx in space, and the data associated therewith, known as orientation data. This is achieved through the magnetometer (M) 322, gyrometer (gyroscope) (G) 324, and accelerometer (Ac) 326, which are in electrical and/or data communication with each other and electrically and/or data linked to processors associated with the IMU 318.

The data from the magnetometer (M) 322, gyrometer (G) 324, and accelerometer (Ac) 326, collectively, the sensors 503 of FIG. 5, is raw data, e.g., in the form of Eulerian angles, (represented by block 1317a) (as supplied from the manufacturer of the IMU 318, for example, STMicroelectronics, Geneva, Switzerland). This raw data 1317a is then processed by a mathematics module (MATH) 1317b, which uses algorithms from the libraries 504, which include the functionalities performed by the mapper 1404 (provided above) to reduce the character length of the raw data to the encoded data of fewer characters than the raw data (prior to encoding by the mapper 1404). The raw data of the roll 1318a, pitch 1318b, and yaw 1318c is transmitted to the encoder 1310, e.g., the mapper 1404, where these values are encoded. The encoded values for roll 1318a', pitch 1318b' and yaw 1318c' are four digit values, with the last or rightmost digit value corresponding to a decimal digit, and the first three values representing integer digits, in the raw data for roll, pitch and yaw, respectively, as shown, for example, in FIG. 13 A. These four values are one (1) byte each, so in the encoded portion 1320b of the packet, 1320 roll, pitch and yaw, each occupy four (4) bytes, for a total of 12 bytes in the packet 1320 (in the encoded portion 1320b).

The encoder 1310 employs an encoding scheme, for raw data values for roll, pitch, and yaw. An example encoding process is shown in FIG. 15.

At the START block 1502 the raw data value is obtained. For example, the raw data value for roll is +357.81, pitch is -11.78, and yaw is +102.39. Moving to block 1504, the roll and yaw values are positive, so the roll becomes 357.81 + 360 = 717.81, and the yaw becomes 102.39 + 360 = 462.39, as per block 1506. Returning to block 1504, the pitch value of -11.78 becomes 011.78, with the 0 added as a placeholder for three integers before the decimal. Accordingly, integer values above 360 indicate positive, while integer values below 360 indicate negative.

The process now moves to block 1510, where final encoded values are obtained as: 1) the two decimals are rounded to the nearest tenth, and 2) the decimal point is removed. Accordingly, as shown, for example, in FIG. 14, the roll becomes 7179 (element number 1318"), the pitch becomes 0118 (element number 1318b"), and the yaw becomes 4624 (element number 1318c"). These are the values which are encoded into the computing system 100', ΙΟΟχ', at block 1512, as four bytes for each value, into the encoded portion 1360b of the packet 1360, for ROLL 1360M, PITCH 1360b2, and YAW 1360b3, respectively (of FIGs. 13A and 13B).

From the joystick 202 two raw data values for X 1322 and Y 1324 are encoded by the encoder 1310. The raw data values are based on the X and Y positions of the joystick 202, and are encoded with values from 0 to 9 on each axis, the encoded values represented by one byte each 1322', 1324' . The encoding scheme is shown in FIG. 16A. Accordingly, an encoded value of X=l and Y=7 is shown in FIG. 16B. The resultant encoding is two bytes total and the two bytes are encoded into the encoded 1320b portion of the packet 1320 for JOYSTICK 1320b4.

The buttons 1306, Button A 204, Button B 208, and Button C 210 provide raw data when depressed, not depressed, and combinations thereof. The raw data from each button, the combination of buttons being pressed at a given time, and the length of the press, known as a gesture, are inputs of the gesture handler 1334, which as raw data are input into the encoder 1310. The resultant encoding is two bytes, one for the sequence 1336', which is the combination of buttons pushed at a given time) which encodes as integers 0 to 7, as shown in FIG. 7B, one for gestures 1338', with an integer value of 0 to 4, with zero a no press, 1 is a short press or single click, 2 is a double click, and 3 is long press. The resultant encoding is two bytes total, one byte 1336', one byte 1338' and the two bytes are encoded into the encoded 1320b portion of the packet 1320 for BUTTONS 1360b5.

The power source (e.g., battery) 314 has a voltage 1342, which is the raw data. The battery is, for example, a battery (e.g., Li-Po 3.7v ~ 250 mah), and is controlled by a switch 316, with a manually controlled ON/OFF button 316a, or via the HWC 316x. This voltage, as raw data, is input into the encoder 1310. The encoded value is an integer from 0-9, indicative of battery voltage. The resultant encoding is one byte 1342' total, which is encoded into the encoded 1320b portion of the packet 1320 for BATTERY 1320b6.

The encoded portion 1320b of the packet 1320 ends with a character delimiter, encoded as a bar " I " (ASCII code pipe). The resultant encoding is one byte 1350' total, which is encoded into the encoded 1320b portion of the packet 1320 for END OF PACKET 1320b7.

The packet 1320 is shown, for example, to be of a fixed size (length) of 20 bytes, so as to be within the Bluetooth® LE Standard. All of the information necessary to operate the computing device 102 at each predetermined interval is provided in this single packet to complete a single cycle of operation (for the computing device 102). As a result, latency is eliminated, as the computing device 102 is not waiting for multiple packet deliveries to complete a single operational cycle. Also, by delivering all necessary data for a single operational cycle in a single packet, of a fixed size, and, for example, at a fast rate, e.g., every approximately 10 milliseconds (to accommodate the Bluetooth® LE connection between the orientation tracking controller 100 and the device 102), operation is consistent and there is a minimal, if any, likelihood of packet loss, resulting in non-delivery, partial or late delivery.

FIG. 17 is a flow diagram of operation of the firmware 1300 (FIGs. 13A and 13B) in the orientation tracking controller 100, lOOx (FIGs. 3A and 3B) .

The process begins at a START block 1702, provided the orientation tracking controller 100, lOOx is ON and the connection, e.g., Bluetooth® (Bluetooth LE) connection between the orientation tracking controller 100, lOOx and the device 102 is established. The process then moves to block 1704, where raw data is received from: i) the IMU 318, ii) control actuators (tracking control actuators), for example, the joystick 202 (via port 310) and buttons 204, 208, 210 (via port 312), and, iii) the power source (e.g., battery) 314, for an operational cycle, for example, an operational cycle of approximately 10 milliseconds. The raw data is then encoded at block 1706 and the encoded data is formed into an encoded data packet 1320, for example in accordance with the Bluetooth® LE Standard(s). The encoded data packet is, for example, of twenty (20) bytes, and not more than twenty (20) bytes, so as to be within the Bluetooth LE Standard(s). The twenty (20) bytes of the encoded packet are of: two (2) bytes of extra data or empty 1320a, and eighteen (18) bytes of filled (not empty) data 1320b. As detailed above the eighteen (18) bytes of the packet portion 1320b are filled by four (4) bytes for each of roll, pitch and yaw, from the IMU 318 (totaling twelve (12) bytes); two (2) bytes for the joystick 202, two (2) bytes for the buttons 204, 208, 210 (the joystick 202 and the buttons 204, 208, 210, known collectively as control actuators (tracking control actuators); one (1) byte for the battery 314, and, one (1) byte for the character delimiter, indicative of the end of the packet, e.g., a bar or "pipe" in accordance with ASCII code. The character delimiter (of one (1) byte) is added to the packet at block 1710.

The process moves to block 1712, where the packet 1320 is transmitted from the orientation tracking controller 100, lOOx, to the computing device, e.g., device 102, on which the event is displayed, e.g., game is being played, by a user 106 (FIG. 1). The packet 1320 is transmitted (sent) by the transmitter Tx 332b of the chipset 332a, to a computing device 102, at a predetermined interval. For example, this predetermined interval is approximatleylO milliseconds.

The process moves to block 1714, where it is determined whether the orientation tracking controller 100, lOOx, continues to operate, and if not, has timed out. The time out is caused, for example, by a connection interruption or otherwise broken between the orientation tracking controller 100, lOOx and the computing device 102. The entire process, for the START at block 1702 to the sending at block 1712 is, for example, approximately 10 milliseconds.

If the connection is detected as broken, the process moves to block 1716, where it ends. If the connections has not timed out, e.g., it is not or remains unbroken, the process returns to block 1704, from where it resumes as detailed above.

FIGs. 18A and 18B, 19, 20A, 20B and 21 illustrate another embodiment orientation tracking system 1800 of the invention, with an alternative orientation tracking controllers 1801 (FIG. 18A) and 1801x (FIG. 18B), also referred to as controller apparatus, which are of the same or similar construction and dimensions to the orientation tracking controllers 100, lOOx shown in FIGs. 1, 2A, 2B, 3 A and 3B, and described above. The orientation tracking controllers 1801 and 1801x are suitable for use with a device 102, as an alternate to the orientation tracking controller 100, in order to perform the processes and methods of the invention, as disclosed herein. This orientation tracking system 1800 provides for orientation and motion of the respective orientation tracking controller 1801, 1801x.

Initially, in FIGs. 18A and 18B, the orientation tracking systems 1800 are similar to the orientation tracking systems 300 of FIGs. 3A and 3B except, that in the computing systems 180 , 1801x' of the orientation tracking controllers 1801, 1801x, there is not a vibration motor 330, as per the orientation tracking controllers/computing systems 100/100', lOOx/lOOx' of the orientation tracking systems 300. Other components remain the same as those in FIGs. 3A and 3B, respectively, and have the same element numbers and are in accordance with the descriptions provided in FIGs. 3 A and 3B. FIG. 19 shows another embodiment of a firmware architecture 1900 operable in the ROM 302c, as shown in FIGs. 18A and 18B and as described above for these drawing figures. This firmware 1900 is also operable as described in FIGs. 4A, 4B, 5 and 6A, with the firmware 500 replaced by firmware 1900 and the packet 402 replaced by the packet 1920.

The firmware architecture 1900 includes a processor 1902, for example, an ATMEL 32u4 8MHz Micro Processor, as detailed above. The processor 1902, while shown as a single processor, may be multiple, processors, microprocessors and the like. In the firmware architecture 1900, components similar and/or identical to those of the firmware 1300 of FIGs. 13A and 13B have the same numbers, or have similar numbers as those of the 1300 series but in the 1900 series.

The processor 1902, functions as a controller 302 (FIGs. 18A and 18B) for the orientation tracking controller/ computing systems 1801/1801' and 1801x/1801x', and is electronically linked or coupled to the IMU 318, joystick 202, for example, an analog joystick, coupled to the processor 1902 via a port 310, a digital port 312 (coupled to the processor 1902) for buttons 204, 208, 210, for example digital buttons, Button A 204, Button B 208, and Button C 210, and, the power source (battery) 314, all of which link to an encoder 1910. The encoder 1910 creates an encoded data packet 1920, for example, of twenty (20) bytes, and moreover, not more than twenty (20) bytes, so as to be within the Bluetooth® LE 4.1 and 4.2 Standards. This encoded data packet 1920 is, for example, a single packet (of not more than twenty (20) bytes). This 20 byte length (size) is the maximum length/sixe under the Bluetooth LE 4.1 and 4.2 Standards.

These twenty (20) bytes of the packet (encoded data packet) 1920, include, four (4) bytes (e.g., a four Byte (character) string 1922a) for encoded quaternion data, expressed as x, y, z and w, for normal orientation of the orientation tracking controller 1801, 1801x, eleven (11) bytes (e.g., an eleven (11) Byte (character) string 1922b) for sampled raw coordinates for the controller 1801, 1801x, two (2) bytes (e.g., a two (2) Byte (character) string 1922c) for encoded x and y coordinate status data for the x and y coordinates of the joystick 202 (via port 310), one (1) byte (e.g., a one (1) Byte (character) string 1922d) for the encoded data associated with the depression/non-depression of each of the digital buttons (at port 312), Button A 204, Button B 208 and Button C 210, one (1) byte (e.g., a one (1) Byte (character) string 1922e) for the power source (e.g., battery) 314 status (via port 315), based, for example on voltage readings/data, and one (1) byte (e.g., a one (1) Byte (character) string 1922f) for the character delimiter, indicating the end of the packet, for example, a bar of ASCII code. The encoded data packet 1920 is such that all of the data necessary for one operational cycle of the computing device, for example, of approximately 10 milliseconds, defining an example interval (for the operational cycle, including sampling data), is contained therein.

The processor 1902, functioning as the controller 302, links to the inertial measurement unit (IMU) 318. The IMU 318 serves to measure and report the specific force, angular rate, e.g., orientation, and acceleration, of the orientation tracking controller 100, lOOx in space, and the data associated therewith, known as orientation data. This is achieved through the magnetometer (M) 322, gyrometer (G) 324, and accelerometer (Ac) 326, which are in electrical and/or data communication with each other and electrically and/or data linked to processors associated with the IMU 318.

The data from the magnetometer (M) 322, gyrometer (G) 324, and accelerometer (Ac) 326, is raw data, for example, as supplied from the manufacturer of the IMU 318 (e.g., STMicroelectronics, Geneva, Switzerland). This raw data is sampled, as represented by blocks 1917a, 1917b, by the controller 1902. This raw data is operated on, as detailed below, to establish orientation and motion of the orientation tracking controller 1800, 1800x.

In a first scenario, sampling the raw data from the accelerometer (Ac) 326 and gyrometer (G) 324 of the IMU 318, as represented by block 1917a, is performed by the processor 1902 (of the controller 302), in accordance with the operational cycle, of, for example, approximately 10 milliseconds, also expressed as Tl (time 1). A sample matrix of the obtained raw data is expressed as the matrix MT1:

MT1 Ac_x, Ac_y, Ac_z

G_x, G_v, G_z

The encoder 1910, which is, for example, the processor 1902 (also used as the controller 302) then applies a Quaternion Algorithm (process) to the values of the Matrix MT1, to form the raw data into Quaternions, four variables, expressed as x, y, z, w. The Quaternion Algorithm (process) is, for example, an Altitude Heading Algorithm, for example, that is produced by GitHub and available at https.github.com/psiphi75/ahrs/blob/master/Mahony.js, and attached as Appendix D. The Quaternion Algorithm (process) outputs values Qi, such that:

where, i = x, y, z, w, the Quaternion variables or values.

The values Qi are typically four or five characters and include decimal points, and in some cases, include signs, such as a negative sign. The Quaternion Algorithm (process), where the raw data is formed into Quaternions x 1918x, y 1918y, z 1918z, w 1918w, is known as Quaternion Elaboration, represented by block 1918.

The encoder 1910 then encodes the Quaternions, x 1918x, y 1918y, z 1918z, w 1918w, by reducing each of the Qi values for x, y, z, w, to three characters. This character reduction process or encoding, to obtain the reduced character value (VCH), is performed, for example, by the processor 1902, applying the formula:

Accordingly, for the initial Qi values 0.41 and -0.201 (the "1" is removed from -0.201 to have five characters), the reduced (to three characters) character values (VCH) are 141 and 080, respectively. Accordingly, three (3) characters for each of x, y, z, w is twelve (12) bits, which are allocated four (4) Bytes in the encoded packet 1920.

In a second scenario, when sampling the raw data from the accelerometer (Ac) 326 and magnetometer (M) 322 of the IMU 318, as represented by block 1917b, is performed by the processor 1902 (functioning as the controller 302, as shown in FIGs. 18A and 18B), in accordance with a second time 2, expressed as T2, which is, for example, a longer sampling interval, such as approximately five minutes (although other sampling time intervals are also permissible). This second scenario is optional, and is used, for example, correct the orientation of the orientation tracking controller 1800, 1800x, for example, to reset the gyrometer (G) 324, to go back to its settings of the first Scenario above, in an accurate manner to compensate for the drift effect on the gyrometer (G) 324.

In this second scenario, a sample matrix of the obtained raw data is expressed as a matrix MT2:

Ac_x, Ac_y, Ac_z 30

M_x, M_y, M_z

The encoder 1910, which is, for example, the processor 1902 then applies a Quaternion Algorithm (process) or Quaternion Elaboration (block 1918) to the values of the Matrix MT2, in accordance with the Quaternion Algorithm (process), as detailed above. The Quaternion Algorithm (process) outputs values Qi, as detailed above.

These Qi values for the Quaternion variables x, y, z, w, are character reduced or encoded, by the encoder 1910, by the character reduction process, as detailed above, to obtain the reduced character value (VCH). In accordance with that detailed above, initial Qi values are reduced to three characters for each of x, y, z, w is twelve (12) bits, which are allocated four (4) Bytes in the encoded packet 1920. The Quaternion Algorithm (process) and the character reduction process for this second scenario is also Quaternion Elaboration, represented by block 1918. The encoded character string of four (4) Bytes, produced by this second scenario becomes the quaternion portion of the packet 1922a, for the operational cycle (e.g., the approximately 10 millisecond interval), when the accelerometer (Ac) 326 and magnetometer (M) 322 are sampled.

In the process of block 1919, raw coordinates from the IMU 318 are sampled and encoded, by the encoder 1910, for example, the processor 1902. This sampling and encoding results in the raw data portion 1922b of the packet 1920, which is eleven (11) Bytes (e.g., an eleven (11) Byte character string). This raw data portion 1922b includes encoded raw data from the IMU 318.

In a first scenario, of block 1919, regular sampling, by the processor 1902 (functioning as the controller 302) is performed during the operational cycle at Tl, which is, for example, approximately 10 milliseconds. This regular sampling at time Tl is of the accelerometer (Ac) 326 and the gyrometer (G) 324. The raw data sampled is with a high accuracy, such that each data point, e.g., Ac_x, Ac_y, Ac_z, G_x, G_y, G_z, of the Matrix MT3 fills 14 bits of space. The Matrix MT3 is expressed as:

Ac_x, Ac_y, Ac_z 1

G_x, G_y, G_z

where each of the data points is fourteen (14) bits. With six (6) data points in the Matrix MT3, and each data point being fourteen (14) bits, eighty-four (84) total bits are used, which occupy eleven (11) Bytes (e.g., in an eleven (11) Byte character string) in the packet 1920. This encoded raw data of the raw data packet portion 1922b provides data for mapping gestures associated with the orientation tracking controller 1801, 1801x. Moreover, the decoder of the device 102 recognizes a shift at every fourteen (14) bits (of the eleven (11) Bytes of the raw data packet portion 1922b).

In a second scenario, of block 1919, sampling, by the processor 1902 (functioning as the controller 302) is performed during a time interval T2, which is, for example, approximately five (5) minutes. This sampling at time T2 is of the accelerometer (Ac) 326 and the magnetometer (M) 322. The raw data sampled is with a high accuracy, such that each data point, e.g., Ac_x, Ac_y, Ac_z, M_x, M_y, M_z, of the Matrix MT4 fills fourteen (14) bits of space. The Matrix M4 is expressed as:

Ac_x, AC_y, Ac_z

MT4

M_x, M_v, M_z where each of the data points is 14 bits. With six data points in the Matrix MT4, and each data point being fourteen (14) bits, eighty-four (84) total bits are used, which occupy eleven (11) Bytes (e.g., in an eleven (11) Byte character string) in the packet 1920. When the data points from the accelerometer (Ac) 326 and the magnetometer (M) 322 are sampled, they are encoded and used as the eleven (11) Byte raw data portion 1922b of the packet 1920. This encoded raw data of the raw data packet portion 1922b provides data, for example, for correcting the drift in the orientation tracking controller 1801, 1801x. Moreover, the decoder of the device 102 recognizes a shift at every fourteen (14) bits (of the eleven (11) Bytes of the raw data packet portion 1922b).

From the joystick 202 two raw data values for X (x) coordinate status 1932 and Y (y) 1934 are samples, as represented by block 1936, and encoded by the encoder 1910. The raw data values are based on the X and Y positions of the joystick 202, and are encoded with values from 0 to 255, on each axis (with the midpoint being 128), the encoded values of the X and Y coordinates represented by one (1) byte each 1322', 1324'. The encoding scheme is shown in FIG. 20A, with the encoding scheme, similar to that of FIGs. 16A and 16B, as detailed above. The resultant encoding is two (2) Bytes total and the two (2) Bytes are encoded into the encoded joystick coordinates portion 1922c of the packet 1920.

The buttons, Button A 204, Button B 208, and Button C 210 are sampled, as represented by block 1940, to provide raw data when depressed, not depressed, and combinations thereof. The raw data from each button, such that the combination of buttons being depressed/not depressed at a given time, is sampled in the normal operational cycle, e.g., approximately every 10 milliseconds.

For example, in FIG. 20B, as shown at sample times STl and ST2, approximately 10 milliseconds apart, where 1 is button depressed, and 0 button not depressed, at STl no buttons are depressed, while at ST2, buttons A and C are depressed. These input states at STl and ST2 are encoded by the encoder 1910 into values indicative of the button states at STl and ST2. The encoded data is one (1) Byte in and encoded button input portion 1922d of the packet 1920.

Returning to FIG. 20B, the orientation tracking controller 100, lOOx, 1801, 1801x may have up to eight buttons, shown by the five extra spaces (S) filled by "0", reserved for these additional buttons.

The power source (e.g., battery) 314 has a voltage which is the raw data. The voltage, as raw data, is sampled (by the processor 1902 functioning as the controller 302), as represented by block 1950, and is input into the encoder 1910. The encoded value is an integer from 0-99, indicative of battery power level. The resultant encoding is one (1) Byte, which is encoded into the power indication 1920e portion of the packet 1920.

The packet 1920 ends with a character delimiter, encoded as a bar " | " (ASCII code pipe). The resultant encoding is a one (1) Byte packet portion 1922f for indicating END OF PACKET, for the packet 1920. The processor 1902 (functioning as the controller 302) signals the transceiver 322 of the orientation tracking controller 1801, 1801x to send the packet 1920 to the device 102, as indicated by block 1960. Alternately, the transceiver 322 of the orientation tracking controller 1801, 1801x may be programmed to send the packet 1920 to the device 102.

FIG. 21 is a flow diagram of operation of the firmware 1900 (FIG. 19) in the orientation tracking controller 1801, 1801x (FIGs. 18A and 18B).

The process begins at a START block 2102, provided the orientation tracking controller 1801, 1801x is in an ON state and a connection, e.g., Bluetooth® connection between the orientation controller 1801, 1801x and the device 102 is established.

The process then moves to blocks 2104a and 2104b. At block 2104a, raw data is obtained, for example, by sampling the IMU (accelerometer (Ac) 326 and gyrometer (G) 324), tracking control actuators (e.g., Joystick 202 and buttons 204, 208, 210), and power source 314 for an operational cycle of a predetermined first time interval Tl, for an operational cycle. For example, an operational cycle is approximately 10 milliseconds. At block 2104b raw data is obtained, for example, by sampling the IMU 318 (accelerometer (Ac) 326 and magnetometer (M) 322), tracking control (or control) actuators (e.g., Joystick 202 and buttons 204, 208, 210), and power source 314 for a predetermined second time interval T2, for example, of approximately five (5) minutes.

From blocks 2104a and 2104b, the processes move to block 2105a and 2105b, respectively, where the raw data from the IMU is encoded into an eleven (11) Byte string. From blocks 2105a and 2105b, the process moves to block 2112.

Returning to blocks 2104a and 2104b, the process moves to block 2106, where the respective raw data, as sampled from the IMU (at blocks 2104a and 2104b, respectively) is formed into Quaternions, x, y, z, w (as per block 1918 of FIG. 19). This is done, for example, by the processor 1902 (functioning as the controller 302). The process moves to block 2108, where the Quaternions, x, y, z, w, are encoded, by the encoder 1910, reducing the characters of each Quaternion, x, y, z, w, to not more than three (3) characters. The process moves from block 2108 to block 2110, where the encoder 1910, for example, encodes the raw data from the control actuators (e.g., joystick 202, and buttons- buttons A 204, B 208, C 210).

The process moves from block 2110 to block 2112, where the packet 1920 is created from the encoded data. The packet created is not more than a predetermined size of, for example, twenty (20) Bytes, so as to be in accordance with the Bluetooth® LE standard. The packet created also includes an end character, a delimiter (e.g., ASCII bar Character), for example, of one (1) byte, indicating END OF PACKET, which is added to the encoded data at block 2114, completing the encoded packet. The now completed encoded packet is not more than the predetermined length, for example twenty (20) Bytes, for example, to be in conformance with the Bluetooth LE Standard(s) (as referenced above).

The process moves to block 2116, where packet 1920 is transmitted (sent) by the transmitter 332, to a computing device 102, e.g., the smart phone 103 (in the headset 104) administering and displaying the event or game being played, by the user 106 (FIG. 1), at a predetermined time/sending interval. For example, this predetermined time/sending interval is approximatleylO milliseconds.

The process moves to block 2118, where it is determined whether the orientation tracking controller 1801, 1801x, continues to operate, and if not, has timed out. The time out is caused, for example, by a connection interruption or otherwise broken between the orientation tracking controller 1801, 1801x and the computing device 102, e.g., smartphone 103. The entire process, for the START at block 2102 to the sending at block 2116 is approximately 10 milliseconds, corresponding to an operational cycle and sending interval.

If the connection is detected as broken at block 2118, the process moves to block 2110, where it ends. If the connections has not timed out, e.g., it is not or remains unbroken at block 2118, the process returns to blocks 2104a and 2104b, from where it resumes as detailed above. While the orientation tracking systems 300 and 1800 have been shown using one apparatus or orientation tracking controller 100, lOOx, 1801, 1801x, these orientation tracking systems 300 and 1800 may use multiple apparatus or orientation tracking controllers 100, lOOx, 1801, 1801x contemporaneously, including simultaneously. This is because the drivers in the devices 102 recognize the Media Access Control (MAC) address of each apparatus or orientation tracking controller 100, lOOx, 1801, 1801x. The orientation tracking systems 300, 1800 are programmed such that they can limit the number of orientation tracking controllers 100, lOOx, 1801, 1801x, which can be accommodated at any given time.

Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non- volatile storage, for example, non-transitory storage media such as a magnetic hard-disk and/or removable media, for storing instructions and/or data.

For example, any combination of one or more non-transitory computer readable (storage) medium(s) may be utilized in accordance with the above-listed embodiments of the present invention. The non-transitory computer readable (storage) medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

As will be understood with reference to the paragraphs and the referenced drawings, provided above, various embodiments of computer-implemented methods are provided herein, some of which can be performed by various embodiments of apparatuses and systems described herein and some of which can be performed according to instructions stored in non-transitory computer-readable storage media described herein. Still, some embodiments of computer- implemented methods provided herein can be performed by other apparatuses or systems and can be performed according to instructions stored in computer-readable storage media other than that described herein, as will become apparent to those having skill in the art with reference to the embodiments described herein. Any reference to systems and computer- readable storage media with respect to the following computer-implemented methods is provided for explanatory purposes, and is not intended to limit any of such systems and any of such non-transitory computer-readable storage media with regard to embodiments of computer-implemented methods described above. Likewise, any reference to the following computer-implemented methods with respect to systems and computer-readable storage media is provided for explanatory purposes, and is not intended to limit any of such computer-implemented methods disclosed herein. The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware -based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise.

The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments. It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

The above-described processes including portions thereof can be performed by software, hardware and combinations thereof. These processes and portions thereof can be performed by computers, computer-type devices, workstations, processors, micro-processors, other electronic searching tools and memory and other non-transitory storage-type devices associated therewith. The processes and portions thereof can also be embodied in programmable non-transitory storage media, for example, compact discs (CDs) or other discs including magnetic, optical, etc., readable by a machine or the like, or other computer usable storage media, including magnetic, optical, or semiconductor storage, or other source of electronic signals.

The processes (methods) and systems, including components thereof, herein have been described with exemplary reference to specific hardware and software. The processes (methods) have been described as exemplary, whereby specific steps and their order can be omitted and/or changed by persons of ordinary skill in the art to reduce these embodiments to practice without undue experimentation. The processes (methods) and systems have been described in a manner sufficient to enable persons of ordinary skill in the art to readily adapt other hardware and software as may be needed to reduce any of the embodiments to practice without undue experimentation and using conventional techniques.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

Claims

Claims:

1. A method for providing the status of a controller apparatus to a computing device administering an event, the computing device responsive to signals from the controller apparatus, comprising:

obtaining orientation data for the controller apparatus;

obtaining status data for the status of control actuators;

obtaining power data for the status of the power in the controller apparatus; and, providing the orientation data for the controller apparatus, the status data for the status of control actuators, and, power data for the status of the power in the controller apparatus, into a single packet of 20 bytes or less, for transmission from the tracking control apparatus to the computing device administering the event.

2. The method of claim 1, wherein the single packet is in accordance with a Bluetooth® standard.

3. The method of claim 2, additionally comprising: transmitting the single packet from the controller apparatus to the computing device at a predetermined interval.

4. The method of claim 3, wherein the predetermined interval is approximately 10 milliseconds.

5. The method of claim 3, wherein the obtaining the orientation data includes:

obtaining Euler angle data from the movement of the controller apparatus,

converting the Euler angle data to a sequence of characters; and,

reducing the number of characters of the sequence of characters.

6. The method of claim 5, additionally comprising:

sampling data from an inertial measurement unit (IMU), comprising an accelerometer, a gyrometer and a magnetometer, to obtain the Euler angle data from the movement of the controller apparatus.

7. The method of claim 5, wherein the reducing the number of characters of the sequence of characters compresses the orientation data to 12 bytes or less for the single packet.

8. The method of claim 3, wherein the obtaining the orientation data includes:

obtaining quaternion data, expressed by variables x, y, z, w, from raw data for movement of the controller apparatus, based on roll, pitch and yaw of the controller apparatus;

converting the quaternion data to a sequence of characters; and,

reducing the number of characters of the sequence of characters.

9. The method of claim 8, wherein the reducing the number of characters of the sequence of characters compresses the orientation data to 4 bytes or less, of the single packet.

10. The method of claim 8, additionally comprising:

sampling data from an inertial measurement unit (IMU), comprising an accelerometer, a gyrometer and a magnetometer, to obtain the quaternion data from the movement of the controller apparatus.

11. The method of claim 10, wherein the data from the inertial measurement unit (IMU) being sampled includes raw data corresponding to raw coordinates of the controller apparatus in space; and, encoding the raw data in 11 bytes or less for the single packet.

12. The method of claim of claim 8, additionally comprising:

sampling raw data from the accelerometer and the gyrometer of an inertial measurement unit (IMU) at a first sampling time; and,

sampling the raw data from the accelerometer and the magnetometer of the inertial measurement unit (IMU) at a second sampling time.

13. The method of claim 12, wherein the first sampling time is at intervals different than the second sampling time.

14. The method of claim 12, additionally comprising: adjusting the gyrometer based on the sampled raw data from the accelerometer and the magnetometer of the inertial measurement unit (IMU) at the second sampling time.

15. The method of claim 5, wherein the control actuators include one or more of:

at least one button; and,

a joystick.

16. The method of claim 15, wherein the at least one button includes a plurality of buttons.

17. The method of claim 15, additionally comprising: encoding coordinates of the joystick and encoding of the input of the at least one button.

18. The method of claim 17, wherein the encoded coordinates of the joystick include two Bytes of the single packet, and the encoded input of the at least one button includes two Bytes of the single packet.

19. The method of claim 8, wherein the event control actuators include one or more of:

a joystick; and,

at least one button.

20. The method of claim 19, wherein the at least one button includes a plurality of buttons.

21. The method of claim 19, additionally comprising: encoding coordinates of the joystick and encoding of the input of the at least one button.

22. The method of claim 21, wherein the encoded coordinates of the joystick include two Bytes of the single packet, and the encoded input of the at least one button includes one Byte of the single packet.

23. The method of claim 3, additionally comprising: encoding the power data from a power source associated with the controller apparatus such that the power data includes one Byte of the single packet.

24. The method of claim 3, additionally comprising: providing the single packet with an end of packet indicator of one Byte.

25. The method of claim 24, wherein the end of packet indicator includes an ASCII character.

26. The method of claim 25, wherein the ASCII character includes a bar.

27. A controller apparatus for operating with a computing device administering an event, comprising:

a measurement device configured for providing orientation data associated with the controller apparatus;

control actuators;

at least one power source;

at least one processor configured for obtaining: a) the orientation data, b) first status data for the status of control actuators, and, c) second status data for the power in the at least one power source; and,

at least one encoder configured for converting the: a) the orientation data, b) the first status data, and, c) the second status data, into packet data to create a single packet of 20 bytes or less, for transmission to the computing device administering the event.

28. The controller apparatus of claim 27, wherein the at least one encoder provides an end of packet indicator into the packet data.

29. The controller apparatus of claim 28, additionally comprising a transmitter for transmitting the single packet to the computing device administering the event.

30. The controller apparatus of claim 28, wherein the single packet of 20 bytes or less is in accordance with a Bluetooth Standard.

31. The controller apparatus of claim 28, wherein the measurement device includes an inertial measurement unit (IMU) comprising: an accelerometer;

a gyrometer; and,

a magnetometer.

32. The controller apparatus of claim 31, wherein the control actuators include one or more of:

at least one joy stick; and,

at least one button.

33. The controller apparatus of claim 32, wherein the power source includes a battery.

34. The controller apparatus of claim 33, wherein the at least one processor obtains the a) the orientation data, b) the first status data, and, c) the second status data, by sampling the IMU, control actuators and at least one power source at a predetermined time defining an operational cycle.

35. The controller apparatus of claim 34, wherein the operational cycle includes a first time interval, and the processor obtains the orientation data by sampling an accelerometer and a gyrometer of the IMU.

36. The controller apparatus of claim 34, wherein the encoder creates the single packet, and the transmitter transmits the single packet within the first time interval.

37. The controller apparatus of claim 35, wherein the operational cycle includes a second time interval, and the processor obtains the orientation data by sampling an accelerometer and a magnetometer of the IMU.

38. The controller apparatus of claim 37, wherein the second time interval is greater than the first time interval.

39. The controller apparatus of claim 38, wherein the at least one processor is additionally configured for adjusting the gyrometer based on the orientation data samples from the accelerometer and the magnetometer.

40. The controller apparatus of claim 35, wherein the first time interval is approximately 10 milliseconds.

41. The controller apparatus of claim 37, wherein the second time interval is approximately 5 minutes.

42. A computer usable non-transitory storage medium having a computer program embodied thereon for causing a suitable programmed system to provide the status of a controller apparatus to a computing device administering an event, the computing device responsive to signals from the controller apparatus, by performing the following steps when such program is executed on the system, the steps comprising:

obtaining orientation data for the controller apparatus;

obtaining status data for the status of control actuators;

43. The computer usable non-transitory storage medium of claim 42, wherein the single packet is in accordance with a Bluetooth® standard.

44. The computer usable non-transitory storage medium of claim 42, wherein the steps additionally comprise: transmitting the single packet from the controller apparatus to the computing device at a predetermined interval.