Path planning - last step to full CNC functionality

[camchaney]

Sharing some progress I’ve been making on the path planning front of the handheld CNC router. Because of the unique nature of this CNC, all of the toolpathing has to be custom made to fit a dynamic workflow where the workpiece is always moving. I’ve chosen to approach this in an interesting way, utilizing the already-so-great-and-powerful CAM software that is already out there to get a generic toolpath, then running the gcode output through my own post processor script to put everything into language that my device will understand. Right now, the only things my post processor is extracting from the gcode are the XYZ coordinates (while ignoring travel speeds, spindle speeds, other gcode commands).

There is another layer of complexity added to this path planning when taking into account the current design of Compass, which only has two axes of correction. This means that the third axis is controlled completely by the user, making complex cuts a little more tough - though not impossible - to perform. The problem boils down to the router being limited to a certain angular range of points in front it. If you imagine wanting to cut a straight vertical line, that is no problem: as the user moves it forward, the motors don’t have to move the tool at all. If you want to cut a line that is tilted, though, the motor has to move faster to keep the tool on track. As you keep tilting that line more and more, the motors reach a point where they can no longer react fast enough. This makes it so that the device essentially has this ~90º FoV in front of it where it can cut:

The 90º number is a little arbitrary because it really depends on how fast you’re moving the router, but at a normal operating speed, that is a decent bound. This doesn’t mean that the router is just limited to straight lines, though. When cutting a circle, for example, you could continuously rotate the router as you move, keeping the correction axis perpendicular to the circle’s tangent as you go. You could also cut half of the circle by moving the router forwards and backwards, and then the other half by rotating the device by 90 degrees and moving the router forwards and backwards. This second approach can be generalized much more effectively to any arbitrary design. You can split up any design into a few angular zones that can be cut by the router using multiple back and forth passes.

I’m using an iterative k-means approach to group all the lines of a design into the minimum number of clusters possible. While this isn’t 100% perfect, it works pretty well. The next step is to split up each cluster into passes for the router. This is an example of what that might look like for cluster 2:

The tough part for me right now is automating that in software. I’m getting a bit of gobbledeygook at the moment:

Almost there though! It’s exciting because once this is done, I can actually start using Compass for actual woodworking projects. Up to now I’ve just been hardcoding the paths, which is hard to do for anything too complex. This whole path planning software hole has been making me think more and more about just making a three axis version, though… But it’s really easy to underestimate how much software complexity that would actually entail hahah. The controls for that is a whole other can of beans. Saving that one for future me…

[jeyeager (Jason Yeager)]

Wow, this is quite a thing to wrap your head around.

@camchaney

the device essentially has this ~90º FoV in front of it where it can cut

This is based on the direction it’s being moved right? So you have 90 degrees in front when moving forwards and 90 degrees behind when moving backwards?

Does the screen also indicate to the user that they need to rotate?

Then to think about cutting that out as a pocket instead of an outline. And even without that, I think at some point the back and forth over cuts would lead to sensors getting confused.

You’ve certainly got an interesting challenge on your hands.

[jeffeb3]

@camchaney

. I’m getting a bit of gobbledeygook at the moment:

It loos pretty good. But some of the things that are there that I think shouldn’t be are probably travel moves. You want to remove those first. You can determine what is a travel move in most gcode because the tool moves up to the clearance plane in Z. Some CAM even makes G0 only for travel and G1 only for cutting (most should support that, honestly).

Also, I think you are probably already doing this. But you should start by converting the gcode to line segments, not vertices. They look like points, but they are lines defined by the previous point. Except for arcs (G2/G3).

I like the k-means approach. My naive approach would be to just bin everything in explicit north/south and east/west bins. But some patterns would lend themselves better to an arbitrary angle for the bins.

@jeyeager

This is based on the direction it’s being moved right?

It is a combination of that and the direction the machine can automatically correct. It has a Z and an X axis. But not a Y axis. So if you’re moving it parallel to the X axis and you’re wrong in Y, there is nothing the machine can do. If you’re following a line parallel to the Y axis and you’re wrong in Y, the machine can just wait for you to move in Y.

[vicious1 (Ryan)]

@camchaney

When cutting a circle, for example, you could continuously rotate the router as you move, keeping the correction axis perpendicular to the circle’s tangent as you go. You could also cut half of the circle by moving the router forwards and backwards, and then the other half by rotating the device by 90 degrees and moving the router forwards and backwards. This second approach can be generalized much more effectively to any arbitrary design.

Okay, now I completely understand why you need to break things up at this point. Currently, either you break things up, or the user basically needs to drive the line to be cut within that window/field of view, I guess the third option for this specific design would be to have the user pause and rotate then continue the cut so there is always some room to correct.

I could envision making that circle and understanding the issue when you get to the top and bottom, if you are not exactly on the line the Compass can no longer correct in that direction.

To not need the user to “drive” the path some changes would need to be made.

[camchaney]

@jeyeager

This is based on the direction it’s being moved right? So you have 90 degrees in front when moving forwards and 90 degrees behind when moving backwards?

Yupp exactly. Jeff explained the rest pretty well. And yes, the screen tells the user how they should be rotating as well as where to move in the X and Y plane.

@jeyeager

