## Another approach to assembly solver (A2plus)

Discussion about the development of the Assembly workbench.
project4
Posts: 153
Joined: Fri Jul 12, 2013 12:53 pm

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

Turro75 wrote:
Mon Jul 23, 2018 6:50 pm
let's wait for a prototype, consider the axis are mainly the ref axis of a constraint.

i.e. in circular edge the remaining dof will be one rot axis, the same used for the constraint.
if another circular edge is defined on the same rigid, we have to compare the axis of the second constraint of the the one above, if the axis is the same (within tolerance) to the one above we can ignore it and the object is still free to rotate around it or if is is different it doesn't matter how, the rigid become fully constrained. this is more or less the logic we need.
I already mapped all constraints, only single point coincident is not yet mapped.
ATM it is intended as a way to split assembly in small subassemblies allowing placement and eventually animate resulting dof of each rigid. of course if your intention is integrating it in the solving process, it would be a big overhead.
WARNING: Long and mindbreaking post

I had a similar way of thinking recently, but that way also improves the 6DOF model processing...

platform1(fixed) + cylynders are added to the computation.
To determine the allowed movement+rotation we have to move the hierarchy using father pointer up to a rigid that don't have any free DOF and tempfixed.
cylynders are sphere constrained to platform, which is fixed (no DOF and tempfixed from the start), so we stop the chain. Sphere constraint places the cylinders to the refPoint and allows rotation to any direction. Every cylinder is processed by its own chain (platform+cylinder in that case x6 times)

Move to child rigids for all that have all fathers tempfixed -> pistons in our case.
For every added rigid (piston) we build the processing chain up to a rigid which have no DOF and is tempfixed. Every chain is calculated by its own after that.
For piston case: father is cylinder - still have DOF (rotation), add it to the chain. Next father is platform1, which is fixed and no DOF, add it to the chain, stop the loop.
While processing the chain, tempfixed flag is set to False, to allow movement since rigids in the chain still have DOF left, besides the last one (which can actually stay tempfixed).
Processing the chain, ideally only piston should be moved in place since the cylinder is already in the needed place, but I think the solver might still rotate the cylinder. Am I right @kbwbw?

== Lets assume that pistons are not connected between themselves and are connected only to the top platform, which is not true in the model ==

At that stage all pistons and cylinders are in place, only the platform2 should be added, and here is the interesting part:
Platform2 is the only added part, so we start building the chain up to a fixed rigid with no DOF (platform1), which means all the rigids will be in calculation, which is the same as today, BUT!!!

While trying to rotate the piston to match needed place in the platform2, the algorithm should see that the piston don't have DOF in the rotation it needs to rotate, so the algo goes up the father chain to find a part that CAN rotate in needed direction, cylinder in that case and process the rotation on the found chain alltogether (similar to a single rigid built out of 2 rigids).

It sounds like we can just add all the rigids to the calculation and that's it, but in the flow I described the algorithm will be the same for all the models, without knowing if the model can be resolved easily or not.
The algorithm will also recognize 6 parts that might be moved together as a single rigid, which I believe will improve the performance as well.

For real life scenarios where most of the parts can't move, the chains back to non-movable parts will be very short and resolve quickly.
project4
Posts: 153
Joined: Fri Jul 12, 2013 12:53 pm

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

kbwbe wrote:
Mon Jul 23, 2018 7:21 pm
project4 wrote:
Mon Jul 23, 2018 6:31 pm
kbwbe wrote:
Mon Jul 23, 2018 6:11 pm
Hi @Turro,
this are good news. If we need six axis' inside a rigid, I think we have to implement 2 vectors per axis. One to the beginning, one to the end. So if a rigid is rotated, the axis can be reconstructed. But it will be more overhead as there 12 vectors more to be rotated. It is a lot !
Can't it be implemented with a multiplication to a vector where the axis that should not be moved/rotated is set to zero (or 1)?
I think with this method the orientation of the 6 axis' will not rotate with the rigid itself. I do not really know it is important for DOF's..
Yes, for that case it sounds like the DOF metadata will have to be rotated with the rigid, like the dependency data does today.
I don't see any other way to do it since you can't check with IFs anything related to 3D space (movement or rotation) without being always in sync with proper placements.

We'll probably have to try and see how it goes.
kbwbe
Posts: 953
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

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

@project4,
@Turro75,

i eliminated the expensive math.sin() and math.atan() functions from calcMoveData().
Branch solver-stabilization is updated again !
KBWBE

https://github.com/kbwbe/A2plus
Turro75
Posts: 175
Joined: Mon Aug 15, 2016 10:23 pm

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

@Kbwbe
@project4

let's see how Hamish code can be applied to a2plus.

as first thing the toolbar constraints must be splitted in low level constraint:
DOF_Part1.PNG (20.9 KiB) Viewed 330 times
that said let's see how each low level constraint affects the DOF in every condition:
DOF_Part2.PNG (70.66 KiB) Viewed 330 times
Attachments
DOF Calculation.ods
project4
Posts: 153
Joined: Fri Jul 12, 2013 12:53 pm

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

project4 wrote:
Mon Jul 23, 2018 7:49 pm
WARNING: Long and mindbreaking post

I had a similar way of thinking recently, but that way also improves the 6DOF model processing...

platform1(fixed) + cylynders are added to the computation.
To determine the allowed movement+rotation we have to move the hierarchy using father pointer up to a rigid that don't have any free DOF and tempfixed.
cylynders are sphere constrained to platform, which is fixed (no DOF and tempfixed from the start), so we stop the chain. Sphere constraint places the cylinders to the refPoint and allows rotation to any direction. Every cylinder is processed by its own chain (platform+cylinder in that case x6 times)

Move to child rigids for all that have all fathers tempfixed -> pistons in our case.
For every added rigid (piston) we build the processing chain up to a rigid which have no DOF and is tempfixed. Every chain is calculated by its own after that.
For piston case: father is cylinder - still have DOF (rotation), add it to the chain. Next father is platform1, which is fixed and no DOF, add it to the chain, stop the loop.
While processing the chain, tempfixed flag is set to False, to allow movement since rigids in the chain still have DOF left, besides the last one (which can actually stay tempfixed).
Processing the chain, ideally only piston should be moved in place since the cylinder is already in the needed place, but I think the solver might still rotate the cylinder. Am I right @kbwbw?

== Lets assume that pistons are not connected between themselves and are connected only to the top platform, which is not true in the model ==

At that stage all pistons and cylinders are in place, only the platform2 should be added, and here is the interesting part:
Platform2 is the only added part, so we start building the chain up to a fixed rigid with no DOF (platform1), which means all the rigids will be in calculation, which is the same as today, BUT!!!

While trying to rotate the piston to match needed place in the platform2, the algorithm should see that the piston don't have DOF in the rotation it needs to rotate, so the algo goes up the father chain to find a part that CAN rotate in needed direction, cylinder in that case and process the rotation on the found chain alltogether (similar to a single rigid built out of 2 rigids).

It sounds like we can just add all the rigids to the calculation and that's it, but in the flow I described the algorithm will be the same for all the models, without knowing if the model can be resolved easily or not.
The algorithm will also recognize 6 parts that might be moved together as a single rigid, which I believe will improve the performance as well.

For real life scenarios where most of the parts can't move, the chains back to non-movable parts will be very short and resolve quickly.
Update to the algorithm:
When moving in the parent's chain to find a rigid that can't be moved, so the chain search will be stopped...
That "can't move" flag should be set after previous chain calculations and based on its constraint to parent rigids.
For example, cylinder and piston might be completely fixed together, but those 2 should still be able to move around the platform1 refPoint, so although piston itself might have no DOF compared to cylinder, it still should not be marked as "can't move" since up the parent's chain there is still free DOF left.
kbwbe
Posts: 953
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

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

project4 wrote:
Tue Jul 24, 2018 5:10 am
Update to the algorithm:
When moving in the parent's chain to find a rigid that can't be moved, so the chain search will be stopped...
That "can't move" flag should be set after previous chain calculations and based on its constraint to parent rigids.
For example, cylinder and piston might be completely fixed together, but those 2 should still be able to move around the platform1 refPoint, so although piston itself might have no DOF compared to cylinder, it still should not be marked as "can't move" since up the parent's chain there is still free DOF left.
@project4,
@Turro75,

i think that's the way !

P.S. @Turro75, if possible we should do the DOF-calculation based on dep's refPoints + dep's Axis which are already linked to the rigids. So there is no extra calculation time used during iteration. Is that possible ?
KBWBE

https://github.com/kbwbe/A2plus
paul18
Posts: 182
Joined: Sat Jul 19, 2014 7:44 pm
Location: France

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

Hi All

I was a fan of Hamish works and I'm happy to see that the succession is assured

I started to play with the module and 2 options are missing from the previous Assembly2:
- in the python interface, the number of remaining DOF (very usefull to "help" the solver if it always equals to zero),
- the incon to aligne/oppose constraint direction

I'm reassembling some projects I did some (years) ago ... I'll share my feedbacks

Paul

PS: have you any docs on the "maths" behind such project?
Turro75
Posts: 175
Joined: Mon Aug 15, 2016 10:23 pm

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

Kbwbe

The dof are property of each rigid so the axis must be relative to the rigid's shape.
If I'm not wrong the solver uses global coordinates and placement so every time you must convert relative to global and viceversa.
kbwbe
Posts: 953
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

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

Turro75 wrote:
Tue Jul 24, 2018 7:37 am
Kbwbe

The dof are property of each rigid so the axis must be relative to the rigid's shape.
If I'm not wrong the solver uses global coordinates and placement so every time you must convert relative to global and viceversa.
Hi Turro,
the deps are always moved in same way as rigid. Therefore they are relative to the rigid.

PS. If you have for example an axisAlignment, the axis and a point is stored in the dep. If moving the rig, dep will be moved also. Therefore you know always the correct position of the axis. If there are other deps, you know the relative positions to each other.
KBWBE

https://github.com/kbwbe/A2plus