Acceleration Ramp Up Code

[ElectricNoodle]

Our team is trying to cut out some of the bumps in acceleration by writing a "ramp up" code. For example, if we want the motor power to go from 0 to 100, we want there to be other steps in there to prevent jumping ss in the acceleration. Any ideas of how to do this?

[Kevin Phan]

Can you elaborate on what you want to do to cut down on acceleration? The way I am familiar with manipulating the drive is from the joystick outputs. I don't think you can manipulate the motor output itself since the motor outputs are used the vi given by wpi. I wouldn't want to mess around with their vis until it becomes necessary.

[Ether]

Originally Posted by ElectricNoodle

Our team is trying to cut out some of the bumps in acceleration by writing a "ramp up" code. For example, if we want the motor power to go from 0 to 100, we want there to be other steps in there to prevent jumping ss in the acceleration. Any ideas of how to do this?

http://thinktank.wpi.edu/article/140

[ElectricNoodle]

Originally Posted by Kevin Phan

Can you elaborate on what you want to do to cut down on acceleration? The way I am familiar with manipulating the drive is from the joystick outputs. I don't think you can manipulate the motor output itself since the motor outputs are used the vi given by wpi. I wouldn't want to mess around with their vis until it becomes necessary.

To be more specific, I'm essentially looking for the best way to do what you described and manipulate the JOYSTICK outputs to ramp up acceleration of the motor INPUTS. Sorry I didn't really explain it well the first time, but if you have any ideas they would be greatly apprieciated.

[Ether]

Originally Posted by ElectricNoodle

I'm essentially looking for the best way to do what you described and manipulate the JOYSTICK outputs to ramp up acceleration of the motor INPUTS. Sorry I didn't really explain it well the first time, but if you have any ideas they would be greatly apprieciated.

Did you read the link in Post #3 ? It explains how to do exactly what you indicated above.

[gnunes]

Originally Posted by Ether

Did you read the link in Post #3 ? It explains how to do exactly what you indicated above.

I did! Thank you for posting that. The linked paper is full of good ideas.

[ElectricNoodle]

Actually yes I read through yesterday, and was interested in the "Slew Rate" and "Low Pass Filtering" sections, as we were thinking of doing it in a similar fashion but didn't know how to implement it. So that helped a lot in that regard, but I'm still wondering. Are there better ways to do this? Which of these options do you think is best?

[Ether]

Originally Posted by ElectricNoodle

Actually yes I read through yesterday, and was interested in the "Slew Rate" and "Low Pass Filtering" sections ...Which of these options do you think is best?

From what you described in your original post, it sounds like you want the slew rate limiter.

In a text-based language, it would look something like this:

change = joystick - limitedJoystick;
if (change>limit) change = limit;
else (if change<-limit) change = -limit;
limitedJoystick += change;

limit is the amount of change you will allow every iteration (e.g. every 20 milliseconds for TeleOp)

limitedJoystick is the rate-limited joystick value you use to control your motors.

[ElectricNoodle]

Thanks for the help!

[wt200999]

I've attached an example that helps visualize what happens when you use the low pass filter option. It has two different low pass filter implementations. One of them is simply averaging your joystick outputs over a number of samples. This method makes the most sense intuitively if you have not studied low pass filters before.

As far as implementing this, I see a couple of options. The easiest might be what was said before, which is to put a block between your joystick and your motor drive functions.

The other option is to put whatever function you want to use into a VI and assign that VI to each motor as its 'transfer function'. This way you use all of your motor drive functions as you normally would, both in teleop and auton, and your ramp function will always be working.

For both of these options, if you create your ramp function as a SubVI and you create multiple instances of it, it will be important to set your execution to Reentrant for that SubVI. This is File -> VI Properties -> Execution -> Reentrant execution with option Preallocate clone for each instance

Edit: Added the PID Output Rate Limiter as well which is what Ether describes.