How to get one-meter location-accuracy from Android devices (Google I/O '18)

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

If I enter location “bedroom” then hue lights trigger “mood” mode.

👍︎︎ 1 👤︎︎ u/Argentibyte 📅︎︎ Jul 27 2018 🗫︎ replies
Captions
[MUSIC PLAYING] FRANK VAN DIGGELEN: We're going to show you how recent changes in hardware and standards make one meter-location accuracy possible, in some cases, as soon as this year. I'll give you a short overview now. Then Roy will introduce Wi-Fi Round Trip Time technology and standards and show you a live demo. Then Wei will explain the Wi-Fi APIs. Then I'll return and talk about new GPS technology and APIs. At the end, they'll be loading up for the next session. So we'll take questions right outside that door. And we'll be available at office hours at 1:30 PM today. So it's a great time for location applications because technology, hardware, standards, and Android API is all evolving simultaneously to enable accuracy that has not been possible previously in phones. So eventually this means high accuracy for everyone. But today we want to take you under the hood of location because we want to give you the opportunity to get a head start on the future. We also want to highlight the need to protect and respect the user. The more people who use location, the more careful we and you have to be. We'll highlight where you must get user permissions, and we'll close with some guidelines for making great location apps. So where are we today with indoor location accuracy? If you think you've noticed that your phone seems to be more accurate when you're inside shopping malls and office blocks than it was a few years ago, you're not imagining it. With each release of the Fused Location Provider, we've had steady improvement of the Android algorithms and machine learning for Wi-Fi locations. There continues to be improvement. And you'll see indoor accuracy of better than 10 meters. But Round Trip Time is the technology that will take us to the one-meter level. Meanwhile, what about GPS? Well, in terms of GPS accuracy in the open sky, there has been not much change in the last few years. If you're out in the open sky, your GPS accuracy from your phone is five meters, and that's been constant. But raw measurements, raw GNSS measurements from the phones, you can now improve on this. And with changes in satellite and receiver hardware, the improvements can become dramatic. Now, everyone's familiar with the blue dot. But to get the blue dot, you need the location provider, of course. And to get location, you need measurements, specifically range measurements from Wi-Fi access points or from GPS satellites. Today we'll show you how one-meter measurement accuracy is available in phones. The key technologies are Wi-Fi Round Trip Time, GPS dual frequency and carrier phase measurements. And we'll show you how to use accurate measurements to create accurate location. Now, if you just want to wait a year or two, this will all find its way into the worldwide ecosystem and the Fused Location Provider. But we want to give you a chance for a one-to-two-year lead by taking accurate measurements and turning them into accurate location. We want to work with you to accelerate the future, to take it and bring it closer to the present. So you might wonder, well, why do I need better location accuracy anyway? Well, let's just look at two instances where existing apps could use much better location accuracy. So for indoor routing or navigation of the kind that you're used to in your cars, you need much better accuracy than you have outdoors. You need one-meter accuracy, because indoor features, like the distance between cubes or aisles, are only a few meters. And even for the most loved outdoor applications, such as directions and especially directions in traffic, we could use higher accuracy than we have now. For example, when you came here this morning in a car, you probably had the time estimated by the average traffic speed. What you really want is the traffic speed in the lane that you're in so that you could ask, how fast would it be if I could take the carpool lane? There are, of course, many other use cases, and I'll mention a few before we finish. But the important thing is that we are sure that you will have many more ideas than we have, and that's the beauty of the Open Android ecosystem. So now here's Roy to tell you about Wi-Fi Round Trip Time. ROY WANT: Thanks, Frank. [APPLAUSE] And I'm very excited to be here today to tell you about a new positioning technology in Android P we call Wi-Fi Round Trip Time, or RTT. You'll hear me say that acronym a lot, which is basically measuring the time of flight of RF signals. It has the potential to estimate your indoor position to an accuracy of one to two meters. Now, we're going to hit the ground running today before I tell you about the details of RTT. And we're going to show you a video of indoor navigation powered by RTT. I want to emphasize, first of all, that this is not a product, but an internal prototype to explore the power of the technology and how it can also be used to support a other context-aware applications. This prototype also showcases some of the magic that Google could offer to its employees today. So we're going to roll the video. And what you should keep in mind is that this is a bit like car GPS except we're working indoors. So in a moment, you'll see there's an application. It's a mapping application. And we're searching for a conference room. We found that conference room. It's plotted the route. That's the shortest route. And now we're off. We're following the route. And as we make progress, you can see the route is turning gray. My position from RTT is the big dot. And I'm deliberately making an error here. So the system is rerouting, and it's rerouting again. If I get about 20 feet away, it starts the rerouting process. And I'm following the route. And you can see the corridor flying by. And there I'm coming in, and I've arrived at my destination, conference room Tepu. So that is the power of RTT. And the thing to think about-- [APPLAUSE] Thank you. The thing to think about here is that if you didn't have one-to-two-meter accuracy, then when that system rerouted, it would jump potentially between aisles that were surrounding me. And it would be a terrible user experience. So that's why it's so important to have this kind of accuracy. So before I get into the details of Wi-Fi RTT, I want tell you about how we calculate location indoors now. We use Wi-Fi RSSI, which stands for Received Signal Strength Indication. And basically we can calculate distance as a function of signal strength. Now, the figure that you see on the left-hand side here, the access point, which is in the center, has a heat map of signal strength. The green is the strongest, and the red is the weakest at the edges. And I've placed two phones on this diagram at the transition between the weak and the strong. Notice that the phone on the right is further away from the access point than the phone on the left, so same signal strength, different distance. And it's this variability in distance for signal strength that unfortunately makes it very hard to get accurate readings from RSSI on a regular basis. But there are lots of algorithms and tricks that we can pull to improve this, but it can be improved further. And that's where Wi-Fi RTT comes into place. So Wi-Fi RTT, Round Trip Time, it uses time of flight instead of signal strength. It measures the time it takes to send a packet, a Wi-Fi RF packet, from an access point to a phone and back again. And because radio signals travel at the same speed as visible light, if we multiply the total time by the speed of light and we divide by 2, we get distance, round trip time divided by 2. And we get the range from the phone to the access point. So that's the basic principle. Now, if you want to calculate position, we have to use a process called multilateration, and more on that in a minute. Well, the key thing to think about here is the more ranges you have, the more constraints you get, and the more accurate position you can achieve. And if you can use at least four ranges, then we think you can get typically an accuracy of one or two meters in most buildings. So why am I telling you about Wi-Fi RTT today? Why not last year or before? Well, what I want you to take away is that 2018 is the year of Wi-Fi RTT in Android. Your takeaways are that we are releasing a public API in Android P based on the IEEE 802.11mc protocol. And furthermore, we're also integrating aspects of this protocol into the Fused Location Provider, which is the main location API that people use to put a location on a map. And any time they're on RTT access points in the vicinity, the accuracy of that position will be greater. Now, a little bit of history, the 802.11 standard was ratified in 2016, the end of it. And in early 2017, the Wi-Fi Alliance started doing interop between silicon vendors to make sure the chips followed the protocol. And that's when we started doing a lot of work to validate how it could be integrated into Android. And by the fall of this year, of course, we will release the API so that all of you can now have access and build your own applications around that technology. So now diving into the principles of how Wi-Fi RTT works. So the ranging process starts with a standard Wi-Fi scan. The phone discovers the access points which are around. And based on certain bits which are set inside the beacons and the probe responses, we can figure out which of those access points are RTT capable. And the phone chooses one of those to range too, and it starts by making a request to the access point. And as a result, the access point will start a ping-pong protocol back. The ping that's sent to the phone is called an FTM, or Fine Timing Measurement packet. And the pong that's sent back to the access point is an acknowledgment of that packet. The timestamps are recorded at each end. Each device records them. But for the phone to calculate the total round trip time, it needs to have all of those timestamps. So the access point sends one more packet, a third message, which contains the missing two. The phone, then, simply calculates the round trip time by subtracting the timestamps from the AP and its own turnaround time which are the timestamps that it recorded. So that leaves the time of flight. We multiply by the speed of light to get distance. We divided by 2. And we get the range that we care about. Now, it turns out, if you do this process multiple times, you will, in fact, get more accuracy. And so that's what the protocol allows for. It allows for a burst. In Android, we're typically during a burst of about eight of these events. And as a consequence, the system can calculate statistics, so the mean and the variance, which allows us to more accurately plot a position on a map. And knowing the accuracy also allows us to calculate a path more accurately as well. So now you have ranges. How do you get a position? So I just want to give you a feel for how you go about doing this. Now, there's lots of different mathematical approaches. And I'm just picking one because it's relatively easy to explain. But this is where the power of developers comes in for you to figure out your own way to do it. So if you know a phone is at a certain range from an access point, that tells you that it can be anywhere on the circumference of a circle of that radius, the radius r. And I've written the circle equation for that circumference on the right-hand side at center, x1 y1. Now, if you want to find a position, you've got to constrain it. So if you take four ranges, the four separate access points, as shown on the diagram on the right-hand side, you then can see that if those ranges were accurate, those circles would intersect at a single point. How do you find that point programattically? Well, if you write those four equations out on the left-hand side-- you see the nasty circle equations, which may be difficult, but, in fact, it's actually very straightforward. You pick one of them. You subtract it from all the others. And you end up with a set of line equations. The squared terms disappear. And those lines are, in fact, drawn on this diagram as well. And then it's very easy to find out where two lines intersect. Now, there's one problem with what I've just told you. And the problem is that we're assuming the measurements are perfect. In reality, no measurements are perfect. Everything has error. And there will be no exact solution to that equation. So let me give you a more realistic example. So here we have several access points which we've ranged to. And I've exaggerated the problem here. And you can see, some of those circles don't intersect. How do you solve that? Well, in, fact, you do the same thing as you did before. You subtract the circles. You get the lines. But this time they don't intersect in a point. They intersect in a polygon. In this case, it's a triangle. And your phone lies probably somewhere, maximum likelihood in center of that triangle. And then we can apply some college math, least squares solution, and get a maximum likelihood. You can find standard packages which do this on the net. You can then also refine this position further by repeating this process, particularly as the phone moves, and then you can calculate trajectory and use filtering techniques like common filters and other things. So that's the basic principles. Now, like any new technology, there are challenges, and so we've experienced some of these early on. A little robot, which you can see on the right-hand side, is used by us to measure the range from the phone which it's carrying to an access point. And it validates that range against the marks, which are on the floor, which provide us with ground truth. What we find is that sometimes there's a constant range calibration offset, maybe as much as a half a meter. And sometimes also you see multi-path effects, where the known line-of-sight path from the access point to the phone is actually received rather than the line-of-sight path. That one can be solved by the vendor using something called antenna diversity. But all of these things are algorithms which the vendors are improving. And basically we need to go through a, sort of, teething process of getting rid of these bugs. And Google can help in this process by providing reference platforms and reference applications so that vendors can calibrate their own platforms before you guys even get to use them, which would be the ideal situation. Now, I've assumed that you want to start as an early adopter and start using this API. But as we move into the relatively near future, we expect you to just use the Fused Location Provider because we're going to be putting the RTT capability into it. So at the moment, Fused Location Provider uses GPS when it's available, cell, signal strength, Wi-Fi, RSSI, and also fuses with the on-board sensors inertia navigation from accelerometer and gyro. Now we're adding Wi-Fi RTT into that mix. And it will increase the accuracy whenever RTT cable access points are available. So the one other thing to remember is that when you were doing it yourself, you had to know the position of the access points. With the Fused Location Provider, we will know those positions automatically for you. We'll crowdsource those positions, and so you won't have to worry about that. And that would make life a lot easier for you to write applications. So now we're going to take it up a notch and we're going to give you a live RTT demo in collaboration with some of our colleagues in Geo. What I have over here on the podium is a phone-- let's bring it back. OK, there we go-- which is running an RTT system in combination with Google Mobile Maps. And what we're doing is we're using a number of access points, which are around the room. So a moment ago you saw the blue boxes which are on the slide. So these were provided by one of our partners. And you can see them around the room towards the back, on the side, and also a couple in the center over here. Now, the thing to bear in mind is that you would-- this phone, because we're just in a tent, would normally receive GPS signals. So we've disabled GPS. You're only using RTT with this phone. And what I'm going to do is I'm going to walk around the aisles. And you can see on this cast that I've already got a plot of where I'm going to go. So I'm going to start moving now. I'm going to start going towards the corner of the stage. And you should see the blue dot with my little man inside following me. And of course, we expect an accuracy of one to two meters. And so I'm walking on the aisle. The aisle here is about-- it's about two meters across, thereabouts. And you can see it's very nicely following within that accuracy. I think the demo environment has been very good to us so far. So we're going along. And there's a little bit of lag. It's going around the back here. And we're approaching a turnaround point, where I'm going to walk up the aisle. And we're rerouting as I come back to make my path a little bit shorter. And you can see we're going very nicely. It's still well within the one to two meters. And if you had GPS shown here as well, I mean, typically you would be expecting to see five meters. But that's, of course, outdoors. And indoors in a typical building, you're only going to have indoor location technology such as this. So now I'm approaching the corner of the stage. And at this point, I'll hand back over to Wei. Thank you very much. [APPLAUSE] Thank you. To Wei, he's going to tell you about the details of the API. WEI WANG: Hey, thanks a lot, Roy. What a great demo. So now you must be very eager to try Round Trip Time ranging yourself. Let me walk you through the RTT API in P to see how you can add RTT in your own application. So as Roy mentioned, RTT measures the round-trip time between two Wi-Fi devices. So both your mobile phone and your the access points need to support 802.11mc protocol. And as you saw, RTT can give you a very fine location, down to one meter-accuracy. So your application needs to declare access find location permission. And of course, both location and a Wi-Fi scan need to be enabled on a mobile device. OK. So how do you know whether your mobile phone supports RTT In P, we added a new system feature called Feature Wi-Fi RTT. So you can simply check whether this returns true on your mobile device. All Pixel Phones running P [? DB2 ?] and above will support RTT. So how do you know whether you access points support RTT? As normal, you will need to do a Wi-Fi scan and get a list of Wi-Fi scan results. [INAUDIBLE] run through this list of Wi-Fi scan results and check whether this method is 802.11mc [INAUDIBLE] return true. This will tell you whether the access points support RTT. So after you get a list of RTT-enabled IPs, simply add them to a scan request builder to build a scan request. RTT is done by Wi-Fi RTT Manager, which you can simply get by getting the system service Wi-Fi RTT ranging service. OK, now we're ready to start RTT ranging. By sending the RT request to the RTT Manager with a ranging result callback, RTT will start. Usually, RTT takes no more than hundreds of milliseconds. And when it finishes, you would get a list of the information, including the status, RTT [INAUDIBLE],, the MAC address, which IP you have just ranged and also, most importantly, the distance between the mobile phone and the access point. So here is the list of the information you can get from RTT Ranging Results. You can get the distance. You can also get the distance [INAUDIBLE],, deviation which is a [INAUDIBLE] deviation from multiple ranges and multiple FTMs. And you also get a number of attempted FTM measurements and number of successful measurements. So the ratio of successful measurements over attempted measurements would give you an idea of how good the Wi-Fi environment is for RTT ranging. OK. So I mentioned all Pixel devices will support RTT. How about access points? We're beginning to [INAUDIBLE] access points supporting 11mc protocol in production. And we are very excited to let you know Google Wi-Fi will soon support 11mc protocol. Thank you. [APPLAUSE] By the end of this year, off the shelf, Google Wi-Fi will have RTT enabled by default. And worldwide, we're also beginning to send the deployment of RTT IPs. South Korea is actually leading the deployment of RTT IPs. And, of course, this is just the beginning of the long journey. We're very eager to see a larger penetration rate of RTT IPs in upcoming years. With that, I'm going to hand over to Frank to talk about one meter GPS. FRANK VAN DIGGELEN: Thank you. [APPLAUSE] OK, so let's move to the great outdoors and speak about GPS. I'm going to show you some basics of GPS, just enough to explain what's new to the satellites and what's new in the phones and how you can exploit these changes to get better location accuracy from GPS when you're outdoors under open sky. So GPS works like this. It sends a code from a satellite, and the code encodes the time at the satellite. Then that travels to you through space and arrives at you. And your GPS receiver will compare that time with the time in its clock. The difference between those two tells you how far you are away. It's kind of like you have a tape measure, where one end's at the satellite. And you're holding the spool. At any moment, you can look down and read a number, which is the difference in these two times. If you move further away, you read a bigger number. If you move a little bit closer, you read a smaller number. But now the actual GPS tape measure's kind of special. First of all, it's really long. Secondly, the tick marks occur only every 300 meters because these bits of the code occur at a rate of one microsecond. So 1 microsecond times the speed of light is about 300 meters. So this is like a tape measure where instead of having all these inches on here, you only have a mark every 300 meters. And your GPS receiver essentially interpolates between those marks, and there's your five-meter accuracy. OK. But there's more to it than that, because how does that code get through space in the first place? Well, it's carried on a carrier wave, a radio wave, which for GPS has a wavelength that is less than 20 centimeters. And your GPS receiver can measure where you are on this wave. And as long as it keeps tracking it, it can measure relative motion with great precision. And this is because the receiver will measure the phase, and then as you move, that phase will change. But now what about getting your absolute location? The trouble with the carrier phase ruler, if you like, is that it's kind of like a ruler with very precise markings on it but no numbers at all, because one wavelength looks just like the next. So your receiver can tell you the phase of the wave you're on, but it doesn't know are you green dot or the red dot? So how do you solve that problem? Well, for that, you need to introduce a new concept, which is GPS reference stations. So these are GPS receivers at fixed sites measuring the same thing at the same time. They communicate that data to you. With well-known algorithms, you can combine this data. And over some period of time, you can work out where you are relative to the reference station with great precision, with this carrier phase precision. Now you know where the reference station is. So now you know where you are with great precision. So this concept is not new. This has been in commercial GPS receivers since the 1980s for surveying. Hence our little surveyor there holding the GPS antenna on the stick. What is new is the availability of these carrier phase measurements from phones and dual-frequency measurements in phones. Right now all of your smartphones, all smartphones everywhere, have GPS or GNSS on one frequency band only. It's known as L1. But there's a new frequency in town. It's called L5. And it's supported by all these GNSS systems, GPS, Galileo, BeiDou, QZSS, and IRNSS. And the availability of a second frequency means that you get much faster convergence to carrier phase accuracy if you're doing this kind of procedure. And why? Well, we just went through the ambiguity that you have on a single wave. Well, now look what happens if you introduce a second wave at a different frequency. Immediately you can disambiguate because you could not have the same phase on that second wave on both of those wavelengths. You could not be on the red dot if you were at the peak of the red wave. And so you can disambiguate and get much faster convergence to the very high accuracy that you want. All right, so what about hardware? Well, in the last few months, several companies that produce consumer GPS chips have announced the availability of dual-frequency L1, L5 GPS chips, both for the automobile market and for the phone market. And these chips are now being designed into cars and phones. Now let's talk about the measurements themselves and the APIs. The phone must support the GNSS Measurements API. And your app is going to need access find location permission and location needs to be on. So these are the basic requirements. So how do you know if a particular phone supports these measurements? Well, at a high level, you can just go to a website that we maintain, g.co/gnsstools. It's part of the Android Developers site. And there's just a table there that lists phones that support the GNSS measurements and also which characteristics they support. So it'll tell you which phone support the measurements and which of those support the carrier phase measurements. Programmatically, you do this as follows. You need a method onStatusChanged. And it will return an integer that tells you the capability of the phone, either if the phone just does not support the measurements at all, or if they support it, but location is off, or if they support it, and location is on. In that last case, you're good to go. So now let's get into some details of the APIs. The most relevant methods for what we're talking about here are the following three. There's getConstellationType, which tells you which of the different GNSS constellations a particular satellite belongs to. There's getCarrierFrequencyHertz, which tells you whether you're on the L1 or the L5 band for a particular signal. And then most importantly, there's getAccumulatedDeltaRangeMeters, which is how far along that wave the receiver has tracked you since it began tracking the signal. And then there's something else that I need to explain, which is duty cycling. So right now, when you're navigating with your phone and you see the blue dot moving along, for example, maybe when you navigated here this morning, you might think that the GPS is on continuously. And it's actually not. What's happening in the phone is that GPS will, by default, be on for a fraction of a second and then off for the remaining fraction of a second and then repeat. And this is to save battery. And so you perceive that the GPS is on all the time because the blue dot will move along continually. But actually, it's duty cycling internally. Now, for this carrier phase processing, you have to continually track the carrier wave because, remember, the carrier wave is the ruler with no numbers on it. So if the GPS was on and your receiver measured your phase and you get the data from the reference station, you'd start processing. If the GPS then goes off for a fraction of a second, well, now you've lost where you were. It'll start again. You're re-acquire. You'll be a different phase on the reacquisition. You'll start again. Well, you'll never solve the problem, [INAUDIBLE],, right? You need the tape measure to stay out, and you need to process. And to do that, you need to disable duty cycling. And you can do that in Android P with a developer option, which I'll talk about some more in a minute. So now some details of the API. What I've shown here on the right is a screenshot of an application that we've put out. It's called GNSS Logger. And this is enables you to log the raw measurements in the phone. Now, the nice thing about this app, it's a reference app. The code is open source and available to you on GitHub. So when you build your app, please, you could make use of our code. And when you do build an app that needs raw measurement, you will need the Android Location Manager API with the method registerGNSSMeas urementsCallback. And this method requires you to pass a GNSS measurements event callback, shown here. You construct this callback and then override the method onStatusChanged. And that will give you the integer status that we discussed to tell you if measurements are supported. If they are, you then override the method onGNSSMeasurementsReceived. And this allows you to receive a GNSS measurement event every epoch, for example, every second. And this event gives you the values we've been talking about, constellation type, carrier frequency, and accumulated delta range. Now for duty cycling, that's a developer option, so you access that through the Developer Page on your phone, as you see there on P. And this allows you to disable the duty cycling. Now, keep in mind, this introduces a trade-off between getting the continuous measurements and battery life. There will be an impact on battery life. How much? Well, even when GPS is on continually, it'll use less than 20% of the power that screen on uses. So that gives you a feel for the magnitude. Now, this is a developer option precisely because it's a trade-off in battery life. And we're very concerned about maximizing battery life. But if you and we together can prove that there's value in this option and people want it, then it will be upgraded to a fully supported API in the future. So here's a block diagram that shows the basic architecture that we expect if you implement an app for high accuracy. Down on the bottom of the block diagram on the left, you've got the GPS, GNSS chip. The GNSS measurements come up through the APIs, as we've just described. And then your app lives at the top in the application layer. You're going to need access to a reference network to get the data that the reference stations are tracking. There are publicly available reference networks. I've listed one down at the bottom, the International GNSS Service, igs.org. And you can get data from them free. Then you need to process that data in some kind of position library. And that does all this carrier phase processing. And that too is available as open source code. There's another example down there. Rtklib.org has an open source package for precise positioning. And then you're good to go. Now, I mentioned that dual frequency gives you a much faster convergence to the high accuracy. But you don't have to wait until the dual frequency phones come out. You can start doing this with single-frequency phones. And here's an example of someone who's already done that. This is an app created by the French Space Agency. And they're doing exactly what we show on the block diagram on the left. And they're achieving sub-meter to accuracy after a few minutes of convergence. Here's some more external analysis that's been done in a similar way. This is from a paper called "Positioning With Android GNSS." This is using one of those chips that I showed you, the chip that goes in cell phones that does dual frequency. And what's been shown here is the cumulative results over many different starts of the GPS. And what you see is that most of the time the accuracy is better than a meter. You see that on the vertical axis, which is 0 to 1 meters. And accuracy gets to better than a meter in less than one minute and then continues to converge as long as the phone continues to track that carrier phase continuously. Here's another similar but different paper. This is using one of the chips that's meant for cars. And so it was tested in a car, driving around that track there. And what the plot here is showing is the accuracy after the initial convergence while the car was driving. So you see with GNSS alone, the accuracy is 1 to 2 meters. And with this carrier phase processing, it's at a couple of decimeters. So for you to build this, what are you going to need? Well, of course you need the device location to be enabled, and your app has to have location permission. So that's going to come from the user. You need the basic GNSS measurements. That's been available since Android N. You also need this continuous carrier phase I've been talking about, and that's available in P with the developer option. It would be nice to have dual frequency for fast convergence, and that's coming soon. You need a reference network, such as the one I already mentioned. There are also commercial reference networks out there and commercially available software to do the same thing. But I recommend you start with the free stuff and go from there. And then finally, there's the app from you. So in summary, everything we've been showing you here, we have indoor and outdoor technology that's been evolving kind of in parallel, in each case, we have a new technology. And Android P gives you something to access it. Let's talk about indoors again. The new technology is Wi-Fi Round Trip Time and Round Trip Time enabled access point. We give you the public API to access these measurements. But you need access point infrastructure. Now, this is where some of you can do this this year. Because if you have a customer who owns or controls a venue, they can upgrade their access point, sometimes just a firmware upgrade. And then you have the infrastructure. Android P comes out later this year. And you can implement something like what Roy just demoed and have indoor navigation or many other apps. For example, someone goes in a store. Where's the milk? You can make the world a better place for all of us by saving us from the tyranny of having to ask directions from strangers. [APPLAUSE] OK. And if you're not one of those people who has access to this now, in a few years the infrastructure will naturally evolve as access points upgrade to Round Trip Time, and this will be available from Fused Location Provider, as Roy said. Now, outdoors, OK, for this carrier phase process, it's not just outdoors, but outdoors with open sky. And what do you need? Dual frequency and continuous carrier phase. And we give you the API and the developer option to make use of that. You will need reference station access, as I mentioned. And then applica-- well, what can you do outdoors with open sky? Well, we already mentioned the traffic example. And there's many other examples that readily come to mind where existing GPS accuracy doesn't cut it. For example, geocaching, where people go look for treasures, it would be nice to have one-meter accuracy. Precision sports monitoring-- imagine a snowboarder who wants to measure her tracks very precisely after the fact. Five meter's not good enough. One meter would be great. Speaking of sports, there are more and more drone apps where you can follow me, and a drone will fly along and video you. Well, it would be nice if it videos you and not the person next door to you. And I'm sure there are hundreds of apps, and you're probably thinking of some right now, and that's the whole point. We want you to do that and you and us together bend the arc of technology history closer to the present. And I'm really looking forward to next year to see some of you back here and see what you've created. And so finally, I want to leave you with a couple of pointers. When you build location apps, please build great location apps. You must have user trust. Please provide the user with transparency and control. You're going to have to ask for location permissions for this. Explain to them what you're doing, how it benefits them. When things go wrong, make your app recover gracefully. If these measurements are unavailable for some moment or something goes wrong, you can fall back to Fused Location Provider location. So think about that. And finally, respect the battery life trade-offs that we discussed. So I must remind you to fill out your surveys, please, at that site. And as I mentioned, we'll be available outside the door here for any questions. So from all three of us, thank you. [MUSIC PLAYING]
Info
Channel: Android Developers
Views: 57,465
Rating: 4.8050418 out of 5
Keywords: type: Conference Talk (Full production);, pr_pr: Google I/O, purpose: Educate
Id: vywGgSrGODU
Channel Id: undefined
Length: 39min 27sec (2367 seconds)
Published: Thu May 10 2018
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.