Missed charging opportunity, ending up with SoC less than preferred reserve

[EVGrokker]

v 1.2.0 (15)

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, Rear CC: 0, Bat Life: 100 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (15) Location: Unknown Trip: Oxford Suites Portland - Jantzen Beach, [st395sqnyhnl5eycdvw5t]

This trip ends up with 17% at the destination, less than the 20% SoC Reserve specified in settings. If there were no supercharging opportunities along the route, I could believe that that's as good as EVTO could offer. However, there is one in Centralia WA which should have been added.

[aesculus]

I'll check it out

EVGrokker mailto:notifications@github.com Tuesday, May 16, 2017 10:18 AM

v 1.2.0 (15)

This trip ends up with 17% at the destination, less than the 20% SoC Reserve specified in settings. If there were no supercharging opportunities along the route, I could believe that that's as good as EVTO could offer. However, there is one in Centralia WA which should have been added.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/aesculus/EVTO-App-Feedback/issues/376, or mute the thread https://github.com/notifications/unsubscribe-auth/AARS5F3hHgoBFZOhcv3jUQTGjzsz1NJTks5r6dpagaJpZM4Nc0Nn.

-- Chris Couper

[aesculus]

Can you do me a favor and go to Edit Segment Details and then just Save. Then see if it's 17% or 14%. Mine goes to 14%.

EVGrokker wrote:

This trip ends up with 17% at the destination,

-- Chris Couper

[EVGrokker]

Still 17% after Edit Segment Details, Save. Note that I have a 5-seater, a factor which is not included in the trip metadata, but should be.

[aesculus]

I'll add the 5 seater to the meta data on the feedback. What happens if you turn that off? It should actually be better not worse.

EVGrokker mailto:notifications@github.com Tuesday, May 16, 2017 11:18 AM

Still 17% after Edit Segment Details, Save. Note that I have a 5-seater, a factor which is not included in the trip metadata, but should be.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/aesculus/EVTO-App-Feedback/issues/376#issuecomment-301870224, or mute the thread https://github.com/notifications/unsubscribe-auth/AARS5J5MUs-JpkewWCXu5agdy6RV-mqVks5r6eiSgaJpZM4Nc0Nn.

EVGrokker mailto:notifications@github.com Tuesday, May 16, 2017 10:18 AM

v 1.2.0 (15)

This trip ends up with 17% at the destination, less than the 20% SoC Reserve specified in settings. If there were no supercharging opportunities along the route, I could believe that that's as good as EVTO could offer. However, there is one in Centralia WA which should have been added.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/aesculus/EVTO-App-Feedback/issues/376, or mute the thread https://github.com/notifications/unsubscribe-auth/AARS5F3hHgoBFZOhcv3jUQTGjzsz1NJTks5r6dpagaJpZM4Nc0Nn.

-- Chris Couper

[EVGrokker]

17% is better than 14% remaining SoC. I used less energy than you did.

I removed the 5-seater option and Optimized Routing, and it came in at 13%.

[aesculus]

