Re: traject planner

[shackle <shackle-at-cme.nist.gov>]

On Tue, 14 Nov 2000 18:20:26 -0500 (EST), Lawrence Glaister said:

> Greetings Luc
>  its interesting you are seeing the speed spikes. I am running a CVS version from around Nov 4. I see these spikes as well using stepper drive. As you mention, the spike seems to come at the end of a move... its almost like the motion blending has a problem. I have been trying to track it down as it can be a real problem for steppers. It only happens at the end of some of the moves and where an x move blends into a radius. I have been using the cds.ngc demo program to test with and there are at least 10 places in the code where the x axis drive seems to take off with no regard to the programmed max speed or accel. I'm not sure if anyone else sees this problem. It may be happening on other axis, but my test setup only has 1 stepper on the
>  x drive. I see the problem with both the old and the g code interpreter, so I dont think it is a g code related problem. In my test setup, I have the feed speed at 45ipm. I thought for a while that one of the real-time tasks was getting behind and playing catch-up, but I rearranged some of the task intervals to make sure there was some available CPU time with no effect. The resulting accel is way beyond the programmed max, which I have at 1.0. Does anyone see this problem in the aug11 release? or in older releases? 

Oddly enough I had just started to work on this.
 
I'll forward the email discussion I had  with Fred Proctor about this just the
other day, to help muddy the waters.

It looks like there were no significant diffs to tp.c since we checked it into
sourcforge in June. So the preAMax stuff, which I suspect caused the problem 
must have been added before June.

In some cases the output of the trajectory planner I think still gets clipped
at  a lower level. Which could mask the problem for many but not all moves.



A short term work around that might improve things would be to replace preAMax
with 0.0 in the call to  

tcSetPreMax( . . .)  

in the function tpRunCycle in tp.c

--- Will



-- Forwarded Message ---
 From: shackle <shackle-at-cme.nist.gov>
 To: proctor-at-cme.nist.gov
 Sent: Tue, 14 Nov 2000 11:17:16 -0500
 Subject: posemath/trajectory planning changes

( posemath nonsense ommitted . . .)



For the trajectory planning, currently the deceleration from the 1st move is
added to the max accell of the second move.

The result is that when the the moves are in the same direction we are blending
in -aMax + 2aMax. Causing an accelleration of aMax. even though the starting
velocity might be already be vmax and reaching a total possible velocity of
1.5*vMax.

When the moves are in oposite directions we add -aMax - 2*aMax, so the total
deccelleration can be 3*aMax.


I would suggest that each cycle the tragectory planner keep not just the scalar
accelleration and velocity  but an accelleration vector and velocity vector,
and adjust preVMax and preAMax so the maximums are really honored.

Objections? Comments?


-- Will

-------------------------------------------------------------------------------
----------------



--- Forwarded Message ---
 From: shackle <shackle-at-cme.nist.gov>
 To: Fred Proctor <frederick.proctor-at-nist.gov>
 Sent: Tue, 14 Nov 2000 13:06:19 -0500
 Subject: Re: posemath/trajectory planning changes



>  > I would suggest that each cycle the tragectory planner keep not just the scalar
>  > accelleration and velocity  but an accelleration vector and velocity vector,
>  > and adjust preVMax and preAMax so the maximums are really honored.
>  
>  This sounds like a good idea, but I'm not sure that what you said:
>  
>  > even though the starting
>  > velocity might be already be vmax and reaching a total possible velocity of
>  > 1.5*vMax.
>  
>  is true. If it is, we'd notice a speed increase during the move on line
>  N03:
>  
>  N01 G0 X0
>  N02 G1 X1 F60
>  N03 X2
>  
>  Is there a speed increase to F90?


Attached is a log created from the output of testtp that might help explain. (
I have modified testtp to print accelleration and velocity, and not print y or
z if numNumbers == 1.)	I gave it two moves before letting it run so it would
blend  goto 4.0x with goto 8.0x. with vmax  = 1.0 and amax = 0.5.

At x=3 when the first move starts to decellerate but the second move starts
being blended in and  over componsates with 2 times the accelleratation so the 
full system starts to accellerate even though it was already moving at vmax. 
When the velocity of the second move has hit vmax and the velocity of the full
sytem is at 1.5, the system immediately starts to decellerate because the 1st
move is still decelerating until the velocity of the first move is at zero and
the velocity of the full system back to vmax. After this point only the second
move is blended so the velocity  remains constant at vmax   over most of the
move to x=8.0 until the final decelleration.

So back to your question  you don't get a constant speed increase to F90.
instead there is a triangular bump with the peak of the triangle at F90.

-------------------------------------------------------------------------------
---------------

>  
>  --Fred
>  



