# Fixed time positioning trajectory calculation - Page 2

#### Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

•  Subject
• Author
• Posted on
Re: Fixed time positioning trajectory calculation
In comp.arch.embedded,

I am sorry for that inaccuracy, please read an extra 's'. :-)

I have an upper limit for acceleration and an upper limit for decelleration
These two are not equal. The optimization should try to balance accel and
decel a little. Common sense would not set one at max while there is plenty
of room in the other. How to implement this comon sense in software is
something else. And this will indeed require more criteria. Fortunately
the balance is not really critical and I will just have to come up with
something usable.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Re: Fixed time positioning trajectory calculation

There will also be limits on acceleration and velocity set by the
motors, mechanics and motor drive.  Figure that going in you need
jerk, acceleration and velocity specs.  Then you need the distance
to travel.  Four variables going in.

The profile is then composed of four jerks: one at the beginning
and one at the end of acceleration and another two for the
deceleration.

For a full move you need to calculate the jerk magnitude, the
jerk time (all 4 are of equal time), the interjerk time (the
period of constant acceleration), and the interacceleration time
(the period of constant velocity). Four variables going out: no sweat.

It is all highschool physics.  It is not that hard.  It is a bit
tedious.  There are three cases of moves to consider:

jerk jerk
jerk accel jerk jerk deaccel jerk
jerk accel jerk constvelocity jerk deaccel jerk

The output of the profile is either a set of way points for a
position control servo or a set of step times for a stepper
motor.  If you are using a stepper you have the additional
requirement of having to be accelerating in the resonance
zone, this may add two more cases to the profiles if the max
velocity is > resonance speed.

This is from memory, so take with grain of salt.

I seem to remember an article on this in some freebie journal
(ISJ?), aimed at stepper motors IIRC.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Fixed time positioning trajectory calculation
In comp.arch.embedded,

That is exectly my problem. This is the usual technique and examples
can be found on the internet. But I have failed to find a technique
for making the move in a specific time, not nesceseraly the shortest
possible time.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Re: Fixed time positioning trajectory calculation

Just ratio real time to calculated time.  As an example: if you want
it 1/2 as slow calculate to where it should be at 1/2 second and
apply that position at one second, etc. etc.  Always calculate for
max jerk, acceleration and velocity and then scale back time and
you are guaranteed to be within the design limits.

You could optimize the system to move at the lowest jerk, accel and
velocity for a given move but you will need to specify how these
are to be balanced.

You have not mentioned the application of the algorithm: why is move
time important?  Is a fastest profile the optimum solution?

For most of us the goal is to find what works well and reliably
and get on with the rest of the design, "time's a wasting" and all
that.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Fixed time positioning trajectory calculation
In comp.arch.embedded,

The application uses a number of independent controllers that
will each get a 'move' command at the same time. The idea is
that the controllers spread out: They start at positions of, for
instance, 10cm apart and then at the command move to, lets say,
30cm apart. These movements must be synchronized to prevent
collissions and also to make it 'look good'. Furthermore, my
controllers must co-exist with other controllers that already
do this timed move.

Indeed. I've asked for some pointers to trajectory calculation and
I think I got more than enough. So now it's up to me to get the
application working OK with the information I got here.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Re: Fixed time positioning trajectory calculation

Well, that sounds weird.  Controllers as in little robot-like
things on a trackless surface or controllers in a multi-axis machine
tool or robot arms on an assembly line?

Do they start in a line and travel in the direction of the line, or
do they star at the periphery of a circle and travel away from the
center?

Ah, computerizing the Bohshoi Ballet: _everybody_ can now be replaced
with a machine ...

Well, that makes your concerns and constraints understandable.
That's a problem with Usenet, one only sees a little bit of the
problem, solves that, and then wonders why the solution is
unacceptable.

Are there any NC machining or industrial robotics discussion groups?
Although most of do motion control, we are not really the right

A post can ask "I need to calculate a free-body trajectory" and
it isn't clear if this is high-school physics homework or NASA
planning a Pluto probe with a double slingshot around the sun
and Jupiter.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Fixed time positioning trajectory calculation

You mentioned that you divide the problem up into three conditions:

There are these two controlling math expressions:  ('d' is the distance and 't'
is the time, each as specified)

(A)  Compare t with [2*sqrt(d/max_ramp)], which examines if you have exceeded
your acceleration limit using the triangular approach, and;
(B)  Compare t with [2*d/max_speed], which examines if you have exceeded your
velocity limit using the triangular approach.