Right. I was thinking the rear climate control. :-(

EVGrokker wrote:

I removed the 5-seater option and Optimized Routing, and it came in at 13%.

-- Chris Couper

[EVGrokker]

So the issue remains, there should have been an SC stop to arrive at or above 20%.

[aesculus]

EVGrokker wrote:

So the issue remains, there should have been an SC stop to arrive at or above 20%. Yes. Working on it

[aesculus]

This could be the effect of not doing weather on the server. I note there is a 20 kpm wind contribution (although interestingly it should help since its a tail wind), lower temp and rain. Maybe my wind is being applied backwards. I checked that before but ...

Without weather the server calcs a loss of 53 kWh where as with weather the app sees a loss 67.5 kWh.

I will look at it more tomorrow.

EVGrokker wrote:

This trip ends up with 17% at the destination, less than the 20% SoC Reserve specified in settings. If there were no supercharging opportunities along the route, I could believe that that's as good as EVTO could offer. However, there is one in Centralia WA which should have been added.

-- Chris Couper

[aesculus]

Pretty sure this is it. The winds in Seattle are SSE so a headwind. The app splits the difference but.

Anyway the default efficiency is 200 kWh/km. The trips efficiency is calculated at 252 kWh/km, hence the big difference.

I might look at coming up with a efficiency for the waypoints based on weather and use that vs the default.

When I added in the higher power consumption (250 kWh/km) it added the charger.

[aesculus]

So the issue is the efficiency used in the server. If I use the default value it will almost always be wrong (kind of like a broken clock). If I try to guess something it will be closer, but each guess causes the app to find other routes, unless the guess is static. For example I was using the last trip efficiency but it takes 2 or 3 passes to stabilize, so users would not like their routes changing or the charging times changing.

So I need to come up some schema that is more appropriate for the situation but still fairly statics.

[EVGrokker]

Can you pass more local parameters to the server to improve the accuracy?

Did you ever consider doing all computation on the server side? Is there an advantage to splitting up the computations?

[aesculus]

Long story. It would require a big matrix to do pros and cons. At this juncture what we have now is best.

Adding the dynamic efficiency should get us to 99% I think.

[EVGrokker]

This discussion raises an important point.

The premise of the app is to to provide trip planning and optimization, based upon available real-time data and the user's specified car configuration. The results are predictions at best, they are not guarantees in any sense. Part of the perceived quality of the app will be the accuracy of the predictions.

Additionally, as discussed previously within this issue, the dynamic factors of weather may result in computations that come close to, but don't exactly match the user's preferred thresholds specified in Settings.

Taking both of these caveats into account, part of what we need to do is to manage user expectations concerning the quality of the predictions, how actual results might vary, and the degree of arrival SoC 'looseness' that is within reason.

For example, I cited a trip that arrived with 17% SoC when my Settings specified I didn't want less than 20%. Is that acceptable 'looseness'? Perhaps it is. Suppose that it came in at 19% arrival SoC when I specified 20%. Is that acceptable? It sure seems like there should be some tolerance for coming close to the target.

I can certainly make the opposite argument as well - if the user specifies 20%, they mean 20%, and the app shouldn't make assumptions on behalf of the user. If I was content with 17%, I'd specify 17%.

I need a better understanding of what the results will look like when you add dynamic efficiency to have a more qualified opinion here, but obviously we're bumping up against some hard constraints in the design that need to accommodated.

[aesculus]

I had a three hour trip back from the Bay Area to ponder some of this last night. I agree that the whole area is a bit gray/fuzzy. We need to face the elephant in the room on that and also make sure users understand that too. Good luck with that in 'the world of perfect'.

Your point of 17% is approximately 20% and is close enough is probably true. And yes, I don't want to force some major change just because the app could save 30 seconds by doing x vs y. Unfortunately there is some of this going on, especially on the server logic, today. One route may be just as good as another. Hence the reason for the Dislike feature on superchargers. In the perfect world it would be nice to see the various routes that could be done and let the user decide. ABRP does do this at a price, and I am not sure how much it is used.

But back to the subject at hand: The discussion above about doing more detailed weather on the server etc. starts to get to the point you are 'chasing your tail'. For example if you include the weather in every calculation and then take the result set and feed it back in again, that will influence the outcome. It's the optimization version of the Heisenberg Uncertainty Principle. It can never really end and you just find yourself upsetting the perfect model you just built. And let's not get started on that fact that the weather is uncertain to start with, plus all the other factors that influence reality such as traffic, driving behavior, user's choices ...

So above I mentioned the concept of a 'fairly static' efficiency factor. It would still be influenced by topical conditions such as weather, but not doing it totally dynamically. I would propose it has these characteristics:

• It is tailored by forecasted weather by user defined waypoints. If we also include the auto waypoints maybe, but they are not fixed and can come and go at well so they are by nature too dynamic IMHO
• whatever model we create for efficiency should only vary if the user either changes the time, adds/deletes waypoints. Never based on the fact that they ran an optimization and the routing is now different
• The efficiency should be somewhat soft (your 17% vs 20% above).

So allow for some margin of error here because we know the more detailed calculations to follow (because the granularity is smaller and auto waypoints are added) will be slightly different. Occasionally it might result in a auto waypoint that is not needed or perhaps a route that was not 'ideal'. What percent this is is hard to tell. Perhaps less than 1% once we add this next component. It will never be perfect. Some users will pride themselves in pointing out where we went wrong. So be it. As you say, through user feedback/documentation we should set those expectations that the app is supposed to get you close. Users are still responsible for using the app correctly and also trying alternatives (and there are probably already too many) to test out various scenarios.

Again this sort of goes with the idea that you knock out a route using Auto and then tweak with Manual from that point on, unless major changes are made. Not sure how to get users to accept that model since many seem to want 'Autopilot' mode all the time.

[EVGrokker]

This is a fruitful discussion, because it's taking me back to my original thinking about the app… what would make someone want to use this app? The primary reasons would be because they want to preview a supercharger-enabled route with results close to the car's nav system, and they want to reduce range anxiety. There are many secondary benefits to EVTO as well, but let's focus on these two for a moment.

Let's say that I've established a Minimum SoC of 20% in Settings. My expectation is that any segment legs that EVTO calculates/optimizes will deliver me to my charging stops with at least 20% SoC. We've established that the server may return a route that ultimately falls short because of subsequent weather penalties, but the user doesn't care about that. In their minds, they clearly said "I never want to fall below x."

Assume that EVTO predicts an arrival SoC of 25% at a given SC, 5% better than my MSoC. I look at that and think "Cool. The route looks good. I've got plenty of buffer for unexpected detours, I can go really fast, I can turn the heat up…" All good things. In effect, we're giving them a buffer that they can spend as they please. In the simplest case, if they arrive with that 25% intact, it will reduce the amount of time needed to charge to reach the next charging stop. It's a win-win.

Now assume that EVTO predicts an arrival SoC of 15% at a given SC. Now the user's definitely not happy. "I'm going to have to slow down. I can't use the HVAC as much as I'd like. What if there's weather along the way, or a detour? I might be screwed."

Clearly, given a choice between delivering them to their SC with more than the specified MSoC is always preferable than delivering them with less.

So here's what I propose: I think you should pad the server side calculation such that a couple of objectives are likely to be met:

• The arrival SoC will typically be at least ~17% more than their specified minimum. If they specify a MSoC of 15%, they'd typically see a floor of 18 or better. If they specify a MSoC of 20%, they'd typically see a floor of 23% or better.
• The buffer will serve as insurance against a nasty weather penalty. Occasionally they may see an arrival SoC that's actually close to their stated minimum, but if it's because of nasty weather, or infrequent, they won't blame the app.
• Out of every 10 charging stops, maybe 1 or 2 would be at or close to the minimum, the rest would be comfortably above.

No one will ever complain that you delivered them to a charging stop with a little extra in the tank. After all, it is called the 'Minimum Arrival SoC', not the 'Target Arrival SoC'.

On the other hand, falling below the MSoC is going to be grounds for some users to complain "I specified I never wanted to go below 20%, and the app told me I'd arrive with 17%, and the developer told me that was by design!" Not good.

I vote for an extra pinch of electrons in the secret sauce.

[aesculus]

I think we can do what you want easily and still work within the framework they specify (ie the Min Arrival SOC). Where it's breaking down is on the server side. It does not have enough slop to take up the potential issues later. So I need to give it some more info and perhaps also pad it a bit.

So I propose that the server gets a bit of a pad (not sure how much yet), and then on the device, it still forces the Min SoC. What this will mean is the charging times might adjust a bit, but the stops will stay consistent. That way they will get there at 15% let's say, but if they decided to charge 10 minutes longer at the prior stop, they will have that pad for what if (driving faster, jacking the temp).

And all along I monitor the cars SoC on arrival estimate. If it looks like it does not agree with the app I ask why. Unless I think something is going to change soon (ie the app says no more rain/wind) I adjust my speed until the numbers fall into what the app says it should be doing.

BTW this is the exact purpose of the Consumption chart, but nobody has figured that out yet. :-)

