keeping the distance between objects

Hello world,

Think of two linear trajectories. Hooks will be moving along those trajectories with "rope" tied between them - hook1 from traj1 with hook1 from traj2 with hook2 from traj1 with hook2 from traj2 and so forth. The two trajectories are in one plane with the center line, symmetrically at an angle around the center line and the hooks need to decelerate to 0 along the trajectory. To simplify, there'll be no queue forming at one end.

I know the timing of hooks because I know the speed of new rope coming in and the length of the rope between hooks. I have found equations for the trajectories, created 1x* matrizes for time and position according to the resolution I will be able to control the hooks at and decided the deceleration along the centerline should be linear for simplicity. What I'm now trying to do is output a lookup table of position (and speed) along either trajectory and the time for that position. As there's nothing dynamic this table will be looped through for each new hook.

I have thought of few ways to go about this, each looks equally beyond my ability right now so I'm hoping for your support.

1. Try to program "free particles" that will be bound by the boundary conditions a) the trajectory b) the distance to the one coming after. It seems to me this would incur great performance tribute.

2. Try to program a circle with the diameter of the distance between two hooks and let that decelerate linearly along the centerline. I don't know how to check the intersections with the trajectories and how to properly adapt the speed of either of the hooks along their trajectories.

3. Perhaps someone could do this with higher-than-I-could-come-up-with differential maths?

4. Perhaps I'm not seeing some easy relationship between the centerline and trajectoral deceleration that would save me all of the above work?

I do hope somebody can give me very easy to understand advice / instructions on which idea would be best and how to actually do it.

Thank you very much! Philipp

[Image Analyst]

A diagram would be helpful so we could visualize this situation.

[Philipp]

Excellent idea:

[Image Analyst]

Wow. Good thing I asked for a diagram I never would have guessed that!

Answer 1

[SK]

I assume:

1. The rope is fixed at Gx3 but free to move through all the other hooks.

2. Also you know the distance of each hook from the point A.

Since alpha and d(alpha)/dt determine the location and speed of all hooks, all you need is to compute d(alpha)/dt given vf - no?

So say (writing in "code" mode for clarity - not actually code):

dist(Gy1, A) = hy1
dist(Gy2, A) = hy2
dist(Gx2, A) = hx2
dist(Gx3, A) = hx3

The above are all known and constant.

Also say:

dist(Gy1, Gx1) = s11
dist(Gy1, Gx2) = s12
dist(Gx2, Gy2) = s22
dist(Gy2, Gx3) = s23

Then

d(s11)/dt + d(s12)/dt + d(s22)/dt + d(s23)/dt = vf     % eq (1)

but:

s11 = hy1 = constant
s23 = hx3^2 + hy2^2 - 2*hx3*hy2*cos(2*alpha) % using cosine rule
s22 = hy2^2 + hx2^2 - 2*hy2*hx2*cos(2*aplha) % using cosine rule
s12 = hx2^2 + hy1^2 - 2*hx2*hy1*cos(2*alpha) % using cosine rule

Plug these into eq (1) and perform the differentiation. You get vf in terms of alpha and d(alpha)/dt. It is a first order differential equation:

4*C*sin(2*alpha)*d(alpha)/dt = vf

where:

C = (hx3*hy2 + hy2*hx2 + hx2*hy1).

You could use an ode solver to find the solution starting from some initial alpha0 and vf0 for time {0, h, 2h, 3h, .....}. Once you get the set of alpha angles, the locations of the hooks follow.

[Edited to make corrections]

[SK]

The above approach will work for a fixed number of hooks at fixed locations, since every distance sij can be written in the form:

sij = hi^2 + hj^2 - 2*hi*hj*cos(2*alpha)

On the other hand if you are going to add hooks "on the fly" at arbitrary locations you'll have to think of some other (more computationally intensive) approach.

[Philipp]

Dear SK,

Thank you so much for your reply. I will try to understand it all now.

I'm very sorry to perhaps have mislead you; the physical process is that of folding the green foil as it comes from the right at v_F. The hooks G follow the closed loop rails to grip the foil and fold it. When they have reached the final position along l_V and have stopped, they wait to be pushed away by the next hook, release the foil they're holding and move back into queue around the looped rail. Therefore 1. is not a correct prerequisite and I'm very sorry I hadn't made this clearer.

