Android Auto Feedback

[Samuel-ABRP]

We don't get car gps, as already mentioned earlier. Android does not offer that data. Telemetry data is not updated often enough to be used in navigation. So the only source currently usable is the GPS of the phone.

There are however feature requests open at google, to get access to that data. So once it's available we will also use it.

[FptNate]

I may be blind, but there doesn't seem to be a "Skip Waypoint" feature in the main app or the AA Beta. Right now all I can do is stop navigation, delete all visited waypoints, replan, and then restart navigation.

This feature is available in routes planned with Google Maps and it is very useful when you've technically hit a waypoint, but the GPS has not, preventing the waypoint from automatically being marked as visited. This situation generally occurs when the waypoint is in the middle of the building or the wrong location in a shopping plaza.

[maexxx]

3 hours ago, Samuel-ABRP said:

So the only source currently usable is the GPS of the phone.

OK, but what's the difference then in switching the "overwrite car position" toggle on and off in the car configuration in ABRP? This phone would be the only one used anyway while running ABRP on AA.

[Samuel-ABRP]

We have no control of how the telemetry apps handle the gps data from the phone. We got reports, that for some people this fixed position update issues.

If that does not help, it might also help to disable battery saver options as some phones (we know of Xiaomi and some Samsung) restrict gps updates when the app is not in foreground (for example when AA is running with phone screen off).

If you want to compare the GPS accuracy with other apps, you should compare to non google apps, as they have the same location restrictions in AA as we have. Google might get more data that other app developers do not have access to.

[Aristodemos]

On 4/7/2021 at 10:29 PM, Aristodemos said:

ABRP Beta doesn't start with Android Auto 6.2.610914-release in my 2020 Nissan Leaf.

 

 

I occasionally still have this problem. The workaround is to open ABRP directly in the phone and then open in the car.

[maexxx]

26 minutes ago, Samuel-ABRP said:

We have no control of how the telemetry apps handle the gps data from the phone.

OK, I get that the API doesn't allow you much choice, and I also understand about power saving settings in Android which can kill location info for apps in the background or when screen is off.

I still don't understand what ABRP does different on AA if I toggle the "use phone location" setting on or off. Does it pass that to an API call? Does it use different API calls? Does it handle things differently internally?

 

Quote

If you want to compare the GPS accuracy with other apps, you should compare to non google apps, as they have the same location restrictions in AA as we have.

Yes I get that. You are right, I'll try comparing it to another 3rd party app next time.

It's a sad fact that Google places lots of restrictions on 3rd party apps while their own apps do many of those forbidden things. In Google Maps I can scroll and zoom the map; they can show many more settings and information, they can use vector maps etc. -- I absolutely feel for you. I am not blaming ABRP for the lack of this functionality (I read the AA developer API docs), and I really hope constant feedback to Google will get them to open up some of these restrictions.

For example, it is stupid that I cannot tap on a charger nearby on the map and select "go there" (or scroll around and zoom to find a charger). Instead, due to Google restrictions, I have to go to a different app to find charging stations nearby and then select there that I want to navigate to it etc. They claim they want to prevent driver distraction, but actually their rules make it harder for the driver to achieve what the driver wants, and require many more taps.

I'll stop ranting now, but feel free to pass my comment on to Google.

[Samuel-ABRP]

Well, AA for navigation was just introduced recently. There are feature requests to get gps data from car and they were not closed immediately, so there is still hope that stuff like that will come eventually.

About the other question you asked, I'm not 100% sure myself what happens here, as I'm not familiar with that code, but i heard from a few people already that position was more stable, so I would assume that it is still used sometimes.

But then again it might really be just bad GPS signal and google gets a better one from the car. In that case try to mount the phone closer to the windows.

[davidtm]

I would like the opportunity to choose between several route options on the mobile app. (If that is available, I'm not seeing it. Please redirect me.) When I do deviate from the established route to a known alternative route, the attempts to redirect to the original route are overly persistent, at least as compared to Google Maps.

 

As others have said, Thank you! for this awesome app!

[maexxx]

On 5/13/2021 at 7:54 PM, Samuel-ABRP said:

About the other question you asked, I'm not 100% sure myself what happens here, as I'm not familiar with that code, but i heard from a few people already that position was more stable, so I would assume that it is still used sometimes.

OK, I turned the setting on and did a few drives. GPS position has been flawlessly so far. So I really think something in the code of ABRP messes up the location with this combination:

• Setting "override with phone location" is OFF
• EVNotify sends car data to ABRP servers
• Phone is plugged in to Android Auto

I think if you're on AA, then position should always be either the GPS from the headunit (best, if that's made available from AA), or the phone that's connected to AA. I suspect that under certain conditions it currently uses a different source, and that messes up things.

 

