Freesteel Blog » Implicit areas in the tool surface applied to five-axis theory
Implicit areas in the tool surface applied to five-axis theory
Monday, September 9th, 2013 at 11:58 am
Following my work attempting to create five axis toolpaths using tracking methods, I’ve fallen back to the more conventional techniques used to create 3-axis toolpaths of defining areas theoretically and then computing their boundaries.
For three-axis strategies almost everything is computed on an XY weave an efficient aligned subdividing structure. When things are aligned in this way it’s possible to be totally strict with the floating point calculations about what cell contains each point, and so rely on the topological and geometric reasoning being consistent.
Here is a view of one of these weaves (where each point has a z-value) offset to the side so you can see its depth.
One of the big headaches with this model is it gets complicated on vertical walls where there are discontinuities and many contours can be on top of one another. But other than that, the mapping is one-to-one.
When you move to 5-axis theory there is no flat surface to which you can project everything.
(I spent a bit of time looking at Hugues Hoppe’s
spherical projections of arbitrary surfaces to see if I could make a mapping to the drive plane through which I could apply all those algorithms, but after some initial success I decided it wasn’t going to work in the long term as the distortions were too arbitrary to gain any benefit from algorithms which depended on consistent localizations to drive their searching strategies.)
So, I’ve settled on starting with a network of edges and facets that approximates the tool surface for a ball tip (ignoring the axis tilt) and exploring whether the algorithms can be reconstructed on this non-rectangular non-rigid structure.
One immediate advantage with a structure that follows all the twists and folds of the surface is we don’t have to have any discontinuities. This is going to represent a huge simplification.
Of course, the sum total of the complexity is constant, and we’ve basically glossed over it by starting with this tool surface structure. What’s going to happen when we run ball cutters with the same diameter as the gaps between the fins? It’s going to be a mess. The headache will come when we attempt to make these tool surfaces for arbitrary parts. I’ve basically hard-coded the solution for this particular impeller example for a single radius so I can move on and explore what I can do — assuming I have this problem solved.
And so I have found I can define implicit areas and create boundaries for them.
Here is one such example.
In this case, the condition is based on the SurfPointClosestApproachPoint() function.
Suppose the item (p, n) is a pair (point, contact_normal) in the tool surface for a ball of radius r relative to the triangulated surface S. This would imply:
If q = SurfClosestApproachPointVector(p, S), then: |p - q| = r p - q = n * r [the contact normal vector scaled by the ball radius]
In other words, for every position in the tool surface for a ball of radius r, the point of closest approach to the surface is going to be exactly the distance r away. That’s what it means for a sphere to be in contact with a surface.
Now pick an offset value e and consider whether the ball of radius (r+e) fits with the same contact point. If it does, then:
p' = p + n * e [projecting out by e] |p' - SurfClosestApproachPointVector(p', S)| = r + e
And if the sphere of radius (r+e) doesn’t fit then the distance will be smaller because you’ll be hitting something closer.
The points where the sphere doesn’t fit are marked as inside the area, and those where it fits are outside the area.
Apply this to every node, pick the halfway point on every rod/edge where there is a change from inside to outside, and connect a line across the polygons between the halfway points to get this nice wobbly outline.
Obviously the mid-point isn’t the right place to pick the boundary, so we need to do some subdivision to get to the right position. This is easy; you pick the half-way point, check if it’s inside the area by calling the function, and pick the first interval or the second interval depending on the answer, and repeat until the interval is sufficiently narrow.
Unfortunately, the mid-point on the rod between to points on the tool surface is not on the tool surface, so we need to do some projecting, like so:
That red line through the point on the p0p1 line in the direction interpolated by n0n1 carries a sphere of radius r in the direction of the surface S until it makes contact when its centre is at point p2 with the contact normal n2. This is very much like a drop cutter along a vector, except more complicated as I don’t want it to pull back all the way to the outside if there is a fold of the surface that prevents access. Luckily I found a function that did this somewhere in the code-base without having to waste time writing it. Unless you complete this computation properly without any shortcuts, the boundaries continue to be wobbly.
These are like theoretical rest area boundaries. What I want are drive curves, so I cut them at the tops and bottoms and threw away the short segments.
This is almost good — if we ignore those bulges where the splitter fin get close to the main fins and the (r+e) ball doesn’t quite fit into the gap. I imagine there could be some ingenious directional tests where we model hemispheres rather than whole spheres or something where we distort the model out of the way in the direction of the normal. We can do an endless amount of fiddling because all we need to produce is a function that returns True/False when given a (point, contact_normal) pair in the tool surface.
Now for the constant scallop case. Simply give these drive toolpaths to the function ToolpathPointClosestApproachPoint() instead of SurfPointClosestApproachPoint() and, hey presto, we have offsets to the side.
And by applying this many times (offsetting everything at once means there’s no room for new offsets between the toolpaths), we get a semi-reasonable result:
I don’t know if anyone could use it, but it’s not so bad for a first go, without any adaptive subdividing of the tool surface. It all depends on producing these True/False functions defining an implicit area, and putting it into the standard tool surface contour detecting engine.
I’ve got plans to write a new function today that measures the curvature at a point. How big a sphere fits into the space between the contact point and the rest of the surface? This might mean I can vary r across the model and more effectively get down into those channels. I think once you have a tool surface model that does fit closely to the actual shape without distortions (in the way that the XY weave model we use in 3-axis does not), defining smooth scalar fields across it becomes realistic.
We already have a smooth toolpath tilting function in beta that avoids holder collisions. Maybe we can apply it to produce a toolpath tilting function on all the points in this tool surface that’s smooth in all directions. Maybe also we can look at the shaft as a way to generate cutting engagement.
There’s a notion of applying the Adaptive Clearing algorithm to roughing in 5-axis. I’m not so sure about that, though it does look similar to swarf machining. You can repeatedly cut more and more material by tilting the tool into the material even if the tip sweeps repeatedly along the same contour. In the extreme case, imagine holding the tip stationary and spiraling out by tilting to scrape out a conical hole like you can do with a flagpole planted in the sand.
It’s hard to predict what will be useful, not having a 5-axis milling centre right here in the office to run experiments on. So my focus is to aim for variety and a flexible platform so as ideas and opportunities come together we are ready to code them up rapidly enough to test them out without losing the moment.