[Ovmsdev] ACC implementation

Tue Jan 22 21:17:23 HKT 2019

Steve,

I think it probably best to extend the vehicle framework to support the core ACC functionality (charge at, charge by, etc). Yes, something like those commands you provide.

Then what we know of as ‘acc’ is really just a profile (with all the charge details), the ability to activate a profile or run those manual commands, and the automatic activation of the acc profile when a particular location is entered (or otherwise via script, command, etc).

Regarding implementation, the core functionality we require is the vehicle ability to start a charge, stop a charge, and provide signaling (such as pilot signal, etc).

When I implemented ACC for the roadster, I did consider various techniques for when ACC is activated. One is to set a charge timer for an hour in the past, and keep resetting that every 22 hours. That would avoid the issue of when you plugin the charge starting. Put the car in ’timer’ mode. But, the roadster also has gps and ‘charge locations’, and remember the mode for each location. Every time I reset the timer, the flash in the VMS would be updated. It just seemed kind of messy. Easier to just send a ’stop charge’ command when pilot is detected and acc is active. So, yes, timer mode should be disabled when using ACC. For roadster, we have a command to do that, and in v3 it is in the standard vehicle framework so other vehicle types may support it.

I guess you may need some sort of capabilities back from the vehicle module in order to be able to implement this. Something like ‘HasChargeStop’, ‘HasChargeStart’, ‘HasTimer’, etc.

> That means the car will want to start charging on plug-in, but
> his note says that OVMS will stop the car from charging until the ACC
> conditions dictate. I expect that functionality is not implemented in
> OVMSv3, correct?

Correct, none of ACC is implemented in v3 yet.

> Should the command to configure charge profiles be included in
> vehicle.cpp as well?

Yes.

> Do you think that command should be named "acc"
> or something else?

Using ‘acc’ as a root is fine by me. It stands for Advanced Charge Control, so that makes sense. I think the goal is best described as bringing a set of advanced charge control functionality to all vehicle types (no matter what the vehicle supports). So long as the vehicle can start / stop charging, we can provide things like timed charges (at or by) in ovms firmware.

>  Profile creation could be made a subcommand of
> "charge", but I think that might be confusing.

Putting it under ‘acc’ is fine for me.

Regards, Mark.

