# Getting a shape to be automatically positioned to be inside the donut

I think I understand what you are doing better than you understand what I’m doing. (for free!)

Due to the way SDivide works, the ‘UV Count’ slider must be an even number to get positions through the center of the donut. There is now a yellow point at the center of the donut. You can enable preview on the yellow group to see the grid of possible positions. I added the list of parts you posted with a slider to choose one at a time.

donut_collision_2024Feb6c.gh (433.0 KB)

your question was about positioning the object(s) inside the donut and now you want to move the donut? What are you referring to? In the example, the donut was moved to the smaller shape.

1 Like

1000 %

2 Likes

Using the new test geometry (parts), I realized that parts in the center of the donut are not inside the brep so changed that - correct? Still not clear about how a robot will be controlled by this?

donut_collision_2024Feb6d.gh (428.7 KB)

I’ll try my best to explain again.

Consider this as the shapes that they will be printed in reality the distances between them the size and everything.

Now these shapes have different heights from the ground, so I have to preserve the relative position of the donut and the part, i can’t just use the “volume component” because it will mess up the position from the start.

From the bottom of the donut to the very start of the print on the floor is a specific height already set in the model sent.

___________________________________________________________________________-

Third one, the positions of the multiple donuts must have their final position like this indicated with blue color, the distance between each donut has to be precise for final export. Whatever the algorithm gives me in the end that’s what will be exported. in order to draw the position on te floor in the real world.

And the shapes must never move from their initial position in space, only the donuts.

What i did before was. Every time I do this I manually position the donuts to their respective positions in space and I export the 6 donuts in a 3d file for AR headset or 2d printing on a large format like a CAD drawing which then I manually draw the donut positions by hand on the floor (technically I draw the legs of the robot on the floor).
The parts are then printed one by one in their positions in real-world conditions.

I apologize for any confusion. I thank you all for this amazing help.

position of the parts.gh (1.9 MB)

I dropped volume centers several versions ago, please try to keep up.

I have not changed my GH file to move the donut. That might be difficult (but not impossible!). More importantly, I can obtain all the information you need to move the robot - now, without any changes. I can produce vectors from an arbitrary “robot home” position to each of the parts and / or from part to part, precisely. And I can produce vectors from the donut center to each of the part positions that pass the collision test (take your pick). Combined, that should be enough to direct the robot.

I’ll follow up with code later and look at your GH file. But if we keep talking past each other, this will be a waste of time - like so many other forum contributions I’ve made for people who don’t understand GH.

Yes i know i just wanted to mention it again for clarity, I’m a beginner in GH so please bear with me
And i thank you for being patient with me and for helping.

Could @René_Corella gh be modified for the donut to be moved to the part? especially with the Z axis being locked the second video but in this case, the height of the respective part has not been preserved.

Exactly that should not be changed you already implemented that

Wouldn’t it be easier to move the donut instead, in both cases? and I could just select each part manually in their respective position in space.

I think this is more of a 2D problem than a 3D one… you just need to get some info about the 3rd dimension, but then it can be solved in 2D?

knowing the 3D reach “donut” of the robot arm is useful: I guess you are going to print mainly perfectly vertical sections in various shapes, most of them defined as a vertical (Z) extrusion of a 2D shape

at the same time, I guess the robot arm is going to be raised from the ground by a solid base, raised up to a certain height, and you are printing on a plane that is parallel to the one the robot lies on

so, in order to have the whole part to stay inside the robot’s reach, you need to check the base and the top of the part are inside the robot’s reach
the fastest way is just to draw a plane and find the intersections:

at the same time: it cannot happen that the base is inside the reach but the top is not, as well as it cannot happen the top is inside the reach but the bottom is not

so the real placement area is the intersection (common/shared area) of the top reach and the bottom reach at those heights (green part):

at this point, the problem is how many ways you can put the this planar green ring in such a way it contains the planar C-shape, which looks like many, but it’s not that many… probably a bit less than A times B many:

minkowski sum is your best friend here, in such a way to avoid brute forcing random movements and checking for collisions, but again I drank enough gin tonics to get myself into troubles but not out, so…

[edit: definitely minkowskiable with Clipper2]

1 Like

My solution for this problem in version ‘Feb6d’ was a mistake because U-shaped parts have their “center” positions outside the donut, even when the shapes are completely inside without collision. I reverted to earlier code (purple group) and don’t have a solution yet for culling small parts that use these central positions outside the donut…

on a side note (sorry for not editing, but saw someone else was replying so I didn’t want to clunk the thread) a maybe more interesting questino might be:

what height should my robot arm be (Z) in such a way to give me the highest degree of (X, Y) freedom of positioning?

and that depends mostly on the height of the thing you want to 3D-print:

the main problem is still on the basis of the above post, the only difference is that you want to maximize the projected “intersection area” of the top and bottom sections along those planes (long story short, get the max green area from the previous post)

this will allow you not only to create a 2D top view where the robot could be placed, but to even create a 3D volumes inside of which the center of the robot could be placed
the more freedom you are able to extract from this, the more options you end up with, the most effective combinations of many robot arms working together you might have

I work with KUKAs, and I hear them crying when they are working in some weird positions

1 Like

I understand completely and this could work but also I’m planning ahead to use multiple robots so it would be good to see the paths if they intersect in 3d space, it would be easier to also plan it and see ahead of time and which part could be printed first and which ones last

I like the solution btw but also these parts have varying shapes sometimes they’re bulky in the midsection and I’m afraid just a projection would not be sufficient in those cases.

i just wana find an easier solution where the donut moves to the part. Z axis preserved, no rotation whatsoever and maintain the parts real world position

I like the kangaroo solution but the problem is i cant get it to lock their position and without using the volume component the part moves in z axis and thats the problem. i wana be able to make that te donut moves to the part and not the other way around. I wana marry @Joseph_Oster solution with @René_Corella kangaroo and do the opposite where the donut moves to the part.

Im trying to incorporate @Joseph_Oster height preservation of the part and the donuts with kanagaroo but cant get it work for the life of me. Moving the donut seems to be a harder task. That would make it easier for me to just select parts and move the donut no headaches after in trying to calculate each individual part and their relative positions.

I have not come back to the computer. Nonetheless, the volume component was used just to grab the {bounding box} centroids of both shapes, and establish a vector from one point to the other, then move the part to the donut, but this translation can be reversed so the donut moves to the part. No biggie.

I have worked out all the code issues without moving the donut, except for display purposes.
The last issue to be resolved is one of the first issues discussed: how to choose between multiple solutions for each part?

TBC (To Be Continued), good night.

Ive been trying to do just that but for me doesnt work when i change that the donit seems to be getting inside the part!

Note: The donut centroid and the part centroid are not on the same z level! Therefore just using volume component doesnt work because the robot position in z axis changes then.

So how could the part and donut initial position in space be preserved before making the donut move to the part?

The parts position has to be static in space as provided in the gh/3dm script/file.

I could just dispatch all the solution to singular ones and just pick one of them for each part. I dont need at that point an algorythm to chose the best solution as long as the donut encapsulates the part completely then it shoudl be fine.

I made an executive decision and picked ‘`round(list length / 2) - 1`’.

UPDATED: See donut_collision_2024Feb7a.gh below:

I’m a bit lost now, but I can edit my previous file. Are these (both the parts and the donuts) in their assigned positions already?

Your file shows 6 donuts (lol) and 6 shapes (already) inside of the donuts. Are their positions supposed to change again?

I just put the doghnuts for reference and where theyre suposed to be roughly speaking

But the parts should remain static and not changed at all especially their position relative to each other part
The donut should move though and encapsulate the parts

1 Like

Are you talking about the height (z)? If you move the donut then its position will have changed, even if height gets preserved.

Ok so the parts are where they are supposed to be, then the donut ‘moves to them’ without losing its position in Z? And then you collide the shapes inside?