If t >= [2*sqrt(d/max_ramp)] and t >= [2*d/max_speed], in other words the time
is long enough so that neither max speed nor max ramp is exceeded, then your
first case is satisfied and a triangular profile makes sense.  In this case,
your actual acceleration is easily computed as [4*d/t^2] and your peak velocity
as [2*d/t].

I agree with you that a trapezoidal profile will be used in some cases where the
specified time is met and you still don't exceed either max speed or max ramp.
This case takes place where t >= [2*sqrt(d/max_ramp)] and t < [2*d/max_speed]
and yet t >= [max_speed/max_ramp - d/max_speed].  So long as these are true, the
trapezoid should be used, with an acceleration of [max_speed/(t-d/max_speed)].

In the case where t >= [2*sqrt(d/max_ramp)] and t < [2*d/max_speed] but instead
now t < [max_speed/max_ramp - d/max_speed], then your acceleration limit would
have to be exceeded so the acceleration is instead set to max_ramp and your time
will be exceeded by the trapezoid, with a computed value for 't' being simply
[max_speed/max_ramp - d/max_speed].

But what about the case where t < [2*sqrt(d/max_ramp)] and t >= [2*d/max_speed]?
In other words, where your max speed isn't exceeded but your max ramp is?  In
this case, you need to accelerate at max ramp, instead.  But following a more
gentle slope will most certainly force you to take longer, however you will NOT
need or require a trapezoid -- as the triangular shape is still optimal, but
just longer.  This is a case where your narrow triangular profile is forced into
a squatter triangular profile by the acceleration limits, yet the area needs to
be the same, thus forcing a longer 't' or base.  But it is not a trapezoid, yet
you fail your time limit.  Here, the new time is [2*sqrt(d/max_ramp)].

In other words, there is another condition you haven't accounted.

It's more like:

A
\                <=                                      >
V  \------------------------------------+------------------------------------+
|                           T R I A N G U L A R                           |
+- - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - - -+
| neither max speed nor max ramp is  | max ramp is exceeded, but not max  |
| exceeded, so a triangular profile  | speed; so use max ramp as accel    |
<= | is used with a computed accel and  | and still hold to a triangular     |
| computed max vel that depends on   | profile to achieve d.  t will be   |
| the specified d and t.             | exceeded.                          |
+------------------------------------+------------------------------------+
|                          T R A P E Z O I D A L                          |
+- - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - - -+
| two cases: increasing the implied  | use max ramp as accel and climb to |
| accel may then exceed the max ramp | to max speed and hold.             |
>  | value -- or, it may not.  This     |                                    |
| becomes two cases, where 't' may   |                                    |
| be met, or not. See comment above. |                                    |
+------------------------------------+------------------------------------+

The above table is based on my conditions (A) and (B), above.

I may have misunderstood, though.  So correct me, as you see appropriate.

Jon

Re: Fixed time positioning trajectory calculation
In comp.arch.embedded,

A little too much I think. After a while I'd forgotten my highschool
math. Taking my mind of it for the weekend has helped.

[huge snip of sensible stuff]

Indeed, this is the case I discribed in my reply to Peter. It showed up in my
simulations. I've now solved it by accelerating for half the requested time with
max ramp. Certainly not optimal and results in a trapezoid lower than max speed.
Should be optimal if I use half of your calculated new time instead. But I'll
have to test how long the int-->float-->sqrt-->float-->int route takes or come
up with an alternate solution.

You understood perfectly, so no corrections required. Thanks for your input.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Toddlers are the stormtroopers of the Lord of Entropy.

Re: Fixed time positioning trajectory calculation

A trapezoid is not normally the desired profile, nor can it be attained
in 'real life' as it requires a step change in acceleration.

The normally specified profile results in the position following a set
of 3rd order splined polynomials with continuos 2nd derivatives:

Poly order    Phase
for position
3         Ramp up acceleration - 'Jerk' is held constant
2         Acceleration - Accel is held constant
3         Ramp down acceleration
1         Constant velocity
3         Ramp up deceleration
2         Deceleration
3         Ramp down deceleration

And this again is only an approximation to the optimum, but for most
practical purposes it is good enough.

The difference between the above profile and a trapezoidal velocity
profile is experienced every day when stopping a car: in a perfect stop
the car comes to a halt perfectly smoothly with no surge or jerk at the
end: a perfect sigh.  In a poor stop you are thrown forward and the car lunges
on
its suspension when the car comes to a rest: a bad cough.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Fixed time positioning trajectory calculation
On Mon, 24 Jan 2005 14:58:55 +0100, stef33d@yahooI-N-V-A-L-I-D.com.invalid

Thanks.  It was fun to imagine.

Jon