Kuka & English wheel paths from doubly curved surface:

Backstory:
Way back in 2017, the R&D team (Elena Vazquez and James Coleman) at Zahner used a Kuka and an English wheel to develop a doubly curved surface. In short, they used grasshopper and kangaroo to extract the points and their direction from a surface, and then convert them to a 2d path for a Kuka and English wheel to follow. The results were beautiful.

In 2018 two researchers, Gabriella Rossi and Paul Nicholas pushed this even further. They basically added a Kinect, a network and AI so that the Kuka could learn and develop over time. Simply put. The results were, of course, more accurate. In theory, the more the Kuka wheels, the more accurate the results.

I’d like to test this theory and see how accurate we can really get using the point cloud/feedback loop setup.

Research:

https://www.researchgate.net/publication/325810118_Modelling_a_Complex_Fabrication_System_New_design_tools_for_doubly_curved_metal_surfaces_fabricated_using_the_English_Wheel!

I’ve attached an image from Zahner of what I’m trying to accomplish 1st.

Goal:
Of course, I’m not asking for someone to make anything but I would appreciate it if someone could point me in the right direction. Essentially, I’m trying to take a doubly curved surface, subdivide and extract the points, find their direction and translate that to a 2d path for which to follow.

I’m familiar with grasshopper but obviously not an expert.

For this project, accuracy is more important than saving time and cutting corners.

Thanks!

Double Curve to 2D Path.gh (4.4 KB)

1 Like

Double Curve to 2D Path.3dm (74.4 KB) Double Curve to 2D Path.gh (4.4 KB)

Ok, so basically you want to verify the research written on the paper you referenced ? Are you sure you want to do that? I am asking this because by the looks of your post, you are working alone, ( at CITA perhaps?) and there is a lot of technical details to be considered. And these guys probably spent a long time doing what they proofed in the paper. In my own opinion, I also think that this obsession of spending so much time and using computation to just think on how to create doubly curved geometry in a more efficient way for architectural buildings is not so interesting, solves any meaningful problem or is really contributing something relevant.

Anyways, an important task for your purposes is to define an algorithm to create a path. In the pdf, they did not incorporate a particle spring strategy in to the method while in Zahner they did. As a start, I would choose not to rely on the Zahner method just as the pdf argued. It Makes sense that the tool path changes over time while the sheet is changing its geometry ( this means Kangaroo would not be allowed then, hence another big question : how to add material behavior in the equation? )

So defining the path is going to be a sorting problem. Given a set of unordered points, order the set within a given criteria. Defining that criteria is key, as well as the sorting algorithm. If you will have high res scanning ( many points) you will want to try to avoid N^2 complexity time, I.e comparing each point with each other point because that will be very time consuming.

It’s also curious that in the paper you referenced, they didint really go in to the details of explaining the tool path algorithm. Its talked about as some kind of “black box” in the paper.

Try to post your first approach, to creating the path and probably more people will jump in.