Then to think about cutting that out as a pocket instead of an outline. And even without that, I think at some point the back and forth over cuts would lead to sensors getting confused.

Ahhah yup pocketing would need a slightly different approach, but I honestly don’t think it would be that bad. You could do a “back and forth” pocketing operation which would actually be a pretty similar protocol to the way I suggested doing back and forth passes to complete complex designs. There is definitely more chance for the sensors to get confused the more you cut (which is actually a shared problem that Shaper also has, as you cut away more of the tape). Having additional sensors for redundancy allows you to overcome this to some extent, as long as you have 2 sensors on the surface at all times and a reliable way of determining when a sensor is giving good readings or not. But yeah, at some point they will definitely get confused.

@jeffeb3

Some CAM even makes G0 only for travel and G1 only for cutting (most should support that, honestly).

Oh that’s awesome that’s a slick way of doing it. I am already accounting for travel moves at the start, but that would be much cleaner.

@jeffeb3

Also, I think you are probably already doing this. But you should start by converting the gcode to line segments, not vertices. They look like points, but they are lines defined by the previous point. Except for arcs (G2/G3).

Yup, I am. Also I’ve just decided to use a post processor without arcs so I don’t have to deal with that hahah. I think some of the bugginess is coming from when I try to combine the lines back into points at the end to sort them into groups. It’s definitely a bit of a whacky approach. But it shouldn’t be too hard to clean up.

@vicious1

Currently, either you break things up, or the user basically needs to drive the line to be cut within that window/field of view, I guess the third option for this specific design would be to have the user pause and rotate then continue the cut so there is always some room to correct.

Yeah there are a few ways of breaking it up, and I think it would honestly be worthwhile to have multiple options in the future depending on what kind of design you have. Breaking the design up into passes at a few distinct orientations just seems like the most reliably generalized solution.

[Dreyfus]

For pocketing would it be practical to do the perimeter and then let the operator ‘freehand’ the rest whatever way they want, lifting the tool if they get to an edge?

[camchaney]

That’s a pretty cool idea. The tricky part would be determining where the “inside” and “outside” of the pockets are based solely on coordinates extracted from gCode. Not impossible though. I guess you could also have a dedication pocketing operation that works a little differently

[Dreyfus]

In CAM software like Estlcam you do specify pocketing operations as distinct to engraving

[vicious1 (Ryan)]

But the gcode does not show any differences that would be easy to just pick out. Like Rapid G0 vs cutting G1.

[camchaney]

@Dreyfus

In CAM software like Estlcam you do specify pocketing operations as distinct to engraving

Yeah I guess I was talking more about the firmware side, or how the router should handle a pocketing operation. But maybe it would be enough to just take the gCode output from a CAM pocketing operation and treat it the same as any other cut. It would be awesome for the firmware to be robust and versatile enough to handle that

[MakerJim]

@camchaney

It would be awesome for the firmware to be robust and versatile enough to handle that

The firmware just executes gcode. It has no idea what you are doing with it.

[RockinRiley (Riley)]

This has mouse sensors, right? What happens if your travel moves the sensor over a cut?

[camchaney]

@MakerJim

The firmware just executes gcode. It has no idea what you are doing with it.

Yup totally. I’m just a little pessimistic about the current state of my firmware in terms of it’s ability to execute pocketing operations with the same quality as engraving or profiling operations. I’m likely going to have to modify it to be able to handle all of these operations more reliably. Right now, though, I’m mainly focusing on engraving and profiling.

@RockinRiley

This has mouse sensors, right? What happens if your travel moves the sensor over a cut?

Ahah yes great question. Generally speaking, when a sensor goes over a cut, it isn’t able to get a reading. As long as there are always at least two sensors on the surface, though, the machine is able to maintain it’s position estimate. That’s part of the reason why I have four sensors. We want to maximize the probability of having >2 good sensor readings. In the sensing code, I check the quality of each sensor’s reading in each time step and throw away sensors that aren’t above a certain threshold. If there aren’t >2 sensors above this threshold, the tool is pulled out and the user is prompted to re-zero the machine.

You can imagine the more material you remove, the higher chance that sensors will be unable to get a reading. This is definitely a limitation with this sensing approach. Shaper interestingly also faces the same issue, as the more material you cut, the more locating fiducials you remove. One simple way to combat this for our router would be to just add more sensors.

[Dreyfus]

How do you set/reset 0,0 is there a homing ‘jig’ you move back to?

[camchaney]

Exactly, I’ve just been using a 3D printed homing bracket that I start from for bigger designs.

[RockinRiley (Riley)]

@camchaney

I’m just a little pessimistic about the current state of my firmware

Any chance of working with Fluidnc to see if you could mutually get something rolling?

Not sure you would want to or not, but could be an avenue to get rolling right away.

[jeyeager (Jason Yeager)]

@RockinRiley

Any chance of working with Fluidnc to see if you could mutually get something rolling?

I wouldn’t go there. This is very different and they’ve got their hands full as it is.

[camchaney]

@jeyeager

I wouldn’t go there. This is very different and they’ve got their hands full as it is.

Yes agreed totally hahah. I’m already 95% of the way there with my firmware and it really is so much different from a standard CNC machine in more ways that not.