Robust odometric architecture and methodology

Abstract

A vehicle includes a plurality of sensors and one or more control units collectively programmed to perform the following instructions: estimating the odometry of the vehicle based on sensor data from the plurality of sensors to generate a plurality of odometry estimates; monitoring the integrity of one or more of the sensors; correcting the sensor data from one or more of the plurality of sensors to provide corrected sensor data; compensating the corrected sensor data to provide compensated data; and using the compensated data to provide at least one of the following information: vehicle odometry, vehicle conditions, and timestamp information.

Description

[0001] This description refers to the area of ​​odometry for vehicles.

[0002] A robust odometry estimation system will be useful in conjunction with various vehicle functions, including autonomous or semi-autonomous driving and autonomous parking.

[0003] DE 10 2014 211 180 A1 describes a method for improved detection and / or compensation of error values. Measured values ​​are recorded by a sensor system. The measured values ​​describe physical quantities. The measured values ​​contain error values ​​that describe deviations of the measured values ​​from the described physical quantities. The error values ​​are detected and / or compensated by means of a comparison, and measured values ​​that exceed a limit value are not used to detect and / or compensate for error values ​​of other measured values.

[0004] US 2021 / 0 325 544 A1 describes systems and methods for monitoring the integrity of odometry measurements within a navigation system. A system includes imaging sensors that generate image frames from optical inputs. The system also includes a GNSS receiver that provides pseudorange measurements and computing devices that receive the image frames and the pseudorange measurements. Furthermore, the computing devices calculate odometry data from image data acquired at different times and calculate a complete solution for the system based on the pseudorange measurements and the odometry data. Furthermore, the computing devices calculate partial solutions for the system based on subsets of the pseudorange measurements and the odometry information. One of the partial solutions is not based on the odometry information.In addition, the computing device determines the integrity of the pseudorange measurements, the odometer information, and a position estimated by the navigation system based on a comparison of the full and partial solutions.

[0005] US 2023 / 0 062 898 A1 describes a method for integrity monitoring for visual odometry, comprising acquiring a first image at a first time epoch using stereo vision sensors, acquiring a second image at a second time epoch, and extracting features from the images. Temporal feature matching is performed to match the extracted features. A boundary discriminator is used for feature mismatch. A range or depth restoration process is performed to enable stereo feature matching between two images acquired by the stereo vision sensors at the same time epoch. A range error bounding discriminator is used. An outlier suppression process is performed using a modified RANSAC technique to limit moving events.The magnitude of the feature error and the error probabilities are characterized using cross-domain Gaussian models. A state vector estimation process with integrity checking is performed using solution separation to determine rotation and translation changes between images, determine error statistics, detect errors, and calculate the protection level or integrity risk.

[0006] US 2023 / 0 053 629 A1 describes a method for determining the position of a vehicle, in which highly precise localization data for the vehicle's positions are determined while driving along a route. Odometric measurements for the vehicle's own odometry are recorded while driving along the route. The determined highly precise localization data and the recorded odometric measurements are evaluated together. Based on the evaluation, the vehicle's own odometry is corrected. Using an error model, a vehicle-specific drift for the vehicle's own odometry is calculated, and the vehicle's own odometry is continuously corrected, provided highly precise localization data can be determined. The corrected vehicle's own odometry can then be used to determine the vehicle's position in areas where highly precise localization data cannot be determined.

[0007] To understand the functions of the claimed vehicle, a method is described below that includes the steps corresponding to the functions of the claimed vehicle. The odometry method is provided by one or more control units for a vehicle traveling on one wheel, the wheel having a wheel rotation sensor that provides pulses with the rotation of the wheel, and the vehicle having an inertial measurement unit ("IMU"). The method includes estimating the odometry of the vehicle to provide odometry data based at least in part on the sensor data from the wheel rotation sensor.Additionally, the method includes correcting sensor data from the wheel rotation sensor to provide corrected data by one or more of the following: upon a confirmed stop of the vehicle, using data from a sensor other than the wheel rotation sensor to correct the sensor data; compensating for missing pulses from the wheel rotation sensor by integrating past IMU data in a stop-to-move scenario of the vehicle to compensate for the missing pulses; compensating for drift in sensor data from the wheel rotation sensor by using a past position of the wheel as a current position of the wheel in a move-to-stop scenario of the vehicle from move to stop; and compensating for latency between wheel speed calculations made using pulses from the wheel speed sensor using a transformation matrix.

