Update Triangular Kinematics Calibration #547
Conversation
This updates the triangular kinematics calibration routine. Rather than request the user to perform multiple cuts, a single cut is performed and then the machine parameters are iteratively found based on the measured parameters.
This requires that a recut be performed before new values can be entered after a successful triangular calibration.
|
This works slick! 🎉💯. The value reality-check will save much confusion 😉 First time through, a couple comments:
I did some test measurements:
This is a definite improvement. Thank you for your work, an excellent contribution! |
|
Thank you for trying it out and providing your feedback!
I greatly appreciate your feedback on the accuracy measurements. The calibration routine assumes the horizontal distance between motors is accurate from the earlier calibration steps, so that parameter is not adjusted. Were the accuracy issues you found at 36" left similar to your previous calibration parameters? |
|
Yes, similar, perhaps smaller now. I can restore the previous settings and see if there’s a difference. |
Configured the triangular kinematics algorithm to cut 5mm horizontal marks at each cut location, then move the sled out of the way for ease of measurement. Also allowed a 0mm bit size for pen use, and tweaked the algorithm for better stability.
|
I made updates per your comments. Would you be able to test it again when you're able and see how it works? 0mm bit diameters are now allowed to facilitate pen usage, 5mm horizontal marks are cut at each spot, and the sled should move out of the way after. I would also be interested in seeing if there is a difference with your previous calibration routine, more to make sure that we at least aren't moving backwards in accuracy. |
|
Also, if your errors on the 36" left measurements are similar with both calibration routines, then I may try to add a chain sag compensation next, as it sounds like the error you are seeing is similar to what chain sag might produce. |
This updates the triangular calibration test cut image to accurately portray the 5mm horizontal cuts and the sled moving out of the way after.
|
As an aside, I have also developed a chain sag compensation algorithm for the firmware and GC. It would be integrated into this calibration process. Should I incorporate it here, or wait for this to be merged and then create a separate PR? |
|
do it as a separate PR to adjust the chain length calculation for everything.
|
|
Sounds good to me. I have the firmware code written to account for chain sag. I'll wait for this to be merged to do the GC code, as this code will need to be modified to provide automatic calibration for chain sag. |
|
Thanks for the recent modifications, they're improvements. 👍 We may get some push-back from folks wanting to use inches instead of mm for the measurements...
I've got some sag measurements as well: |
|
Thank you for gathering that information, it is very helpful! Would you be able to send me the log files for me to review? My e-mail address is listed in my GitHub profile. The sag measurements are extremely helpful as well, and it looks like sag correction could go a long way to improving the horizontal errors you observed. Regarding the changing rotation radius values, that could make sense, in particular if we are having sag-induced error of even a small amount. Do you happen to recall which values you measured for the distance between cuts? I was wondering about the metric vs imperial units. In the previous triangular calibration it seemed only metric units were allowed, whereas on the quadrilateral calibration the user could select. Do you think it is worthwhile allowing the user to select metric or imperial? |
|
Yes, it is a good idea to support both unit systems.
|
|
note that the distances for the "sag over X" are diagonal distances, not horizontal distances |
|
a note on measuring with a tape measure. The reason the hook on the end of a tape measure is loose is to that it moves by the thickness of the hook. That way, if you hook it over something, you get the same measurement that you would get if there was a vertical surface there that you were pushing the end of the tape against. cutting a short horizontal mark instead of just drilling a hole makes it much easier to tell where the top and bottom edges are (make the cut at least 1/2" wide, probably better to make it 1" wide so that even large tape measures can hook in the slot) always measure from the bottom of one slot to the bottom of the other slot (or top to top), that way it doesn't matter how large a bit was used to make the slot. when allowing entry of imperial units, see if you can support entering fractions. |
| rotationRadiusCorrectionScale = float(rotationRadiusCorrectionScale/2) | ||
| print "Estimated values out of range, trying again with smaller steps" | ||
|
|
||
| if n == numberOfIterations: |
There was a problem hiding this comment.
at least as a debug option, we should output both the number of iterations, and the accuracy we think we are at.
|
I can make an update to make the slots 1 inch wide, to facilitate easier measurements. Imperial units shouldn't be difficult to do either. Native support for fractions are a different story, and may be something to be included later! |
|
could you do this in firmware as a B (or $) code and have GC invoke that?
This way the chain sag work will directly help everything, not just the
calibration step.
|
|
The chain sag will be a complete implementation, including:
|
Something like 10mm or half an inch would be wide enough, don't want to make bigger marks than we need 😉. The sled doesn't need to travel quite so far out of the way, and perhaps should go back to 0,0 when finished? |
|
I'm asking if you can make it so that the iteritive calculations can be done in
the firmware rather than in GC
This would need to be a series of two commands
1. set location 1 (tell the firmware to remember the chain lengths and current Y
position')
2. set location 2 (tell the firmware to remember the chain lengths and current Y
3. actual distances are X and Y (do the calculations and save/report the results
This would ensure that any improvements to the firmware (like chain sag/stretch)
are automatically used by the calibration
This would also make it possible to do the calibration with any tool, not just
GC
It makes sense to keep the machine specific math limited to the firmware if we
can.
|
|
On Mon, 8 Jan 2018, Scott Smith wrote:
> make the slots 1 inch wide
Something like 10mm or half an inch would be wide enough, don't want to make bigger marks than we need
I intially thought of saying 1/2" wide, but then I realized that 1" is a pretty
normal width for tape measures when you get to the longer ones (25+ ft), it
takes very little time to do this, and so better to support as much as possible
rather than get into a state where the marks aren't wide enough for the hook of
the tape measure to fit.
|
This is possible, but not with how the current code is written. I like the idea, but it would require that the kinematics formulas be written such that calibration patterns can be used. The alternative would be to rewrite the existing values, but with them stored in EEPROM we have to worry about write endurance. I was thinking a separate PR would re-write those algorithms so that could be allowed, but it will take some effort. |
|
This is VERY exciting!! As soon as I finish getting caught up on email (sooooo much email), the rest of my day is going to be on testing this idea. It's a brilliant concept and I'm so glad you did this! Great work!!! |
|
I appreciate it! I'm still working on some tweaks, per the great feedback in this thread. I have some of the updates done, but some of it will have to wait until tomorrow. So tomorrow expect another commit with some tweaks! |
|
I've just done my first run through the new calibration process and this is so great! Thank you for taking the time to even update the pictures. I found a new rotation radius of 143.8mm where my old one was 131.9. How important is the accuracy of the vertical motor offset measurement to this process? I didn't do a very careful job on that measurement because in the past it wasn't important. If it is important I think we need a better technique than asking people to kinda eyeball when the chain is at the same height of the top of the sheet. When I run the 1905mm horizontal test cut after the calibration finishes I get 1896mm |
Is this with the ring linkage: As the true value for that linkage is easily measured, it's a good test of the calculation done in this method. It sounds like some correction is needed, yes? |
|
Yes, this is with the ring...but I would really like to check for bowing in my frame before I am considered the ideal test case |
|
Thanks @BarbourSmith! Looking forward to seeing the results! I think Bar's tests here will be informative on the topic. From what we have been seeing, after calibrating the rotation radius using the vertical calibration routine in this PR we see that a cut across the horizontal axis is commonly around 10mm short (1905mm Gcode vs 1896mm sled movement, 1805mm Gcode vs 1797mm sled movement, etc). I have also read of user reports recently of similar error. So I'm suspecting that something in the range of 10-12 mm of error along the entire horizontal axis at Y=0 is realistic. |
This is me being dumb. Feel free to ignore. :-D |
|
With the gcode issue fixed we're back to 1896 so I think the data is OK here's the final numbers for test 1
|
|
did you check for frame flex? test1 is the new calibration, correct? can you also measure the outside of the squares at teh top and bottom (is the top wider or narrower than 1896 that we get at the middle?) at some point, we need to get someone to spend some time with the simulator and see what measurement errors would result in this. |
|
I am using the stock frame design. I have not checked for frame flex, but I will. What was the recommended technique? This is for the new calibration system. You are asking for me to check that the measurement is the same at the top and bottom of the squares? I can do that. |
|
All of the squares are the same at the top, middle, and bottom to within ~.2mm which is about the limit of what I think is reasonable to consider accurate the measurement |
Measure motor-to-motor before pulling the chain and while the chain is pulled. It doesn't matter what you measure so long as you measure the same two points both times - is there any difference, and how much. |
|
On Wed, 10 Jan 2018, BarbourSmith wrote:
I am using the stock frame design. I have not checked for frame flex, but I will. What was the recommended technique?
measure with a tape measure with everything is loose, then measure again while
the chain measuring motor distance is under the max tension.
You are asking for me to check that the measurement is the same at the top and bottom of the squares? I can do that.
top and bottom of the sheet, not top and bottom of individual squares.
|
|
sorry, I was meaning the left edge of the top left square to the right edge of
the top right square.
that should be the same as the distance measured across at Y=0
simiarly, what is the distance across the bottom two (left edge of the bottom
left square to the right edge of the bottom right square)
|
|
Excellent suggestion. Updated with those measurements:
|
|
Dopn't we expect 1805mm across the middle? |
|
Yes, I think we do The 1896 measurement was after adjusting the gcode to expect 1905 so that it would match with my measurement from yesterday to confirm that something was deeply wrong |
|
Yes, the expect 1808 across the middle is actually expect 1805. |
|
Thanks for taking the time to do this @BarbourSmith! This a very useful info. I would be curious to have you (and anyone else that is interested) to try out the chain sag correction code that I have as a next step so we can compare to this result. I think that will give us additional insight as to whether the error we're still seeing is sag-induced or due to some other aspect. |
|
I would love to test it. I'm really liking this test pattern, I think it gives us a lot of good information to work from. I'm working my way through the original calibration process right now and really missing that one click calibration 😉 |
|
Just so I can better understand how it works, why does the new calibration ask for a measurement from the cut to the top of the sheet? |
|
That is to precisely determine the motor Y offset based on the updated motor Y coordinate from the calibration process. It's the more accurate value of step 5. |
Step5 has always bothered me- trying to estimate by eye a distance in a different plane and several inches aside. This is so much nicer! |
|
Here's the results for the current calibration system:
|
|
Looking at them side by side I think it's pretty much immediately clear that @reecej has made a MAJOR improvement. Here is both in a single post for easy side by side comparison: |
|
Great testing, thank you for putting the time in for that! I suspect the updated calibration method is getting values closer to the actual geometry of the rotation radius, so on average the numbers look better than before. However, this does show that we are trading some horizontal accuracy for vertical accuracy. I'm looking forward to seeing your tests with the chain sag compensation to see if we can get it even closer! |
|
Here is one last test where I did the normal calibration process for the first part and then skipped the calibration process and entered my expected value of 140.4
This test pattern is a good metric I think. I am more than happy to run it any time there is a request. I vote we are ready to merge the pull request and make this the official calibration procedure...anyone opposed? |
|
the fact that the horizontal values get smaller as we go down tells me that some of the parameters are not right (either the rotation radius or motor spacing) |
|
I think the horizontal values getting smaller as he went down correlates well with chain sag. I took Bar's measurements and put them into my chain sag algorithm. I had to make some rough guesses of what measurements Bar would have gotten for the chain sag calibration process, but based on those guesses here are my calculated chain sag errors for Bar's setup: Y=450mm Y=0mm Y=-450mm These values seem to correlate well with Bar's observed measurements: Top measurement: 3mm too short |
|
Fantastic PR @reecej 👍 👍 💯 |
|
On Thu, 11 Jan 2018, reecej wrote:
I think the horizontal values getting smaller as he went down correlates well with chain sag.
I took Bar's measurements and put them into my chain sag algorithm. I had to make some rough guesses of what measurements Bar would have gotten for the chain sag calibration process, but based on those guesses here are my calculated chain sag errors for Bar's setup:
what is your chain sag algorithm?
I've been using the calculations here:
https://www.spaceagecontrol.com/calccabm.htm?F=100&a=4.407&q=0.13&g=9.81&Submit+Button=Calculate
and they've seemed plausable
… Y=450mm
1800mm nominal cut is actually 1798.1391mm
1.8609mm too short
Y=0mm
1800mm nominal cut is actually 1794.6549mm
5.3451mm too short
Y=-450mm
1800mm nominal cut is actually 1790.4618mm
9.5382mm too short
These values seem to correlate well with Bar's observed measurements:
Top measurement: 3mm too short
Middle measurement: 6.5mm too short
Bottom measurement: 10mm too short
|
I used the same source, although designed my own formula based on it in which I consolidated all coefficients into a single variable (chainSagCorrection). |
This updates the triangular kinematics calibration routine. Rather than request the user to perform multiple cuts, a single cut is performed and then the machine parameters are iteratively found based on the measured parameters.
I have not been able to test the G code or final calibration accuracy as I don't have a Maslow yet, so I would request that this be throughly tested before being merged.
More information at: https://forums.maslowcnc.com/t/calibration-pattern-for-triangular-kinematics/879/34