Sketcher: Ellipse support

[ulrich1a]

We are missing here (do I miss something?):
1. Perpendicular to ellipse constraint (I know there is an equation some 20 posts ago, I still have to take a look to...)
2. Circle tangent to ellipse (without point tricks, I still have to take a look to DevJohans code with the nice figure)
3. Ellipse tangent to ellipse

Yes guys, we can, we are doing it

Regarding this constraints have a look here: viewtopic.php?f=10&t=7520&start=220#p63707

Ulrich

[DevJohan]

DevJohan. I have quite a lot of problems to follow this (matlab?, octave?) code.
1. I do not know what the variables are intended for p,q,...
2. I do not know what is exactly the aim of the code. Is this additional code that has to be executed once a quartic equation is obtained? How do I apply your code to, for example, DeepSOICs equation proposal?

Would you please explain to me? Thanks!!!

I have been busy these last few days and I can't find which DeepSOICs equation proposal you are referring to

To answer your questions,
1) p and q are just calculations that are part of the general solution (p and q are used in R1 and R2).
2) This is just to get the solutions for angle of closest point on ellipse for every point in the plane, color coded. If you could point me to the equations DeepSOIC proposed, I could have a go at trying to apply a similar approach to them.

To illustrate why I think we need to keep track of which point on the ellipse we are using in a tangent constraint: http://youtu.be/uwnlla6Hbu4

[abdullah]

I have been busy these last few days and I can't find which DeepSOICs equation proposal you are referring to ...

If you could point me to the equations DeepSOIC proposed, I could have a go at trying to apply a similar approach to them.

It is the tangent constraint that we are currently using.

Sage worksheet:

Ellipse_Tangent_DeepSOIC_squared_ModifUlrichDeepSOICparams.zip

(3.57 KiB) Downloaded 62 times

You can load this file in you computer if you have sage, or in http://www.sagenb.org (upload option)

It is an error function that looks like this:
DM = (F1_m-F2)*(F1_m-F2) - (2*a)^2

where F1_m is the mirror of the focus F1 with respect to the tangent line

With the current solver parameters, it looks like this:

ellipse33.png (22.15 KiB) Viewed 2036 times

To illustrate why I think we need to keep track of which point on the ellipse we are using in a tangent constraint: http://youtu.be/uwnlla6Hbu4

You made your point. I have just tried it with the current development branch:
sketcher_ellipse_general_alignment_to_internal_geometry_contraint

It jumps considerably less than in your video, due to the change in parameters used in the model (phi angle is no longer a parameter to the solver, but center point, positive focus point and minor radius). Nevertheless, it is by far the one showing the worst behaviour while moving the line, specially if you leave the 5 degrees of freedom of the ellipse unconstrained. But even if you would constrain some of them, well, the line does not line to be near the extremes of the major and minor axes.

I must add that I have a problem knowing exactly what is "acceptable behaviour" here. I explain myself, I usually have very little requirements to interactive moving and solving. I am happy if I can constrain my sketch without having to drag, so I am happy if it converges when setting datum values. I can understand though that for a CAD user this relaxed requirements are unacceptable, as he might be used to drag it to visualize options during design (I guess, I do not know, I am not a real CAD user). In general, tangent constraint for ellipse, as it is now in the aforementioned branch might not be acceptable for a real CAD user. I would like to have the input of CAD users on this. Of course, I do agree that if it can be improved (and it can certainly be improved), we should try...

[abdullah]

Here is an approach for those constraints:

1. Perpendicular to ellipse constraint:
a) A point on the ellipse is needed: Pelli

Sorry for replying to this so late (to the original post).

Here I think I understand that a physical point is needed in the sketch. In principle this is an approach I would be willing to avoid unless no other option presents ourselves. If I got it wrong, and you just mean: "let's define a point in the plane that is on the ellipse", the "problem" is that you have to solve for a point (decide on the point), probably, maybe in a similar way that I was doing it by using N-R within the error and gradient calculations. This problem arises because the point is not existing in the solver (is not a solver element)...

In other words, if I calculate that, I will get three error functions, yes, but they will have one parameter, Pelli, that can not be modified by the solver... May be I am getting everything wrong. The perpendicular constraint should remove 1 DoF and be based on the parameters available to the solver, center of ellipse, positive focus of the ellipse, minor radius and the two points of the line. Any other parameter shall be solved for (numerically, by substitution, ...) in the loop. Numerical usually has the problems with partials, substitution generates higher order polynomials, but maybe DevJohan can help there in selecting the right root...

I am sorry if I am not understanding it properly...

[abdullah]

Quick note: Ellipse tangency is sometimes a pain the back, we might have to review it...

[ulrich1a]

In other words, if I calculate that, I will get three error functions, yes, but they will have one parameter, Pelli, that can not be modified by the solver...

The point Pelli just stands for the coordinates, where the circle and the ellipse do touch, in case of the circle-ellipse-tangent-constraint. There is no need to create this point in real in the sketch. These coordinates are just needed for an easier expression of the error-functions.
In practice a first guess is needed for these coordinates. The first guess may be calculated at the first definition of the constraint by the user.
In one aspect you are right. The solver must track this coordinates, in order for fast solving later changes of the equation system. So a new class of solver-element is be needed: internal not shown solver points. It has the advantage, that already existing constraints can be reused for another constraint.
If this is not acceptable, the error equations with the error set to zero have to be solved symbolically, in order to eleminate the coordinates of Pelli out of the three equations. I did not try that. It could be a challenge.

Ulrich

[ulrich1a]

Here is a simulation sketch for the circle-ellipse-tangent-constraint. It is based on the master branch of FreeCAD. The ellipse is defined by the two foci and the major radius a. It allows movement of the circle in small steps. Moving fast over the major axis gives problems.
What is important: The tangent constraint should no freeze the sketch, in order to test for missing constraints. Smooth movement over large ranges may not necessary.

Ulrich

[abdullah]

First:
I have merged the test branch above into:

sketcher_ellipse_master

You can use either of them (they are exactly the same at this moment).

I have reworked a little DeepSOIC tangent equation, meaning basically simplifying and adopting back the linear form (as opposed to squared). This gives me overall better convergency and the Jacobian matrix welcomes the change. This is here:

https://github.com/abdullahtahiriyo/Fre ... master.git
* [new branch] sketcher_ellipse_tangentconvergenceimprovement

If you can test, you might want to compare the behaviour of the tangent constraint of the two branches. Just let me know your impressions... if you see something not working please post the sketch file.

So a new class of solver-element is be needed: internal not shown solver points. It has the advantage, that already existing constraints can be reused for another constraint.

That would be a challenge But I also see that invisible parameters for the solver might slow down convergence when big changes to the sketch are made (dragging). Also there is no means to convey a value "at the definition of the constraint by the user" to the constraint, other than the datum value. This might imply tons of modifications... I might rather accept the intermediate point approach then...

If this is not acceptable, the error equations with the error set to zero have to be solved symbolically

Last time I tried this approach, I got very very very long partials (I refrain from writting again which size of code ). But maybe now that I am starting to know a little bit better sage I can manage to simplify them...

What is important: The tangent constraint should no freeze the sketch, in order to test for missing constraints. Smooth movement over large ranges may not necessary.

Thanks for this definition. Then the new implementation of tangent might comply with it (I did little testing)...

Here is a simulation sketch for the circle-ellipse-tangent-constraint

Your simulations get more interesting by the hour...

ellipse34.png (50.32 KiB) Viewed 2014 times

Ain't no challenge big enough,
Ain't no simulation tricky enough...

[abdullah]

BTW:
I forgot to add the sage sheets of the InternalAlignment constraints:

download_worksheets(1).zip

(26.53 KiB) Downloaded 43 times

[abdullah]

Ok, looking at the improvements of the reworked tangent, I have made similar changes in the PoE constraint. I think it works much better. It is here:

https://github.com/abdullahtahiriyo/Fre ... master.git
* [new branch] sketcher_ellipse_PoE_convergenceimprovements

This branch does NOT have the improvements of the tangent.

I would like to have your input on this improved versions versus the ones in ellipse_master branch.

Next consequence of testing is merging the best convergence functions into ellipse_master. Give me your feedback!!