> There is a book by Jacob Tal, called "Motion Control by Microprocessors", published by Galil Motion Control. Thanks for the info. I just ordered it from amazon.com, they say 3-4 weeks. I am also reading the data sheet on the National part.

 

This is the classic rectangular approximation PID that DSPs use. The trapazoidal approximation may be better. How does the rectangular or trapazoidal approx. PID do about the integral winding up when the output is saturated? Using the traditional PID one can keep the integral term from winding up because it is kept separate. Just something to consider.

 

Kip, Your problem doesn't sound so much like a PID control problem as a trajectory generation problem. You need to define your trajectory as a single path from A to B and then implement a coordinate system involving the two motors to follow that path. Straight line movements are easy, drive both motors the same distance (PID closed on position rather than velocity) if you do velocity, you will lose accuracy because you will be forced to integrate the velocity command to keep track of position. Turning the robot is simply a matter of speeding up one motor or slowing down of a motor or a combination of the two. You can easily calculate the angle / heading of the robot about the center of rotation as a function of wheel / axle geometry. Create a trajectory that gets you from point A to Point B, define straight line segments and curves, send these as waypoint commands that are updated each servo cycle to each of the motors. Each motor should have a position PID loop to ensure the trajectory is followed. Sounds like a fun application to me. Ken Brown Applied Motion Systems, Inc. http://www.kinemation.com

 

Peter, You can have the best of both worlds if you have a feature that turns on the integrator when the commanded zero speed bit gets set . . . . Ken Brown Applied Motion Systems, Inc. http://www.kinemation.com

 

Hello Rolf, On Tuesday, March 27, 2001, 9:34:00 AM, Rolf Gerste <[email protected]> wrote: >> PWM = PID // His case RG> Right Case >> PWM = PWM[i-1] + PID // My case RG> Wrong Case if Ki is zero, there are cases it can be used in practice... (at least if both Ki and Kd = 0, exactly... Of course, strictly, it is not a classical PID(PD) control, even if the formula is the same And there is a few circumstances the programmer has to keep in mind before he makes a decision... frequency of the control loop, inaccuracy and type of the feedback sensor, motion type, etc. -- Best regards, Vladimir

 

Kipton, > In almost all of our cases, we have a DC motor driving the wheels, an > optical encoder providing ticks for portions of a rotation of > the wheel, > and Pulse Width Modulation (PWM) for controlling the speed of > the motor. > We desire to be able to know our position, and be able to run a course > autonomously as fast as possible. So how do you do this best? > What is the best form? I think your main problem is to get the velocity profiles for moving/turning of your robot for both motors. - Move Profile If you want to move a wheel a certain distance you ramp up velocity to a preset speed maintain the speed and ramp down to stop. From physics we know that the area under the velocity curve in time is the moved distance (s = Integral(dv/dt)). In the digital world you will have a fixed cycle time to set new values of your profile and compute the PID controller. Depending on accuracy of movement it will be longer or shorter. For your application 1-10ms (100-1000Hz) seems to be sufficient. I now imply that you use some kind of microcontroller (by the way: do you?). With a little math you can calculate a velocity profile for a given distance, cycle time, max. velocity and acceleration (I can give you the equations). When turning the robot comes into play, things get a bit more complicated. Sorry, I can't help you with that. - Velocity Controller Then you have to look if a velocity controller is sufficient or you need an overlying position controller. A DC motor is a velocity device. Give it a certain voltage (PWM value) and it will turn at a certain speed depending on the load. Without feedback you will not know how fast the motor will turn. With a velocity controller in the form: PWM = PIDvel you can compensate that. - Position Controller If the motor cannot reach a given speed, because of too much load, the velocity controller may not be able to maintain your profile and you will not reach your end position. If this can not be ruled out you need an overlying position controller in the form: Velocity = PIDpos The position controller will now needs a 'position profile' that is the integration of your velocity profile. The output is a velocity for the underlying velocity controller. Now even when the velocity cannot be reached due to load you will get a position error and the integral part of the position controller will compensate that. Both controller need some attention on overload conditions. Limiting the I part of the controller helps here. - Stepper Motor Things are different if you use a stepper motor. This is a position device. You can directly set a position without using any controller. Simplified: Step = R * Position With a ratio or gear constant R that translates positions in motor steps. The same profile as for the DC motor position controller can be used. Since a stepper motor itself has a rather high resolution (even better if you are use microsteps) you may not need any controller and encoder at all! If accuracy is not sufficient you can easily add a controller into the above equation that uses the old equation as a feed forward term: Step = R * Position + PIDpos Since the motor is already more or less on the move profile the controller just has to compensate a relatively small error. I hope this helps and we will hear from you again. Greetings, Christian Grebe Dipl.-Ing. ITK Dr. Kassen GmbH Positioning- and CNC-Controllers Beim Eberacker 3 D-35633 Lahnau Germany Tel: +49 6441/6 50 05-14 Fax: +49 6441/6 50 05-29 EMail: [email protected] WWW: www.itknet.de

 

