Velocity PID control and setpoint ramping

[Oblarg]

Originally Posted by Alan Anderson

Consider what would happen if you added feedforward and took the output of the FPID directly to control the motor rather than integrating it.

This would certainly be another way of doing velocity control. I don't think I can guess exactly what the differences in performances would be without having an actual robot to test it on - naively, I suspect that doing this could yield faster response times than integrating the output (since the F term provides an immediate approximation of any desired output, while we have to wait for the integrated output to reach it) but we're not really worried about response lag.

It's worth noting that we're not seeing any problems with oscillations or overshoot, we're more worried about the taxing effect on the drive components from the (correct) behavior of the motors fighting the robot's forward momentum to come to a stop quickly.

[Jared]

I would set up something that limits how quickly your velocity setpoint can change when you are slowing down. You could put this in the part of your code where you're mapping joystick position to desired velocity.

For example, you could have something like:

//set currentSetpoint here
if(currentSetpoint - lastSetpoint > .1){
    currentSetpoint = lastSetpoint - .1;
}
//set your PID controller here
lastSetpoint = currentSetpoint;

You could replace .1 by how much you want the maximum change in velocity setpoint per 20ms to be. You'd also need to do something clever for when you're going in reverse and slowing down, but the idea is the same.

[Ether]

Originally Posted by Jared

//set currentSetpoint here
if(currentSetpoint - lastSetpoint > .1){
    currentSetpoint = lastSetpoint - .1;
}
//set your PID controller here
lastSetpoint = currentSetpoint;

Let's test that code.

inputs:
currentSetpoint = .1
lastSetpoint = 1

output:
currentSetpoint is not updated

[Jared]

Originally Posted by Ether

Let's test that code.

inputs:
currentSetpoint = .1
lastSetpoint = 1

output:
currentSetpoint is not updated

I'm not sure why currentSetpoint wouldn't be updated.
currentSetpoint is updated before the if statement, so the condition for the if statement isn't met, it will use the value of currentSetpoint set in the first line.

It does only work in one direction though - if you wanted it to work in both directions for only decelerations, you'd need to know which way you were going.

[Ether]

Originally Posted by Jared

I'm not sure why currentSetpoint wouldn't be updated.

The large step in setpoint is allowed through without being ramped.

.1 - 1 = -.9 which is not > .1, so the logic does not prevent a jump in setpoint from 1 to .1.

[Oblarg]

One thing I'm still rather clueless about is how little ramping we could get away with while still reducing the impact on the gears. We haven't yet timed how fast the robot is decelerating under the current control loop, and we probably won't be able to between now and our next district.

If we knew both that and by what factor we need to reduce the loading on the drive to reduce the chance of future damage to acceptable levels (I'd say just preventing gear failure would be acceptable), then we could calculate a rate to start with. Since we're not immediately stripping this out, I don't think we're too far above such a threshold, so perhaps halving the acceleration would be a good place to start...

Alternatively, if we knew the max rated load of the gears we could calculate the maximum acceptable acceleration from the robot weight and gear diameter, but I don't see any such figure on VexPro (and I wouldn't be surprised if gear failure is more complicated than simply a "maximum load").

Anyone have any guesses?


EDIT: Looking at an online gear strength calculator (http://www.botlanta.org/converters/dale-calc/gear.html), it seems I should be aiming for under 100 lbs of force on the gear.

The gear that broke (14t) was meshing with the gear on the output shaft (60t). Both of these gears are experiencing the same load. The load on this set of gears is clearly going to be higher than that on the input gear that meshes with the CIMs. So, I reason thus:

The maximum permissible torque on the output shaft is 100 lbf * 3 inches (pitch diameter of 60t gear).

The robot mass is about 130 lbm with bumpers and battery, one half of which is loaded on any given side of the drive. The wheels are 8-inch diameter.

Thus, the maximum permissible acceleration of the robot is (100 lbf * 3 inches) / (130/2 lbm * 8 inches) = 5/8 g = ~20 ft/s^2

Our robot moves about 10 feet/second at top speed, so we should be decelerating from full speed to zero in no more than half a second.

Does this seem right to everyone else? Any idea how close to this we should be willing to stray?

[tr6scott]

So, in labview...
lineal ramp...
We use this.

Believe it was written by Killer Bees, we have just been dragging it along for years.

[Oblarg]

We toyed with an input ramp today, and found that the values we had been considering (roughly a half-second from 0 to max) were way too slow for effective driving.

We're going to move forward with the ramp disabled for now, and hope that switching the 14t gear to a steel version will prevent further catastrophic drive failure (we observed no major damage to the 60t gear meshing with the 40t gear upon taking apart the gearboxes yesterday, so we think we'll probably be OK).

Thanks for all the help!