Fixed time positioning trajectory calculation

acceleration

requiring

Eh? If a>A for a triangle then you can't get to where you want to be by accelerating as hard as you can for half the time then decelerating just as hard for the the other half. In that case you just can't get there on time even if you don't get anywhere near the max speed.

You can't have more time than asked for, thats a given.

Eh?

Thanks, but I wrote formulae :)

decelleration

stalling.

It depends on the constraints between the acceleration and deceleration. It can be simple, difficult or haev a family of solutions.

If you are moving at the start and want to arrive at the same speed then the extension is also trivial - just replace S but S-v0*t, V by V-v0 and use the initial moving frame as your new rest frame.

mail)

Peter

You still speak about decreasing _the_ acceleration. But you have _two_ accelerations to choose from. For the second time: as stated, that optimization goal doesn't make sense. You have to be more specific in how you want to apply this single goal to two independent parameters.

In the trapezoidal case, it's actually quite simple to resolve this, since the area of the trapezoid has only one remaining parameter (after we agreed that the height must be v_max, and the baseline is given by the travel time): the length of the "roof". In particular, you can shift around the upper horizontal part arbitrarily, without changing the effective result. Keeping it centered will give lowest maximum acceleration (because if you move it away from the center, the two angles will be different, and one of them will be larger than in the symmetric case). If that violates the smaller of the two acceleration limits, pin that side of the trapezoid to the allowed angle and shift the roof accordingly.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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)

You are being a bit too strict here. :-)

The given time is a request, the distance is a must, not the other way around. But that may not have been completely clear from my question. So you can accelerate for for more than half the requested time and decelerate for more than half the requested time, thereby completing the required move in more than the requested time, using a triangular profile.

If the move can not be completed in the requested time but stil uses a triangular profile, you'll need to calculate the top of the actual triangle, not the 'preferred' one. I've made a very crude calculation topspeed = (required_time / 2) * max_accel. The result is not a triangle but a trapezoid that gets lower if you request shorter (impossible) times. I only did this to get the simulation up and running and see if the other solutions give the wanted results. (and they did). I will now punish myself for this foul and lazy hack and do it properly.

Goed, maar eigenlijk lees ik formules. ;-)

I'm not actually moving at the start, but the motor control loop gets an initial 'minimal' speed to prevent sticking. This may not be the ideal solution but this was already in the software. I am just rewriting the profile generation as the original was rather flakey and did not meet the targets even when possible. (It just calculated the required average speed and set that as max_speed. Which ofcourse always results in a move that takes longer than requested).

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

Novinson's Revolutionary Discovery:
	When comes the revolution, things will be different --
	not better, just different.

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.
To reply, remove spaces: n o lindan at ix  . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

"Stef" wrote

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. To reply, remove spaces: n o lindan at ix . netcom . com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

Thanks. It was fun to imagine.

Jon

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)

"Stef" wrote

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 group to ask.

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.
To reply, remove spaces: n o lindan at ix  . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/