LASER SCANNER WITH REAL-TIME, ONLINE EGO-MOTION ESTIMATION

BACKGROUND

An autonomous moving device may require information regarding the terrain in which it operates. Such a device may either rely on a pre-defined map presenting the terrain and any obstacle that may be found therein. Alternatively, the device may have the capabilities to map its terrain while either stationary or in motion comprising a computer-based mapping system with one or more sensors to provide real-time data. The mobile, computer-based mapping system may estimate changes in its position over time (an odometer) and/or generate a three-dimensional map representation, such as a point cloud, of a three-dimensional space.

Exemplary mapping systems may include a variety of sensors to provide data from which the map may be built. Some mapping systems may use a stereo camera system as one such sensor. These systems benefit from the baseline between the two cameras as a reference to determine scale of the motion estimation. A binocular system is preferred over a monocular system, as a monocular system may not be able to resolve the scale of the image without receiving data from additional sensors or making assumptions about the motion of the device. In recent years, RGB-D cameras have gained popularity in the research community. Such cameras may provide depth information associated with individual pixels and hence can help determine scale. However, some methods including the RGB-D camera may only use the image areas with coverage of depth information, which may result in large image areas being wasted especially in an open environment where depth can only be sparsely available.

In other examples of mapping systems, an IMU may be coupled one or more cameras with, so that scale constraints may be provided from IMU accelerations. In some examples, a monocular camera may be tightly or loosely coupled to an IMU by means of a Kalman filter. Other mapping systems may use optimization methods to solve for the motion of the mobile system.

Alternative examples of mapping systems may include the use of laser scanners for motion estimation. However, a difficulty of the use of such data may arise from the scanning rate of the laser. While the system is moving, laser points unlike a fixed position laser scanner are impacted by the relative movement of the scanner. Therefore the impact of this movement may be a factor of the laser points arriving arrive at the system at different times. Consequently, when the scanning rate is slow with respect to the motion of the mapping system, scan distortions may be present due to external motion of the laser. The motion effect can be compensated by a laser itself but the compensation may require an independent motion model to provide the required corrections. As one example, the motion may be modeled as a constant velocity or as a Gaussian process. In some example, an IMU may provide the motion model. Such a method matches spatio-temporal patches formed by laser point clouds to estimate sensor motion and correct IMU biases in off-line batch optimization.

Similar problems of motion distortion may be found in the use of rolling-shutter cameras. Specifically, image pixels may be received continuously over time, resulting in image distortion caused by extrinsic motion of the camera. In some examples, visual odometry methods may use an IMU to compensate for the rolling-shutter effect given the read-out time of the pixels.

In some examples, GPS/INS techniques may be used to determine the position of a mobile mapping device. However, high-accuracy GPS/INS solutions may be impractical when the application is GPS-denied, light-weight, or cost-sensitive. It is recognized that accurate GPS mapping requires line-of-sight communication between the GPS receiver and at least four GPS satellites (although five may be preferred). In some environments, it may be difficult to receive undistorted signals from four satellites, for example in urban environments that may include overpasses and other obstructions.

It may thus be appreciated that there are several technical challenges associated with merging data from optical devices with other motion measuring devices in order to generate a robust map of the terrain surrounding an autonomous mapping device, especially while the mapping device is in motion. Disclosed below are methods and systems of a mapping device capable of acquiring optical mapping information and producing robust maps with reduced distortion.

SUMMARY

The examples in this section are merely representative of some possible embodiments, but do not reflect all possible embodiments, combination of elements, or inventions disclosed in this application. In an example, a mapping system may include an inertial measurement unit, a camera unit, a laser scanning unit, and a computing system in communication with the inertial measurement unit, the camera unit, and the laser scanning unit. The computing system may be composed of at least one processor, at least one primary memory unit, and at least one secondary memory unit. The primary memory unit may store software that is executed by the at least one processor, in which the software may include: a first computational module that, when executed by the at least one processor, causes the at least one processor to compute first measurement predictions based on inertial measurement data from the inertial measurement unit at a first frequency; a second computational module that, when executed by the at least one processor, causes the at least one processor to compute second measurement predictions based on the first measurement predictions and visual measurement data from the camera unit at a second frequency; and a third computational module that, when executed by the at least one processor, causes the at least one processor to compute third measurement predictions based on the second measurement predictions and laser ranging data from the laser scanning unit at a third frequency.

In an example of the mapping system, the first computational module may further include software that, when executed by the at least one processor, causes the at least one processor to correct bias error in the first measurement predictions based on the second measurement predictions and the third measurement predictions.

In an example of the mapping system, the first frequency is greater than the second frequency and the second frequency is greater than the third frequency.

In an example of the mapping system, the second computational module may further include software that, when executed by the at least one processor, causes the at least one processor to determine whether the visual measurement data are degraded during a first measurement time period, and upon a determination that the visual measurement data are degraded during the first measurement time period, compute the second measurement predictions during the first measurement time period equal to first measurement predictions during the first measurement time period.

In an example of the mapping system, the third computational module may further include software that, when executed by the at least one processor, causes the at least one processor to determine whether the laser ranging data are degraded during a second measurement time period, and upon a determination that the laser ranging data are degraded during the second measurement time period, compute the third measurement predictions during the second measurement time period equal to second measurement predictions during the second measurement time period.

In an example of the mapping system, the primary memory device may store first and second sets of voxels in which the first and second sets of voxels are based on the third prediction measurements. Each voxel of the first set of voxels may correspond to a first volume of space and each voxel of the second set of voxels may correspond to a second volume of space. The second volume of space may be smaller than the first volume of space and each voxel of the first set of voxels may be mappable to a plurality of voxels of the second set of voxels.

In an example of the mapping system, the secondary memory unit may store point cloud data generated from the third prediction measurements.

In an example, the mapping system may further include a mobile unit, in which the inertial measurement unit is on the mobile unit, the camera unit is on the mobile unit, the laser scanning unit is on the mobile unit, and the computing system is on the mobile unit.

In an example of the mapping system, the mobile unit may include a navigation system for guiding the mobile unit and the navigation system may use the third measurement predictions to guide the autonomous mobile unit.

In an example of the mapping system, the third computation module may use a scan matching algorithm to compute the third measurement predictions. The at least one processor may comprise multiple processing threads. The primary memory device may store software that, when executed by the at least one processor, may manage the processing of scans of the laser ranging data by the multiple threads such that a first thread is assigned to scan match a first scan of the laser ranging data. The first thread may be assigned to scan match a second scan of the laser ranging data from a point in time after the first scan, when the first thread can process the first scan before arrival of the second scan. A second thread may be assigned to scan match the second scan of the laser ranging data when the first thread cannot process the first scan before arrival of the second scan.

In an example of the mapping system, the inertial measurement unit, camera unit and laser scanning unit may interface via the computing system with an interactive display on which a down-sampled version of the scanning data is presented in a three-dimensional representation.

In accordance with an exemplary and non-limiting embodiment, a mapping system, comprises an inertial measurement unit, a camera unit, a laser scanning unit, and a computing system in communication with the inertial measurement unit, the camera unit, and the laser scanning unit, wherein the computing system comprises at least one processor, at least one primary memory unit, and at least one secondary memory unit, wherein the primary memory unit stores software that is executed by the at least one processor, wherein the software comprises a first computational module that, when executed by the at least one processor, causes the at least one processor to compute at least one first measurement prediction based, at least on part, on inertial measurement data from the inertial measurement unit at a first frequency, a second computational module that, when executed by the at least one processor, causes the at least one processor to compute at least one second measurement prediction based, at least on part, on the at least one first measurement prediction and visual measurement data from the camera unit at a second frequency and a third computational module that, when executed by the at least one processor, causes the at least one processor to compute at least one third measurement prediction based on the at least one second measurement prediction and laser ranging data from the laser scanning unit at a third frequency.

In accordance with an exemplary and non-limiting embodiment, the mapping system is comprised of a modularized system structure to address the problem of bidirectional information flow. Specifically, three modules address the problem step by step from coarse to fine data. Data processing flow may proceed from an IMU prediction module to a visual-inertial odometry module to a scan matching refinement module, while feedback flow occurs in a reverse order to correct the biases of the IMU.

In accordance with an exemplary and non-limiting embodiment, the mapping system is dynamically reconfigurable. For example, if visual features are insufficient for the visual-inertial odometry, the IMU prediction module (partially) bypasses the visual-inertial odometry module to register laser points locally. If, on the other hand, environmental structures are insufficient for the scan matching, the visual-inertial odometry output (partially) bypasses the scan matching refinement module to register laser points on the map.

In accordance with an exemplary and non-limiting embodiment, the mapping system employs priority feedback for IMU bias correction. For example, both the visual-inertial odometry module and the scan matching refinement module provide may feedback to the IMU prediction module to correct the IMU biases. The feedback may be combined giving priority to the visual-inertial odometry module. In other words, feedback from the scan matching refinement module compensates for the visual-inertial odometry module in directions where the visual-inertial odometry module is degraded.

In accordance with an exemplary and non-limiting embodiment, the mapping system employs a two-layer voxel representation of the map. The first layer is composed of large voxels. This layer is for map storage. For each large voxel that is close to the sensor, the voxel contains a second layer of small voxels for precisely retrieving the map for scan matching.

In accordance with an exemplary and non-limiting embodiment, the mapping system employs multi-thread processing of scan matching. The scan matching may utilize KD-tree building, point querying, matrix inverse for nonlinear optimization, and the like. Standard parallel processing such as openMP can only accelerate point querying and does not serve to substantially reduce overall time. In contrast, the present system processes a different scan on each thread. In other words, the four threads process four consecutive scans instead of one scan.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a block diagram of an embodiment of a mapping system.

FIG. 2 illustrates an embodiment a block diagram of the three computational modules and their respective feedback features of the mapping system of FIG. 1.

