Another approach to assembly solver (A2plus)

[Kunda1]

I have made a help request in the scripting section.

Hi @kbwbe, care to post a link to said thread?

Edit: found it
https://forum.freecadweb.org/viewtopic. ... 92#p453592

[Zolko]

BTW - do you know how to draw, from Python level, a 3D arrow of given origin and direction?

I have made a help request in the scripting section.

I'd be very interested in this also

[kbwbe]

I'd be very interested in this also

Resulting principle from help-request ( https://forum.freecadweb.org/viewtopic. ... 11#p453711) is:

Code: Select all

import FreeCADGui
import FreeCAD
from PySide import QtGui
from PySide import QtCore

from pivy import coin

#setup the contour
color = coin.SoBaseColor()
color.rgb = (1, 0, 0)

points=coin.SoCoordinate3()
lines=coin.SoLineSet()

points.point.values = ( (0,0,0),(10,10,10),(10,10,0) )


#feed data to separator
sep=coin.SoSeparator()
sep.addChild(points)
sep.addChild(color)
sep.addChild(lines)

#add separator to sceneGraph
sg = FreeCADGui.ActiveDocument.ActiveView.getSceneGraph()
sg.addChild(sep)

BTW - do you know how to draw, from Python level, a 3D arrow of given origin and direction?
It would greatly improve my debug capabilities to draw some arrows representing all the intermediate vectors that are used to calculate each step of solving.

I will now create some functionality according to this within the workbench.

[kbwbe]

BTW - do you know how to draw, from Python level, a 3D arrow of given origin and direction?
It would greatly improve my debug capabilities to draw some arrows representing all the intermediate vectors that are used to calculate each step of solving.

First quick and dirty test: Convergency (red = spin vector, blue = move vector) tracked on screen...
(Arrow heads missing, will follow)
.

tracking.png (52.66 KiB) Viewed 12447 times

[topyra]

I've done some changes in your code.
I have only my few models to test it, so it is not tested well.
Probably it may fail for some other models (maybe in different scale, with different constrains etc.).
So rather think about is as a proof-of-concept, then solution for everything.

But for my model works, is faster and can handle models with everything messed up.
But it still not works for my more complex models in animation mode - I don't understand why, but I not analyzed this method yet.
With less complex models it works and is quite fast

Main changes:
1) spinCenter is now randomly chosen from inside "bounding box" - it works quite well to avoid stuck in some 'pitfalls'
2) rotations are weighted averaged by radius length (so it works like torque right now), for axial spins that (pseudo)radius is refPointsBoundBoxSize
3) added one more required accuracy step (0.033) - also I think here posAccuracy should not be absolute (it would behave different in different scale models) - should be calculated based on model bounding box size
4) added lot of debug messages (+ changed DebugMsg to be compatible with print() )
5) added SOLVER_ONESTEP to do only one step of solving (usefull for debugging)

I attached .patch with changes all together, because your github project is private and I can't create a branch.

[kbwbe]

Thank you very much. Sounds very, very interesting. I did some first tests. For a very small system, solving was succesful. For a medium sized model solving failed. I attach the test file.

I created a branch called "topyra" at github repo. Your patch is already applied. So you can do PR's if you want.

[topyra]

I found there was as problem in one constrain rigids.
refPointsBoundBoxSize was zero, and I used this as 'radius' for axial forces.

As a workaround I expand bounding box by 5 in each direction (not good solution, as every that use fixed number not related to actual model dimensions), but it fixing this issue. I'll find something better later.
Patch is attached.

But I cant still solve pump-system, but I found interesting thing.
I can't be solved using 'a2p_SolverCommand' - it can't even go down to 10.0 accuracy.

But when I use 'a2p_SearchConstraintConflictsCommand' (conflict finder) it is able to solve it quick in each step with perfect accuracy like 1e-07

