Elevator Motion Profiling / PID Ramping

[Aero]

Our elevator is way too fast.

We're currently using a standard PID loop, but it accelerates ridiculously quickly and throws totes.

I've looked into motion profiling, but can't see an easy way to (quickly) dynamically generate profiles between two arbitrary points on our elevator.

Is motion profiling the best solution here, or is there a simpler way to stop our elevator from accelerating too fast?

[eddie12390]

If you're using CAN Talons, you can use the built-in voltage ramping.

[Aero]

Originally Posted by eddie12390

If you're using CAN Talons, you can use the built-in voltage ramping.

We're using the 2015 Victors, so no built-in ramping there.

[eddie12390]

Originally Posted by Aero

We're using the 2015 Victors, so no built-in ramping there.

Ether has a lot of information about motion profiling here: http://www.chiefdelphi.com/media/papers/3107. If you haven't seen it, it would be a good starting point. I know for sure that the Cheesy Poofs used trapezoidal motion profiles for their 2011 robot so it may be a good place to find an example. (https://github.com/Team254/FRC-2011)

[Bluman56]

Did you attempt to lower the P (gain) value of your PID loop?

[Aero]

Originally Posted by eddie12390

Ether has a lot of information about motion profiling here: http://www.chiefdelphi.com/media/papers/3107. If you haven't seen it, it would be a good starting point. I know for sure that the Cheesy Poofs used trapezoidal motion profiles for their 2011 robot so it may be a good place to find an example. (https://github.com/Team254/FRC-2011)

I read the Motion Profiling whitepaper, looked through the Poof's 2011 Github, and also read through 236's 2015 code. All the motion profiling I can find involves drivetrain stuff, which is between static values. Nothing that'll let you move between non-predefined setpoints.

Originally Posted by Bluman56

Did you attempt to lower the P (gain) value of your PID loop?

That will provide slower acceleration, but won't help the deceleration because our integral term will take over.

[JABot67]

You could try:

- Open loop speed control on the elevator, such as connecting the Y axis of an operator joystick directly to the elevator motor output

- Closed loop speed control on the elevator (instead of position control), such as using the Y axis of an operator joystick as the setpoint to a (rate/speed control) PID controller which controls the motor

- Limiting the maximum output of the PID controller using SetOutputRange (float mimimumOutput, float maximumOutput)

- Motion profiling

Honestly, the open loop control might be enough. It's basically closed loop control given that the operator can look at the position of the elevator from the driver station to determine if it's moving too fast. If you are trying to do this in autonomous, though, obviously you have to use some sort of closed loop control. Limiting the maximum output of the PID controller may be a good idea in that case.

[Aero]

Originally Posted by JABot67

You could try:

- Open loop speed control on the elevator, such as connecting the Y axis of an operator joystick directly to the elevator motor output

- Closed loop speed control on the elevator (instead of position control), such as using the Y axis of an operator joystick as the setpoint to a (rate/speed control) PID controller which controls the motor

- Limiting the maximum output of the PID controller using SetOutputRange (float mimimumOutput, float maximumOutput)

- Motion profiling

Honestly, the open loop control might be enough. It's basically closed loop control given that the operator can look at the position of the elevator from the driver station to determine if it's moving too fast. If you are trying to do this in autonomous, though, obviously you have to use some sort of closed loop control. Limiting the maximum output of the PID controller may be a good idea in that case.

Any sort of speed control won't really work, because our elevator is really fast. It's about 0.75 seconds from bottom to top.
We have limited the max output of our PID controller, but that only provides a max speed, and no acceleration ramping.

I'm still looking into dynamic motion profiling, but I haven't figured it out yet.

[JABot67]

Originally Posted by Aero

Any sort of speed control won't really work, because our elevator is really fast. It's about 0.75 seconds from bottom to top.
We have limited the max output of our PID controller, but that only provides a max speed, and no acceleration ramping.

I'm still looking into dynamic motion profiling, but I haven't figured it out yet.

Closed loop speed control should allow you to set the speed to whatever you want it to be. You could make it so that it takes 4 seconds or 8 seconds or 16 seconds to go from bottom to top.

Open loop speed control allows your driver/operator to control the elevator's up/down motion directly (at least during teleop). This means that the operator can theoretically make sure the elevator isn't going too fast.

Of course the downside of these options is that it's hard to have position setpoints (ground, 1tote, 2totes, etc) but if you're just trying to get your elevator to stop throwing totes they probably would work.

