Re: Motion Profiling
 

Technically, it's just the derivative of acceleration, but yes, that is effectively correct.

You just need to get them within the robot's capabilities -- if you're too close to your limits, then you'll get wheel slippage anyway, throwing off your distance measurements. You could probably get close enough just by looking at your wheel's CoF.

I think that motion profiling would be slower than directly doing PID or PD on position, since motion profiling usually has a more gentle acceleration. One tradeoff, however, is that where pure PID/PD would spin the wheels on acceleration, motion profiling should prevent wheel slippage.

To everyone: Please let me know if I've made any mistakes in my interpretation of "motion profiling" -- I personally see several ways to do this, so I hope I am responding with the correct interpretation in mind.

Re: Motion Profiling
 

A perfect motion profiler (and appropriate controller) will get you to your goal at least as fast as any other method. If the acceleration limit in your profiler is right on the cusp of the stick-slip point for the wheels, you have essentially implemented a form of traction control for your robot.

Of course, the stick-slip point depends on a lot of things (tread wear, carpet irregularities, the amount of weight being carried by each wheel instantaneously, etc.), so in practice you usually want to back off on the acceleration limit by a safety margin. The extra repeatability is worth the handful of milliseconds longer it takes for your robot to get to its goal.

In general, if all your feedback controller is doing is removing noise/error from your planned trajectory, you're going to have a good time. This is why feedforward gains are so powerful - in the absence of any disturbances, you theoretically will get exactly where you want to go without needing ANY feedback!

Re: Motion Profiling
 

Tom,

I am sitting in the HK airport so I have some time to kill. I will try to go through a simple double linear filter motion profile scheme. This is the fastest way, computationally, to do real time motion profiling. However, for FRC autonomous mode applications, the real time filtering really isn't required.

Some definitiions:

itp = iteration time (loop time)
T1 = Time, in ms for the first filter
T2 = Time, in ms for the second filter
FL1 = Filter 1's length, unitless. Must be an integer. FL1=RoundUp(T1/itp)
FL2 = Filter 1's length, unitless. Must be an integer. FL2=RoundUp(T2/itp)

Vprog = Desired Max Speed, ft/sec (can be any units you desire, just be consistent)

Dist = Desired travel distance, ft (can be any units ...)

T4 = Time, in ms, to get to destination if always at Vprog. T4 = Dist / Vprog
N = Total number of inputs to the filter, Integer. N = RoundUp (T4/itp)

That is really all you need to do the filtering so here is an example with numbers:

Vprog = 10 ft/sec
Dist = 4 ft
itp = 50ms (doing this to make the math short and easy)
T1 = 200 ms
T2 = 100 ms (this makes it an even trapezoid, as this number increases, it becomes a more traingular accel profile)

T4 = 4/10 *1000 = 400
FL1 = 200/50 = 4
FL2 = 100/50 = 2
N = 400/50 = 8

Ok, now time to fill the filters. How this works is simple. FIlter 1 has FL1 number of boxes, Filter 2 has FL2 # of boxes, and your inputs are N # of 1s until all filters are cleared.

Step # Time Input FL1 FL2 Output (Vel)
1 0 0 0 0 0 0 0 0 0 * Vprog
2 .05 1 1 0 0 0 0 0 1/6 * Vprog
3 .10 1 1 1 0 0 0 0 1/3 * Vprog
4 .15 1 1 1 1 0 0 0 1/2 * Vprog
5 .20 1 1 1 1 1 0 0 2/3 * Vprog
6 .25 1 1 1 1 1 1 0 5/6 * Vprog
7 .30 1 1 1 1 1 1 1 1 * Vprog
8 .35 1 1 1 1 1 1 1 1 * Vprog
9 .40 1 1 1 1 1 1 1 1 * Vprog
10 .45 0 0 1 1 1 1 1 5/6 * Vprog
11 .50 0 0 0 1 1 1 1 2/3 * Vprog
12 .55 0 0 0 0 1 1 1 1/2 * Vprog
13 .60 0 0 0 0 0 1 1 1/3 * Vprog
14 .65 0 0 0 0 0 0 1 1/6 * Vprog
15 .70 0 0 0 0 0 0 0 0 * Vprog

