## Another approach to assembly solver (A2plus)

Discussion about the development of the Assembly workbench.
kbwbe
Posts: 860
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

### Re: Another approach to assembly solver (A2plus)

project4 wrote:
Sun Jul 29, 2018 6:09 pm
Ok. Based on the printouts now I have the needed rotation center and the rotation angle...
How do I apply it to the rigid.spin?

I should probably get somehow the rotation axis... how do I do it?

@kbwbe, @Turro75
Your math lessons are needed again
Hi @project4,

if you are working with 2 vectors, which are not colinear, the rotation axis needed to rotate one vector to the other is a vector which is perpendicular to both. A cross product always generates a vector with this property. If the vectors are colinear, the crossproduct will generate a zero-vector with all components equal to zero, no valid axis is defined then.

So, if you have the 2 vectors, vec1.cross(vec2).normalize() calculates the axis with length==1.0 because of normalize().
If the operation returns vector(0,0,0), no axis does exist and it is not valid.

In A2plus a spin is defined as an axis with length "angle" (unit degrees!)
So: spin = vec1.cross(vec2).normalize().multiply(math.degrees(angle))

You always have to check whether doing vec1.cross(vec2) or vec2.cross(vec1) is the correct one you need, as they have the same axis, but they are opposed.
KBWBE

https://github.com/kbwbe/A2plus
Tutorials:
Paul Randall: https://youtu.be/mnkecA9S7kc
kbwbe
Posts: 860
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

### Re: Another approach to assembly solver (A2plus)

Turro75 wrote:
Sun Jul 29, 2018 6:38 pm
Guys,

this was a thought Sunday, let's see what it turned out, the first library to handle DOF...

I wrote it as a library so You can easily insert it in the code by Yourself

I detailed as much as I can in the file, it should be self-explained anyway let me know for any further info
Ok !!!!! Some stuff to read ...
KBWBE

https://github.com/kbwbe/A2plus
Tutorials:
Paul Randall: https://youtu.be/mnkecA9S7kc
project4
Posts: 153
Joined: Fri Jul 12, 2013 12:53 pm

### Re: Another approach to assembly solver (A2plus)

kbwbe wrote:
Sun Jul 29, 2018 6:40 pm
project4 wrote:
Sun Jul 29, 2018 6:09 pm
Ok. Based on the printouts now I have the needed rotation center and the rotation angle...
How do I apply it to the rigid.spin?

I should probably get somehow the rotation axis... how do I do it?

@kbwbe, @Turro75
Your math lessons are needed again
Hi @project4,

if you are working with 2 vectors, which are not colinear, the rotation axis needed to rotate one vector to the other is a vector which is perpendicular to both. A cross product always generates a vector with this property. If the vectors are colinear, the crossproduct will generate a zero-vector with all components equal to zero, no valid axis is defined then.

So, if you have the 2 vectors, vec1.cross(vec2).normalize() calculates the axis with length==1.0 because of normalize().
If the operation returns vector(0,0,0), no axis does exist and it is not valid.

In A2plus a spin is defined as an axis with length "angle" (unit degrees!)
So: spin = vec1.cross(vec2).normalize().multiply(math.degrees(angle))

You always have to check whether doing vec1.cross(vec2) or vec2.cross(vec1) is the correct one you need, as they have the same axis, but they are opposed.
I am 1 step behind that.
I have the needed spinCenter.
There are dependencies refPoints.
How do I get to the rotation axis from that?
vec1 = spinCenter - dep.refPoint
vec1 = spinCenter - foreignDep.refPoint
angle = DraftVecUtils.angle(v1, v2) # I know, I will get rid of it if I get to the needed results
spin = vec1.cross(vec2).normalize().multiply(math.degrees(angle))

Is that correct?
kbwbe
Posts: 860
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

### Re: Another approach to assembly solver (A2plus)

project4 wrote:
Sun Jul 29, 2018 7:10 pm
I am 1 step behind that.
I have the needed spinCenter.
There are dependencies refPoints.
How do I get to the rotation axis from that?
vec1 = spinCenter - dep.refPoint
vec1 = spinCenter - foreignDep.refPoint
angle = DraftVecUtils.angle(v1, v2) # I know, I will get rid of it if I get to the needed results
spin = vec1.cross(vec2).normalize().multiply(math.degrees(angle))

Is that correct?
It's nearly correct. Vectors always have a direction. So it is a difference if you do vec1-vec2 or vec2-vec1.
The way i am using in this context is: vectorToRefPoinFromSpinCenter = dep.refPoint - rig.spinCenter, not vice versa. It should always be consistently in whole WB.

So your pseudo code would be like this:

Code: Select all

``````vec1 = dep.refPoint - spinCenter
vec2 = foreignDep.refPoint - spinCenter
angle = DraftVecUtils.angle(v1, v2) # <== only positive results allowed, direction comes from cross product next line
spin = vec1.cross(vec2).normalize().multiply(math.degrees(angle)) #<== numerical exeption will happen if ZeroVector.normalize()
``````
KBWBE

https://github.com/kbwbe/A2plus
Tutorials:
Paul Randall: https://youtu.be/mnkecA9S7kc
manuelkrause
Posts: 442
Joined: Thu Jul 05, 2018 7:16 pm

### Re: Another approach to assembly solver (A2plus)

Turro75 wrote:
Sun Jul 29, 2018 6:38 pm
Guys,

this was a thought Sunday, let's see what it turned out, the first library to handle DOF...

I wrote it as a library so You can easily insert it in the code by Yourself

I detailed as much as I can in the file, it should be self-explained anyway let me know for any further info
@Turro75:

Wow, that's a huge piece of work you've done!

The #comments you've added are really fine to understand a bit more, what you intend! Oh yes, and you added the lockRotation back to it's intention.

At first reading into it, I've seen some "(" and ")" missing, while you otherwise used them. Hopefully not harmful but maybe worth a re-check. Maybe only typos.

Thank you,
Manuel

EDIT:
Sorry for bothering, after second reading it only affects the "if dbg:" lines.
/EDIT
kbwbe
Posts: 860
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

### Re: Another approach to assembly solver (A2plus)

@Turro75, @project4

i added Turro's library to branch "solver-stabilization". It's new name there is: "a2p_libDOF".
KBWBE

https://github.com/kbwbe/A2plus
Tutorials:
Paul Randall: https://youtu.be/mnkecA9S7kc
Turro75
Posts: 166
Joined: Mon Aug 15, 2016 10:23 pm

### Re: Another approach to assembly solver (A2plus)

A little update with some helper function added
Attachments
DOF_Management.py
Turro75
Posts: 166
Joined: Mon Aug 15, 2016 10:23 pm

### Re: Another approach to assembly solver (A2plus)

kbwbe wrote:
Mon Jul 30, 2018 10:28 am
@Turro75, @project4

i added Turro's library to branch "solver-stabilization". It's new name there is: "a2p_libDOF".
Thanks Kbwbe!

for sure there are bugs, anyway it will be faster fix them once inserted in the getcandidates methods.

Regarding lock rotation, I think it will be quite easy the handling of that property as:
• if activated the rotation is always fully locked so You can skip the rigid from spin calculation
• if deactivated You can do as Today
Do You think You can skip move or rotation independently while solving?
kbwbe
Posts: 860
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

### Re: Another approach to assembly solver (A2plus)

Turro75 wrote:
Mon Jul 30, 2018 12:31 pm
Do You think You can skip move or rotation independently while solving?
Hi Turro,
i do not really know at moment. For coding, it is no problem. But in reality any "magnetic" rotation is inexact per calculation step somehow, and moves are necessary to correct some errors. So i do not know at moment, what will happen if trying this.

A very good thing would be, using your systematics to find the "candidates" for next partial system to solve. Is that possible ?

Do you perhaps have some "pseudo-code" ideas ?
KBWBE

https://github.com/kbwbe/A2plus
Tutorials:
Paul Randall: https://youtu.be/mnkecA9S7kc
project4
Posts: 153
Joined: Fri Jul 12, 2013 12:53 pm

### Re: Another approach to assembly solver (A2plus)

Hi guys,

Sorry for being less involved recently. There is a chance I'll have to step down from active involvement due to very big changes in my business that will require all of my time for some period.

For now, I was playing with the code to try my rotations theory...
With the experimental code any 3 parts assembly connected as a chain with 1 part fixed takes exactly 4 steps:
1 step to move 2'nd part + 1 step to understand that there is nothing should be moved any more
1 step to move 3'rd part + 1 step to understand that there is nothing should be moved any more

To compare, my chain assembly (1 constraint between every part) took 200-300 steps to resolve, the bigplate assembly (2 constraints between every part) took thousands (or 10s thousands?) of steps. Both need only 4 steps as I wrote.

Every step performs move, rotate to align axis and rotate based on constraints refPoints. The code calculates the exact spin point and angle based on the refPoints.

I've tried it on 6DOF model, but it didn't work well. The piston started to jump around the needed point, probably due to looped connection between the pistons and cylinders. Didn't have the time to debug it further. CrankShaft didn't assemble at all, didn't debug it yet.

That code could work only with the chained parts and with proper DOF analysis it might help alot if we will be able to recognize the chains that should be moved all together.

I hope I will still have some time to debug the code and bring it to the level that it will work with all the assemblies we have. If not, I'll clean it abit and push to GitHub so you could use it as a reference and hopefully make it work.

Thinking while writing the post, its possible that there is a bug somewhere around the tempfixed flag since when 3'rd part added to the scene, I didn't see the second part move toward the 3'rd part, but only the 3'rd part moved toward the second...
But I still think the code will improve the solver speed.