Motion profiling would be an excellent next step if you think it's both important to have preset positions for the elevator (thus requiring position control) and use the max translation speed of your elevator during the travel time between positions. Downside, of course, is that it's harder to program.

[Jefferson]

Originally Posted by Aero

Our elevator is way too fast.

We're currently using a standard PID loop, but it accelerates ridiculously quickly and throws totes.

I've looked into motion profiling, but can't see an easy way to (quickly) dynamically generate profiles between two arbitrary points on our elevator.

Is motion profiling the best solution here, or is there a simpler way to stop our elevator from accelerating too fast?

We used a pretty simplistic approach to ramping/position control this year:

First, capture the time the new setpoint was set (rampStartTime)

ramp = rGain*(GetClock() - rampStartTime)
output = error*ramp
constrain output in a reasonable range for the current load

Adjust the rGain to get the ramp up you want and the constraints to limit the top end.

[Aero]

Originally Posted by JABot67

Closed loop speed control should allow you to set the speed to whatever you want it to be. You could make it so that it takes 4 seconds or 8 seconds or 16 seconds to go from bottom to top.

Open loop speed control allows your driver/operator to control the elevator's up/down motion directly (at least during teleop). This means that the operator can theoretically make sure the elevator isn't going too fast.

Of course the downside of these options is that it's hard to have position setpoints (ground, 1tote, 2totes, etc) but if you're just trying to get your elevator to stop throwing totes they probably would work.

Motion profiling would be an excellent next step if you think it's both important to have preset positions for the elevator (thus requiring position control) and use the max translation speed of your elevator during the travel time between positions. Downside, of course, is that it's harder to program.

I've already been through this train of thought, and motion profiling really is what we want. How inefficient would it be to generate a new motion profile every time we change setpoints?

[Jared]

I have two ideas that might help
If you want to stick with plain PID, you could try just increasing the value of kD. If it starts to oscillate a lot, try a low pass filter (moving average over 0.1 seconds or so) on the sensor value. This will help slow the elevator, but it may not be enough.

A second solution is a nested PID controller (sometimes called cascade). Have the output of one PID controller be the input of the other.

Your first PID controller looks at the actual elevator position and the desired elevator position, and outputs a desired lift rate - not motor power.

The second PID controller takes this desired lift rate as an input, looks at the actual lift rate, and adjusts elevator lift motor power.

To tune, you first worry about the second PID controller that takes velocity as an input. To tune, you can set it up so that the operator sets a desired lift rate, and the elevator moves at this rate. Make sure all your units are in terms of velocity for this loop and you should have mainly kI for this loop, and no kP. You may want to also try having a feedforward term here, I believe WPI has this built in.

Next, you tune the second PID controller. This should have lots of kD, which will give you the smooth deceleration and dampening you want.

[AdamHeard]

Originally Posted by Aero

Any sort of speed control won't really work, because our elevator is really fast. It's about 0.75 seconds from bottom to top.
We have limited the max output of our PID controller, but that only provides a max speed, and no acceleration ramping.

I'm still looking into dynamic motion profiling, but I haven't figured it out yet.

Gear slower. It will do wonders here.

[Tom Bottiglieri]

Originally Posted by Jared

I have two ideas that might help
If you want to stick with plain PID, you could try just increasing the value of kD. If it starts to oscillate a lot, try a low pass filter (moving average over 0.1 seconds or so) on the sensor value. This will help slow the elevator, but it may not be enough.
.

Off topic a bit - I saw your team was using Java this year. Have you run into issues with the timing of the JVM's Timer? We have used this construct successfully over the past two years, but on the roborio the timing is complete garbage. We have ditched using derivatives on any control loops due to massive noise.

My best theory is the squawkVM was ported manually and used VXworks timers under the hood. The standard JRE we use now probably just sleeps or something.

[virtuald]

Originally Posted by Tom Bottiglieri

Off topic a bit - I saw your team was using Java this year. Have you run into issues with the timing of the JVM's Timer? We have used this construct successfully over the past two years, but on the roborio the timing is complete garbage. We have ditched using derivatives on any control loops due to massive noise.

My best theory is the squawkVM was ported manually and used VXworks timers under the hood. The standard JRE we use now probably just sleeps or something.

More off topic -- I'm pretty sure that the JVM just does a sleep under the hood. To get more precise timing in python, we did a big sleep, then sleeps in increments of 200us to get the rest of the way there. We get +/- 0.5ms accuracy with this method.