>  =======================================================
>  Lawrence Glaister VE7IT             email: lg-at-jfm.bc.ca
>  1462 Madrona Drive                  http://jfm.bc.ca
>  Nanoose Bay BC Canada  
>  V9P 9C9                         
>  =======================================================
>    ----- Original Message ----- 
>    From: Luc Vercruysse 
>    To: Multiple recipients of list 
>    Sent: Tuesday, November 14, 2000 2:32 PM
>    Subject: traject planner
>  
>  
>    Hi ,
>  
>    I am developping an "intelligent servo driver"...(I try it). It is a driver  with a microcontroller on board (89S8252 from atmel) and a ispLSI 1016 (LATTICE) that contains a quadrature decoder + counter, a pulse width modulator that feeds a H-bridge to let turn the motor.
>    I want to acces the board with my parallel port in EPP or ECP mode (to speed up data transfert and to acces more than one device). 
>    The microcontroller receives the goal positions  from the EMC-interpolator, reads its actual position of the encoder, and generates a PWM signal (that feeds the H-bridge => motor) using the PID stuf from EMC (using fixed point math).
>    Right now I am making a prototype.
>    To test the microcontroller software, I separated the trajectory planner and interpolator.
>    Following program is suposed to move the X and Y axes to make 2 lines.
>    I capture positions and speed in a file and plot it out using GNUplot.
>    The postions seems to be OK, but when I plot the speed, there is a "spike" (speed increments up to 150% of its programmed speed) on the point where the Y-axis starts turning. 
>    Is this normal , or is there a bug in my test program ??
>  
>  
>    PS. As soon the prototype is finished, I'll drop it in the drop box.
>     
>    Luc Vercruysse.
>     
>     
>    void main(void)
>    {
>  
>     FILE *data;
>     CUBIC_STRUCT xCubic;
>     CUBIC_STRUCT yCubic;
>     CUBIC_STRUCT zCubic;
>     PID_STRUCT xPid;
>     PID_STRUCT yPid;
>     PID_STRUCT zPid;
>     PID_STRUCT Pid;
>  
>     double OutPut[3];
>  
>     TP_STRUCT queue;
>     TC_STRUCT tcSpace[100];
>  
>     PmPose pos;
>  
>     PmCartesian center;
>     PmCartesian normal;
>     PmPose end;
>  
>     double vMax = 0.1;
>     double aMax = 1.0;
>     double CycleTime = 0.01;
>     double vMaxAxes = 5.0;
>     double SpeedX, SpeedY, SpeedZ;
>  
>  
>     data = fopen("Data.dat","wt");
>  
>  
>  
>     tpCreate(&queue, 100, tcSpace);
>  
>  
>    // set traj parameters
>  
>     tpSetCycleTime(&queue, CycleTime);
>     tpSetVmax(&queue, vMax);
>     tpSetAmax(&queue, aMax);
>     tpSetVlimit(&queue, vMaxAxes);
>  
>  
>     cubicInit(&xCubic);
>     cubicSetSegmentTime(&xCubic,CycleTime / 10);
>     cubicSetInterpolationRate(&xCubic,10);
>     cubicInit(&yCubic);
>     cubicSetSegmentTime(&yCubic,CycleTime / 10);
>     cubicSetInterpolationRate(&yCubic,10);
>     cubicInit(&zCubic);
>     cubicSetSegmentTime(&zCubic,CycleTime / 10);
>     cubicSetInterpolationRate(&zCubic,10);
>  
>  
>  
>     pos.rot.x =  0.0;
>     pos.rot.y =  0.0;
>     pos.rot.z =  0.0;
>  
>  
>     pos.tran.x = 1.0;
>     pos.tran.y = 0.0;
>     pos.tran.z = 0.0;
>     tpAddLine(&queue,pos);
>  
>     pos.tran.x = 2.0;
>     pos.tran.y = 1.0;
>     pos.tran.z = 0.0;
>     tpAddLine(&queue,pos);
>  
>  
>  
>     while(!tpIsDone(&queue)) {
>  
>  
>       while(cubicNeedNextPoint(&xCubic)) {
>         tpRunCycle(&queue);
>         pos = tpGetPos(&queue);
>         cubicAddPoint(&xCubic,pos.tran.x);
>         cubicAddPoint(&yCubic,pos.tran.y);
>         cubicAddPoint(&zCubic,pos.tran.z);
>       }
>  
>  
>       pos.tran.x = cubicInterpolate(&xCubic,0,&SpeedX,0,0);
>       pos.tran.y = cubicInterpolate(&yCubic,0,&SpeedY,0,0);
>       pos.tran.z = cubicInterpolate(&zCubic,0,&SpeedZ,0,0);
>       fprintf(data,"\n%f %f %f %f",pos.tran.x,
>        pos.tran.y,
>        pos.tran.z,
>        sqrt(SpeedX*SpeedX + SpeedY*SpeedY + SpeedZ*SpeedZ));
>     } 
>     fclose(data);
>    }
>  

-- 
-------------------------------------------------
William Penn Shackleford III			shackle-at-nist.gov
National Institute of Standards & Technology	Tel:	(301) 975-4286
100 Bureau Drive Stop 8230			FAX:	(301) 990-9688
Gaithersburg MD  20899	USA
http://www.isd.mel.nist.gov/personnel/shackleford/
Office Location: Bldg. 220 Rm A253