Another approach to assembly solver (A2plus)

Discussion about the development of the Assembly workbench.
Jee-Bee
Posts: 2011
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Another approach to assembly solver (A2plus)

Postby Jee-Bee » Fri Aug 10, 2018 2:27 pm

for python 3 all print commands should be print()
kbwbe
Posts: 949
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

Re: Another approach to assembly solver (A2plus)

Postby kbwbe » Fri Aug 10, 2018 3:55 pm

Jee-Bee wrote:
Fri Aug 10, 2018 2:27 pm
for python 3 all print commands should be print()
@Jeee-Bee,
that's clear. I know the differences between python 2/3

@Turro75,
Hi Turro, my state: I am refactoring your code so that it gets a bit more clear to me...
KBWBE

https://github.com/kbwbe/A2plus
latest release: v0.4.47, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
User avatar
wandererfan
Posts: 3849
Joined: Tue Nov 06, 2012 5:42 pm

Re: Another approach to assembly solver (A2plus)

Postby wandererfan » Fri Aug 10, 2018 4:54 pm

Still getting up to speed, so this may be obvious, but why is Visibility the criteria for taking objects from the import file? Doesn't this cause problems (especially with PD Bodies, but also things like Cut where we don't want the Base and Tool)?

I would have thought we would do something like:

Code: Select all

searchForShapes(objects)
   for x in objects:
      if x is App::Part
         partList = searchForShapes(x.Group)
         outList.extend(partList)
      if x is Body:
         add to Body.Shape.copy() to outList
     if x is Part::Feature
        if x.InList does not contain a  Part::Feature   #want Cut, but not Base or Tool
           add x.Shape.copy() to outList
      return outList
kbwbe
Posts: 949
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

Re: Another approach to assembly solver (A2plus)

Postby kbwbe » Fri Aug 10, 2018 5:30 pm

wandererfan wrote:
Fri Aug 10, 2018 4:54 pm
Still getting up to speed, so this may be obvious, but why is Visibility the criteria for taking objects from the import file? Doesn't this cause problems (especially with PD Bodies, but also things like Cut where we don't want the Base and Tool)?

I would have thought we would do something like:

Code: Select all

searchForShapes(objects)
   for x in objects:
      if x is App::Part
         partList = searchForShapes(x.Group)
         outList.extend(partList)
      if x is Body:
         add to Body.Shape.copy() to outList
     if x is Part::Feature
        if x.InList does not contain a  Part::Feature   #want Cut, but not Base or Tool
           add x.Shape.copy() to outList
      return outList
Hi wandererfan,
criteria "visibility" was taken from Hamish's work. It is not correctly working with PDN parts in any case. So if your code delivers the true shape of all contained objects, this would be ok. Perhaps we need the criteria "visibility" in an additional mode. Sometimes user makes a part invisible in a subassembly which he want to import to a main assembly and he does not want to see it there.
KBWBE

https://github.com/kbwbe/A2plus
latest release: v0.4.47, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
Turro75
Posts: 175
Joined: Mon Aug 15, 2016 10:23 pm

Re: Another approach to assembly solver (A2plus)

Postby Turro75 » Fri Aug 10, 2018 5:56 pm

kbwbe wrote:
Fri Aug 10, 2018 3:55 pm


@Turro75,
Hi Turro, my state: I am refactoring your code so that it gets a bit more clear to me...
Do You mean it was enough rewriting getcandidates?
kbwbe
Posts: 949
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

Re: Another approach to assembly solver (A2plus)

Postby kbwbe » Fri Aug 10, 2018 9:48 pm

Turro75 wrote:
Fri Aug 10, 2018 5:56 pm
kbwbe wrote:
Fri Aug 10, 2018 3:55 pm


@Turro75,
Hi Turro, my state: I am refactoring your code so that it gets a bit more clear to me...
Do You mean it was enough rewriting getcandidates?
Hi Turro,
i fear that this will not be enough. Also tempfixing has to be done at correct points. There will be sure more modifications. My goal is to keep the clean structure of project4's code alive and implement your DOF methods. With doing refactoring of your code, i will learn how it works. But i will need a little bit time..

P.S.: @Turro75, just saw your fork and patches on github. :D . I will check !
KBWBE

https://github.com/kbwbe/A2plus
latest release: v0.4.47, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
kbwbe
Posts: 949
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

Re: Another approach to assembly solver (A2plus)

Postby kbwbe » Fri Aug 10, 2018 11:02 pm

@Turro75,
i merged both of your pull requests /Edit/ to branch "turro-dof-1", so we have again same basis of code.

I attached again same test assembly "assembly-bigplate.fcstd".
There are some errors:
First hit "solve"-button: 2'nd plate moves to 1'rst plate, 3rd plate moves to strange position
Second hit "solve"-button: 3rd plate moves to nearly correct position to 2'nd plate, but positioning error is much bigger than normal.

So we have more than one bug.
- it's necessary to hit button "solve" multiple.. (i think i cannot be a complicated bug to find)
- Iteration stops without reaching required accuracy.. (seems to be related to manuels tests with wrong positioning)

Perhaps you have an idea, what's wrong.

At first i will continue cleaning up the code. It is always good to do this in order to find bugs. 8-)
Attachments
assembly-bigplate.fcstd
(14.83 KiB) Downloaded 6 times
KBWBE

https://github.com/kbwbe/A2plus
latest release: v0.4.47, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
kbwbe
Posts: 949
Joined: Tue Apr 10, 2018 3:12 pm
Location: Germany, near Köln (Cologne)

Re: Another approach to assembly solver (A2plus)

Postby kbwbe » Fri Aug 10, 2018 11:31 pm

wandererfan wrote:
Fri Aug 10, 2018 4:54 pm
Hi @wandererfan,

as Turro and me are working on files which do no affect importing files to A2Plus, this is a good point to do a PR against devel branch regarding "a2p_importpart.py". Let's try out your ideas ! ;)
KBWBE

https://github.com/kbwbe/A2plus
latest release: v0.4.47, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
Turro75
Posts: 175
Joined: Mon Aug 15, 2016 10:23 pm

Re: Another approach to assembly solver (A2plus)

Postby Turro75 » Sat Aug 11, 2018 8:18 am

kbwbe wrote:
Fri Aug 10, 2018 11:02 pm
@Turro75,
i merged both of your pull requests /Edit/ to branch "turro-dof-1", so we have again same basis of code.

I attached again same test assembly "assembly-bigplate.fcstd".
There are some errors:
First hit "solve"-button: 2'nd plate moves to 1'rst plate, 3rd plate moves to strange position
Second hit "solve"-button: 3rd plate moves to nearly correct position to 2'nd plate, but positioning error is much bigger than normal.

So we have more than one bug.
- it's necessary to hit button "solve" multiple.. (i think i cannot be a complicated bug to find)
- Iteration stops without reaching required accuracy.. (seems to be related to manuels tests with wrong positioning)

Perhaps you have an idea, what's wrong.

At first i will continue cleaning up the code. It is always good to do this in order to find bugs. 8-)
during 1st hitting of solve button, the 3rd plate moves exactly to match its mate to 2nd plate, the problem is that this mate is calculated by using placement set at the time of button press not the updated one. this is why I'm thinking recreate self.rigids after every solutiontoparts call.

the placement wrong...I don't know atm, may be accuracy applied to separate solving play a role on this. We have to investigate.
may be a final stage "all together" could help on this.
User avatar
manuelkrause
Posts: 442
Joined: Thu Jul 05, 2018 7:16 pm

Re: Another approach to assembly solver (A2plus)

Postby manuelkrause » Sat Aug 11, 2018 10:57 am

Short feedback regarding the code from last night (branch turro-dof-1 plus patches):
* calculation of DOF is correct now (meaning my previously reported error is fixed)
* in partial processing the rotational accuracy is bad (as I and @kbwbe already said)
* as last step manually switching to "alltogether/magnetic" and then pressing "solve" on the unchanged assembly fixes the rotational inaccuracy (visibly), that's what @Turro75 suggested in his last posting

Regards,
Manuel