Hows this going? Hasn’t been this quiet in a long time .
I just got power back last night. Still cleaning up after the mess the hurricane made.
1 Like
Oh sorry to hear you were hit. All my best
Besides being inconvenienced, I made out exceptionally well… neighbor three houses down has a tree bifurcating their house. I had two piles of branches and twigs to rake up. I’m honestly amazed.
6 Likes
A suggestion that a friend of mine had, what if you just stretch a tape measure
across the machine, then have the camera read the tape measure.
move the tape measure up and repeat.
then put the tape measure vertically and repeat
you won’t get a completely accurate vertical measurement while reading the
horizontal tape, or horizontal measurement while reading the vertical tape, but
I think it’s possible to do, and it would be much faster to scan across the tape
and note the movement of the marks vs the camera.
thoughts?
David Lang
I think it depends upon what you goal is. If you are just trying to measure error, and see how well your setup performs (i.e., testing your calibration, different sled weights, sled materials, linkages, etc.), then I think it’s doable
though it would be pretty challenging to code… reading a tape measure is a bit more complex than recognizing a lone square. But, if you are trying to use that error for calibration, then I think you need accuracy in your vertical measurement when scanning horizontally, and vice versa.
This is a really good idea. I believe the information can be used in a calibration. Even though the information is not absolute (you don’t measure the absolute (x,y) coordinates at each point), I believe the information is usable for a calibration. This kind of thing, in terms of using information that isn’t absolute, is what I have been wanting to do as a curve fit.
Right now, I would like to work through a curve fit using simpler data, but if we can visually parse the tape measure at its increments, I believe I can build a calibration using the data.
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.
1 Like
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.
1 Like
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!
2 Likes
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
1 Like
Any chance you could post an explanation of the derivation of the catenary equation?
1 Like
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.
Have you plotted it out with real world data to see the values you get at different points on the board?
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.
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).
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.
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…
1 Like
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.
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
1 Like