2. is the result I would like to obtain in a manner that I input

v_F, l_F, l_V

and output

 Time | Distance from A | Speed
0.2 s | 5 mm | 20 mm/s
...
4 s | 450 mm | 5 mm/s

(these are arbitrary numbers) This will then be executed repeatedly (with a delay between new hooks that will allow l_F of foil to pass before the next hook grips) by the twincat control for the hooks.

The trouble is the angle alpha at which this is happening. The hooks have to remain fixed distance to each other (as they're not freely moving along the foil but are meant to move the foil into folds), therefore neither their velocity nor their deceleration are obvious to me. But I'm working on mere intuition, which is why I'm looking for more qualified perspectives. I will try to adapt your instructions as far as I can. Perhaps it is even a quadratic deceleration or something as simple as this but I have not idea how to arrive at that; it's again mere hopeful intuition.

EDIT: alpha will be stationary (d(alpha)/dt = 0), so will l_F (which is the the distance to be maintained between hooks) and l_V. All of them as well as v_F are parameters in order to find the lookup table. In a sense, I want the braking profile of a hook in form of a lookup table.

Thank you again for your lightning quick response, Philipp

[SK]

OK, I think I get the rough idea. But I still don't understand how the foil can fold unless the hooks bunch up near Gx3. How can the distance between Hooks remain constant. I don't have a mechanical/industrial engineering background, so some things that are obvious to you must be slipping past me. You may need to explain it as if you are describing it to a freshman student. For example what is a "twincat control".

[Philipp]

Thank you so much for all the effort you're putting in. I really do appreciate it.

The constant distance between Gx3 and Gy2 will be l_F (as will be that between Gy2 and Gx2 and Gy1 and Gx1 so forth). The distance between Gx3 and Gx2 will decrease as Gx3 will be waiting stationary at the end of l_V to be pushed away by Gx2, which will then be waiting stationary at the end of l_v to be pushed away by Gx1. As Gx2 and Gy1 approach and push Gx3 and Gy2 out of the way, Gx3 and Gy2 will release the foil and Gx2 and Gy1 will take the position that was formerly Gx3 and Gy2's. The hooks that have been pushed beyond l_V by successive hooks will follow around the looped rail to reiterate the process. Which I would think will make this easier because once I have the deceleration profile of one of the hooks (in form of a lookup table), it will be the very same for every hook, just with a time delay between hooks - no worry about bunching up or first hooks behaving differently or anything like that. Perhaps the definition of Gx1 ..2 ..3 is a bit misleading also - they're really the same speaking programmatically, think of this number as the iterator although it might have been more sensible to start with 1 and count up instead of 3 and count down, I hadn't thought of it in the schematics.

Twincat is a programming environment very much similar to matlab (it even has a matlab interface) just much more focused on programming analog and digital inputs and outputs of industrial interfaces. Many industrial devices have twincat drivers supplied in their documents. Twincat programs can very easily be embedded. Matlab seemed to be more proper for calculating this kind of thing, especially if I were to use free particle toolkits or something like that. Also, I have even less aptitude with TwinCat.

[SK]

OK, I get it now. That is just amazing. To think that machinery like that is probably used to manufacture commonplace items - we never think twice about. Anyway, I'd like to mull it over in my spare time - maybe I can come up with something in case you haven't already. Good luck with it anyway.

[Philipp]

Thanks so much!

I've attached the preparation I've already coded. Any help will be very very much appreciated.

So far I've got the hooks slow down linearly also which unfortunately doesn't keep the distance between any two of them but it get's somewhat close. I'm still looking for a solution.

Thanks again for your support!

[SK]

Hi,

OK, so let us first ensure we are on the same page here. These are my notations:

By the point A on your diagram, I mean a fixed non-moving reference point (The hook Gx1 moves but when I refer to A, I mean the fixed point which serves as a transit point for the foil). One can think of the foil as sliding over a fixed bar A.

The hooks all "Grasp" the foil, i.e: there is no sliding through hooks (as I erroneously assumed in my earlier post). This means that the distances d(x3,y2), d(y2,x2), d(x2,y1) and d(y1,x1) are all the same and are equal to I_F.

Now let the hook Gx1 start moving away from A. After some time, the distance d(x1, A) becomes equal to I_F. At this time, a new hook (call it Hyy) appears at A on the upper side and grasps the foil. The combination of the three hooks Gy1, Gx1 and Hyy then moves preserving the distances between them until the distance d(yy, A) becomes equal to I_F. Again a new hook (call it Hxx) appears at A on the lower side and grasps the foil. The combination of the four hooks then continues to move preserving distance ... and so on. Of course the number of simultaneous hooks that are moving depends on the angle alpha - If alpha is small, the number of simultaneous hooks will be more. If alpha is larger then there may only be a few simultaneously moving hooks - because old hooks will merge on the left before new hooks appear on the right.

OK so far?

So we see that there is one leading hook (just call it hook0). In theory, the leading hook can move at any speed along the conveyor. The speed of the following hook (hook1 - on the opposite side of hook0) has a relationship with the speed of hook zero that is determined by the distance constraint.

Similarly the speed of hook2 (which is on the opposite side of hook 1) has a relationship with the speed of hook1 that is determined by exactly the same kind of distance constraint.

So as you had mentioned in your first post, there is essentially one relationship to figure out - that between the speed of a hook and the speed of the hook that is following it (on the opposite side). And this relationship is given to us, surprise, surprise, by the cosine rule:

y1^2 + x1^2 - 2*x1*y1*cos(alpha) = L^2

where L is the length of I_F.

The above actually expresses the relationship between the distance of Gx1 from A (which I've denoted by x1) and the distance of Gy1 from A (which I've denoted by y1). A triangle is formed with sides x1, y1 and I_F. Use the cosine rule on this triangle to get the above relationship. Moreover any two consecutive hooks (on opposite sides) satisfy this relationship.

We can solve the equation above for x1 in terms of y1 and alpha. SO at every location of a hook, the location of the opposite following hook is known.

The speed of the leading hook can be arbitrary - unless you want to set it using some other condition on how exactly the hooks move around the conveyor.

{edited later for corrections]

[SK]

By the way, I haven't looked at your code yet, but perhaps the above would help.

As a "by the way", the diagram is somewhat misleading. I now see that the foil should be drawn like a ray of light reflecting in-between two angled mirrors. Does that place a constraint on the angle alpha??

Note also that in that in my first post there were three equations like:

s23 = hx3^2 + hy2^2 - 2*hx3*hy2*cos(2*alpha) % using cosine rule

The LHS should be squared, so these should actually be:

s23^2 = hx3^2 + hy2^2 - 2*hx3*hy2*cos(2*alpha) % using cosine rule

and things modified accordingly. But anyway it is irrelevant now as these were based on a complete misunderstanding.

[Philipp]

I didn't even think to think of that triangle! Brilliant. I had just now been looking at the vertical and horizontal distance between two hooks and how they would be changing with the time... Way more complicated and I didn't even get anywhere. Thank you for your detailed and very easy to follow comments.

Do you think you could comment on my approach from here;

I take the linear deceleration of the first hook and generate a lookup table of time vs x0.

I then loop through the cosine rule for those x0 to generate a lookup table time vs y0.

Do you think I will need to use the cosine rule on the y0 table to find the x1 table or shouldn't it be the same as the y0 just triggered appropriately later? I'm getting a knot in my head trying to figure out whether over iterations the decelartion profile would change, thus, whether the linear deceleration profile of the first hook doesn't have an obfuscating side effect. What do you think would be the best arbitrary deceleration profile for the first hook? I really only have the constraint that it needs to have decelerated to 0 after l_V. You said in your comment that any two following hooks would satisfy the formula which I agree with yet it's not clear to me if they would follow the exact same profile as the second hook or would somehow need to slow down earlier than the second one.. I'm hoping I'm making myself clear here.

Thank you for your feedback on the figure above. I'm afraid I don't understand how a ray of light would look and what constraint you mean? Alpha is defined by l_V and l_F so I'm not sure I'm following your train of thought.

EDIT: I've got another idea: How about I take a linearly decelerating point on the centerline say w_-1 from which to find the deceleration profile of x0 using cosine rule. Would that even make any difference to whether profiles for hooks of (i>0) differ from that of x0?

Many many thanks again.

[SK]

take the linear deceleration of the first hook and generate a lookup table of time vs x0. I then loop through the cosine rule for those x0 to generate a lookup table time vs y0.

Right.

Do you think I will need to use the cosine rule on the y0 table to find the x1 table or shouldn't it be the same as the y0 just triggered appropriately later?

You need to use the cosine rule iteratively / recursively until the (smaller) solution becomes less than L. For example, given the alpha of round 17 degrees that you have, it may be only around four or five iterations /recursions max.

You said in your comment that any two following hooks would satisfy the formula which I agree with yet it's not clear to me if they would follow the exact same profile as the second hook or would somehow need to slow down earlier than the second one.

If you solve for x1 in terms of y1 (or vice versa) you will see that x1 and y1 are in a constant ratio (R say) that depends only on alpha and L. So in fact the acceleration profiles will also be related to each other by the same ratio. So whatever profile you have for the leading hook gets multiplied by R, R^2, R^3, ... etc for successive hooks.

So in fact, we realize now that it is actually much simpler than we originally thought (I'm not feeling bad about that and I recommend that you don't either :-) ). In fact you probably do not even need to write a single loop (get familiar with using the .* and ./ operators and vector operations in general in Matlab).

