openinverter forum

Posted: **Sun Feb 19, 2023 8:01 pm**

I have designed a traction control module that is able to take my wheel speeds & calculate a slip angle. I'm planning to pull back motor current proportionally on increasing slip via CANbus(and maybe with a PID loop in future)

Had a quick search, but couldn't see a huge amount. Has anyone thought about the best parameter to limit?

Thoughts:

Must be capable of pulling back (and re-adding) current instantly without being subject to any ramps

Sampling frequency is 100Hz, can a parameter be updated this quickly?

Ideally parameter to vary won't affect any other 'live' tune

Setting an incorrect value should not do anything worse than if the module was not present (ie: full power)

Should not override BMS limits

The parameter that seems most suited is throtmax, I can just set a value less than 100% all the way back to 0. However it's not clear how a changing value would interact with the throtramp smoothing?
Alternatively I guess iacmax, boost, bmslimhigh are options

Anyone else have any thoughts - or even tried an implementation of this?

Posted: **Sun Feb 19, 2023 11:30 pm**

The only parameter to update to directly reduce torque is throtmax. This is used as part of the throttle calculation at 100Hz. There are two problems here though:
1) Throtmax won't have any impact until it's less than the actual throttle value (potnom). This probably isn't a huge issue, traction is likely to be an issue at 100% throttle, and you can keep reducing the value until traction is regained.
2) It's still subject to hardcoded ramps *and* throtramp. This is unavoidable.

I suspect that the better way to to implement this effectively will be to add new code that takes the wheel slip as an input and reduces throttle internally.

Posted: **Mon Feb 20, 2023 6:09 am**

I've implemented basic traction control using throtmin/max for acceleration and regen: https://github.com/jsphuebner/stm32-car ... r.cpp#L395

The ramps don't seem to hurt it, it works well

Posted: **Mon Feb 20, 2023 12:04 pm**

Thank you both - that's most helpful! Johannes, looks like you are sending the throtmax param at 100Hz - is that working OK?

Posted: **Mon Feb 20, 2023 1:51 pm**

cloudy wrote: ↑Mon Feb 20, 2023 12:04 pm Thank you both - that's most helpful! Johannes, looks like you are sending the throtmax param at 100Hz - is that working OK?

Yes and yes

Posted: **Mon Feb 20, 2023 4:17 pm**

Well looks like I need to just try it!

I looked at a few 3rd party TC modules and seems common to have a parameter for increased slip allowed during initial phase of launch (I guess to combat backlash, squat & slow wheel sensor update) I've implemented to see if useful...

Posted: **Tue Feb 21, 2023 6:17 am**

As for the parameter to limit, throtmax does seem like a suitable option as it limits the maximum throttle output. However, as you mentioned, changing throtmax could potentially interact with throtramp smoothing, which is designed to gradually increase or decrease the throttle output to avoid sudden changes in speed.

Another parameter you could consider is iacmax, which limits the maximum current that can be drawn by the motor. This parameter should not affect any other live tune and can be updated quickly at a 100Hz sampling frequency. However, keep in mind that if you set the iacmax too low, it could limit the motor's performance even when there is no slip.

Boost and bmslimhigh are less suitable options as they are related to the battery and may interact with the BMS limits you mentioned.

Posted: **Tue Feb 21, 2023 9:16 am**

I think with stm32-catphish that may be an option but the implementation of iacmax in the legacy firmware might not provide the expected dynamics. I'd rather roll with the proven throtmax there. It may seem like traction control required super fast reaction time but from a control frequency point of view the process is actually quite slow.

Posted: **Wed Feb 22, 2023 1:32 pm**

