Assembly3 preview

[saso]

This would obviously be great, but in my opinion this would much better fit as a new "kinematic" or "physics simulation" workbench. IMO this continues the wrong understanding of what an basic assembly should be...

This is an empty assembly, no geometry and no constraints (it is how one would start when doing a top down design)

asm_empty.png (13.07 KiB) Viewed 2722 times

This is an assembly with some geometry (just dumb imported solids from step) inside the parts, still no constraints

asm_and_geometry.png (29.44 KiB) Viewed 2722 times

This is similar to the one above, but this time it is with fully parametric build geometry, still nowhere no constraints (ppemawm hopefully you are ok I copied a bit from your great work )

asm_parametric_geometry.png (183.17 KiB) Viewed 2666 times

All of the above examples are what an assembly is and there are no constraints or what so ever in this (ok maybe inside the sketches ). Of course constraints or other things like kinematics can then be added on top of such assemblies.

Few days ago there was a link to the solidworks online help, here are the first two sentences from the assemblies section http://help.solidworks.com/2016/english ... _topic.htm

You can build complex assemblies consisting of many components, which can be parts or other assemblies, called subassemblies. For most operations, the behavior of components is the same for both types.

Constraints (or mates in solidworks) are explained later...

Mates create geometric relationships between assembly components...

What I want to say is that constraints don't make the assemblies. It is like if I would ask someone to build foundations for a house, instead they would build the walls and then try to convince me that walls are foundations, they are not.

And part is a container, not a geometry (ex. a solid box by itself is not a part, it is something you put inside a part container).

As I have suggested before, we should IMO first get an proper assembly container in to FreeCAD, then fix the existing part and body and then split asm3 in two workbenches, one that would work on top of assembly and part containers and one that would work directly on geometry inside the part containers (since this is sort of how it is mostly working now). In my view asm3 is currently much more like another implementation of the part container then what an assembly workbench should be.

[realthunder]

This would obviously be great, but in my opinion this would much better fit as a new "kinematic" or "physics simulation" workbench.

I intend to wrap the physics engine into a separate module. When I said I want to integrate bullet (now, maybe Chrono) into FC, I meant to add it as a C++ module. A module can expose more than one workbenches, or none, which provides non GUI service to other modules.

[saso]

This would obviously be great, but in my opinion this would much better fit as a new "kinematic" or "physics simulation" workbench.

I intend to wrap the physics engine into a separate module. When I said I want to integrate bullet (now, maybe Chrono) into FC, I meant to add it as a C++ module. A module can expose more than one workbenches, or none, which provides non GUI service to other modules.

ok, sounds great

[bill]

Remember folks, A3 is an OPTIONAL WorkBench ( i.e., A3WB).

first get an proper assembly container in to FreeCAD, then fix the existing part and body

ickbys Part/Body was the first real FC step into getting control of the Object-SubObject relationhip which is essential to an extensible ASSEMBLY model. Any Part should be considered a potential sub-assembly and posess/declare the necessary interface/control definition.

Dont forget that rt's LINK merge is probably the most crucial dependency of a PROPER Assembly Solution due to its potential to provide robustness to VeryLargeAssemblies, as opposed to those seen to date.

LINK(virtualization) is the fourth dimension in our FC, 3D, cad world.

Additionally, I see the need for multiple assemblyWBs; However, A3WB seems the most valuable and powerful for my needs.

[jpg87]

I would like to give my opinion on assemblies.


My personal experience leads me to think that there are at least two different situations according to our needs :


1- The project is a set in which all the pieces are completely connected to each other:

Solution 1:
Parts can be built into a MultiBody file of PartDesign in which they are represented in different bodies. In this case, the bodies can be drawn relative to each other using ShapeBinder.

Solution 2:
Parts can be built in separate files. In this case, an Assembly WorkBench is welcome. It allows to put in relative position the different objects in order to realize the complete product.

Note that I do not voluntarily talk about sketch positions, objects, or others, which assume numerically known the desired positions as well as the dimensions of the objects.
This is not always possible in team work or even when you use older components in a new project whose details are no longer known (also true for standard elements of component libraries).

