Several bugs, including forgetting SOC (Android Auto)

[ePR]

On 25-29 June we did our first long-distance EV trip: Ottawa to Toronto (Canada) and back. This was our first time DC fast charging and first time using ABRP, so lots of learning.

ABRP beta premium, with real-time weather & traffic enabled, was running in our 2020 Kona electric via Android Auto. Not sure what version of ABRP Beta it was, since my phone auto-installs the updates; at least one version update has occurred after the trip ended. We found ABRP to be super impressive and useful, but did run into some bugs. Apologies if these are already known/fixed or if they are user error:

1) The most serious was that ABRP sometimes "forgot" the State of Charge (SOC), changing so that it thought the car was at a much higher SOC.

When we left Toronto for the return leg of the trip, I manually entered the departing SOC (49%) and ABRP started us on a route with 3 charging stops. Soon after we set off, it popped up a suggested alternative faster route that was the same as the original route but eliminated the first charging stop. We agreed to this, but later noticed that the car was at much lower SOC than what ABRP was reporting, and we probably wouldn't make it to the first charging stop of the new (2-stop) route. We had to detour and untangle this.

It appears that soon after we started driving at the start of the return leg, the app arbitrarily changed the 49% I had entered to something higher -- maybe 80 or 90%? Then it quite rationally suggested that, if the SOC was so high, there was no need for the first charging stop of the original route.

We observed this happening again later on: as we were in the middle of the route, we saw the SOC reported by ABRP beside the little battery icon suddenly jump up by tens of percent (taking it much higher than the actual car SOC), with the estimated SOC beside the flag icon also jumping up in a commensurate way. But that time we were not fooled.

2) As we neared Ottawa, ABRP put up an error message like "invalid route" or "can't do route" or something like that, and the route on the navigation screen turned red. It stayed like this for the remainder of the trip, even though the red route was correct and we continued to drive on it. Hard to say what triggered this: we were just driving along on the highway when it happened.

3) We also experienced a bunch of occurrences where ABRP told us to go off the highway and then immediately back on, as already described in another thread ( https://forum.abetterrouteplanner.com/topic/3206-infuriating-routing/ ). These were not in the route from the start: as we approached a place where an off-ramp connected to the highway, the navigation screen would suddenly change from showing the route as staying on the highway ignoring the off-ramp (as intended) to directing us to take the off-ramp. If we then took the off-ramp, it would proceed to direct us back onto the highway. This fooled us once, then we wised up.

4) Lastly, every time we were about to turn left into a charging station, ABRP would instead tell us to do a U-turn and then turn right into the station. We politely ignored these suggestions.

[Sofia-ABRP]

Hi @ePR,

Thank your for reporting these issues! We did release an update to the Android Auto beta about a week ago. It's possible that some issues were addressed in the latest update. If you notice any of these issues again since updating you are welcome to notify us!

To troubleshoot the issues you've reported it would help greatly if you sent us an email via your app. Open the menu by clicking the ABRP button in the top left corner of the screen and click the "Tell us what you think!" button, which will generate an email. That way we can see your account settings and give you better feedback.

1) Have you connected your vehicle to provide live data to the app? Using what data provider? The behavior you're describing sounds like the app received conflicting SoC values thoughout the trip.

2) This error message sometimes appears when a route cannot be planned within the arrival SoC preference, but is almost able to. As such this error could be caused by the inaccurate SoC data telling the planner that the SoC was lower than it actually was.

3) Could you provide us with the locations of where the re-routings happened? If you're not comfortable sharing them publically you are welcome to email them to us.

4) This issue has not been reported before. Did you notice any issues with your position in the app during the trip? Could you link the chargers where you were asked to perform a u-turn? Click on the charger on the map and then Share > Share ABRP link.

/Sofia

[ePR]

Hi Sophia,

Thanks for your response. I will certainly notify you if I see these issues again, although it may be another few months before I do another long trip like that. I've sent the e-mail via the app now, so hopefully that helps. Regarding your questions:

1) I have not connected my vehicle to provide live data to the app, unless somehow this is happening through Android Auto. My understanding was that ABRP has no way of directly knowing my vehicle's SoC, all it knows are the values I type into it, and then based on that it internally estimates things like how the SoC should drop as I drive along the route, and what it is likely to be when I get to each charging stop, etc.  So I'm not sure what would cause it to spontaneously jump up to a much higher SoC without any user input. No one was touching the phone or car navigation screen when this happened!

2) We arrived home with slightly higher SoC (32%) than the plan (I think the arrival SoC preference was something like 20% or 25%). And when we saw ABRP jump to the different inaccurate SoC it jumped up, not down (so ABRP thought the SoC was higher than it actually was). Could the error trigger on an existing route (we were not trying to plan a new route at that point, just follow the existing one), if ABRP calculates that the SoC will be too high compared to the arrival SoC preference?

3) This happened several times, but unfortunately I don't remember the exact locations. This is probably not very helpful, but most were on highway 401 and at least one time it happened somewhere on highway 416 on the way back into Ottawa ( https://www.google.com/maps/place/ON-401,+Ontario/@44.4497043,-77.953108,8.5z ).

4) We didn't notice any issues with our position in the app during the trip. I believe these are the chargers where that happened -- we stopped at both on both legs of the trip, and I think the problem happened every time:

https://abetterrouteplanner.com/?charger_id=8234135

https://abetterrouteplanner.com/?charger_id=8187031

[Sofia-ABRP]

Hi @ePR,

Thank your for emailing us.

1) If you were using live traffic and weather data during the trip the predictions may have shifted due to changes in the real-time data. The app recalculates the plan every few minutes to account for any updates in the data, such as traffic situations or charger availability.

Indeed, Android Auto does not send any data from your car to ABRP. If you'd like more accurate SoC updates and predictions you can connect your car to send live data to the app. Open your saved car's settings (click the car symbol in the upper right corner of the screen and select the car you wish to connect) to connect live data.

2) Since you haven't connected your vehicle to send live data to ABRP the app will use the default reference consumption of your vehicle to calculate plans. The default ref. consumption is set to be 10% higher than it should be to account for all driving styles. The app will still plan to arrive at the destination with the preferred SoC but has no way of getting feedback directly from the car regarding the actual SoC along the route.

3) It could be that the map data was inaccurate along some parts of the route. But without knowing the locations it will be difficult to troubleshoot.

4) It appears that the "Petro-Canada [Petrol]" (https://abetterrouteplanner.com/?charger_id=8234135) charger is placed incorrectly on the map, which may have caused the issue. Are you able to confirm that this is the correct position https://goo.gl/maps/QHjTHV4VxzZntNui7 ?

As for the other charger I was not able to find the exact location of the charger. If you know where it should be placed you are welcome to provide a link or coordinates.

We get data about both of these chargers from OpenChargeMap (OCM), which is an open source database of chargers. If you notice that the data about a charger is off in any way you are able to change this directly in OCM (or another database). Click on the charger in ABRP and then Actions > Edit in Open Charge Map.

[ePR]

For 1), the big problem was the ABRP app suddenly dramatically increasing what it thought the current SoC was, without any input from myself or from the car (because the car was not connected to send live data).

I understand that if I enter in a correct starting SoC of e.g. 49%, then the app may initially predict that I will arrive at a charging stop with e.g. 30% SoC, and this prediction is continually re-calculated & revised based on live traffic & weather data, and that it is of course possible that I will arrive at the stop with a slightly different real SoC because I may have driven more or less efficiently than assumed by the app. No problem, that is completely reasonable and how I expect it to work, given that I have not connected my car to feed it live SoC data.

But if I initially enter 49% SoC into the app, there should be no way for the app to internally jump that up to 80% just as I'm driving -- with no charging or user input. That's a big bug, and caused us a serious headache on our trip. This is because after the bug occurred, the app continued working normally (but all its calculations were then based on the anomalous SoC that was ~30% higher than reality) so told us that we could skip the first charging stop, because if we really had started with 80% SoC it would be silly to stop so soon to charge.

For 4), yes that does look like the correct position for that charger.

[Sofia-ABRP]

Hi @ePR,

Thank you for clarifying. We apologize for any inconvenience you may have experienced as a result of this bug.

If you notice this behavior again you are welcome to report it to us. We have released an update to the Android Auto beta (latest version is 4.0.46) that may have solved the problem and have not received any similar reports from other users (that I know of).

