Steady acceleration for drive train

i was wondering how to have the robot accelerate to a certain speed(The speed of my joysticks) in a given amount of seconds, this would remove the need to slowly raise the joysticks to the desired speed

You’re looking for a ramping function


Can program an increment system where the target speed can only be x and then increase x by y every 0.5sec or similar until x=z the raw target speed from the joystick

Would I use a for loop until it hits the speed, but wouldn’t that cut out after the for loop reaches the number?


I don’t fully understand on how to implement this in my code, currently I have the raw joystick input driving the robot in tank drive

If you’re using Talon SRX’s the ctre libraries contain an easy way for you to do voltage ramping.

1 Like

What base class are you using for your robot? If you are using Iterative, Timed, or Command based, then instead of directly giving the motor the joystick value like this:


You could have an intermediary value:

speedMod = 0.05;
if(joystick_speed > current_speed + speedMod){
    current_speed = current_speed + speedMod;
} else {
    current_speed = joystick_speed;


Note: The above is pseudocode obviously, but the gist is you’d put something like that in your periodic function.

I’m using a Timed robot I’ll try that out is there anywhere I can place the code and import it rather than having those chunks in the

Yes you can have different classes and that have methods that do that, and you can import them in.

The relevant ramping logic is located in the accordingly-commented method. You can take the whole object and use it nearly as-is, if you want, though you’ll have to change the clock call from our global clock object to the standard system clock method.

I think what you are wanting to do is PID control, but with the only non-zero term being the integral term. You can have the setpoint be the joystick, and the current point start at 0, and then tune your “I” controller to your liking. A PID controller set up like this will do exactly as you describe as you want - a ramping function for your joystick. This is what I would call the simplest solution. I say that because there are PID libraries all over the place and all you would have to do is tune one for your joystick.

I should say though, that you usually want to have instantaneous joystick control. If the ramping is a requirement, and software integration is difficult, using somebody else’s PID library should suffice. Lines of code needed:

  1. Instantiate PID object with P=0, D=0, I = maybe 0.05, IDK, need to test. Set the max and min throttle to 1.0 and -1.0. You will need to make sure you have a dead band in there somewhere.
  2. In your while loop, set the setpoint as the current joystick input. As for the current point, this is a variable initialized to 0., but then continuously updated by this PID block.
  3. The output of this function call is now the value you pass into your robot control software.
    Does this make sense?

If you end goal is to just slow your acceleration to make it smoother to control, you can easily use the Talon or Victor to do it for you. See here.

1 Like

This is a slight tangent, but one easy way to smooth out your control is to run your raw joystick values through a cubic function, like so:

Math.pow(joystick.getRawAxis(0), 3);

This will give you much smoother control without the need for any further tuning. Obviously you’ll want to use the correct axis number for your specific controller.

1 Like

I accidentally ended up making our robot do exactly this this season. You need to create a trapezoidal motion profile curve, but with the trapezoid being the acceleration instead. The only thing is that this ends up making the robot movement “laggy”

@cmsmallegan I am interested in knowing the purpose of why you want to do that above? Based on reading the above comments, it seems apparent that without knowing what you want to do, we can’t help you easily find the best way to achieve your goals.

That’s called an S-curve profile (the profile is named after the shape of the velocity curve). I think what they actually want is constant acceleration, so an S-curve profile is unnecessary.

This is an absolutely terrible way to control a drive, and if your integral gain is low enough to result in noticeably “smooth” acceleration it is almost certain that:

a) Your robot will never, ever drive straight (if you’re running separate loops on each side of the drive)
b) You won’t be able to control it anyway due to massive input lag and output oscillations


You are not entirely wrong @Oblarg, but as some other commenters pointed out, trying to implement acceleration control is inherently laggy. I am by no means saying that acceleration control is the best way to ramp a velocity, I am just saying that that is one way to implement it without having to do lots of research/thinking/testing aimlessly. In my personal and school projects, acceleration/jerk/snap control is best in autonomous control: this is where the robot can PLAN the motion beforehand, whereas joystick input is random. Acceleration control is great for deterministic motion plans, whereas velocity control is better for stochastic (probabilistic) control. The OP is requesting help for teleop control.

I am just not sure how far deep the OP wants to go down the rabbit hole of motion planners. If they want to go more in depth, a quintic polynomial is an excellent method for mobile robot platforms.

Here is a paper that I think explains the subject pretty well.

This is a great textbook for autonomous robots by Sebastian Thrun:

I just wanted to suggest something that would be simple to implement in less than an hour’s time. There are a multitude of better ways to control mobile robots, but my suspicion tells me that they are not in an engineering program at a top tier university that teaches motion planning for mobile robots in stochastic environments. In my personal projects, for teleop control, I simply square the joystick input and then multiply by the sign of the input joystick value. The OP does not have to implement anything in these blog posts, they are just ideas to implement.

Also, as @UnofficialForth pointed out, we do not really know what the OP wants: they can pick and choose what they want.

One last thought: you can always do PID on PID setpoint/error (depends on implementation). This will also give you acceleration control. This is known as Cascaded PID.

From the wikipedia page:

Setpoint ramping
    In this modification, the setpoint is gradually moved from its old value to a newly specified value using a linear or first order differential ramp function. This avoids the discontinuity present in a simple step change.

Equivalently (and more cleanly), multiply the joystick input by the absolute value of the joystick input.

An even better solution was given by @Ether back in 2010. Both the square and cubed joystick inputs result in a rather wide deadband because the slope at zero is zero. A cubic with a linear term can give a program-determined low value multiplier, and still increase up to full output at full input. Here’s the topic: