Patent Description:
Modern computing and display technologies have facilitated the development of systems for so called "virtual reality" or "augmented reality" experiences, wherein digitally reproduced images or portions thereof are presented to a user in a manner wherein they seem to be, or may be perceived as, real. A virtual reality, or "VR", scenario typically involves presentation of digital or virtual image information without transparency to other actual real-world visual input; an augmented reality, or "AR", scenario typically involves presentation of digital or virtual image information as an augmentation to visualization of the actual world around the user.

<CIT> discloses methods and systems for displaying a computer generated image corresponding to the pose of a real-world object in a mixed reality system. The system may include of a head-mounted display (HMD) device, a magnetic track system and an optical system. Pose data detected by the two tracking systems can be synchronized by a timestamp that is embedded in an electromagnetic field transmitted by the magnetic tracking system. A processor may also be configured to calculate a future pose of the real world object based on a time offset based on the time needed by the HMD to calculate, buffer and generate display output and on data from the two tracking systems, such that the relative location of the computer generated image (CGI) corresponds with the actual location of the real-world object relative to the real world environment at the time the CGI actually appears in the display.

Head-mounted augmented reality (AR) devices can track the pose of the wearer's head (or other body part) to be able to provide a three-dimensional virtual representation of objects in the wearer's environment. Embodiments of an electromagnetic (EM) tracking system can be used to track head pose or body gestures. For example, a handheld user input device can include an EM emitter and the head-mounted AR device can include an EM sensor. In some implementations, the EM emitter generates an EM field that can be sensed by the EM sensor. EM information from the sensor can be analyzed to determine location and/or orientation of the sensor and thereby the wearer's head pose in a reference frame of the AR device. The pose can be a six degree-of-freedom (6DOF) pose including three spatial coordinates and three angular coordinates in the reference frame of the AR device. The reference frame of the AR device may be a global (or world) coordinate system, representative of fixed objects in the real world environment of the wearer.

The AR device can include other sensors that provide pose information, for example, an accelerometer, a gyroscope, a magnetometer, optical sensors or cameras, etc. As an example, accelerometer data can be integrated twice to provide an estimated position. However, errors in the sensor signal can cause the estimated position to drift relative to the actual position. Also, the position or orientation inferred from the sensor may be in a frame of reference associated with the sensor rather than the reference frame of the AR device (e.g., the world coordinate system).

Examples of techniques for fusing outputs from an electromagnetic tracking system and another sensor modality (e.g., accelerometer, gyroscope, magnetometer) to reduce pose error or to transform pose to the reference frame of the AR device are described herein. A Kalman filter or other type of data fusion technique can be used to fuse the outputs.

The sensor fusion techniques are not limited to AR or VR applications and in other implementations can be applied to pose determination of any object where sensors of different modalities (e.g., an accelerometer and an EM tracking device) are used. For example, the sensor fusion techniques can be applied to tracking medical devices and instruments in an operating room.

Neither this summary nor the following detailed description purports to define or limit the scope of the inventive subject matter.

Throughout the drawings, reference numbers may be re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of the disclosure.

In <FIG> an augmented reality scene (<NUM>) is depicted wherein a user of an AR technology sees a real-world park-like setting (<NUM>) featuring people, trees, buildings in the background, and a concrete platform (<NUM>). In addition to these items, the user of the AR technology also perceives that he "sees" a robot statue (<NUM>) standing upon the real-world platform (<NUM>), and a cartoon-like avatar character (<NUM>) flying by which seems to be a personification of a bumble bee, even though these elements (<NUM>, <NUM>) do not exist in the real world. As it turns out, the human visual perception system is very complex, and producing a VR or AR technology that facilitates a comfortable, natural-feeling, rich presentation of virtual image elements amongst other virtual or real-world imagery elements is challenging.

For instance, head-worn AR displays (or helmet-mounted displays, or smart glasses) typically are at least loosely coupled to a user's head, and thus move when the user's head moves. If the user's head motions are detected by the display system, the data being displayed can be updated to take the change in head pose into account.

As an example, if a user wearing a head-worn display views a virtual representation of a three-dimensional (3D) object on the display and walks around the area where the 3D object appears, that 3D object can be re-rendered for each viewpoint, giving the user the perception that he or she is walking around an object that occupies real space. If the head-worn display is used to present multiple objects within a virtual space (for instance, a rich virtual world), measurements of head pose (e.g., the location and orientation of the user's head) can be used to re-render the scene to match the user's dynamically changing head location and orientation and provide an increased sense of immersion in the virtual space.

In AR systems, detection or calculation of head pose can facilitate the display system to render virtual objects such that they appear to occupy a space in the real world in a manner that makes sense to the user. In addition, detection of the position and/or orientation of a real object, such as handheld device (which also may be referred to as a "totem"), haptic device, or other real physical object, in relation to the user's head or AR system may also facilitate the display system in presenting display information to the user to enable the user to interact with certain aspects of the AR system efficiently. As the user's head moves around in the real world, the virtual objects may be re-rendered as a function of head pose, such that the virtual objects appear to remain stable relative to the real world. At least for AR applications, placement of virtual objects in spatial relation to physical objects (e.g., presented to appear spatially proximate a physical object in two- or three-dimensions) may be a non-trivial problem. For example, head movement may significantly complicate placement of virtual objects in a view of an ambient environment. Such is true whether the view is captured as an image of the ambient environment and then projected or displayed to the end user, or whether the end user perceives the view of the ambient environment directly. For instance, head movement will likely cause a field of view of the end user to change, which will likely require an update to where various virtual objects are displayed in the field of the view of the end user. Additionally, head movements may occur within a large variety of ranges and speeds. Head movement speed may vary not only between different head movements, but within or across the range of a single head movement. For instance, head movement speed may initially increase (e.g., linearly or not) from a starting point, and may decrease as an ending point is reached, obtaining a maximum speed somewhere between the starting and ending points of the head movement. Rapid head movements may even exceed the ability of the particular display or projection technology to render images that appear uniform and/or as smooth motion to the end user.

Head tracking accuracy and latency (e.g., the elapsed time between when the user moves his or her head and the time when the image gets updated and displayed to the user) have been challenges for VR and AR systems. Especially for display systems that fill a substantial portion of the user's visual field with virtual elements, it is advantageous if the accuracy of head-tracking is high and that the overall system latency is very low from the first detection of head motion to the updating of the light that is delivered by the display to the user's visual system. If the latency is high, the system can create a mismatch between the user's vestibular and visual sensory systems, and generate a user perception scenario that can lead to motion sickness or simulator sickness. If the system latency is high, the apparent location of virtual objects will appear unstable during rapid head motions.

In addition to head-worn display systems, other display systems can benefit from accurate and low latency head pose detection. These include head-tracked display systems in which the display is not worn on the user's body, but is, e.g., mounted on a wall or other surface. The head-tracked display acts like a window onto a scene, and as a user moves his head relative to the "window" the scene is re-rendered to match the user's changing viewpoint. Other systems include a head-worn projection system, in which a head-worn display projects light onto the real world.

Additionally, in order to provide a realistic augmented reality experience, AR systems may be designed to be interactive with the user. For example, multiple users may play a ball game with a virtual ball and/or other virtual objects. One user may "catch" the virtual ball, and throw the ball back to another user. In some embodiments, a first user may be provided with a totem (e.g., a real bat communicatively coupled to the AR system) to hit the virtual ball. In some embodiments, a virtual user interface may be presented to the AR user to allow the user to select one of many options. The user may use totems, haptic devices, wearable components, or simply touch the virtual screen to interact with the system.

Detecting head pose and orientation of the user, and detecting a physical location of real objects in space enable the AR system to display virtual content in an effective and enjoyable manner. However, although these capabilities are key to an AR system, but are difficult to achieve. In other words, the AR system can recognize a physical location of a real object (e.g., user's head, totem, haptic device, wearable component, user's hand, etc.) and correlate the physical coordinates of the real object to virtual coordinates corresponding to one or more virtual objects being displayed to the user. This generally requires highly accurate sensors and sensor recognition systems that track a position and orientation of one or more objects at rapid rates. Current approaches do not perform localization at satisfactory speed or precision standards.

Thus, there is a need for a better localization system in the context of AR and VR devices.

Referring to <FIG>, some general componentry options are illustrated. In the portions of the detailed description which follow the discussion of <FIG>, various systems, subsystems, and components are presented for addressing the objectives of providing a high-quality, comfortably-perceived display system for human VR and/or AR.

As shown in <FIG>, an AR system user (<NUM>) is depicted wearing head mounted component (<NUM>) featuring a frame (<NUM>) structure coupled to a display system (<NUM>) positioned in front of the eyes of the user. A speaker (<NUM>) is coupled to the frame (<NUM>) in the depicted configuration and positioned adjacent the ear canal of the user (in one embodiment, another speaker, not shown, is positioned adjacent the other ear canal of the user to provide for stereo / shapeable sound control). The display (<NUM>) is operatively coupled (<NUM>), such as by a wired lead or wireless connectivity, to a local processing and data module (<NUM>) which may be mounted in a variety of configurations, such as fixedly attached to the frame (<NUM>), fixedly attached to a helmet or hat (<NUM>) as shown in the embodiment of <FIG>, embedded in headphones, removably attached to the torso (<NUM>) of the user (<NUM>) in a backpack-style configuration as shown in the embodiment of <FIG>, or removably attached to the hip (<NUM>) of the user (<NUM>) in a belt-coupling style configuration as shown in the embodiment of <FIG>.

The local processing and data module (<NUM>) may include a power-efficient processor or controller, as well as digital memory, such as flash memory, both of which may be utilized to assist in the processing, caching, and storage of data a) captured from sensors which may be operatively coupled to the frame (<NUM>), such as image capture devices (such as cameras), microphones, inertial measurement units (which may include an accelerometer and a gyroscope or a magnetometer), accelerometers, compasses, gyroscopes, magnetometers, or GPS units, radio devices; and/or b) acquired and/or processed using the remote processing module (<NUM>) and/or remote data repository (<NUM>), possibly for passage to the display (<NUM>) after such processing or retrieval. The local processing and data module (<NUM>) may be operatively coupled (<NUM>, <NUM>), such as via a wired or wireless communication links, to the remote processing module (<NUM>) and remote data repository (<NUM>) such that these remote modules (<NUM>, <NUM>) are operatively coupled to each other and available as resources to the local processing and data module (<NUM>).