FIG. 3 illustrates an embodiment of a Kalmann filter model for refining positional information into a map.

FIG. 4 illustrates an embodiment of a factor graph optimization model for refining positional information into a map.

FIG. 5 illustrates an embodiment of a visual-inertial odometry subsystem.

FIG. 6 illustrates an embodiment of a scan matching subsystem.

FIG. 7A illustrates an embodiment of a large area map having coarse detail resolution.

FIG. 7B illustrates an embodiment of a small area map having fine detail resolution.

FIG. 8A illustrates an embodiment of multi-thread scan matching.

FIG. 8B illustrates an embodiment of single-thread scan matching.

FIG. 9A illustrates an embodiment of a block diagram of the three computational modules in which feedback data from the visual-inertial odometry unit is suppressed due to data degradation.

FIG. 9B illustrates an embodiment of the three computational modules in which feedback data from the scan matching unit is suppressed due to data degradation.

FIG. 10 illustrates an embodiment of the three computational modules in which feedback data from the visual-inertial odometry unit and the scan matching unit are partially suppressed due to data degradation.

FIG. 11 illustrates an embodiment of estimated trajectories of a mobile mapping device.

FIG. 12 illustrates bidirectional information flow according to an exemplary and non-limiting embodiment.

FIGS. 13a and 13b illustrate a dynamically reconfigurable system according to an exemplary and non-limiting embodiment.

FIG. 14 illustrates priority feedback for IMU bias correction according to an exemplary and non-limiting embodiment.

FIGS. 15a and 15b illustrate a two-layer voxel representation of a map according to an exemplary and non-limiting embodiment.

FIGS. 16a and 16b illustrate multi-thread processing of scan matching according to an exemplary and non-limiting embodiment.

DETAILED DESCRIPTION

In one general aspect, the present invention is directed to a mobile, computer-based mapping system that estimates changes in position over time (an odometer) and/or generates a three-dimensional map representation, such as a point cloud, of a three-dimensional space. The mapping system may include, without limitation, a plurality of sensors including an inertial measurement unit (IMU), a camera, and/or a 3D laser scanner. It also may comprise a computer system, having at least one processor, in communication with the plurality of sensors, configured to process the outputs from the sensors in order to estimate the change in position of the system over time and/or generate the map representation of the surrounding environment. The mapping system may enable high-frequency, low-latency, on-line, real-time ego-motion estimation, along with dense, accurate 3D map registration. Embodiments of the present disclosure may include a simultaneous location and mapping (SLAM) system. The SLAM system may include a multi-dimensional (e.g., 3D) laser scanning and range measuring system that is GPS-independent and that provides real-time simultaneous location and mapping. The SLAM system may generate and manage data for a very accurate point cloud that results from reflections of laser scanning from objects in an environment. Movements of any of the points in the point cloud are accurately tracked over time, so that the SLAM system can maintain precise understanding of its location and orientation as it travels through an environment, using the points in the point cloud as reference points for the location.

In one embodiment, the resolution of the position and motion of the mobile mapping system may be sequentially refined in a series of coarse-to-fine updates. In a non-limiting example, discrete computational modules may be used to update the position and motion of the mobile mapping system from a coarse resolution having a rapid update rate, to a fine resolution having a slower update rate. For example, an IMU device may provide data to a first computational module to predict a motion or position of the mapping system at a high update rate. A visual-inertial odometry system may provide data to a second computational module to improve the motion or position resolution of the mapping system at a lower update rate. Additionally, a laser scanner may provide data to a third computational, scan matching module to further refine the motion estimates and register maps at a still lower update rate. In one non-limiting example, data from a computational module configured to process fine positional and/or motion resolution data may be fed back to computational modules configured to process more coarse positional and/or motion resolution data. In another non-limiting example, the computational modules may incorporate fault tolerance to address issues of sensor degradation by automatically bypassing computational modules associated with sensors sourcing faulty, erroneous, incomplete, or non-existent data. Thus, the mapping system may operate in the presence of highly dynamic motion as well as in dark, texture-less, and structure-less environments.

In contrast to existing map-generating techniques, which are mostly off-line batch systems, the mapping system disclosed herein can operate in real-time and generate maps while in motion. This capability offers two practical advantages. First, users are not limited to scanners that are fixed on a tripod or other nonstationary mounting. Instead, the mapping system disclosed herein may be associated with a mobile device, thereby increasing the range of the environment that may be mapped in real-time. Second, the real-time feature can give users feedback for currently mapped areas while data are collected. The online generated maps can also assist robots or other devices for autonomous navigation and obstacle avoidance. In some non-limiting embodiments, such navigation capabilities may be incorporated into the mapping system itself. In alternative non-limiting embodiments, the map data may be provided to additional robots having navigation capabilities that may require an externally sourced map.

There are several potential applications for the sensor, such as 3D modeling, scene mapping, and environment reasoning. The mapping system can provide point cloud maps for other algorithms that take point clouds as input for further processing. Further, the mapping system can work both indoors and outdoors. Such embodiments do not require external lighting and can operate in darkness. Embodiments that have a camera can handle rapid motion, and can colorize laser point clouds with images from the camera, although external lighting may be required. The SLAM system can build and maintain a point cloud in real time as a user is moving through an environment, such as when walking, biking, driving, flying, and combinations thereof. A map is constructed in real time as the mapper progresses through an environment. The SLAM system can track thousands of features as points. As the mapper moves, the points are tracked to allow estimation of motion. Thus, the SLAM system operates in real time and without dependence on external location technologies, such as GPS. In embodiments, a plurality (in most cases, a very large number) of features of an environment, such as objects, are used as points for triangulation, and the system performs and updates many location and orientation calculations in real time to maintain an accurate, current estimate of position and orientation as the SLAM system moves through an environment. In embodiments, relative motion of features within the environment can be used to differentiate fixed features (such as walls, doors, windows, furniture, fixtures and the like) from moving features (such as people, vehicles, and other moving items), so that the fixed features can be used for position and orientation calculations. Underwater SLAM systems may use blue-green lasers to reduce attenuation.

The mapping system design follows an observation: drift in egomotion estimation has a lower frequency than a module's own frequency. The three computational modules are therefore arranged in decreasing order of frequency. High-frequency modules are specialized to handle aggressive motion, while low-frequency modules cancel drift for the previous modules. The sequential processing also favors computation: modules in the front take less computation and execute at high frequencies, giving sufficient time to modules in the back for thorough processing. The mapping system is therefore able to achieve a high level of accuracy while running online in real-time.

Further, the system may be configured to handle sensor degradation. If the camera is non-functional (for example, due to darkness, dramatic lighting changes, or texture-less environments) or if the laser is non-functional (for example due to structure-less environments) the corresponding module may be bypassed and the rest of the system may be staggered to function reliably. The system was tested through a large number of experiments and results show that it can produce high accuracy over several kilometers of navigation and robustness with respect to environmental degradation and aggressive motion.

The modularized mapping system, disclosed below, is configured to process data from range, vision, and inertial sensors for motion estimation and mapping by using a multi-layer optimization structure. The modularized mapping system may achieve high accuracy, robustness, and low drift by incorporating features which may include:

an ability to dynamically reconfigure the computational modules;

an ability to fully or partially bypass failure modes in the computational modules, and combine the data from the remaining modules in a manner to handle sensor and/or sensor data degradation, thereby addressing environmentally induced data degradation and the aggressive motion of the mobile mapping system; and

an ability to integrate the computational module cooperatively to provide real-time performance.

Disclosed herein is a mapping system for online ego-motion estimation with data from a 3D laser, a camera, and an IMU. The estimated motion further registers laser points to build a map of the traversed environment. In many real-world applications, ego-motion estimation and mapping must be conducted in real-time. In an autonomous navigation system, the map may be crucial for motion planning and obstacle avoidance, while the motion estimation is important for vehicle control and maneuver.

FIG. 1 depicts a simplified block diagram of a mapping system 100 according to one embodiment of the present invention. Although specific components are disclosed below, such components are presented solely as examples and are not limiting with respect to other, equivalent, or similar components. The illustrated system includes an IMU system 102 such as an Xsens® MTi-30 IMU, a camera system 104 such as an IDS® UI-1220SE monochrome camera, and a laser scanner 106 such as a Velodyne PUCK™ VLP-16 laser scanner. The IMU 102 may provide inertial motion data derived from one or more of an x-y-z accelerometer, a roll-pitch-yaw gyroscope, and a magnetometer, and provide inertial data at a first frequency. In some non-limiting examples, the first frequency may be about 200 Hz. The camera system 104 may have a resolution of about 752×480 pixels, a 76° horizontal field of view (FOV), and a frame capture rate at a second frequency. In some non-limiting examples, the frame capture rate may operate at a second frequency of about 50 Hz. The laser scanner 106 may have a 360° horizontal FOV, a 30° vertical FOV, and receive 0.3 million points/second at a third frequency representing the laser spinning rate. In some non-limiting examples, the third frequency may be about 5 Hz. As depicted in FIG. 1, the laser scanner 106 may be connected to a motor 108 incorporating an encoder 109 to measure a motor rotation angle. In one non-limiting example, the laser motor encoder 109 may operate with a resolution of about 0.25°.

The IMU 102, camera 104, laser scanner 106, and laser scanner motor encoder 109 may be in data communication with a computer system 110, which may be any computing device, having one or more processors 134 and associated memory 120, 160, having sufficient processing power and memory for performing the desired odometry and/or mapping. For example, a laptop computer with 2.6 GHz i7quad-core processor (2 threads on each core and 8 threads overall) and an integrated GPU memory could be used. In addition, the computer system may have one or more types of primary or dynamic memory 120 such as RAM, and one or more types of secondary or storage memory 160 such as a hard disk or a flash ROM. Although specific computational modules (IMU module 122, visual-inertial odometry module 126, and laser scanning module 132) are disclosed above, it should be recognized that such modules are merely exemplary modules having the functions as described above, and are not limiting. Similarly, the type of computing device 110 disclosed above is merely an example of a type of computing device that may be used with such sensors and for the purposes as disclosed herein, and is in no way limiting.

