Switch from getCurrentPosition Polling to watchPosition

[ladyisatis]

I've been running a customized web/android.html that uses watchPosition instead of polling getCurrentPosition, and would this make a good pull request?

So, with the polling option, there's a lot of lag in fetching locations in which using Maps or Waze will sometimes go backwards and re-route, the speedometer will randomly go between 60 km/h and 120 km/h when the speed is a constant 100 km/h, etc. With the latest Tesla update, there'd been a lot more GPS lag with the browser. I think this is how much time it would take to retrieve the current position, whereas watchPosition will hook to the Tesla system itself.

Heading/Speed might not be provided on Chromium or Firefox engines (and is only updated once per second on iOS and Android) but Tesla seems to have come up with some custom way to hook any changes to the location to information from the car, and will fetch heading the same way it will on Tesla's navigation maps. Speed will also come from the speedometer. (I did leave in the GPS estimator code just in case.)

Running this on a 2020 Tesla Model Y (MCU2), using Browser Audio for Spotify + using Waze, I've had zero issues and zero lag whatsoever: ladyisatis/tesla-android-flutter-app@c93d898

If you want to also test out the raw stats and how often it updates, make a gps.html on an HTTPS site with this code and open in the Tesla browser, then go for a drive:

Latitude: <strong><span id="lat"></span></strong><br />
Longitude: <strong><span id="lon"></span></strong><br />
Altitude: <strong><span id="alt"></span></strong><br />
Accuracy: <strong><span id="acc"></span></strong><br />
Altitude Accuracy: <strong><span id="alac"></span></strong><br />
Heading: <strong><span id="hea"></span></strong><br />
Speed: <strong><span id="spe"></span></strong><br />
Last Update: <strong><span id="t"></span></strong>
<script type="text/javascript">
let pos = null;
window.addEventListener('load', () => {
    console.log('load');
    pos = navigator.geolocation.watchPosition((position) => {
        //if(!position.coords) return;
        document.getElementById('lat').innerText = '' + position.coords.latitude + '';
        document.getElementById('lon').innerText = '' + position.coords.longitude + '';
        if(position.coords.speed !== null) document.getElementById('spe').innerText = '' + position.coords.speed + '';
        document.getElementById('alt').innerText = '' + position.coords.altitude + '';
        document.getElementById('acc').innerText = '' + position.coords.accuracy + '';
        document.getElementById('alac').innerText = '' + position.coords.altitudeAccuracy + '';
        if(position.coords.heading) document.getElementById('hea').innerText = '' + position.coords.heading + '';
        document.getElementById('t').innerText = '' + position.timestamp + '';
    });
});
window.addEventListener('beforeunload', () => {
    navigator.geolocation.clearWatch(pos);
});
</script>

[mikegapinski]

Great idea! Submit the PR and I'll get it merged with the next update.

The current solution was developed last year and it was the only approach that worked reliably back then. It looks like Tesla made some changes in the browser recently - heading was not provided before.

I'll be also including a hardware GNSS in the upcoming Tesla Android bundle refresh. It'll also give us RTC on top of improved location tracking. Browser GPS will become a fallback on the CM4 and it'll be mostly utilised by the RPI4/FOSS users. It feels like a right thing to do, Tesla used to mess up browser GPS in multiple updates and it lead to crashes.

I am also going to retire the HTML viewer this year (if I get accepted for FlutterCon US it'll happen by September). I think we can gain a lot of performance with a WASM frontend app.

[ladyisatis]

PR submitted! Will be interesting to see the hardware GNSS solution - is that via an addon module?