As to what profile to use for the first hook, why not just take constant deceleration. The distance profile (x0) would then be:

x0 = u*t - 0.5*a*t^2

where a is the constant deceleration and u is the initial speed with:

t = [0, 0.001, 0.002, ...]

You will have to choose the constants u and a so that x0 becomes equal to I_V at some time (T say) of your choice and the speed u - a*t becomes 0 at that t = T. The distance profiles of successive hooks are then related by the the constant multiplier R.

More generally you could write a function that takes an arbitrary distance profile for the leading hook, and returns the distance profiles of all the successive hooks. Note that, in general each successive hook will have a shorter distance profile than the previous one due to the cutoff condition, so the function is not entirely trivial.

The speed and acceleration profiles can then be found (approximately) by taking first and second differences, respectively, of the distance profiles.

How about I take a linearly decelerating point on the center-line say w_-1 ...

Do you mean to take the projection of the point onto the conveyor. In that case, a linearly decelerating point on the centre-line would translate into a linearly decelerating point on the conveyor, wouldn't it?

You could also start with acceleration profiles or speed profiles (instead of distance profiles). They also are related by the same ratio R. It would probably be a good Matlab exercise to write a general function that takes either a distance profile or speed profile or acceleration profile, along with some initial conditions and produces all the remaining profiles correctly with correct cutoff lengths.

