Skip to content

Keep old bearing value if new one is not available#10

Open
mat02 wants to merge 1 commit into
tesla-android:mainfrom
mat02:patch-1
Open

Keep old bearing value if new one is not available#10
mat02 wants to merge 1 commit into
tesla-android:mainfrom
mat02:patch-1

Conversation

@mat02
Copy link
Copy Markdown

@mat02 mat02 commented Mar 26, 2024

By not resetting the bearing value when a new one is not available (e.g. the car is stationary so we can't calculate the bearing based on the location difference), we can avoid annoying map rotation in navigation apps like Waze or Yanosik in stop-and-go traffic.

By not resetting the bearing value when a new one is not available (e.g. the car is stationary so we can't calculate the bearing based on the location difference), we can avoid annoying map rotation in navigation apps like Waze or Yanosik in stop-and-go traffic.
@TonyHoyle
Copy link
Copy Markdown
Contributor

There will always be a bearing - there's no case in which we stop sending it - so that case won't ever get invoked.

Since speed and bearing are calculated directly from GPS, and GPS has jitter - even more so due to being processed by javascript which has no timing guarantees, they'll always be somewhat unreliable. It's the limitations of the hardware/browser.

Waze will spin around sometimes at 30mph.. It seems to get its predictions of where you're going next wrong. I'm not sure it even uses the bearing in that case - before that existed waze worked more or less the same way.

@mat02
Copy link
Copy Markdown
Author

mat02 commented Apr 4, 2024

There will always be a bearing - there's no case in which we stop sending it - so that case won't ever get invoked.

Ok, I was under impression that if the car is stationary then heading and speed is not being sent to the RPi.
Nevertheless, the problem is still relevant, because when the car is stationary, e.g. waiting for stop lights etc., then heading calculation is always 0 degress, because in estimator.js diffLon = 0 and lat1 = lat2, but this could be fixed in the estimator.js itself. What do you think?

@TonyHoyle
Copy link
Copy Markdown
Contributor

It won't be zero because jitter in the GPS reading means you'll always have sometihng.. it gets increasingly innacurate at slower speeds becauase of this.

I still don't think waze uses that value - just stop sending it and you'll find it behaves exactly as before. It only even uses speed as a visual display.. we used to just send GPS coordinate and waze worked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants