keeping the distance between objects

14 ビュー (過去 30 日間)
Philipp 2014 年 10 月 22 日
編集済み: SK 2014 年 11 月 2 日
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
  3 件のコメント
Image Analyst
Image Analyst 2014 年 10 月 23 日
Wow. Good thing I asked for a diagram I never would have guessed that!



SK 2014 年 10 月 23 日
編集済み: SK 2014 年 10 月 23 日
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
d(s11)/dt + d(s12)/dt + d(s22)/dt + d(s23)/dt = vf % eq (1)
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
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]
  18 件のコメント
Philipp 2014 年 10 月 30 日
編集済み: Philipp 2014 年 10 月 30 日
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
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:
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.


その他の回答 (2 件)

SK 2014 年 10 月 31 日
編集済み: SK 2014 年 10 月 31 日
with this cutoff function you wrote, am I not retaining something like
5 s 304 mm
5.01 s 305 mm
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]

SK 2014 年 10 月 31 日
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?
  3 件のコメント
SK 2014 年 11 月 2 日
編集済み: SK 2014 年 11 月 2 日
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.



Find more on Vehicle Scenarios in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by