Forget the remark about light rays :-P. The thing to note is that the shape of the foil forms a set isosceles triangles on the conveyor.

[Philipp]

Thank you very much for your truly great support.

I feel I'm so close to understanding what you explain.

Right now I've got my constant deceleration (velocity of a hook vs time) in the form of

v_h_t = -v_0/(cosd(angle)*(t_max+trigger_time/2-pre_t))*(t_h-pre_t)+v_0/cosd(angle);

where v_0 is the foils speed, angle is alpha, t_max is what you call T, trigger_time is the time needed for l_F to pass by point A, pre_t is the time required for foil to reach point A if it's not at the beginning of l_V and t_h is what you call t.

EDIT: I realize there's something needing more explanation. t_max=cosd(angle)*l_V/v_0, therefore the time, a point along the centerline would require. If I imagine a circle or radius l_F/2 around this decelerating point on the centerline, its intersections with the hook trajectories should be the hook positions. At A, the front hook needs to be at alpha from the centerline on the circle. At cosd(angle)*l_V, the hook needs to be perpendicularly above the center of the circle. At the time, I figured I could achieve this by just giving the hook half the trigger time more time for l_V than the point on the centerline has for cosd(angle)*l_V. As I'm writing this down for you I feel I have found a substantial mistake in my train of thought. I will try to figure out how to do it correctly and edit this comment further.

