Assembly 2 workbench for FreeCAD v0.15

[danielfalck]

Thank you hamish for making the video. It confirmed some things for me- mainly that I was using the same method as you to try your workbench. The root of my problem was my version of scipy and maybe numpy were not working. After uninstalling them through synaptic and reinstalling newer versions using pip, all is good. Thank you. Now I can use your workbench.

[Bhutun]

Hi Hamish,

Great to see a working assembly for Freecad. Sure it's going to be useful for many applications. I am keenly interested in understanding limitation for my specific requirement. My typical model will have around 50-500 parts. Will the "hamish assembly solver" work for that kind of model. From your experience, what is typical running time on an average desktop for say 10 parts with 20 constratits, 50 parts with 100 constraits or 100 parts with 200 constraints? What kind of complexities becomes too hot to handle for it? and what kind of complexity will send me for a quick nap before solutions comes out. How many times does it return a correct solution for say 10 parts 20 constraints case for a 100 trial?

Appreciate your effort in building it up and will be delighted if it can suits my requirement.

Cheers,
Bhutun

[hamish]

Hi Bhutun,

At the moment of this posting the assembly solver 2 will likely really begin to struggle with assemblies of 20 parts or more.
The reason is that the solver currently minimizes the square sum of the constraints errors, i.e. formulates the constraint problem as a single objective optimization problem.
This approach is very inefficient, but really easy to implement.
When i get some spare time, i will look into implementing Newton's method for solving a system of non-linear equations, which should result in a substantial performance increase.

Will keep you posted ...

[Bhutun]

Sounds interesting.. Some form of newton would be progressive.. google says graph + iterative is what modern solvers uses. Any thought on that?

[ickby]

Graph and numeric (iterative) is what freecads c++ based assembly solver uses. The reason for that is that an assembly problem forms a non-metric parameter space which is rather bad for numeric solvers. A pure numeric approach will never be very robust. That is what I learned during extending the 2d sketcher to 3d a few years ago. Actually it was pretty.much the same as Hamish's solver now, just with analytical gradients instead of numeric ones. Since then I work on the new graph based version, which goes forward pretty well, but only slowly because assembly module in itself is not likely to hit master any time soon.

[Bhutun]

Yay... FreeCAD assembly solver is going to be one hell of modern solvers..

Ickby, is there some specific approach(documented somewhere?) that you are following or are you creatively building your own algorithm on the go? Is your latest code solving cyclic constraints robustly? Basically, my application hardly cares about the interface and master integration of assembly. As far as the constraints are solved robustly, it does the job for me. Are we already there?

Cheers,
Bhutun

[ickby]

Yay... FreeCAD assembly solver is going to be one hell of modern solvers..

Hehe I don't think so, we are lucky enough if we get it to work properly. The comercial codes (simens dcm or ledas etc.) are developed for decades and cost multiple hundred thousand dollars, this shows we are not facing a trival problem here

is there some specific approach(documented somewhere?) that you are following or are you creatively building your own algorithm on the go?

I follow a few papers on the matter. However, non give realy an insight in how their solvers work, only partial information. And most puplications are research related and ultimativly dead ends. Therfore I combine their ideas with my own and create my custom software architecture. It gets pretty involved when one combines graph based and numeric aproaches... And I don't have much documentation written up to now. It get's more and more in the code base, but that is most likely not enough to get a clear picture ( also because I do many code experiments, lernaing new stuff and for the fun of it, makes it rahter hard to grasp the code )

Is your latest code solving cyclic constraints robustly

I assume you tested the first freecad assembly module where I deactivated cyclic constraints because of the roustness issue? In the state of the solver used there a pure numerical approach was used, even if the graph was build up internaly. Currently I work on graph analysis and reduction, so we are getting better. But it is not in a state where I would call it roubustly or finished.

Are we already there?

Not yet, but we could be there in short time if needed. But that does not make sense without the assembly workbench infrastrcuture, so it takes long

And that is actually why I realy likle hamish's python solver. It don't need an involved build infrastructure or anything but can be downloaded and used on the fly, very nice!

@hamish: sorry for highjacking your thread

[Bhutun]

Thanks for your reply. Your work is worth hundred of thousands of dollars and we have already crossed one decade mark, so hopeful of seeing a state of art solver some day.

-An Optimist

[sgrogan]

Has anyone been able to get this to work on Windows?
I can't seem to install scypy in the right place.

My latest attept was to place it in my Python27 directory that is my system path.

EDIT:
A fresh pull removes the SciPy dependancy. clone in your MOD folder and everything works

[hamish]

Graph and numeric (iterative) is what freecads c++ based assembly solver uses. The reason for that is that an assembly problem forms a non-metric parameter space which is rather bad for numeric solvers. A pure numeric approach will never be very robust. That is what I learned during extending the 2d sketcher to 3d a few years ago. Actually it was pretty.much the same as Hamish's solver now, just with analytical gradients instead of numeric ones. Since then I work on the new graph based version, which goes forward pretty well, but only slowly because assembly module in itself is not likely to hit master any time soon.

Ickby is right on the money, a pure numeric solver for 3d constraint system is rather unstable.
At least in my case for the assembly2 wb, setting up the constraint problem solely as a system of non-linear equations, and then attempting to solving it via Newton method, did not work very well...

I ended up overhauling the assembly2 constraint solver system to what a graph and numeric solver does.
side note: is there perhaps a wikipedia page outlining these methods?.
The new assembly 2 constraint solver begins with an unconstrained or free system.
The degrees-of-freedom of this free system allow for all possible movements and rotations of the objects in the assembly.
Then for each constraint equation

• adjust those degrees-of-freedom to solve an constraint equation ( f(x) = 0 )
• determine new degrees-of-freedom (i.e. movements and rotations which can be made without violating the constraint equation added)

This works well for the standard assembly constraints (with no complex interactions), where the reduction of the degrees-of-system have analytical solutions.
However, for complex mechanics (cam, bar linkage systems, ...) the reductions of degrees-of-freedom needs to done numerically (not implemented [yet] in the assembly 2 work bench) and suppose will be rather slow.
If this difficulty in reducing degree-of-freedoms is a property of 3D constraints problem in general, or just to my approach, i do not know.

Those of you curious enough to have read this far, I sure would like to see a demo, have a look at the screen recording at
http://youtu.be/ufhyUxQkeC0