Optical Calibration Demo and Three Hours Working on a Bug

[johnboiles]

We can add a vertical offset to HomingPosY and shoot low and then have it move up to see if this affects things. Can try tonight.

I think this is a good practical thing to try

I’ll look at vistaprint tonight. Could you send me any details about your order and maybe also the file you provided them? I want to make sure I get exactly what you got

[madgrizzle]

I’ll look at vistaprint tonight. Could you send me any details about your order and maybe also the file you provided them? I want to make sure I get exactly what you got

For some reason I can’t find the file… it might be on another computer and can check tonight. Otherwise, I’ll just recreate it. Looks like Vista Print’s sale is off… now $80 for the banner…maybe can find a coupon code…

[Jatt]

VPEXTRA20

This code is only valid until october 3, good for 20% off anything at vistaprint.

[dlang]

the vibration does help, so there is less of a problem in actual cutting than in
your measurement. But it can be a problem in cutting as well.

David Lang

[dlang]

if you have someone with a suitable CNC nearby, I’d like to have you have them
cut a grid for you in melamine or something slick like that.

it’s expensive (I’ll help cover the costs), but I think having the comparison
with a slick suface like that would be good.

David Lang

[pillageTHENburn]

I wonder how the vibration of the router affects this in practice. My sense is that vibration would help shake loose any sticking friction and help keep the chain tension more consistent.

A half-serious idea: what about bolting a little rumble motor either to the work area or to the router sled.

On a technical level the cause of this problem is similar to the cause of the wobble lines that the ring causes. Here it’s a static vs kinetic friction issue. Static friction is “stronger” than sliding friction; this is why antilock brakes were invented. Friction between your tires and the road is much higher when your tires are not sliding (which is kinetic friction) but instead rolling (effectively static friction). Ideally, with Maslow, we want only kinetic friction during moves/calibration with no moments of static friction. But brief stops allow the sled to “stick” with static friction…

I know it takes time to compute the registration squares but if the computation could be done on the fly and the sled never actually stops I bet you’d see much less of that periodicity. I don’t even know if that is technically possible since it’s using data from each point to calculate where the next should be (right?). Anyway, just a thought.
-Logan

[madgrizzle]

Interesting theory… but I’m afraid you are likely correct that it can’t be adjusted in realtime or, at a minimum, be practical to adjust in real time without moving the homing routine to the controller… and the Arduino can’t manage that.

[madgrizzle]

@johnboiles, I reworked the settings so they all get stored in their own section except for the enabling the calibration and switching between interpolation and curve fitting. So, when you go into the program, you will see the default values. It should retain in “Computer Settings” your original values and calibration matrix if you want to edit groundcontrol.ini to transfer them over.

[johnboiles]

Note, I still do not believe that this will result in a usable map to correct
out errors, but I think it’s a good way to measure accuracy with different
calibration settings and algorithms.

I think our hope is in the curve fitting or some other kind of averaging at this point. It seems like the individual measurements are probably too noisy, so just straight linear interpolation between points might not be the best.

I suppose ideally we’d have some form of curve fitting that would fit curves that represent the physical ways poor calibration can affect the motion of the sled. Perhaps we could even work backwards to figure out what the ideal calibration settings are (especially if sled weight is an input into the routine). Though I’m out of my depth with this math.

if you have someone with a suitable CNC nearby, I’d like to have you have them
cut a grid for you in melamine or something slick like that.

Thanks for the offer to pitch in, I’ll look around and see what I can find!

Here it’s a static vs kinetic friction issue. Static friction is “stronger” than sliding friction; this is why antilock brakes were invented.

Thanks for this explainer on static/kinetic friction, it adds some good language to this discussion.

if the computation could be done on the fly and the sled never actually stops I bet you’d see much less of that periodicity.

I think that’s true, but I’ve noticed my camera has significant motion blur, even though the Maslow moves pretty slowly. Another potential fallback is @madgrizzle’s method for calculating offset to the center of the square. With this method, the image is rotated so that the square is upright, then an x,y offset is calculated from the center of the square to the target point (using the width of the square to determine how pixels map to physical space).

Interesting theory… but I’m afraid you are likely correct that it can’t be adjusted in realtime or, at a minimum, be practical to adjust in real time without moving the homing routine to the controller… and the Arduino can’t manage that.

Probably not practical for this project (and maybe not practical ever), but we potentially could move the motor control algorithm during homing to GroundControl. We would expose the PWM values directly to GroundControl via serial commands and hook up our control algorithm to take the position offset of the square directly. Not that it would necessarily be a big improvement, but could potentially making homing much smoother and maybe faster. It might be able to eliminate small, discrete moves. Though really not sure if it’d help

I reworked the settings so they all get stored in their own section except for the enabling the calibration and switching between interpolation and curve fitting.

Great! Definitely something we would have wanted to do at some point!

Any luck on finding that 4x8 calibration file? If not, don’t worry about recreating it. I’ll redo it in Illustrator tonight and maybe send to you to double check before I make the order.

[madgrizzle]

We would expose the PWM values directly to GroundControl via serial commands and hook up our control algorithm to take the position offset of the square directly. Not that it would necessarily be a big improvement, but could potentially making homing much smoother and maybe faster. It might be able to eliminate small, discrete moves.

I think our issue (if we really have one) happens during the very small adjustments. Anything we do to eliminate them will improve the system. But, unless you plan to adjust the target in the middle of coordinatedMove, you’d have to send a gcode move command prior to the controller finishing the previous one. I’m not very hopeful. I’m almost done with rerunning the calibration with a 7mm lowering of the target position… will see how that turns out.

Any luck on finding that 4x8 calibration file?

Yes, thanks for the reminder. It’s in the repo:

madgrizzle/GroundControl

[madgrizzle]

I’m almost done with rerunning the calibration with a 7mm lowering of the target position… will see how that turns out.

The calibration run failed on the last row and I think the vacuum hose I attached to the sled might have caused it issues… the bottom is rather low to the floor. But I save the results to csv nevertheless… kinda nice the software is non-blocking.

[madgrizzle]

The biggest Y error issue is at the top of the board. I don’t have a skirt and the sled doesn’t lie perfectly flat (has some wiggle to it). I’m not really seeing periodicity in the data.

[johnboiles]

Neat! So we can say the drop 7mm thing is an improvement right? I don’t see any pattern in there either, just normal noise

[johnboiles]

Looks like Vista Print’s sale is off… now $80 for the banner…

Looks like Vista Print is in a perpetual sale for first time customers. When I looked at the site yesterday it applied an immediate discount code of 25% with code VPSUMMER18. Today the immediate code is VPFALL18. I wouldn’t be surprised if this is always the case

I’m going to do express shipping though so that eats up my savings. But my test pattern wouldn’t make it through the weekend I’m pretty sure.

[dlang]

The top center is where errors in chain length (from any cause) result in the
largest movement of the sled.

David Lang

[johnboiles]

The top center is where errors in chain length (from any cause) result in the
largest movement of the sled.

Definitely makes sense, thanks for sharing. I for one would love a writeup from your deep experience about what causes different types of errors in different parts of the board. Could be helpful to folks in the community trying to reason about why their machine isn’t dimensionally accurate. E.g. I assume chain sag I imagine affects the X in the corners etc. For this, it would be helpful to try to use this routine to try to figure out the greatest sources of inaccuracy. Let me know if this already exists in the forum somewhere.

[madgrizzle]

Perhaps we could even work backwards to figure out what the ideal calibration settings are (especially if sled weight is an input into the routine). Though I’m out of my depth with this math.

If the algorithm that is used by Kinematics::triangularInverse is representative of the machine, then, yes, I think we can come up with calibration settings. Sled weight is factored in by the chain sag value. It’s a constant though and doesn’t account for variability (i.e., hose weight)…Regardless, I’m not confident we have the correct model.

I took the calibration data from my previous runs (not this last one from last night) and put it into the Holey Maslow optimizer to see what results it comes up with. Takes a lot longer to run because of the number of test points (31x15) vs 8, so I limited it to 100,000 iterations. It came up with values, but many of the test holes still had significant errors. In essence, the Holey Maslow program tries to ‘curve-fit’ the data to the algorithm… I’m checking for mistakes in my code, but here are the results nevertheless:

[madgrizzle]

Here’s a comparison of measured values and curve-fit values:

[johnboiles]

Those curve-fit values look nice! We’re probably about ready to make some cuts with it right and see how they come out?

Once I calibrate a full sheet with my vinyl banner (probably Friday), I’ll use my pencil collet and draw some shapes to see how dimensionally accurate they come out.

[madgrizzle]

, I’ll use my pencil collet and draw some shapes to see how dimensionally accurate they come out.

I’m gonna print that out tonight!

I wonder if could be spring loaded so you didn’t have to get the z-axis precise. Ideally I would be able to put a sheet of paper over my banner and draw on it. I worry that if the z-axis is too far down, it would put too much pressure on the paper and mess up the banner