EDIT2:t_max=2*cosd(angle)*l_V/v_0 made much more sense and I think trigger_time/2 doesn't make any sense to be in the formula. Leaving it out doesn't solve any one of my problems still, it rather somehow makes the distances for h2+ complex. I think I'd better go to sleep. I'm very much looking forward to your comment!

So a linear profile accounting for point A (the intersection of hook trajectories) being offset from the beginning of l_V depending on hook length and distance of the rails from one another. The hooks will have the projection onto their trajectory of the foil speed at point A and stand still at the end of l_V. This I integrate from 0 to t_h and get

d_h_t = v_0/(cosd(angle)*(t_max+trigger_time/2-pre_t))*t_h.*(t_max+trigger_time/2-t_h/2); (+u*t_h)

which I feel should somehow be your

x0 = u*t - 0.5*a*t^2

This is where I run into my first problem: x0 or d_h_t as I called it obfuscatingly ends at 388 instead of 500. This is where what you call u comes in. I have thought it might be

(t_h-pre_t)*v_h_t(1,1)/(t_max+trigger_time/2-pre_t)
or L_V/t_max*t_h

which unfortunately doesn't quite get me there. I must be doing something very obvious wrong, perhaps you can see it?

Without any u, I went on to implement the cosine rule;

d_h2_t = d_h_t*cosd(2*angle)+sqrt(L_F^2 + (d_h_t*cosd(2*angle)).^2 - d_h_t.^2);

I don't see a constant factor but perhaps you do?

This produces distance values from 304_t=0 to 520_T.
The recursions for h3 from 495 to 461,
for h4 from 504 to 520,
for h5 from 495 to 461,
for h6 from 504 to 520,
and h7 from 495 to 461.

I see that indeed as you said the result stabilizes after so many recursions but I don't know what to make of the values. Ideally they should all be the same not alternatingly equal? And perhaps after figuring out what went wrong with my initial, linear x-range, (what u should be) they should all be from 0 to l_V? Using the other solution for d_h2_t to the cosine rule (with a negative square root) yielded

h2 from -304_t=0 to 111_T.
h3 from -495 to -206,
h4 from -504 to -447,
h5 from -495 to -523,
h6 from -504 to -447,
h7 from -495 to -523.

and using the solution d_h2_t but subtracting L_F from every result lead to

h2 from 0 to 216,
h3 from 0 to 149,
h4 from 0 to 109,
h5 from 0 to 82,
h6 from 0 to 63,
h7 from 0 to 49

Which at least has one correct boundary to the distance interval but doesn't seem to stabilize and I wouldn't have any idea why l_F should have to be subtracted, this was a mere shot into the blue.

When these two problems are solved (1. the wrong linear distance range, 2. the unclear distance range after a safe number of cosine rule iterations), if I understand you correctly, I would be able to use my final distance profile for all hooks (including the first) with just the proper delay (trigger_time) between hooks? Would I have to map the final but shorter distance profile onto l_V, or would that be unnecessary given all steps before that are correct? Perhaps this is exactly what you were referring to when you said it won't be entirely trivial?

You're right, a linearly decelerating point on the centerline would translate into a linearly decelerating point on the conveyor belt - my thought was to use this point on the centerline to derive any hook on either rail instead of using one hook on one rail to derive the next one on the next but I haven't pursued that at all.

I agree, it's a wonderfully intricate exercise with many dead ends forking off and I'm very thankful for all the help you're giving me.

[SK]

OK, I had a quick read through your post. I'll read it in more detail later. But a couple of points:

1. You are right about there being no constant factor. That was a mistake on my part. We have

y1^2 + x1^2 - 2*x1*y1*cos(2*angle) = L_F^2

I divided throughout by y1^2 and forgot to divide the RHS - which is how I obtained a constant ratio between x1 and y1. So you are right, it should be:

x1 = y1*cos(2*angle) - sqrt(L_F - y1^2sin^2(2*angle))

( using 1 - cos^2(2*angle) = sin^2(2*angle) )

2. You are eventually looking for a numerical set of profiles - right? So suppose that you are given an arbitrary initial profile (say distance profile - although it could be a velocity or acceleration profile also with initial conditions). Then:

