Freesteel Blog » Machining
Thursday, October 9th, 2014 at 3:43 pm - Machining
I’m casting around for some little long term geometric projects which I could be good at. I’m very bad at the sysops stuff and compilers (which seems to be a breeze for every other hacker in the world). Plotting the geometry which you have calculated is also a drag.
For me, twistcodewiki does it all.
I followed the instructions to compile OpenVoronoi on this very small under-powered linux netbook I have kicking around, and got twistcodewiki to work. Here is me entering a polygon and plotting a voronoi structure from it:
The code is as follows:
Doesn’t matter in the long term. I am still absolutely certain that this will be a consumer product, like a TV or a microwave oven. Every house will have one.
I think I am coming down with my winter cold. Lethargy and crawly skin. The train journey from London was a lot tougher than it should have been. I am now back on my old pre-Autodesk laptop. There was a bit of panick getting the Webgl drivers to work so I could run my essential twistcodewiki system. Then I chatted with Mr. Heeks of HeeksCNC and made an inspection of the state of the art in the Open Source CNC world. It’s waiting for the time when geeks own their own machine tools so they are not only in the hands of professional engineers who don’t like to program.
The whole HeeksCAD UI is in C++ wxWidgets and too complicated for me to compile (especially as I’ve uninstalled the compilers), but it works by writing out a short Python program that it runs in a separate executable which links against area_funcs, libarea and nc (for the post-processor) in ways that rely on the global namespace (ahem).
Anyways, I’ve just managed to get it to operate in my WebGL system, so the point is proven. Don’t know where it leads, but one of the intentions is to get a computer system that drives a machine tool directly in a tight feedback loop in a similar manner that it would drive a car — ie not by generating all the motions of the steering wheel off-line and simply replaying them from a file. That would be some innovation that I cannot ever see happening in the real world, because the idea is not an incremental change strictly limited to one of the hardened silos in which this field of engineering is strictly divided.
Other projects not touched on yet are my laser scanning software (I’ve lost my sample files), the undemocracy scraper, tunnelx cave surveyor, triangle machine tool kickstarter, and some android phone apps.
This CEO of Autodesk has taken everything I’ve made in the field of machine tool software in return for some stock options that I cannot cash and a crushing of my spirit. Nevermind the price; I need to get out before I lose my mind.
This is the time to create negative publicity for myself. The teflon was scraped off years ago. Burning your bridges is alive in the hackspace.
Is it inevitable that any large hierarchical organization will deteriorate into a pool of grease and bureaucracy around one exquisite bubble containing the CEO?
Since he possesses the sole discretionary power of patronage and the gift of money, the sapiens do gather round and stare as if at camp fire. No one is permitted to spit.
The first thing that happened when I became CEO was I got much funnier and smarter… I would say there’s a part of it that you can resist and resist and resist, but there is a part of it where there’s a whole organization or a world around you that looks out for you in a weird way.
Still, it must be tough at the top of a creaking ten billion dollar thirty year old software corporation, raking in the multi-millions of dollars that awarded during this post-financial crisis corporate CEO pay bubble era.
Meanwhile, paradigm-shifting software products are popping up left and right out of nowhere within miles of your downtown San Francisco offices, and nothing happens on your patch. The magic has gone. You can pay over the odds for any tech start-up you like, but you’re not fooling anyone. It’s simply retail therapy.
I have a US passport because my dad is American. I’ve never lived or worked there in my adult life, because I am British, so I didn’t know you had to pay tax on everything, because the Internal Revenue Service does not believe there is such a thing as not belonging to America. They’re an empire. Everywhere else in the world is foreign, so you have to send your money back to the homeland — even if it’s not your home.
If you are a U.S. citizen or resident alien, the rules for filing income, estate, and gift tax returns and paying estimated tax are generally the same whether you are in the United States or abroad. Your worldwide income is subject to U.S. income tax, regardless of where you reside. [source]
Lot’s of stay-down linking work going on. Sometimes I worry it’ll never work. While Becka has been caving, I’ve been working through the weekends in the empty bedrooms of Bull Pot Farm, (occasionally interrupted by horrible hangovers).
Here’s the checkin changes of a beast of a file.
It’s like building a dry stone wall: I can’t remember any of what I’ve done; I only know what move is next. It’s an incremental procedure. New problem cases crop up, and you go away, have a cup of tea and come up with a solution, and keep repeating in the hope you don’t run out of ideas before it gets fixed.
The basic steps of the algorithm are as follows:
It rains and rains and just won’t stop. It’s also gotten pretty cold and I’m having to wear all my clothes that aren’t damp from lying in the tent. The last day of warm sunshine was six days ago where I stood on takeoff for 2 hours as paragliders wafted past and went down in the totally dead air of that day.
See the smile? I want more flying. Some canyoning would be good too, but it ain’t going to happen on this trip.
When I finally took off I flew in a direct straight line across the valley beyond the highway and golf course, and then had to walk 5 miles back via an ice cream stand to Base Camp for a lift back up the hill, after which I drove down, fetched my glider, and drove back up again for the walk up to Top Camp (the Stone Bridge).
Here’s the outside view of Top Camp:
And this is the inside:
It’s both a rock and a hard place with nothing in between, but it is still better than tents because it is larger, cavernous, and not like a box of damp fabric that progressively rots things as each day passes.
I dropped into the far end of Tunnockshacht down to the new connection to Arctic Angle. Becka was away with the Austrians on a different expedition and couldn’t warn me that it was going to be an unutterably deep one. That wasn’t the problem. The problem was getting terrifyingly stuck in a U-bend crawl while weaseling around the C-leads waiting for the guy with the drill to rig a rope traverse along a ledge of an undescended shaft to access the phreatic continuation. Then we surveyed about 100m until it crapped out, and hauled ourselves back out by 2am.
I forgot to take any pics, so here’s a photo of a nosy horse’s nose:
On Tuesday I went to the newly discovered Balconyhohle. (The horizontal entrance is from a ledge within the side of a hole.) I was cold and had to keep eating. We killed a couple of going leads there too, but there’s enough unexplored ways on to keep this one spreading further underground. This has been the big find of the expedition. It’s a lot of work to keep up with the mapping.
Here’s a picture from the walk back to the carpark from Top Camp in the morning:
Since then I’ve been working on the Adaptive Clearing stay-down linking killing the bugs one at a time while all my HSMWorks buddies have been at a big planning meeting in Copenhagen this week. It seems like an endless grind. Anyway, I don’t plan to go there again, and the ferry between the UK and Denmark is being terminated this September.
One of the things that crashes the system is when the A-star linking can’t find a way to connect from point A to point B, and spreads out through every single cell in the dense weave until it runs out of memory.
One obvious solution is to generate a weave that has a wider cell spacing and solve the routing issue in it, but this is too complicated. I worked out another way, which is to deny it access to most of the interior cells of the fine weave that are nowhere near the boundary or on the theoretical direct line route. The A-star algorithm is so powerful that it will find a way round, even though the domain would look so much more complicated. This initial result becomes the starting solution for the linking path, on which the PullChainTight() function is called. This is actually a bad name for it. It should be called RepeatedlySpliceStraighterSectionsIn(), but this discription wouldn’t remotely be so compelling to the imagination.
This will get implemented only if absolutely necessary. The thing about the linking routine is that it does not need to work 100% of the time, because it can always fall back to the old way of retract linking, which is what everybody puts up with right now, so it might not be worth expending too much effort for the last 2% of awkward cases where the reliability is going to be questionable anyway. In software development the trick is to know when to stop.
Time to work on some cave surveying software today. Maybe I’ll get a flight in tomorrow. Hope so.
Thursday, July 31st, 2014 at 10:05 am - Adaptive
We’re having some classic Austrian weather right now. It’s been rodding it down since 5am. I’ve been eating Egg And Chips enough times for it to lose its special status.
Most everyone else is caving at the minute. I haven’t seen Becka in 5 days. I’m waiting for better flying weather.
This is a great time to get some work done on these pesky stay-down linking in the Adaptive algorithm.
Here is an example of the A-star linking path calculated in its setting of the rest of the cutting toolpaths, so you can see how it fits in. The path must traverse through the area without colliding with material that hasn’t been cut yet. This image is of the first iteration. There’s a secondary process which pulls the path of light blue dots tight within its structural matrix once it is connecting in the right direction.
What I mean by the right direction is the way that the path rolls off the preceding path and rolls on to the next cutting path. I can calculate the shortest path reliably now, but it would sometimes result in going 180 degrees back on itself if it’s shorter to go round the circle, so the trick is to artificially insert a circle of exclusion that it has to avoid as it finds its shortest trajectory.
This worked well most of the time, except that the path would sometimes go the wrong way round the circle. It doesn’t know any better. It just finds the shortest path which it can. So I inserted this radial blocking line to block off paths that started off the wrong direction.
And of course sometimes the radial line becomes a liability and the stupid shortest path thing has to go all the way around it when it should be coming in to the path nice and smoothly. I just worked this one out this morning.
It takes ages to discover these errors in the data, looking at unusual tool motions in real examples, and trying to separate them out into the debug development environment so they can be analysed and plotted.
In computational geometry, if you can’t see it, you can’t debug it. In the real world you’d hope that a corporation that depended on vast quantities of computational geometry would have a dedicated team helping programmers visualize their messed up algorithms, so they don’t have to hack up crazy things like my “webgl canvas”.
I’ll spend the rest of the day getting to the root of this one, I guess, and then be one insignificant step closer to finally getting this out of the way.
I don’t deserve to enjoy any flying until I do. Nor do I deserve another egg and chips.
Thursday, June 26th, 2014 at 4:52 pm - Adaptive
Just some notes on the serious work that’s still going on. This whole thing was supposed to take a couple of months. It’s run 6 months beyond the time I expected it to already because I had no idea how hard it would be. But this shouldn’t matter in the long-run as the code will probably be in service for 60 years if it works.
At the moment Adaptive Clearing doesn’t do any fancy links. If it can’t go nearly directly through the partially cleared pocket, it rolls off and does a retract to a roll-on to the next starting point. This doesn’t look great. Also, when we re-order the passes for better efficiency, we shred all the links that are any good and need another way of recreating them.
I’ve been meaning to write up something about how we re-order the passes for a year, because it’s a really simple trick. It’s unfortunate that it exposes this re-linking problem, so you don’t get the benefit.
I’ve disabled all the smoothing features that were getting in the way. The first priority is to make a path from the start to the end that avoids the uncut stock using the A-star algorithm which operates within the model of the area. This is how it currently looks:
We’re going to get lots of questions about how it passes on the “wrong” side of the previously cut path. The diagram below should explain why it is correct.
The real problem is that my linking path is going round the wrong side of the roll-off arc. It then has to back-track to find its way to its linking destination. Note how it zig-zags through the cells because re-smoothing is disabled.
The problem is that the cutting cycle skips out sections when there is almost nothing left to cut. But my re-linking motions spots this material and tries to avoid it. Since there’s not enough room to get round the arc on one side, it goes round the wrong way.
This small diagram shows how there is a lot less material there than it seems.
But still, it’s non-zero, and I don’t want to include a tolerance here. So I’m going to try and barge through the start of the linking motion and splice it in some way. Not sure how to code it yet. Things keep growing more and more layers of unexpected complexity. That’s how it goes.
Most CADCAM systems have about half a dozen 2D polygon offsetting algorithms somewhere about inside them. None of them work very well because the trickiness of the problem is notoriously easy to underestimate. The naive method is to offset each line segment perpendicularly sideways and then insert an arc where the angle between two adjacent lines is convex, or otherwise trim them back when the angle is concave, like so:
This seems attractive because it’s going to work whenever the offset distance is very small. Once you offset further than half the minimum distance between any two vertices, then you start to get multiple self-intersections, some of which involve intersections with the inserted arcs. A little bit of thought and you’ll see that this quickly enters a quagmire and you’ll be debugging it for the next 20 years. This is not an exaggeration.
An alternative method is to use Voronoi diagrams. These are great if you want to offset the same polygon by numerous different values, for example if you are producing some offset area clearing passes. The API into such algorithms (if you’ve got one) is daunting, and it’s going to be very time-consuming to add features such as allowing offset to be on only one side.
When all else fails, there’s my machining method, where we repurpose one of the waterline machining algorithms to give the answer that we want. Here we imagine converting the contour we would like to offset into a vertical wall of rectangles, and then we run a flat-bottomed cutter against it. My weave sub-sampling waterline algorithm delivers the structure shown in cyan with a contour going all the way round it on both sides.
Now the trick is to break the contour so it gives only the right hand side (the yellow curve). We have filters for tracing out partial waterline contours based on the contact angle with the tool-tip — for example producing z-constant toolpaths only where the tool is in contact with the surface at greater than 75degrees so they only appear on the walls.
So we could fake this by tilting the vertical wall to one side so that on the upper side the tool tip makes contact with a slope at an angle of less than 75degrees, and on the undercut side the tool shaft hits the top edge giving an effective slope of 90degrees.
But this gets messy. It’s better to add in a special toolpath filtering case that simply works for this application and sets the flags to filter out the toolpath when the contact direction either on the left hand side of the contour, or in contact with one of the end-points of the contour if the contour is not closed.
The disadvantage of this method is that your offset contour is made up of hundreds of little line segments that only approximate the offset with regards to the endpoints of straight sections and linearizations of the arcs. But does this matter? Graphically it looks exactly the same. It might be good enough — especially if we don’t have to debug it for the next 20 years.
If I was starting this fresh and not trying to get it done in a day, I could encode which line segment or vertex each point of the offset shape was offset from, and then try to rejoin sequences of segments into the same line or arc where they came from the same entity. Then, after that, for segments that jump the gap between a offset point from entity A to a offset point from entity B, I’d extend the two offset passes to the true intersection between A and B. This would be robust almost all the time. And it would be fail-safe because wherever there was a problem it would fall back to the approximate offset — which is almost always going to be better than crashing or giving a properly screwed up result.
A mere 9 years after we first tried to use our own mini-machine tool — which Martin wants to make sure everyone understands he did get working (shortly before it broke) — it’s been brought out of the cupboard and fitted with some proper electronics in the form of an Arduino controller by the DoESLiverpool Italian intern, and is showing signs of life.
The part of this kit that gave me the most surprise was the GRBL G-code parser code that ran on the Arduino. Look at the amount of software crammed onto that thing! Watch out Hurco and Heidenhain, your days are numbered. Soon all your industrial equipment will be deader than a Vax VMS.
My favourite function in the GRBL code is report_realtime_status() which prints a line of the form
Yes, it’s the current position of the tool while it is running.
I immediately wrote a threading Python program to drip tool motions into the Arduino interspersed with the “?” command to invoke this realtime status to find out where the position currently had got to. Eventually this could become the principle behind a combined probing, cutting and dynamically feed-backing CAM system — something that cannot be implemented on industrial machines today due to their batch-work nature and one-way post-processing valve filter. For more, see earlier post on the feedback in the cnc drive configuration.
While writing an internal rant about why it’s okay to machine triangles, when some CAM systems claim to be “more accurate” because they locate their cutter positions against the analytic geometric surfaces themselves, I came to an important observation: the point nodes of the toolpath as defined in the G-code file are of no significance to the total cutting process, which continues along the straight lines between the nodes. All these cutting positions on the lines between are never on the accurate surface, so getting the zero dimensional finite set of node positions exactly right doesn’t make a difference.