# Calibration pattern for triangular kinematics

so the quick first pass says:

linear distance 4407mm sag 48mm tension ~65N (14.6 pounds) chain length 4408mm
for a position error of ~1mm due to the chain sag.

that’s actually better than I thought

could you tinker with things in that position (add weight, adjust tilt) and see
if anything makes a signficant difference in the sag. if the sag can be reduced
to 30mm then the error drops to ~0.5mm for example (a 50% heavier sled may do
that, but also a steeper angle may let the sled slide better into that position)

David Lang

I meant to say that setting the 0,0 point should be done after the sled is calibrated in the same way as in the quad calibration process. One change at a time.

you could do it as a separate step. My contention is that it won’t change the
accuracy of the final center, so we may as well do it in one step.

David Lang

I won’t be able to tinker with the angle, but I can hang some more weight on the sled after I finish today’s cutting.

1 Like

I ran down to the same location and verified that my 26lb sled sees 48mm of sag. I moved and added another 10.5lbs and returned to that spot and found 42mm of sag. Again moved and added another 6lbs and returned to find 37mm of sag.
The worksurface is at 17 degrees from vertical, but not convenient to alter.
That said, visually friction does seem to be a factor. My sled base is UHMW and the worksurface is primed ply.

I ran down to the same location and verified that my 26lb sled sees 48mm of
sag. I moved and added another 10.5lbs and returned to that spot and found
42mm of sag. Again moved and added another 6lbs and returned to find 37mm of
sag.

very interesting, so another 16 pounds will shrink the error by half.

The worksurface is at 17 degrees from vertical, but not convenient to alter.
That said, visually friction does seem to be a factor. My sled base is UHMW and the worksurface is primed ply.

we’ll have to have someone who can tilt things (even if it’s by putting books
under the back legs of the machine) try adjusting the tilt.

the other thought I have is:

once we have the basic calibration done, can we pull a similar triangulation
trick to calculate the weight of the sled (say by doing two vertical cuts, one
in each of the bottom corners and measuring the space between them) to figure
out how much chain sag we have and compensate for it.

In the meantime, it looks as if the triangular kinematics probably gets us to
within 1mm of ideal about double the initally desired 1/64" or 0.4mm

it looks like adding weight to the sled can increase the accuracy to the target.

David Lang

I want to make sure I understand this line. With the kinematics, what do you think our current accuracy is?

yOn Wed, 25 Oct 2017, Matt Nelson wrote:

I want to make sure I understand this line. With the kinematics, what do you think our current accuracy is?

it all depends on the acuracy of your measurements. There are a LOT of
measurements that need to be accurate to make the stock kinematics work. If they
are all measured accurately, then you shoudl be in similar shape.

But the calibration routine for standard kinematics is just tweaking one of the
many variables. So if you build the machine and it cuts a square to start with,
you are good, if the square doesn’t come out right, we don’t have a way to have
you get the machine accurate everywhere.

people have reported being off by inches in some cases.

David Lang

to be clear, other people are getting pretty accurate cuts, but we don’t have
good info on how accurate.

David Lang

Thanks for the info about accuracy. I’ve been very careful with all my measurements, so I’m expecting good accuracy. I’d be very happy if it was within 1mm.

1 Like

The calibration process reiterates until it gets to within 0.5mm difference between a 600mm vertical and a 600mm horizontal. That’s pretty good.
My experience is that making certain that the motors are mounted securely, that the arms are very rigid and that the work area sheet hasn’t bowed very much are important mechanical considerations. I’m still learning about the software side, but not using too aggressive a feed rate, cut depth or overlap distance seem important as well.

1 Like

The problem is that this is just that it’s accurate at that point on the work
area. The calibration routine only tweaks the distance between the chain mounts
to get the square accurate. If you have errors in the distance to the bit, or
distance to the CG of the sled, the calibration steps haven’t fixed that, just
introduced enough counter-error to make the box square in the center of the
worksheet.

However, the different types of errors map out to different patterns of errors
across the work area, so as you move away from the calibration area, the
different errors don’t cancel themselves out and you start to see issues.

how bad this is depends on how far off the other measurements are.

I posted this earlier, but can’t find it now.

dimensions that matter are:

Traditional kinematics

1. distance between the motors
2. distance down to the (0,0) point from the motors
3. length of chains
4. distance between chain mounts on sled
5. distance from chain mounts to router bit
6. distance from router bit to CG of sled

Triangular kinematics

1. distance between the motors
2. distance down to the (0,0) point from the motors
3. length of chains
4. distance from bit to chain mounts on sled (as an ‘error’ to the chain length)

distance between the motors can be measured fairly accurately.

distance down to the (0,0) point [1] is hard to measure (but the triangular
calibration routine can calculate it), especially for a traditional frame, it’s
a little easier with a top-beam frame.

length of the chains we measure out by how far we have rotated the motors and
how many teeth on the sprocket. There is error here based on if we started with
a sprocket point straight up (how accurate is straight up), and error based on
the chain ‘stretching’ as the clearances between the parts of the chain are
taken up. This is down in the thousanths of an inch per link, but it starts to
matter as we have lots of links in play (in the area of 700 links)