a) Find the profile for the next hook. You have already figured that out in (1) above.

b) In the profile found in (a), remove all the distances that are less than L_F. (That is a single line in Matlab)

c) Go back to step (a).

My point is that if you try to start with a profile given by a complicated expression, integrate it mathematically, find the succeeding profiles, all in one step, the likelihood of error is high. So first get (a), (b) and (c) coded. Then you can worry about what exact initial profile you want. So basically you will have a convenient function:

function following = get_hook_profiles(leading, type)

The 'type" argument will be a one of the strings: 'dist', 'vel' or 'acc'. The 'leading' argument is the profile of the leading hook. The return result 'following' can perhaps be a cell-array of vector profiles, with following{i} being the profile for the i-th hook.

Also, before I read your post in detail, am I to infer from your post that the distance/velocity/acceleration profiles of all the hooks (including the leading one) is determined (constrained) by a few scalar parameters. I had thought that, since the hooks were free to move along the conveyor, that the speed of the leading hook could be more or less arbitrary. But of course, in any given span of time, the number of hooks leaving on the left side must equal the number of hooks coming in on the right - so is that the condition that constrains the speed of the leading hook? In other words - why should the profile of the leading hook matter at all? Whatever its speed, the overall job of folding the foil still gets accomplished right?

[Philipp]

Thanks for your quick reply. I really hope I'm not annoying you with my thickness. Don't worry so much about my previous comment, I've gotten to a different stage with your help already.

Thanks for the suggestion of the general and truly convenient function. It sounds marvelous but I'm so far into this particular case now and I feel this function would cost me as many hours as this particular case has cost me already...

I'm not sure I understand your inference, sorry. I have a few scalar parameters such as l_V, l_F, v_0, hook_length, minimal distance between rails. Ideally, I output one lookup table which all hooks can follow regardless of being a first one. As far as I understand, this lookup table could be the profile of say y3, found using a virtual, linearly decelerating x0 and virtual decendants down to y3 which I will then call my final output. Hence, the initial profile for x0 does not matter at all.

Following your advice I removed all complications due to A being offset to an intersection point of the two hook trajectories. Perhaps I will worry about that later. I now get a nice distance y0 vs time profile for the first, linearly decelerating hook. I've attached a plot.

When I solve for x1, I get

x1 = y0*cosd(2*angle) +/- sqrt(L_F^2 - y0^2sind^2(2*angle))

of which the solution with the positive root gives me profiles x1 vs t such as the attached ones named "squared ...". As you can see, all values from the second hook onward are above L_F as is. I can't make much sense of what I see. Can you?

If I use your solution with L_F instead of L_F^2, I get something much better looking, named "unsquared..." among the attached files. I understand neither why the square would go away nor what this little inconsistency until 0.2s might be. The fifth, seventh, ninth profile looks like the third, all even numbered ones look like the second. Should I really remove all distances less than L_F from these?

[Philipp]

PS: I did the same thing using the solution to x1 with subtraction of the root. I attached only the ones with L_F^2. The ones with unsquared L_F make much less sense still. Noteworthy that these solutions don't seem to stabilize.

PPS: I can't attach any more files today but I think you understand what I mean.

[SK]

I really hope I'm not annoying you with my thickness.

Not at all. It is good to see someone who follows through with his own ideas rather than blindly accepting somebody else's suggestion.

[SK]

You probably just made a mistake in the computation. Try this. I get the leading hook and 2 following hooks for your distance profile. All the code below can be executed (in order) in Matlab.

angle = 17.698*pi/180;
L_F = 2*500*sin(angle);

From you graph, I see that the deceleration a is:

a = 500/40.5;

Initial speed is:

u = 9*a;

Take vector of times:

t = 0 : 0.01 : 9;

leading distance profile (hook 0):

y0 = u*t - 0.5*a*t.^2;
plot(t', y0);

Next hook (hook 1):

x0 = y0*cos(2*angle) - sqrt(L_F^2 - (y0.^2)*sin(2*angle)^2);

Remove distances that are less than LF (don't forget to modify the time vector):

t1 = t(x0 >= L_F);
x0 = x0(x0 >= L_F);
figure;
plot(t1', x0);

Next hook (hook 2)

y1 = x0*cos(2*angle) - sqrt(L_F^2 - (x0.^2)*sin(2*angle)^2);
figure;
plot(t1', y1);

Cant go any further, since all elements in y1 are less than L_F. SO there is a leading hook and two following hooks for this particular angle (17.698 degrees)

[SK]

Now of course when y0 reaches its endpoint, x0 becomes the leading hook and its distance profile has to be extended upto the endpoint. Presumably you would give it the same distance profile that you gave y0, and then compute the following two hooks. The process goes on.

The only thing is that both x0 and y1 come to a stop when y0 reaches the endpoint (look at the graphs) so you have to "restart" x0. So when you look at the profiles over the full time, they are going to be jerky - although they still accomplish the job of folding the foil. If you feel this is ugly, you need to choose the initial profile in such a way that the transition from the constrained (ie: following) profile to the leading profile is smooth. You get what I mean? You would probably have to choose an initial profile whose speed is non-zero right up to the endpoint (ie: it just stops suddenly at the endpoint)

To do these computations in a loop, you'll have to decide on how you are going to store each profile and also make few other programming decisions.

Anyway, you have really worked hard over this, so I don't want to burden you with any further advice. :-)

[Philipp]

Thank you. You are awesome. I will follow this as closely as possible as soon as I can. Until then I have again so many thoughts...

with this cutoff function you wrote, am I not retaining something like

5 s 304 mm
5.01 s 305 mm
etc.

when I really want the whole remainder x0>=L_F shifted to begin at the origin?

Now that I would be getting a single profile (I suppose without having tried it that x0 and y1 are the same) that can be repeated by all hooks, could I not let my seeding y0 continue beyond L_V so as to avoid having to restart x0? Ie let x0 linearly decelerate till it gets to 800, reiterate cosine rule a couple of times and be left with say y3 which goes to 500 and use this for everything? I have a feeling I'm wrong because y3 to x3 following the same profile y3 won't keep the distance correctly, it needs to be the cosine decendant.

You have also alerted me to a problem I hadn't even seen;

When whichever leading hook reaches L_V, the following hook cannot continue and keep the distance at the same time. And this is not just because the translation of the first one has stopped but because a following hook would need to follow a circular arc of radius L_F around the now fixed hook while it is constrained by the linear trajectory. Following this linear bit of 184 in length (graphically found for these parameters, I'll look into the programmatical realization) will slacken the foil as d(x_i,y_i) must become less than L_F. This is the sketch: https://sketch.io/render/sketch545291d8d19f9.png

From an engineering perspective this can be turned into a feature, the slack aids another grapple that picks up the folded foil from the fixed hooks. From the profile calculation perspective this means I have to complicate it in either of these ways:

1. split the profile in two; the first part will be cosine rule deceleration until about 184 away from the end and about 10% of v_0, the second part will be linear deceleration from 10% of v_0 to 0. This would avoid the restarting dilemma or rather shift the restarting point into the interval of the profile that's actually linear so it's easy to continue from there.

2. continueing the seeding linear profile beyond L_V so that I avoid running into this breakdown of the constraint d(x_i,y_i)=L_F and after so many iterations, I am left with one beautiful profile of length L_V. Instead of using its earlier-stopping decendant for the following hook, I use the same one which will really just be a bit faster than the decendant profile towards the end. This will more gradually increase a tiny bit of slack instead of having that slack "all at once" near the end. I have a feeling having the slack "all at once" near the end would be better, but this will be easier to build..

I'm hoping I'll end up with the one-profile-fits-all-hooks lookup table. Two alternating but stable profiles would be close enough to this goal. Having an upper profile and a lower one so to speak.

Anyway, I'll be back when I'm further.

Thank you again for all your help.

Answer 2

[SK]

with this cutoff function you wrote, am I not retaining something like

5 s 304 mm
5.01 s 305 mm
etc.

when I really want the whole remainder x0>=L_F shifted to begin at the origin?

It depends on how you want to represent the final data. I think you need to think about this carefully, ie:

What does the final data representation look like?

But before considering this question, there is another issue:

The problem of choosing the leading profile is under-determined. We would probably want to use some sort of continuity / periodicity condition to choose the leading profile. Ideally we want periodicity - after all it is a machine that repeats things over and over.

could I not let my seeding y0 continue beyond L_V so as to avoid having to restart x0?

Yes you could and you would get correct results - in the sense that the job will still get done. But you would have to keep on "seeding" y0 arbitrarily to keep going. Since this is after all a machine, we expect some sort of periodicity and you won't get that by arbitrarily seeding y0.

Now that I would be getting a single profile (I suppose without having tried it that x0 and y1 are the same) that can be repeated by all hooks, ...

This is the key. In a sense we want all the profiles to merge smoothly into one another. Moreover the profile of one hook should look the same as the profile of any other hook - only shifted in time. So that should give us a condition to fix the leading profile shape, ie we want:

x(t+tau) = x(t)*cos(2*angle) + sqrt(L_F^2 - (x(t).^2)*sin(2*angle)^2) -- (1)

which can alternately be written in its original form (before we solved for the root):

x(t+tau)^2 + x(t)^2 - 2*x(t)*x(t+tau)*cos(2*angle) = L_F^2  ----- (1a)

What is the time tau? It is the time for which:

x(tau) = L_F    -----  (2)

because that's when the next hook comes online (after the leading hook has moved L_F from the zero position). Note that we don't know this time yet because we don't yet know the profile. We have to simultaneously solve for both the time tau and the profile x(t) from the two equations (1) and (2) above.

How does one solve this? I'm not sure - I've never really come across a "delay" equation like the above, but it certainly looks like it should be solvable. Note that simple ansatz's like polynomials in t wont work since you will get more equations than unknowns. For example - 2nd degree polynomial (constant acceleration) would be of the form x(t) = at + bt^2. There is no constant term since x(0) = 0 (equivalent to x(tau) = L_F) . If we plug this in to eq (1a), we get 5 equations in three unknowns (a, b and tau).

Thus we need a more sophisticated ansatz, or we need to solve (1) numerically.

Can you think of an ansatz? How about x(t) = A(1 - e^(-bt)). What if we plug this into (1a) and try to equate coefficients (we will have e^(2bt) terms, e^(bt) terms and constant terms (so three equations) and three unknowns A, b and tau. Could you try it?

[edited for corrections]

Answer 3

[SK]

I don't think the problem has an answer.

There is one very obvious fact that has been embarrassingly missed. It is not possible to keep all the foil lengths constant simultaneously. At the very least the length of the foil from Gy2 to Gx3 has to change. So somehow the problem statement has to be modified.

Where do you get this problem from?

[Philipp]

Perhaps we can get close to an answer though?

If we find the y2 profile seeded from the more complicated profile you suggested (I'm working on this), using tau=trigger_time=L_F/v_0 and run this repeatedly up to the point 184 mm from the end of L_V (for here we'll need the arc I sketched in a previous comment) and linear deceleration from there, don't you think we'll have very little slack and quite a bit more on the last 184 mm but generally get the thing done? If I then find the slack vs time curve, I can adjust springs in the hooks to compensate for this. I feel we're closer than ever to a closest solution.

To answer your question: I've taken a course on technology management. The people who gave it are engineers. I was to do a homework assignment on say change management. When they heard I had worked with matlab before, they felt they should put me to better use than to writing this essay and I felt this would be more valuable to me also. They have a master's student whose thesis is the realization of the folding apparatus. The rails are done, the hooks are being finalized. Finding the deceleration profile was one of his todos which they outsourced for me to work on as the homework assignment.

[Philipp]

If you have the time, could you explain to me how you arrived at the conclusion that y2 to x3 cannot be kept?

[SK]

I'll get back to you with a drawing. It really is quite easy to see if you draw a bunch of isosceles triangles starting from the stopping point Gx3.

However, I think we should probably continue this via private e-mail, as this thread may have outlasted its welcome on this site. We are taking up MathWorks bandwidth on a problem not directly related to the Matlab product. I wonder if you can see my e-mail address. If you do, send me an identifying e-mail. Let me know.

Regards.