Makes a lot more sense - thanks!
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)
Motion Profile - Copioli Method.xlsx (11.7 KB)
Motion Profile - Copioli Method.xlsx (11.7 KB)
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?
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.
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.
Ah, I didn’t realize the Ka term was necessary.
That makes sense then. Thank you for the clarification!
I added some slider controls to Paul’s spreadsheet.
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)
Are you sensing and limiting motor current, or are you sensing acceleration?
I’m limiting change in motor current.
Technically, acceleration is a function of current, not rate of change of current.
I suspect what you mean is you have a rate limiter on your motor commands?
If you try, I think you will find the motion profile algorithm takes less memory usage, is much more accurate, and makes PID much easier to tune.
*I’m ruminating why a motion control algorithm plus PID would take less memory than a PID without motion control. What am I missing?
Without knowing exactly what Paul is thinking, I am assuming that the PID control algorithm does not work as well as expected and the necessary software additions required to get desirable PID performance are greater than the proposed motion profiling software and the “out of the box” PID software.
Your plot shows me exactly why you wouldn’t want to do it that way. Look at the overshoot at the end of the trajectory. You can do a lot better with a trapezoidal profile, for a similar space/time cost.
Without reading your implementation, I would also ask how your robot handles the case when both sides of the drivetrain are artificially or physically saturated and you have a heading error. You somehow have to deal with the heading error. You can either try to close the loop on heading so that you are still aiming for the same point in the x, y, theta configuration space, or you have to eliminate heading errors very quickly to avoid missing your goal.
What I meant was that the motion profile algorithm plus PID will take less memory than the method he was using to sense and control acceleration. The motion profile filter is very few lines of code and was designed to run real time back in the early 90s. It is very clean and fast.
I’ll try the motion profiling method and post my results.
Edit: One question: What’s the easiest way to tune velocity PID?
I know that 254 has their drive code implemented into their 2011 robot code, but is there anybody willing to post drive code implementing this feature in the most stripped down form possible?
Being able to see this feature (in C++ or Java) singled out will really allow me to see what is going on here.
I think it will help everybody gain a more pragmatic understanding of this motion profiling implementation.
I looked through 254’s code but was very confused. First, I don’t really understand C++. Second, I don’t think that this is the simplest implementation of motion profiling. I mostly understand how Paul’s system works, but am not sure how his algorithms translate into real time motion profiling code.
Would it be possible for someone to post pseudocode for his motion profiling technique?