[0008] In the odometry method, the confirmed stop can be confirmed by a vehicle's gear indicator, for example, by the gear indicator indicating that the vehicle is in a parking gear. The other sensor can be the IMU.

[0009] To understand the functions of the claimed vehicle, a second method is described below, which includes the steps corresponding to the functions of the claimed vehicle. The second odometry method is provided by one or more control units for a vehicle. The second odometry method includes estimating the odometry of the vehicle based on sensor data from a plurality of sensors to generate a plurality of odometry estimates.The method also includes processing the sensor data to provide processed sensor data by one or more of the following methods: compensating to prevent calculation inaccuracy by adjusting a first position origin for the vehicle maintained in the one or more control units; compensating to prevent calculation inaccuracy by adjusting a second position origin provided by the one or more control units to external users of the odometry; and adjusting an operating mode of the odometry method and a relative odometry output from the odometry method based on a predetermined number of past states of the odometry method and a current state.The method also includes using the processed sensor data to provide at least one of vehicle odometry, vehicle states, and timestamps as outputs from the one or more control units.

[0010] The second odometry method can use floating-point numbers to estimate the vehicle's odometry. These floating-point numbers can also be 32-bit single-precision numbers.

[0011] The invention is defined by the main claim.

[0012] According to the invention, a vehicle comprising an odometry system is provided. The vehicle includes a plurality of sensors. The vehicle also includes one or more control units collectively programmed to perform the following instructions: estimating an odometry of the vehicle based on sensor data from the plurality of sensors to generate a plurality of odometry estimates, monitoring an integrity of one or more of the plurality of sensors, correcting sensor data from one or more of the plurality of sensors to provide corrected sensor data, compensating the corrected sensor data to provide compensated data, and using the compensated data to provide at least one of vehicle odometry, vehicle conditions, and timestamp information. The vehicle is traveling on one wheel. A rotational position sensor detects rotation of the wheel by providing pulses as the wheel rotates.The vehicle has an inertial measurement unit (IMU). The instruction to correct data from one or more of the sensors includes an instruction to compensate for missing pulses from the rotational position sensor by integrating past IMU data during a vehicle stop-to-move scenario to compensate for the missing pulses.

[0013] According to one embodiment, the instruction to monitor the integrity of the one or more sensors comprises an instruction to monitor one or more sensors for sensor errors.

[0014] According to another embodiment, the instruction to monitor the integrity of the one or more sensors comprises an instruction to check the convergence of the plurality of odometry estimates.

[0015] According to another embodiment, the instruction to monitor the integrity of the one or more sensors includes an instruction to check for outliers in the plurality of odometry estimates.

[0016] According to a further embodiment, the instruction to monitor an integrity of the one or more sensors comprises an instruction to check a rationality of estimates of the longitudinal and lateral velocity of the vehicle.

[0017] According to another embodiment, the instruction to monitor the integrity of the one or more sensors includes an instruction to check a rationality of estimates of the yaw rate of the vehicle.

[0018] According to another embodiment, the vehicle travels on one wheel. A rotational position sensor provides rotational position data of the wheel. The instruction to correct the data from one or more of the sensors includes using data from a sensor other than the wheel rotation sensor to confirm the vehicle's odometry upon a confirmed vehicle stop. The other sensor may be an IMU.

[0019] According to another embodiment, a rotational position sensor detects wheel rotation by providing pulses upon wheel rotation. Additionally, the vehicle may have an IMU. The instruction to correct data from one or more sensors may include the instruction to compensate for missing wheel rotation sensor pulses by integrating past IMU data in a stop-to-move scenario to compensate for the missing pulses.

[0020] According to another embodiment, a rotational position sensor in the vehicle provides rotational position data of the wheel. The instruction to correct the data from one or more sensors may include the instruction to compensate for drift in the wheel speed sensor data by using a previous position of the wheel as the current position of the wheel in a move-to-stop scenario of the vehicle.

[0021] According to a further embodiment, in the vehicle, the instruction to correct the data from one or more sensors also includes the instruction to compensate for a latency between the wheel speed calculations performed with the wheel speed sensor pulses using a transformation matrix.

