More Granular Efficiency Model Needed For Optimizer

[aesculus]

When optimizing long, non segmented trips with no additional waypoints, the optimizer uses an average efficiency model to guess what the consumption might be. While elevation changes are not included in this model, weather and speed certainly are.

Today the app guesses at an efficiency for each waypoint and sends that along with the optimization request to the server. But if there are large distances between waypoints, this efficiency may not be appropriate for all parts of the route. Note that this is cleaned up in the app calculations because each auto waypoint improves the efficiency model for it's segment. However this can also result in cases where the optimizer selected a charger that the app later decides it does not need.

What is needed is a way to fill in the gaps of the efficiency model for trips that span hundreds of miles with no manual waypoint, especially when weather can vary dramatically.

[aesculus]

I keep running into this, especially with MS cars. Just a few points of efficiency can make the difference between making a charger and not making a charger. Right now I have erred a bit on the conservative side but that results in the optimizer adding a charger where one might not be needed in some cases.

If I used the auto chargers in the efficiency calculation it would be more exact but it would also result in the efficiency and potentially the auto chargers changing. A bit like a dog chasing it's tail.

So I am at a bit of a conundrum. Making the model more exact and therefore having potentially volatile/variable results or making it more consistent and potentially adding chargers that may not be needed.

[aesculus]

I have worked on this some more in V1.2 (76). I added some speed offsets to increase/decrease consumption based on overall driving estimates plus adding in speed adjust and max speed influences.

[EVGrokker]

Can you provide an example to study this?

[aesculus]

The one I used was Sacramento to San Diego but LA might be OK too. I used both an MS85D and 90D. It has issues with Harris Ranch. I used 15% Min SoC

In some cases it comes up short at Harris Ranch (like 10-11%) depending on the weather.

You will need the ID [kt2ye2cv2aebityix8lv2n] and the PIN [1234] in order to Import the trip on the EVTO Trips menu.

[aesculus]

I added hvac to the supercharger selection routine in V1.2 (83). I also have it set to turn hvac on/off in the server based on the trips status. Prior it was always on for manual waypoints on the server and not used for supercharger to supercharger calcs.

We will have to monitor it to make sure it's appropriate. I have noticed a few trips that now place a charger where it's not really necessary. The reason for this is that the server uses a much larger span for it's calculations (ie the distance between stops) while the app uses each turning point. Just a few kWh/mi of efficiency can make the difference between a supercharger being added to a route or not.

[aesculus]

I still struggle with this. I did improve the first waypoint efficiency in V1.2 (88) but it can still be wrong. Usually if it underestimates the energy consumption, the easy fix is for the user to add a waypoint and then reoptimize.