We have now corrected the location of the "Petro-Canada [Petrol]" charging station.

/Sofia

[xflow7]

Hi,

I'll add my recent experience which is slightly different from, but may be related to, what the OP observes in (1). It's different mainly because I do typically have live data enabled.

In brief, it appears that when the route gets recalculated (either because of a deviation from plan, or because of switching to an alternate route), ABRP resets the current state of charge to some other value than the latest estimated value. I have wondered if maybe it reverts to the the originally predicted SoC or maybe to some stale cached SoC from an earlier point in the route.  Anyway, what results is ABRP suddenly showing the SoC (typically) much higher than it was, with the predicted arrival SoC also correspondingly higher.

If you are using live data (as I typically am), after some period, the displayed SoC gets updated with the live data and is correct. However, the predicted arrival SoC still reads too high until yet another interval passes.

Here's a more concrete example of the behavior. The values here are hypothetical, but this is the behavior I have seen on several occasions (as recently as last weekend)

1. I plan a route from Point A to Point B that is 200 miles, starting at 90% and ABRP predicts my arrival as 20% SoC. I start driving
2. At 100 miles, ABRP displays Current SoC a = 60% / Arrival SoC = 25%
3. Just then, road construction forces me to use an alternate route.
4. ABRP dutifully recalculates, but suddenly shows Current SoC = 70% (erroneous) / Arrival SoC = 35% (assumed erroneous)
5. Some time later (say, 15 minutes), Current SoC suddenly drops from 68% to 58% (now correct) / Arrival SoC still shows 35% (still assumed erroneous)
6. Another interval later, Arrival SoC finally also updates based on the corrected Current SoC and now reads 25% (assumed approx. correct).

So my observation is there are two issues:

1. ABRP fails to either cache or correctly restore the current estimate on a recalculate
2. Once ABRP *does* update the current SoC from live data, it doesn't (at the same time) update the arrival estimate; but instead waits another update interval.

Hope that helps.

 

[Sofia-ABRP]

Hi @xflow7,

Thank you for providing some insight to your own experience.

Since you are using live data with ABRP there will be some differences in how the app handles the SoC value. But it might be something similar causing the issues you experienced. It may be easier to troubleshoot your issue since your car is connected to send us live data.

What version of the app are you running? Click the ABRP logo in the top left corner of the screen in the app. At the bottom of the menu you will find the current version of the app on your device. Are you using Android Auto or CarPlay?

/Sofia

[xflow7]

Hi Sofia,

Thanks for following up. I use Android Auto (although I think I noticed this actually while just using the app on the phone. I've updated the app since I observed this (and haven't taken a trip where I'd notice it since) so I don't know the number. But the trip where I noticed it last was July 16th and I had the latest available Beta version from the App Store at the time.

Dave

[Samuel-ABRP]

@xflow7 do you by chance use Tronity as live data source? Or what is your live data source? The behavior you describe sounds like there are no current SoC values available. Normally the SoC should refresh within 1 minute from live data if it took the wrong one or if it was outdated. But if it takes roughly 15mins it means there was no love data available until it refreshed. The latest beta also indicates that with green and red signal bars near the current SoC. Can you please check if that gets red before you experience such a behavior?

[xflow7]

I use Torque Pro. Don't take 15min too literally. That was my stand-in for "some period I would guess was some number of minutes," but I was focusing on driving and not paying close attention to when it updated. Next time I'm driving some distance I'll check with the signal bars about the data availability.

I guess the thing that most surprised me was that any update of current SoC was required at all with a re-route since the app clearly had a current estimated value from just prior to re-calculating. I expected that this value would itself be used as the departure SoC for the re-route.

[Genomecop]

The 're-routing' is the most annoying aspect of the app for us. We have had the same experiences as you, from going past exits only to be told to get off the highway and go back after MILES and also having us get off our route, go through a parking lot and get back on the original route. 

[Sofia-ABRP]

Hi @Genomecop,

We're sorry to hear that you also experienced this issue. 

What version of the app are you running? Have you noticed this issue recently? We have made some changes in the past few updates that should have fixed this problem.

/Sofia