|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
Re: Motion Profiling
I think you're right -- I was making an assumption that I did not state in my post. I was assuming that the velocity feedforward gain (your Kv) is sufficient to cause essentially zero steady-state error without an integral component -- if it is less, than it is possible to have no overshoot. Also, I was not claiming that it would be unstable -- it would overshoot once then return to the setpoint in a perfectly stable manner.
Here's where I'm coming from, assuming Kv is as described above (i.e. would cause approximately 0 steady state error with no integral component): Say you're moving steadily (tracking a target trajectory) at a velocity of 1 (arbitrary units) -- your P, I, and D terms are all approximately zero, since you are at steady state. The Kv term is the majority of your control signal. Now suppose the target trajectory changes to a velocity of 2 -- this could happen either smoothly or instantaneously. Due to the system's inertia, it will find itself at less than the desired position. Therefore, the control system will correct, trying to bring the state towards the new setpoint. During this time, the previously-small I term will be growing as the errors accumulate. However, due to the Kv term, the necessary I term to maintain zero steady state error at the setpoint is approximately zero. Since the I term will not begin decreasing until it has overshot, it is guaranteed to overshoot. This overshoot may or may not be acceptable. Additionally, if Kv is less than the value I've described, then it would only decrease the Ki value necessary to prevent overshoot, and decrease the rise time of the controller, which may be desirable. |
|
#2
|
|||
|
|||
|
Re: Motion Profiling
Paul,
Thank you for posting your profile generator. It is fun to see how others do it and learn more. Quote:
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. |
|
#3
|
|||
|
|||
|
Re: Motion Profiling
Ah, I didn't realize the Ka term was necessary.
That makes sense then. Thank you for the clarification! |
|
#4
|
||||
|
||||
|
Re: Motion Profiling
Last edited by roystur44 : 22-12-2012 at 16:36. |
|
#5
|
|||||
|
|||||
|
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) Last edited by z_beeblebrox : 25-12-2012 at 01:51. |
|
#6
|
||||
|
||||
|
Re: Motion Profiling
Are you sensing and limiting motor current, or are you sensing acceleration?
|
|
#7
|
|||||
|
|||||
|
Re: Motion Profiling
I'm limiting change in motor current.
|
|
#8
|
||||
|
||||
|
Re: Motion Profiling
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? |
|
#9
|
|||||
|
|||||
|
Re: Motion Profiling
Correct.
|
|
#10
|
||||||
|
||||||
|
Re: Motion Profiling
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.
|
|
#11
|
||||
|
||||
|
Re: Motion Profiling
I'm ruminating why a motion control algorithm plus PID would take less memory than a PID without motion control. What am I missing? |
|
#12
|
||||
|
||||
|
Re: Motion Profiling
Ether,
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. Thoughts? |
|
#13
|
|||
|
|||
|
Re: Motion Profiling
Quote:
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. |
|
#14
|
||||||
|
||||||
|
Re: Motion Profiling
Ether,
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. Paul |
|
#15
|
|||||
|
|||||
|
Re: Motion Profiling
I'll try the motion profiling method and post my results.
Edit: One question: What's the easiest way to tune velocity PID? Last edited by z_beeblebrox : 26-12-2012 at 10:53. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|