Assembly3 preview
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
I have added my own logic to auto relax/skip redundant composite constraints. Now multi-PlaneAlignment should be even more reliable. And multi-PlaneCoincident works, too.
The order of appearance of the constraints determines how redundancies are handled.
PlaneCoincident: the second PlaneCoincident of the same pair or parts is relax to a 2d points horizontal or vertical constraint. The third and onwards are ignored. Any PlaneCoincident constraint will be ignored if there are any pre-existing PlaneCoincident or AxialAlignment.
PlaneAlignment: the second one is relaxed to two PointInPlane or PointPlaneDistance constraint. The third one is relaxed to one PointInPlane or PointPlaneDistance. The forth and onwards are ignored. Any PlaneCoincident constraint will be ignored if there are any existing PlaneCoincident or AxialAlignment.
AxialAlignment: ignored if there are any existing PlaneAlignment or PlaneCoincident constraints
These rules are only heuristics, and can still lead to inconsistent result if your specify the constraints "too wrong", e.g. two plane coincident on two different planes, or two plane alignment on the same plane.
In the following screencast, I've turned off auto re-solve at the beginning, because it is kind of hard to select elements for the second PlaneCoincident if they snapped together. Once the second one is created and snapped, you can see that there are two solutions when I dragged the parts. Because, according to the logic above, the points horizontal/vertical constraint can indeed be satisfied at two different locations. In fact, if you consider plane orientation, there are more solutions. This is a thing with SolveSpace that you should probably be getting used too. It is better to be under constrained than over constrained.
The order of appearance of the constraints determines how redundancies are handled.
PlaneCoincident: the second PlaneCoincident of the same pair or parts is relax to a 2d points horizontal or vertical constraint. The third and onwards are ignored. Any PlaneCoincident constraint will be ignored if there are any pre-existing PlaneCoincident or AxialAlignment.
PlaneAlignment: the second one is relaxed to two PointInPlane or PointPlaneDistance constraint. The third one is relaxed to one PointInPlane or PointPlaneDistance. The forth and onwards are ignored. Any PlaneCoincident constraint will be ignored if there are any existing PlaneCoincident or AxialAlignment.
AxialAlignment: ignored if there are any existing PlaneAlignment or PlaneCoincident constraints
These rules are only heuristics, and can still lead to inconsistent result if your specify the constraints "too wrong", e.g. two plane coincident on two different planes, or two plane alignment on the same plane.
In the following screencast, I've turned off auto re-solve at the beginning, because it is kind of hard to select elements for the second PlaneCoincident if they snapped together. Once the second one is created and snapped, you can see that there are two solutions when I dragged the parts. Because, according to the logic above, the points horizontal/vertical constraint can indeed be satisfied at two different locations. In fact, if you consider plane orientation, there are more solutions. This is a thing with SolveSpace that you should probably be getting used too. It is better to be under constrained than over constrained.
Re: Assembly3 preview
The screencast you have added is 'in real life' not realisitic. Linking two circles on the same plane should normally result in zero DOF (considering one part is fixed/locked). Now there is still one DOF that can not excist. To my very humble opinion that is...
That said; keep up the good work! You're doing an amazing job realthunder, I love to see the Assembly3 WB getting 'mature'. I follow this thread with great interest.
That said; keep up the good work! You're doing an amazing job realthunder, I love to see the Assembly3 WB getting 'mature'. I follow this thread with great interest.
Re: Assembly3 preview
Excellent news! We are getting closer to the manufacturers' reflexes.realthunder wrote: ↑Fri Mar 23, 2018 9:30 am I have added my own logic to auto relax/skip redundant composite constraints. Now multi-PlaneAlignment should be even more reliable. And multi-PlaneCoincident works, too. ...
If you only constrain the centers of the last two circles, would that eliminate the problem of the 2 position possibilities?
I share this opinion.
My website : http://help-freecad-jpg87.fr updated 2023/11/06
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
There is really no DOF left in this case. When we talk about DOF, the emphasis is on 'F'. There are multiple solutions, yes, but no 'Free' variables. The multiple solution is inevitable in this kind of inverse problem, like given an angle, since we write equation using sine or cosine, there bound to be multiple solutions satisfy the equation. In fact, the two solutions found by the horizontal constraint are the same positive and negative angles between the two associated parts.Koemi wrote: ↑Fri Mar 23, 2018 10:42 am The screencast you have added is 'in real life' not realisitic. Linking two circles on the same plane should normally result in zero DOF (considering one part is fixed/locked). Now there is still one DOF that can not excist. To my very humble opinion that is...
This also answers the following questions.
In theory, to disambiguate this kind of problem, one must ask the solver for all possible solutions, and compare the solution to the desired positions. I guess this may complicates solver implementation quite a bit.
Re: Assembly3 preview
I would suggest for this to stay enabled:
Lets just leave this things to SolveSpace solver and to the way it works? As the general problem was too strict redundant constraints policy and not composite constraints?
You once said there is a setting you could expose. That determines on how robust SolveSpace solver is to "initial conditions". This is something that makes sense to me. And after i guess use cases and feedback should drive the maturing of the Assembly 3? I read some info and i guess SolveSpace solver doesn't use sparse matrix decomposition ATM. Therefore if we end up using it for a while. There is still room for future speed improvements in large assemblies. But i guess lets first see how things evolve around Assembly 1 strategy.
As for Link effort. The way i see it one thing is still missing. In use cases where you create a Link to geometry in external file. And there is substantial amount of "design history" in that file. Or in use cases where you need to have a big number of "part documents". There should be a way (one example of a solution to the problem being Assembly 2 import feature). Where only the "subset of geometry" would get loaded and documents wouldn't need to be opened at all. Or it would be opened only to extract a "subset of geometry" to crate a Link feature and after to be closed.
As for Topology effort. If i am correct in assuming you are now after history and geometry based solution. I feel that if that is correct. My guidance likely came to an end and @ickby should take over.
As it improves things substantially. But as for this:realthunder wrote: ↑Thu Mar 22, 2018 10:16 am It turns out that SolveSpace allows redundant constraints.
To get removed as "auto relax" results in this (fourth PlaneAlignement constraint added):realthunder wrote: ↑Fri Mar 23, 2018 9:30 am I have added my own logic to auto relax/skip redundant composite constraints. Now multi-PlaneAlignment should be even more reliable. And multi-PlaneCoincident works, too.
Lets just leave this things to SolveSpace solver and to the way it works? As the general problem was too strict redundant constraints policy and not composite constraints?
You once said there is a setting you could expose. That determines on how robust SolveSpace solver is to "initial conditions". This is something that makes sense to me. And after i guess use cases and feedback should drive the maturing of the Assembly 3? I read some info and i guess SolveSpace solver doesn't use sparse matrix decomposition ATM. Therefore if we end up using it for a while. There is still room for future speed improvements in large assemblies. But i guess lets first see how things evolve around Assembly 1 strategy.
As for Link effort. The way i see it one thing is still missing. In use cases where you create a Link to geometry in external file. And there is substantial amount of "design history" in that file. Or in use cases where you need to have a big number of "part documents". There should be a way (one example of a solution to the problem being Assembly 2 import feature). Where only the "subset of geometry" would get loaded and documents wouldn't need to be opened at all. Or it would be opened only to extract a "subset of geometry" to crate a Link feature and after to be closed.
As for Topology effort. If i am correct in assuming you are now after history and geometry based solution. I feel that if that is correct. My guidance likely came to an end and @ickby should take over.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
Could you please attach the file that shows this problem? SolverSpace redundant constraint tolerance is still on. My logic only handles some specific combinations of my added composites.
I haven't looked into this yet, about the initial condition. As for the speed, the easiest speed up is to move the entire asm3 code to C++, then we can have roughly the same response speed as SolveSpace CAD itself. But I don't think that's worth it at the moment. Ideally we shall make our own solver work first, or find another one with a compatible license.You once said there is a setting you could expose. That determines on how robust SolveSpace solver is to "initial conditions". This is something that makes sense to me. And after i guess use cases and feedback should drive the maturing of the Assembly 3? I read some info and i guess SolveSpace solver doesn't use sparse matrix decomposition ATM. Therefore if we end up using it for a while. There is still room for future speed improvements in large assemblies. But i guess lets first see how things evolve around Assembly 1 strategy.
That's a nice feature to have. I'll think about it.As for Link effort. The way i see it one thing is still missing. In use cases where you create a Link to geometry in external file. And there is substantial amount of "design history" in that file. Or in use cases where you need to have a big number of "part documents". There should be a way (one example of a solution to the problem being Assembly 2 import feature). Where only the "subset of geometry" would get loaded and documents wouldn't need to be opened at all. Or it would be opened only to extract a "subset of geometry" to crate a Link feature and after to be closed.
Well, using history is always the intention. I did read the papers and checked others code before starting.As for Topology effort. If i am correct in assuming you are now after history and geometry based solution. I feel that if that is correct. My guidance likely came to an end and @ickby should take over.
Re: Assembly3 preview
A lot of hours Im searching. Could you help me to make the final constraint? Rod must be straight housed in the hole.
Have a look inside the pin rod assembly, i succeed to use a shape2D while i haven't the sketch.
OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.5235 (Git shallow)
Build type: Release
Branch: (HEAD detached at FETCH_HEAD)
Hash: f405cbcfb65f681366cf4ff09518cc4b95d19c99
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
Locale: French/France (fr_FR)
Have a look inside the pin rod assembly, i succeed to use a shape2D while i haven't the sketch.
OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.5235 (Git shallow)
Build type: Release
Branch: (HEAD detached at FETCH_HEAD)
Hash: f405cbcfb65f681366cf4ff09518cc4b95d19c99
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
Locale: French/France (fr_FR)
- Attachments
-
- GlissGoup.FCStd
- (178.61 KiB) Downloaded 101 times
-
- Capture.JPG (38.6 KiB) Viewed 2278 times
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
You are making things too complicated. I've deleted everything leaving only the bodies. You have the sketch containing the circle to create the rod, which is perfect for use as constraining element. Using Axial Alignment along is enough. It accepts more than two elements, so you can conveniently add more elements aligning on the same axis. BTW, Plane Coincident/Alignment/Parallel all support multiple elements.
Re: Assembly3 preview
I agree with that. But its not possible to use clones?
Re: Assembly3 preview
Yes. When you enabled redundant constraint tolerance. PlaneAlignment started to work more like Assembly 2. Composite constraints didn't cause solver troubles anymore as before. After you added the additional logic to handle composite constraints. I got results as seen above. I didn't save the original file therefore i made a new one and attached it. Notice that it only took 2 PlaneAlignment constraints this time for things to start misbehaving. In addition try to delete a cube from assembly (FreeCAD crash).realthunder wrote: ↑Wed Mar 28, 2018 10:56 pm SolverSpace redundant constraint tolerance is still on. My logic only handles some specific combinations of my added composites.
From general point of view. If this area could improve a bit. Likely that would be that. Everything else i guess is more or less in OK state now. Maturing and relations related discussions should likely happen based on use case feedback going forward.I haven't looked into this yet, about the initial condition.
Note that i didn't complain about the speed. I just researched a bit on where SolveSpace is ATM. And it has still potential to get faster. As for what we will do in the future. End up using SolveSpace for a while, write our own solver or do something else. I don't know. What i do know is Assembly 3 likely will end up being a good option. And from user point of view the license is compatible.As for the speed, the easiest speed up is to move the entire asm3 code to C++, then we can have roughly the same response speed as SolveSpace CAD itself. But I don't think that's worth it at the moment. Ideally we shall make our own solver work first, or find another one with a compatible license.
Good to hear that. This is basically what "the core" feature of a "Link" effort i guess is. At least the discussion in the past (before the Link effort) went in this direction. On how it would be nice to have something like that.That's a nice feature to have. I'll think about it.
Great. After you share your work hopefully @ickby will provide some feedback. And evaluating @ezzieyguywuf approach will get easier.Well, using history is always the intention. I did read the papers and checked others code before starting.
- Attachments
-
- AssemblyRelax.fcstd
- (9.51 KiB) Downloaded 72 times