[Samuel-ABRP]

That telemetry GPS issue is not AA specific, but i guess it makes sense to check that again. Thanks.

[kristgy]

First, I want to thank the ABRP team for creating this important service. By reducing the hassle of electric vehicle ownership, you speed the transition from fossil fuel powered transportation.

I have been running the ABRP Android Auto beta for a few weeks and share some thoughts below.

My configuration:
Car: Hyundai Ioniq 2019 (28 kWh battery).
Head-unit model: AEAE.S5ALN.EU
Head-unit software version: AE_EV.EUR.SOP.008.1.191209
Head-unit firmware: AE_EV.EUR.0.5.352.191031.MICOM
Mobile phones: Google Pixel 2 XL (Android 10) and Google Pixel 4a (Android 11).
ODB-II dongle: “kungfuren OBD2 Bluetooth 4.0 Adaptor” ordered from amazon.de:
https://www.amazon.de/gp/product/B07PLDC2SC/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
Telemetry app: EV Notify (latest beta version, currently 2.2.1):
https://play.google.com/store/apps/details?id=com.evnotify.app

General remarks:
ABRP adds a lot of value to my aging BEV, by providing route planning on a level only found in the most recent top-of-the-segment cars. The upcoming Android Auto (AA) release has the potential to significantly improve the ABRP in-car user experience. However, the current AA beta does not address my use case very well. Judging by the previous comments of the ABRP developers in this thread, I realize that this is probably due to the restrictions Google currently places on the AA apps it allows on the Play Store. Nonetheless, I describe briefly below what I would value in ABRP on AA.

The greatest value of ABRP to me is the advanced BEV route-planning, that is the capability to factor in all the details that are important to an optimal BEV route, such as current state of charge (SoC), charging curves of different EV models, availability and power delivery of chargers, outdoor temperature, wind, route topography, etc. Turn-by-turn navigation of the planned route is less important, given the sophistication of the free Google Maps turn-by-turn navigation software available on AA. Thus, the focus of ABRP on AA should be in-car route planning, follow-up, and updating.

Ideally then, ABRP on AA would have an interface for planning a route from the head-unit before departure, visual follow up of route progress (SoC vs distance) during driving, warnings if route is no longer valid, and a button for handing-off an updated route to Google Maps. A killer feature would be if ABRP would continuously monitor the availability of chargers at the planned stops and automatically reroute to the nearest free charger, in case the planed one would be occupied upon arrival.

For ABRP on AA to deliver its full value, live SoC is essential. My current solution relying on a third party OBD dongle and telemetry app is workable but took quite some effort to set up and can easily be derailed by a bug in an update of the telemetry software or a failure of my OBD dongle. It also requires careful sequencing of the start-up of the various parts. This is too intricate for most users. For live SoC to work smoothly, ABRP needs direct access to SoC from the head-unit.

Specific remarks on current ABRP AA implementation:

The current SoC indicator is of limited value since it is not obvious by looking at it if the value is up to date. There needs to be a visual indication of where the value came from (live from telemetry app or assumed starting SoC) and in case of live SoC, if the value is current (not older than a few minutes).

The current interface for planning new routes on the head-unit is very limiting. The interface would benefit greatly from better history, more favourites, the possibility of adding and removing stops, etc. All the options available in the phone app.

The inability to interact with the map during navigation is also a severe limitation. I often pan and zoom out to review a route during turn-by-turn navigation with Google Maps, for example during a red light stop.

Visually, I much like the map rendering on the ABRP AA beta. It is much more detailed than Google Maps, but probably that intentional on Google’s part, to minimize distractions. However, the reliance of ABRP on OpenStreetMap is risky. I have witnessed first-hand how a small mistake by an OpenStreetMap volunteer derailed the navigation of routes entering Stockholm from the north.

 

Looking forward to following the continued development ABRP on AA.

[KOAL]

 

Hello, I want to say thank you to the ABRP team, you do the planning so much better than anyone else. (for EV cars) THANKS!

I still have a few things on my wish list.  Is there an area where we can put our wishes?

1.) I only see the oldest 6 routes in Android Auto, as soon as I create a 7 route I first have to delete an old one. Why is that?
Is that a premium feature?
If yes then I'll buy it right away.

2.) State of charge point is free. (not even Tesla)