There are a host of things that can effect the most efficient path to take, starting with cubic splining at the bottom to reverse kinematics at the top. Perhaps someone (Ken?) who is better equipped technically than I can explain reverse kinematics, but the point is that there are many options available to you when moving in a three dimensional world, and your ability to make use of them depends on the sophistication of the controller. Controllers today can have multiple DSPs on each channel (axis) allowing some preprogramming of algorithms for that particular axis as well as controlling the individual PID loop in near real time (not sharing that chore with the central processor. These individual axis functions can be further enhanced by providing FPGAs on the axis that can be used to manipulate input data from various types of feedback. Central processors can be basic DSPs, RISC type or even the powerful MIPs type, which will allow multiple programs to be run simultaneously. All of these factors effect the rate and path which you use to make your robotics move. Bob Close Executive V.P. Precision MicroControl Corp TELE 760-930-0101 FAX 760-930-0222 [email protected]

 

Finally a post that goes to the heart of Kiptons real problem. Forget the PID, until you have a decent model of a trajectory generator you are wasting your time. Think modular. Trajectory Planner . . . map the desired PATH of the vehicle. Coordinate system . . . define a function that can convert the PATH into COMPONENTS for each motor. i.e. straight moves = both motors traveling same displacement. etc. PID . . . calculated commanded PWM output based on the PID filter results from comparing the COMPONENT to the FEEDBACK. This should obviously be done separately for each motor. Ken Brown Applied Motion Systems, Inc. http://www.kinemation.com

 

> Finally a post that goes to the heart of Kiptons real problem. Forget the PID, until you have a decent model of a trajectory generator you are wasting your time. So what you are proposing is that I should not tell the robot to go forward 10 feet, and the control loop deals with the ramp up velocity, going the maximum speed both wheels can maintain to go straight, and then the ramp down to a stop at 10 feet. Instead, at every control loop pass (like 20 - 30 Hz) I should give the right wheel and the left wheel their desired position at that time interval, and build a trajectory of desired positions that takes into account ramp up speed and holding at maximum speed and then the ramp down speed as I approach the 10 foot mark. At first glance this seems less desireable, the two wheels have got to be synchronized to go straight. This should not be a problem, until you start approaching maximum speed and the maximum speed of one motor is faster than the other. So then you have to modify the trajectory to not go as fast, which is a form of feedback, so choosing the desired trajectory is in the middle of the control loop. Which is what I thought the approach was trying to simplify. Kip

 

I havn't been following this thread, but caught the following post and have this comment. "New CV = Old CV +/- adjustment for each scan" is effectively a time integration. If CV equals control output, it is a way to do the I part of a PID calculation. The "+/- adjustment" (presumably a gain x deviation) by itself is a way to do the P part of a PID calculation. Using "New CV = Old CV +/- adjustment for each scan" works real nice as a "floating" type controller for motorized valves and some non-linear control situations. Especially, if you add setpoint deadband and hold at max/min, or kill, output limiting. Al Pawlowski, PE dba ALMONT Engineering Baton Rouge, LA USA

 

Bob, Good motion controllers (e.g. Delta Tau UMAC /PMAC) can manage all the items you listed on 32 Axes simultaneously using a single DSP with no support what so ever from the host CPU. Ken

 

Ken, Perhaps I should have defined what I meant by cpu... I meant the main processor on the MOTION board not the computer. You're right however, PMC, Galil, and Acroloop all have the ability to act as stand alone and will continue long after the windows program has gone blue screen... in fact PMC can stack a dozen 8 axis boards and run 10 programs of multiaxis function simultaneously. But the addition of individual axis DSPs to handle the PID loops independently means that the main processor on the motion board does not get bogged down with loop updates for each axis... It can do its job of trajectory planning etc. without being tasked for the PID functions. This means that when you add axis to a board you do not loose performance. The individual DSPs in conjunction with the FPGAs can also serve to handle individual axis resonance problems through notch and band pass filtering and in situations of repetitive motion where the trajectory is the same, but the distances vary (i.e. wire bonding), the axis DSP can handle the entire pattern, thus shortening the implementation time. Of course all of these functions can carry a price and are very specialized in their applications, but it does serve to demonstrate the point that PID isn't the only thing effecting performance. Bob Close Executive V.P. Precision MicroControl Corp TELE 760-930-0101 FAX 760-930-0222 [email protected]

 

Kipton, You are getting a better picture of how this type of problem is typically approached. Now ratchet up the loop closure rate to 500Hz minimum (2-3kHz is where the big boys play) and you will be ready to start worrying about PID loops. Trajectory generation is not as tough as it sounds. This is where you ramp up from a stop with a zero jerk hermite spline curve (obeying your system acceleration limits) / heck, just start out with a linear ramp and you will be miles ahead of the straight PID approach. . . run at constant velocity (obeying your motor velocity limits) and decel using the same curve that you used to accel. Define these trajectory segments with mathematical models that will allow you to integrate dt by the loop closure rate and plug the new waypoint f(t) right into the command register of the PID. Now if your PID has any level of performance, you don't care about error, you only care about your commanded position. If you defined your path accurately, you only need worry about the small position error that your PID allows, this is a much smaller error than what you have to tolerate when trying to control a loop with a huge step input and tune the output of the PID to manage ramping up and down from a stop. Ken Brown

 

Hi Bob, Thank you for your clarification of tasks. I am most familiar with integrating Delta Tau products and until we started integrating other products I was not aware that other controllers used an on-board CPU to do trajectory planning and general housekeeping chores while leaving individual axis DSPs to manage the loop closure and specialized PID loop functions. I have since gravitated back to the Delta Tau controller because it does do all these functions on a single DSP, multiple com ports, display driver, trajectory planning, inverse kinematics, lookahead, 32 axis loop closure (at 2.2kHz default) with notch filters, encoder compensation tables, cross axis compensation, motor commutation with current loop closure . . . etc. etc. etc. . . . all done on a single DSP. When I look at other products that require the expense of a housekeeping CPU and dedicated DSPs . . . I look at $ signs. Ken Brown Applied Motion Systems, Inc. http://www.kinemation.com

 

Kip, You and your friend are both right depending on the case. If you are making a *velocity control* as in your example, you have to add a constant level. But if you are making a *position control* (like controlling a fuel actuator) then you should not. The key point is coming from the fact that you can add a constant to the integral part of the PID equation depending on initial conditions and the process, since: Int(adx)=ax + K and you can/should choose K to be 0 or non-zero. > Is the PID equation is used to adjust the output up or down, or does it produce the output value directly? > In velocity control, PWM(i)=PWM(i-1)+PID(i) In position control, PWM(i)=PID(i). As you can see, PWM(i-1) is a constant at instant i (because it already happended before), so you and your friend are both right. By the way, I think this is a very nice question and at the first sight I thought that you must be wrong. Best regards, Hakan Ozevin