[EVGrokker]

80% of the people will use 20% of the features. :)

[aesculus]

Yep. But is it the same 80% and same 20%? :-)

[aesculus]

As a start I added climate control in the server calculations. For this trip at least, it was enough to make a difference that forced the Centralia SC to be added to the route. Issue #378

[EVGrokker]

👍

[aesculus]

It turns out this did not work because I was calculating in seconds when I should have been in hours. Now I am off to a new approach.

After further review 10% is needed to alter the route to add the charger. Climate control only added about 2%.

What about a hack that looks at each segment and provides a subjective decision about the wind and precip? I could look at the wind and determine if it was a headwind or tailwind and to what amount and give it a factor to multiply by. Same with the precip index. I would also look at the next waypoint and perhaps take the average. This way if the weather is unique at one end or another it would not have an overriding impact.

So in the end I could do 10%, 20%, 30%, 40% kickers. It's worth seeing what happens. Since climate control is dealt with, that does not need to be folded into this approach.

[aesculus]

Lets try this again with V1.2 (17). It now includes road conditions, precip and wind on server for waypoints. I split the difference on the weather between waypoints so it uses an average. For the SC to SC I just use the default car efficiency as you can never tell which way you are going to approach the SC from.

[EVGrokker]

Car Data: S85, Charger: 48, Wheels: 19, Tires: 0, Pano: 0, 5 Seat: 0, Rear CC: 0, Bat Life: 100 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (17) IAP: Pro:1, Sub:1 Location: Unknown Trip: Oxford Suites Portland - Jantzen Beach, [l6opyurr74h1kl7fxsb9e]