As illustrated in FIG. 1, the mapping system 100 incorporates a computational model comprising individual computational modules that sequentially recover motion in a coarse-to-fine manner (see also FIG. 2). Starting with motion prediction from an IMU 102 (IMU prediction module 122), a visual-inertial tightly coupled method (visual-inertial odometry module 126) estimates motion and registers laser points locally. Then, a scan matching method (scan matching refinement module 132) further refines the estimated motion. The scan matching refinement module 132 also registers point cloud data 165 to build a map (voxel map 134). The map also may be used by the mapping system as part of an optional navigation system 136. It may be recognized that the navigation system 136 may be included as a computational module within the onboard computer system, the primary memory, or may comprise a separate system entirely.

It may be recognized that each computational module may process data from one of each of the sensor systems. Thus, the IMU prediction module 122 produces a coarse map from data derived from the IMU system 102, the visual-inertial odometry module 126 processes the more refined data from the camera system 104, and the scan matching refinement module 132 processes the most fine-grained resolution data from the laser scanner 106 and the motor encoder 109. In addition, each of the finer-grained resolution modules further process data presented from a coarser-grained module. The visual-inertial odometry module 126 refines mapping data received from and calculated by the IMU prediction module 122. Similarly, the scan matching refinement module 132, further processes data presented by the visual inertial odometry module 126. As disclosed above, each of the sensor systems acquires data at a different rate. In one non-limiting example, the IMU 102 may update its data acquisition at a rate of about 200 Hz, the camera 104 may update its data acquisition at a rate of about 50 Hz, and the laser scanner 106 may update its data acquisition at a rate of about 5 Hz. These rates are non-limiting and may, for example, reflect the data acquisition rates of the respective sensors. It may be recognized that coarse-grained data may be acquired at a faster rate than more fine-grained data, and the coarse-grained data may also be processed at a faster rate than the fine-grained data. Although specific frequency values for the data acquisition and processing by the various computation modules are disclosed above, neither the absolute frequencies nor their relative frequencies are limiting.

The mapping and/or navigational data may also be considered to comprise coarse level data and fine level data. Thus, in the primary memory (dynamic memory 120), coarse positional data may be stored in a voxel map 134 that may be accessible by any of the computational modules 122, 126, 132. File detailed mapping data, as point cloud data 165 that may be produced by the scan matching refinement module 132, may be stored via the processor 150 in a secondary memory 160, such as a hard drive, flash drive, or other more permanent memory.

Not only are coarse-grained data used by the computational modules for more fine-grained computations, but both the visual-inertial odometry module 126 and the scan matching refinement module 132 (fine-grade positional information and mapping) can feed back their more refined mapping data to the IMU prediction module 122 via respective feedback paths 128 and 138 as a basis for updating the IMU position prediction. In this manner, coarse positional and mapping data may be sequentially refined in resolution, and the refined resolution data serve as feed-back references for the more coarse resolution computations.

FIG. 2 depicts a block diagram of the three computational modules along with their respective data paths. The IMU prediction module 122 may receive IMU positional data 223 from the IMU (102, FIG. 1). The visual-inertial odometry module 126 may receive the model data from the IMU prediction module 122 as well as visual data from one or more individually tracked visual features 227a, 227b from the camera (104, FIG. 1). The laser scanner (106, FIG. 1) may produce data related to laser determined landmarks 233a, 233b, which may be supplied to the scan matching refinement module 132 in addition to the positional data supplied by the visual-inertial odometry module 126. The positional estimation model from the visual-inertial odometry module 126 may be fed back 128 to refine the positional model calculated by the IMU prediction module 122. Similarly, the refined map data from the scan matching refinement module 132 may be fed back 138 to provide additional correction to the positional model calculated by the IMU prediction module 122.

As depicted in FIG. 2, and as disclosed above, the modularized mapping system may sequentially recover and refine motion related data in a coarse-to-fine manner Additionally, the data processing of each module may be determined by the data acquisition and processing rate of each of the devices sourcing the data to the modules. Starting with motion prediction from an IMU, a visual-inertial tightly coupled method estimates motion and registers laser points locally. Then, a scan matching method further refines the estimated motion. The scan matching refinement module may also register point clouds to build a map. As a result, the mapping system is time optimized to process each refinement phase as data become available.

FIG. 3 illustrates a standard Kalman filter model based on data derived from the same sensor types as depicted in FIG. 1. As illustrated in FIG. 3, the Kalman filter model updates positional and/or mapping data upon receipt of any data from any of the sensors regardless of the resolution capabilities of the data. Thus, for example, the positional information may be updated using the visual-inertial odometry data at any time such data become available regardless of the state of the positional information estimate based on the IMU data. The Kalman filter model therefore does not take advantage of the relative resolution of each type of measurement. FIG. 3 depicts a block diagram of a standard Kalman filter based method for optimizing positional data. The Kalman filter updates a positional model 322a-322n sequentially as data are presented. Thus, starting with an initial positional prediction model 322a, the Kalman filter may predict 324a the subsequent positional model 322b. which may be refined based on the receive IMU mechanization data 323. The positional prediction model may be updated 322b in response to the IMU mechanization data 323. in a prediction step 324a followed by update steps seeded with individual visual features or laser landmarks.

FIG. 4 depicts positional optimization based on a factor-graph method. In this method, a pose of a mobile mapping system at a first time 410 may be updated upon receipt of data to a pose at a second time 420. A factor-graph optimization model combines constraints from all sensors during each refinement calculation. Thus, IMU data 323, feature data 327a, 327b, and similar from the camera, and laser landmark data 333a, 333b, and similar, are all used for each update step. It may be appreciated that such a method increases the computational complexity for each positional refinement step due to the large amount of data required. Further, since the sensors may provide data at independent rates that may differ by orders of magnitude, the entire refinement step is time bound to the data acquisition time for the slowest sensor. As a result, such a model may not be suitable for fast real-time mapping. The modularized system depicted in FIGS. 1 and 2 sequentially recovers motion in a coarse-to-fine manner. In this manner, the degree of motion refinement is determined by the availability of each type of data.

Assumptions, Coordinates, and Problem
Assumptions and Coordinate Systems

As depicted above in FIG. 1, a sensor system of a mobile mapping system may include a laser 106, a camera 104, and an IMU 102. The camera may be modeled as a pinhole camera model for which the intrinsic parameters are known. The extrinsic parameters among all of the three sensors may be calibrated. The relative pose between the camera and the laser and the relative pose between the laser and the IMU may be determined according to methods known in the art. A single coordinate system may be used for the camera and the laser. In one non-limiting example, the camera coordinate system may be used, and all laser points may be projected into the camera coordinate system in pre-processing. In one non-limiting example, the IMU coordinate system may be parallel to the camera coordinate system and thus the IMU measurements may be rotationally corrected upon acquisition. The coordinate systems may be defined as follows:

the camera coordinate system {C} may originate at the camera optical center, in which the x-axis points to the left, the y-axis points upward, and the z-axis points forward coinciding with the camera principal axis;

the IMU coordinate system {I} may originate at the IMU measurement center, in which the x-, y-, and z-axes are parallel to {C} and pointing in the same directions; and

the world coordinate system {W} may be the coordinate system coinciding with {C} at the starting pose.

MAP Estimation Problem

A state estimation problem can be formulated as a maximum a posterior (MAP) estimation problem. We may define χ={x_i}, iϵ{1; 2; . . . , m}, as the set of system states U={u_i}, iϵ{1; 2; . . . , m}, as the set of control inputs, and Z={z_k}, kϵ{1; 2; . . . , n}, as the set of landmark measurements. Given the proposed system, Z may be composed of both visual features and laser landmarks. The joint probability of the system is defined as follows,

$\begin{matrix} P (χ | U, Z) \propto P (x_{0}) \prod_{i = 1}^{m} P (x_{i} | x_{i - 1}, u_{i}) \prod_{k = 1}^{n} P (z_{k} | x_{i_{k}}), & Eq . 1 \end{matrix}$

where P(x₀) is a prior of the first system state, P (x_i|x_i-1,u₁) represents the motion model, and P(z_k|x_ik) represents the landmark measurement model. For each problem formulated as (1), there is a corresponding Bayesian belief network representation of the problem. The MAP estimation is to maximize Eq. 1. Under the assumption of zero-mean Gaussian noise, the problem is equivalent to a least-square problem,

$\begin{matrix} χ^{*} = \arg \min_{χ} \sum_{i = 1}^{m} { r_{x_{i}} }^{2} + \sum_{k = 1}^{n} { r_{z_{k}} }^{2} . & Eq . 2 \end{matrix}$

Here, r_xiand r_zkare residual errors associated with the motion model and the landmark measurement model, respectively.

The standard way of solving Eq. 2 is to combine all sensor data, for example visual features, laser landmarks, and IMU measurements, into a large factor-graph optimization problem. The proposed data processing pipeline, instead, formulates multiple small optimization problems and solves the problems in a coarse-to-fine manner. The optimization problem may be restated as:

Problem: Given data from a laser, a camera, and an IMU, formulate and solve problems as (2) to determine poses of {C} with respect to {W}, then use the estimated poses to register laser points and build a map of the traversed environment in {W}.

IMU Prediction Subsystem
IMU Mechanization

This subsection describes the IMU prediction subsystem. Since the system considers {C} as the fundamental sensor coordinate system, the IMU may also be characterized with respect to {C}. As disclosed above in the sub-section entitled Assumptions and Coordinate Systems, {I} and {C} are parallel coordinate systems. ω(t) and a(t) may be two 3×1 vectors indicating the angular rates and accelerations, respectively, of {C} at time t. The corresponding biases may be denoted as b_ω(t) and b_a(t) and n_ω(t) and n_a(t) be the corresponding noises. The vector, bias, and noise terms are defined in {C}. Additionally, g may be denoted as the constant gravity vector in {W}. The IMU measurement terms are:

{circumflex over (ω)}(t)=ω(t)+b_ω(t)+n_ω(t), Eq. 3

â(t)=a(t)−_W^CR(t)g−_C^It∥ω(t)∥²+b_a(t)+n_a(t), Eq. 4

where _W^CR(t) is the rotation matrix from {W} to {C}, and t is the translation vector between {C} and {I}.

It is noted that the term _C^It∥ω(t)∥²represents the centrifugal force due to the fact that the rotation center (origin of {C}) is different from the origin of {I}. Some examples of visual-inertial navigation methods model the motion in {I} to eliminate this centrifugal force term. In the computational method disclosed herein, in which visual features both with and without depth information are used, converting features without depth from {C} to {I} is not straight forward (see below). As a result, the system disclosed herein models all of the motion in {C} instead. Practically, the camera and the IMU are mounted close to each other to maximally reduce effect of the term.

The IMU biases may be slowly changing variables. Consequently, the most recently updated biases are used for motion integration. First, Eq. 3 is integrated over time. Then, the resulting orientation is used with Eq. 4 for integration over time twice to obtain translation from the acceleration data.

Bias Correction

The IMU bias correction can be made by feedback from either the camera or the laser (see 128, 138, respectively, in FIGS. 1 and 2). Each feedback term contains the estimated incremental motion over a short amount of time. The biases may be modeled to be constant during the incremental motion. Starting with Eq. 3, b_ω(t) may be calculated by comparing the estimated orientation with IMU integration. The updated b_ω(t) is used in one more round of integration to re-compute the translation, which is compared with the estimated translation to calculate b_a(t).

To reduce the effect of high-frequency noises, a sliding window is employed keeping a known number of biases. Non-limiting examples of the number of biases used in the sliding window may include 200 to 1000 biases with a recommended number of 400 biases based on a 200 Hz IMU rate. A non-limiting example of the number of biases in the sliding window with an IMU rate of 100 Hz is 100 to 500 with a typical value of 200 biases. The averaged biases from the sliding window are used. In this implementation, the length of the sliding window functions as a parameter for determining an update rate of the biases. Although alternative methods to model the biases are known in the art, the disclosed implementation is used in order to keep the IMU processing module as a separate and distinct module. The sliding window method may also allow for dynamic reconfiguration of the system. In this manner, the IMU can be coupled with either the camera, the laser, or both camera and laser as required. For example, if the camera is non-functional, the IMU biases may be corrected only by the laser instead.

Visual-Inertial Odometry Subsystem

A block system diagram of the visual-inertial odometry subsystem is depicted in FIG. 5. An optimization module 510 uses pose constraints 512 from the IMU prediction module 520 along with camera constraints 515 based on optical feature data having or lacking depth information for motion estimation 550. A depthmap registration module 545 may include depthmap registration and depth association of the tracked camera features 530 with depth information obtained from the laser points 540. The depthmap registration module 545 may also incorporate motion estimation 550 obtained from a previous calculation. The method tightly couples vision with an IMU. Each provides constraints 512, 515, respectively, to an optimization module 510 that estimates incremental motion 550. At the same time, the method associates depth information to visual features as part of the depthmap registration module 545. If a feature is located in an area where laser range measurements are available, depth is obtained from laser points. Otherwise, depth is calculated from triangulation using the previously estimated motion sequence. As the last option, the method can also use features without any depth by formulating constraints in a different way. This is true for those features which do not have laser range coverage or cannot be triangulated because they are not tracked long enough or located in the direction of camera motion.

Camera Constraints

The visual-inertial odometry is a key-frame based method. A new key-frame is determined 535 if more than a certain number of features lose tracking or the image overlap is below a certain ratio. Here, right superscript l, lϵZ⁺ may indicate the last key-frame, and c, cϵZ⁺ and c>k, may indicate the current frame. As disclosed above, the method combines features with and without depth. A feature that is associated with depth at key-frame l, may be denoted as X_l=[x_l, y_l, z_l]^Tin {C_l}. Correspondingly, a feature without depth is denoted as X_l=[x_l, y_{l, 1}]^Tusing normalized coordinates instead. Note that X_l, X_l, x_l, and x_lare different from χ and x in Eq.1 which represent the system state. Features at key-frames may be associated with depth for two reasons: 1) depth association takes some amount of processing, and computing depth association only at key-frames may reduce computation intensity; and 2) the depthmap may not be available at frame c and thus laser points may not be registered since registration depends on an established depthmap. A normalized feature in {C_c} may be denoted as Xc=[x_c, y_c, 1]^T.

Let R_l^cand t_l^cbe the 3×3 rotation matrix and 3×1 translation vector between frames l and c, where R_l^cϵSO(3) and t_l^cϵ custom-character ³, R_l^cand T_l^cform an SE(3) transformation. The motion function between frames l and c may be written as

E
_c
=R
_l
^c
X
_l
+t
_l
^c. Eq. 5

X_chas an unknown depth. Let d_cbe the depth, where X_c=d_cX_c. Substituting X_cwith d_cX_cand combining the 1st and 2nd rows with the 3rd row in Eq. 5 to eliminate d_c, results in

(R(1)−x_cR(3))X_l+t₁−x_ct(3)=0, Eq. 6

(R(2)−ycR(3))X_l+t₂−y_ct(3)=0, Eq. 7

R(h) and t(h), hϵ{1, 2, 3}, are the h-th rows of R_l^cand t_l^c. In the case that depth in unavailable to a feature, let d_lbe the unknown depth at key-frame l. Substituting X_land X_cwith d_kX_land d_cX_c, respectively, and combining all three rows in Eq. 5 to eliminate d_kand d_c, results in another constraint,

[y_ct(3)−t(2)],−x_ct(3)+t(1),x_ct(2)−y_ct(1)]R_l^cX₁=0. Eq. 8

Motion Estimation

The motion estimation process 510 is required to solve an optimization problem combining three sets of constraints: 1) from features with known depth as in Eqs. 6-7; 2) from features with unknown depth as in Eq. 8; and 3) from the IMU prediction 520. T_a^bmay be defined as a 4×4 transformation matrix between frames a and b,

$\begin{matrix} T_{a}^{b} = [\begin{matrix} R_{a}^{b} & t_{a}^{b} \\ 0^{T} & 1 \end{matrix}], & Eq . 9 \end{matrix}$

where R_a^band t_a^bare the corresponding rotation matrix and translation vector. Further, let θ_a^bbe a 3×1 vector corresponding to R_a^bthrough an exponential map, where θ_a^bϵso(3). The normalized term θ/∥θ∥ represents direction of the rotation and ∥θ∥ is the rotation angle. Each T_a^bcorresponds to a set of θ_a^band t_a^bcontaining 6-DOF motion of the camera.

The solved motion transform between frames l and c−1, namely T_l^c-1may be used to formulate the IMU pose constraints. A predicted transform between the last two frames c−1 and c, denoted as T_c−1^cmay be obtained from IMU mechanization. The predicted transform at frame c is calculated as,

T

_l
^c
=T
_c−1
^c
T
_l
^c-1 Eq. 10

Let θ_l^cand t_l^cbe the 6-DOF motion corresponding to T_l^c. It may be understood that the IMU predicted translation, t_l^c, is dependent on the orientation. As an example, the orientation may determine a projection of the gravity vector through rotation matrix _W^CR(t) in Eq. 4, and hence the accelerations that are integrated. {circumflex over (t)}_l^cmay be formulated as a function of θ_l^c, and may be rewriten as t_l^c(θ_l^c). It may be understood that the 200 Hz pose provided by the IMU prediction module 122 (FIGS. 1 and 2) as well as the 50 Hz pose provided by the visual-inertial odometry module 126 (FIGS. 1 and 2) are both pose functions. Calculating t_l^c(θ_l^c) may begin at frame c and the accelerations may be integrated inversely with respect to time. Let θ_l^cbe the rotation vector corresponding to R_l^cin Eq. 5, and θ_l^cand t_l^care the motion to be solved. The constraints may be expressed as,

Σ_l^c[(θ_l^c−θ_l^c)^T,(t_l^c(θ_l^c)−t_l^c)^T]^T=0, Eq. 11

in which Σ_l^cis a relative covariance matrix scaling the pose constraints appropriately with respect to the camera constraints.

In the visual-inertial odometry subsystem, the pose constraints fulfill the motion model and the camera constraints fulfill the landmark measurement model in Eq. 2. The optimization problem may be solved by using the Newton gradient-descent method adapted to a robust fitting framework for outlier feature removal. In this problem, the state space contains θ_l^cand t_l^c. Thus, a full-scale MAP estimation is not performed, but is used only to solve a marginalized problem. The landmark positions are not optimized, and thus only six unknowns in the state space are used, thereby keeping computation intensity low. The method thus involves laser range measurements to provide precise depth information to features, warranting motion estimation accuracy. As a result, further optimization of the features' depth through a bundle adjustment may not be necessary.

Depth Association

The depthmap registration module 545 registers laser points on a depthmap using previously estimated motion. Laser points 540 within the camera field of view are kept for a certain amount of time. The depthmap is down-sampled to keep a constant density and stored in a 2D KD-tree for fast indexing. In the KD-tree, all laser points are projected onto a unit sphere around the camera center. A point is represented by its two angular coordinates. When associating depth to features, features may be projected onto the sphere. The three closest laser points are found on the sphere for each feature. Then, their validity may be by calculating distances among the three points in Cartesian space. If a distance is larger than a threshold, the chance that the points are from different objects, e.g. a wall and an object in front of the wall, is high and the validity check fails. Finally, the depth is interpolated from the three points assuming a local planar patch in Cartesian space.

