## FreeGCS 3D constraints

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
ickby
Posts: 3058
Joined: Wed Oct 05, 2011 7:36 am

### FreeGCS 3D constraints

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
Attachments
3DSolverTest.rar
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

### Re: FreeGCS 3D constraints

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.
ickby wrote: 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.
ickby wrote: 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.
ickby wrote: 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?
ickby wrote: 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.
Last edited by logari81 on Thu Oct 06, 2011 3:28 pm, edited 1 time in total.
ickby
Posts: 3058
Joined: Wed Oct 05, 2011 7:36 am

### Re: FreeGCS 3D constraints

Hello logari,

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
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

### Re: FreeGCS 3D constraints

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...
Stop whining - start coding!
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

### Re: FreeGCS 3D constraints

@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
Posts: 3058
Joined: Wed Oct 05, 2011 7:36 am

### Re: FreeGCS 3D constraints

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
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

### Re: FreeGCS 3D constraints

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
Stop whining - start coding!
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

### Re: FreeGCS 3D constraints

@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
Posts: 3058
Joined: Wed Oct 05, 2011 7:36 am

### Re: FreeGCS 3D constraints

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