> On 19 Jan 2019, at 4:15 PM, Stephen Casner <casner at acm.org> wrote:
> 
> Mark,
> 
> I think the addition of "charge profile <name>" fits well.
> 
> Do you think there should also be direct commands like:
> 
>    charge at <time>
>    charge by <time>
>    charge on-plugin
>    charge to soc <percent>
>    charge to range <distance>
> 
> Or should those parameters be controlled only be selecting a profile?
> 
> The implementation of those functions is the real infrastructure for
> this feature:
> 
>  - "charge by" requires using the charge time predictor to
>    figure the start time, then is becomes the same as "charge at".
>    (I have some concern that ctp may not be accurate for Roadsters
>    with the 3.0 battery.)
> 
>  - "charge on-plugin" has an associated event, but all the other
>    operations require use of a ticker to see if the start time has
>    come or the stopping condition has been reached.
> 
> Bennett's writeup of how to use ACC with OVMSv2 mentions that the user
> needs to turn off timer-based charging on the VDS before configuring
> ACC.  That means the car will want to start charging on plug-in, but
> his note says that OVMS will stop the car from charging until the ACC
> conditions dictate.  I expect that functionality is not implemented in
> OVMSv3, correct?
> 
> Should the command to configure charge profiles be included in
> vehicle.cpp as well?  Do you think that command should be named "acc"
> or something else?  Profile creation could be made a subcommand of
> "charge", but I think that might be confusing.
> 
>                                                        -- Steve
> 
> On Fri, 11 Jan 2019, Mark Webb-Johnson wrote:
> 
>> Steve,
>> 
>>> Are you proposing that those actions be stored in the location config?
>> 
>> Yes, I’m thinking these actions could be associated with each location (and direction - ‘enter’ or ‘leave’). Configuration of the locations page of the web ui makes sense.
>> 
>>> I suppose we could define a syntax to allow appending a chain of actions
>>> after the basic location config.
>> 
>> Yep, exactly. I was thinking before of a generic ’tag:value’ list for location, but now this new approach seems more sensible. Make it a list of type:actions:param. Something like enter:homelink:1, enter:acc:home, etc. The list goes into class OvmsLocation and can be persisted to config in the normal way.
>> 
>>> I'm still a bit unclear on how much an "ACC profile" could specify.
>> 
>> The idea is to model a charge profile. For example, at home I might want to do a:
>> 
>> Type: Charge By
>> Cooldown on plugin
>> Charge limit: 90% SOC
>> Charge mode: Standard
>> Charge current: 32A
>> Complete charge by 7am
>> 
>> Another example:
>> 
>> Type: Charge At
>> Cooldown: no
>> Charge limit: 200km
>> Charge mode: Standard
>> Charge current: 32A
>> Start charge at 11pm
>> 
>> The ACC profiles are a charge type (on-demand, charge at, charge by, etc) and associated parameters controlling the charge.
>> 
>>> But would users really want to
>>> access those profiles for a manual charge (not associated with a
>>> location) as opposed to just giving the charge command(s)?
>> 
>> I’m thinking something like ‘charge profile home’ to activate that profile for the duration the car is plugged in. But you could get to a restaurant, and type ‘charge profile ontheroad’ to set a profile without having to set all the individual parameters.
>> 
>> Regards, Mark.
>> 
>>> On 11 Jan 2019, at 3:55 PM, Stephen Casner <casner at acm.org> wrote:
>>> 
>>> Mark,
>>> 
>>> Along the same lines, when I poked around the web UI it occurred to me
>>> that it would be a logical (and I think intuitive) extension to the
>>> location configuation page to allow specifying some actions to be
>>> associated with a location.
>>> 
>>> Are you proposing that those actions be stored in the location config?
>>> That's where I was heading with the ACC feature when I began to wonder
>>> whether that would be considered inappropriate.
>>> 
>>> I suppose we could define a syntax to allow appending a chain of actions
>>> after the basic location config.
>>> 
>>> I'm still a bit unclear on how much an "ACC profile" could specify.
>>> In the OVMSv2 ACC command, it was just the combination of a mode
>>> (standard or range), start time (on plug-in, at a time, or as
>>> appropriate to end at a particular time), and optionally an ending
>>> condition (SOC or range) other than what the car's algorithm would
>>> normally do.  I suppose the option to do cooldown on plug-in could
>>> also be considered part of a profile.  But would users really want to
>>> access those profiles for a manual charge (not associated with a
>>> location) as opposed to just giving the charge command(s)?
>>> 
>>>                                                       -- Steve
>>> 
>>> On Fri, 11 Jan 2019, Mark Webb-Johnson wrote:
>>> 
>>>> Steve,
>>>> 
>>>> I haven’t had much time to think about this, so putting this out just for comment. Not really sure the best way, but this does seem to be narrowing down to something quite useful.
>>>> 
>>>> I agree that there is value for a simplified system (configured by command and/or web interface). Scripting is certainly not for the novice user.
>>>> 
>>>> Brian’s comments (and the issue of Homelink), coupled with the above ’novice’ user requirement, has made me think about this from another direction. Perhaps we need a simple mechanism for a location to have ‘actions’. Like activate homelink, send a textual notification, activate an ACC profile, etc. Those actions can be chosen from a hard-coded extensible set, and config can be via web or commands. Each location would have both enter and exit actions. This connects locations to ACC, but in a general way (allowing for other simple location actions such as homelink activation).
>>>> 
>>>> Then we come to ACC. I’m still thinking this should be on the vehicle side. Have the ability to define smart ACC charge profiles, and choose one as the active one (or otherwise one of the other charge modes). So, our charge types become one of:
>>>> On demand
>>>> On plug-in
>>>> On timer
>>>> ACC profile
>>>> etc
>>>> 
>>>> Does that solve the problem, and provide a general enough framework?
>>>> 
>>>> Regards, Mark.
>>>> 
>>>>> On 9 Jan 2019, at 6:55 AM, Stephen Casner <casner at acm.org> wrote:
>>>>> 
>>>>> Mark,
>>>>> 
>>>>> After reading both of your messages and sleeping on the question, I
>>>>> can see that you might object to my idea of extending the location
>>>>> config with additional parameters for ACC.  I concede that this is not
>>>>> a good fit architecturally because it would be a mess to try to add
>>>>> other functions tied to geofencing by the same mechanism.  As I
>>>>> mentioned, my motivation for the idea was a concern about an ACC
>>>>> config becoming stranded if it references a location by name and the
>>>>> location is then deleted.  In OVMSv2 an ACC profile could not exist
>>>>> without a location, but now you are suggesting that those profiles
>>>>> could be standalone.  I suppose that when listing an ACC profile that
>>>>> was bound to a location subsequently deleted I can just add a note
>>>>> "(deleted)" after the name.
>>>>> 
>>>>> It seemed to me that providing backwards compatibility by implementing
>>>>> the OVMSv2 ACC commands would be valuable, perhaps with some
>>>>> extensions to the command syntax such as to allow naming the ACC
>>>>> profiles.  Of course, we don't have the SMS gateway yet so those
>>>>> commands could not be used exactly as before.  I suppose now the
>>>>> preferred interface would be the webserver.  That's not my forte;
>>>>> perhaps Michael could add that once the infrastructure is in place.
>>>>> 
>>>>> Although homelink is irrelevant to ACC, it might have been possible
>>>>> for Timothy to set up his gate and garage door geofencing using the
>>>>> ACC command syntax whereas he needed my help for the current method
>>>>> that requires creating a script.  There should be a command somewhere
>>>>> that says "trigger homelink 1 at location foo" that automates the
>>>>> creation of the script.  But then again, where and how would you go
>>>>> about listing such settings?  You could have "homelink status" or have
>>>>> "location status" list homelink commands that are attached to
>>>>> locations, but to implement such a listing would require parsing the
>>>>> scripts to determine what homelink operation is configured.  If the
>>>>> user is allowed to edit the script, then we can't assume that the
>>>>> format of the script is the same as when the command created it.
>>>>> 
>>>>> I agree with your suggestion to implement the ACC functions in the
>>>>> base vehicle module.  Some things like charge time prediction would
>>>>> have to come from the vehicle-specific modules.  Probably the "charge"
>>>>> command should be expanded with something like "at" and "by"
>>>>> subcommands.
>>>>> 
>>>>>                                                      -- Steve
>>>>> 
>>>>> On Tue, 8 Jan 2019, Mark Webb-Johnson wrote:
>>>>> 
>>>>>> Re-reading this, I think I may not have been clear. What I mean, at a high-level, is:
>>>>>> 
>>>>>> Have a facility to create and maintain ACC charging profiles. Make them optionally connectable to locations (so they auto-activate in that location), but also just generally available for manual activation.
>>>>>> 
>>>>>> Ignore homelink, it is irrelevant to ACC.
>>>>>> 
>>>>>> Implement the ACC implementation itself in the base vehicle module, in a way that vehicles can implement/override this core charging functionality, but that we can bring the power of ACC to all vehicle types. For example, if a vehicle doesn’t support timer charging, we can do it.
>>>>>> 
>>>>>> I hope that is clearer.
>>>>>> 
>>>>>> Regards, Mark.
>>>>>> 
>>>>>>> On 8 Jan 2019, at 1:58 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>>>>> 
>>>>>>> Steve,
>>>>>>> 
>>>>>>> In v2.x, ACC handled:
>>>>>>> 
>>>>>>> What is now ‘locations’ in v3; geofenced areas.
>>>>>>> The option to fire a homelink button when entering a geofence.
>>>>>>> The option to perform a cooldown when plugging in.
>>>>>>> The option to charge at plugin, at a specific time, or complete by a specific time.
>>>>>>> The option to limit charging to SOC% or range.
>>>>>>> 
>>>>>>> The v2.x ACC was Tesla Roadster specific.
>>>>>>> 
>>>>>>> My thoughts:
>>>>>>> 
>>>>>>> The #1 (locations) function has already been implemented in v3. ACC can work from that, and doesn’t need to re-implement it.
>>>>>>> 
>>>>>>> Firing a homelink can be done with scripts today, and has nothing to do with ACC anyway.
>>>>>>> 
>>>>>>> The core function of ACC should be Advanced Charge Control - provide a high level of charge control, in a flexible way, to vehicle types that don’t have that functionality.
>>>>>>> 
>>>>>>> While this can be done in scripting, perhaps a simpler interface does make sense? Then have scripting able to override this for more advanced functionality?
>>>>>>> 
>>>>>>> I think this can sit on the base vehicle module, and control the vehicle implementation beneath it. For example, have functions to set the charge type (on-plugin, at a specific time, complete by time, etc) and have a base implementation that does it from ovms if the vehicle implementation can’t. So long as the base vehicle implementation can do ChargeStart and ChargeStop, the rest can be built on top.
>>>>>>> 
>>>>>>> ACC then become the language to control these functions, and perhaps something to tie a particular charge profile to a location geofence.
>>>>>>> 
>>>>>>> Regards, Mark.
>>>>>>> 
>>>>>>>> On 5 Jan 2019, at 3:05 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>>>>>>> 
>>>>>>>> Mark has suggested that the "advanced charge control" (ACC) functions
>>>>>>>> of OVMSv2 could be implemented in OVMSv3 using scripting.  However,
>>>>>>>> there are some missing parts remaining in the scripting support.
>>>>>>>> 
>>>>>>>> Since I have a couple of friends anxiously awaiting ACC in OVMSv3,
>>>>>>>> I'm thinking of implementing it in C++ as a command following the
>>>>>>>> previous implementation.  Is there any reason that would be a bad
>>>>>>>> idea?
>>>>>>>> 
>>>>>>>>                                                     -- Steve
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev