FreeGCS 3D constraints

[ickby]

Hello,

as preparation for the upcoming assembly module I started to write 3D-constraints under logari's advise for his solver. I'm far from finished, but i thougth I share what I've already done to get some feedback (So this mostly concearns logari, i think). These are the constraints working rigth now:

P2PDistance_3D, //point-point distance (works as point-on-point with distance 0)
P2LDistance_3D, //point-line distance (works as point-on-line with distance 0)
P2PLDistance_3D, //point-plane distance (works as point-on-plane with distance 0)
LParallel_3D, //lines-parallel
PLParallel_3D, //planes-parallel
LPerpendicular_3D, //lines-perpendicular

I've attached an archive with a test suit. It's a cmake project creating an executable which reads an xml-file describing the problem to solve (thanks logari for this) and writes a octave-file to show the results (directly executable by octave). Execute like this: solver in.gcs out.m. Examples are included.

Most stuff is in 3DConstraint.h and *.cpp, here is what i changed in the basic solver files:
Geo.h : added 3D points, lines and planes
Constraint.h: added the new constraint types in the type-enum
gcs.cpp: copy the new constraints in the constructor.

Now here are some questions which raised while coding:

1. I don't fully crasp what the scale and maxStep functions in constraints suppose to do. It would be nice to get some theoretical background on this, as from code alone i dont get a full understanding. Seems everything works without implementing them, but i belive I could get prettyer results by using these two.

2. 3D stuff is best done with vectors, so i written my own little vector extension. This was stupid as eigen provides everything I needed (and of course way better), just discoverd that too late. I suppose sticking with eigen is the way to go?

3. Is describing planes with 3 points a good way to go? I think a normal vector and reference point would be nicer, but no idea how to integrate this into the solver.

4. How does the P2PAngle constraint in works in 2D? I've no idea what this one is about, so there is no way for me to extend it in 3D.

I'm off traveling again the next week, so no work will be done on this for a few days. I'm still very excited on the progress I've made and love to hear some of your ideas.

Greetings,
Stefan

[logari81]

Hi Ickby, nice to see that you are doing progress with this. I haven't tried your code yet but I can try to give some answers to your questions.

1. I don't fully crasp what the scale and maxStep functions in constraints suppose to do. It would be nice to get some theoretical background on this, as from code alone i dont get a full understanding. Seems everything works without implementing them, but i belive I could get prettyer results by using these two.

- scale is not used at the moment it may be necessary in order to add some weighting to the constraints of a system.
- maxStep is a very useful trick for increasing the robustness of the solver. For example constraints that include angles will not permit large steps in the solution, because it is known before hand that for angles greater than e.g. 20° the linearization of the geometric problem is not very accurate anymore. Another case where maxStep is used is for point to line distance so that the point will not jump to the opposite side of the line.

2. 3D stuff is best done with vectors, so i written my own little vector extension. This was stupid as eigen provides everything I needed (and of course way better), just discoverd that too late. I suppose sticking with eigen is the way to go?

yes, Eigen is a very well tested and widely used library and has good support for small dimension vectors.

3. Is describing planes with 3 points a good way to go? I think a normal vector and reference point would be nicer, but no idea how to integrate this into the solver.

here we'd need some advice from the core FreeCAD developers, so that the solver will be as close to the currently available FreeCAD conventions as possible. Are you aware of the placement property and the plane primitive that are available in FreeCAD?

4. How does the P2PAngle constraint in works in 2D? I've no idea what this one is about, so there is no way for me to extend it in 3D.

Maybe we don't need angle constraints for the assembly. Let's hear others opinions.

I will try your code and I will also try to set up a test case that we can use as a reference for the development of the assembly module. We should keep in mind that the result of the solution should return the placement property of all objects involved.

[ickby]

Hello logari,

thanks for answering my questions.

Are you aware of the placement property and the plane primitive that are available in FreeCAD?

I'm aware of these, but to be honest, I've given the integration in the freecad context not too much thougth rigth now. My priority was to get back into the math again and see what I can do. I agree that the placement property is the variable that should be used, but the issue of translating solver-results to placement propertys is still to solve (I have some rough ideas).

I will also try to set up a test case

That would be awsome. But take your time, I'm away for 10 days. When I'm back I clean up the code I've written and try to dig into the freecad integration, so a testcase would be realy helpful!

Thanks,
Stefan

[jriegel]

For me the interface to the solver is very simple. It is always a frame (placement) with position (x,y,z) and rotation (A,B,C).

Each object in the assembly has a frame for its position. Each referenced geometry has a frame too. A e.g. face means the x,y plane of the frame
and a axis is the z-axis of the frame. So for example the error function for a axis constraint is to minimize the angle between the z-axis vectors...

The result is a new set of placement frames (X,Y,Z,A,B,C) for the objects... But as logri said already, I think we have to treat the angle parameters (A,B,C)
somewhat weaker in the solver. also we have to think about some temporary constraints to force a natural behavior, like the screw moves to the car not the car to the
screw. that means considering mass...