Those features without laser range coverage, if they are tracked over a certain distance and not located in the direction of camera motion, may be triangulated using the image sequences where the features are tracked. In such a procedure, the depth may be updated at each frame based on a Bayesian probabilistic mode.

Scan Matching Subsystem

This subsystem further refines motion estimates from the previous module by laser scan matching. FIG. 6 depicts a block diagram of the scan matching subsystem. The subsystem receives laser points 540 in a local point cloud and registers them 620 using provided odometry estimation 550. Then, geometric features are detected 640 from the point cloud and matched to the map. The scan matching minimizes the feature-to-map distances, similar to many methods known in the art. However, the odometry estimation 550 also provides pose constraints 612 in the optimization 610. The optimization comprises processing pose constraints with feature correspondences 615 that are found and further processed with laser constraints 617 to produce a device pose 650. This pose 650 is processed through a map registration process 655 that facilitates finding the feature correspondences 615. The implementation uses voxel representation of the map. Further, it can dynamically configure to run on one to multiple CPU threads in parallel.

Laser Constraints

When receiving laser scans, the method first registers points from a scan 620 into a common coordinate system. m, mϵZ⁺ may be used to indicate the scan number. It is understood that the camera coordinate system may be used for both the camera and the laser. Scan m may be associated with the camera coordinate system at the beginning of the scan, denoted as {C_m}. To locally register 620 the laser points 540, the odometry estimation 550 from the visual-inertial odometry may be taken as key-points, and the IMU measurements may be used to interpolate in between the key-points.

Let P_mbe the locally registered point cloud from scan m. Two sets of geometric features from P_mmay be extracted: one on sharp edges, namely edge points and denoted as ε_m, and the other on local planar surfaces, namely planar points and denoted as H_m. This is through computation of curvature in the local scans. Points whose neighbor points are already selected are avoided such as points on boundaries of occluded regions and points whose local surfaces are close to be parallel to laser beams. These points are likely to contain large noises or change positions over time as the sensor moves.

The geometric features are then matched to the current map built. Let Q_m−1be the map point cloud after processing the last scan, Q_m−1is defined in {W}. The points in Q_m−1are separated into two sets containing edge points and planar points, respectively. Voxels may be used to store the map truncated at a certain distance around the sensor. For each voxel, two 3D KD-trees may be constructed, one for edge points and the other for planar points. Using KD-trees for individual voxels accelerates point searching since given a query point, a specific KD-tree associated with a single voxel needs to be searched (see below).

When matching scans, ε_mand H_minto {W} are first projected using the best guess of motion available, then for each point in ε_mand H_m, a cluster of closest points are found from the corresponding set on the map. To verify geometric distributions of the point clusters, the associated eigenvalues and eigenvectors may be examined Specifically, one large and two small eigenvalues indicate an edge line segment, and two large and one small eigenvalues indicate a local planar patch. If the matching is valid, an equation is formulated regarding the distance from a point to the corresponding point cluster,

ƒ(Xm,θm,tm)=d, Eq. 12

where X_mis a point in ε_mor H_m, θ_m, θ_m, ϵso(3), and t_m, t_mϵ custom-character ³, indicate the 6-DOF pose of {C_m} in {W}.

Motion Estimation

The scan matching is formulated into an optimization problem 610 minimizing the overall distances described by Eq. 12. The optimization also involves pose constraints 612 from prior motion. Let T_m−1be the 4×4 transformation matrix regarding the pose of {Cm−1} in {W}, T_m−1is generated by processing the last scan. Let {circumflex over (T)}_m−1^mbe the pose transform from {C_{m−1} to {C}_m}, as provided by the odometry estimation. Similar to Eq. 10, the predicted pose transform of {C_m} in {W} is,

{circumflex over (T)}
_m
={circumflex over (T)}
_m−1
^m
T
^m-1. Eq. 13

Let {circumflex over (θ)}_mand {circumflex over (t)}_mbe the 6-DOF pose corresponding to {circumflex over (T)}_m, and let Σ_mbe a relative covariance matrix. The constraints are,

Σ_m[({circumflex over (θ)}_m−θ_m)^T,({circumflex over (t)}_m−t_m)^T]^T=0. Eq. 14

Eq. 14 refers to the case that the prior motion is from the visual-inertial odometry, assuming the camera is functional. Otherwise, the constraints are from the IMU prediction. {circumflex over (θ)}_mand {circumflex over (t)}′_m(θ_m) may be used to denote the same terms by IMU mechanization. {circumflex over (t)}′_m(θ_m) is a function of θ_mbecause integration of accelerations is dependent on the orientation (same with {circumflex over (t)}_l^c(θ_l^c) in Eq. 11). The IMU pose constraints are,

Σ′_m[({circumflex over (θ)}′_m−θ_m)^T,({circumflex over (t)}′_m(θ_m)−t_m)^T]^T=0, Eq. 15

where Σ′_mis the corresponding relative covariance matrix. In the optimization problem, Eqs. 14 and 15 are linearly combined into one set of constraints. The linear combination is determined by working mode of the visual-inertial odometry. The optimization problem refines θ_mand t_m, which is solved by the Newton gradient-descent method adapted to a robust fitting framework.

Map in Voxels

The points on the map are kept in voxels. A 2-level voxel implementation as illustrated in FIGS. 7A and 7B. M_m−1denotes the set of voxels 702, 704 on the first level map 700 after processing the last scan. Voxels 704 surrounding the sensor 706 form a subset M_m−1, denoted as S_m−1. Given a 6-DOF sensor pose, {circumflex over (θ)}_mand {circumflex over (t)}_m, there is a corresponding S_m−1which moves with the sensor on the map. When the sensor approaches the boundary of the map, voxels on the opposite side 725 of the boundary are moved over to extend the map boundary 730. Points in moved voxels are cleared resulting in truncation of the map.

As illustrated in FIG. 7B, each voxel j, jεϵS_m−1of the second level map 750 is formed by a set of voxels that are a magnitude smaller, denoted as S_m−1^jthan those of the first level map 700. Before matching scans, points in ε_mand custom-character _mare projected onto the map using the best guess of motion, and fill them into {S_m−1^j}, jϵS_m−1. Voxels 708 occupied by points from ε_mand _mare extracted to form Q_m−1and stored in 3D KD-trees for scan matching. Voxels 710 are those not occupied by points from ε_mor custom-character _m. Upon completion of scan matching, the scan is merged into the voxels 708 with the map. After that, the map points are downsized to maintain a constant density. It may be recognized that each voxel of the first level map 700 corresponds to a volume of space that is larger than a sub-voxel of the second level map 750. Thus, each voxel of the first level map 700 comprises a plurality of sub-voxels in the second level map 750 and can be mapped onto the plurality of sub-voxels in the second level map 750.

As noted above with respect to FIGS. 7A and 7B, two levels of voxels (first level map 700 and second level map 750) are used to store map information. Voxels corresponding to M_m−1are used to maintain the first level map 700 and voxels corresponding to {S_m−1^j}, jϵS_m−1in the second level map 750 are used to retrieve the map around the sensor for scan matching. The map is truncated only when the sensor approaches the map boundary. Thus, if the sensor navigates inside the map, no truncation is needed. Another consideration is that two KD-trees are used for each individual voxel in S_m−1—one for edge points and the other for planar points. As noted above, such a data structure may accelerate point searching. In this manner, searching among multiple KD-trees is avoided as opposed to using two KD-trees for each individual voxel in {S_m−1^j}, jϵS_m−1. The later requires more resources for KD-tree building and maintenance.

Table 1 compares CPU processing time using different voxel and KD-tree configurations. The time is averaged from multiple datasets collected from different types of environments covering confined and open, structured and vegetated areas. We see that using only one level of voxels, M_m−1, results in about twice of processing time for KD-tree building and querying. This is because the second level of voxels, {S_m−1^j}, jϵS_m−1, help retrieve the map precisely. Without these voxel, more points are contained in Q_m−1and built into the KD-trees. Also, by using KD-trees for each voxel, processing time is reduced slightly in comparison to using KD-trees for all voxels in M_m−1.

TABLE 1

Comparison of average CPU processing time on KD-tree operation

1-level voxels
2-level voxels

KD-trees
KD-trees
KD-trees
KD-trees

for
for
for
for

Task
all voxels
each voxel
al voxels
each voxel

Build (time
54
ms
47
ms
24
ms
21
ms

per KD-tree)

Query (time
4.2
ns
4.1
ns
2.4
ns
2.3
ns

per point)

Parallel Processing

The scan matching involves building KD-trees and repetitively finding feature correspondences. The process is time-consuming and takes major computation in the system. While one CPU thread cannot guarantee the desired update frequency, a multi-thread implementation may address issues of complex processing. FIG. 8A illustrates the case where two matcher programs 812, 815 run in parallel. Upon receiving of a scan, a manager program 810 arranges it to match with the latest map available. In one example, composed of a clustered environment with multiple structures and multiple visual features, matching is slow and may not complete before arrival of the next scan. The two matchers 812 and 815 are called alternatively. In one matcher 812, P_m, 813a P_m−2, 813b and additional P_m−k(for k=an even integer) 813n, are matched with Q_m−2813a, Q_m−4813a, and additional Q_m−k(for k=an even integer) 813n, respectively. Similarly, in a second matcher 815, P_m+1, 816a P_m−1, 816b and additional P_m−k(for k=an odd integer) 816n, are matched with Q_m−1816a, Q_m−3816a, and additional Q_m−k(for k=an odd integer) 816n, respectively, The use of this interleaving process may provide twice the amount of time for processing. In an alternative example, composed of a clean environment with few structures or visual features, computation is light. In such an example (FIG. 8B), only a single matcher 820 may be called. Because interleaving is not required P_m, P_m−1, . . . , are sequentially matched with Q_m−1, Q_m−2, . . . , respectively (see 827a, 827b, 827n). The implementation may be configured to use a maximum of four threads, although typically only two threads may be needed.