[0022] According to another embodiment, the instruction to arbitrate and compensate the corrected data further comprises compensating in the vehicle to prevent inaccuracy in a floating-point calculation by adjusting an internal position origin of the vehicle maintained in one or more control units. The instruction to arbitrate and compensate the corrected data may additionally or alternatively include an instruction to adjust an external position origin to compensate for rollover.

[0023] According to another embodiment, the odometry estimates comprise relative odometry estimates, and the instruction for arbitrating and compensating the corrected data comprises an instruction for setting an odometry operating mode and a relative odometry output based on a predetermined number of previous states of the odometry and a current state of the odometry. Fig. 1 shows a vehicle with a distance estimation system. Fig. 2 illustrates the system for estimating the distance measurement of Fig. 1. Fig. 3 shows a sensor integrity monitoring of the odometry estimation system of Fig. 2. Fig. Figure 4 illustrates a routine for setting the reference frame for the odometry estimation system of Fig. 2.

[0024] This description may be embodied in many different forms. Representative examples of the description are illustrated in the drawings and are described in detail herein as non-limiting examples of the principles disclosed. To this end, elements and limitations described in the "Summary," "Introduction," "Summary," and "Detailed Description" sections, but not expressly recited in the claims, should not be incorporated into the claims, individually or collectively, by implication, inference, or otherwise.

[0025] For the purposes of this description, the use of the singular includes the plural and vice versa, unless expressly excluded; the terms "and" and "or" apply both in the subjunctive and disjunctive moods; "each" and "all" mean "each and all," and the words "including," "comprising," "comprising," "with," and the like mean "including without limitation." Furthermore, words of approximation such as "approximately," "almost," "substantially," "generally," "about," etc., may be used herein to mean "at, near, or almost at," or "within 0-5% of," or "within acceptable manufacturing tolerances," or logical combinations thereof.

[0026] See first Fig.1. There, a vehicle 10 is depicted. The vehicle 10 may be any type of vehicle, for example, a car, a truck, a van, a sport utility vehicle, a motorcycle, a scooter, a bicycle, or another vehicle. The vehicle 10 may be an electric vehicle, a vehicle with an internal combustion engine, or a hybrid vehicle with a powertrain comprising one or more electric motors and an internal combustion engine. The vehicle 10 may be driven manually, autonomously, or semi-autonomously. The vehicle 10 may have autonomous driving functions, such as automatic parking. The vehicle 10 may be equipped with an odometry estimation system 12 (see also Fig.2) be equipped to measure and / or estimate the distance traveled by the vehicle 10, both in absolute terms (i.e., the distance traveled from an initial location) and in relative terms (i.e., the incremental distance traveled from one or more previous locations). The vehicle 10 may travel on one or more wheels, for example, four wheels, which may include the wheel 14 and the wheel 16.

[0027] For the purposes of this description, the term "odometry" may refer to the estimation or measurement of the distance traveled by the vehicle 10. It may be a two-dimensional distance traveled. It may also be a distance traveled in both the forward and reverse directions relative to the front of the vehicle 10. It may be a distance traveled relative to an absolute origin, in which case the distance measurement may be referred to as an "absolute distance measurement." Further, "relative odometry" may mean the incremental distance traveled relative to one or more previous positions of the vehicle 10, rather than relative to an absolute origin.

[0028] The odometry estimation system 12 may include one or more electronic control units (ECUs), such as ECU 100. ECU 100 may be a microprocessor-based control unit and should be understood to have the electronic resources (microcontrollers, software, memory, inputs, outputs, circuitry, and the like) to perform the functions attributed to ECU 100 in this description. The functions described in this description may also be distributed among one or more electronic control units in the vehicle 10, which may be interconnected by data buses and / or hard wiring and may therefore share data and computational responsibilities.

[0029] Because the ECU 100 and other control units in the vehicle 10 may be microprocessor-based devices, they may operate based on instructions; these instructions may include one or more programmed software commands. Furthermore, some or all of these instructions may include additional instructions or software commands.

[0030] Inputs to ECU 100 may include inertial measurement unit (“IMU”) 102. IMU 102 may measure longitudinal and lateral acceleration with respect to the x- and y-axes, as well as yaw rate with respect to the z-axis, of vehicle 10. Inputs to ECU 100 may include one or more wheel speed (i.e., wheel rotational position) or wheel velocity sensors, such as wheel encoders 104; one such encoder may be provided for each wheel of vehicle 10. Wheel encoders 104 may generate pulses as the wheels of vehicle 10 rotate, which may be used to measure or calculate the distance traveled by the wheels of vehicle 10, such as wheel 14 and wheel 16. The speeds of the wheels may be calculated by integrating the pulse rate generated by the encoders.The term "wheel speed" used in this specification may refer to either the rotational speed of a wheel or the linear speed of the outer circumference of the wheel on the wheel; the speeds are directly related to the radius of the wheel and, as such, may be essentially interchangeable for the purposes of this specification.

[0031] Inputs to ECU 100 may also include one or more steering sensors 106, which detect the angle to which the vehicle's steering wheel is turned or the angles to which the wheels of vehicle 10, such as wheel 14 and / or wheel 16, are steered. Another input to ECU 100 may be one or more engine speed sensors 108, which provide the speed of the engine or motors powering vehicle 10. Inputs to ECU 100 may also include a transmission state sensor 110. Transmission state sensor 110 may detect whether vehicle 10 is in park (and thus not moving) or not in park. The transmission condition sensor 110 may also sense which out-of-park gear the vehicle 10 is in to understand the speed relationship between the motors powering the vehicle 10 and the speeds of the wheels of the vehicle 10.

[0032] The inputs of the control unit 100 may also include TCP (“Transmission Control Protocol”) 112, a GPS sensor input that may provide the three-dimensional position of the vehicle 10.

[0033] The above-mentioned inputs to the ECU 100 may be used in an odometry estimation system 12, which may estimate or measure the distance traveled by the vehicle 10 through a series of algorithms that utilize the inputs to the ECU 100. For example, wheel encoders 104 may be used to detect the distance traveled by the vehicle 10, while steering sensors 106 may be used to detect the contour of the path of the vehicle 10. The IMU 102 may also be used as an alternative or additional mechanism for determining the distance traveled by the vehicle 10 (for example, by double integrating the longitudinal and / or lateral acceleration of the vehicle 10). TCP 112 may provide an alternative or additional means for measuring the position of the vehicle 10 and the distance traveled.

[0034] Since high-precision odometry can be important, particularly in semi-autonomous or autonomous driving or parking, certain additional processing of the calculated odometry data may be desirable. Such additional processing may include functions performed in block 122 (sensor correction) and block 124 (compensation), each of which is described in more detail below.

[0035] Next, the odometry transformation 126 occurs. The odometry transformation may involve converting data received at various parts of the vehicle (e.g., the wheels) into the center of gravity of the vehicle 10. This may then result in outputs from the ECU 100 that may include vehicle odometry 128, vehicle states 130, and timestamps 132.

[0036] An integrity monitor 150 can check the integrity of the sensors input to the ECU 100. In addition to Fig.3, the integrity monitor 150 may include block 152, a sensor fault test block. This may include tests to determine the basic functionality of the respective sensors, for example, whether they output any voltages and / or signals at all, or whether they output voltages and / or signals that are within an appropriate range for the sensors. A sensor failure may also manifest itself in the sensor outputting a diagnostic, error, or trouble code indicating that the sensor has failed.

[0037] If it is determined that one or more sensors have failed, the algorithm proceeds to update the fault by marking the fault mode in block 154 (Update Fault Mode).

[0038] If no sensor(s) failure was detected in block 152, the algorithm proceeds to the aforementioned block 120 to calculate odometry estimates for the vehicle 10. These may then be subjected to statistical testing in any or all of blocks 156, 158, 160, 162, and 164 to draw further conclusions about the reliability of the data received from the sensors. In block 156 (convergence), a determination is made as to whether a sufficient number of consistent or convergent updates to the odometer estimate have been received to conclude that the sensor data is likely to be reliable. In block 158 (outlier detection), outliers may be identified, for example, through chi-square tests, to determine whether the sensor data is likely to be sound or whether a subset of inconsistent data is merely an outlier.