In one embodiment, the remote processing module (<NUM>) may include one or more relatively powerful processors or controllers configured to analyze and process data and/or image information. In one embodiment, the remote data repository (<NUM>) may include a relatively large-scale digital data storage facility, which may be available through the internet or other networking configuration in a "cloud" resource configuration. In one embodiment, all data is stored and all computation is performed in the local processing and data module, allowing fully autonomous use from any remote modules.

Referring now to <FIG>, a schematic illustrates coordination between the cloud computing assets (<NUM>) and local processing assets, which may, for example reside in head mounted componentry (<NUM>) coupled to the user's head (<NUM>) and a local processing and data module (<NUM>), coupled to the user's belt (<NUM>; therefore the component <NUM> may also be termed a "belt pack" <NUM>), as shown in <FIG>. In one embodiment, the cloud (<NUM>) assets, such as one or more server systems (<NUM>) are operatively coupled (<NUM>), such as via wired or wireless networking (wireless being preferred for mobility, wired being preferred for certain high-bandwidth or high-data-volume transfers that may be desired), directly to (<NUM>, <NUM>) one or both of the local computing assets, such as processor and memory configurations, coupled to the user's head (<NUM>) and belt (<NUM>) as described above. These computing assets local to the user may be operatively coupled to each other as well, via wired and/or wireless connectivity configurations (<NUM>), such as the wired coupling (<NUM>) discussed below in reference to <FIG>. In one embodiment, to maintain a low-inertia and small-size subsystem mounted to the user's head (<NUM>), primary transfer between the user and the cloud (<NUM>) may be via the link between the subsystem mounted at the belt (<NUM>) and the cloud, with the head mounted (<NUM>) subsystem primarily data-tethered to the belt-based (<NUM>) subsystem using wireless connectivity, such as ultra-wideband ("UWB") connectivity, as is currently employed, for example, in personal computing peripheral connectivity applications.

With efficient local and remote processing coordination, and an appropriate display device for a user, such as the user interface or user display system (<NUM>) shown in <FIG>, or variations thereof, aspects of one world pertinent to a user's current actual or virtual location may be transferred or "passed" to the user and updated in an efficient fashion. In other words, a map of the world may be continually updated at a storage location which may partially reside on the user's AR system and partially reside in the cloud resources. The map (also referred to as a "passable world model") may be a large database including raster imagery, <NUM>-D and <NUM>-D points, parametric information and other information about the real world. As more and more AR users continually capture information about their real environment (e.g., through cameras, sensors, IMUs, etc.), the map becomes more and more accurate and complete.

With a configuration as described above, wherein there is one world model that can reside on cloud computing resources and be distributed from there, such world can be "passable" to one or more users in a relatively low bandwidth form preferable to trying to pass around real-time video data or the like. The augmented experience of the person standing near the statue (e.g., as shown in <FIG>) may be informed by the cloud-based world model, a subset of which may be passed down to them and their local display device to complete the view. A person sitting at a remote display device, which may be as simple as a personal computer sitting on a desk, can efficiently download that same section of information from the cloud and have it rendered on their display. Indeed, one person actually present in the park near the statue may take a remotely-located friend for a walk in that park, with the friend joining through virtual and augmented reality. The system will need to know where the street is, wherein the trees are, where the statue is - but with that information on the cloud, the joining friend can download from the cloud aspects of the scenario, and then start walking along as an augmented reality local relative to the person who is actually in the park.

Three-dimensional (<NUM>-D) points may be captured from the environment, and the pose (e.g., vector and/or origin position information relative to the world) of the cameras that capture those images or points may be determined, so that these points or images may be "tagged", or associated, with this pose information. Then points captured by a second camera may be utilized to determine the pose of the second camera. In other words, one can orient and/or localize a second camera based upon comparisons with tagged images from a first camera. Then this knowledge may be utilized to extract textures, make maps, and create a virtual copy of the real world (because then there are two cameras around that are registered).

So at the base level, in one embodiment a person-worn system can be utilized to capture both <NUM>-D points and the <NUM>-D images that produced the points, and these points and images may be sent out to a cloud storage and processing resource. They may also be cached locally with embedded pose information (e.g., cache the tagged images); so the cloud may have on the ready (e.g., in available cache) tagged <NUM>-D images (e.g., tagged with a <NUM>-D pose), along with <NUM>-D points. If a user is observing something dynamic, he may also send additional information up to the cloud pertinent to the motion (for example, if looking at another person's face, the user can take a texture map of the face and push that up at an optimized frequency even though the surrounding world is otherwise basically static). More information on object recognizers and the passable world model may be found in <CIT>, entitled "System and method for augmented and virtual reality", which is incorporated by reference in its entirety herein, along with the following additional disclosures, which related to augmented and virtual reality systems such as those developed by Magic Leap, Inc. of Plantation, Florida: <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; and <CIT>, each of which is hereby incorporated by reference herein in its entirety.

GPS and other localization information may be utilized as inputs to such processing. Highly accurate localization of the user's head, totems, hand gestures, haptic devices etc. may be advantageous in order to display appropriate virtual content to the user.

The head-mounted device (<NUM>) may include displays positionable in front of the eyes of the wearer of the device. The displays may include light field displays. The displays may be configured to present images to the wearer at a plurality of depth planes. The displays may include planar waveguides with diffraction elements. Examples of displays, head-mounted devices, and other AR components usable with any of the embodiments disclosed herein are described in <CIT>. <CIT> is hereby incorporated by reference herein in its entirety.

One approach to achieve high precision localization may involve the use of an electromagnetic (EM) field coupled with EM sensors that are strategically placed on the user's AR head set, belt pack, and/or other ancillary devices (e.g., totems, haptic devices, gaming instruments, etc.). EM tracking systems typically include at least an EM field emitter (sometimes referred to as a transmitter or emitter generally) and at least one EM field sensor (sometimes referred to as a receiver or sensor generally). The EM emitter generates an EM field having a known spatial (and/or temporal) distribution in the environment of wearer of the AR headset. The EM field sensors measure the generated EM fields at the locations of the sensors. Based on these measurements and knowledge of the distribution of the generated EM field, a pose (e.g., a position and/or orientation) of a field sensor relative to the emitter may be determined. Accordingly, the pose of an object to which the sensor is attached may be determined.

EM tracking may be a promising approach for localization and tracking of objects in multiple domains, including applications in AR, VR, medicine, sports, manufacturing and gaming. A possible advantage of EM localization over some other methods using optical imaging techniques is that EM tracking can localize objects in the presence of occlusions (e.g., where a first object is in front of a second object and at least partially blocks the second object from view of an imaging system). EM tracking can also offer good dynamic response time, and may not require performance of complex image processing and computer vision techniques sometimes implemented with camera methods. Camera-based tracking systems may require dedicated algorithms and hardware for their high computational workload and may also lack robustness against fast motion dynamics and occlusions. In AR and VR applications, the processor (e.g., the local processing and data module <NUM>) performs many computationally-intensive tasks (e.g., rendering virtual content to the user as described with reference to <FIG>), as well as performing many of these tasks in real time. Therefore, reducing the computational complexity of tasks performed by the processor may be advantageous in AR and VR applications, and the usage of EM tracking systems can also be advantageous in offloading tasks from the processor.

Referring now to <FIG>, an example system diagram of an EM tracking system (e.g., such as those developed by organizations such as the Biosense division of Johnson & Johnson Corporation, Polhemus, Inc. of Colchester, Vermont, manufactured by Sixense Entertainment, Inc. of Los Gatos, California, and other tracking companies) is illustrated. In one or more embodiments, the EM tracking system includes an EM emitter <NUM> (which sometimes may be referred to as an EM field emitter or simply an emitter), which is configured to emit a known magnetic field. As shown in <FIG>, the EM emitter may be coupled to a power supply (e.g., electric current, batteries, etc.) to provide power to the emitter <NUM>.

In one or more embodiments, the EM emitter <NUM> includes several coils (e.g., at least three coils positioned perpendicular to each other to produce field in the X, Y and Z directions) that generate magnetic fields. This magnetic field is used to establish a coordinate space (e.g., an X-Y-Z Cartesian coordinate space). This allows the system to map a position of the sensors (e.g., an (X,Y,Z) position) in relation to the known magnetic field, and helps determine a position and/or orientation of the sensors. In one or more embodiments, the EM sensors 404a, 404b, etc. may be attached to one or more real objects. The EM sensors <NUM> (which sometimes may be referred to as EM field sensors or simply sensors) may include smaller coils in which current may be induced through the emitted EM field. Generally the "sensor" components (<NUM>) may include small coils or loops, such as a set of three differently-oriented (e.g., such as orthogonally oriented relative to each other) coils coupled together within a small structure such as a cube or other container, that are positioned/oriented to capture incoming magnetic flux from the magnetic field emitted by the emitter (<NUM>), and by comparing currents induced through these coils, and knowing the relative positioning and orientation of the coils relative to each other, relative position and orientation of a sensor relative to the emitter may be calculated.

One or more parameters pertaining to a behavior of the coils and inertial measurement unit ("IMU") components operatively coupled to the EM tracking sensors may be measured to detect a position and/or orientation of the sensor (and the object to which it is attached to) relative to a coordinate system to which the EM emitter is coupled. In one or more embodiments, multiple sensors may be used in relation to the EM emitter to detect a position and orientation of each of the sensors within the coordinate space. The EM tracking system may provide positions in three directions (e.g., X, Y and Z directions), and further in two or three orientation angles (e.g., yaw, pitch, and roll). For example, the EM tracking system may determine a six degree-of-freedom (6DOF) pose including three spatial coordinates (e.g., X, Y, and Z) and three orientation angles (e.g., yaw, pitch, and roll). In one or more embodiments, measurements of the IMU may be compared to the measurements of the coil to determine a position and orientation of the sensors. In one or more embodiments, both EM data and IMU data, along with various other sources of data, such as cameras, depth sensors, and other sensors, may be combined to determine the position and orientation. This information may be transmitted (e.g., wireless communication, Bluetooth, etc.) to the controller <NUM>. In one or more embodiments, pose (or position and orientation) may be reported at a relatively high refresh rate in conventional systems. Conventionally an EM emitter is coupled to a relatively stable and large object, such as a table, operating table, wall, or ceiling, and one or more sensors are coupled to smaller objects, such as medical devices, handheld gaming components, or the like. Alternatively, as described below in reference to <FIG>, various features of the EM tracking system may be employed to produce a configuration wherein changes or deltas in position and/or orientation between two objects that move in space relative to a more stable global coordinate system may be tracked; in other words, a configuration is shown in <FIG> wherein a variation of an EM tracking system may be utilized to track position and orientation delta between a head-mounted component and a hand-held component, while head pose relative to the global coordinate system (say of the room environment local to the user) is determined otherwise, such as by simultaneous localization and mapping ("SLAM") techniques using outward-capturing cameras which may be coupled to the head mounted component of the system.

The controller <NUM> may control the EM field generator <NUM>, and may also capture data from the various EM sensors <NUM>. It should be appreciated that the various components of the system may be coupled to each other through any electro-mechanical or wireless/Bluetooth means. The controller <NUM> may also include data regarding the known magnetic field, and the coordinate space in relation to the magnetic field. This information is then used to detect the position and orientation of the sensors in relation to the coordinate space corresponding to the known EM field.

One advantage of EM tracking systems is that they produce highly accurate tracking results with minimal latency and high resolution. Additionally, the EM tracking system does not necessarily rely on optical trackers, and sensors/objects not in the user's line-of-vision may be easily tracked.

It should be appreciated that the strength of the EM field drops as a cubic function of distance r from a coil transmitter (e.g., EM emitter <NUM>). Thus, an algorithm may be used based on a distance away from the EM emitter. The controller <NUM> may be configured with such algorithms to determine a position and orientation (e.g., a 6DOF pose) of the sensor/object at varying distances away from the EM emitter. Given the rapid decline of the strength of the EM field as the sensor moves farther away from the EM emitter, best results, in terms of accuracy, efficiency and low latency, may be achieved at closer distances. In typical EM tracking systems, the EM emitter is powered by electric current (e.g., plug-in power supply) and has sensors located within 20ft radius away from the EM emitter. A shorter radius between the sensors and emitter may be more desirable in many applications, including AR applications.

Referring now to <FIG>, an example flowchart describing a functioning of a typical EM tracking system is briefly described. At <NUM>, a known EM field is emitted. In one or more embodiments, the magnetic emitter may generate magnetic fields each coil may generate an electric field in one direction (e.g., X, Y or Z). The magnetic fields may be generated with an arbitrary waveform. In one or more embodiments, the magnetic field component along each of the axes may oscillate at a slightly different frequency from other magnetic field components along other directions. At <NUM>, a coordinate space corresponding to the EM field may be determined. For example, the control <NUM> of <FIG> may automatically determine a coordinate space around the emitter based on the EM field. At <NUM>, a behavior of the coils at the sensors (which may be attached to a known object) may be detected. For example, a current induced at the coils may be calculated. In some embodiments, a rotation of coils, or any other quantifiable behavior may be tracked and measured. At <NUM>, this behavior may be used to detect a position or orientation of the sensor(s) and/or known object. For example, the controller <NUM> may consult a mapping table that correlates a behavior of the coils at the sensors to various positions or orientations. Based on these calculations, the position in the coordinate space along with the orientation of the sensors may be determined. The order of the blocks in the flowchart in <FIG> is intended to be illustrative and not limiting. For example, the block <NUM> can be performed before the block <NUM> is performed, in some embodiments.

In the context of AR systems, one or more components of the EM tracking system may need to be modified to facilitate accurate tracking of mobile components. As described above, tracking the user's head pose and orientation may be desirable in many AR applications. Accurate determination of the user's head pose and orientation allows the AR system to display the right virtual content to the user. For example, the virtual scene may include a monster hiding behind a real building. Depending on the pose and orientation of the user's head in relation to the building, the view of the virtual monster may need to be modified such that a realistic AR experience is provided. Or, a position and/or orientation of a totem, haptic device or some other means of interacting with a virtual content may be important in enabling the AR user to interact with the AR system. For example, in many gaming applications, the AR system can detect a position and orientation of a real object in relation to virtual content. Or, when displaying a virtual interface, a position of a totem, user's hand, haptic device or any other real object configured for interaction with the AR system may be known in relation to the displayed virtual interface in order for the system to understand a command, etc. Conventional localization methods including optical tracking and other methods are typically plagued with high latency and low resolution problems, which makes rendering virtual content challenging in many augmented reality applications.

In one or more embodiments, the EM tracking system, discussed in relation to <FIG> and <FIG> may be adapted to the AR system to detect position and orientation of one or more objects in relation to an emitted EM field. Typical EM systems tend to have a large and bulky EM emitters (e.g., <NUM> in <FIG>), which is problematic for head-mounted AR devices. However, smaller EM emitters (e.g., in the millimeter range) may be used to emit a known EM field in the context of the AR system.

Referring now to <FIG>, an EM tracking system <NUM> may be incorporated with an AR system as shown, with an EM emitter <NUM> incorporated as part of a hand-held controller <NUM>. The controller <NUM> may be movable independently relative to the AR headset (or the belt pack <NUM>). For example, the user can hold the controller <NUM> in his or her hand, or the controller could be mounted to the user's hand or arm (e.g., as a ring or bracelet or as part of a glove worn by the user). In one or more embodiments, the hand-held controller may be a totem to be used in a gaming scenario (e.g., a multi-degree-of-freedom controller) or to provide a rich user experience in an AR environment or to allow user interaction with an AR system. In some embodiments, the hand-held controller may be a haptic device. In some embodiments, the EM emitter may simply be incorporated as part of the belt pack <NUM>. The controller <NUM> may include a battery <NUM> or other power supply that powers that EM emitter <NUM>. It should be appreciated that the EM emitter <NUM> may also include or be coupled to an IMU <NUM> component configured to assist in determining positioning and/or orientation of the EM emitter <NUM> relative to other components. This may be especially advantageous in cases where both the emitter <NUM> and the sensors (<NUM>) are mobile. The IMU <NUM> may comprise an accelerometer and a gyroscope in some embodiments. Placing the EM emitter <NUM> in the hand-held controller rather than the belt pack, as shown in the embodiment of <FIG>, helps ensure that the EM emitter is not competing for resources at the belt pack, but rather uses its own battery source at the controller <NUM>. In some embodiments, the EM emitter <NUM> may be disposed on the AR headset <NUM> and the sensors <NUM> may be disposed on the controller <NUM> or belt pack <NUM>.

In one or more embodiments, the EM sensors <NUM> may be placed on one or more locations on the user's headset, along with other sensing devices such as one or more IMUs or additional magnetic flux capturing coils <NUM>. For example, as shown in <FIG>, sensors (<NUM>, <NUM>) may be placed on one or both sides of the head set (<NUM>). Since these sensors are engineered to be rather small (and hence may be less sensitive, in some cases), having multiple sensors may improve efficiency and precision. In one or more embodiments, one or more sensors may also be placed on the belt pack <NUM> or any other part of the user's body or in the controller <NUM>. The sensors (<NUM>, <NUM>) may communicate wirelessly or through Bluetooth to a computing apparatus that determines a pose and orientation of the sensors (and the AR headset to which it is attached). In some embodiments, the computing apparatus may reside at the belt pack <NUM>. In some embodiments, the computing apparatus may reside at the headset itself, or even the controller <NUM>. The computing apparatus may in turn include a mapping database (e.g., passable world model, coordinate space, etc.) to detect pose, to determine the coordinates of real objects and virtual objects, and may even connect to cloud resources and the passable world model, in one or more embodiments.

As described above, conventional EM emitters may be too bulky for AR devices. Therefore the EM emitter may be engineered to be compact, using smaller coils compared to traditional systems. However, given that the strength of the EM field decreases as a cubic function of the distance away from the emitter, a shorter radius between the EM sensors <NUM> and the EM emitter <NUM> (e.g., about <NUM> to <NUM> ft) may reduce power consumption when compared to conventional systems such as the one detailed in <FIG>.

This aspect may either be utilized to prolong the life of the battery <NUM> that may power the controller <NUM> and the EM emitter <NUM>, in one or more embodiments. In some embodiments, this aspect may be utilized to reduce the size of the coils generating the magnetic field at the EM emitter <NUM>. However, in order to get the same strength of magnetic field, the power may be need to be increased. This allows for a compact EM emitter unit <NUM> that may fit compactly at the controller <NUM>.

Several other changes may be made when using the EM tracking system <NUM> for AR devices. Although this pose reporting rate is rather good, AR systems may require an even more efficient pose reporting rate. To this end, IMU-based pose tracking may (additionally or alternatively) be used in the sensors. Advantageously, the IMUs may remain as stable as possible in order to increase an efficiency of the pose detection process. The IMUs may be engineered such that they remain stable up to <NUM>-<NUM> milliseconds. It should be appreciated that some embodiments may utilize an outside pose estimator module (e.g., IMUs may drift over time) that may enable pose updates to be reported at a rate of <NUM> to <NUM>. By keeping the IMUs stable at a reasonable rate, the rate of pose updates may be dramatically decreased to <NUM> to <NUM> (as compared to higher frequencies in conventional systems).

If the EM tracking system <NUM> may be run at, for example, a <NUM>% duty cycle (e.g., only pinging for ground truth every <NUM> milliseconds), this would be another way to save power at the AR system. This would mean that the EM tracking system wakes up every <NUM> milliseconds out of every <NUM> milliseconds to generate a pose estimate. This directly translates to power consumption savings, which may, in turn, affect size, battery life and cost of the AR device.

In one or more embodiments, this reduction in duty cycle may be strategically utilized by providing two hand-held controllers (not shown) rather than just one. For example, the user may be playing a game that requires two totems, etc. Or, in a multi-user game, two users may have their own totems/hand-held controllers to play the game. When two controllers (e.g., symmetrical controllers for each hand) are used rather than one, the controllers may operate at offset duty cycles. The same concept may also be applied to controllers utilized by two different users playing a multi-player game, for example.

Referring now to <FIG>, an example flowchart describing the EM tracking system <NUM> in the context of AR devices is described. At <NUM>, a portable (e.g., hand-held) controller containing an EM emitter emits a magnetic field. At <NUM>, the EM sensors (e.g., placed on headset, belt pack, etc.) detect the magnetic field. At <NUM>, a pose (e.g., position or orientation) of the headset/belt is determined based on a behavior of the coils/IMUs at the sensors. The pose may include a 6DOF pose or have fewer than all six degrees of freedom (e.g., one or more spatial coordinates or one or more orientation angles). At <NUM>, the pose information is conveyed to the computing apparatus (e.g., at the belt pack or headset). At <NUM>, optionally, a mapping database (e.g., passable world model) may be consulted to correlate the real world coordinates (e.g., determined for the pose of the headset/belt) with the virtual world coordinates. At <NUM>, virtual content may be delivered to the user at the AR headset and displayed to the user (e.g., via the light field displays described herein). It should be appreciated that the flowchart described above is for illustrative purposes only, and should not be read as limiting.

Advantageously, using an EM tracking system similar to the one outlined in <FIG> enables low latency pose tracking (e.g., head position or orientation, position and orientation of totems, belt packs, and other controllers). This allows the AR system to project virtual content (based at least in part on the determined pose) with a higher degree of accuracy, and very low latency when compared to optical tracking techniques.

Referring to <FIG>, an augmented reality system configuration is illustrated featuring many sensing components. A head mounted wearable component (<NUM>) is shown operatively coupled (<NUM>) to a local processing and data module (<NUM>), such as a belt pack, here using a physical multicore lead which also features a control and quick release module (<NUM>). The control and quick release module (<NUM>) can include buttons for operation of the associated system, for example, an on/off button and up/down volume controls. Opposing ends of the module (<NUM>) may be connected to electrical leads running between the local processing and data module (<NUM>) and the display (<NUM>) as shown in <FIG>.

The local processing and data module (<NUM>) is operatively coupled (<NUM>) to a hand held component/controller (<NUM>), here by a wireless connection such as low power Bluetooth; the component (<NUM>) may also be operatively coupled (<NUM>) directly to the head mounted wearable component (<NUM>), such as by a wireless connection such as low power Bluetooth. Generally where IMU data is passed to coordinate pose detection of various components, a high-frequency connection is desirable, such as in the range of hundreds or thousands of cycles/second or higher; tens of cycles per second may be adequate for EM localization sensing, such as by the sensor (<NUM>) and transmitter (<NUM>) pairings. Also shown is a global (also referred to as world) coordinate system (<NUM>), representative of fixed objects in the real world around the user, such as a wall (<NUM>).

Cloud resources (<NUM>) also may be operatively coupled (<NUM>, <NUM>, <NUM>, <NUM>) to the local processing and data module (<NUM>), to the head mounted wearable component (<NUM>), to resources which may be coupled to the wall (<NUM>) or other item fixed relative to the global coordinate system (<NUM>), respectively. The resources coupled to the wall (<NUM>) or having known positions and/or orientations relative to the global coordinate system (<NUM>) may include a wireless transceiver (<NUM>), an EM emitter (<NUM>) and/or receiver (<NUM>), a beacon or reflector (<NUM>) configured to emit or reflect a given type of radiation, such as an infrared LED beacon, a cellular network transceiver (<NUM>), a RADAR emitter or detector (<NUM>), a LIDAR emitter or detector (<NUM>), a GPS transceiver (<NUM>), a poster or marker having a known detectable pattern (<NUM>), and a camera (<NUM>).

The head mounted wearable component (<NUM>) features similar components, as illustrated, in addition to lighting emitters (<NUM>) configured to assist the camera (<NUM>) detectors, such as infrared emitters (<NUM>) for an infrared camera (<NUM>); also featured on the head mounted wearable component (<NUM>) are one or more strain gauges (<NUM>), which may be fixedly coupled to the frame or mechanical platform of the head mounted wearable component (<NUM>) and configured to determine deflection of such platform in between components such as EM receiver sensors (<NUM>) or display elements (<NUM>), wherein it may be valuable to understand if bending of the platform has occurred, such as at a thinned portion of the platform, such as the portion above the nose on the eyeglasses-like platform depicted in <FIG>.

The head mounted wearable component (<NUM>) also features a processor (<NUM>) and one or more IMUs (<NUM>). Each of the components preferably are operatively coupled to the processor (<NUM>), which can include a hardware controller, hardware microprocessor, application specific integrated circuit (ASIC), etc. The component (<NUM>) and local processing and data module (<NUM>) are illustrated featuring similar components. As shown in <FIG>, with so many sensing and connectivity means, such a system is likely to be heavy, power hungry, large, and relatively expensive. However, for illustrative purposes, such a system may be utilized to provide a very high level of connectivity, system component integration, and position/orientation tracking. For example, with such a configuration, the various main mobile components (<NUM>, <NUM>, <NUM>) may be localized in terms of position relative to the global coordinate system using WiFi, GPS, or Cellular signal triangulation; beacons, EM tracking (as described herein), RADAR, and LIDAR systems may provide yet further location and/or orientation information and feedback. Markers and cameras also may be utilized to provide further information regarding relative and absolute position and orientation. For example, the various camera components (<NUM>), such as those shown coupled to the head mounted wearable component (<NUM>), may be utilized to capture data which may be utilized in simultaneous localization and mapping protocols, or "SLAM", to determine where the component (<NUM>) is and how it is oriented relative to other components.

In some embodiments, in addition or as an alternative to a LIDAR (<NUM>) type of depth sensor, the system includes a generic depth camera or depth sensor, which may, for example, be either a stereo triangulation style depth sensor (such as a passive stereo depth sensor, a texture projection stereo depth sensor, or a structured light stereo depth sensor) or a time or flight style depth sensor (such as a LIDAR depth sensor or a modulated emission depth sensor); further, the system may include an additional forward facing "world" camera (<NUM>, which may be a grayscale camera, having a sensor capable of 720p range resolution) as well as a relatively high-resolution "picture camera" (which may be a full color camera, having a sensor capable of two megapixel or higher resolution, for example).

Referring to <FIG>, an EM sensing coil assembly (<NUM>, e.g., <NUM> individual coils coupled to a housing) is shown coupled to a head mounted component (<NUM>); such a configuration adds additional geometry to the overall assembly which may not be desirable. Referring to <FIG>, rather than housing the coils in a box or single housing <NUM> as in the configuration of <FIG>, the individual coils may be integrated into the various structures of the head mounted component (<NUM>), as shown in <FIG> shows examples of locations on the head-mounted display <NUM> for X-axis coils (<NUM>), Y-axis coils (<NUM>), and Z-axis coils (<NUM>). Thus, the sensing coils may be distributed spatially on or about the head-mounted display (<NUM>) to provide a desired spatial resolution or accuracy of the localization and/or orientation of the display (<NUM>) by the EM tracking system.

Referring again to <FIG>, a distributed sensor coil configuration is shown for the AR device <NUM>. The AR device <NUM> can have a single EM sensor device (<NUM>), such as a housing containing three orthogonal sensing coils, one for each direction of X, Y, Z, which may be coupled to the wearable component (<NUM>) for <NUM> degree of freedom (6DOF) tracking, as described herein. Also as noted above, such a device may be disintegrated, with the three sub-portions (e.g., coils) attached at different locations of the wearable component (<NUM>), as shown in <FIG>. To provide further design alternatives, each individual sensor coil may be replaced with a group of similarly oriented coils, such that the overall magnetic flux for any given orthogonal direction is captured by the group rather than by a single coil for each orthogonal direction. In other words, rather than one coil for each orthogonal direction, a group of smaller coils may be utilized and their signals aggregated to form the signal for that orthogonal direction. In some embodiments wherein a particular system component, such as a head mounted component (<NUM>) features two or more EM coil sensor sets, the system may be configured to selectively utilize the sensor and emitter pairing that are closest to each other (e.g., within <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>) to improve or optimize the performance of the system. In some embodiments, the EM emitter(s) and the EM sensor(s) can be arranged differently. For example, the EM emitter(s) can be disposed in or on the head mounted component (<NUM>), and the EM sensor(s) can be disposed in or on the controller (<NUM>) or the belt pack (<NUM>). As another example, the EM sensor(s) can be disposed in or on the head mounted component (<NUM>), and the EM emitter(s) can be disposed in or on the controller (<NUM>) or the belt pack (<NUM>). As yet another example, the EM emitter(s) can be disposed in or on the belt (<NUM>), and the EM sensor(s) can be disposed in or on the controller (<NUM>) or the head mounted component (<NUM>).

EM tracking updating may be relatively "expensive" in terms of power for a portable system, and may not be capable of very high frequency updating. In a "sensor fusion" configuration, more frequently updated localization information from another sensor such as an IMU may be combined, along with data from another sensor, such as an optical sensor (e.g., a camera or a depth camera), which may or may not be at a relatively high frequency; the net of fusing all of these inputs may place a lower demand upon the EM system and provides for quicker updating. As described herein, in some embodiments, sensor fusion techniques can include fusing or combining IMU (or other sensor) data with EM tracking data to provide a robust estimation of pose of the hand-held component or the head mounted component.

<FIG> illustrate example headsets with more than one EM sensor 604C, 604D. <FIG> illustrate example handheld controllers with more than one EM emitters 602E, 602F. Depending on the implementation, the quantity of EM sensors and/or EM emitters may vary, such as to improve accuracy of pose detection generated by the EM tracking system. For example, a headset with two EM sensors 604C (e.g., <FIG>) may be used with a controller with one EM emitter, two EM emitters 602E (e.g., <FIG>), three EM emitters 602F (e.g., <FIG>), or more EM emitters. Similarly a headset with three (or any other quantity) EM sensors 604D (e.g., <FIG>) may be used with a controller with one EM emitter, two EM emitters 602E (e.g., <FIG>), three EM emitters 602F (e.g., <FIG>), or more EM emitters.

Embodiments with multiple EM sensors on different sides of the headset (e.g., <FIG>) may reduce the effect of metal distortion. For example, in some implementation the input from the EM sensors 604C may be weighted based on proximity or position with reference to the controller with the EM emitters <NUM>. For example, if the controller with the EM emitters <NUM> is to the right of the user, an EM sensor <NUM> on the right side of the headset may have a higher weighted input than other EM sensors that have a less direct communication channel with the controller (e.g., EM sensors <NUM> on the left side or middle of the headset).

Use of multiple EM sensors may further provide data that is usable to quantitatively monitor distortion that may be caused by interference of EM signals between EM emitters and the EM sensors. For example, with two EM sensors on the headset in known locations and one EM emitter on the controller, the two resolved position vectors between the EM sensors and the EM emitter can be used to form a triangle. This "sensed" displacement between the EM sensors may be compared with "known" EM sensor positions, for example, in a model of the headset. This quantitative estimate of distortion may then be used to provide feedback to the user, software applications, etc., such as an indication of "expected distortion" (e.g., the distortion effect measured between the headset and controller in a clean environment) and "environmental distortion" (e.g., after subtracting out the expected distortion, the amount of distortion that remains). Similar weighting and distortion calculations may be determined in configurations having with other quantities of emitters and sensors.

Referring to <FIG>, in one embodiment, after a user powers up his or her wearable computing system (<NUM>), a head mounted component assembly may capture a combination of IMU and camera data (the camera data being used, for example, for SLAM analysis, such as at the belt pack processor where there may be more raw processing horsepower present) or EM tracking system data to determine and update head pose (e.g., position or orientation) relative to a real world global coordinate system (<NUM>; an example of the real world global coordinate system <NUM> is shown in <FIG>). The user may also activate a handheld component to, for example, play an augmented reality game (<NUM>), and the handheld component may include an EM transmitter operatively coupled to one or both of the belt pack and head mounted component (<NUM>). One or more EM field coil receiver sets (e.g., a set being <NUM> differently-oriented individual coils) coupled to the head mounted component to capture magnetic flux from the transmitter, which may be utilized to determine positional or orientational difference (or "delta"), between the head mounted component and handheld component (<NUM>). The combination of the head mounted component assisting in determining pose relative to the global coordinate system, and the hand held assisting in determining relative location and orientation of the handheld relative to the head mounted component, allows the system to generally determine where each component is relative to the global coordinate system, and thus the user's head pose, and handheld pose may be tracked, preferably at relatively low latency, for presentation of augmented reality image features and interaction using movements and rotations of the handheld component (<NUM>).

Referring to <FIG>, an embodiment is illustrated that is somewhat similar to that of <FIG>, with the exception that the system has many more sensing devices and configurations available to assist in determining pose of both the head mounted component (<NUM>) and a hand held component (<NUM>, <NUM>), such that the user's head pose, and handheld pose may be tracked, preferably at relatively low latency, for presentation of augmented reality image features and interaction using movements and rotations of the handheld component (<NUM>).

In various implementations, the augmented reality device can include a computer vision system configured to implement one or more computer vision techniques to identify objects in the environment of the system, user gestures, or perform other computer vision procedures used or described herein. For example, as described below, the computer vision system can analyze images of the user input device / controller <NUM> taken by an outward-facing camera <NUM> to determine the pose (e.g., position or orientation) of the device for use in compensating for EM distortion in an electromagnetic tracking system. Nonlimiting examples of computer vision techniques include: Scale-invariant feature transform (SIFT), speeded up robust features (SURF), oriented FAST and rotated BRIEF (ORB), binary robust invariant scalable keypoints (BRISK), fast retina keypoint (FREAK), Viola-Jones algorithm, Eigenfaces approach, Lucas-Kanade algorithm, Horn-Schunk algorithm, Mean-shift algorithm, visual simultaneous location and mapping (vSLAM) techniques, a sequential Bayesian estimator, a Kalman filter, an extended Kalman filter, bundle adjustment, Adaptive thresholding (and other thresholding techniques), Iterative Closest Point (ICP), Semi Global Matching (SGM), Semi Global Block Matching (SGBM), Feature Point Histograms, various machine learning algorithms (such as e.g., support vector machine, k-nearest neighbors algorithm, Naive Bayes, neural network (including convolutional or deep neural networks), or other supervised/unsupervised models, etc.), and so forth.

EM localization is based on magnetic field coupling measured by one or more EM sensors derived from excitation of magnetic fields by one or more EM emitters. There are two common ways of exciting the magnetic fields. One is based on a pulsed alternating current (AC) field, and the other is based on a pulsed direct current (DC) field. At present, EM tracking systems utilizing an AC EM field are more common, because they tend to be less sensitive to noise. As described with reference to <FIG> and <FIG>, for 6DOF localization, the EM sensor (e.g., the EM sensor <NUM>) and the EM emitter (e.g., the EM emitter <NUM>) can each include three orthogonally-aligned coils (e.g., along respective X, Y, Z axes). In many applications using this configuration, the emitter coil currents in the EM emitter <NUM> are pulsed sequentially (e.g., in X, then in Y, and then in Z), and the resultant magnetic fields induce currents in each sensor coil in the EM sensor <NUM> that are then used to determine the position or orientation of the sensor coil relative to the emitter coil and thus the EM sensor <NUM> relative to the EM emitter <NUM>.

Without being bound or limited by the following theoretical development, an EM model for EM localization will now be presented. In this model, the magnetic field generated by the emitter coils in the EM emitter <NUM> is assumed to be an equivalent magnetic dipole field (which tends to be accurate when the size of the emitter coils in the EM emitter <NUM> is smaller than the distance between the emitter coils and sensor coils). The dipole field decreases with increasing distance between the EM emitter <NUM> and the EM sensor <NUM> as the inverse cube of the distance.

The equations for 6DOF localization can use Euler angle transformations (or quaternions) to describe the position and orientation of the EM sensor <NUM> with respect to the EM emitter <NUM>. The EM field sensed by the EM sensor <NUM> may be represented by a matrix equation: <MAT> where F is a 3x3 EM field matrix, c is a constant for any given coil configuration (e.g., proportional to a product of a number of loops of wire, an area of the loops, and a sensor gain), r is the distance between the EM emitter <NUM> and the EM sensor <NUM>, T is a <NUM>×<NUM> rotation matrix representing a <NUM> degree of freedom (3DOF) orientation of the EM sensor <NUM> with respect to the EM emitter <NUM>, P is a 3x3 rotation matrix representing the position of the EM sensor <NUM> with respect to the EM emitter <NUM>, K is a 3x3 diagonal matrix with diagonal elements proportional to [<NUM>, -<NUM>/<NUM>, -<NUM>/<NUM>], and E is a 3x3 diagonal matrix where diagonal elements represent the strengths of the EM fields measured by the three orthogonal emitter coils of the EM emitter <NUM>. The matrix P may be represented in terms of an azimuthal angle θ and a pitch ϕ by: <MAT> where roty is a 3x3 rotation matrix around the Y-axis and rotz is a 3x3 rotation matrix around the Z-axis.

As the elements of the matrices involve trigonometric functions, Equation (<NUM>) is actually a system of simultaneous nonlinear equations with six unknowns (three position variables and three orientation variables), which can be solved simultaneously (e.g., via iterative numerical techniques) to obtain the 6DOF pose of the EM sensor <NUM> with respect to the EM emitter <NUM>. The positions and orientations from the method described above may have to be transformed to a different frame of reference, because of the placement of the EM sensor coils with respect to a global frame of reference. This frame (or frame of reference) is sometimes called the world frame (or world frame of reference or world or global coordinate system). An example of a world coordinate system <NUM> is described with reference to <FIG>. In some implementations, the world coordinate system <NUM> is established when the AR device is turned on by the user, for example, when the user's initial head pose is determined. The origin of the world frame can be set at any point in the environment, for example, a corner of a room in which the user is operating the device could be set as the origin (e.g., with coordinates (<NUM>,<NUM>,<NUM>) in a Cartesian system).

<FIG> is a block diagram for an example of an inertial navigation system (INS) <NUM> that can accept input from an IMU <NUM> on a handheld user-input device (e.g., the hand-held controller / totem <NUM> described with reference to <FIG> and <FIG>) and provide the totem's 6DOF pose (e.g., position and orientation) in a world frame (e.g., the world coordinate system <NUM>) associated with an AR system <NUM>. The AR system <NUM> can utilize the 6DOF pose, for example, as described with reference to the flowcharts in <FIG>, <FIG>, and <FIG>.

As described herein, the totem IMU <NUM> can include, among other components, an accelerometer and a gyroscope. The accelerometer provides acceleration a(t) as a function of time, measured in the frame of reference of the totem. The gyroscope provides angular velocity ω(t) as a function of time, measured in the frame of reference of the totem.

The INS <NUM> can include a hardware processor that integrates the acceleration data twice to obtain the position of the totem <NUM> and integrates the angular velocity once to obtain the angular orientation of the totem <NUM> (e.g., expressed as Euler angles or quaternions). For example, the position x(t) of the totem <NUM> can be written as: <MAT> where x<NUM> and ν<NUM> are integration constants representing the initial position and velocity of the totem, respectively, at time t=<NUM>. The orientation θ(t) of the totem <NUM> can be written as: <MAT> where θ<NUM> is an integration constant representing the initial angular orientation of the totem at time t=<NUM>.

There are several challenges when implementing Equations (<NUM>) and (<NUM>). First, the initial position, orientation, and angular orientation of the totem <NUM> in the world frame of reference of the AR system <NUM> generally are not known. Therefore, the integration constants x<NUM>, ν<NUM>, and θ<NUM> may be difficult to determine without additional information or input from other sensors to link the position and orientation of the frame of reference of the IMU to the world frame of reference of the AR system <NUM> at the initial time (e.g., t=<NUM>). This link between the two frames of reference may sometimes be referred to herein as an offset, as it represents the offset between the position of the totem relative to the world frame of reference of the AR system <NUM> at the initial time (e.g., t=<NUM>).

The data from the totem IMU <NUM> generally is subject to error, nonlinearity, and noise. For example, the output from the accelerometer or gyroscope may have a bias, which is an offset from the true acceleration or angular velocity. For some sensors, the bias may be a function of time, temperature, orientation of the sensor, power source voltage, and so forth. Thus, the bias (which is unknown) can change over time in an unknown manner. Even if the sensor is initially calibrated to remove the bias that is present in the sensor, bias will tend to develop over time.

Error in the accelerometer and gyroscope data can lead to drift of the position and orientation, respectively, determined from Equations (<NUM>) and (<NUM>). Because of the double integration in Equation (<NUM>), error in accelerometer data leads to a drift in determined position that increases quadratically with time. Because of the single integration in Equation (<NUM>), error in gyroscope data leads to drift in determined orientation that increases linearly with time. If uncorrected, these drifts can cause the determined position and orientation to depart substantially from the actual position and orientation.

As will be described below, input from sensors additional to the totem IMU <NUM> can be fused with the IMU data (e.g., accelerometer data and gyroscope data) to reduce the drift and to link the position and orientation of the totem to the world frame of reference of the AR system <NUM>. Sensor fusion algorithms such as, for example, a Kalman filter, can be used to fuse the sensor data inputs together with a model of the sensor error state and frame of reference offset. For example, the Kalman filter can provide robust predictions of the pose of the totem in the presence of sensor bias, noise and offset for the initial pose of the totem in the world frame of reference of the AR system <NUM>. Although the embodiments described below utilize a Kalman filter, other statistical filters or stochastic data fusion techniques can be used. For example, a Kalman filter can include an extended Kalman filter, an unscented Kalman filter, or any other variety of Kalman filter. The stochastic data fusion techniques can include a Markov model, Bayesian filtering, linear quadratic estimation, and so forth. Further, although described in terms of estimating a 6DOF pose of the totem (e.g., position and orientation), this is not a requirement, and in other embodiments, the sensor fusion system can estimate a 3DOF pose (e.g., position or orientation).

As an illustrative example, in the case where the initial velocity ν<NUM> of the totem is zero, a model for the position of the totem can be written as: <MAT> where offsetx is an estimate of the position error between the world frame of reference of the AR system <NUM> and the accelerometer frame of reference (relative to an arbitrarily chosen coordinate origin), and ε(t) is an error state estimate to correct for bias in the accelerometer output. An analogous equation can be written for the angular orientation θ(t): <MAT> where offsetθ is an estimate of the angular error between the world frame of reference of the AR system <NUM> and the gyroscope frame of reference (relative to an arbitrarily chosen coordinate origin), and δ(t) is an error state estimate to correct for bias in the gyroscope output (angular velocity). The Kalman filter (or other appropriate filter) can provide estimates of the error states (e.g., the offsets, ε, and δ) as will be further described below.

<FIG> is a block diagram that schematically illustrates an example of a sensor fusion system <NUM> usable with an AR system <NUM> such as, for example, described with reference to <FIG>, <FIG>, or <FIG>. Embodiments of the sensor fusion system <NUM> address some or all of the challenges described above with reference to <FIG>.

The sensor fusion system <NUM> includes an inertial navigation system (INS) <NUM> configured to receive and fuse sensor data from multiple types of sensors. For example, as shown in <FIG>, the INS <NUM> can receive input data from the totem IMU <NUM>, an EM tracking system <NUM>, and additionally or optionally, other sensors <NUM>. As described herein, the totem IMU <NUM> can include, among other components, an accelerometer and a gyroscope. The other sensors <NUM> can include, among other components, a magnetometer and an optical sensor (e.g., in outward-facing or inward-facing camera).

Embodiments of the EM tracking system <NUM> have been described above with reference to <FIG>. For example, the totem <NUM> can include an EM emitter <NUM> that emits an EM field, and the head-mounted AR headset <NUM> can include an EM sensor <NUM> that measures the emitted EM field and calculates a pose (3DOF or 6DOF) of the EM sensor <NUM> with respect to the EM emitter <NUM>. For example, the 6DOF pose can be calculated from the EM field matrix F described above with reference to Equation (<NUM>).

In other implementations, the EM emitter <NUM> can be disposed in the AR headset <NUM>, and the EM sensor <NUM> can be disposed in the totem <NUM>. See, for example, the description of various arrangements of EM sensors and emitters with reference to <FIG> and <FIG>.

The sensor fusion system <NUM> includes a Kalman filter <NUM> that can estimate the error states for totem pose (e.g., as described with reference to Equations (<NUM>) and (<NUM>)). The Kalman filter <NUM> can utilize models for how the totem IMU <NUM> should be behaving (e.g., without bias, noise, etc.) and compare these models to the actual measurements from the sensors (e.g., totem IMU <NUM>, EM tracking system <NUM>, and (optionally) other sensors <NUM>). The Kalman filter <NUM> uses the differences between model and measurement to provide a better estimate of the totem pose. For example, the Kalman filter <NUM> can predict an estimate of the current state of the totem pose and compare this state to the data from the sensors being fused (e.g., IMU <NUM>, EM tracking system <NUM>, and (optionally) other sensors <NUM>) in order to generate the error states. Knowledge of the error states can be used to update the state of the totem pose (e.g., via Equations (<NUM>) and (<NUM>)). As noted above, use of a Kalman filter <NUM> is not a requirement, and in other embodiments, other statistical filters or stochastic data fusion techniques can be used such as, for example, a Markov model, Bayesian filtering, linear quadratic estimation, and so forth.

The INS <NUM> uses the Kalman filter to fuse the inputs from the totem IMU and the EM tracking system (and optionally any other sensors <NUM>) in order to provide estimates of the totem pose that statistically tend to be more accurate than pose estimates using input just from the totem IMU <NUM> or just from the EM tracking system <NUM>. For example, the Kalman filter <NUM> can correct for the drift of the totem pose (e.g., due to sensor bias, noise, etc.) and adjust for the offset with respect to the world frame of reference of the AR system <NUM>.

Accordingly, the sensor fusion system <NUM> can determine the totem pose (e.g., 3DOF or 6DOF) in the world frame of reference of the AR system <NUM> and provide this totem pose to the AR system <NUM>. The AR system <NUM> can use totem pose in the world frame of reference of the AR system <NUM> to, for example, deliver virtual content to the user of the AR system (see, e.g., <FIG>, <FIG>, <FIG>). The sensor fusion technique provides a more accurate and robust estimate of the totem pose, thereby leading to improved delivery of virtual content to the user and an improved user experience with the AR system <NUM>.

<FIG> and <FIG> provide additional illustrative features of the sensor fusion system <NUM>. As described above with reference to Equation (<NUM>), the EM tracking system <NUM> uses an EM field matrix <NUM> measured by the EM sensors <NUM> to determine totem pose. The measured EM field matrix <NUM> is a 3x3 matrix denoted by F and has nine components. In <FIG>, the measured EM field matrix <NUM> is compared to a predicted EM field matrix <NUM> that represents the system's estimate of what the totem pose is expected to be. The comparison can include a difference <NUM> between the predicted EM field matrix <NUM> and the measured EM field matrix <NUM>. The comparison between the predicted and the measured EM field matrices <NUM>, <NUM> provides an estimate of the error states used by the Kalman filter <NUM>. For example, when the difference between the predicted and the measured EM field matrices <NUM>, <NUM>, is relatively small, there may not be much drift due to sensor bias or noise, and the determination of the totem pose by the INS <NUM> may be relatively accurate. As drift accumulates, the difference between the predicted and the measured EM field matrices <NUM>, <NUM> may increase, and the Kalman filter <NUM> acts to restore the accuracy of the totem pose <NUM>. As shown by a dashed line <NUM> in <FIG>, the current value of the totem pose in the world frame <NUM> can be fed back into the prediction for where the totem <NUM> is expected to be. The Kalman filter <NUM> thus works recursively to provide an improved or optimal determination of the totem pose in the world frame <NUM> by fusing the inputs from the totem IMU <NUM> and the EM tracking system <NUM> (and optionally the other sensors <NUM>).

<FIG> illustrates an example of how the predicted EM field matrix <NUM> can be determined by the sensor fusion system <NUM>. In <FIG>, the EM emitter <NUM> is labeled "TX" (short for transmitter), and the EM sensor <NUM> is labeled "RX" (short for receiver). The block diagram in <FIG> illustrates an example of how measurements made by the EM emitter <NUM> and the EM sensor <NUM> are transformed to the world frame of reference of the AR system <NUM>. In this example, the EM emitter <NUM> is presumed to be located in the totem <NUM> (see, e.g., <FIG>), and the EM sensor <NUM> is presumed to be located in the AR headset <NUM> (see, e.g., <FIG>). This arrangement of the EM emitter <NUM> and the EM sensor <NUM> is not a limitation, and in other embodiments, the processing described with reference to <FIG> could be modified for other arrangements (e.g., EM emitter <NUM> in the AR headset <NUM> and EM sensor <NUM> in the totem <NUM>).

At block <NUM>, the system <NUM> accesses headpose data indicative of the pose of the AR headset <NUM> in the world frame of reference of the AR system <NUM>. As described above with reference to <FIG>, sensors in the AR headset <NUM>, such as an IMU <NUM> or outward-facing world cameras <NUM>, can be used to determine the pose of the headset <NUM>. For example, the cameras <NUM> may be utilized to capture data which may be utilized in simultaneous localization and mapping protocols, or "SLAM", to determine where the AR headset <NUM> is and how it is oriented relative to other components in the system <NUM> or the world. The pose (e.g., position and orientation) of the AR headset <NUM> can be referenced to a fiducial origin <NUM> relative to the AR headset <NUM>. For example, as schematically shown in <FIG>, the fiducial origin <NUM> may be at a point near the center of the headset <NUM>, for example, substantially between a pair of outward-facing world cameras.

As can be seen from <FIG>, the EM sensor <NUM> may not be located at the fiducial origin <NUM> of the AR headset <NUM>, but displaced from the origin by a displacement <NUM> (shown as a double-headed arrow). Thus, measurements made by the EM sensor <NUM> may not represent the pose of the AR headset <NUM> relative to the fiducial origin <NUM>, because of this displacement <NUM>. The displacement of the EM sensor <NUM> relative to the fiducial origin <NUM> can be stored by the sensor fusion system <NUM> at block <NUM> of <FIG>, which is labeled "RX Extrinsics. " To adjust the measurements made by the EM sensor <NUM> to reflect the position of the AR headset <NUM> in the world frame of reference of the AR system <NUM>, at block <NUM> of <FIG>, the RX Extrinsics (e.g., the displacement <NUM>) can be applied to the EM sensor <NUM> measurements. The output of the block <NUM> is the pose (e.g., position and orientation) of the EM sensor <NUM> in the world frame of reference of the AR system <NUM> (labeled as "RX in World Frame" in <FIG>).

Turning to the lower portion of <FIG>, an analogous procedure may be used to determine the pose of the EM emitter <NUM> in the world frame of reference of the AR system <NUM> (labeled as "TX in World Frame" in <FIG>). Similarly to the EM sensor <NUM> being displaced from a fiducial origin of the AR headset <NUM>, the EM emitter <NUM> may be displaced from a fiducial origin <NUM> that represents the position of the totem <NUM> in the world frame of reference of the AR system <NUM>. Returning to the example shown in <FIG>, the totem <NUM> includes a fiducial origin <NUM> that is displaced by a displacement <NUM> from the position of the EM emitter <NUM>. The fiducial origin <NUM> of the totem <NUM> can be selected at any suitable location, for example, at the center-of-mass of the totem <NUM> or at the volumetric center of the totem <NUM>.

The displacement of the EM emitter <NUM> relative to the fiducial origin <NUM> of the totem <NUM> can be stored by the sensor fusion system <NUM> at block <NUM> of <FIG>, which is labeled "TX Extrinsics. " In order to know where the fiducial origin <NUM> of the totem <NUM> is in the world frame of reference of the AR system <NUM>, totem pose data from block <NUM> (see <FIG>) can be used. To adjust the EM emitter <NUM> to reflect the position of the totem <NUM> in the world frame of reference of the AR system <NUM>, the TX Extrinsics (e.g., the displacement <NUM>) and the totem pose of the fiducial origin <NUM> can be applied at block <NUM> of <FIG>. In effect, the totem pose in the world frame <NUM> provides the position and orientation of the fiducial origin <NUM> of the totem <NUM> in the world frame of reference of the AR system <NUM>, and the TX Extrinsics <NUM> adjusts for the fact that the EM emitter <NUM> may be displaced from the fiducial origin <NUM>.

The output of the block <NUM> is thus the pose (e.g., position and orientation) of the EM emitter <NUM> in the world frame of reference of the AR system <NUM> (labeled as "TX in World Frame" in <FIG>). Accordingly, at this point in the procedure, the predicted pose of both the EM sensor <NUM> (RX) and the EM emitter <NUM> (TX) are determined in the same frame of reference, namely, the world frame of reference of the AR system <NUM>.

At block <NUM>, labeled TX → RX Resolver", the relative pose of the EM emitter <NUM> with respect to the EM sensor <NUM> can be determined. The relative pose may include the distance r between the EM emitter <NUM> and the EM sensor <NUM> and the angular orientation (e.g., azimuthal angle and pitch angle) of the EM sensor <NUM> relative to the EM emitter <NUM>.

At block <NUM>, the relative pose of the EM emitter <NUM> and the EM sensor <NUM> can be used to determine the values of the EM field matrix <NUM> that would be predicted to occur for that particular relative pose between the EM emitter <NUM> and the EM sensor <NUM>. For example, the predicted EM field matrix <NUM> can be calculated from Equations (<NUM>) and (<NUM>) since the distance r and the orientation angles (e.g., azimuth and pitch) are determined from the relative pose.

Thus, the output of the block <NUM> in <FIG> provides a prediction for the EM field matrix, which can be compared with the actual, measured EM field matrix <NUM> as described with reference to <FIG>. The difference, if any, between the predicted and measured EM field matrices can be used by the Kalman filter <NUM> to provide error state estimates used by the INS <NUM> to update the totem pose in the world frame <NUM>.

<FIG> illustrates calculation of the predicted EM field matrix <NUM> for an example system where the EM emitter <NUM> is disposed in or on the totem <NUM> and the EM sensor <NUM> is disposed in or on the head-mounted wearable display <NUM>. This is for the purpose of illustration and not limitation. In other implementations, the EM emitter <NUM> may be disposed in or on the head-mounted wearable display <NUM>, and the EM sensor <NUM> may be disposed in or on the totem <NUM>. In such an implementation, the RX extrinsics may include a displacement of the EM sensor <NUM> relative to a fiducial position of the totem <NUM>, and the TX extrinsics may include displacement of the EM emitter <NUM> relative to a fiducial position of the head-mounted display <NUM>.

In some implementations of the sensor fusion system <NUM>, the totem IMU <NUM> operates at about <NUM>. The INS <NUM> integrates the IMU data while applying the error state estimates from the Kalman filter <NUM> to determine the totem pose in the world frame <NUM>. For example, the INS <NUM> may evaluate Equations (<NUM>) and (<NUM>). The EM tracking system <NUM> may operate at a different rate than the IMU <NUM> (e.g., <NUM>). Whenever new data from the EM tracking system <NUM> is obtained, the procedure described with reference to <FIG>/<FIG> can be performed to supply measured and predicted EM field matrices to the Kalman filter <NUM>. This process is iterated as new IMU <NUM> or EM tracking system <NUM> data is obtained in order to provide updated world-frame totem poses to the AR system <NUM> in real time. The use of the sensor fusion system <NUM> advantageously may permit the AR system <NUM> to operate with reduced latency, improved performance (e.g., since the totem pose will be more robust and accurate), and thereby provide an improved user experience.

When the AR system <NUM> is started up (or re-booted), the sensor fusion system <NUM> may be initialized. For example, the initial totem pose may be calculated by the EM tracking system <NUM> from the measured EM field matrix <NUM>. As the sensor integration and filtering proceeds, the estimated totem pose may be improved in accuracy by virtue of the optimization performed by the Kalman filter <NUM>. In some cases, determining the initial totem pose from the measured EM field matrix <NUM> may result in an ambiguity regarding the direction in which the totem <NUM> is pointing (e.g., which hemisphere it is pointing toward). In some implementations, to resolve this ambiguity, two threads for the fusion system <NUM> are started in parallel, with each thread assuming the totem <NUM> is pointing in one of the hemispheres. One of the threads will have the correct hemisphere, and one of the threads will have the incorrect hemisphere. As the sensor fusion system <NUM> runs, the thread that assumed the incorrect hemisphere can readily be determined, because the pose estimated by this thread will start to diverge more and more from the true totem pose. At that point, this thread can be terminated, and the sensor fusion system <NUM> proceeds with just the one thread that assumed the correct hemisphere for the initial totem pose. This technique advantageously identifies the correct hemisphere quickly and is not very computationally demanding in practice.

The totem <NUM> is typically held in the user's hand, and therefore the distance between the totem <NUM> and the AR headset <NUM> typically does not exceed approximately the length of the user's arm. Some embodiments of the sensor fusion system <NUM> implement an error protocol that checks whether the estimated distance between the totem <NUM> and the AR headset <NUM> exceeds a threshold distance (e.g., comparable to a typical human arm length). For example, the TX → RX Resolver block <NUM> can calculate the distance between the EM sensor <NUM> (typically disposed in the AR headset <NUM>) and the EM emitter <NUM> (typically disposed in the totem <NUM>) and if the distance exceeds the threshold distance, the fusion system <NUM> can determine that an error has likely occurred. If an error is detected, the fusion system <NUM> can take corrective actions such as, for example, re-initializing the system.

<FIG> is a flowchart illustrating an example of a method <NUM> for calculating a pose of a handheld user input device / controller / totem <NUM> for a wearable system <NUM>. The method <NUM> may be performed by the INS <NUM> described with reference to <FIG>.

At block <NUM>, the method <NUM> accesses pose data from a pose sensor associated with the handheld user input device <NUM>. The pose sensor may include an IMU, an accelerometer, a gyroscope, a magnetometer, an optical sensor, or a combination thereof. At block <NUM>, the method <NUM> accesses EM tracking data associated with an EM tracking system <NUM> associated with the handheld user input device <NUM>. The EM tracking data may include the EM field matrix, F, described with reference to Equation (<NUM>).

At block <NUM>, the method <NUM> applies a data fusion technique to combine the pose data and the EM tracking data. The data fusion technique may include a Kalman filter (or any variety of Kalman filter such as, e.g., an extended or unscented Kalman filter), a Markov model, a Bayesian estimator, linear quadratic estimation, a neural network, a machine learning algorithm, etc. The data fusion technique may calculate error states to correct for bias, noise, nonlinearity, errors, etc. of the pose data output from the pose sensor.

At block <NUM>, the method <NUM> determines a pose of the handheld user input device <NUM> in a world reference frame associated with an environment of the AR system <NUM>. An example of a world reference frame is the world coordinate system <NUM> described with reference to <FIG>. The pose can be a 6DOF pose or a 3DOF pose.

At block <NUM>, the pose may be used to present virtual content to the user of the wearable system <NUM> or to provide convenient user interaction with the handheld user input device. For example, as described with reference to <FIG> and <FIG>, the combination of the head mounted display <NUM> assisting in determining pose relative to the world coordinate system, and the handheld user input device <NUM> assisting in determining relative location and orientation of the handheld user input device <NUM> relative to the head mounted display <NUM>, can allow the system <NUM> to generally determine where each component is relative to the world reference frame, and thus the user's head pose, and handheld pose may be tracked, preferably at relatively low latency, for presentation of augmented reality image features and interaction using movements and rotations of the handheld component. Thus, embodiments of the method <NUM> can provide low latency performance and an improved user experience for users of the wearable device <NUM>.

Although certain embodiments of the sensor fusion technology are described in the context of real-time pose determination for components of a wearable display system (e.g., IMU and EM sensors for tracking head pose or body pose in an AR or VR context), this is for illustration and not limitation. Embodiments of the sensor fusion technology can be used in other applications and with other devices and in general can be applied to any pose determination system. For example, the sensor fusion technology can be used in a medical or surgical environment and thereby provide an improved position or orientation of medical instruments used during a medical or surgical procedure.

Each of the processes, methods, and algorithms described herein and/or depicted in the attached figures may be embodied in, and fully or partially automated by, code modules executed by one or more physical computing systems, hardware computer processors, application-specific circuitry, and/or electronic hardware configured to execute specific and particular computer instructions. For example, computing systems can include general purpose computers (e.g., servers) programmed with specific computer instructions or special purpose computers, special purpose circuitry, and so forth. A code module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language. In some implementations, particular operations and methods may be performed by circuitry that is specific to a given function.

Further, certain implementations of the functionality of the present disclosure are sufficiently, mathematically, computationally, or technically complex that application-specific hardware or one or more physical computing devices (utilizing appropriate specialized executable instructions) may be necessary to perform the functionality, for example, due to the volume or complexity of the calculations involved or to provide results substantially in real-time. For example, a video may include many frames, with each frame having millions of pixels, and specifically programmed computer hardware is necessary to process the video data to provide a desired image processing task or application in a commercially reasonable amount of time. Further, pose estimation using EM tracking typically needs to be done in real time in an AR or VR environment, and hardware processing is required to perform the pose estimation task to provide an enjoyable user experience.

Code modules or any type of data may be stored on any type of non-transitory computer-readable medium, such as physical computer storage including hard drives, solid state memory, random access memory (RAM), read only memory (ROM), optical disc, volatile or non-volatile storage, combinations of the same and/or the like. The methods and modules (or data) may also be transmitted as generated data signals (e.g., as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums, and may take a variety of forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). The results of the disclosed processes or process steps may be stored, persistently or otherwise, in any type of non-transitory, tangible computer storage or may be communicated via a computer-readable transmission medium.

Any processes, blocks, states, steps, or functionalities in flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing code modules, segments, or portions of code which include one or more executable instructions for implementing specific functions (e.g., logical or arithmetical) or steps in the process. The various processes, blocks, states, steps, or functionalities can be combined, rearranged, added to, deleted from, modified, or otherwise changed from the illustrative examples provided herein. In some embodiments, additional or different computing systems or code modules may perform some or all of the functionalities described herein. The methods and processes described herein are also not limited to any particular sequence, and the blocks, steps, or states relating thereto can be performed in other sequences that are appropriate, for example, in serial, in parallel, or in some other manner. Tasks or events may be added to or removed from the disclosed example embodiments. Moreover, the separation of various system components in the implementations described herein is for illustrative purposes and should not be understood as requiring such separation in all implementations. It should be understood that the described program components, methods, and systems can generally be integrated together in a single computer product or packaged into multiple computer products. Many implementation variations are possible.

The processes, methods, and systems may be implemented in a network (or distributed) computing environment. Network environments include enterprise-wide computer networks, intranets, local area networks (LAN), wide area networks (WAN), personal area networks (PAN), cloud computing networks, crowd-sourced computing networks, the Internet, and the World Wide Web. The network may be a wired or a wireless network or any other type of communication network.

The invention includes methods that may be performed using the subject devices. The methods may include the act of providing such a suitable device. Such provision may be performed by the end user. In other words, the "providing" act merely requires the end user obtain, access, approach, position, set-up, activate, power-up or otherwise act to provide the requisite device in the subject method. Methods recited herein may be carried out in any order of the recited events which is logically possible, as well as in the recited order of events.

The systems and methods of the disclosure each have several innovative aspects, no single one of which is solely responsible or required for the desirable attributes disclosed herein. The various features and processes described above may be used independently of one another, or may be combined in various ways. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. Various modifications to the implementations described in this disclosure may be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other implementations without departing from the scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein, but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

Certain features that are described in this specification in the context of separate implementations also can be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also can be implemented in multiple implementations separately or in any suitable subcombination. No single feature or group of features is necessary or indispensable to each and every embodiment.

Conditional language used herein, such as, among others, "can," "could," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment. In addition, the articles "a," "an," and "the" as used in this application and the appended claims are to be construed to mean "one or more" or "at least one" unless specified otherwise. Except as specifically defined herein, all technical and scientific terms used herein are to be given as broad a commonly understood meaning as possible while maintaining claim validity.

As an example, "at least one of: A, B, or C" is intended to cover: A, B, C, A and B, A and C, B and C, and A, B, and C. Conjunctive language such as the phrase "at least one of X, Y and Z," unless specifically stated otherwise, is otherwise understood with the context as used in general to convey that an item, term, etc. may be at least one of X, Y or Z. Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y and at least one of Z to each be present.

Claim 1:
A wearable system (<NUM>) comprising:
a head-mounted display (<NUM>);
a handheld user input device (<NUM>) comprising an inertial measurement unit IMU (<NUM>);
an electromagnetic EM tracking system (<NUM>) comprising:
an EM emitter (<NUM>, <NUM>) disposed in or on the handheld user input device, the EM emitter configured to generate an EM field; and
an EM sensor (<NUM>, <NUM>) disposed in or on the head-mounted display, the EM sensor configured to sense the EM field,
wherein the EM tracking system is configured to output an EM field matrix associated with an estimated pose of the EM sensor relative to the EM emitter; and
a hardware processor programmed to iteratively, in real time during operation of the handheld user input device:
access IMU data from the IMU, the IMU data representative of an estimated pose of the handheld user input device in a reference frame associated with the handheld user input device;
access the EM field matrix from the EM tracking system;
calculate a predicted EM field matrix representative of a predicted pose of the handheld user input device in a world reference frame associated with an environment of the wearable system;
generate an error state based at least partly on the EM field matrix and the predicted EM field matrix, the error state representing at least one of: bias or noise in the IMU, or an offset between the reference frame of the handheld user input device and the world reference frame;
apply a Kalman filter to the IMU data based on the error state; and
determine, using the Kalman filter, a pose of the handheld user input device in the world reference frame.