Could you please briefly describe differences between regular solver, and solving during searching for conflicts?
Is only difference is adding constrains one-by-one? Or there is some more magic behind?

[topyra]

Ok, found simple bug why pump was unsolvable.

In axial rotation when calculated 'weight' of each rotation I temporally put '30' and forgot about that.
So there is next patch (should be applied on one from previous post)

PS I don't know much about github.com but is this possible to give me permission to commit changes into topyra branch?

[kbwbe]

I applied both patches to branch "topyra" and uploaded the new version to github.

PS I don't know much about github.com but is this possible to give me permission to commit changes into topyra branch?

I think i cannot grant commit permissions to a single branch only. That's a problem.

Usual way is: (but im also not an very experienced git user)
- you create your own github accont (it's free of costs)
- fork my A2plus repo to your account at github
- clone your A2plus repo to your local machine
- checkout the topyra branch on local machine
- do your changes
- commit them on your local machine
- push the changed branch to your repo
- on github, use the compare button. After that you can create a pull request, which appears in my repo. I will merge it soon to your branch.

It's much better to track changes at github than managing patch sets manually.

If to complicated, i can still apply your patches like i do at moment.

Test results of your new changes:
- pump-system can be solved now

I attach 2 other files, which now have solving problems with your new version.

P.S: Tomorrow, i try to implement the graphical output for 3D debugging of constraints. I will try to reduce the 3D output somehow to selected rigids/constraints. Perhaps we can trace the problems more exactly.

[kbwbe]

BTW - do you know how to draw, from Python level, a 3D arrow of given origin and direction?
It would greatly improve my debug capabilities to draw some arrows representing all the intermediate vectors that are used to calculate each step of solving.

I have integrated some helper tools for this now.

Within a2plib.py, there is now a section for debug setup and you can activate a GRAPHICALDEBUG flag:

Code: Select all

#===================================================
# do debug settings here:
#===================================================
A2P_DEBUG_LEVEL = A2P_DEBUG_NONE    #normal: A2P_DEBUG_NONE
GRAPHICALDEBUG = True               #normal: False

# for debug purposes
# 0:normal
# 1:one step in each worklist
# 2:one step in first worklist
SOLVER_ONESTEP = 1                  #normal: 0
#===================================================

The GRAPHICALDEBUG is used together with a new function in a2plib:

Code: Select all

def drawDebugVectorAt(position,direction,rgbColor):
    '''
    function draws a vector directly to 3D view using pivy/Coin
    
    expects position and direction as Base.vector type
    color as tuple like (1,0,0)
    '''
    color = coin.SoBaseColor()
    color.rgb = rgbColor

    # Line style.
    lineStyle = coin.SoDrawStyle()
    lineStyle.style = coin.SoDrawStyle.LINES
    lineStyle.lineWidth = 2

    points=coin.SoCoordinate3()
    lines=coin.SoLineSet()

    startPoint = position.x,position.y,position.z
    ep = position.add(direction)
    endPoint = ep.x,ep.y,ep.z
    
    points.point.values = (startPoint,endPoint)
    
    #create and feed data to separator
    sep=coin.SoSeparator()
    sep.addChild(points)
    sep.addChild(color)
    sep.addChild(lineStyle)    
    sep.addChild(lines)    
    
    #add separator to sceneGraph
    sg = FreeCADGui.ActiveDocument.ActiveView.getSceneGraph()
    sg.addChild(sep)
    
    solver_debug_objects.append(sep)

If GRAPHICALDEBUG==True the imported parts of A2plus get a new boolean property "debugmode"
If you set "debugmode" = True at moment the move function of the corresponding rigid will draw it's movement vector (blue) and it's rotation vector (red) to screen. So you can see what the solver is producing.

graphical-debug-mode.png (116.98 KiB) Viewed 12191 times

If the output is getting to much, you can clean up the debug lines with this button:

clean-up-button.png (1.69 KiB) Viewed 12191 times