Google Maps shows car running backwards

[mishaaq]

Inserting navigation SD card causes your car to turn backwards :). Google Maps shows from now on that you are running backwards as far as you remove the nav card. After removing it the issue disappears and maps behave correctly.

[FREESCALE009]

I'm not able to produce the bug as my unit does not come with a standard Mazda Navi. It looks like the default CMU's Location Data Service process which has full control of the GPS port is being overridden or replaced with a Navi process with the bearing data rotated by 180 degrees. Here is one quick verification test, could you toggle (disable then enable) the cmu navi process while Google Maps with the opposite bearing is running ? Toggling the navi process can be done through the CMU's secret #11 3rd page Menu. This will execute a cmu script that will reset the gps port and restart the cmu location data service process. Also, i want ask if Waze is ok even with the Navi card ?

[Trevelopment]

From the reports I have heard this only happens on firmware versions in the 56.00.5XX range. @mishaaq is this accurate in your case? It does not happen to me on v55.00.753 and I have gotten reports that it does not happen on at least v59.00.441 and I think it doesn't affect all FW v59. Removing the nav card fixes the issue for everyone and waze is working fine even with the nav card for every FW as well, this only affects Google Maps..

[FREESCALE009]

That means we have to whitelist every firmware version with the bug and trigger a 180degree bearing recomputation for every firmware that is in that list. A more automatic way is to roughly compute for the bearing based on the last two captured coordinates while speed is > 0. Then use that computed bearing value to check if the spewed bearing data from the location data service process is aligned or reversed and we set a flag. The flag initialization is done only one time from the time AA is activated (gps connection established) and the speed is not 0. That flag is then used to retain or alter the bearing data from the location data service.

In the case of Waze, two things: Maybe Waze is not using the bearing data or it is possible that the bearing data is greater than 360 (not normalized) and Waze was able to normalize it and Maps treated it as is.

In short, we need actual gps values from the buggy firmware :)

[lmagder]

There is definitely something weird going on with the GPS since we started using the car's GPS. I noticed now that the old code was waiting for 500s between each timestamp, so practically we were always using the phone's GPS before....so that means we don't know if the current code is even correct at all :) On my car I would say it works like 80%, but it seems kind of jumpy. Sometimes it slides back a lot while driving on the freeway and it jumps across the street when at stoplights a bit.

I think based on the comments in the dbus xml we are using the right units, etc. although not sure about the km/hr -> knots conversion. Possibly it's wrong since the map seemed to zoom out randomly for me. Since the rest of fields are the standard NMEA units I tried just passing the km/h (plus the fixed point multipler which we know is correct). Map seemed closer to the correct zoom? dunno? I know the lat and long are right since I logged them and compared against my phone.

Also, the timestamp AA wants is in uS not seconds. We also need to check the lock status, etc. I did these changes locally but it didn't seem to make a difference. Maybe we need to poll faster than 1s interval? The accuracy seems kind of bad though 🤔

The fact that this issue exists makes me think: Is there some API the CMU Nav is using to turn on "high accuracy mode" or something, which has this bug with the reversed direction either in our code or theirs. Android itself has something like this and it might explain why the data we are getting from the DBus API seems to be not as great as I expected. It's less stable and accurate than my phone's GPS.

Any ideas for improving this in general? we might fix this issue in the process.

[FreeFrags]

I would like to confirm this issue im using the following:

• OS version in the car is 56.00.230 EU N
• Android auto version is 2.8.574514-release
• AOI version is 2.7.2

If i can help in any way please let me know

@FREESCALE009 If you let me know how to get the values you need i can try to get them for you as soon as i have time

[FREESCALE009]

@Trevelopment , is it ok to create an installer with the main.cpp's gps printf active ? Currently it is commented out. From the printf logs, it is possible to compute for the bearing based on the latitude and longitude values and quickly verify the bearing values generated by the car gps process. GPS data is read every 1 second. Logs should be captured from a moving car.

[Trevelopment]

Are you asking me to make that and have people test and report back with logs? Sure I guess I can do that in the next few days.

[mishaaq]

@Trevelopment yes, I am on 56.00.512 EU and there is no such issue when using Waze. If the bug can be observed only on 56.xx software version we should ask ourselves that is there a point fixing that instead of forcing people to update theirs CMU.

[FREESCALE009]

By the way, what if we dont send the car bearing data to the phone ? Has this been tried before on the original AA gps code ?

[FreeFrags]

Well i hope you do fix it, i'd be happy to drive around and provide you with the logs if you could tell me how to retrieve them from the car.

[davepro305]

Happens to me on 55.00.760

[FREESCALE009]

Sorry. was busy lately. will try to experiment with the reverse bearing data and reproduce the bug and try to see if the effect will go away if we comment out the bearing data. It seems waze is not using it and hoping Google Maps will simulate the heading-bearing data in the absence of an "interpolated" heading info.

[lmagder]

Could we detect the bug somehow based on CMU version or maybe by comparing the bearing to the difference in position between two readings? (assuming we can tell if the car is in reverse) Then we could just flip the bearing in our code before passing it on.

[FREESCALE009]

Ok. I tried to reproduce the bug by reversing the bearing data by 180 degrees and it seems both waze and maps ignore it - in short, the heading is still correct. My firmware is 55.xx.xx . Drove around with a reversed bearing, maps and waze are ok. I also tried commenting out passing of bearing data to AA, waze and maps both work. So it may not be the bearing value at this point but more of the sequence of coordinate data being passed to AA (probably new data goes out first then the old ones - thus the reverse arrow ?). I need logs from a firmware where the bugs really occur. My guess is that we need to scan for the gps timestamp (UtcTime) as well and check if its incrementing on every read otherwise if it is less than the previous read, data should be ignored and should not be passed to AA.

[Trevelopment]

@FREESCALE009 This may or may not help you but in the code for the MZD Speedometer App for setting the rotating compass direction there is a check for presents of a Nav SD card and if it finds one it it adds 180 to the heading like this: (jQuery)

$('.gpsCompassBG').css("transform","rotate("+(-Math.abs(currentGPShead)+180)+"deg)");

Just FYI it might help

[Trevelopment]

@FREESCALE009 This is the command I use to get that heading BTW so I think its from the same dbus socket

GPS=$(/usr/bin/dbus-send --print-reply --address=unix:path=/tmp/dbus_service_socket --type=method_call --dest=com.jci.lds.data /com/jci/lds/data com.jci.lds.data.GetPosition)
...
...
HEADING=$(echo "$GPS" | awk 'NR==7{print $2}')

also I saw that it checks for v56 to apply that so It seems like the same issue and this was the fix

[Tristan-cx5]

Hi, I also had problems with Google Maps in AA 1.07 on my 56.00.513C EU: 180-degree-reverse navigation and sometimes a fixed wrong location. Removing the SD-Card helped, but was no option for me. In AA 1.06 these problems did not occur.

Today I installed AA 1.08 from http://aa.mazdatweaks.win . Google Maps and MZD Navi are working fine now. The bugs of AA 1.07 are gone: Google Maps does not show 180-degree-reverse-navigation, no fixed wrong location and the SD-Card does not have to be removed any more. The MZD navigation is working fine, even if AA Google Maps is running in the background with connected smartphone (S7) and inserted SD-Card.

If you need some logs of AA 1.08 or AA 1.07 - I would be happy to generate and provide them (have already installed the log-tool of Trezdog44).

[Tristan-cx5]

Here are the links to my logs of 56.00.513C EU (Samsung Galaxy S7 with Android 7.0):

• Download-link to logs of probably AA 1.06 or AA 1.07 - not moving navigation or backwards arrow navigation
• Download-link to definitivly AA 1.08 - working navigation (AA Google Maps & MZD Navi - but once there was a not reproducible backwards arrow navigation)
• Link to video of backwards arrow navigation of AA 1.07. I drove forward over the bridge. Google Maps always recalculated the route.

Hopefully these logs help to identify the before mentioned GPS problem(s) (backwards arrow or fixed/not moving wrong location).

[FREESCALE009]

Ok, i was able to reproduce the reverse arrow on a git clone image used to produce V1.07 by reversing the heading data by 180 degrees before passing it to AA.. Maps arrow is reversed during the drive. Commenting out the passing of heading data to AA fixes it. Both maps and waze works.

However, on the current code version of the headunit which was used to produce V1.08 (i presume), even if i reverse the heading data, both waze and maps are ok. Same result as i reported earlier. What are the mods from V1.07 to V1.08 ?

[lmagder]

@FREESCALE009 I'm not sure exactly since I never saw the issue myself. However I did fix the units we use to pass the speed to AA from the GPS. This fixed the marker jumping around for me and also the code now enables the mode the nav system enables in the GPS driver when you insert the SD card. Not sure what it does, but figure it couldn't hurt.

[FREESCALE009]

I think that extra command on the gps control part on enabling the GPS driver on V1.08 fixes it. @Tristan-cx5 reported it to be working too with V1.08 on his firmware version with the V1.07 heading bug occurring. In the meantime, will gather more data on my setup using the latest image on the master branch.

[Tristan-cx5]

Today all four times I tested occured the backward arrow navigation with AA 1.08 on my 56.00.513C (with S7 and Android 7.0). I did not do anything else than two days before, when everything was fine.
Link to download the logs & VehDataPull of my dropbox.

Edit: I just right now saw the AA 1.08 in AIO 2.7.4 and will try the disabled car GPS option - report follows.

[FREESCALE009]

I did more tests and here is what i found out. AA is also checking the parameter "HorizontalAccuracy". Both car and phone gps is providing this data and the one with a better value is chosen for the map data. Forcing the heading data to be reversed (by adding 180 degrees) and by covering the phone (in my case my laptop), both 1.07 and 1.08 will result to a reverse arrow on Maps and normal on Waze. Commenting out the passing of heading(or bearing) data should fix this. Waze is not using the heading data as it will interpolate its own heading value based on the changes of latitude and longitude over a given time. Maps in this case, based on observation and with the absence of the heading data, it will also interpolate its own heading based on the long-lat So i see three possible fixes here, (1) Comment out the passing of heading data, (2) As @Trevelopment has pointed out, detect the firmware version and trigger the reverse heading on a given list of firmware where the bug occurs. A third (3) option is to come up with a different version of each release with the car heading available and the one commented out as an AIO selectable option.

I think by commenting out the heading data passing is a much simpler option.

[Trevelopment]

@FREESCALE009 thanks for the good ideas. I already did the third option in AIO v2.7.4 (actually commented out all car GPS data reading which has surprisingly little effect on GPS accuracy if any) but it sounds to me like you are saying commenting out the heading data for everyone won't even affect the GPS accuracy or heading data for other versions that aren't experiencing the bug and will fix the bug for those who are. Is that a safe assumption to make? If so then I think option 1 is the way to go.

[mishaaq]

I'd like to inform that the issue disappeared on current master in my case.

[FREESCALE009]

@mishaaq , probably the phone has the better gps horizontal accuracy value (lower value is better) than the car at the time of your test.

@Trevelopment, yes long-lat is still being used and has little effect on GPS accuracy if heading data is commented out/removed

[Trevelopment]

@FREESCALE009 I think the issue is fixed for most people but I am just basing that off the fact that I have not heard anything about it since I released the last version with AIO last week and when there is a problem I pretty much always get at least 20 emails about it. Also I forgot there is kind of a 4th fix for this I thought of before #96 but maybe if commenting the heeding data will have no noticeable effect we could try it anyway.

[lmagder]

@Trevelopment yeah it's possible just not passing the heading could be fine and is definitely the simplest. It just feels wrong somehow though since I am OCD about passing the "correct" data for some reason 😀

I feel like we should be able to calculate an approximate heading from a few location readings and times and then check that against the heading we are getting from the dbus call. If they are way off then we know the bug is happening and we can reverse the heading before we pass it on. I haven't actually tried this though since I'm away from my PC for the holidays and also can't repro the bug anyway.

[Trevelopment]

@lmagder I know what you mean buddy I feel the same way. I can't repro the bug either but I want it to work correctly!! haha

[wipwar]

I installed AA last night and have this issue. Read above that removing the SD card might fix it so will be doing this tonight.

OS version in the car is 56.00.513 4A N
Android auto version is 2.8.574514-release
AOI version is 2.7.4

Edit: Removed SD card, issue is gone! Maps is working correctly now.

[aidandj]

The only thing I can think of is I installed the sd card after I installed Android auto, but I have since reinstalled the fix compass tweak and Android auto multiple times. Ill try and get a build environment set up today.

[Trevelopment]

Yes it is the SD card navigation that causes this issue, removing it will fix the issue. Do you really need 2 navigation apps running at the same time?

[aidandj]

Yeah, my wife uses the Navigation and I use Android auto. Does the compass fix used for the speedo not work for Android auto.

[Trevelopment]

nope, It does not. you can just pop the SD card out and to disconnect it when using AA and pop it back in when you are done. Doing that will also improve AA performance by a lot since the navigation is the biggest memory eater in the whole system.

[aidandj]

That won't fly with her, if I forget to plug it back in I'm sure she will be annoyed. I tried to build the head unit earlier today and got some missing dbus errors. Going to try again this evening. Would like to just try disabling the heading/bearing in AA and give it a shot. Interesting that I see it in 55 though. I will do some more testing.

[Trevelopment]

Yea I have v55.00.753A NA and even with nav card I have no issues like this

[aidandj]

I wonder if it's because I installed aio before I installed the Nav card.

…

On Feb 28, 2018 3:18 PM, "Trezdog44" ***@***.***> wrote: Yea I have v55.00.753A NA and even with nav card I have no issues like this — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABdtB6XDLK4BDuYhqpodlNLMjUCid6lXks5tZd7VgaJpZM4Q14CH> .

[aidandj]

Wonder if I can easily downgrade to .753, maybe the issue started in .760. I was able to get it to build by installing dbus-c++ so I will try disabling the heading and see what happens.

[Trevelopment]

You can downgrade just make sure to read the forum posts about it because there is a specific way you need to do it I think you install the fail-safe second instead of first but again make sure to look it up and follow the instructions from people who have done that before.

[aidandj]

I dug around in the code some more and reversed the heading, going to give that a shot as soon as the car gets home. I'll update here if it works out.

[aidandj]

Maybe a stupid question, but where can I read the printf statements. Is there a log saved somewhere that I can access by SSH or something similar?

[aidandj]

One last question. Do I have to use the installer every time. Or can I copy a compiled headunit binary to the car directly.

[Trevelopment]

the log is at /data/headunit.log you can also view it by tapping the textbox in the AA intro screen just open AA from the app menu without your phone connected and yes, you can just swap out the binary.

[aidandj]

This fixed the issue completely.

location->set_latitude(static_cast<int32_t>(data.latitude * 1E7));
location->set_longitude(static_cast<int32_t>(data.longitude * 1E7));

double dataReversed = data.heading + 180;
if (dataReversed >= 360)
{
        dataReversed = dataReversed - 360;
}

location->set_bearing(static_cast<int32_t>(dataReversed * 1E6));

[Trevelopment]

Yes but we have to be sure to either A. only apply that on certain FW versions and only when the NAV SD card is connected or B. have 2 separate builds and let people decide for themselves whereas if they ever want to remove or connect their NAV SD card they will have to reinstall AA to fix the issue. The problem with A is that we are now finding out for the first time that FW v55.00.760 is effected by this when before it was only v56 (also I am not sure if it is all v56 or only up to a certain version) but other than that it is most likely the proper thing to do. I'm not really a C++ wiz but I do know you can easily get the version from show_version.sh script. I wouldn't know how to check that the Nav SD card is connected but probably just checking for /tmp/mnt/sd_nav/ or maybe one more folder deep like /tmp/mnt/sd_nav/content/ would be sufficient for that.

[aidandj]

I'm halfway decent at c++, I'll see what I can do about nav sd plugged in. As far as version, I saw you were looking into adding a config file, so you could add the option to flip heading based on the config file, and let the user set it.

Either way thanks for the help. Even if there is no perfect solution for everyone I've got my setup working.

[Trevelopment]

Nice, I forgot about the config file solution. Most people are content with my disabled-car-gps solution for now but I could just swap that out with your modded build and its essentially the same result right.

[aidandj]

Yeah, I will try and do a Navi card check.

…

On Mar 1, 2018 5:40 AM, "Trezdog44" ***@***.***> wrote: Nice, I forgot about the config file solution. Most people are content with my disabled-car-gps solution for now but I could just swap that out with your modded build and its essentially the same result right. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABdtB8vuUaXFokNFUTGKrO9tj2QJoYvsks5tZ_pAgaJpZM4Q14CH> .

[aidandj]

Tested this on my way to work. Can plug and unplug the nav sd card. Takes a few seconds for things to get flipped around, but then they work correctly. Still needs a way to either parse the version (questionable, because we don't know exactly which versions have this issue), or a selectable config. For now I will continue building my own.

https://github.com/gartnera/headunit/pull/123/files

PS this project is awesome, I love it. Let me know if you need anymore help on things, or if there are any pressing issues I can look into.

[hansaya]

Im not in favor of removing car GPS functionality. In some scenarios and for some people's phone GPS is useless. Car GPS has a high gain antenna compared to phone gps. I would recommend adding a configuration option and let people chose. I would agree that new phones do have better GPU units built in and has better accuracy but that does not matter when you driving in a very dense city and you are not getting a GPS lock.

[ddavidebor]

I have this issue too, but it appears almost random. For now it seems to appear if i plug in the phone before the bluetooth has completed syncing contacts and stuff.

[Wxfisch]

I had this issue this evening on v55 firmware with the nav card plugged in. I will check tomorrow whether running without the nav card fixes it for me. I do agree with hansaya though that the cars gps should be used if at all possible, to me that is a huge advantage of AA since the car has a better high gain antenna than my phone, additionaly because the USB port in the car does not provide enough power to charge my phone, anything that can help reduce battery usage is welcome. As actually using the GPS in the phone drastically increases battery usage this is a big negative in my eyes. I would be fine with a config option.

[emyarod]

@Wxfisch did running without the nav card resolve the issue?

[matthewpetersen]

Observation from user (non dev) on V56 (which is the latest avail for Australian cars): when using 1.06 Beta with reversed compass heading, GPS reception drops in and out often. GPS reception with car nav system is fine, GPS system with maps native on the phone fine. Just fails when using Maps in Android Auto. Note though: if you're not in Maps for a little while (say, in music player) and you come BACK to Maps, it shows you in exactly the right spot. But if you stay in maps, the GPS reception is lost, the screen rotates 180degrees as reception is lost and gained and lost again. Is there somewhere I could set a flag to use the phone GPS when attached to Android Auto?

[Wxfisch]

That does fix it, and I am on v56 for NA. However it seems as though Waze does not have the issue if it is opened first, so could it be something in Maps that is setting the direction?

I would still really prefer a fix for this that does not disable the cars GPS antenna, very often my phone gets poor GPS reception when my car is fine while in the city (buildings, overpasses, tunnels, etc.)

[emyarod]

so I'm on v55 NA and didn't remove the nav card. I did install AA 1.09 beta though, which seems to have fixed the issue for me

[ConX]

I am also having the issue described here, on a 2016 Mazda6 GT, v55.00.753 NA N with AA v1.10, installed using mzd-aio v2.8.1.

I believe a config option that allows you to add the 180-degree offset and correct the bearing during installation or when the AA is used would be a great solution.

[Trevelopment]

hey @ConX that config file does exist now! in the AIO installer you will find it in config/androidautowifi/headunit.json and you can probably figure it out from there (change "reverseGPS" to true)
and come to think of it, that means this issue is solved right?