Calibration pattern for triangular kinematics

Technical Details
41

Ok, I understand better what you are trying to do here. I think we are pretty
close

I think we have a more accurate measurement of the distance between the motors
than the sled rotation radius, so I would want to measure motor distance and
calculate rotation radius rather than the other way around.

In an earlier discussion the possibility that the motors are not centered on the
work area was raised. I’d also like to avoid having people enter in machine
dimensions at all if we can.

I believe that we can do this by:

  1. say that one of the locations is 0,0 (or possibly as close to this as a full
    tooth movement allows so that the chains can be marked for this location)

  2. have the user manually move up/down/left/right to mark out the
    limit of the allowable space

We then don’t need to have them measure/input anything other than the distance
between the two cuts.

I think it would be interesting to test this in two ways

  1. Low Precision, Long Baseline

    use as large a distance as possible with a tape measure (I’m good with
    requiring this measurement be done in mm, even in the US most new tape measures
    cover metric as well as imperial).

  2. High Precision, Short Baseline

    use a small distance (about 6") so that a high precision measurement can be
    made with a cheap electronic caliper

It would be interesting to see which approach is more accurate and easier to do
(and it may be worth offering both options and letting the user specify)

So where you list the steps as:

  1. Enter sled rotation disk radius and validate Machine Parameters are
    correct
  2. Calibrate chain lengths, then connect chains to sled
  3. Move sled vertically only to top of work space and make first cut/mark
  4. Record programmed chain length for first cut/mark below
  5. Move sled vertically only to bottom of work space and make second
    cut/mark
  6. Record programmed chain length for second cut/mark below
  7. Measure the distance from the top of the workspace to the centerpoint of
    the first cut/mark and record below
  8. Measure the distance between centerpoints of the first cut/mark and the
    second cut/mark and record below

I think it should be.

  1. if using non-standard motors/gears enter:
    • stepsPerRotation
    • link size
    • sprocket tooth count
  2. measure the distance between the motors using the chain
  3. adjust the chain lengths to attach to the sled in the center of the work area. Mark the chains for this location.[1]
  4. do one small cut/mark
  5. move vertically as much as possible and still be in the work area
  6. do a second small cut/mark
  7. move the sled out of the way
  8. measure the distance between the cuts and enter it into the software
  9. move to the top/left corner and tell the machine we are at the limit there
  10. move to the bottom/right corner and tell the machine we are at the limit there.
  11. trace the full boundry of the work area to confirm everything is clear (possibly in both directions). This is sort of a ‘victory lap’, but it’s also a valid confirmation that the sled doesn’t hit anything or fall off anywhere along the way.

This only requires one measurement to be entered, the distnce between the cuts.
It also only requires three positions to be tagged (home and two corners), no
matter what the machine size is.

Since there are two unknowns here, I as thinking that we can’t just guess an
iterate to find the right answer (that’s why I took the more mathamatical
approach). But if we can, that is great (given that this only needs to happen
once, it doesn’t matter if it takes 1000 interations of 10,000 iterations, we
are talking seconds at most. Have it output what it thinks it’s accuracy is
every few hundred iterations so we can show a progress bar :slight_smile:

If we can do this, I would not implement this calibration in GC, but rather in
the firmware. That way we can use literally the same code to do the calibration
calculations that is used to do the calculations during movement. (and the fact
that this is done in C will probably mean it’s faster than Python in GC, even on
a faster desktop)

If we need to, we can add a third mark (down from center) as a sanity check,
with three points and only two unknowns, I know we can calculate the unknowns.

David Lang

[1] this is a couple of steps as far as the user is concerned, but only one as
far as the machine is concerned because they all move both motors the same
amount ane they can be done on one screen without any prompts other than chain
movement.

First feed out a guess of the right length, then allow the user to adjust the
lengh by a multiple of one tooth movement until it’s convienient to attach the
sled, then move (again by multiples of one tooth) until the sled is in the
center of the work area

We don’t care when during this process the sled gets attached.

1 Like
42

Will one need skirts around the workarea to support the sled? Perhaps this step could be optional; it takes quite a while to go ‘round the world’.

43

This is after the user has specified what the limits are by driving the sled to those limits. So it’s up to the user to decide if they are going to include skirts to support going to the very edge of the wood or not.

Yes, this can be optional (and the step before could allow for manual entry of the 4 limits), but I think it’s valuable to do this once (with any power tool, and especially with a CNC machine, it’s important to move it to it’s limits before trying to run it for real, you don’t want it hitting something while cutting)

44

by the way, this is why I suggested going round the world once in each direction, just to check that there’s not any instability that happens going one direction vs the other.

45

Better make it clear that the ‘workarea’ is not the same as the sled support surface, then. All the instructions are written around a 4x8 sheet, so the ‘workarea’ of that 4x8 layout would need to be three or four inches less on each edge. It’s one thing to plan a temporary support skirt for a cut that gets near the edge of a sheet, but different if its presence is required for calibration.

46

well, IMHO part of calibration (or at least machine setup, which is effectively
what this calibrtion process is) is defining what the cutting limits are. It may
be that we allow there to be multiple sets of limits (or easy ways to override
the limits), but the idea is to define what the machine’s effective size is, and
if you don’t want to cut too near the edge, you set the limits accordingly, if
you are willing to go all the way to the edge, you should plan to do so and test
it during the machine setup stge.

47

You shouldn’t have to drive to the limits to define them.

1 Like
48

no, but it’s the easiest way to be sure that the limits are sane and what you think you are measuring.

So I would make the ‘drive to the corners’ be the default and allow for manual entry of the limits if people want to do that.

If you don’t actually move the sled to the corner, how do you really know that there is enough support there to keep it from tipping?

49

That makes sense to me, and is entirely possible. I’ll create another Excel document which functions similarly but solves for the rotation disk radius instead.

This is an interesting topic, and I feel itself could easily be an entire thread. The Excel calculator I created makes two assumptions:

  1. The line connecting the motor axes is parallel to the workspace X axis
  2. The X=0 line is equidistant from both motors

#1 is a function of build accuracy (due to the fact that currently the motors do not have individual Y coordinates but instead a single Y offset from the workspace). Individual Y coordinates for each motor, along with a corresponding change to the calibration routine, would allow this issue to be mitigated. Having said that, this particular issue does not affect precision or relative positional accuracy, but instead only influences absolute positional accuracy on the workspace. If you were trying to push to the very boundaries of the workspace or had a significant difference in height between motors then this could be more significant. I could see this being adjusted in the future, but for the time being I feel it is an acceptable assumption to make.

#2 is similar in that it only affects absolute positional accuracy. Having said that, while the code as it stands today cannot account for this, it would be a simple change to incorporate it. Individual motor X coordinates would be required, or an X offset of the workspace, but during calibration it could be assumed there was no X offset of the workspace center compared to the motor spacing midpoint. Then the X offset could be corrected after using a routine such as the one you mentioned of having the machine positioned to two opposite corners of the workspace.

I completely agree. My initial thought was to prefer the long baseline approach. Given the contents of my toolset, I can accurately measure down to roughly 0.5mm over a long distance. If I made such a measurement over say 900mm (assuming a 4x8 foot Maslow and performing calibration in the vertical direction), this would give an error of roughly 0.056%. The same error over 150mm would require an accuracy of 0.083mm. My current toolset is not accurate to anywhere near this level, and I suspect many Maslow users would be similar. Additionally, such accuracy is roughly within an order of magnitude of our current motor encoder resolution (assuming # 25 chain, a 10 tooth sprocket, and 8113.7 encoder steps per revolution). Because of that, we could see substantial resolution-based error as well.

However, this level of accuracy during calibration may not even be required to achieve the project target accuracy levels, so I think it would still be interesting to test out.

Based on the steps you mentioned, it is possible to determine the rotation disc radius, the center of the workspace, and the workspace boundaries. Once the rotation disc radius is determined based on the two cuts/marks and the motor spacing is entered in, then the workspace limits need to be defined. This could be done either as you stated, by having the user move the sled manually to opposing corners and have the limits automatically calculated, or have the user enter the workspace dimensions manually as well as the offset from the top cut/mark to the top of the workspace. I think including both options would be beneficial.

Also, I completely agree on the iterative process. Even if it takes 10,000 iterations, we’re likely only talking a couple seconds at most, and then the process doesn’t need to be repeated until a change is made or a recalibration is desired. Having intermediate outputs is a good idea too.

I’ll work next on that updated Excel calculator.

50

sounds great

I think we define these as axioms. X=0 is by definition exactly the center of the motors (the backer may allow more movement in one direction than the other, so X=0 may not be centered on the work area :slight_smile: )

similarly, the X axis is parallel to the line between the motors, if the frame isn’t square, it’s the frame that’s wrong :smiley:

I think it would be useful to add a button that has you fasten a piece of plywood slightly above the bottom beam of the machine (to support the sled) and then cuts top edge of the bottom beam so that it is flat

we already allow for a working home to be defined differently than the actual home. This is what should be used. But limits to movement need to work on the machine’s actual dimensions.

currently chain sag will introduce enough error to throw us off beyond this.

for the short baseline, cheap harbor freight calipers like these
https://www.harborfreight.com/6-in-composite-digital-caliper-63137.html ($10 ± 0.01"/0.2mm) or https://www.harborfreight.com/6-in-digital-caliper-with-sae-and-metric-fractional-readings-62569.html ($20 ±0.001"/0.03mm) will give you the accuracy needed for the short baseline approach, and it’s good to have a set of these available, you want to measure your plywood thickness when cutting pockets or slots for it to go into.

with the short baseline, you also care about the width of the slot cut by the bit to take that into account.

Thanks for working on this.

51

Here is a version of the Excel calculations which have the user enter the motor spacing and calculates the motor offset height and the rotation disc radius. Let me know what you guys think!

MaslowTriangularCalibration v1.1.xlsx (157.7 KB)

1 Like
52

overall looks good. One detail, it’s hard to measure to the centerpoint of a
cut.

you can measure the distance beteen two cuts by measuring from top edge to top
edge

you need to measure the width of the cut (or assume the bit is the size it
claims to be) and subtract half of it. So you need to ask the bit size and tweak
the directions slightly.

53

I agree about the centerpoint of the cuts part. My intent was to ensure the user did not measure from the bottom of the top cut to the top of the bottom cut. I think measuring top edge to top edge is the simplest approach.

2 Likes
54

that works for measuring the distance between the cuts, but not for measuring
the distance to the top of the work area

55

Ahh good point. So for the best accuracy we should ask for the cutting diameter of the bit. We then ask the user to measure from the top of the top cut to the top edge of the work space, and incorporate the half bit width as you mentioned.

1 Like
56

How does this use the measurement from the motors to the top edge of the workspace? The current system lowers a chain end from a motor and has the user eyeball it. That’s probably not accurate enough for adjusting precision.

57

or we ask the user to move the sled to the middle at some point and use the
chain lengths at that point to figure out the height.

58

How does this use the measurement from the motors to the top edge of the workspace? The current system lowers a chain end from a motor and has the user eyeball it. That’s probably not accurate enough for adjusting precision.

This version calculates the distance from the motors to the top edge of the
workspace.

by doing the calculations based on the two cuts and the distance between them,
it figures out how far the motors are above the cuts. So if you then tell it how
far the edge of the workspace is above the top cut, it can subtract that from
the distance between that top cut and the motors, giving you the distance from
the top of the workspace and the motors

1 Like
59

also, if we have the user move the sled to two corners, that will define the top
of the workspace as well, and we can define ‘center (0,0)’ as midway between the
two corners.

I’ll admit that I really like defining the center as a point that has the chains
at equal lengths with a sprocket point straight up so that the chains can be
marked for the center to make it faster to reload the chains/sled if they are
detached from the frame. but if we know the to corners, this isn’t strictly
needed.

60

Having a (0,0) point defined by a marked sprocket point and point on the chain would make resetting the machine after having the chain off the sprocket extremely simple. But the same could be done for any point, it doesn’t necessarily have to be for a sprocket pointing straight up.