[0039] In Block 160 ( vx→ and vy→ Rationality) Several tests can be performed regarding the rationality of the estimated longitudinal and lateral speed of the vehicle 10. For example, a cross-check can be performed between the detected or counted wheel sensor pulses and the calculated wheel speeds for the individual wheels. The consistency between the data for the individual wheels, for example, the detected or counted wheel sensor pulses and the calculated wheel speeds, can also be checked. Furthermore, the estimated speed of the vehicle 10 can be compared with the speeds calculated from the data from the individual wheel encoders / sensors.In addition, the estimated lateral velocity of the vehicle 10 may be compared to the lateral velocity calculated from differences in wheel speeds (for example, between the outside and inside wheels when cornering) and / or the lateral velocity of the vehicle (calculated from the lateral acceleration of IMU 102).

[0040] In Block 162 ( ωz→ Rationality) A test for the rationality of the yaw rate of the vehicle 10 can be performed. For example, a comparison can be made between the steering angle of the steering wheel of the vehicle 10 or the steering angles of one or more wheels of the vehicle 10, on the one hand, and the difference in wheel speeds between radially inner and radially outer wheels ("radially inner" and "radially outer" with respect to a curve on which the vehicle 10 may be traveling), on the other hand. If this comparison is inconsistent, it can be determined that one or more sensors are suspect.

[0041] For clarity, when used as a geometric variable in this description, “x” refers to a longitudinal axis (front to rear), “y” to a transverse axis (side to side), and “z” to a vertical axis relative to the vehicle 10.

[0042] In block 164 (Noise Covariance Check OK?), a measurement noise covariance check is used to determine whether the sensor measurements are suspicious.

[0043] If the tests in any of blocks 156, 158, 160, 162, or 164 result in NO (i.e., the respective statistical test in that block is suspect), the algorithm can proceed to block 154 to update the failure mode. Conversely, if the tests in all blocks result in YES, indicating that the sensors appear to be providing reasonable data, the system's operating mode can be updated in block 166.

[0044] Next, block 122 (sensor correction) may be performed. (When block 122 is executed, one or more of blocks 122a, 122b, 122c, and 122d may be executed.) The sensor correction may include block 122a (speed-based sensor source update). Here, it has been observed that when using wheel speed as an input, a latency-related error pattern may occur in the estimated distance traveled by the vehicle 10; this may occur above a predetermined speed. The predetermined speed may be a crawl speed, below which the vehicle and wheels are considered to be "crawling"; this may be two meters per second. The predetermined speed may also be half a meter per second, one meter per second, or three meters per second.Below this speed, where the distance traveled by vehicle 10 is measured not by wheel speed but by wheel pulses, the latency may not be present. Furthermore, latency may occur when vehicle 10 is moving to a standstill because the distance traveled between wheel sensor pulses may not be known for highly accurate odometry. Similar inaccuracies may occur during a stop-to-move operation. Errors may accumulate as a result of multiple vehicle maneuvers, for example, during an automatic parking maneuver. In block 122a, the errors may be corrected by using alternative sensor data to correct the sensor data that may have been subject to an accumulated error.For example, previous IMU data that captured the motion of the vehicle 10 may be used to correct the accumulated odometry error, for example, by double integrating the acceleration of the vehicle 10; this correction may occur when the vehicle 10 is confirmed to be at rest or when it is confirmed to have stopped, for example, by the shift state sensor 110 indicating that the vehicle 10 is in park.

[0045] Block 122 (sensor correction) may also include block 122b (missing pulse compensation), which may be used in a stop-to-move scenario of the vehicle 10. Assume that an observation model for the distance traveled by a wheel of the vehicle 10 may look like this: dwhl(ts,tc)=∫tstcuwhl(t)dt=2πRtireNΔn(ts,tc), where d whl is the distance that the outer circumference of the wheel travels on the wheel from time ts until time t c travels, u whl is the linear speed of the outer circumference of the wheel, R tire is the radius of the wheel, N is the number of teeth of the wheel encoder, and Δn (t s , t c ) is the number of tooth pulses between time t s and time t c .

[0046] t sis unknown for the first update after the vehicle 10 has stopped. There is a delay in the standstill indication because the standstill is only derived after the absence of pulses from the respective wheel sensor, i.e., after the absence of a pulse. (There is no wheel sensor pulse data that definitively indicates the time at which the vehicle 10 came to a stop.) During this time, false zero-speed observations may be used. Therefore, this error condition can be corrected during a stop-to-move detection by integrating past IMU data to determine the position of the vehicle 10. The start time of the integration can be assumed to be the time of the last wheel edge detected by the standstill detection logic. This can result in a lookback of half a second or a similar period.

