Ramp support for Speed Loop regardless of input

Are there any features that you would like to add to the VESC?
Posts: 24
Joined: 10 Feb 2016, 10:21

Ramp support for Speed Loop regardless of input

Postby wdaehn » 10 Feb 2016, 13:04

The goal of the speed loop is to bring the motor to that speed as quickly as possible. That means full thrust and maximum possible accelaration.
Would be much nicer if you could limit the maximum acceleration via a speed ramp.

Imagine I have the RC stick an by accident I give it a full kick for half a second. The e-board would throw me off.
Imagine I would like to limit the amount of Amps and the mechanical stress on the gear belt by limiting the maximum acceleration.

Hence the request to filter the input based on a maximum acceleration limiter.
new_rpm = rc_input * Kp;
if (new_rpm > old_rpm + max_accel) { new_rpm = old_rpm + max_accel; }
old_rpm = new_rpm;

As a positive side effect, it looks very cool and improves riding comfort, when you simply go to max speed with the stick and you keep accelerating for the entire time by a constant factor.

Site Admin
Posts: 280
Joined: 15 Dec 2015, 08:38
Location: Sweden

Re: Ramp support for Speed Loop regardless of input

Postby benjamin » 22 Feb 2016, 11:26

If you want to limit the mechanical stress you want to limit the torque, and this is already done with the current limit. The speed loop can't override the maximum current. Adjusting how fast the speed controller acts can be done with the PID control parameters.

Adding input ramping and having a fast control loop would the controller act fast when external disturbances affect the speed, but not when a new speed is commanded. Maybe this makes sense for some applications. I have put this on my to-do-list and will have a look at it.

Posts: 24
Joined: 10 Feb 2016, 10:21

Re: Ramp support for Speed Loop regardless of input

Postby wdaehn » 17 Mar 2016, 17:02

Now being more familiar with the VESC, I would suggest to make that setting a global option, regardless of input method and motor operation mode.

Basically the Nunchuk ramping constants but moved to the App Configuration General page.

The obvious example is PID Speed Loop in PPM Control mode. You crank the stick to full power but the ramp simulates a slow increase of the stick.
Same obvious example is Duty Cycle or Current in PPM mode. A sudden movement is dampened using the ramp. So the duty cycle/current is increased slowly instead.
Nunchuk in current mode works that way today already.
But also UART should support that feature. I send a requested target speed of 15000erpms and the motor is spinning up slowly, if configured.

The actual UI implementation I am worried a bit. Best would probably be to use percent/second.
Every screen has a min/max value. In PPM that would be the pulse width, in ADC the min/max voltage, in uart the configured max speed, max current or whatever the mode is. Now we know the value range and can map that to -100%...0%...+100%.
In the General page of the App Configuration you can specify how many percent the value can change per control loop. A value of 0.0001% would mean that the target value increases very slowly, a value of 100.0% would mean the target value equals the requested value immediately.

In the firmware we add another variable. Currently there is the motor target value and the input device sets this value directly. Now it sets a variable called dialed_speed and the target value is moved by this configured change_percent towards the dialed_speed.
if (target * (1+change percent) / 100 < dialed_speed) {
target = target * (1+change percent)/100;
} else if (target * (1-change percent) / 100 > dialed_speed) {
target = target * (1-change percent)/100;
} else {
target = dialed_speed;

To your arguments about using the current limit, you are correct of course. But the argument falls too short in my thinking.
1. There are two kinds of torque, torque because of the high speed and torque due to acceleration. If I set the current limit to a very small value for very slow accelerations, I would never get a high top speed. The torque for the acceleration I want to limit.
2. Current limit does not give you a nice, linear acceleration.
3. When running at high speed and decelerating, you are certainly not increasing the current and you might not be in regen braking current limit. Hence in this speed area the current limits would not be reached and hence no speed ramp.
4. You implemented for Nunchuk for a reason. Why, if current limit does the job.

Posts: 24
Joined: 10 Feb 2016, 10:21

Re: Ramp support for Speed Loop regardless of input

Postby wdaehn » 29 Nov 2017, 20:25

I just found in the current Vesc Tool the settings:

PPM -> General -> Positive/Negative Ramping Time. Isn't that the exact function I requested here?

If yes, you can close it on your ToDo list as it shows status "TODO" there still.

Return to “Feature Requests”

Who is online

Users browsing this forum: No registered users and 1 guest