I’m trying to use kangaroo for some linkage simulations but I’m getting stuck. I’ve got a start but I’m trying to add a radial constraint and some sort of collision to create a piston motion. Any tips? I was thinking I could use an anchor pt but I’m not really sure how to go about that.
LinkageTest.3dm (2.3 MB)
LinkageTest.gh (8.5 KB)
Attached is a definition showing a way to simulate a piston type motion using only length constraints and anchors.
piston_linkage.gh (12.9 KB)
Also, here’s a version still using the rigid bodies:
LinkageTest2.gh (14.6 KB)
1 Like
Sir,
I’m trying to teach myself to solve multi-bar linkage problems and I’m hoping to use Kangaroo to do it but it is totally new to me. Can you direct me to the most direct path to understanding? I’m a competent Rhino user and an intermediate Grasshopper user.
Thanks in advance.
Hi Pete,
simple_4bar_linkage.gh (10.2 KB)
Here’s a basic linkage example - setting the lengths of a few lines, fixing 2 points and then dragging the points.
Is that the kind of thing you mean?
2 Likes
YES!
Thank you.
You’ll be glad to know that I managed to tinker it out for myself last night using the Rigid Body object. What I’m struggling with now is defining physical limitations for the system, such as collisions between bars.
-
How do I make objects bump into each other meaningfully?
-
I feel like I don’t understand how information flows in Kangaroo, it seems slightly different from Grasshopper somehow. Does it?
-
I also don’t quite understand how the strength works. If I’m creating a hinge, could I use strength as a kind of deflection tolerance? If so, how would that work?
-
Is there a way a way to simulate friction?
Number One is a pressing question. 2,3 & 4 are more like curiosities.
Thanks again!
Here’s one example combining a rigid body linkage with collision between the 2 bodies:
rigid_linkage_collision.gh (32.6 KB)
However…I’d actually try and avoid using full rigid body collision for this kind of thing whenever possible.
When the bodies are complex or interlocking, and multiple collisions take place between the same pair simultaneously things can get a bit jittery. I do hope to improve this over time.
…but if it is possible to replace the collision with something like a simple distance or angle constraint (using ClampLength or ClampAngle), then this is always going to be faster and more stable. In this example we know the collision will always take place along a certain axis, so it can be handled with a ClampLength goal like this:
rigid_linkage_collision2.gh (32.2 KB)
Also - to answer your other questions:
(2)
You are correct that for Kangaroo the data flow is a bit different from other Grasshopper components. Normally the components on the Grasshopper canvas form a directed acyclic graph, and changing data in one component can affect components downstream of it, but not the other way around.
However, for the type of constraint systems and physical simulations Kangaroo deals with, the relationships between objects are bi-directional and allow dependency cycles, so we do not want the user to have to specify a hierarchy between them (this is sometimes called variational modelling as opposed to the parametric modelling of regular Grasshopper).
In Grasshopper, when parameters change, such as the referenced Rhino geometry moving, or the user changing a slider value, these changes propagate downstream through the whole canvas until it is solved, and the result is displayed.
To combine these two approaches, Kangaroo essentially hides all the bi-directionality inside one solver component on the canvas, and data flows into this parametrically, interacts in a variational way, then flows out parametrically again. This component also has a timer, so it keeps recalculating, sending intermediate results downstream, until it converges.
(3)
For systems of constraints such as my 4 bar linkage example above, the strength doesn’t really matter much, since the system has a solution which satisfies all the constraints exactly. Where the strength becomes important is when the goals are inconsistent, and there is no way to simultaneously satisfy them all at once. Here Kangaroo minimizes the sum of the weighted squared errors of all the goals, and the strength is what sets that weighting.
This allows it to be used for things like simulating elastic deformation of structures under the effect of gravity, considering gravity as another goal pulling the vertices downward. So while Kangaroo can deal with constraints, it also encompasses things which aren’t really constraints in the conventional sense, which is why I chose to use the more general term goals instead.
(4)
The focus with this version of Kangaroo has been mainly on finding equilibrium solutions, for constraint solving, form-finding, or analysis applications.
The dynamic behaviour in these cases is used mainly as a means to an end (although the intermediate visual feedback it provides can be useful in understanding the behaviour of the system).
For this reason the default solver tries to converge as quickly as possible, rather than directly simulating real world energy dissipation (note that this is does not affect the eventual equilibrium solution reached, which can be realistic, even when the speed and path taken to reach it is not).
While this version of Kangaroo does now support momentum preservation (using the ‘Bouncy’ solver component), for situations where the dynamics is of interest in its own right, this side of things is still less developed than the equilibrium focused aspect. Adding some more components for friction would be fairly easy, but I think for more realistic simulation of movement speeds in dynamic simulations the bigger challenge would be reducing the amount of extra friction that most goals automatically cause, whether it is wanted or not (a side effect of the numerical methods used, which were chosen more for convergence).
For further development of this it might be useful to have some use cases in mind.
2 Likes
Hi
Does someone have any suggestion to approach the following problem ?
Thank you in advance for any help.