[0047] Block 122 (Sensor Correction) may also include block 122c (Drift Compensation) in a move-to-stop scenario for stopping vehicle 10. When vehicle 10 stops, there may be a delay in indicating that vehicle 10 is stationary; there are no additional wheel encoder edge counts to be certain that vehicle 10 has stopped. At some point, vehicle 10 is assumed to have stopped if no further wheel encoder edge counts are available. Estimating the stop state could be done solely by integrating the acceleration data from IMU 102, but this may result in a rapid accumulation of position errors. To compensate for these errors, the following calculations can be used: ux=x(tstop)−x(tcurrent) and uy=y(tstop)−y(tcurrent).

[0048] u x and u ycan be considered as corrections to the x and y positions of vehicle 10, which can be used to compensate for the drift. In the above equations, t stop be the assumed time at which the vehicle 10 stopped, and t current the current time. The x and y positions at time t current can be taken from a buffer containing the last positions of the vehicle 10. A look back into the buffer of several hundred milliseconds, for example 500 milliseconds, can be used, an unlimited example based on the minimum speed to be detected.

[0049] Correcting inaccuracies caused by the aforementioned stop-to-move and move-to-stop scenarios (latency in classifying and declassifying vehicle 10 as stationary) may be important in certain scenarios involving repeated such events. One such scenario could be automatic parking.

[0050] Block 122 (Sensor Correction) may also include block 122d (Sensor Latency Compensation) to compensate for the wheel speed (integrated by the wheel encoders) used to measure wheel travel. The problem is that the state of the vehicle 10 should be known at the current time, but the wheel speed measurements may have been taken several milliseconds ago. To compensate for this, a transformation matrix can be used that relates the current time to the previous observation time, as follows: Φ(tz,t)≈I−∑i|tz <ti≤tF(ti)dt δz(tz)=H(tz)δx(tz)+v=H(tz)Φ(tz,t)δx(t)+v =H(tz,t)δx(t)+v, where Φ (t z , t) is the transformation matrix; I is the identity matrix; F(t i ) is a dynamic matrix; t is the current time; t z an earlier observation time; δz(t Z ) error states are (the measurement matrix transforms the δx), δx(t z ) Error states are (measured states - estimated states), H is a measurement matrix that relates the observable (z) to the value to be estimated; and v is the measurement noise (an unknown).

[0051] After block 122 (sensor correction), block 124 (compensation) may be performed. (When block 124 is executed, one or more of blocks 124a, 124b, 124c, and 124d may be executed.) Block 124 may include processing, which may include block 124a (floating-point compensation). Here, the continuous operation of the vehicle odometry could potentially lead to a degradation of accuracy, as in certain implementations, it relies on a 32-bit single-precision floating-point variable. This loss of accuracy can cause problems both internally in the vehicle odometry estimation process and externally when the vehicle position is communicated from the odometry estimation system 12 to downstream systems, such as automated or semi-automated driving or parking systems that utilize vehicle odometry data.

[0052] The estimated position of the vehicle 10 can be based on the integration of the vehicle speed: p(t)=∫0tv(t)dt≈p(t−Δt)+v(t)Δt=p(t−Δt)+Δp(t), where p is the position; and v is the speed.

[0053] Assume that the minimum speed of vehicle 10 of interest is 1 mm / s, and the calculation in control unit 100 runs with a period of 10 ms. In these examples, the smallest position increment to be considered is: Δp(t)=v(t)Δt=1 mm / s⋅10 msec=0.01 mm

[0054] When the position reaches a value of 100 meters for the parameters in this example, a loss of accuracy or precision may occur. This can be explained by the nature of a 32-bit single-precision floating-point number. Such a number has only about seven decimal places of accuracy. The larger the integer part of the number, the less room remains for floating-point precision. When the integer part reaches 100 meters, the accuracy of the decimal part drops to 0.008 mm (~0.01 mm).

[0055] Therefore, in order to avoid calculation inaccuracies in the odometry estimation, the internal reference origin maintained in the ECU 100 for the position of the vehicle 10 can be shifted (i.e., updated) every 100 meters as follows: pinner(t)=pinner(t−Δt)+Δp(t) |pintern|<100 meters p=p0+pinternal, where p internalthe position used for internal calculations, p is the final position, and p0 is the previous position before resetting.

