6dof nodes + Rigid body collisions

I've just posted on Food4Rhino Kangaroo release 2.2.1

http://www.food4rhino.com/app/kangaroo-physics

The biggest change in this release is the inclusion of 6 degree of freedom nodes.

Until now particles always had only position (3 degrees of translational freedom).

Now they can also optionally have an orientation (3 degrees of rotational freedom), which are updated by the solver at each iteration.

This makes possible new types of goals based on these orientations. The first example of this is a more robust rigid body component, and collision between pairs of rigid bodies. These can be any closed solids, and do not need to be convex.

In coming weeks I will be posting more examples of Goals which make use of the 6dof nodes, including some scripted ones.

Replies to This Discussion

Permalink Reply by Jon on February 8, 2017 at 4:19am

great! cant wait to try new Features!!

Thx Daniel!

Permalink Reply by Winsion Liang on February 8, 2017 at 10:07pm

Thanks your update , I am waiting the new examples. :(

Permalink Reply by Nick Bruscia on February 13, 2017 at 3:51pm

Thanks, Daniel - as ever!

Quick question - is the entire suite of mesh processing tools and utilities from 099 carried over, or just a portion? I've installed 221, so this is just a check to be sure things aren't missing on my machine.

Permalink Reply by Daniel Piker on February 14, 2017 at 9:55am

Hi Nick,

Not all of the utilities from the old version are carried over.

Some are redundant now, since their behaviour is easily achieved with default GH components

(duplicate points and interconnect points).

Some of the user objects I didn't convert for K2 yet. Also I haven't decided yet whether to include MeshMachine in K2 or have it as a separate gha.

Permalink Reply by Nick Bruscia on February 21, 2017 at 7:55am

Thanks Daniel, that makes sense.

One thing that I've also found to be very useful from the old version is that handy little C# component within the Shell cluster. I've copied it out to simulate bending in triangle meshes in K2. Perhaps this would be a useful utility? Just a thought.

Permalink Reply by Efilena Baseta on February 23, 2018 at 8:27am

Hello Daniel,

Thank you very much for the amazing features of the the new Kangaroo! It is great for me since I am currently doing bending simulations of beams for my PhD. I have checked your example on GitHub and I was wondering if it is possible to bend custom shaped beams (as Mesh or Brep) which can act as rigid bodies.
In your example you work with polylines, which are translated into meshes after the solver. What do you suggest as a process if I want to explore collisions between different beams? Do you have any example on that? Any example in 2D (representing the longitudinal section of a beam) of 3D (with custom shape meshes or Brep) will be very much appreciated.

Best,

Efilena

Permalink Reply by Daniel Piker on February 27, 2018 at 9:03am

Hi Efilena,

Do the examples here help? there are a few different types of collision shown:

https://github.com/Dan-Piker/Kangaroo-examples

Permalink Reply by Gerard Guell on August 21, 2018 at 8:49am

Hey Daniel,

I have a question regarding the use of the 6dof supports. For some reason, the nodes to which I'm assigning the supports act as "free nodes" and I cannot figure out why. When using anchor points, it works quite well.

If you could take a look and tell me what I'm doing wrong it would be greatly appreciate it.

Thanks in advance

try_support6dof.gh

try1.gh

Permalink Reply by Daniel Piker on August 21, 2018 at 1:17pm

Hi Gerard,

A beam element has 4 input planes - a start and an end frame, and a start and end node.

If nothing is supplied for the start/end nodes, they default to xy aligned planes with their origins at the ends of the beam.

Also setting the frames for your supports as xy aligned lets Kangaroo know the beam and the support act on the same node.

I realise this appears odd at first, but I'll try and explain why it is set up like that...

Attachments:

try_support6dof_dp.gh, 26 KB

Permalink Reply by Daniel Piker on August 21, 2018 at 2:12pm

Trying to explain more clearly -

Here's an illustration of 2 beams meeting at a node. The beams here are scaled down to show the junction more clearly, but in reality their ends would be coincident.

The frame in the wireframe cube in the middle would be the EndNode of one beam, and the StartNode of the other. Because they are the same, this would result in a fixed angle connection between these two beams.

The actual orientation of this node is arbitrary - as long as it is the same for both beams they will be joined. The orientations of the beam ends are maintained relative to this frame.

Permalink Reply by Gerard Guell on August 27, 2018 at 4:16am

Hello Daniel,

Thank you very much for the explanation. Its working perfectly now!

In that direction I have a question regarding the use of beam elements in Kangaroo2. To get mysefl familiar with it, I'm modelling a simply supported beam and applying a concentrated force in the middle of it. Then, I'm comparing the deflection given with the analytical solution.

What I've realized is that when changing the beam elements Ix, Iy, GJ parameters, barely no change in the result is made; while when the E modulus is changed, then yes we observe a difference in the results.

I have been spending sometime over the script and I have yet to find out what I'm not doing correctly.