If you assume that there won’t be much difference in x error between measurements done at 20 inches above center, 20.5 inches above center or 19.5 inches above center (just as an example), then yes, you could build a calibration matrix under the assumption the reading is at 20 inches above center… I tend to think that’s a valid assumption.

# Optical Calibration Demo and Three Hours Working on a Bug

**Joshua**#449

Something like this. Estimate the x,y coordinates of each tick on the tape-measure using assumed machine parameters. The x,y coordinates would be the intersection between the mark on the tape-measure, and the top edge of the tape-measure. Estimate the distance between the ticks using the current machine parameters. The difference between the estimate and the actual forms the basis for the calibration. The goal is to find some delta in machine parameters which makes these differences all zero. The output would be like a delta from the current calibration. As long as enough information is included, (horizontal, vertical, and diagonal), the calibration should be just an optimization.

**johnboiles**#450

If anyone is interested in looking at the firmware implementation of optical calibration correction. I pulled it out of @madgrizzle’s fork into this PR

Would be great to have some more eyes on this!

**Joshua**#451

hey @johnboiles, I have made some changes to kinematics.py, to include a chain tension calculation, the catenary equation for chain-sag, and a chain stretch calculation. I am very rusty on my cpp. How difficult would it be to mirror those changes in the firmware?

The github link is here: https://github.com/schmittjoshc/MaslowCalibration/blob/master/kinematics.py

**madgrizzle**#452

Any chance you could post an explanation of the derivation of the catenary equation?

**Joshua**#453

I referenced the wikipedia page here: https://en.wikipedia.org/wiki/Catenary. Go to the section labeled “Analysis”. It goes through the whole derivation. Toward the end of the “Analysis” section, there is a “Determining Parameters” subsection. This covers the equation we want to use.

## Here is the content from Wikipedia:

I couldn’t get it to display very well. Sorry. You’ll have to follow the link to view

### Determining parameters

In general the parameter a is the position of the axis. The equation can be determined in this case as follows:[53] Relabel if necessary so that *P* 1 is to the left of *P* 2 and let h be the horizontal and v be the vertical distance from *P* 1 to *P* 2. Translate the axes so that the vertex of the catenary lies on the y-axis and its height a is adjusted so the catenary satisfies the standard equation of the curve

and let the coordinates of *P* 1 and *P* 2 be ( *x* 1, *y* 1) and ( *x* 2, *y* 2) respectively. The curve passes through these points, so the difference of height is

and the length of the curve from *P* 1 to *P* 2 is

When *s* 2 − *v* 2 is expanded using these expressions the result is

so

This is a transcendental equation in a and must be solved numerically. It can be shown with the methods of calculus[54] that there is at most one solution with *a* > 0 and so there is at most one position of equilibrium.

## For Maslow:

We know the parameter “a” a-priori because it is a function of the horizontal tension and the chain-weight. So, we need to re-formulate the equation to solve for “s”, the catenary length.

## How to use the Equation:

However, it has to be manipulated to solve for s.

Thoughts on Chain Sag Calculation

**madgrizzle**#454

Have you plotted it out with real world data to see the values you get at different points on the board?

**Joshua**#455

I have validated it against the online calculator for a few different points. I have printed the compensation during the calibrations. However, I haven’t plotted compensation as a function of position on the board.

**madgrizzle**#456

I get a headache looking at it Is this basically the same thing we worked on back in September?

But with a few tweaks added in? I had incorporated what we worked on back then into firmware and activated using it if you entered the chain sag value as a negative number. I can take your python and convert it to cpp if that’s what you need if you want to test it out (by entering a negative chain sag value). Honestly, there’s very little difference between the python code and the cpp code… just some brackets, semicolons, you don’t need to name the math routines.

Is chain elasticity and important factor at this point to test out (that might require a more intensive change to add another setting… it could be hard coded to something if you’d like).

**Joshua**#457

I get a headache, too. Yeah. That is what I am talking about. I have implemented it in my branch of the kinematics.py class. I was able to validate the chain-tension calculations, etc. I validated that the horizontal components of the chain-forces were equivalent, for the left and right chains. I validated that the vertical components of the chain-forces (left+right) sum to the weight of the sled. I tried to run an analysis of displacement vs. position. I ran into an issue. I am not sure what the cause of the problem is. Sometimes, the calculation predicts a chain-length that is obviously incorrect. It is not ready for prime-time, yet.

**madgrizzle**#458

Do you think you could bake it into the simulator and see what’s going on? We shouldn’t put it in the firmware until we are confident it won’t result in bad chain lengths. Nothing is more frustrating than getting a message indicating that the controller could not determine the position of the sled and you need to reset the chains to known lengths…

**Joshua**#459

I haven’t dug into the Kivy part of GC, so that will be an additional hurdle. I may need help.

Agreed. That is what’s going on right now.

**dlang**#460

this is the sort of problem we were running into when we were using the

incorrect calculation (one that assumed that the low point in the arc was

between the endpoints), the forces still balanced out, but the length

calculations were useless.

David Lang

**Joshua**#461

Here it is. Chain-sag displacement plotted against position on the worksurface, as predicted by the catenary equation. This shows the magnitude of how far the catenary equation displaces the sled, the geometric distance the sled moves as a result of chain sag.

Holey Triangular Calibration

**madgrizzle**#462

so ~6mm displacement at the corner? I don’t know what the true value should be, but at least this seems reasonable. What chain sag compensation values have you found the calibration routine to come up with? Correct me if I’m wrong, *ideally* the value should equal the weight of the sled.

**Joshua**#463

It hasn’t been all that good when calibrating sled weight. If I start with a sled weight of 20 lbs, I end up with a sled weight of 10.4 lbs, which is clearly incorrect. I believe this is consistent to your experience.

My hypothesis is the calibration is compensating for very small measurement differences. When I look at your original measurements for the 5 point Holey Calibration, the bottom measurement is 1 mm shorter than the top measurement. I believe the calibration reduces the sled weight by 50% to compensate for this 1 mm difference. I would like to test to confirm. If this is true, sled weight isn’t a very good candidate for calibration, because it is so sensitive.

**madgrizzle**#464

This is the latest optical calibration run with hand entered parameters (no real calibration had been done)

### Actual measured Y-Error

### Curve fit to a*x^2 + b*y^2 + c*x*y + d*x + e*y + f (please ignore the trace colors, they are inverted)

So I’m thinking a different curve might be needed as the “curve” doesn’t really match all that well… especially along the left and right edges (0 and 30 on the x axis)… It does smooth out the data at least.

The calibration near the top is pretty good (6 inches from top the accuracy is ~ 0.5 mm) but the bottom corners still have issue (~1.2 mm) and I’m think it might be more of a precision issue (friction, sled balance, etc.)