Calibration Raw Data

TLDR: I’m re-writing the calibration system. It’s WAY better than any previous Maslow, but it’s not perfect yet.

Since we hit our goal I’ve been focusing on the only thing that I am at all worried about which is the automatic calibration process. Up until a few weeks ago I was using a genetic algorithms based approach which “evolved” the correct X,Y coordinates for each of the anchor points. Right before launching the kickstarter I was going through and vetting and checking everything and I realized that while it did a great job sometimes, genetic algorithms are non-deterministic because of simulating random mutations which meant that it didn’t always give a the same answer even given the same input measurements and it could be wrong. I decided that I wanted a deterministic solution (ie it will always give the same correct answer, given correct measurements) so I started re-writing it.

The new system is coming along well and I wanted to share my progress both for the sake of transparency and also because many eyes are better than two.

Here’s how the system works.

We start out with a series of measurements. These measurements are taken by moving the machine to some unknown point using the upper two belts the way the two chain Maslow moved, and then pulling the lower two belts tight. We don’t know the XY coordinates where each measurement was taken, we only know the lengths of all four belts at that point.

We have an initial guess for the XY coordinates of the anchor points, but it’s a random guess. No matter how bad that guess is we want the process to end with the right answer.

We then take those starting coordinates for the anchor points and “attach” each measurement to them then we find the setup that puts the end of each measurement as close together as possible. When we have found the correct solution each of the measurements will join at a single point, but for now they don’t meet.

Next we find the “center of mass” of each measurement (basically the center of each grouping of 4 dots) and compute how far each dot is from that grouping in X and Y. We then take the average of all of these and determine which corner we should move to make the most dots closer together and move that corner.

(A couple iterations later to show some progress)

The process then repeats until moving any anchor point in any direction will move the dots apart.

At this point we’ve found our anchor points.

This works very well on simulated data and always produces the correct result independent of what the starting guess is and it handles inaccuracy in the measurements well.

I showed it above with 9 measurements which is what I was initially using because it’s easier to see, but I’ve found in practice that more data is better so we are now using 110 data points which looks like this



One other note is that because we get to define our coordinate system we can declare that the lower left anchor point is (0,0) and the right anchor point is at (?,0) so we’re only actually solving for the top left X,Y, the top right X,Y and the lower right X.

How does it work in practice:

Pretty good, but not perfect yet. Running the calibration process twice on the same frame should give the same results, and while it gives close to the same results they aren’t identical. Two back to back runs yesterday produced

(-1.2775505926851451, 2125.411304076909), (3036.051941957454, 2127.91394620096)
(0, 0), (3041.4964766419607, 0)


(-1.639147982037378, 2128.4314646585512), (3033.2235866981528, 2131.949568552577)
(0, 0), (3038.5630396604274, 0)

Which are closer than I could measure by hand, but the goal is for them to be identical.

After running the first one I cut two 600mm test squares (one in the center of the sheet, and one at the far left of the sheet) and then measured them to be:

Width: 596.5
Height: 598.5

Width: 598.5
Height: 595.5

I think I may have accidentally forgotten to change to cut outside the line instead of on the line in Carbide Create (for some reason they have on the line as the default) which would give a target 600-(6.35/2) = 596.8mm in each dimension. Measuring across the tops of both squares with a straight edge I can’t see any bend.

It’s a heck of a lot better than the “my circles are ovals” type of issues we’ve had in the past, but the goal is ±.5mm across the whole sheet so we need to keep dialing it in.

What can we improve?

One of the thing which I discovered this week is that the order that the belts get pulled tight in matters sometimes. For example:

In this location if the right belt pulls tight before the left belt is taught the tension can be removed from the upper right belt leading to an inaccurate measurement.

Changing the system to always pull the left belt tight first on the left side of the sheet and the right belt tight first on the right side of the sheet made a big difference in improving repeatability.

Belt stretch is not currently taken into account, and while the belts are very low stretch, they aren’t zero stretch and I would like to factor that in.

How can you play with it before you have actual hardware? (by which point I intend to have perfected it)

I’ve written a simulator to mess around with the math. You can find it and sample data from test runs here: GitHub - BarbourSmith/Calibration-Simulation

It’s written in JavaScript so you don’t need to install anything, just download the files and double click on the index.html file there to play with it.

I haven’t made it super user friendly yet (pull requests are welcome :stuck_out_tongue: ) so if you want to see what is going on in the background you will need to open the console where it can print things out.

I’ll keep you updated on my progress, and answer any questions. I’m open to any and all ideas and suggestions.


Thanks for this info. A couple quick things