This is now your velocity command. Some interesting statistics:

Total time to end point = (N + FL1 + FL2)*itp
Total time to Max Speed = (FL1 + FL2)*itp
Theoretical time to end point = N*itp. This now corresponds to the time when decel starts.

In theory, if your itp time is short enough, then you can simply do a velocity PI routine on each of these commands in the Jag and get great position control. In addition, you can manipulate the ratio between T1 and T2 to get different Velocity trajectories based on your robot's capabilities. At FANUC, the T1 = 2 * T2 was pretty much a golden rule, but I violated it once or twice on specific painting robot models.


Let me know if you have any questions.

Paul

Re: Motion Profiling
 

Paul,

Thanks for sharing that. That's a very elegant way to do it.

You say about T2, "this makes it an even trapezoid, as this number increases, it becomes a more traingular accel profile". I don't follow. In your spreadsheet I can't see the difference between the two filters (to me it looks like one filter of length FL1+FL2).

Re: Motion Profiling
 

Jared,

Graph acceleration vs. time and you will see what I mean. Now I did just do that from memory while sitting in an airport so there is a chance I missed a step. When I get back to my notes I will make sure what I put in this post is correct.

Edit:
Yep, I missed a step. After filter 1 you are supposed to sum filter 1 and divide by the number of steps in filter 1 (in our case, 4) and use that as the input to filter 2. Everything else stays the same. I attached a new Excel file. The resolution of this example stinks so that is why you get the chop in the accel curve.


Paul

Re: Motion Profiling
 

Makes a lot more sense - thanks!

Re: Motion Profiling
 

Paul:

I turned your spreadsheet into something that lets the user more easily play with the various inputs and have everything update properly (OFFSET is my new favorite spreadsheet function). Once I played around with it for a couple minutes, it made perfect intuitive sense. Thanks again.

(Recommend making a scatter plot of Time vs. Pos/Vel/Acc and then changing values to visualize what is happening)

Re: Motion Profiling
 

How well would passing the position commands to a PD or PID positon controller work compared to the above suggestion?

Also, would you leave the Vprog, T1, T2 parameters constant for all movements (for traveling 1 ft, and also 100 ft?), or would you vary per distance?

Re: Motion Profiling
 

Adam,

I think passing position commands work too. One interesting thing to note is that you could do a cascading PID with pos PID in the crio and velocity in the jag.

The motion profile usually needs 2 types of parameters: regular and short motion. The short motion routine is for motions where T4 is less than T1 +T2. Other than that, the profile constants adjust the profile pretty well.

Re: Motion Profiling
 

Paul,

Thank you for posting your profile generator. It is fun to see how others do it and learn more.

You are missing a term. Ka will accelerate the robot as required, so it should in theory track the profile perfectly and never have any error. You are trying to get Kp and Ki to do the work of Ka.

Especially for the drivetrain, if you saturate your motors, you loose all ability to make adjustments. This quickly shows up as not having power available to correct for the robot turning. By providing a profile that will never ask for full power, you avoid this whole problem and can still steer nicely as you accelerate and decelerate.

Re: Motion Profiling
 

Ah, I didn't realize the Ka term was necessary.

That makes sense then. Thank you for the clarification!

Re: Motion Profiling
 

I added some slider controls to Paul's spreadsheet.




Attachment 13342

Re: Motion Profiling
 

I'm on my third rewrite of this sort of code for Vex and I've learned that position PID with no acceleration limiting makes robots do wheelies and that speed PID is very hard to tune. My third iteration uses position PID with acceleration limiting and seems to be working very well. I'm curious why you would want to use motion profiling rather than just PID, as a well designed and tuned PID controller with acceleration limiting approximates the results of a trapezoidal speed curve, as can be seen in the data from running my program on a Vex robot:

(Column C being position in inches and Column D being speed in inches / second)

Re: Motion Profiling
 

Are you sensing and limiting motor current, or are you sensing acceleration?

Re: Motion Profiling
 

I'm limiting change in motor current.