beyond that, things get messy.

where the chains mount to the sled is hard with the traditional mounts because
what matters is where the chain bends, and you also need to shorten the
effective length of the chain as you have parts of the chain extending beyond
where it pivots.

on triangular kinematics, this is much easier and everything can be viewed as an
error in the length of the chain (although, centering the ring/pantograph with
the bit can introduce error) and discovered via calibration.

the other diemensions are impossible to automatically measure.

during the traditional calibration, the only thing that is being changed is #4,
so if #2, #5, #6 are off (or the amount of chain used at the mount is off), we
cannot fix them

David Lang

[1] the [0,0] point’s actual location is not critical, what is critical is that
we know how far below the motors it is and that the user of the machine knows
where it is, and has some control over it

4 Likes

That’s a very good summary, it would make a very good wiki page.

1 Like

I expsnded this to make this wiki page

It could really use some pictures/diagrams to show the different options, but I
don’t have time to do that right now

Comments?

David Lang

4 Likes

Digging up this thread. For triangular kinematics, has an auto-calibration scheme such as what @dlang described at the beginning of this thread been developed?

I’ve been playing with this idea. I started with the concept of trying to determine the motor spacing by having the user measure the vertical distance between two cuts. To do this, I took the triangular kinematics formulas used to calculate chain length and attempted to solve them in reverse, such that _xCordOfMotor and _yCordOfMotor could be determined. However, with the updated triangular kinematics equations accounting for sprocket geometry, this process led to some complex equations which I was not able to solve.

With that, and because this is not involved in the real-time operation of cutting, I decided to try an iterative approach instead. I designed an algorithm which would extend both chains a certain amount (this would likely have to be completed by the user pressing a button to extend the chains to the desired length), such that when connected to the sled the sled is at the top of the workspace. A cut would be made in place, then the user would move the sled vertically down to the bottom of the workspace and another cut made. The distance between centerpoints of these two cuts would be measured. This measurement, combined with the known chain lengths for each cut, would serve as the inputs to the algorithm to determine the motor spacing.

I formed a very simple algorithm to solve this. It started with assuming the top cut defined position (0,0) (this can be changed later, as desired), and then used a seed position for the right motor of (1,1). As the cuts were performed in the horizontal middle of the workspace, due to both chains being extended the same amount, only one motor position needed to be solved for. I then had the algorithm compute the expected chain lengths for this motor position. The calculated chain lengths were compared with the actual chain lengths for each cut location, and based on the results the motor position was updated. If both estimates were too low, the motor X and Y coordinates were each increased by 50% of the average chain length error. If the top chain estimate was too short and the bottom chain estimate was too long, I assumed the estimated motor position was too high and decreased the motor Y coordinate by 50% of the average chain length error while keeping the X coordinate static. Similarly, if the top chain estimate was too long and the bottom chain estimate was too short, I assumed the estimated motor position was too far to the side and decreased the motor X coordinate by 50% of the average chain length error while maintaining the Y coordinate. If both chain length estimates were too long then both coordinates were reduced.

I ran a test case of this using actual motor coordinates (3413, 1857). 561 iterations later beginning at (1,1) and the estimated motor position was (3412.995, 1857.007).

Next, I turned my attention to the rotationDiskRadius variable. Like David mentioned, if you performed three cuts (one at the top, one in the center, and one at the bottom), you would have two data points of the distances between them. I tried this, using the chain lengths of the top and bottom cuts to calculate the motor position, and then referencing the chain length of the center cut to calculate the rotationDiskRadius. The theory is, if the rotationDiskRadius variable was lower than the actual radius of the linkage assembly, the calculated chain length to this middle cut would be lower than the actual chain length. I used a feedback loop on this chain length to calculate the rotationDiskRadius while the motor position was being calculated as well.

This proved to be a bit more challenging. I had to scale down the feedback loop for this variable, otherwise it tended to become unstable and run off to very high values. With enough tweaking, I got it to run reliably. The downside of this is that it takes a lot more iterations.

My test case was a motor position of (1524, 724) with a rotationDiskRadius of 103.4. I began the motor at (1, 1) with a rotationDiskRadius of 1. After 3,842 iterations the estimated motor position was (1523.951, 723.967) with a rotationDiskRadius of 103.324.

Overall then, the theory checks out. However theory and practice can be quite different. My primary concern comes from chain sag. The accuracy level of the chain lengths required to produce these results was 0.001mm. Using the last simulation with an accuracy of 0.1mm the estimated motor position was (1519.147, 720.700) with a rotationDiskRadius of 97.635. This gives a motor position error of (-4.853, 3.300) and a rotationDiskRadius error of -5.765. While it’s still in the right neighborhood, you can see that even small errors in chain length compound to substantial errors in the predicted dimensions.

All my simulations were done in Excel as I don’t have my Maslow yet, so I cannot comment on how much of a factor chain sag or other aspects would be. What I can say though is that from my simulations, if the rotationDiskRadius value was entered manually then the accuracy of the motor position becomes better than 0.4mm based on a 0.1mm chain accuracy. Given what I have seen doing this, and based on the relatively limited number of linkage kits compared to the drastic difference in motor position across different Maslows, I would prefer to use a static rotationDiskRadius and focus all the accuracy we have on motor position.

What do you guys think?

3 Likes

nobody has followed up on this, thanks for checking.

what about instead of increasing/decreasing the chain length by 50% you try setting it to what the chain length should be for the position actually cut (or 90% of the difference between what it thought it was and what it ould have been for that cut)

One interesting thing about the calculations being done in radians, it actually forms triangles and you can calculate where the top of the triangle would be if the chain wrapped around the sprocket were to be straight (if you dig into the math enough to make your head spin, you will see that it’s doing exactly that in the normal kinematics)

by the way, your testing is complicated by the fact that the chain lengths are incorrect, see What is correct chain pitch? and Whats inside the gearbox/motor? so that you can change the encodersteps variable and eliminate a 0.4% error that you didn’t know you had.

2 Likes

Using this approach you can’t set the chain lengths directly as they are calculated from the estimated motor positions, but you absolutely could use a larger step percentage to speed up the convergence. During my initial trials I used a very large step size and had issues with stability, so I was intentionally using a small step size to avoid those issues. There is definitely room for further tuning however.

On the topic of the triangles, I’ll have to investigate this further. If you try to accurately calculate the chain length with the sprocket portion of the chain straight then you still have the issue of unknown chain angle. You can remove this by assuming tan(x) = x, where x is the angle of the chain below horizontal. This is approximately true up to about pi/4, at which point the approximation breaks down. However, the chain angle from horizontal can easily exceed pi/4. Granted, the errors are not massive, but a couple mm error is possible, particularly in the bottom corners.

I’ve been catching up on the encoder steps per revolution topic. That’s a great find! Good job. I’m suspecting that will make a substantial difference in accuracy.

this is why you don’t try to calibrate in the bottom corners

do the calibration in the top half of the center of the workpiece (i.e. 0,0 and
0,+20" or so) that way the chain angles stay in the good range, and you can also
calculate the height of the motors above the work area.

1 Like

The concern I have is that as the kinematics formulas get more accurate, say accounting for chain sag or other effects, the math for the calculation of the motor position becomes increasingly more complex. An iterative approach would allow simpler incorporation of future improvements to chain length calculations.

As an example, I put together an Excel calculator. Basically it has someone make two cuts/marks in the workspace, measure their distance, and then enter the programmed chain lengths required to get the sled to each position. This algorithm statically runs 1000 times, although if implemented criteria could be used to determine when to stop. Additionally, it could easily incorporate chain sag calculations or other aspects as well.

The calculator is here: MaslowTriangularCalibration v1.0.xlsx (158.3 KB)

Note that I haven’t tested this at all, so I would not say this is ready for inclusion in the GC code. However, if it works then it would be a possible method of providing an automated calibration routine for triangular kinematics.

If anyone has time and would be able to test the calculator to see if it gives approximately correct values, I would appreciate it!

The maslow is slow, doing 1000 cuts is not going to work.

The concern I have is that as the kinematics formulas get more accurate, say
accounting for chain sag or other effects, the math for the calculation of the
motor position becomes increasingly more complex. An iterative approach would
allow simpler incorporation of future improvements to chain length
calculations.

Anything with the triangular kinematics is SO
much less complex than the traditional kinematics (which could take hundreds or
thousands of iterations to try and figure out the chain length) that there is
pleanty of time for added calculations like chain sag.

As an example, I put together an Excel calculator. Basically it has someone
make two cuts/marks in the workspace, measure their distance, and then enter
the programmed chain lengths required to get the sled to each position. This
algorithm statically runs 1000 times, although if implemented criteria could
be used to determine when to stop. Additionally, it could easily incorporate
chain sag calculations or other aspects as well.

chain sag will have to be calculated on the fly because it will vary based on
the length of the chain and the tension on the chain

I don’t like the idea of making a separate thing in excel, the calculations
should be done in ground control.

If you look at my formulas at the top of this section, they are doing roughly
what you are talking about, making to cuts that should be at known positions and
then measuring the distance between them and solving the math.

I’ll take a look at your spreadsheet later, but how close are your forumlas to
mine? can you document how you came up with your forumulas?

Sorry for the confusion. Two point cuts/marks are made, the distance between them entered, then the algorithm iterates 1000 times to determine the motor coordinates. It’s more clear in the Excel file.

The formulas used here are literally exact copies of the triangular kinematics formulas. That was part of the goal, in that as the triangular kinematics equations are updated with things such as chain sag this would be updated with it. No reverse calculations required.

Also, the intention would be to build this functionality into GC. But for proof of concept (and because I don’t have a Maslow yet), I made it in Excel.

2 Likes