Ensuring the accuracy of vehicle locations is essential for facilitating a seamless and efficient user experience on the Uber platform. Inaccurate pickup and dropoff locations can result in poor estimated times of arrival (ETAs), difficulty for riders in locating their driver, or wasted time for drivers.
To calculate vehicle location, our platform uses Global Navigation Satellite System (GNSS) signals coming from the receiver on the driver’s phone. Given the diversity of phones that drivers use globally, there is a wide variation in the quality of data from these receivers. In fact, even the best receivers perform poorly in downtown areas and other urban canyons because of GNSS RF signal reflections from buildings, or in tunnels and stacked roads where GNSS coverage may be absent.
With these issues in mind, Uber built beacon, a piece of hardware that features a GNSS receiver, accelerometer and gyroscope, otherwise called inertial measurement units (IMUs), and barometer sensors. Signals from these sensors can be fused together with the GNSS signal to provide better location quality compared to the pure GNSS-based location from the driver’s phone. In urban canyon environments, GNSS location can be quite erroneous, and so IMUs provide an additional measurement of vehicle acceleration and turn rate that can reduce this error. Altitude information from the barometer can be used to further improve location by providing an additional vertical measurement.
GNSS and sensors on smartphones
Smartphones feature a wide range of available sensors, but nearly all contain a GNSS chipset and an accelerometer. In fact, almost 95 percent of smartphones used by Uber driver-partners in the US feature a gyroscope, but only about 60 percent have a barometer. The lack of a barometer and sensor fusion performance inconsistencies can affect driver location accuracy during the rider pickup and dropoff experience.
Operating systems can also affect these experiences. While some operating systems leverage map matching (primarily relying on road networks) to specify locations, making it difficult for some devices to attain location accuracy, others provide non-map matched location data that enables further location accuracy with advanced technologies like shadow matching.
Enhancing location quality with beacon
Most drivers keep their phones on a dashboard mount in their cars, and may take the phone off the mount and put it back on throughout the course of a series of trips.
Beacon, on the other hand, is firmly mounted on the driver’s dashboard and is rarely moved during the driver experience. Therefore, it can help improve confidence in the location of the vehicle compared to a driver’s phone.
On Android phones, satellite data, like signal-to-noise ratio (SNR), can be used to further improve location accuracy using algorithms like Uber’s shadow matching. This information is not available on iOS phones. For phones that run iOS, beacon sends this data to phones over a Bluetooth link, enabling an implementation of shadow matching on iOS as well.
In addition, raw GNSS measurements (e.g., pseudorange and pseudorange rate) on Android 7 or higher phones make an advanced sensor fusion implementation possible. This technique is superior to the sensor fusion version that uses latitude and longitude, which are available on all Android phones. Beacon can send raw GNSS measurements to all phones, enabling this superior sensor fusion implementation.
Assessing GNSS, sensors, and signals of interest
Together, GNSS and sensors work in beacon to calculate accurate location estimates. Below, we assess each component of this equation.
GNSS receivers measure location, velocity, and associated uncertainties. These measurements can be represented as
Position, , comprises latitude, longitude, and altitude. The noise,, is Gaussian noise , , with zero mean and covariance. Velocity,, is calculated across these three dimensions as well. The noise,, is Gaussian noise , with zero mean and covariance , The uncertainties imply that the associated signal is within uncertainty value with 68 percent confidence. and are represented in the World Geodetic System (WGS84) frame.
The receiver also gives raw GNSS measurements, called pseudorange,, and pseudorange rate,,that can be used to estimate position and velocity. Pseudorange measures the distance between a satellite and the receiver, while the pseudorange rate measures the doppler frequency as a function of vehicle speed.
In addition to and, shadow matching uses satellite SNR, azimuth, and elevation from the GNSS receiver to better determine location in urban areas where satellite signals become occluded by building.
Beacon’s more accurate location not only makes it easier for drivers and riders to find each other but also improves ETA accuracy and stability. These are some of the key factors that improve the pickup and dropoff experiences for both riders and drivers.
An accelerometer is used to measure acceleration along x, y, and z axes of the sensor. Its measurement is represented as whereis measured acceleration, is linear acceleration, is gravity,is bias, and is Gaussian noise. is the signal of interest for navigation and is used to predict speed and position between two GNSS samples, a prediction commonly called dead reckoning. Gravity and bias should be continuously estimated and removed from to get a good estimate ofdue to the fact that gravity depends on sensor orientation that can change over time and bias changes over time and temperature.
There are some other impairments like sensitivity error and non-linearity that are not considered because their impact is much smaller compared to estimation error in gravity and bias. Sensitivity is the scale factor for the observed acceleration, which ideally should be one. Error in sensitivity can result in its value being slightly different from one. Any deviation from linear input-output relationship is called non-linearity.
Beacon uses this accelerometer measurement for dead reckoning between GPS points and to smooth sudden location jumps that are typical of GNSS behavior in urban canyon areas. Sudden location jumps that require acceleration much higher than that observed by the accelerometer are filtered, thereby providing smooth location.
Beacon’s gyroscope measures turn rate along x, y, and z axes of the sensor. Its measurement is represented aswhere is the measured turn rate, is actual turn rate, is bias, and is Gaussian noise. is the signal of interest for navigation and is used to derive heading changes. Heading is defined as the angle of the vehicle direction of motion from North. The bias is estimated and removed from to attain an accurate estimate of. The bias changes over time and temperature. Similar to the accelerometer, the effect of sensitivity error and non-linearity is ignored for the gyroscope.
Gyroscope measurement is used for dead reckoning between GPS points and smoothing the GNSS receiver’s heading computation. Sudden heading changes in GNSS measurement that are not consistent with gyroscope measurement are filtered, thereby providing a smoothed heading.
A barometer measures ambient pressure. Beacon’s barometer features root mean square noise of about 1Pa, corresponding to 8 cm in altitude resolution.
Figure 1, below, shows a barometer reading during a trip in San Francisco:
This graph demonstrates a high correlation between the barometer reading and the fused altitude estimated by the highly accurate GNSS reference sensor, NovAtel SPAN. The altitude measured by the barometer is helpful when satellite coverage is poor. Beacon’s barometer measurement can be thought of as another satellite measurement that is directly above the receiver position, further improving beacon’s location estimate.
Bringing sensors together: GNSS/IMU/barometer fusion
By combining GNSS, IMU, and barometer signals, beacon can leverage sensor fusion to calculate more accurate locations on our platform. (For a more detailed description of how to implement sensor fusion, check out Loose and Tight GNSS/INS Integrations: Comparison of Performance Assessed in Real Urban Scenarios, from Falco, Pini, and Marucco.) However, to achieve this accuracy, signals must be fused from GNSS, IMU, and the barometer in a common reference frame.
Accelerometer and gyroscope measurements are in the sensor frame that aligns with the 3 axes of these sensors. We assume that both accelerometer and gyroscope axes are perfectly aligned. Sensor frame is different from the navigation frame in which user position and velocity are expressed. Earth-centered, earth-fixed (ECEF) is used as the navigation frame to represent our location in reference to Earth. Using the gyroscope, measured user acceleration is transformed into the navigation frame and used in position computation.
There are multiple sensor fusion architectures based on the type of GNSS measurements used. Most popular ones are loosely coupled and tightly coupled. In loosely coupled architecture, GNSS position and velocity are used as measurements to a navigation filter that does the fusion. The advantage of this approach is its ease of implementation. Tight coupling uses satellite pseudo-range and pseudo-range rates as inputs to the navigation filter directly. The benefit from tight coupling is that a full GNSS solution needing at least four satellite measurements is not necessary. This is critical in difficult GNSS environments like urban canyons and, hence, used in beacon.
This fusion solution described above is improved by using additional motion constraints. During regular vehicle motion, it is reasonable to assume that the vehicle does not slide sideways or jump upwards. In addition, barometer measurements can be used to constrain altitude in the navigation filter. These constraints along with the fact that the beacon is firmly mounted on the car help us avoid position errors even during periods of limited or zero satellite visibility.
Improved driver location using sensor fusion
Beacon’s use of sensor fusion results in improved location accuracy of pickup and dropoff spots for users worldwide. These improvements are particularly helpful in areas with poor GPS by providing a more accurate location and heading.
Tunnels provide strong examples of GNSS-deprived areas. If raw GNSS location is used for vehicle positioning inside a tunnel, it will stay stuck at the start of the tunnel till the driver exits the tunnel. Figure 2, below, shows improved location coverage in San Francisco’s Broadway tunnel with sensor fusion on beacon:
Above, green dots are raw GNSS output and red dots are the output from sensor fusion. It can be clearly seen that fusion with IMU enables dead reckoning during the GNSS outage.
Urban canyons are well known for imprecise and erroneous GNSS. In some cases, the GNSS location can have errors of more than 100 meters. Figure 3, below, shows GNSS location with green dots that have up to 10 meters of error, causing the location to be on the wrong side of the street and running through a built-up area. Fused output from beacon, shown with red dots, reduces these errors noticeably.
Beacon’s robust sensor suite improves driver location on the Uber platform, offering a number of benefits. It makes in-app navigation for our driver-partners better, helping them get to pickup and dropoff locations conveniently. Riders benefit from getting a more accurate picture of their driver’s location, along with a more accurate ETA.
Beacon also creates a common location reference point usable by different types of phones, such as Android and iOS, ensuring that the user’s own phone is not a limitation when using the Uber platform.
Interested in working on large-scale mobile or geospatial positioning projects? Our team is constantly working on improvements and always looking for talented and highly motivated individuals to build these solutions at scale. Apply for a role in our group as an Android engineer or a back-end engineer!
Hemabh Shekhar is a technical lead manger on Uber's Sensing & Perception team.
Vivek Sankaravadivel is a senior software engineer on Uber's Sensing & Perception team.
Posted by Hemabh Shekhar, Vivek Sankaravadivel
Selective Column Reduction for DataLake Storage Cost Efficiency
September 20 / Global
CheckEnv: Fast Detection of RPC Calls Between Environments Powered by Graphs
September 13 / Global