Since you assume that the bottom two points are horizontal from each other, when
they aren’t, you rotate your cutting axis. Not a fatal flaw, but something to
note (and possibly allow to change. For example, when you use your unistrut
frame you can reliably say that the right point is the width of the unistrut
lower than the left. Still won’t be perfect, but will be pretty close). It may
also be that after doing the calibration, there needs to be a ‘move to the 4
corners’ type of thing to adjust for workpiece/calibration coordinate system

How much of a difference do you get in calibrating with the driveway anchors vs
the unistrut frame?

In tems of reliability, I see several sources of error

  1. belt stretch
  2. frame flex
  3. belt sag (should be low as the belts are light)
  4. starting belt length

for belt strech and frame flex:

first off, what differences do you get from having your calibration happen at
low tension (low motor current) vs high tension?

you should be able to categorize the belt material, take a known length, apply
different amounts of force to it and see how the length changes. You can get a
measurement of the actual force applied by a scale attached to one end, or by
stretching it out horizontally and then hanging a known weight to the center and
see how much it moves that point (yes, it stretches the belt a smidge more, but
a trivial amount compared to the vertical movement caused by the weight)

I’m not saying that you need to do this as part of the calibration routine
(although it may be worth having a routine to do this for people who are using
different belts), rather I’m suggesting that you do some testing and load a
‘belt definition’ into the firmware as a default that you then use in your

youc an also categorize the expected tension caused by the motors compared to
the current applied to them. Again, different motors will be different, but I
expect they will be fairly close.

once you have an idea of the expected changes in belt length based on different
tension, you can test how much the frame flexes by going from low tension to
high tension and see how much more length change you get than you expect.

finally, the starting belt length, when you have the belt fully retracted, how
confident are you that the position is 100% repeatable? even a mm or two of
slack at that point will result is fairly significant errors in anchor

David Lang


are you pulling them tight one at a time? or can you apply power to all the motors simultaneously to make sure they are all tight? (the original maslow had a B command to run individual motors at a given power level, but you had no way to do so to both motors, the new system should allow you to specify power to multiple motors if you want to)

check how gravity is affecting you. What coordinates do you get if you rotate your anchors? (90, 180, 270 degree rotation of the sled) or if you lay the frame flat (I asked in the prior message about testing on the driveway anchors, but that changes two things, gravity and frame flex)


Would setting zero degrees and keeping track of how much rotation off zero takes place be of use? Do you have say a straight line for reference on the sled?

I would be interested how much rotation took place to see if it was similar or way different between the two calibrations. Just a tough off the top of my head while reading through this.

Thank you


I don’t think the rotation of the sled itself would be an issue. In fact, I think if we allowed it to rotate around the router, that wouldn’t change anything much; Since the arms rotate freely around the router, and even with little tension the belts always align themselves, so they “end” at the very center of the router. In other words belt tension always works against any rotation.

The problem with rotation we have though is sled tends to tilt a little bit, when one side has more tension than the other, but we’re planning to solve it by making a bigger sled and starting calibration at low Z.

Since you assume that the bottom two points are horizontal from each other, when
they aren’t, you rotate your cutting axis.

Why would you say it’s a flaw? After all, we kind of free to choose the rotation of the coordinate system, right?

So it’s just a handy way to do it. The only “real” basis could be dictated by the gravity axis, but again, that wouldn’t work if we are working on a horizontal plane. And I think it’s safe to assume that in many real world frames, the sheet of plywood wood be aligned with whatever the “bottom bar” of the frame would be.

This is a great question. I will find out. The system is really designed from a workflow perspective to be easier in the upright direction, but I’ll make it work for both and do a comparison.

This is also an excellent suggestion and pretty easy to change since it’s just a constant in the code. I’ll do some runs at two different tensions and see what the results are. It might also be nice to do driveway vs frame at both high and low tension since the frame will flex more, while in the driveway only belt stretch is really a factor (I don’t imagine the concrete compresses much :stuck_out_tongue: ). We’re getting into a lot of permutations to run, but I’ll get on that.

This one I feel great about. After running the calibration the belts are retracted back to their home position and we report any error…basically we should expect zero to be where it was before and it’s usually within 0.05mm at the most, often less so we getting very good repeatability for homing the belts to zero length.

We have the option to pull them all tight at the same time, but I’ve found that pulling them tight one at a time in a repeatable order improves the accuracy. Pulling them all tight at the same time introduces random chance into which belt gets taught first. Making that change alone resulted in about a 5x improvement.

I just tweaked the code to report the X,Y coordinates of each corner at each step so if you downloaded the code yesterday, it might be worth updating to make it more usable

Since you assume that the bottom two points are horizontal from each other, when
they aren¢t, you rotate your cutting axis.

Why would you say it’s a flaw? After all, we kind of free to choose the rotation of the coordinate system, right?

it’a a flaw if you are trying to cut square on your material