3.) In a planned route I always set an alternative charging point, can you please incorporate the function that we can skip waypoints in the active route.

4.) Radar detectors and other danger spots would be very nice.

5.) 3D view would be cool too.

6.) Display of how far away from the target, how far from the waypoint. Arrival times.


many thanks

KOAL

[Samuel-ABRP]

1) that's a restriction we get from google. The distraction should be kept to a minimum, so we are only allowed to show a few entries.

[KOAL]

Aha, thanks for the quick reply.

Can I then rearrange the routes so that the newest is always at the top? I don't want to delete my old routes. (I like to have this as a reminder)

[Samuel-ABRP]

You can reorder them in the Android app in the saved plans overview. They should appear in the same order in AA.

[kristgy]

Consistent crash on non-viable route

I have identified an edge case that consistently crashes ABRP on AA.

For some reason, my telemetry app (EV Notify) reported an erroneously low SoC at the end of a trip. The next time I used ABRP on AA, I didn't turn on my OBD-II dongle so the erroneous SoC was used to plan a new route. After a bit of driving, a dialog box popped up on the head-unit reporting: "This plan is no longer viable. Tap to view alternatives." (see attached photo of the head-unit). When I tap to view alternatives, ABRP AA crashes without presenting any alternative routes (see attached photo of the head-unit).

I have tested this a few days now and the crash occurs consistently on my way to work, while on my way home from work ABRP comes up with an alternative route with one charge stop on the way. My theory is that on my way to work there is no viable alternative route, given the very low SoC, and in that edge case ABRP on AA crashes.

Details of my configuration below:

ABRP beta version: 4.0.42
Car: Hyundai Ioniq 2019 (28 kWh battery).
Head-unit model: AEAE.S5ALN.EU
Head-unit software version: AE_EV.EUR.SOP.008.1.191209
Head-unit firmware: AE_EV.EUR.0.5.352.191031.MICOM
Mobile phones: Google Pixel 2 XL (Android 10) and Google Pixel 4a (Android 11).
OBD-II dongle: “kungfuren OBD2 Bluetooth 4.0 Adaptor” ordered from amazon.de:
https://www.amazon.de/gp/product/B07PLDC2SC/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
Telemetry app: EV Notify (latest beta version, currently 2.2.1):
https://play.google.com/store/apps/details?id=com.evnotify.app

[storm96]

Hey,

thank you for your amassing work!

Firstly, like some of the commentators before, i would love to be able to see the graphs while driving.
I hope google will allow it at some point.

Another small figure i would like if it were implmented is the car name and the configuration is visible while planing and easily changeable, much like in the App.
It's really annoying if your traveling with a bike rack and you've planed without one.

[Samuel-ABRP]

On 5/21/2021 at 9:28 AM, kristgy said:

Consistent crash on non-viable route

I have identified an edge case that consistently crashes ABRP on AA.

For some reason, my telemetry app (EV Notify) reported an erroneously low SoC at the end of a trip. The next time I used ABRP on AA, I didn't turn on my OBD-II dongle so the erroneous SoC was used to plan a new route. After a bit of driving, a dialog box popped up on the head-unit reporting: "This plan is no longer viable. Tap to view alternatives." (see attached photo of the head-unit). When I tap to view alternatives, ABRP AA crashes without presenting any alternative routes (see attached photo of the head-unit).

I have tested this a few days now and the crash occurs consistently on my way to work, while on my way home from work ABRP comes up with an alternative route with one charge stop on the way. My theory is that on my way to work there is no viable alternative route, given the very low SoC, and in that edge case ABRP on AA crashes.

Details of my configuration below:

ABRP beta version: 4.0.42
Car: Hyundai Ioniq 2019 (28 kWh battery).
Head-unit model: AEAE.S5ALN.EU
Head-unit software version: AE_EV.EUR.SOP.008.1.191209
Head-unit firmware: AE_EV.EUR.0.5.352.191031.MICOM
Mobile phones: Google Pixel 2 XL (Android 10) and Google Pixel 4a (Android 11).
OBD-II dongle: “kungfuren OBD2 Bluetooth 4.0 Adaptor” ordered from amazon.de:
https://www.amazon.de/gp/product/B07PLDC2SC/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
Telemetry app: EV Notify (latest beta version, currently 2.2.1):
https://play.google.com/store/apps/details?id=com.evnotify.app

