Advanced traction control - work with single ESC too

[Gabrielerusso]

Adds a Traction control that uses derivate of rpm (rate of change of rpm) to calculate the new current instead of the classic difference of the RPM. For the moment it's possible to setup it via lisp console, some configuration are commented as the apps doesn't have the two new field.

It's completely configurable via LISP and has a quick "level" setting like automotive motorcycles.

This is separate from the rpm-difference TC, and you can chose to use both, or to use only one:

1. Advanced TC + Standard TC (only with multiple ESC)
2. Adavanced TC with any setup
3. Standard TC (only with multiple ESC)

• tc_max_rpm_rate : rate of change in erpm/s for small motors (<12") should be between 3000 and 150000, the higher the number more sharp will be the response.
• tc_level : how much the traction controll will affect riding in %, <1.0 means no effect, 99.99 means maximum effect; common values are between 20% and 90%, an higher percentage means a more aggressive traction control.

TODO: maybe calculate this for each other ESC in case of multiple ESC, by now it's only done on the master

Note: i think this could also be used, if set correctly, to limit acceleration to preserve battery life while keeping motor current high for when it's needed, as it will limit only the acceleration but not the current at a steady speed.

[Gabrielerusso]

Tested today with a QS273 ebike and with a 65H rear traction escooter on muddy terrain, seems to do it's job correctly reducing wheel slip.

[vedderb]

The confgenerator-file should not be edited manually as it is autogenerated from vesc tool when editing the configuration xml files.

What this looks like to me is a limit on the RPM rate of change. Maybe it helps when wheels start to slip, but I'm not sure that is what usually is meant by traction control. If a RPM derivative limit is useful it should be added to the General -> RPM settings and implemented in the mc_interface-function update_override_limits. Doing it that way means that all apps and inputs can take advantage of it.

[Gabrielerusso]

The confgenerator-file should not be edited manually as it is autogenerated from vesc tool when editing the configuration xml files.

Didn't know that, just changed files to test it out.

What this looks like to me is a limit on the RPM rate of change.

Yes, this is a RPM rate of change limiter.

Maybe it helps when wheels start to slip, but I'm not sure that is what usually is meant by traction control.

TC is everything used to reduce wheel slip, so actually even evaluating wheel acceleration to estimate wheel slip is a way of doing TC. We usually use wheel slip for ABS and TC, wheel slip ratio is defined (more or less) as $slip=({RPM{driven} \over RPM{undriven}} - 1)100$ or more precisely $slip=({Speed{wheel} \over Speed{vehicle}} - 1)100$ . Other than that accelerometers are used for Stability Control and other things we don't care much as the moment. Note that we could use this info for another PR to abstract the "TC ERPM difference limit" now used in the TC for a more generic Slip % that would work to any configuration.

In our case something similar is done using a RPM thresold and doing the RPM difference of the motors BUT as we are not using an undriven wheel, and the rpm is not always equivalent to the real ground speed it basically acts like a RPM sincronizer more than an actual TC. This mean that if both (2 wheel used as reference) wheels start slipping (and they do in ice/snow/mud) we won't have TC anymore but a simple syncro between the two wheels, and that will lead to slipping, more than a TC the actual is a limited slip differential.

Car and motorcycles uses perforated wheels mounted on disc brakes (and other sensors) to calculate slip, but this is almost impossible for our use cases. To compensate for that the rpm rate of change ($dRPM \over dt$) limiter could be very helpful if set-up correctly to limit the $dRPM \over dt$ to the actual physical maximum value.

Example: maximum possible for that motor in optimal working condition is ${dRPM \over dt}=10{RPM \over s}$ if ${dRPM \over dt}>10{RPM \over s}$ this mean we are surely slipping (or running without any load) , if we are ${dRPM \over dt}<=10{RPM \over s}$ this mean we PROBABLY are inside our normal working range. Reading from accelerometer could be used to be more precise, as if $dRPM \over dt$ is increasing and rate of change of accelerometer in one specific direction is not increasing then this mean we are slipping in that direction, but not everyone has an IMU installed.

Note that $dRPM \over dt$ limiter works also for non-wheel driven, like if you are using a propeller the $dRPM \over dt$ is lower than in the case the propeller is missing, this also could help to reduce strain on components that are not suppose to have that sudden acceleration in case of a "no load" operation. For ground vehicles, if set-up correctly for that use case this can be used as an efficiency improver as it limits the overrall acceleration while keeping all the torque.

PS now TC is used only during acceleration and not braking, using TC and/or $dRPM \over dt$ limiter during braking will act like some sort of ABS.

[Gabrielerusso]

• [X] RPM rate of change limiter moved to mc_interface and max_erpm_rate to mc_configuration struct.
• [X] enable/disable TC from Lisp
• [X] Using a combination of slip ratio and "slip differential" for Traction Control
• [ ] Test new changes

[FDResearch]

Did you ever get a chance to test this further?