Transform Integration

The final motion estimation is integration of outputs from the three modules depicted in FIG. 2. The 5 Hz scan matching output produces the most accurate map, while the 50 Hz visual-inertial odometry output and the 200 Hz IMU prediction are integrated for high-frequency motion estimates.

On Robustness

The robustness of the system is determined by its ability to handle sensor degradation. The IMU is always assumed to be reliable functioning as the backbone in the system. The camera is sensitive to dramatic lighting changes and may also fail in a dark/texture-less environment or when significant motion blur is present (thereby causing a loss of visual features tracking). The laser cannot handle structure-less environments, for example a scene that is dominant by a single plane. Alternatively, laser data degradation can be caused by sparsity of the data due to aggressive motion.

Both the visual-inertial odometry and the scan matching modules formulate and solve optimization problems according to EQ. 2. When a failure happens, it corresponds to a degraded optimization problem, i.e. constraints in some directions of the problem are ill-conditioned and noise dominates in determining the solution. In one non-limiting method, eigenvalues, denoted as λ1, λ2, . . . , λ6, and eigenvectors, denoted as ν₁, ν₂, . . . , ν₆, associated with the problem may be computed. Six eigenvalues/eigenvectors are present because the state space of the sensor contains 6-DOF (6 degrees of freedom). Without losing generality, ν₁, ν₂, ν₆may be sorted in decreasing order. Each eigenvalue describes how well the solution is conditioned in the direction of its corresponding eigenvector. By comparing the eigenvalues to a threshold, well-conditioned directions may be separated from degraded directions in the state space. Let h, h=0; 1, . . . , 6, be the number of well-conditioned directions. Two matrices may be defined as:

V=[ν₁, . . . ,ν₆]^T,V=[ν₁, . . . ,ν_h,0, . . . ,0]^T. Eq. 16

When solving an optimization problem, the nonlinear iteration may start with an initial guess. With the sequential pipeline depicted in FIG. 2, the IMU prediction provides the initial guess for the visual-inertial odometry, whose output is taken as the initial guess for the scan matching. For the additional two modules (visual-inertial odometry and scan matching modules), let x be a solution and Δx be an update of x in a nonlinear iteration, in which Δx is calculated by solving the linearized system equations. During the optimization process, instead of updating x in all directions, x may be updated only in well-conditioned directions, keeping the initial guess in degraded directions instead,

x←x+V
⁻¹

VΔx. Eq. 17

In Eq. 17, the system solves for motion in a coarse-to-fine order, starting with the IMU prediction, the additional two modules further solving/refining the motion as much as possible. If the problem is well-conditioned, the refinement may include all 6-DOF. Otherwise, if the problem is only partially well-conditioned, the refinement may include 0 to 5-DOF. If the problem is completely degraded, V becomes a zero matrix and the previous module's output is kept.

Returning to the pose constraints described in Eqs. 14 and 15, it may be understood that the two equations are linearly combined in the scan matching problem. As defined in Eq. 16, V_Vand V_Vdenote the matrices containing eigenvectors from the visual-inertial odometry module, V_Vrepresents well-conditioned directions in the subsystem, and V_V−V_Vrepresents degraded directions. The combined constraints are,

Σ_mV_V⁻¹V_V[({circumflex over (θ)}_m−θ_m)^T,({circumflex over (t)}_m−t_m)^T]^T+Σ′^mV_V⁻¹

(V_V−V_V)[({circumflex over ({circumflex over (θ)})}′_m−θ_m)^T,({circumflex over (t)}′_m(θ_m)−t_m)^T]^T=0. Eq. 18

In a normal case where the camera is functional, V_V=V_Vand Eq.18 is composed of pose constraints from the visual-inertial odometry as in Eq. 14. However, if the camera data are completely degraded, V_Vis a zero matrix and Eq. 18 is composed of pose constraints from the IMU prediction according to Eq. 15.

Case Study of Camera Degradation

As depicted in FIG. 9A, if visual features are insufficiently available for the visual-inertial odometry, the IMU prediction 122 bypasses the visual-inertial odometry module 126 fully or partially 924—denoted by the dotted line—depending on the number of well-conditioned directions in the visual-inertial odometry problem. The scan matching module 132 may then locally register laser points for the scan matching. The bypassing IMU prediction is subject to drift. The laser feedback 138 compensates for the camera feedback 128 correcting velocity drift and biases of the IMU, only in directions where the camera feedback 128 is unavailable. Thus, the camera feedback has a higher priority, due to the higher frequency making it more suitable when the camera data are not degraded. When sufficient visual features are found, the laser feedback is not used.

Case Study of Laser Degradation

As shown in FIG. 9B, if environmental structures are insufficient for the scan matching 132 to refine motion estimates, the visual-inertial odometry module 126 output fully or partially bypasses the scan matching module to register laser points on the map 930 as noted by the dotted line. If well-conditioned directions exist in the scan matching problem, the laser feedback contains refined motion estimates in those directions. Otherwise, the laser feedback becomes empty 138.

Case Study of Camera and Laser Degradation