We are currently reworking the alternative routes feature. We will also fix that crash with our reworking. Still i would recommend to wait for live data to be available in the meantime. That would always be the recommended way, as you might want to adjust the route on the phone as well which would then immediately be overridden by replanning and end up in a route you did not want. If however you just want the carefree driving support then i agree that this should work as well when starting with low soc that is updated within a few minutes. We are working on that.

[Samuel-ABRP]

I'm pretty pessimistic, that google will allow the graph. I drive with ABRP for AA quite a while now and I have to say after a few drives i don't miss the graph at all. If you watch the arrival soc (which is also adjusted during drive like the graph) you can also react pretty fast on changes to drive faster or slower. Try it out and you will get used to it pretty fast. Of course if we get the chance to also show the graph we will do it.

[ThomasW]

Thank you to all of the ABRP team to make this extremely useful tool work on AA.

I am driving a Renault Zoe R110ZE50 built end of 2020. ABRP is running on a Samsung Galaxy A40 with Android 11. When I run ABRP on AA, navigation is calculated correctly and during the driving the street name display and voice commands are given correctly. Only the map on the car's multimedia screen is not moving at all, it stays at the first shown position. Mostly the exact route is not marked blue. If the route has to be replanned, the map jumps to the new current position but will never move away from that.

I think it will be hard work to handle all those different output platforms and their specific behaviour, but maybe you will find the reason for this freeze.

Thanks a lot.

Edited May 23, 2021 by ThomasW
typo

[davidtm]

I attempted a fairly simple trip today with 2 waypoints. The first leg went well, though I realized I had no way of telling ABRP that I arrived in order to be ready for the next leg. It seems that ABRP knew, but didn't offer enough info to assure me that it did.

Also, I got a notification of a route change. When I tapped on it, things went haywire. I had to ditch the whole route after the second waypoint a and resort to the Home option to return home.

Btw, I am now a fan of OSM!

Edited May 23, 2021 by davidtm

[dudule]

 I am testing the ABRP AAndroid since almost three weeks, I must say it's a fantastic app (thats we I have
become a premium user) - despite some restrictions e.g. max number of routes limites by 6.....I wonder if
it isn't possible to have an address book where the driver has access to - but only when the car isn't running ???
Hence it should not be a security issue anymore.....

In the meantime i have found in german forum an app which allows to get SOC live date fm an OBD  Dongle,
transmit them to the ABRP Server and within a short time I can see SOC live data on ABRP AAndroid - including
a predicted arrival SOC - and which fits !! Even so it's a beta version I am really convinced as to this function -
Therefor I don't even need e.g. EVNotify anymore. But the app could be even better in case the battery life data are
sent directly the ABRP AAndroid without passing via the ABRP server. (It is to some extent unbelievable that in some
cars the SOC data are availible - e.g. KIA e-Niro - but the build-in navigation system doesn't make use of it)

Do you have any ideas in this context to grant an direct access to ABRP AutoAndroid ?

[Brian D]

Using 4.0.42 (502) and seeing issues in the past week or so where the app is logging me out during a stop en route. It's also losing "Override Car Position" saved setting during these times.

Additionally, it's showing some erratic SOC readings. I was on a trip yesterday and for the first 1-2km it was showing a lower SOC than EV Notify, despite being connected and earlier showing the correct reading on desktop. During the trip occasionally the SOC flipped to 50%, where it was much higher.

 

[Samuel-ABRP]

We just reworked the logic for "override car position" in Android Auto. Now it is not needed anymore to activate that toggle button to get good position data in AA. The next AA version will also have some other considerable improvements, so stay tuned for the next version (which unfortunately is not publicly available yet).

[remy]

Hi !

First of all, thanks for this app and the android auto support, it enables so much.

Here are my feedbacks:

• would be nice to always show the distance to the next turn/exit. When on the motorway, it would be nice to know if the next exit is in 10 km or 200 km
• show the GPS speed, as some cars speedo are not that well calibrated
• pinch to zoom and move around features are not possible
• I did not found the setting to adjust the navigation voice volume
• add the possibility to quickly change the destination in the car screen (my bad it is already available)
• add a view that show all the detailed informations about the current route (total distance, ETA, waypoints, charging stops, etc)
• maybe being able to update the settings (max SOC, max speed, weight, etc) in the car screen. although it is ok to do in the phone

 

The navigation feature is nice, but as someone else stated earlier, I think a "share to maps" option would work great as long as it is possible to update automatically the external app when abrp recalculated the route. It would free a lot of time and hassle for you to work on other ev-specific features or take some rest

 

Keep up the good work, you are class leading in what you are doing !

Edited June 10, 2021 by remy