I did a bit of digging on the way the traction control worked on the Smart Roadster which may be relevant (see viewtopic.php?p=43659#p43659). I intend to duplicate this when converting.

The most interesting bit was that the comms was bidirectional, the engine sending a message detailing the current torque requested by the driver to the TC module and the TC module replying with the max permissible torque. This allows the complete control algorithm to run within the TC module. The other benefit to this is that it prevents the driver over-riding the TC. When testing I found my reaction to the car feeling sluggish out of a corner (but still feeling stable) was to push harder on the accelerator. If the TC simply backs of by a percentage this behaviour could be troublesome! By having the current driver torque request accessible to the TC module it avoids this and also means that the TC module knows when it is safe to return full throttle authority to the driver.

I would also suggest hooking into the firmware after all the throttle ramps and keeping the response time as fast as possible. For a powerful rwd car (likely the case with an SDU) it's amazing just how quickly the back of the car can come round and I can well imagine the throttle ramps being problematic here (if the TC is only for launch control or fwd then I could imagine that you could get away with a bit more delay).

Posted: **Wed Feb 22, 2023 4:01 pm**

I'm pretty sure traction control originally worked in the same way in Touran but I couldn't decipher that part. Would surely be the proper way to do it. I'm mildly worried about slew rates as the ICE engine would be way slower to react unless driven at very high revs.

Posted: **Wed Feb 22, 2023 4:08 pm**

Even 6000rpm in an ICE gives only 50Hz (assuming one chance to change torque per cycle, and that the ECU isn't dosing fuel and spark per piston). Plus all the rotational inertia of the drivetrain. How quickly can the wheels accelerate?

Posted: **Wed Feb 22, 2023 4:18 pm**

ICE will be a bit slower but not massively. It's more that there will already be delays in wheel speed measurement, the TC control loops and comms latency, adding more in the throttle ramps just doesn't seem helpful.

Posted: **Sat Feb 25, 2023 9:09 pm**

Struggling to get the throtmin parameter to map... for throtmax I have:

can rx throtmax 1794 48 8 32 (which works fine)

For throtmin (negative numbers)

I have tried all sorts but think it should be: can rx throtmin 1794 56 8 32

I can get it to set 0 on 0x00, but no other values work (ie: 0xCE (-50) nor 0x32 (+50)

I've tried scaling as 1, running it across two bytes, including clearing throtmax so only one param is mapped can rx throtmin 1794 48 16 32 but no dice.

If I set it to transmit instead - the values come out of the inverter exactly as I'm playing them in when in RX mode

I'm missing something stupid, any ideas?

Posted: **Sat Feb 25, 2023 9:34 pm**

Hmm setting the scaling to -32 works, but I have to send in a positive number...

Posted: **Sat Feb 25, 2023 11:39 pm**

Yeah that's right, the CAN implementation only supports unsigned numbers.

Posted: **Sat Feb 25, 2023 11:50 pm**

Mystery solved!

Posted: **Sat Mar 04, 2023 11:31 am**

Ran a few tests today with 2%/10ms throtramp. It's "working" but unable to keep up and ends up oscillating. Seems throtramp also applies for coming off throttle, I had assumed it was only for application, but clearly see its falling at 2%/10ms also. I'm going to have to raise that value a lot to be able to catch the slip which will make the throttle pretty jerky...

Posted: **Sat Mar 04, 2023 12:13 pm**

Good data there!

2%/10ms is IMO a very slow throttle ramp. I run mine at 50%/10ms so you can definitely go a decent way up. The throttle is only as jerky as your foot

Personally I prefer the "instant" throttle response.

Posted: **Sat Mar 04, 2023 2:44 pm**

40%/10ms - fair bit better but still not fast enough. Throttle/potnom is cut within about 40-50ms of the slip starting, but motor current takes a further 50ms to decay - can reduce the ramp up to 100%/10ms but then I'm dealing with some internal openinverter ramping I guess...

Posted: **Sat Mar 04, 2023 8:29 pm**

cloudy wrote: ↑Sat Mar 04, 2023 2:44 pm 40%/10ms - fair bit better but still not fast enough. Throttle/potnom is cut within about 40-50ms of the slip starting, but motor current takes a further 50ms to decay - can reduce the ramp up to 100%/10ms but then I'm dealing with some internal openinverter ramping I guess...

tcutest2.JPG

Yes, sorry, there's a hardcoded internal ramp (filter) that happens after throtramp and creates quite a lag in throttle response. This was a problem for me so I added a patch to make it adjustable:
https://github.com/jsphuebner/stm32-sine/pull/21

I reduced this filter from 4 to 3 to half the response time. You need to be a little careful with this value if you are using regen. If not, you can get much more aggressive with it.

Posted: **Sat Mar 04, 2023 9:46 pm**

Sounds like you've gone through the same journey! (am also SDU)

Thanks for your patch! I've compiled latest with your commit included and will give it a whirl at 50%/10ms and throtFilter at 3 instead of 4 when out next.

I wonder if it would be also be useful to be able to configure rising and falling throttle ramps as separate values?

Posted: **Sun Mar 05, 2023 12:57 am**

cloudy wrote: ↑Sat Mar 04, 2023 9:46 pm Sounds like you've gone through the same journey! (am also SDU)

I spent a LOT of time tuning the small drive unit. See my thread here: viewtopic.php?t=2558
Ultimately I wasn't 100% happy with the results and decided to write a whole new control algorithm: viewtopic.php?t=3086
I'm awaiting feedback from people brave enough to test it.

cloudy wrote: ↑Sat Mar 04, 2023 9:46 pm I wonder if it would be also be useful to be able to configure rising and falling throttle ramps as separate values?

I agree that throttle ramps could be more flexible. Ideally we'd want 4 ramps: throttle up, throttle down, regen up, regen down.

Posted: **Sun Mar 05, 2023 4:20 pm**

Another slight improvement. 50%/10ms and throtfilter 3. I reckon I can shave off even more time by either dropping the target slip (so it drops throtmax quicker) and increasing the proportional response (or moving to a basic PID controller that can see the trend of increasing slip earlier) and reducing the slip angle averaging a little.

Assuming a 20% slip target, it would appear I have around 100ms from the start of slip being apparent in the sensors and slip exceeding 20%. This is a very light car with very low rotating mass in the driven axle, so maybe a harder challenge than most.

Posted: **Sun Mar 05, 2023 5:23 pm**

cloudy wrote: ↑Sat Mar 04, 2023 11:31 am Ran a few tests today with 2%/10ms throtramp. It's "working" but unable to keep up and ends up oscillating.

If I might make a suggestion: assuming you're doing a simple proportional feedback ie:

Code: Select all

throtmax = 100 - slip;

Try an integral-only approach, like this:

Code: Select all

if(slip > 20) throtmax--;
else throtmax++;

The benefit of this is that while it will respond slower, it will reach an equilibrium. The reason for the oscillation is likely because throtmax is reduced too much, slopping the slip entirely, but as soon as the slip is gone, throamax is returned to 100%, and the slip returns. By using an integral, the reduction in throtmax will be maintained at the correct value to keep the slip at 20%. This is how I do current control anyway.

Posted: **Sun Mar 05, 2023 6:51 pm**

Exactly, currently it's 3* slipError (deviation from desired slip)

I was just focused on the first slip ie: getting a control loop fast enough to catch the initial slip - but was certainly expecting getting my approach to reach steady state would need lots of tuning. Will give integral-only approach a go. Would love to see a graph if you've done any data logging...

A few questions come to mind:

Do you correct at a flat rate per cycle, linearly against error size or even apply some exponent?

Do you pull / return throttle at the same rate?

Do you have hysteresis or just set a target well outside of "straight and steady" slipAngle noise?

EDIT: Put together a new approach based on your suggestion. Removes throttle % at a rate of (slipError * scaler) every cycle and re-adds it at a constant rate. Trying slipError*0.2 for cut and 4%/10ms for recover. If that was used in the latest log, that should have removed about 30% throttle by the time slip is highest and motor current is responding. Hopefully a good starting ballpark....

openinverter forum

Best sine parameter to vary for traction control?

Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?

Re: Best sine parameter to vary for traction control?