In a more complex example, both the camera and the laser are degraded at least to some extent. FIG. 10 depicts such an example. A vertical bar with six rows represents a 6-DOF pose where each row is a DOF (degree of freedom), corresponding to an eigenvector in EQ. 16. In this example, the visual-inertial odometry and the scan matching each updates a 3-DOF of motion, leaving the motion unchanged in the other 3-DOF. The IMU prediction 1022a-f may include initial IMU predicted values 1002. The visual-inertial odometry updates 1004 some 3-DOF (1026c, 1026e, 1026f) resulting in a refined prediction 1026a-1026f. The scan matching updates 1006 some 3-DOF (1032b, 1032d, 10320 resulting in a further refined prediction 1032a-1032f. The camera feedback 128 contains camera updates 1028a-1028f and the laser feedback 138 contains laser updates 1038a-1038f, respectively. In reference to FIG. 10, cells having no shading (1028a, 1028b, 1028d, 1038a, 1038c, 1038e) do not contain any updating information from the respective modules. The total update 1080a-1080f to the IMU prediction modules is a combination of the updates 1028a-1028f from the camera feedback 128 and the updates 1038a-1038f from the laser feedback 138. In one or more of the degrees of freedom in which feedback is available from both the camera (for example 10280 and the laser (for example 10380, the camera updates (for example 10280 may have priority over the laser updates (for example 10380.

In practice, however, the visual-inertial odometry module and the scan matching module may execute at different frequencies and each may have its own degraded directions. IMU messages may be used to interpolate between the poses from the scan matching output. In this manner, an incremental motion that is time aligned with the visual-inertial odometry output may be created. Let θ_c−1^cand t_c−1^cbe the 6-DOF motion estimated by the visual-inertial odometry between frames c−1 and c, where θ_c−1^cϵso(3) and t_c−1^cϵ custom-character ³. Let θ′_c−1^cand t′_c−1^cbe the corresponding terms estimated by the scan matching after time interpolation. V_Vand V_Vmay be the matrices defined in Eq. 16 containing eigenvectors from the visual-inertial odometry module, in which V_Vrepresents well-conditioned directions, and V_V−V_Vrepresents degraded directions. Let V_Sand V_Sbe the same matrices from the scan matching module. The following equation calculates the combined feedback, f_C,

f
_c
=f
_V
+V
_V
⁻¹(V_V−V_V)f_s, Eq. 19

where f_Vand f_srepresent the camera and the laser feedback,

f
_V
=V
_V
⁻¹(V_V)[θ_c−1^c)^T,(t_c−1^c)^T]^T, Eq. 20

f
_s,
=V
_S
⁻¹

V

_S[θ′_c−1^c)^T,(t′_c−1^c)^T]^T. Eq. 21

note that f_Conly contains solved motion in a subspace of the state space. The motion from the IMU prediction, namely {circumflex over (θ)}_c−1^cand {circumflex over (t)}_c−1^c, may be projected to the null space of f_C,

f
_I
=V
_V
⁻¹(V_V−V_V)V_S⁻¹(V_S−V_S)[{circumflex over (θ)}_c−1^c)^T,({circumflex over (t)}_c−1^c)^T]^T Eq. 22

{tilde over (θ)}_c−1^c(b_ω(t)) and {tilde over (t)}_c−1^c(b_ω(t), b_a(t)) may be used to denote the IMU predicted motion formulated as functions of b_ω(t) and b_a(t) through integration of Eqs. 3 and 4. The orientation {tilde over (θ)}_c−1^c(b_ω(t)) is only relevant to bω(t), but the translation {tilde over (t)}_c−1^c(bω(t), b_a(t)) is dependent on both bω(t) and b_a(t). The biases can be calculated by solving the following equation,

[({tilde over (θ)}_c−1^c(b_ω(t)))^T,({tilde over (t)}_c−1^c(b_ω(t),b_a(t)))^T]^T=f_C+F^I. Eq. 23

When the system functions normally, f_Cspans the state space, and V_V−V_Vand V_S−V_Sin Eq. 22 are zero matrices. Correspondingly, b_ω(t) and b_a(t) are calculated from f_C. In a degraded case, the IMU predicted motion, θ_c−1^cand t_c−1^c, is used in directions where the motion is unsolvable (e.g. white row 1080a of the combined feedback in FIG. 10). The result is that the previously calculated biases are kept in these directions.

EXPERIMENTS

Tests with Scanners

The odometry and mapping software system was validated on two sensor suites. In a first sensor suite, a Velodyne LIDAR™ HDL-32E laser scanner is attached to a UI-1220SE monochrome camera and an Xsens® MTi-30 IMU. The laser scanner has 360° horizontal FOV, 40° vertical FOV, and receives 0.7 million points/second at 5 Hz spinning rate. The camera is configured at the resolution of 752×480 pixels, 76° horizontal FOV, and 50 Hz frame rate. The IMU frequency is set at 200 Hz. In a second sensor suite, a Velodyne LIDAR™ VLP-16 laser scanner is attached to the same camera and IMU. This laser scanner has 360° horizontal FOV, 30° vertical FOV, and receives 0.3 million points/second at 5 Hz spinning rate. Both sensor suites are attached to vehicles for data collection, which are driven on streets and in off-road terrains, respectively.

For both sensor suites, a maximum of 300 Harris corners were tracked. To evenly distribute the visual features, an image is separated into 5×6 identical sub-regions, each sub-region providing up to 10 features. When a feature loses tracking, a new feature is generated to maintain the feature number in each sub region.

The software runs on a laptop computer with a 2.6 GHz i7 quad-core processor (2 threads on each core and 8 threads overall) and an integrated GPU, in a Linux® system running Robot Operating System (ROS). Two versions of the software were implemented with visual feature tracking running on GPU and CPU, respectively. The processing time is shown in Table 2. The time used by the visual-inertial odometry (126 in FIG. 2) does not vary much with respect to the environment or sensor configuration. For the GPU version, it consumes about 25% of a CPU thread executing at 50 Hz. For the CPU version, it takes about 75% of a thread. The sensor first suite results in slightly more processing time than the second sensor suite. This is because the scanner receives more points and the program needs more time to maintain the depthmap and associate depth to the visual features.

The scan matching (132 in FIG. 2) consumes more processing time which also varies with respect to the environment and sensor configuration. With the first sensor suite, the scan matching takes about 75% of a thread executing at 5 Hz if operated in structured environments. In vegetated environments, however, more points are registered on the map and the program typically consumes about 135% of a thread. With the second sensor suite, the scanner receives fewer points. The scan matching module 132 uses about 50-95% of a thread depending on the environment. The time used by the IMU prediction (132 in FIG. 2) is negligible compared to the other two modules.

Accuracy Tests

Tests were conducted to evaluate accuracy of the proposed system. In these tests, the first sensor suite was used. The sensors were mounted on an off-road vehicle driving around a university campus. After 2.7 km of driving within 16 minutes, a campus map was built. The average speed over the test was 2.8 m/s.

TABLE 2

Average CPU processing time using the first and second sensor suites

Visual-inertial odometry

(time per image frame)
Scan Matching

GPU
CPU
(time per laser

Environment
Senor suite
Tracking
Tracking
scan)

Structured
First suite
4.8 ms
14.3 ms
148 ms

Second suite
4.2 ms
12.9 ms
103 ms

Vegetated
First suite
5.5 ms
15.2 ms
267 ms

Second suite
5.1 ms
14.7 ms
191 ms

To evaluate motion estimation drift over the test, the estimated trajectory and registered laser points were aligned on a satellite image. Here, laser points on the ground are manually removed. It was determined, by matching the trajectory with streets on the satellite image, that an upper bound of the horizontal error was <1:0 m. It was also determined, by comparing buildings on the same floor, that the vertical error was <2:0 m. This gives an overall relative position drift at the end to be <0:09% of the distance traveled. It may be understood that precision cannot be guaranteed for the measurements, hence only an upper bound of the positional drift was calculated.

Further, a more comprehensive test was conducted having the same sensors mounted on a passenger vehicle. The passenger vehicle was driven on structured roads for 9.3 km of travel. The path traverses vegetated environments, bridges, hilly terrains, and streets with heavy traffic, and finally returns to the starting position. The elevation changes over 70 m along the path. Except waiting for traffic lights, the vehicle speed is between 9-18 m/s during the test. It was determined that a building found at both the start and the end of the path was registered into two. The two registrations occur because of motion estimation drift over the length of the path. Thus, the first registration corresponds to the vehicle at the start of the test and the second registration corresponds to the vehicle at the end of the test. The gap was measured to be <20 m, resulting in a relative position error at the end of <0:22% of the distance traveled.

Each module in the system contributes to the overall accuracy. FIG. 11 depicts estimated trajectories in an accuracy test. A first trajectory plot 1102 of the trajectory of a mobile sensor generated by the visual-inertial odometry system uses the IMU module 122 and the visual-inertial odometry module 126 (see FIG. 2). The configuration used in the first trajectory plot 1102 is similar to that depicted in FIG. 9B. A second trajectory plot 1104 is based on directly forwarding the IMU prediction from the IMU module 122 to the scan matching module, 132 (see FIG. 2) bypassing the visual-inertial odometry. This configuration is similar to that depicted in FIG. 9A. A third trajectory plot 1108 of the complete pipeline is based on the combination of the IMU module 122, the visual inertial odometry module 126, and the scan matching module 132 (see FIG. 2) has the least amount of drift. The position errors of the first two configurations, trajectory plot 1102 and 1104, are about four and two times larger, respectively.

The first trajectory plot 1102 and the second trajectory plot 1104 can be viewed as the expected system performance when encountering individual sensor degradation. If scan matching is degraded (see FIG. 9B), the system reduces to a mode indicated by the first trajectory plot 1102. If vision is degraded, (see FIG. 9A), the system reduces to a mode indicated by the second trajectory plot 1104. If none of the sensors is degraded, (see FIG. 2) the system incorporates all of the optimization functions resulting in the trajectory plot 1108. In another example, the system may take the IMU prediction as the initial guess and but run at the laser frequency (5 Hz). The system produces a fourth trajectory plot 1106. The resulting accuracy is only little better in comparison to the second trajectory plot 1104 which uses the IMU directly coupled with the laser, passing the visual-inertial odometry. The result indicates that functionality of the camera is not sufficiently explored if solving the problem with all constraints stacked together.

Another accuracy test of the system included running mobile sensor at the original 1× speed and an accelerated 2× speed. When running at 2× speed, every other data frame for all three sensors is omitted, resulting in much more aggressive motion through the test. The results are listed in Table 3. At each speed, the three configurations were evaluated. At 2× speed, the accuracy of the visual-inertial odometry and the IMU+scan matching configurations reduce significantly, by 0.54% and 0.38% of the distance traveled in comparison to the accuracy at 1× speed. However, the complete pipeline reduces accuracy very little, only by 0.04%. The results indicate that the camera and the laser compensate for each other keeping the overall accuracy. This is especially true when the motion is aggressive.

TABLE 3

Relative position errors as percentages of the distance traveled

(Errors at 1 × speed correspond to the trajectories in FIG. 11)

Configuration
1 × speed
2 × speed

Visual-inertial odometry
0.93%
1.47%

IMU + scan matching
0.51%
0.89%

Complete pipeline
0.22%
0.26%

With reference to FIG. 12, there is illustrated an exemplary and non-limiting embodiment of bidirectional information flow. As illustrated, three modules comprising an IMU prediction module, a visual-inertial odometry module and a scan-matching refinement module solve the problem step by step from coarse to fine. Data processing flow is from left to right passing the three modules respectively, while feedback flow is from right to left to correct the biases of the IMU.

With reference to FIGS. 13a and 13b, there is illustrated an exemplary and non-limiting embodiment of a dynamically reconfigurable system. As illustrated in FIG. 13a, if visual features are insufficient for the visual-inertial odometry, the IMU prediction (partially) bypasses the visual-inertial odometry module to register laser points locally. On the other hand, if, as illustrated in FIG. 13b, environmental structures are insufficient for the scan matching, the visual-inertial odometry output (partially) bypasses the scan matching refinement module to register laser points on the map.

With reference to FIG. 14, there is illustrated an exemplary and non-limiting embodiment of priority feedback for IMU bias correction. As illustrated, a vertical bar represents a 6-DOF pose and each row is a DOF. In a degraded case, starting with the IMU prediction on the left where all six rows designated are “IMU”, the visual-inertial odometry updates in 3-DOF where the rows become designated “camera”, then the scan matching updates in another 3-DOF where the rows turn designated “laser”. The camera and the laser feedback is combined as the vertical bar on the left. The camera feedback has a higher priority “laser” rows from the laser feedback are only filled in if “camera” rows from the camera feedback are not present.

With reference to FIGS. 15a and 15b, there is illustrated an exemplary and non-limiting embodiment of two-layer voxel representation of a map. There is illustrated voxels on the map M_m−1(all voxels in FIG. 15a), and voxels surrounding the sensor S_m−1(dot filled voxels). S_m−1is a subset of M_m−1. If the sensor approaches the boundary of the map, voxels on the opposite side of the boundary (bottom row) are moved over to extend the map boundary. Points in moved voxels are cleared and the map is truncated. As illustrated in FIG. 15b each voxel j, jϵS_m−1(a dot filled voxel in FIG. 15a) is formed by a set of voxels S_m−1^jthat are a magnitude smaller (all voxels in (FIG. 15b)ϵS_m−1^j). Before scan matching, the laser scan may be projected onto the map using the best guess of motion. Voxels in {S_m−1^j}, jϵS_m−1occupied by points from the scan are labeled in cross-hatch. Then, map points in cross-hatched voxels are extracted and stored in 3D KD-trees for scan matching.

With reference to FIG. 16, there is illustrated an exemplary and non-limiting embodiment of multi-thread processing of scan matching. As illustrated, a manager program calls multiple matcher programs running on separate CPU threads and matches scans to the latest map available. FIG. 16a shows a two-thread case. Scans P_m, P_m−1, . . . , are matched with map Q_m, Q_m−1, . . . , on each matcher, giving twice amount of time for processing. In comparison, FIG. 16b shows a one-thread case, where P_m, P_m−1, . . . , are matched with Q_m, Q_m−1, . . . . The implementation is dynamically configurable using up to four threads.

While only a few embodiments of the present disclosure have been shown and described, it will be obvious to those skilled in the art that many changes and modifications may be made thereunto without departing from the spirit and scope of the present disclosure as described in the following claims. All patent applications and patents, both foreign and domestic, and all other publications referenced herein are incorporated herein in their entireties to the full extent permitted by law.

The methods and systems described herein may be deployed in part or in whole through a machine that executes computer software, program codes, and/or instructions on a processor. The present disclosure may be implemented as a method on the machine, as a system or apparatus as part of or in relation to the machine, or as a computer program product embodied in a computer readable medium executing on one or more of the machines. In embodiments, the processor may be part of a server, cloud server, client, network infrastructure, mobile computing platform, stationary computing platform, or other computing platform. A processor may be any kind of computational or processing device capable of executing program instructions, codes, binary instructions and the like. The processor may be or may include a signal processor, digital processor, embedded processor, microprocessor or any variant such as a co-processor (math co-processor, graphic co-processor, communication co-processor and the like) and the like that may directly or indirectly facilitate execution of program code or program instructions stored thereon. In addition, the processor may enable execution of multiple programs, threads, and codes. The threads may be executed simultaneously to enhance the performance of the processor and to facilitate simultaneous operations of the application. By way of implementation, methods, program codes, program instructions and the like described herein may be implemented in one or more thread. The thread may spawn other threads that may have assigned priorities associated with them; the processor may execute these threads based on priority or any other order based on instructions provided in the program code. The processor, or any machine utilizing one, may include non-transitory memory that stores methods, codes, instructions and programs as described herein and elsewhere. The processor may access a non-transitory storage medium through an interface that may store methods, codes, and instructions as described herein and elsewhere. The storage medium associated with the processor for storing methods, programs, codes, program instructions or other type of instructions capable of being executed by the computing or processing device may include but may not be limited to one or more of a CD-ROM, DVD, memory, hard disk, flash drive, RAM, ROM, cache and the like.

A processor may include one or more cores that may enhance speed and performance of a multiprocessor. In embodiments, the process may be a dual core processor, quad core processors, other chip-level multiprocessor and the like that combine two or more independent cores (called a die).

The methods and systems described herein may be deployed in part or in whole through a machine that executes computer software on a server, client, firewall, gateway, hub, router, or other such computer and/or networking hardware. The software program may be associated with a server that may include a file server, print server, domain server, internet server, intranet server, cloud server, and other variants such as secondary server, host server, distributed server and the like. The server may include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other servers, clients, machines, and devices through a wired or a wireless medium, and the like. The methods, programs, or codes as described herein and elsewhere may be executed by the server. In addition, other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the server.

The server may provide an interface to other devices including, without limitation, clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers, social networks, and the like. Additionally, this coupling and/or connection may facilitate remote execution of program across the network. The networking of some or all of these devices may facilitate parallel processing of a program or method at one or more location without deviating from the scope of the disclosure. In addition, any of the devices attached to the server through an interface may include at least one storage medium capable of storing methods, programs, code and/or instructions. A central repository may provide program instructions to be executed on different devices. In this implementation, the remote repository may act as a storage medium for program code, instructions, and programs.

The software program may be associated with a client that may include a file client, print client, domain client, internet client, intranet client and other variants such as secondary client, host client, distributed client and the like. The client may include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other clients, servers, machines, and devices through a wired or a wireless medium, and the like. The methods, programs, or codes as described herein and elsewhere may be executed by the client. In addition, other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the client.

The client may provide an interface to other devices including, without limitation, servers, other clients, printers, database servers, print servers, file servers, communication servers, distributed servers and the like. Additionally, this coupling and/or connection may facilitate remote execution of program across the network. The networking of some or all of these devices may facilitate parallel processing of a program or method at one or more location without deviating from the scope of the disclosure. In addition, any of the devices attached to the client through an interface may include at least one storage medium capable of storing methods, programs, applications, code and/or instructions. A central repository may provide program instructions to be executed on different devices. In this implementation, the remote repository may act as a storage medium for program code, instructions, and programs.

The methods and systems described herein may be deployed in part or in whole through network infrastructures. The network infrastructure may include elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices and other active and passive devices, modules and/or components as known in the art. The computing and/or non-computing device(s) associated with the network infrastructure may include, apart from other components, a storage medium such as flash memory, buffer, stack, RAM, ROM and the like. The processes, methods, program codes, instructions described herein and elsewhere may be executed by one or more of the network infrastructural elements. The methods and systems described herein may be adapted for use with any kind of private, community, or hybrid cloud computing network or cloud computing environment, including those which involve features of software as a service (SaaS), platform as a service (PaaS), and/or infrastructure as a service (IaaS).

The methods, program codes, and instructions described herein and elsewhere may be implemented on a cellular network has sender-controlled contact media content item multiple cells. The cellular network may either be frequency division multiple access (FDMA) network or code division multiple access (CDMA) network. The cellular network may include mobile devices, cell sites, base stations, repeaters, antennas, towers, and the like. The cell network may be a GSM, GPRS, 3G, EVDO, mesh, or other networks types.

The methods, program codes, and instructions described herein and elsewhere may be implemented on or through mobile devices. The mobile devices may include navigation devices, cell phones, mobile phones, mobile personal digital assistants, laptops, palmtops, netbooks, pagers, electronic books readers, music players and the like. These devices may include, apart from other components, a storage medium such as a flash memory, buffer, RAM, ROM and one or more computing devices. The computing devices associated with mobile devices may be enabled to execute program codes, methods, and instructions stored thereon. Alternatively, the mobile devices may be configured to execute instructions in collaboration with other devices. The mobile devices may communicate with base stations interfaced with servers and configured to execute program codes. The mobile devices may communicate on a peer-to-peer network, mesh network, or other communications network. The program code may be stored on the storage medium associated with the server and executed by a computing device embedded within the server. The base station may include a computing device and a storage medium. The storage device may store program codes and instructions executed by the computing devices associated with the base station.

The computer software, program codes, and/or instructions may be stored and/or accessed on machine readable media that may include: computer components, devices, and recording media that retain digital data used for computing for some interval of time; semiconductor storage known as random access memory (RAM); mass storage typically for more permanent storage, such as optical discs, forms of magnetic storage like hard disks, tapes, drums, cards and other types; processor registers, cache memory, volatile memory, non-volatile memory; optical storage such as CD, DVD; removable media such as flash memory (e.g. USB sticks or keys), floppy disks, magnetic tape, paper tape, punch cards, standalone RAM disks, Zip drives, removable mass storage, off-line, and the like; other computer memory such as dynamic memory, static memory, read/write storage, mutable storage, read only, random access, sequential access, location addressable, file addressable, content addressable, network attached storage, storage area network, bar codes, magnetic ink, and the like.

The methods and systems described herein may transform physical and/or or intangible items from one state to another. The methods and systems described herein may also transform data representing physical and/or intangible items from one state to another.

The elements described and depicted herein, including in flow charts and block diagrams throughout the figures, imply logical boundaries between the elements. However, according to software or hardware engineering practices, the depicted elements and the functions thereof may be implemented on machines through computer executable media haa sender-controlled contact media content item a processor capable of executing program instructions stored thereon as a monolithic software structure, as standalone software modules, or as modules that employ external routines, code, services, and so forth, or any combination of these, and all such implementations may be within the scope of the present disclosure. Examples of such machines may include, but may not be limited to, personal digital assistants, laptops, personal computers, mobile phones, other handheld computing devices, medical equipment, wired or wireless communication devices, transducers, chips, calculators, satellites, tablet PCs, electronic books, gadgets, electronic devices, devices haa sender-controlled contact media content item artificial intelligence, computing devices, networking equipment, servers, routers and the like. Furthermore, the elements depicted in the flow chart and block diagrams or any other logical component may be implemented on a machine capable of executing program instructions. Thus, while the foregoing drawings and descriptions set forth functional aspects of the disclosed systems, no particular arrangement of software for implementing these functional aspects should be inferred from these descriptions unless explicitly stated or otherwise clear from the context. Similarly, it will be appreciated that the various steps identified and described above may be varied, and that the order of steps may be adapted to particular applications of the techniques disclosed herein. All such variations and modifications are intended to fall within the scope of this disclosure. As such, the depiction and/or description of an order for various steps should not be understood to require a particular order of execution for those steps, unless required by a particular application, or explicitly stated or otherwise clear from the context.

The methods and/or processes described above, and steps associated therewith, may be realized in hardware, software or any combination of hardware and software suitable for a particular application. The hardware may include a general-purpose computer and/or dedicated computing device or specific computing device or particular aspect or component of a specific computing device. The processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable device, along with internal and/or external memory. The processes may also, or instead, be embodied in an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It will further be appreciated that one or more of the processes may be realized as a computer executable code capable of being executed on a machine-readable medium.

The computer executable code may be created using a structured programming language such as C, an object oriented programming language such as C++, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and software, or any other machine capable of executing program instructions.

Thus, in one aspect, methods described above and combinations thereof may be embodied in computer executable code that, when executing on one or more computing devices, performs the steps thereof. In another aspect, the methods may be embodied in systems that perform the steps thereof, and may be distributed across devices in a number of ways, or all of the functionality may be integrated into a dedicated, standalone device or other hardware. In another aspect, the means for performing the steps associated with the processes described above may include any of the hardware and/or software described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

While the disclosure has been disclosed in connection with the preferred embodiments shown and described in detail, various modifications and improvements thereon will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present disclosure is not to be limited by the foregoing examples, but is to be understood in the broadest sense allowable by law.

The use of the terms “a” and “an” and “the” and similar referents in the context of describing the disclosure (especially in the context of the following claims) is to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “haa sender-controlled contact media content item,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate the disclosure and does not pose a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

While the foregoing written description enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The disclosure should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope and spirit of the disclosure.

All documents referenced herein are hereby incorporated by reference.

	Number	Date	Country
Parent	16125054	Sep 2018	US
Child	17188567		US
Parent	PCT/US2017/021120	Mar 2017	US
Child	16125054		US

LASER SCANNER WITH REAL-TIME, ONLINE EGO-MOTION ESTIMATION

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

STATEMENT OF PRIORITY

Provisional Applications (1)

Continuations (2)