Motion profile generator.

[richard]

its mainly the idea's I'm experimenting with at this stage . this one is to increment the setpoint not at the pid update rate but a rate that suits the acceleration / velocity . in the example that would be every 8 mS. it would be fairly simple to clamp the velocity at any rate after the acceleration move (the pid offset is constant), short moves can easily be accommodated by calculatining a lower vmax, the decelerate phase would begin when distance remaining = or less than the total accelerate displacement and then the accelerate parameter blocks are fed into pid setpoint in reverse leaving no doubt at all for the final move. assuming of course that you can sync the real position with where the ramp-generator thinks it is but you have plenty of steps here to adjust out any error.
speed wise after the initial "move" parameters are calculated the array could be filled in on the fly if you have the processing time, I like the array idea because it applies easily to both acceleration phases for the move. biggest problem I can see is that the block rate could vary with each "move " (this keeps the numbers manageable) so you would to be able to provide an accurate but variable timebase for the block clock
its a work in progress

[HenrikOlsson]

Hi Richard,

this one is to increment the setpoint not at the pid update rate but a rate that suits the acceleration / velocity

Yes, I'd probably not run it at the PID rate either but for the purpose of the discussion it makes it easier. I probably wouldn't want to run it slower than say 50 times per second though since that would make the motion jerky. So, with a fixed array size of 64 the longest move possible is 1.28s

the decelerate phase would begin when distance remaining = or less than the total accelerate displacement and then the accelerate parameter blocks are fed into pid setpoint in reverse leaving no doubt at all for the final move

Exactly, but that's the big problem. Because if you don't start "playing back" the accelerate parameter block in reverse at exactly the right position you will reach zero velocity either before or after you reach the target position. And since the motor is moving at a velocity of 240 counts (in your example .pdf) per update the likelyhood of hitting (target position - 7620) (where 7620 is the total displacement during acceleration in your example) is slim.

Accelerating is easy, clamping the velocity is easy, moving at velocity is easy, even decelerating is easy. The hard part is ending up at exactly the desired position.
Your .pdf shows a nice ramp from 0 to 30000 in velocity. Now see if you can keep moving at the velocity and then, at any given "tick", start playing back the acceleration ramp in reverse and get to position 55727. To do that you need to start playing back the acceleration ramp in reverse exactly at position 55727-7620 but since the motor is moving at 240 counts per update you're never going to hit that exact location.

I'm obviously too far into my own thinking and can't see the forest due to the trees.....prove me wrong will you ;-)

/Henrik.

[richard]

I understand what your saying , but the array data is only required for the acceleration phases of each move the constant velocity part if one is required can easily just be a loop terminating when actual_position is less than or equal to target-ramp_length. so moves of any length are possible. I envision the deceleration would need error correction applied as
error = (actual_position - (target-(ramp_length-array[])) , each iteration would be adjusted by that error and the ramp_length decremented by the array [] increment . with potentially 60 odd iterations the final movement should be pretty good. (ramp_length=0 and error=0)=good
I agree about the jerkiness I'm hoping inertia will smooth some out , tell me if you feed a 200 step increment into the pid how many iterations till the error is 0 ? . my guess is that its more the 1 ,this may also do a bit of smoothing.

[HenrikOlsson]

Hi Richard,

tell me if you feed a 200 step increment into the pid how many iterations till the error is 0 ? my guess is that its more the 1 ,this may also do a bit of smoothing.

Yes, of course it's more than one, perhaps 20-200.
Exactly HOW many depends on the inertia of the system, the tuning of the PID parameter, encoder resolution, current limit of the drive etc etc etc. Aggressive tuning will cause overshoot and ringing, "loose" tuning will cause slow risetime and so on - as I'm sure you know.

I think that what you're aiming to do with recalcuating the array is basically what I'm doing as well - except I do it on the fly at each tick. What your method have going for it, provided it works of course, is that you don't use a division in the recalculation phase which will make it run fast. Then, on the other hand, if you need to recalcute the what's left of the array each tick (not sure if you need that or not?) then it might not be more effecient, I don't know.

Please do keep posted and I'll do the same - if I could just find the time to sit down and actually get it running...

Thanks Richard!
/Henrik.