Also, try to consider if you really want to proof how accurate the conclusions were in the paper you referenced (:slight_smile:

1 Like

Hello Nicholas,

Thank you for taking the time. We’re actually a multidisciplinary team of 25. I’m just the messenger.

Why we want to continue the research is for our own fabrication sake of making doubly curved surface without the multipoint stretching technique. We could of course send off our sheets to a factory to get pressed but that defeats the purpose.

I’ll get to work on some grasshopper defs and post them here. We’re trying to push the accuracy of the doubly curved surface using point cloud etc. This research will also compound into something we could use for some other design, concept, analysis etc. I just feel that the research isn’t finished for the Kuka and doubly curved surface just yet.

But I appreciate your input!

Thanks.

Is research ever really finished? :slight_smile:

Variation in material properties and sheet production tolerances (thickness) make this a very tricky problem. Hopefully you have a material scientist on your team?

Happy to help advise where I can - in the meantime go visit some autobody shops, wheeling is an art!

1 Like

If the right most pic related with the desired path is the goal, then this is easily achieved via code (C# in my case).

1 Like

Are you the Jcoleman from the Zahner R&D?! Amazing!

The material is going to be tricky. Though ambient temp and many other factors play into how a material acts, we’d like to start creating a database for this. At x thickness, x material will act as x. It’s more complicated than that but of course, we must start somewhere.

We have a molecular engineer and a relationship with a material scientist. We also have an excellent group of metal fab experts but the wheel will still be a challenge.

We could use a little more info on how to get to the “predicted tracking path”. I seem to be missing a step.

Thanks for the response Jcoleman!

You have my attention, Pete. The predicted path is the goal. In theory, we’d keep developing the path based on the material and results of course. I’m decent at c# scripting but I’m no expert. What would you suggest?

Thanks, Pete.

Well … since R SDK provides access to everything you need (on an abstract basis, i.e. if we forget materials) the classic way to start your analysis is to get a collection/grid of U/V points and make a kind of custom “info” class by including “properties” (say Osc R, Gaussian/Mean curvatures or something else). Then having the custom List items you filter (say: Where(x=>x.GetThisOrThat(searchRange))), sort (say: OrberBy(x=>x.OscR)), manage what happens in case of symmetrical topologies and get your U/V points in order … and your path (Karma is a must, mind). What this may serve without the material part of the story … well … you tell me. In theory … what’s MIA is a ThenBy(x=>x.MagicMaterialFactor) thingy.

Anyway … see some snapshots with regard Osc Circles and curvature analysis on Surfaces (but you should deal this the proper way: use BrepFaces instead and check for inclusion):


BTW: Such an “info” class could be:

2 Likes

Peter,

Oh I see. This is very helpful. I need to do some more research on c# to get my grasshopper def to this level. But this makes a lot of sense and I appreciate it!

PS: Don’t forget (a) to use nullable types (case BrepFaces) and (b) to remap your filtering values (say: Osc radii etc etc) if you want some visual indication upon what’s going on … otherwise you’ll get some big things in your screen (Plan B: get a way bigger screen, he he). You’ll need a proper remap policy as well in case that you want to work with Lists of BrepFaces (don’t put all your apples in the same bag).

May the Force (the dark option) be with you (and the LINQ part of the story).

On the other hand … well … maybe you’ll need more than The Force: Imagine attempting to do this piece of @%$@ without taking into account the material involved.

1 Like

That’s exactly what I need! How did you do that so fast!? There’s a way to do this without c# but c# seems more organized and better in the long run.

I have 50++K C# scripts … so the fast part is related with how fast I type some search stuff in some custom RDBMS that controls the chaos. Very rarely I write new things these days (I’m a bit bored with all that ^%!^%!^).

BTW: this is a general strategy that I would recommend: use/test various queries (Karma a must, mind) in order to get the Holly Grail: if not … abandon ship light a proper cigar and go ride some proper Ducati.

1 Like

It’s not looking good…I can’t extract the direction!


Double Curve to Path.gh (5.2 KB) Double Curve Test.3dm (168.1 KB)

The C# is kicking my a%$. I might be lighting that cigar soon.

Peter,

I believe I found a few of your old defs. A lot of it seems similar to your screenshots.

I’ve been trying for hours but I can’t figure out what’s wrong. My focus is on the “Osculating Curvature” and the “BrepFace Curvatures”. Both are fighting me. I just know I’m missing something.

If you or someone could take a look at my files I would greatly appreciate it!

Double Curve Test.3dm (256.8 KB) Brep_Osculating Curvatures.gh (21.0 KB) BrepFace_Curvatures.gh (12.4 KB)

Thanks!

You are lucky: is Sunday (meaning Ducati time) but the #@#@ thing don’t start (is a genuine made in Italy product meaning #@#@ electrics/electronics/build quality/pieces falling around the place/etc). What does parent company Audi on that matter? You tell me.

I’ll look on your stuff ASAP (but have the cigar ready: better safe than sorry).

Update (I don’t work wiith R6 so used an other test BrepFace):

BrepFace_curvatures: I can’t find anything wrong with the thing. To prove the point I’ve added a nullable Point2d Tree (for the U/V coords) and tested my output VS the GH component output (obviously match … since David reports what Rhino has to say).

Maybe you need some other result of some sort? Or some other visual thinky? Or some other cigar? (Note: avoid at any cost non Cuban stuff).

BrepFace_Curvatures_testedByTheLord_V1.gh (151.0 KB)

The other thing: Well … see above. But I must add a thing or two: (a) accepting BrepFaces AND (b) remap what you see (radii, that is) since as it is … well … you need a big screen (but that is not written having visual results in mind). On the other hand I guess that you are after the Math.Min(OscRU, OscRV) value per U/V pt … meaning some simplification is (maybe) required (and some different properties in the InfoUV Class, not to mention the unfortunate terminology).

Surface_OsculatingCurvatures_V2.gh (154.5 KB)

PS: A class is defined that way (but I changed some stuff [u,v as integers? what kind of idiot did that?, he he] - see inside C#):

That said, I have no idea why the crap C# build-in editor does this:

Yikes: Forgot to attach the following as well. A modified OscR thinky: BrepFaces, adios Circles, hello TextDots, new simpler(?) logic(?), new class def. If for a given pt the Gaussian curvature is < doc tol the pt is skipped (change the tol if you want) and the item in the Osc radii Tree is “Flat” (LOL). If the pt is not contained in a given BrepFace the item is “N/A”.

This def is exactly like Windows10: 99% of the things are faulty/useless things … but the next update could resolve all that.

Finish it (with queries an/or with a recursion for further refining spots etc etc):

BrepFace_OscCurvatures_testedByTheLord_V1.gh (164.8 KB)

Moral: life sucks.

1 Like

Peter

First, what do you think of the Panigale V4 R…Death machine?

Second, thank you so much for your help!
The “Surface_OsculatingCurvatures_V2” works beautifully. It’s exactly what I need. Both the “BrepFace” defs won’t work with my surface. See attached. If I understand correctly its because “for a given pt the Gaussian curvature is < doc tol the pt is skipped”. Is that correct? If so what is this “tol” you speak of?
I’ve also attached my R5 version of the surface.

Again I appreciate the help. You’ve saved me weeks of stress.


Double Curve Test (Rhino 5).3dm (227.8 KB)

Hmm … your stuff is kinda a Harley Davidson: a piece of @#@#@ that is,

But if you do a proper Surface the C# works as intended (NOTE: these things they DON’T check your input … meaning garbage in garbage out etc etc):

Included the new thing (a bit bigger for making company to the other test stuff).

BrepFace_OscCurvatures_testedByTheLord_V1A.gh (188.5 KB)

BTW: tol means this:

public static double tol = RhinoDoc.ActiveDoc.ModelAbsoluteTolerance;

And here’s where the massacre happens:

On serious matters:

The V4R is NOT a death machine provided that you know what are you doing. BUT … is an overkill and VERY unreliable as well. Avoid at any cost unless your father in law pays for the thing. I have the V4S (but the Ohlins reactive things are rather pointless and unreliable as well). In fact the best Ducati ever is my 998S … but that is another story. Obviously the worst is that pig ugly 999.

If you want the real deal get the baby Pani (the V2 model year 2020). All the stuff that you can manage at half the V4R price. If you can live with the ugly side exhausts of the previous Pani V2 … well … get the thing (they are still available out there) and spend the difference wisely.

BTW: IF you input (as Brep) a thingy that you believe that is a BrepFace … but is not (i.e. has more than one Face) the C# aborts (for good reason). I should inform the user explicitly mind (Adios may mean various things).

Maybe I should provide 2 viz options: the TextDots or these @#@#@ circles as well (remapped).

Lol guilty. I did once upon a time have a Harley. And she leaked oil like a mother.

When you say a “proper surface” what do you mean? I tried the deconstruct brep but never got an error.

For the BrepFace Curvature direction is that also why it isn’t working? Because it’s not a proper surface?

Fortunately, our family doesn’t come from money. So we know better than to buy a $40k bike lol. And I’m not a fan of the Pani V2 exhaust either. Still a beautiful bike though. You may not be a cafe racer type but what do you think of the ARCH Method 143?