I'm still seeing a 17% arrival SoC in Portland for this trip, with a 20% MSoC.

[aesculus]

OK. I see that. This may be a different problem but will review it. It looks to be right on the edge but since there is no rain, I would have thought it would align better.

[aesculus]

I kicked up the estimated SOC by 10% as a buffer. We will have to see how this works out. Hope it does not add chargers where they are not needed.

Updated in V1.2 (19)

[aesculus]

I actually ran into situations where routes could not be found because the estimate SoC exceeded the charging distance on low battery and/or low efficiency cars. We are going to have to monitor this and make a choice on how to handle these situations.

[aesculus]

This is still a problem in V1.2 (26). It's on the server side. It is not picking the correct set of chargers to satisfy all the trips requirements across segments.

[aesculus]

Hopefully this should be resolved in 1.2 (36).

[EVGrokker]

v 1.2.0 (36)

This trip now properly stops in Centralia to charge from 53% > 67%, arrives with 31%.

Deleting Centralia arrives with 6% SoC, which seems low, given that the Trip Summary says the trip requires 64.4 kWh.

If I subtract the Centralia added charge delta of 14% from the arrival SoC of 31%, it seems like I should arrive with 17% after deleting Centralia.

[aesculus]

This should be a trivial trip but it's not working right for me. I will dive in and see why it did not add a charger in Centralia. This was fixed when I applied Issue #438.

Note I found a bug in that I imported the trip but the cabin temp did not come through since we changed it. This was fixed with Issue #438 .

[aesculus]

I have been dissecting this short trip in order to understand what is going on under the covers. I have spent quite a few hours on it and still have more to go. Hopefully I can either explain it or find a bug to fix. It is interesting and non trivial.

[EVGrokker]

Here's are some interesting anomalies related to this trip, might be useful in diagnosing the issue.

Model X 90D, 90% SoC = 217, 220lbs payload, 68º HVAC. 5-seater.

1. New Trip: Seattle WA - Oxford Suites Portland (no destination charger).
2. The trip is calculated with an arrival SoC of 12%.
3. Add Waypoint: Starbucks, Pacific Avenue, Tacoma WA (no charger), 0 minimum stop time.
4. Route is recalculated, arrival SoC is now 21%, a difference of 9%.