2- The project is a mechanism in which certain parts retain the mobility necessary for their operation.

It is then composed of classes of kinematic equivalence, that is to say groups of parts completely related to each other. These groups are subsets that will be made according to solutions 1 and 2 above.

A general assembly will collect these kinematic equivalence classes and Assembly WorkBench will create the specific kinematic connections (joints) needed for the assembly to work.

This assembly can be used in simulation programs kinematic behavior or dynamic technical solutions before performing real tests on prototypes.

[fosselius]

BTW, I have looked at bullet's code these few days, and decided to integrate it to FC.

You got me, I was actually playing around with creating .urdf models from asm3 assemblies and then running them in with pybullet inside FreeCAD.

I would vote for making a "abstraction layer" for physics simulations to allow for several integrations.
chrono might be more accurate, but developers and end users might prefer ODE, Bullet, Simbody, or DART as they might give good enough results without being too demanding.

You might want to take inspiration from gazebo:
https://bitbucket.org/osrf/gazebo/src/f ... at=default
https://www.youtube.com/watch?v=2nq5P3-qgmA

[Mark Szlazak]

BTW, I have looked at bullet's code these few days, and decided to integrate it to FC.

You got me, I was actually playing around with creating .urdf models from asm3 assemblies and then running them in with pybullet inside FreeCAD.

I would vote for making a "abstraction layer" for physics simulations to allow for several integrations. You might want to look at
chrono might be more accurate, but developers and end users might prefer ODE, Bullet, Simbody, or DART as they might give good enough results without being too demanding.

You might want to take inspiration from gazebo:
https://bitbucket.org/osrf/gazebo/src/f ... at=default
https://www.youtube.com/watch?v=2nq5P3-qgmA

Best of both worlds.

If one is a mechanical watch maker or someone like me which just has an interest then accurate physics modelling is a must. Especially with advances in this centuries old craft that are being made with micro-3d-printing in silicon.

An example is here https://monochrome-watches.com/zenith-d ... deo-price/.

Very high end, luxury mechanical watch makers like Patek Philippe, Audemars Piguet, Vacheron Constantin, Jaeger-LeCoultre, A. Lange & Söhne and Girard-Perregaux, are all using 3d-printing in silicon and the simulations are with advance physical/mechanical models.

[realthunder]

I would vote for making a "abstraction layer" for physics simulations to allow for several integrations.
chrono might be more accurate, but developers and end users might prefer ODE, Bullet, Simbody, or DART as they might give good enough results without being too demanding.

Yeah, this seems just come in time. It's being used in the next release of gazebo.

[fosselius]

I thought they already had an "abstraction layer", but what they have is a common "interface" that gets implemented for each physics engine, in my world that is an abstraction layer

so you got the common:
physics/joint.[cc/hh]
then you got the actual solver implementations
physics/simbody/Simbodyjoint.[cc/hh]
physics/ODE/ODEjoint.[cc/hh]
physics/bullet/bulletjoint.[cc/hh]
.. etc

then you register your physics engine in the physicsFactory
https://bitbucket.org/osrf/gazebo/src/f ... ew-default

from your link:
"The current approach requires physics engines to be present when gazebo is configured, prior to compilation. The abstraction layer also requires many derived classes and files to be created in order to reach a minimal level of functionality. Ignition Physics is a redesign of the physics abstraction layer to remove these limitations." sounds like its focused on having physics engines as run-time plugins, that is neat but overkill?

Btw here is the library they refer to:
https://ignitionrobotics.org/libs/physics
https://bitbucket.org/ignitionrobotics/ign-physics

But if you could work with ign-physics* that would be great especially if its less work for you and you might actually contribute something to both FreeCAD and Gazebo.
* is under active development (git repo created july 17, last commit 8h ago), v 0.1 released
Here is the joint types supported by Gazebo:

4032427536-demo_joint_types_2.gif (426.01 KiB) Viewed 2477 times

[realthunder]

New buf fix version released.