Re: [SeattleRobotics] Re: Robotic control algorithms
- From: "Kevin Ross" <kevinro@...>
You seem to be referring to any mismatch between desired and actual speed as
"overshoot". I'm simply referring to what is called "overshoot" in
discussions of controllers. For instance, the first graph in
shows overshoot. The word "overshoot" is used in that technical sense
throughout the article and throughout any discussion of PIDs.
> your simulation must beThe laws of physics predict that there will be overshoot using a P
> broken. Simple laws of physics will ALWAYs apply. There is a reason that
> exists, not just P.
controller that controls the position of a motor. The laws of physics
predict that there will NOT be overshoot using a P controller that controls
the speed of a motor.
There are many PID controllers on the web. Can you find one that
demonstrates overshoot in a speed controller. (Remember, most of the demos
are of position controllers.)
> Sorry, momentum is a force.Momentum is not a force in any physics textbook I've ever read.
> momentum is a force. A force over time causes acceleration.So "momentum over time causes acceleration"? Not in this universe.
> The momentums change inWhat does "the momentums change in speed" mean?
> speed is going to cause overshoot.
The laws of our universe make it so that a mass tends to resist a change in
velocity. That's momentum. A mass does not resist a change in acceleration.
That's why momentum causes overshoot in a position controller. And why
momentum cannot cause overshoot in a speed controller. There's a fundamental
difference between a position controller and a speed controller.
>>> 6) Changes in the mass of your robotThere will be a mismitch in speed which will be corrected by the controller.
>> That has no effect on overshoot. It only affects the rate of response.
> If your controller is outputting a force to keep a robot at a speed, and
> mass of the robot changes, the robot is going to accelerate.
There will be no overshoot.
If there is no sensor and power-control lag then a P controller will not
cause overshoot. Other "real-world" factors may cause a speed mismatch but
the controller itself will not cause overshoot.
> In the real world, the D term is low pass filtered for frequenciesI hadn't realised that. I guess it's obvious when someone points it out.
> above the loop response. The effect is to cap the D term gain for
> frequencies above the loop response.
I knew that D was sensitive to noise but I'd always been wary of filtering
it because filters introduce delay and delay causes oscillation.
> > To start with, there is a delay in the system of 1/20 sec at 20 Hz.(That was dpa's statement. And graphs and robot.)
> I took a guess from your statement: "Here is a plot of a PD velocity
> controller, showing the controller variables and output for
> 6 seconds at 20 Hz, 120 samples, for my SR04 robot."
> I jumped to the conclusion that the 20 Hz was the servo pulse updateAh. I was searching for something subtle in the graphs.
> rate. I hope my parachute opened.
> > If you remove the D term, check the overshoot and ringing.I just realised something. You were suggesting in your previous post that "a
> > I bet it will go up.
conventional D term cannot compensate for this [20mS] delay". Therefore the
D term isn't there for that purpose. It's a velocity controller so D is not
there because of momentum. It must be there simply for "balancing the I and
D terms". So if you remove both I and D then you wouldn't expect extra
overshoot and ringing.
And why can't D compensate for a fixed delay?