[0056] Block 124 (compensation) may also include block 124b (rollover compensation). External "consumers" of odometry information from the odometry estimation system 12, such as autonomous or semi-autonomous parking or driving systems, may (as an example only) not be interested in a positional accuracy of greater than, say, 1 mm (whereas an accuracy of 0.01 mm may be pursued internally, as discussed above in connection with block 124a). Since, in this example, the smallest step size external consumers might be interested in is 1 mm, the floating-point accuracy issue for these users may arise every 10 km. Therefore, the reference origin provided to these users may (again, as an example only) be reset every 10 km.This sudden change can cause problems for these users, including those calculating relative odometry (i.e., a delta between a position and one or more previous positions), unless a compensation mechanism is provided. This compensation mechanism can be implemented in block 124b (rollover compensation). There, an odometry buffer can be maintained as follows: RelativeTime Odometry buffer 0 O O O O O 1 O O O O N 2 O O O N N 3 O O N N N 4 O N N N N 5 N N N N N

[0057] Until the buffer is completely filled with position data for the vehicle 10 with respect to the new reference frame relative to the new origin (N), the ECU 100 makes the data available to external consumers with corrections between the old origin (O) and the new origin to prevent the odometry data used by these external consumers from drastically jumping due to the reference change. Once the buffer is filled with all data of the new reference frame relative to the new origin (for example, at a relative time = 5 in the table above), such corrections can be adjusted.

[0058] Relative vehicle odometry relies on a prior number of samples to correctly calculate the distance traveled. For the most useful relative odometry, all samples could come from a single source of algorithms. To enable smooth transitions between states, the following state transitions can be used in block 124c (state transition): States output Previous NState(s) Current status Operating mode relative odometry output Normal operation Normal operation Normal operation estimate Normal operation Sensor fault Sensor fault Default value Normal operation Non-sensor error Remedial measures Estimation of remedial measures Sensor fault Normal operation Not converged Default value Sensor fault Sensor fault Sensor fault Default value Sensor fault Non-sensor error Not converged Default value Non-sensor error Normal operation Remedial measures Estimation of remedial measures Non-sensor error Sensor fault Sensor fault Default value Non-sensor error Non-sensor error Remedial measures Estimation of remedial measures

[0059] In the table above, Normal Operation means the normal operation of the system; Sensor error refers to a detected error of a relevant sensor (see block 152, Fig. 2); Non-sensor error means that a statistical anomaly has been detected (see block 156, block 158, block 160, block 162 and block 164, Fig. 2); Estimate means that an estimate of the relative odometry is used, corresponding to the normal operation of the system, which may include block 122 and / or block 124 ( Fig. 2); Default value is a default value that can be selected by the system designer; Non-consistent means that the conditions for the initial and current odometry measurements do not match, so that the relative odometry may not be reliably calculated; and Remedial estimation means that a simple sensor integration can be used for odometry estimation without compensation via block 122 and block 124.

[0060] The relative odometry output for downstream users can follow the Relative Odometry Output column for each of the conditions in the table above.

[0061] Block 124 (compensation) may also include block 124d (reference frame adjustment); see also Fig.4. There, in block 300, it is determined whether the internal cumulative threshold has been exceeded. If YES, the internal reference frame is updated in block 302 (see also block 124a ( Fig. 2)). In block 304, it is then determined whether the external cumulative threshold has been exceeded. If YES, the external reference frame is updated in block 306 and the position buffer is updated in block 308 (see also block 124b ( Fig. 2)). In block 310, it is then determined whether an external rollover has occurred. If YES, in block 312, the last position of vehicle 10 is updated and made the new starting point for the position of vehicle 10. If NO, the routine continues with block 314.

[0062] In block 314, it is then determined whether the buffer is filled with the new origin. If YES, the relative odometry can be calculated in block 316, assuming the buffer is filled with data related to a common origin. If NO, the positions are updated in block 318 with the new origin based on the last position before the external rollover. The relative odometry can then be calculated in block 318 and made available to the systems that consume / use this relative odometry.

