Page 1 of 1

User selectable throttle response by CAN

Posted: Wed Nov 17, 2021 10:29 pm
by catphish
I've been asked to build a module with several push buttons to select different behaviours for a Tesla Large Drive Unit. There will be 4 modes:

* Normal
* Economy
* Performance
* Downhill

Each of which will send CAN messages to openinverter to immediately change parameters to achieve the desired behaviour. In the first three modes will aim to simply change the maximum torque commanded by the throttle pot. The final mode would dramatically increase the zero-throttle regen.

My question is: which parameters should I be changing? For max torque, it seems that I could use either fslipmax, or throtmax. What is the practical difference between the two, and which would be appropriate for this use case? Similarly, for the high regen mode, I could modify brkmax or throtmin. Again, what is the practical difference between the two.

Are there any better ways to achieve this that I might have missed? Thanks!

Re: User selectable throttle response by CAN

Posted: Thu Nov 18, 2021 12:33 am
by jon volk
I’ve done similar mode switching. The most dramatic change in torque will be fweak and fslip. Both get really need to be adjusted together at the limit to prevent overcurrent trips which are usually hardware desat faults on an LDU and require a full LDU power cycle.

The only throttle parameter for drive modes I change is throtramp.

I deal with downhill a bit differently. I use an inclinometer to increase throttle off regen when pointed downhill linearly with angle. The same also increases idle throttle for not rolling back on a steep incline.

Re: User selectable throttle response by CAN

Posted: Thu Nov 18, 2021 9:31 am
by johu
I like that inclinometer idea :)

To start out you could indeed just change throtmin and throtmax. Like dial in a ridiculous amount of regen and then limit it with throtmin OR pot2. If you set throtmax=slipstart you would always be driving with fslipmin, the most efficient operating point of induction motors.

Re: User selectable throttle response by CAN

Posted: Thu Nov 18, 2021 9:44 am
by catphish
jon volk wrote: Thu Nov 18, 2021 12:33 am I’ve done similar mode switching. The most dramatic change in torque will be fweak and fslip. Both get really need to be adjusted together at the limit to prevent overcurrent trips which are usually hardware desat faults on an LDU and require a full LDU power cycle.
johu wrote: Thu Nov 18, 2021 9:31 am To start out you could indeed just change throtmin and throtmax. Like dial in a ridiculous amount of regen and then limit it with throtmin OR pot2. If you set throtmax=slipstart you would always be driving with fslipmin, the most efficient operating point of induction motors.
Thanks both. It would be my preference not to be modifying the v/hz curve of the motor once I've found optimal settings. In a similar way, it makes sense not to change fslipmin and fslipmax once I've dialled in sensible values for optimal efficiency and breakdown torque. So I think for now I will keep it simple and stick with throtmin and throtmax.

I do like the idea of using an accelerometer to detect slope and set the hill holding torque automatically!

Re: User selectable throttle response by CAN

Posted: Thu Nov 18, 2021 3:33 pm
by jon volk
The sensor I currently have in the car is a G-NSDOG2-002. It's a pure analog output and needs some filtering to function reasonably well. Ive got some remedial averaging that works well enough.

Ill likely be swapping it out for one of these as it does on-board kalman filtering and fully configurable over CAN
https://www.aceinna.com/inertial-systems/MTLT305D

Re: User selectable throttle response by CAN

Posted: Thu Nov 18, 2021 6:36 pm
by catphish
I used to use the MPU5060 for multirotor flight control. This provides a very stable output by using a gyroscope for high frequency and accelerometers for low frequency data. Perhaps a little overkill for this application, but would work very well. Of course a fully integrated CAN solution is even better, I'll have a look at the devices you linked to. Shame I don't have an immediate requirement for this.