-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chain Sag Correction for Triangular Kinematics #558
Chain Sag Correction for Triangular Kinematics #558
Conversation
This incorporates chain sag correction into the triangular kinematics algorithm. Changes are made to the simulator to align with the associated firmware changes. Additionally, a new parameter called chainSagCorrection is introduced. The triangular calibration process is updated to determine this value and send to the firmware.
I would request @BarbourSmith and others test this thoroughly before being merged. I have run simulations on it and all seems well, but testing on an actual Maslow is the real test. |
Man, you are really getting things done @reecej! Fantastic work! I will run the same test we were running yesterday using this branch and the compirable branch for the firmware. I will start with a fresh settings file and run through the calibration process before starting the test. |
I got to the end of the calibration process, but then I ran into an error. When I entered my values I got a warning which looked like this:
|
Could you send me the full logs please? And do you know which values you entered for the measurements? I should modify the calibration process to include the entered measurements as well for troubleshooting. |
Yes here is the log: The full output of the terminal is unfortunately lost because it will only let me scroll back so far before the terminal itself stops keeping track. Those same repeating lines scrolled by for maybe a minute before it got to the end Here are the measurements I entered: |
Were you starting with a clean configuration? Based on the screenshot of the console output it calibrated for the motorYoffset and rotationRadius, and was attempting to calibrate for chain sag but calculated that a negative chain sag would be required. The algorithm doesn't allow this, so it timed out. |
I did start with a clean configuration (deleted the Ground Control.ini file) What would cause it to come up with a negative number? |
In this case, it looks like the horizontal measurement you had (1861mm) is longer than it expected. For an 8' wide work area it should have tried to cut out a 1830mm wide mark. With a smaller-than-actual rotationDiskRadius setting it would be reasonable to expect the cut out mark to be longer than 1830, but this value was long enough that the chains to cuts 3 and 4 were calculated as being too long rather than too short (i.e. chain stretch, for instance). Could you confirm you measured from the same side of each mark (left/top/etc) to remove the size of the bit from the equation? The only place the bit diameter is factored in is the motor Y offset. If everything is good there then I have an idea to see if we can make it work. |
I am still measuring pretty much exactly 1861mm from the right edge of the left cut to the right edge of the right cut |
Could you check your settings and ensure the chainSagCorrection value is 0? If so, try rolling back to the previous firmware and repeating the cut to see if the measurement changes. I'm wondering if something is off in the firmware. |
I am seeing zero...but I am also seeing that it is in the quadrilateral kinematics mode: I'm 99.9% sure I clicked triangular during the calibration process...no wait I know exactly what happened...I forgot to turn on the z-axis because the switch wasn't working the calibration option (now fixed) and going back probably messed something up. 203% my fault...although if I was in quadrilateral mode how did I get to the triangular calibration window? |
Definitely not 203% your fault. If you, admittedly very experienced in using the machine, was able to encounter an issue then I am confident a new user could have the exact same issue. Did you by chance press the next step button from step 9 rather than pressing the triangular kinematics button? |
It's possible, but I thought I had a lockout that would prevent someone from being able to skip into the wrong one. It should skip you into the correct calibration window. I am going to try again being very careful from step 1 |
Good call on asking me to check on the settings! We never would have found it if you hadn't throught to look there 👍 👍 |
I have a theory as to what happened. I see in the code that if no rotationRadius was able to be obtained, then a value of 260 is applied. I'm wondering if you deleted your .ini file if this value would be used instead. The algorithm is written to search upwards for a rotation radius as there are actually two sets of solutions (the motor being below the workspace technically satisfies the math), so with the rotation radius default being so much above the actual value I could see it being confused. It might be worthwhile having the calibration routine clear the rotation radius and chain sag correction values before calibration if this is the case, to avoid these types of problems. Thoughts? |
Oh good point! Something that has been on my todo list for a while now is to re-think the order of the calibration process. There is the step where we make a rough estimate of the distance between the points where the brackets attach to the sled and I think doing something similar for the rotation radius would be a good idea. I am mid way through the calibration process (after deleting the .ini), and I just checked the newly created .ini file and the radius is at 100 right now. I will keep an eye on it through the rest of the process |
Here are my settings going into running the test cut:
|
if you start your calculations at rotation radius =0 and search from there, how
many iterations before it gets in the ballpark of the right value?
Even if it's 1000, just add another thousand or two iterations to the limit and
everything's good.
That's far better than having a hard-coded minimum size that calibration breaks
if we drop below it.
|
The calculations do start at rotationRadius = 0, but it's more of the possibility of the test cut being done with a rotation radius that was substantially larger than the real value. Regardless, even if we clear the rotationRadius on the machine and iterate from complete scratch, like you mention it will take a negligible amount more time to complete the calculations. |
Try it out! |
I'm seeing the same thing as before 😐 This error:
Scrolling by very quickly and then ultimately the popup say that the values could not be determined. The fact that we got the exact same measurements feels like a little bit of a win...at least the calibration process is very repeatable |
Could you try setting the rotationRadius to 0 and repeating the cut to see what the measurements are by chance? |
Something seems off in the cut pattern. In the testing you did yesterday the long horizontal cuts were always a couple mm shorter than the nominal distance. Here, it's 30+mm too long. Another option would be to reset your rotationRadius to the proper value and perform the test cut too. |
should we do the vertical spacing test, get the results, then do the horizontal
ones?
k
|
I agree that its very strange that all the cuts used to tend to short, but now we're getting long. I will run the 1905mm test cut again and see what I get with the current settings |
That's effectively how the algorithm works, but the part that is giving us trouble is moving to that second phase of calibrating the horizontal. |
Where is the gcode which is being sent to the machine? For some reason I can't see it in the "files changed of the pull request" |
True, and that goes into my thought process from where we go from here. So far, I have been grouping remaining error into three categories:
My suspicion is that item 1 is contributing a substantial amount to this. As a test, I was designing the next generation of this calibration process (for a separate PR) which would incorporate additional horizontal cuts to use in the calibration process. The goal of this would be to remove some of the "randomness" of sled position, if such randomness exists. But it would substantially change how the calibration algorithm works, so I anticipate that will come sometime in the future. |
You've helped the sled randomness issue a lot by the way that you've ordered your cuts in vertical rows. Doing the right side cuts from top to bottom might help it a little as the X-accuracy is better at the top of the work area. |
Can someone try doing the calibration a few times, but between doing the
calibration runs, change the rotation radius to different values (say 0mm, 50mm,
100mm, 200mm, 300mm) and see what the results look like?
I'm not saying that there's no compensation for the prior rotation radius, just
that it's not right yet, something isn't been accounted for properly.
I expect that repeated calibration runs with the rotation radius set to the same
value before the run will result in very similar final numbers, but that there
will be significant, and consistant differences between the different starting
values.
|
Very good point. Think this is something I should modify quickly, or leave as is for the time being? |
I don't think the order of the cuts is going to make much difference, as the
sled moves up and down, it's going to have pleanty of time to adjust any
side-to-side error.
|
Do modify it, to have it in this release. Is there a reason for the horizontal cut not to be connected to cut 2? |
@davidelang , the sled makes the cuts in counterclockwise order, so it makes cut 4 after a horizontal travers across the bottom of the aork area. That is sub-optimal for avoiding chain sag error... |
I started with rotationRadius at 100, the default, and the procedure set it to 28.1mm, almost perfect. Subsequent runs changed it a half a mm up and down, and it settled on 27.7 on the fourth run. |
My original thinking for the separation of the horizontal cut was to maximize the side area of cut 2 for measurement purposes. If cut 5 was connected to cut 2, do you think it would make it more difficult to measure? |
The cuts seem big enough to not interfere. Spoil less of the sheet, too 😁. I'd cut 1, 3, 5, 2 then 4. |
Sounds good to me. 1, 3, 5, 2, 4 is the order I have been making the Gcode for right now. I think I'll move 5 to the top edge of 2, so that set of cuts will become a "L" shape rather than a "T" shape. |
I'm glad I re-visited this, because I did actually find a little error in the Gcode. The cuts 3 and 4 were actually 2 inches lower than I expected. I'm cleaning that up here too, but that may create a bit more stability in the output. |
So when I measured center-to-center I was half a mm long! 😁 |
Well cuts 3 and 4 are primarily used for chain sag correction, so some error in height there (where we see the most chain sag effects) could create some of the widely varying values. Out of curiosity, could you measure the distance of the cuts 1/2/3/4 from the top/bottom? They should be around 10, but I suspect 3/4 are closer to the bottom than that. |
Cuts three and four end about 7 1/2 inches from the bottom of the sheet. |
Thank you, they should end about 9 1/2 inches. Correcting that with the aforementioned changes! |
The cut pattern for the triangular kinematics calibration algorithm was altered to spoil less of the sheet and make all vertical cuts in the same direction.
Alright, hopefully I have it all sorted out now. The cuts should all be approximately 9 1/2 inches away from the edges (after the machine is calibrated). The other thing I would request to be validated is that the motorYoffset value is correct. With moving cut 5 I had to adjust the calculation for motorYoffset, so I'm more just looking to ensure that after calibration the home location is truly the center of the sheet. |
Ok, I’ll check it. |
The marks are 9.5"" from the upper and lower edge, and 10" in from the sides. The 3-4 measurement was 1mm less than the previous runs (this time 1929.4 ) with the other cut order. Cuts 1-2 were the same, 1930.4. The new measurement for motoroffsety was within 1mm of the previous. I measure it to be 475mm, the calc guesses 464.4.Probbly close enough 👍 The rR came out 128.0 instead of 127.7 and the chain sag came out 35.75 instead of 29.05 |
Thanks for your testing! Sounds like your sag correction value was right in the middle of the values you were getting before, which is a good sign. |
Thanks @blurfl! From the horizontal lengths, it looks like that combination of rotationRadius and chainSagCorrection is pretty good for you. Are the vertical lines all supposed to be 900? That is also very interesting about the right side of your machine. Bar saw similar errors on the right side, but also saw errors on the widths of the 100mm squares on the left side, which you don't seem to. |
I’m not in a place to check the file - it’s taken from Bar’s open PR, I think it’s the same one he’s been running. |
My right side is funny too! Let's investigate. The Y-span should be 900mm so you are looking way closer than if it was 800mm 😀 I am sure we can continue to improve, but we've already proved conclusively that this pull request brings us a roughly five fold improvement in accuracy. It's been tested with both the ring and linkage systems. It is fantastic, and I am going to merge it here. We can continue to make tweaks in further pull requests. I want to say a huge thank you to everyone who worked on this and especially @reecej for making it all happen. This is huge. Totally massive. This is open source at it's best with people working together to build something. Great work everyone! 👍 👍 🍾 🎆 |
Thank you everyone for your assistance with this process. I greatly appreciate your input of time and testing to get this sorted out. It was a great team effort! |
@BarbourSmith did you ever try attaching a 2x4 across the top of your machine to
see what difference it makes to the accuracy?
|
I haven't yet. I started to and then I decided that enough of the play was in the plywood motor mounts that I really think the right solution is to attach the motor brackets directly to a beam like you show in your design. That way there are the minimal number of joints which could have play in them. |
This incorporates chain sag correction into the triangular kinematics algorithm. Changes are made to the simulator to align with the associated firmware changes.
Additionally, a new parameter called chainSagCorrection is introduced. The triangular calibration process is updated to determine this value and send to the firmware.
This is the Ground Control PR associated with Firmware PR 369.