[0063] As in Fig.As shown in Figure 2, after block 122 (sensor correction) and block 124 (compensation), block 126 (odometry transformation) may be performed. The output for downstream users of the odometry information processed by the odometry estimation system 12 may be the vehicle odometry 128, vehicle states 130, and timestamps 132. The vehicle states 130 may include the yaw rate, vehicle speed, and vehicle accelerations (lateral and longitudinal) of the vehicle 10.

[0064] Embodiments according to the present description can have many advantages. The disclosed architecture can seamlessly switch between different measurement sources to provide continuous and stable odometry data. The architecture can provide accumulated odometry data over a long period of time. The disclosed methodology is robust against the limitation of single-precision and floating-point numbers, which can lead to accumulated errors over a long period of time, which can cause accuracy problems during fine, low-speed maneuvers after a long drive. The architecture and methodology described here can provide robust odometry even in the presence of sensor errors and possible statistical errors. The architecture and methodology can also adapt the odometry data upon reference frame reset.The architecture and methodology can also provide vehicle states and odometry along with timestamps to eliminate potential latency between states and odometry when used by downstream users.

Claims

[1] Vehicle (10) comprising an odometry system (12), the odometry system (12) comprising: a variety of sensors; and one or more control units (100) which are jointly programmed to execute the following instructions: Estimating an odometry of the vehicle (10) based on sensor data from the plurality of sensors to generate a plurality of odometry estimates; monitoring an integrity (150) of one or more of the plurality of sensors; Correcting sensor data from one or more of the plurality of sensors to provide corrected sensor data; Compensating the corrected sensor data to provide compensated data; and Using the compensated data to provide at least one of the following information: vehicle odometry (128), vehicle states (130) and timestamps (132); wherein the vehicle (10) travels on one wheel (14, 16); a rotational position sensor (104) detects rotation of the wheel (14, 16) by providing pulses upon rotation of the wheel (14, 16); the vehicle (10) has an inertial measurement unit, IMU (102); and the instruction to correct data from one or more of the sensors comprises an instruction to compensate for missing pulses from the rotational position sensor (104) by integrating past IMU data in a stop-to-move scenario of the vehicle (10) to compensate for the missing pulses. [2] The vehicle (10) of claim 1, wherein the instruction to monitor the integrity of one or more of the plurality of sensors (150) comprises an instruction to check a rationality of estimates of the yaw rate of the vehicle (10). [3] Vehicle (10) according to claim 1, wherein: the vehicle (10) travels on one wheel (14, 16); a rotational position sensor (104) provides rotational position data of the wheel (14, 16); and the instruction to correct data from the one or more sensors after a confirmed stop of the vehicle (10) comprises using data from a sensor other than the rotational position sensor (104) to confirm the odometry of the vehicle (10). [4] Vehicle (10) according to claim 1, wherein: the vehicle (10) travels on one wheel (14, 16); a rotational position sensor (104) provides rotational position data of the wheel (14, 16); and the instruction to correct data from one or more of the plurality of sensors comprises an instruction to compensate for drift in the rotational position data, in a move-to-stop scenario of the vehicle (10), using a previous position of the wheel (14, 16) as a current position of the wheel (14, 16). [5] Vehicle (10) according to claim 1, wherein: the vehicle (10) travels on one wheel (14, 16); a rotational position sensor (104) provides rotational position data of the wheel (14, 16); and the instruction to correct data from one or more of the plurality of sensors comprises an instruction to compensate for a latency between performed wheel speed calculations using the rotational position data and using a transformation matrix. [6] The vehicle (10) of claim 1, wherein the instruction to compensate for the corrected data comprises compensating to prevent inaccuracy in a floating point calculation by adjusting an internal position origin of the vehicle (10) maintained in one or more control units (100). [7] The vehicle (10) of claim 1, wherein the instruction to compensate for the corrected data further comprises an instruction to adjust an external position origin of the vehicle (10) provided by the one or more control units (100) to external users of the vehicle odometry. [8] Vehicle (10) according to claim 1, wherein: the odometry estimates include relative odometry estimates; and the instruction to compensate for the corrected data comprises an instruction to adjust an odometry operating mode and a relative odometry output based on a predetermined number of previous states of the odometry system (12) and a current state of the odometry system (12). [9] Vehicle (10) according to claim 3, wherein: the confirmed stop can be confirmed by means of a gear indicator of the vehicle (10) indicating that the vehicle (10) is in a parking gear; and the other sensor is an IMU (102).

Images