Motion Profiling

[JesseK]

Jared, that's really interesting. We have a desire to do a trapezoidal profile on our tote lift in order to prevent sudden deceleration from jerking a tote off of the hooks. We're doing something primitive right now, but I wonder if our programming lead thought about a lookup table for it.

[Jared Russell]

Originally Posted by JesseK

Jared, that's really interesting. We have a desire to do a trapezoidal profile on our tote lift in order to prevent sudden deceleration from jerking a tote off of the hooks. We're doing something primitive right now, but I wonder if our programming lead thought about a lookup table for it.

The only reason we used a lookup table last season is that (a) we wanted to be able to visualize the x/y/theta quintic spline paths we were generating before deploying to the robot to make sure they looked reasonable, and (b) we needed to re-parameterize our splines by arc length, which we did with naive (and costly) numerical integration that took a little too long on the cRIO. If we had more time we would have made some quick optimizations and just done it on the fly.

[Jared]

The lookup table method was the best way for our team, as all of our autonomous action is based on distance triggers. We would generate the desired motion profile on the roboRIO, generate a .csv file from the data, copy it to the laptop, and open it in excel. This let us sit in front of graphs and data and decide when and where each action in autonomous would happen. It takes some amount of time for our elevator and container swatter to move, so knowing how fast the robot was going at each point was very helpful to determine where we should set the distance trigger for starting elevator or swatter movement.

The table method is also super easy to explain. The polynomial method would require separate polynomials for acceleration ramp up, constant positive acceleration, acceleration ramp down, constant velocity, deceleration ramp, constant deceleration, and final deceleration ramp. That seems harder to keep track of.

The table calculation method also gave me an easy way to work in motor equations. You get more torque, and therefore more acceleration, from your motor at lower speeds. If your profiling takes this into account, you can go much faster. Without taking this into account, you must limit your max acceleration to less than the robot can actually achieve so that as it accelerates, it can still achieve the same acceleration.

The solution to the dc motor equations for a pulley driven lift is

v = (r * w_n * (a_g * r * m - T_s)/T_s) * (1 - e^(-(t * T_s)/(r^2 * w_n * m))))

where v is velocity, r is pulley radius, w_n is no load speed (rad/sec), a_g is acceleration of gravity, m is mass carried, T_s is stall torque, and t is time.

If you have lots of time, you could integrate this again and find the position equation, and use that to determine your motion profile.

However, that's difficult, and you can come up with a simpler equation, v * a = k, where k is some constant specific to your setup. This means you either get a large acceleration or a large velocity, but not both at the same time. This equation is only valid when a is less than the acceleration achieved by stall torque and v is less than the no load speed. This is really easy to add into your calculations for the constant acceleration portion with

a = k/v_prev

If you have a large velocity, you can't accelerate as fast.

This would let you achieve the most aggressive and fastest profile possible for when speed really matters.

[Ether]

Originally Posted by Jared

However, that's difficult, and you can come up with a simpler equation, v * a = k, where k is some constant specific to your setup. This means you either get a large acceleration or a large velocity, but not both at the same time. This equation is only valid when a is less than the acceleration achieved by stall torque and v is less than the no load speed. This is really easy to add into your calculations for the constant acceleration portion with

a = k/v_prev

If you have a large velocity, you can't accelerate as fast.

This would let you achieve the most aggressive and fastest profile possible for when speed really matters.

If you can experimentally (or analytically) determine the maximum speed vmax and the maximum acceleration amax, you could try using a linear relation:

acceleration = amax*(1-speed/vmax)

... and that would be easy to numerically integrate in a spreadsheet.

When speed=vmax the acceleration is zero, and when speed=0 the acceleration is amax.

EDIT: added screenshot and XLS for user-selectable accel & speed limiting

[Jared]

I've attached an excel spreadsheet with a few of the motion equations I've come up with so far. For inputs, they take motor constants. If you have a gear reduction before the motor constants, you need to come up with a new set of motor constants that match the characteristics of the output of the gearbox.

The first sheet is for some mechanism which is always fighting gravity in the same direction it is trying to move. The speed under load after a few seconds matches the loaded speed values calculated by the JVN design calculator.

The velocity is determined exactly, not by numerical integration. I don't know how to integrate that velocity function (though I'm sure it's possible), so I did what you suggested in your previous post.

The second sheet calculates velocity and position with explicit functions for each, but does not take into account gravity. The velocity function had a less complicated integral. This would work for a drive system, but not for an elevator. I like this better because the robot could simply plug in the time elapsed into the position function to determine its setpoint.

If you're interested in seeing my work, I could take a picture of it.


Our 2015 elevator has these values
stall torque 25 nm
mass 35 kg
free speed 32 rad/sec
sprocket radius .022 meters

It's way overpowered, and does achieve full speed in less than .25 seconds under load.