Does the sled “stop” at each point? Is the cause of some at least of the bouncing points static friction, breaking it loose from a stationary point? Pulling a little sag out of the chain, and then a small “lurch” forward?
If you think it may be the sled against the vinyl, (I hate to say this), but how about a little “baby powder” dusting of the sled and vinyl to see if it changes anything?
Yes. I think it will be incredibly challenging to do all of this in realtime. So it moves, analyzes the image, and then issues new move commands.
Just to confirm:
The axes are in inches from the 0.0 centerpoint?
The values in the spresdsheet are in mm?
For X, a negative value means “left” of the target point, a positive value is to the right of the target point?
For Y, a negative value means “below” the target point, a positive value is above the target point?
Thanks
I can look in to it.
What kind of information do you want in the QR, Just the location (x,y) or (row 4, column 5) that makes the complete sheet resizable for other maslow dimensions.
Also the quadrant? Or is there a hartline in the pattern?
What i mean, is there 1 cube that is the center of the pattern and count from therecalculate from there.
I followed the discussion but mostly after 23h 
You hava function fingerprint in mind? I have not looked at the current code yet.
Almost. The axes are the test point index. The test points are ~3 inches spaced, so to find the distance from the center point you can just multiply the test point index by 3. So the point for -15,4 is actually 45 inches to the left of the center point and 12 inches above the center point.
My brain gets this confused on this on a regular basis. I’m fairly certain these are ‘correction values’ – that is, the additional movement required to move the machine to the center of the test point. So I think it’s the opposite of what you say – a negative X value means that the machine was to the right of the target point without calibration and a negative Y value means that the machine was above the target point without calibration. @madgrizzle please correct me if I’m confused.
Yeah I think just the row and column would be enough, but maybe @madgrizzle has other ideas.
Yeah there’s a square in the center, the 0,0 square. There are 15 columns both to the left and right of it, and then 7 rows above and below, for 31 colums, and 15 rows total. Each point is spaced 3 inches apart.
Sounds accurate to me.
I tried plotting the curve fit values from my spreadsheet.
The Y-error curves look pretty good
But the X-error curves look way too linear
Is this to be expected? Could we add more degrees to the polynomial to get it to fit better? (I know very little about curve fitting)
I’m sure its possible, but not sure how to do it. I adapted it from here:
I know it’s likely moosely ignorance, but isn’t the best shape for both the x and y curves a straight line?
I’d consider the x-error curve showing the current thinking that there’s problems at the travel limits, where the y-error curve points at kinematic math errors. Or have I been drinking too much swamp water?
@madgrizzle, also hoping your home and shed came through with minimal damage
That looks fairly reasonable and quite useful. What does concern me is not so much the linearity of the X-error curves, but rather that they converge nearer to 5 than to 0. I would have expected the minimum error to be at the dead center of the range.
That’s definitely the ideal shape. If you have perfect calibration you’d expect straight lines near 0 across the work piece. But the goal of this process is to correct for miscalibration. Errors in calibration end up making nonlinear shapes because of the kinematics. We’re trying to figure out how to represent those nonlinear errors in a way that also smooths out any noise from individual measurements.
Looking at the graph of actual values, I’m unable to eyeball any meaningful point of convergence. I think the convergence at test column 5 (15 inches right of center) is just because of noise in the measurements and the over-linear fit to the nonlinear curves.
That said there’s no reason to necessarily expect all x errors to converge to 0 at any point. For example if the chain lengths were different you would expect some x error in the middle of the board.
Again, my math classes were in the slide rule days and not used a whole lot since (meaning they’ve gotten fuzzy) but the regular non-linearity suggests that it’s a math or configuration error. I’d suspect you’ve got the config under control so rather than come up with a correction matrix isn’t the first step to sort out the calculations and think about corrections after that?
Of course, living in a swamp means I’m naturally all wet 
X and Y are not separate, errors in the math affect both.
play around with the simulator in ground control and look at how errors in
different things affect both X and Y
I’d be interested in seeing plots of the residuals, that is (X_actual - X_curvefit) vs. Column and (Y_actual - Y_curvefit) vs. Column. Residual plot shows you what part of the data isn’t captured in the curve fit.
Got that, but a series of nice curves looks like a kinematics firmware issue that should be solved before applying adjustment matrices. It looks too regular to be a mechanical issue like the sled sticking.
I’d be tempted to play with calibration numbers like the motor spacing (or something suggested by wiser non swamp dwellers) and see what happens (write down the original values, of course), and turn chain saw off and on. Does it get better or worse, and what happens going the opposite direction? Then use that to poke around in the positioning code if there’s any meaningful results.
I would too! My spreadsheet is linked above and publicly accessible. You should be able to duplicate it and play with the values. The ‘10/6 Averaged’ sheet is where I have my curve fits (at the bottom)
I’ve done this a little bit with my motor spacing. I could see noticeable improvements in the calibration after changing my motor spacing to the value determined with a tape measure. I’m planning to hook up the simulator to make the same style graphs we’re looking at here so that I can try to recreate the same shapes in the graphs. That way I can better understand what to change and maybe better understand the way error in measurements affects the kinematics
I did another cut last night (pictured left) with optical calibration (interpolation-mode) enabled. I did the same cut as I did last week (pictured right) to complete another vertical support for my friend’s table.
I first drew everything out with my router pencil collet, and measured the height, the width at the top, and the width at the bottom. All dimensions were spot on. However, when I did my cut, the top width was ~3/64 (1.19mm) short and the bottom width was ~1/8" (3.175mm) short. The height was spot-on within my ability to measure.
I was pretty discouraged as this was a step backwards in accuracy from last week. For this run I averaged 3 calibrations together so I was hoping for an even more accurate cut. Then, after the cut, I noticed that my router wasn’t clamped in. I had forgotten to flip the tab on the router base that holds the router more tightly, so there would have potentially been significant jiggle room in the router base. I wonder if this is what could have caused the inaccuracy. I can sorta visualize the inward forces as the router moves outward on the piece pushing the router inwards, creating a cut that’s dimensionally too small.
Does anyone have experience or intuition about how a loose router might affect dimensional accuracy in cuts?
I somewhat got started on this tonight. First step was to hook up some easy-to-refresh graphs to my existing calibration csv files (done in madgrizzle/groundcontrol#6). Next step will be to hook that up to the output from the simulator. Using a nice color gradient from D3.js also makes it a lot easier to follow a row across the graph.
This could maybe also be a nice pairing with @madgrizzle’s webserver feature in groundcontrol
open the clamp and wiggle the router side to side (and try to rotate it,bit
down, top up, etc), I’ll bet that you will see substantially more than 1mm of
bit movement from doing this.
I definitely do. Plenty of wiggle to account for this error.