So it’s just a handy way to do it. The only “real” basis could be dictated by
the gravity axis, but again, that wouldn’t work if we are working on a
horizontal plane. And I think it’s safe to assume that in many real world
frames, the sheet of plywood wood be aligned with whatever the “bottom bar” of
the frame would be.

it’s not on Bar’s unistrut frame. He has the workpiece parallel to the unistrut,
but the machine coordinates are rotated from that as the bottom right anchor is
lower than the bottom left anchor.

That’s fine for calibration, but between that and when you start cutting, you
need to be able to correct for what angle the material is at compared to your
absolute machine coordinates…

It’s not a matter of the gravity axis (if you have the machine on a table, that
wouldn’t work), it’s adding a step to define where cutting 0,0 is and rotation
from there.

David Lang


pulling them all tight at the same time can move where the sled actually is, but
it avoids the example you give where pulling others tight makes one loose. In
your example, if you pull the top left tight first, then it gets lose when if
you pull the top right and bottom left tight. But whatever order you pick, there
will be someplace on the sheet that that results in that order moving the sled
to loosen the first belt you work on.

so you need to follow your individual retraction with applying power to all 4
motors to see if anything moves.

Is the system stiff enough to hold it’s position without power?

David Lang

tilt in the Z direction?

the only real fix for that is going to be to mount the anchors at the correct
height for the balance of the sled, and the right balance of the sled will vary
depending on the router used (and to a small amount, the Z position of the

a larger sled will reduce this a bit (but have problems near the edges)

David Lang

I made some pretty significant progress on this by starting to incorporate belt stretch into the algorithm. Adding a 0.5% belt stretch into the system and then re-reunning the data gave me the locations of the anchor points as:

(9.253529809814152, 2119.1431555347945), (3027.87782566824, 2119.9644539441906)
(0, 0), (3042.0849894449107, 0)

In the first run, and:

(8.771011804292286, 2120.3915138387947), (3027.135642788878, 2121.1544011076794)
(0, 0), (3041.2287605396036, 0)

In the second run which are excellent.

This is with disconnecting everything, powering off, re-homing all the belts, and then taking the measurements again from scratch so finding the nearly identical bolt positions again looks fantastic.

There’s still a bunch of ways that we can improve, for example instead of adding a constant percentage of belt stretch we could add a dynamic belt stretch measurement based on the tension in the belts in different locations and also @dlang idea of taking a measurement in the same location twice with different tensions could help us to compute the flex in the frame and compensate for it.

Basically it’s looking really really good already, and there’s more exciting stuff to make it even better.

Will you not get more belt stretch in the top belts due to gravity and the weight of the sled in a vertical plane…? Just wondering what the calibration will be in a horizontal plane vs one that is 15° from vertical …?

1 Like

What has been your average depth of cut in the plywood you have been working with?

More specifically, I am hoping the newer version can handle a deeper cut. In baltic birch I was having to limit depths to .125” per pass.

Totally and I think that we should have a setting for upright vs horizontal to compensate for that difference.

I think that’s about what you want. I’ve been using the default settings in Carbide Create which are for the Shapeoko 5 Pro and I just checked their settings for soft wood and they recommend a 0.06" stepdown. I think that’s excessively small and 0.125" is better, but you do want to be taking pretty shallow passes. This big difference is that now we can run at the recommended speed too of 1900mm/min.

1 Like

The Shapeoko is not a very powerful or ridged machine, so it has to do shallow
cuts. I think there is a good chance that the maslow4 can do more, but testing
is needed.

David Lang


Since tightening order affects calibration, you might get more repeatable results by tightening twice.

Sort of like when you torque lug nuts.


I noticed in your simulator, you don’t solve for Z. While a 3mm difference in Z is immeasurable at 3m, it is of the same magnitude as your target error near the attachment point.

Calibrating on a driveway, I’d expect that there could be large differences between Z for each corner as well as the center of the workpiece. My driveway has several 1" deep puddles, so I know it isn’t flat, and my while my basement floor is better, it isn’t all that flat either.

1 Like

is it possible to chuck a 1/4" guide pin in the router, drill a 1/4" hole in the waste board, and take a number of repeat measurements to see how much variation there is? is this what the “bolt” measurement is, or does it mean connection points?

is variation different at a top corner, bottom corner, center?

1 Like

I noticed in your simulator, you don’t solve for Z. While a 3mm difference in Z is immeasurable at 3m, it is of the same magnitude as your target error near the attachment point.

Z is in and out from the pictures, there is only ~2" worth of Z travel, and it’s
screw driven, not a belt driven

While a steep angle of the belt could be a factor at some points, with over a
foot of belt extension even at the top corners (and probably 2-3’ worth of belt
at the top measuring points), even if the Z of the belt is a difference of 2"
vertical difference, with a belt length of 2’, that’s about a 1mm difference in
measured belt length from actual offset.

but more to the point, it should be consistant, not vary from run to run

David Lang