Somehow, the addition of the Starbucks stop causes the energy calculation to be correct (IMHO), even though a simple stop for 0 minutes should have no significant impact on energy consumption.

Now, if I change the minimum stop time at SBUX to 20 minutes, the arrival SoC drops back down to 14%, which seems wrong. I shouldn't be charged 7% SoC for sitting still for 20 minutes.

[aesculus]

Need to get back to this but first superchargers ...

[aesculus]

Can you check this with V1.2 (56)?

[EVGrokker]

Still seeing this behavior with v 1.20 (56)

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 1, Rear CC: 0, Bat Life: 100, Payload: 100, PF: 0, SA: 0, Temp: 20 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (56) IAP: Pro:1, Sub:1 Location: Known Trip: Oxford Suites Portland - Jantzen Beach, [q4mz6rqk8krldb7nj2u5js]

When the trip is initially calculated, the SoC upon arrival is 19%. After adding the (non-charging) Starbucks stop, the arrival SoC is 22%. The trip creation sequence is the same as detailed in the comment 3 above this one.

[aesculus]

I did some experiments by turning off the wind effect. If it is turned off you have a much flatter energy consumption profile. The winds look pretty similar but from Seattle the winds are NNE and a direct tailwind until you get past Olympia, then it's a quarter tailwind. The winds in Portland are NNW so that has bit more influence in favor of the direction you are going. Note the app takes the average for the 1/3 section between waypoints. By adding Tacoma you have forced the wind to be a bit stronger (just 1 mph) but also put that centroid further along the route, thus taking away some of the favorable effects of the Portland weather.

To get more ideas of what's going on look at the Trip Details for each waypoint and look at the efficiency. Try this both with Tacoma and without.

One could debate that the winds are contributing too much to the overall model. That may or may not be true and some real world testing may need to be performed. There is a Tesla Winds web app that can be used as another source to verify effects but you have to do it IRL.

BTW I wrote a long diatribe about this issue via email a few weeks ago discussing how EVTO changes its estimates the more waypoints you give it. This is called out in Issue #486. It's the same problem here too.

Planners that don't use weather and have a static efficiency method do not suffer this issue.

[EVGrokker]

I don't dispute your explanation, but seeing the estimated SoC levels change noticeably by simply adding a waypoint that's already along the route seems counterintuitive.

I'm wondering if a more believable (if incorrect) explanation is that getting off the interstate requires slowing down and doing local driving, thus losing momentum, and getting back on the interstate requires accelerating, so the net effect of a stop, even though it's along the route, is a couple percent of SoC.

[aesculus]

I don't dispute your explanation, but seeing the estimated SoC levels change noticeably by simply adding a waypoint that's already along the route seems counterintuitive.

I agree, but it looks to be what is happening under the covers. This is why I wrote up that long diatribe a few weeks ago. It is going to confuse some people who cannot or will not accept the answer I gave and proved to myself via turning off the winds.

And another thing that happened to me recently that I did not catch until after I spent an entire day pulling my hair out was sometimes adding a waypoint along a route completely changes the route. I actually added a waypoint along a route and then Google for some reason decided going another way would shave a few seconds (maybe the approach to the location?) and it took a shorter route than it did without it (that might have been faster).

This is not the case here as the route is actually a bit longer by a few miles (167/174) so you think overall energy would make it worse.

[aesculus]

I'm wondering if a more believable (if incorrect) explanation is that getting off the interstate requires slowing down and doing local driving, thus losing momentum, and getting back on the interstate requires accelerating, so the net effect of a stop, even though it's along the route, is a couple percent of SoC.

I did not look into this. Certainly driving slower saves a lot of energy. If you want to pursue it go to Segment Details and then use the menu to export a CSV version of the segment with the legs. Do both versions and then compare the legs in a spreadsheet. You can see exactly where the energy is being expended at each driving point.

[aesculus]

This problem may be related to issue #500

[aesculus]

This seems to be old so I am going to close it. It this seems to appear again we should open a new ticket.