Jump to content

kristgy

Members
  • Posts

    6
  • Joined

  • Last visited

  • Days Won

    1

kristgy last won the day on May 17

kristgy had the most liked content!

Reputation

4 Neutral
  1. There are two map view modes of the five options that I haven't really figured out. How are the view modes indicated with a checkered flag and a route with four waypoints (see attached) supposed to work? Apropos: Is there any documentation specifically for the AA version of ABRP?
  2. I think the below ideas have been mentioned before, but just to give some more motivation: - It would be very helpful if the part of the route that has already been driven would change color on the map display (say from blue to gray). I often plan a trip back and forth at once, since it gives the optimum charging plan for the whole trip, not just each leg on its own. In this case, the map view is quite confusing with the outgoing and returning routes overlapping and everything in the same color. - The map display could be used more effectively while navigating a route, for example by displaying alternative charging stops along the route, with real-time availability information visually presented, for example by color (real-time availability information is after all one of the unique selling points of ABRP). For this to be really effective though, it would also need to be easier to update a route from the head-unit while navigating it.
  3. The new 3D view and the visual indicator of live SoC connection work really well and are great steps forward in terms of usability. Excellent. The SoC on arrival prediction is also good help once you figure out what it is telling you. I wonder if the icon could be more descriptive. As is, it is unclear by just looking at it if it refers to SoC at next waypoint or at final destination (of course only the former makes sense but it took me a while to get it). Finally, as mentioned before, it would be great to be able to delete a waypoint from the current route on the head unit. It happens that ABRP doesn't register a stop and then it keeps sending you back to a stop that is already done.
  4. I am seeing the same unexpected behaviour of the bottom bar (Android 11).
  5. 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
  6. 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.
×
×
  • Create New...