Motion profile generator.

[Darrel Taylor]

Maaaannnnn ... This is harder than it looks.

Well, I have it going to the exact target position with zero error ... as long as it's able to reach the maximum velocity (the flat part of the profile).

But if the target position isn't far enough away, and it doesn't reach V_Max before it has to decelerate ... it overshoots the center, and with the maximum deceleration (A_Max) ... the velocity can't reach 0 until it's past the target. Arrrrrggg.

So on the shorter distances, I'll have to stop accelerating before it gets half way there, and calculate a new slope for the second half so that it stays under the maximum deceleration and gets the velocity to 0 before or at the target position. This way will make it decelerate slightly slower than it accelerates. Probably not noticable though.

Need more time.

[HenrikOlsson]

Darrel,
What, you need more time? Unacceptable, I need a working solution NOW ;-)
Seriously, take all the time you need, I appreciate any and all help!

I know, I found it quite a bit harder....

Since I don't know how you're actually aproaching this I'm just thinking out loud:
On the short moves I'm thinking how it would work out if the distance was simply cut in half and then the actual acceleration value tweaked to fit so we'd hit right on the centermark while accelerating. Then start decelerating at the same slope would make us end up at the target, right? I wonder what the worst case deviation from the set acceleration value would be... Code size and speed is obviosuly of interest as well...

I'm looking forward to see what you come up with!

Don,
Perhaps Darrels aproach is exactly what you're trying to explain but I must I admit I don't quite follow what you're trying to explain.
If an error at the end of the move of alwas less than A_Max is the best we can get then so be it but it sounds like Darrel is really onto something.

Thank you both!
/Henrik.

[amgen]

Henrik,
While the professional is working up the best scheme.

Question..... on the last itteration to stopping, can you subtract 'position now' from 'position desired' ?
and if so, can you move exact steps of the difference with the A value?

Don

[HenrikOlsson]

Hi Don,
If it always ends up short of the actual target AND the remaining distance TO the actual target is always less than A_Max then I could probably live with that. It means that it would always reach the actual target within a single "tick" from optimal.
However, I'd have to move it a speed equal to the actual distance to target, if moved at A_Max then it would overshoot in one tick - which in turn gives it a little bit of "S" at the end reducing the jerk. Might actually be good.

Thanks!
/Henrik.

[aratti]

Surely I will say something obvious, but since I did not noticed it in the above post, let me say it.

When the travel distance is less than twice the accelleration the trapezoidal profile become triangular and V max decrease, so that Vmax = tan(accelleration Slope) time the travel distance / 2

Cheers

Al.

[Darrel Taylor]

Here's what I'm up against ...

You can only adjust the acceleration.
I don't see any way to know what acceleration is required to make the half-way point end up exactly at an interrupt period.
It always ends up somewhere in the middle of a period.

If I new what the velocity would be at the halfway point, I could adjust the acceleration so it reaches the half-way point at exactly an interrupt period.
Except that since the acceleration changed, it won't be at that velocity at the half-way point anymore.
So I don't see any way of predicting the half-way point in order to use the same deceleration slope it uses for acceleration (the yellow line).

I can only change the acceleration at specific times, which coincide with the interrupt periods.
So if I recalculate the deceleration slope at period 6 before it reaches the half-way point, it creates the green line, which should end up at the target perfectly.

If I were to recalculate it after passing the half-way point, the deceleration rate would be higher, and violate the A_Max constraint.

The blue line is the overshooting profile, with it's velocity using the left axis.
The red line is the position, using the right axis.
The parameters for that run were ... A_Max=10, V_Max=100, Target=475.



I'm doing the green line.
But since the green line is actually a slower velocity, it will take longer than shown in the chart to reach the target.
But at least it is calculatable.

[timmers]

You can only adjust the acceleration.
I don't see any way to know what acceleration is required to make the half-way point end up exactly at an interrupt period.
It always ends up somewhere in the middle of a period.

Realistically, there will be thousands of intervals, the error will be tiny. We use an interval of 2mS and get a QC count of 1 at 15 RPM to 680 at 10,000 RPM. (using a 512 line encoded motor)
I would suggest to leave the acceleration at the demand rate, and work out when to stop accelerating and run at a constant speed or to decelerate in time to hit the target.

[Darrel Taylor]