As I said, after the 0.12 release I will set up a framework in FreeCAD for the assembly solver which allows the embedding of an solver. the interface will
be the placements and the constraints between them...

[logari81]

@Stefan
I have taken a look at your work and your changes seem to be according to the logic of the 2D solver. For the assembly module we need however to support the coordinate frames mentioned by jriegel.

E.g. an xml input could look like:

Code: Select all

<GCS_3D>
  <frames_3D>
    <frame_3D id="1" x="0.0" y="0.0" z="10.0" A="1.57" B="0." C="0."></frame_3D>
    <frame_3D id="2" x="0.0" y="0.0" z="10.0" A="0." B="3.14" C="0."></frame_3D>
  </frames_3D>
  <points_3D>
    <point_3D id="1" frame="1" x="1.0" y="1.0" z="1.0"></point_3D>
    <point_3D id="2" frame="1" x="5.0" y="2.0" z="3.0"></point_3D>
    <point_3D id="3" frame="2" x="1.0" y="1.0" z="1.0"></point_3D>
    <point_3D id="4" frame="2" x="5.0" y="2.0" z="3.0"></point_3D>
  </points_3D>
  <lines_3D>
    <line_3D id="1" frame="1" point1="1" point2="2"></line_3D>
    <line_3D id="2" frame="2" point1="3" point2="4"></line_3D>
  </lines_3D>
  <constraints>
    <constraint id="1" kind="P2PDistance_3D" point1="1" point2="2" distance="4."></constraint>
    <constraint id="2" kind="P2PDistance_3D" point1="3" point2="4" distance="5."></constraint>
    <constraint id="3" kind="Perpendicular_3D" line1="1" line2="2"></constraint>
  </constraints>
</GCS>

In contrast to the Sketcher, for the assembly module, the x,y,z parameters in the "points_3D" section will be known beforehand. The system unknowns for the assembly module will be the x,y,z,A,B,C variables in the "frames_3D" section. Could you experiment a bit with this idea?

[ickby]

Hello,

thanks for the input, I played around with your ideas and got some promising results. Using reference frames workes fine, however, i don't think solving for the roll-pitch-yaw angles is a good idea as this will be numerical unstable. In my opinion it's better to use the quaternions, and my test implementation showed that this works fine (still lot's of testing to do). Any objections on that?

If I understand you corecct, a typical constraint would, for example, look something like this:

Code: Select all

add_constraint_parallel_face(Placement object1, Placement face1, Placement object2, Placement face2)

Of cource the face placements would not be changed by the solver. They are just needed to calculate the reference geometrys position in the object frame (as Placements do always reference the global coordinate system, rigth?)

Implementing a fixed constraint is simple. Applying however is something the solver can not take care of. I think the simplest thing is to calculate the volume of all objects (opencascade offers this functionality) and compare before solving: the biggest object with constraints get fixed. However, this wont work with already assembled parts, as there is no way to check if subgroups are fully defined assemblys and if adding volumes makes sense. (I't can happen that 3 small parts together are bigger then the big one, but there is no way to tell what counts for what) But to implement stronger analysing capabilitys we have to go for graph approach, and thats something for later if needed.

So are my thougths correct? I'd like to hear your opinions.

Thanks,
Stefan

[jriegel]

In my opinion it's better to use the quaternions, and my test implementation showed that this works fine (still lot's of testing to do). Any objections on that?

IMO is Ok, since we use it internally anyway..

add_constraint_parallel_face(Placement object1, Placement face1, Placement object2, Placement face2)

exactly!

I would suggest following Assemby constraints (users view) for the start. If you implment it as one or more solver constraints makes no difference.

1. Offset -> parallel faces with distance and orientation (same or opposite)
2. Axle -> two e.g. cylinders selected (which is for the solver line on line constraint)
3. Contact -> face on face, opposite face normal
4. Angle -> between two faces
5. Fixed

I think with this 5 constraints we could build up a very decent Assembly module. I hardly use more in Catia.

Do we have to fork the solver or can we use the same code base?
I can imagine that it becomes difficult to tune the solver for both applications...
With this four constraints

[logari81]

@Stefan: I have no objections to your ideas. The problematic of which part to keep fixed doesn't belong to the solver. I think that it should just be the first part in the assembly tree but this has nothing to do with the solver. I am excited to see some working examples.

@Jürgen: My suggestion was to fork the solver. It is what we will probably end up with.

[ickby]

fine, i will start rigth away. Hope to get something to show to the end of the week!

To the solver forking: I would like to wait as long as nothing special is needed for the assembling as it makes mainaining easyer till then. For now I write constraints which do not need any changes.

[jriegel]

Sounds good!

I will start the Assembly object framework right after the 0.12 release to open the new hunting season!