I think the linear error is what we see from the slope of the graphs. Typical Maslow calibration errors tend to be a more nonlinear shape right? I would expect a linear graph like this if the X-dimension had a calibration pattern that is a little smaller than expected (which is definitely the case when I measure it)
If there was such an issue, would it not (and I don’t know so that’s why I’m asking) show that if when you scan from left to right you see a down slope then when you scan from right to left you would see an up slope?
If its linear, then I would suggest everywhere something gets multipled by 3 * 25.4, it gets multiplied by 3 * 25.4 * xScale. Then the xScale (and yScale) would also be sent as firmware keys to the controller and the same math is done there. You could do fancy compensation of the calibration matrix in GC, but I think we can do it in the controller without much of a hit.
I don’t think so. Assuming we dial in the center point pretty well (as it seems we do in the graph above), I think that a pattern that’s too close together (<3in on center) would result in positive correction values for the left calibration points (square is to the right – closer to the center point than it should be) and negative correction values for the right calibration points (square is to the left – closer to the center point than it should be).
When you have a moment, it’d be interesting to measure your vinyl banner. I wonder how well-spaced your squares are.
I see what you mean… I think you are correct about that. Any scaling will definitely need to be based upon 0,0 being 0,0 and then working out from there… I’ll go look at my pattern…
Cool I’ll go ahead and wire in my scaling fields for my test tonight.
I’m wondering if we could source a common sign sheet in 4 x 8 material , PVC, and place a vinyl cut pattern on it as a calibration target. This would be obtainable from just about any sign shop.
I’m dead on vertically but a 1/4-inch long from the left edge of the left-most square to the left edge of the right-most square. My squares appear to be 0.61-inch x 0.61-inch… that’s not a big deal, but the 1/4-inch scale issue is something that needs to be mitigated. I’ll modify settings and the firmware to work with scale factors in the meantime.
Do you need to modify the firmware? Can’t we just adjust the calibration values in GroundControl by the calculated scale offset?
Meaning, via homing we determine that a square is [1, 2] mm from the machine’s expected point for that calibration value – we can add to the correction value based on the scale.
For example, for square at -2,0 (second square to the left of the home square 0,0). If the x offset is determined by the routine as 3 mm (square is closer to home than it should have been), and the x scale is 0.98 (test pattern is smaller than expected), then the correct offset (with scaling) could be calculated with something like this:
[actual offset] = [measured offset (3mm)] + (1- [scale (0.98)]) * [index (-2)] * 3 * 25.4
I’m not very confident in my math, but I think there’s something like this that should work.
Edit: now that I write it out, I think it’d be more intuitive to just input the X and Y spacing (e.g. 3.023in) or something like that. Maybe i’ll make that change next time I’m at a computer. I have my work in progress here if you want to pick up where I left off.
Ok thinking about it a bit more I guess you’d need to know the spacing in the firmware to interpolate perfectly (though it might not make much of a difference in practice). But I think when using curve fitting it’s probably not necesssry right?
Well, if the idea is that when we are telling the machine to move to x0,y0 and we are actually moving to x1, y1 because the pattern is off and we determine the offset at x1, y1 to be x2, y2, we can assume the offset for x,y to be x2-(x1-x0), y2-(y1-y0) for reasonably small x1-x0 and y1-y0? If so, we don’t need to do anything to the firmware.
I like the idea of someone measuring like I did and entering that as a distance and then we just divide by the appropriate number of squares.
That makes sense to me, a few mm on top of 3 inches shouldn’t make a huge difference in interpolation.
That’s definitely easier for the end user! The main downside in my mind is that if you change the dimensions of the area you calibrate on, you’d also have to change the value. Using something like 3.0324in OR 1.0108 scale factor should be constant even if you change the area you’re calibrating on.
Maybe we could have both – when this gets productionized there could be a step to measure the outer squares of the pattern and we could do the math under the hood. But the value we store / save is a scale factor or an ‘average distance between squares’ or something like that.
I tried your method out and I was getting results that didn’t make sense to me and I stopped it. I then changed the calibration to do it the way I suggested originally and I got similar results as your way but I let it run the full board… So, I’ve been mulling why the results don’t make sense but are, nevertheless, correct. Tomorrow (getting late), I will try your way across the full sheet and see if I get reasonably consistent results with my original way. If so, your way will be the way since its a lot simpler to implement. If not, we need to figure out which is the correct way.
And thanks for the addition to save centerx, centery… that was on my todo list.
We definitely should store it as a scale factor… I just want to make it easy for people to determine that scale and eliminate as many places as possible for someone to make a math error.
Yeah no guarantees on my math above. I think it probably has some errors. I’m not very confident in it. We are talking about the correct way to handle scaling right? Just want to make sure we’re talking about the same thing
You’re welcome! Glad to be able to contribute to this
Totally agree. Before shipping to other users, I envision splitting this out into multiple steps, similar to the current calibration. Measuring the pattern could be one of the steps. For now I think we can just expose the scaling value directly. I think I lean towards storing distance between test markers (3*25.4mm by default).
Did not get the crash this time when saving to eeprom, so whatever you did seems to have worked!
I updated my doc with my calibration values from the run tonight. I did some traditional value changes I had been considering: I set the motor distance to the measured value (instead of the one generated by the ‘pull tight’ routine), I set rotational radius to 139.1, then I ran the calibration again.
My values overall look like they were better calibrated after my changes, which is nice. I still have that gnarly ~1mm amplitude periodicity in my Y axis, so I’m 2 for 2 in replicating that. I’m super curious what would be causing it. I’m pretty sure it’s not in the test pattern. I think I would be able to see 1mm of misalignment.
I also noticed when returning to center after sending the values, that I didn’t end up in the middle of the home square like I used to. Zooming in on the snazzy grid you made, I see that the target is over the blue line, which I think is the curve fit values? The red line (I think the interpolated values) seems to be a ways over. Is this expected with curve fitting? Seems like it should be closer, especially for the home position. How are you switching between curve fit and interpolation for testing?
I didn’t get around to implementing the scale function tonight, but I might be able to tomorrow if you don’t beat me to it!
The blue lines are the idealized grid, spaced 3 inches apart.
The red lines are the calibration matrix.
The green lines are the curve-fit values.
After you send the cal values and enable the calibration, you would ideally end up on the blue lines (like I see in your picture). This means that the adjustments are working.
Regarding your image, I would have thought the red horizontal red and green lines would have been much closer. Here’s mine:
Regarding using interpolation or curve, in Advanced Settings there’s two switches, one enables the use of calibration and the other switches between interpolation and curve. On means use interpolation and Off means use curve. When you connect and you get a stream if information from the controller on the front page, you will see the values .
1 (enable calibration) means it’s on
1 (use interp or curve) means it’s using interpolation
I got interesting results with my test last night, the x errors came out smooth and slanted (normalized to the center error):
and Y is similar but with some periodicity going on…
Is it possible as you save the values of x and y for each square to also save the chain length value sent to the motors left and right values? Just wondering if that would be a good checkpoint to see if they are smooth or have those oscillations in them.
Yeah, we could do a motor read and log that as well
I discovered my left motor controller chip was missing its heatsink. It’s now reattached and ziptied to the board.