Timmers,

You are talking about the control that Henrik is using. I'm sure the intervals are much smaller, and it includes a PID loop with an encoder feedback.
My task is to generate a "Profile" for that control to follow. A much different situation.

[richard]

I found this article on setting and using the qei /pcpwm modules and incorporated it into my scheme ,its worth a look the qei.h and motor_pwm.h in particular.

http://hades.mech.northwestern.edu/i...l_Port_Example

[timmers]

It is all relative to time. One thing not concidered yet is what to do if the servo has not achieved the demand. Do you run the servo faster/slower (velocity), harder/softer rate of change (acceleration & deceleration), longer/shorter (time) or forwards/back (position) to achieve the end target?

I assume you are attempting to modulate the velocity to achieve an end target at xx time whilst keeping the rate of change and max velocity within the set limits.

If you concider a velocity/time graph (trapezoid shape), with velocity as the height of the perpendicular at the current time, then the distance to travel is the area under the graph from the current position. (see graph in post #1)
The math to extract the velocity demand (in QC's / time period), at any given time, according to end target, defined limitations and servo error, is what you are trying to calculate.

Am I helping?

[richard]

this works on the real servo motor. what a difference the qei module makes ,and 14 bit pwm seems much smoother
pid rate now 1ms ramp rate 8ms with 49 steps , no attempt yet to handle short moves but long ones are good . fwd and backwards moves are good .
pos counter 24bit / vmax and accel are fixed constants so far

[HenrikOlsson]

Hi Richard,
I've actually made some progress myself too, just for fun I'm attaching a photo of my little testbed. It was designed a long time ago, at the time I was Little "afraid" of the PCPWM module so it's actually using the normal CCP module for the PWM output, 19.531kHz, 10bit resolution. What PWM frequency are you using to get 14bit with the PCPWM module?



Anyway, my code seems to work pretty good in the real world too. PID-rate is 1220Hz (derived from the PWM time base, 1:16 postscale). Initially I tried to run the profile generator "slower" than the PID but it really didn't want to fly properly. Now it's updating at the same rate as the PID and it's working pretty good. The CPU load is pretty high during deceleration but I'm "only" running it at 20MHz on this board so at 40MHz it'll be more relaxed. Acceleration, velocity and distance can be set arbitrarily.

Time is limited and motivation to work on it comes and go but I'll keep poking at it.

/Henrik.

[richard]

yes noise is an issue for 14 bit its 1.8khz , much quieter at 16khz and 10 bit res fosc is 32mhz (8meg rock *4pll)

I need to make a better test bed 600ma from the l293d is a bit limiting .

got the pid routine under 500us worst case using floats . I find that floats are easier to work with (mentally) for experimenting with but will go back to ints when I have things sussed out.

I'm not sure how I will go about implementing variable velocity or accel yet. I was just really happy to get " pid lock " and good position control to start with.

ps using the microchip c floating point library adds 8k bytes to the pgm its huge

[richard]

the idea was easier to implement than I expected. when the setpoint to target distance is less than the ramp_length + the constant velocity increment , rather than any fancy math I just set the setpoint to the target-ramp_length value. I just let the pid work the mechanics out for its self. after that its just a matter or playing the array back backwards to arrive dead on target .
I have included a poorly annotated sketch of my c routine,
the motor I want to use can only achieve 300 counts/sec (accel 2000 counts /s/s) and needs to not have a count for at least 30mS to guarantee 0 vel , therefore the pid loop is run @40mS intervals and the profile input is applied on every second pid loop. this works pretty well (motor inertia gives smooth motion) and it stops on target _+ 1 count (pid might need better tuning).
seems to me that motor/load characteristics really change the entire nature of the problem.
I'm yet to try this on a real servo motor my pid loops are taking 50-300 uS to run so hopefully a 1mS pid rate is possible , I think I will get some pic18f2431's and have a play with thev qei module

[richard]

I forgot to add that in my application the accel and max v will never change only the direction and distance therefore the ramp array will never need recalculating , for "short" moves i just reduce the number of elements played out. the pid tolerance seems pretty accommodating.
I want no overshoot no stalling and no hunting +- 4 counts is accurate enough . its controlling the really stiff and jerky air slide on the pid controlled wood heater in the lounge (its a matter of principle)