For kicks I will run the calibration with the exhaust port 180 from what I’m doing and see how the machine values follow. I’m wondering if there is a similar keystone effect.
1 Like
I love that idea!
I re-ran the job with bot 180 degrees rotated and the following are the results. This was also with the z offsets changed to match anchor heights.
Calibration values Rotated:
Fitness: 3.1542010014588175
Maslow_tlX: 3.9
Maslow_tlY: 2321.3
Maslow_trX: 3585.2
Maslow_trY: 2319.8
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3603.5
Maslow_brY: 0.0
For reference, the following are the unflipped readings from the previous post/log.
Calibration values:
Fitness: 2.4419750107813196
Maslow_tlX: -27.1
Maslow_tlY: 2316.9
Maslow_trX: 3581.3
Maslow_trY: 2325.1
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3576.0
Maslow_brY: 0.0
Maslow-serial Updated anchor Z values 180 Flipped.log (36.4 KB)
Would it be worth re-running any of these to get back to back comparisons? -Scott
1 Like
More data is always valuable, but I haven’t spotted a pattern to dig into yet.
The next thing that I want to explore is looking at how running the calibration process multiple times back to back changes the results.
In theory it shouldn’t make a difference, but that is to be tested
I had time to run one more calibration today with the router in the standard orientation. Should I manually load my table measurements and run a test job that punches holes to check for distortion?
Fitness: 3.8801333679441234
Maslow_tlX: -26.7
Maslow_tlY: 2306.6
Maslow_trX: 3581.7
Maslow_trY: 2325.2
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3581.9
Maslow_brY: 0.0
Maslow-seria Dec 18 Round 1l.log (39.0 KB)
I punched a set of holes with the latest config, but when I updated the yaml with my measurements (and restarted) The router would not go to the ready state. It would take up slack, but then return to belts extended. I changed just the X an Y values. Are there others that require changing when doing a manual config. I think there was a long thread about this subject a few months back.
When the machine applies tension it is taking a single measurement and comparing that to the anchor point locations stored in the .yaml file and checking to make sure that the measurement that it just took is a valid solution for those anchor points. If the numbers don’t match up it won’t proceed as a “something is off, let’s not go any further” safety catch.
There is a bug in that process which was that the calculation was not taking into account the z-axis height which has been fixed in the latest version which is to be released hopefully next week. You can find a test version of it here: Interstitial Firmware Releases - #585 by bar
1 Like
I’ve been a bit distracted with getting v1.16 out, but this is still a top priority.
The first thing that I’m focusing on is improving consistency. Basically making sure that every time we locate the anchor points we locate the exact same points. There will always be a little bit of variability, but we want to minimize it as much as possible.
The pattern that I’ve noticed is that the results seem more consistent if I run the locate anchor points process twice in a row. That is if I start with a fresh .yaml file and run it twice I find the same anchor points more consistently.
That tells me that either we need more data in each run or we need to process the data that we have more carefully.
I think that what is happening is that as we approach the right solution we are getting caught in a local minima. Basically the results stop improving so we think we’re there, but there is actually more room to keep improving.
My theory is that running the calibration process a second time right after the first gives us a new set of data which is less likely to have a local minima at the same place so our results improve.
There are also ways we could re-interpret our original data set to see if we can improve the results. We could try computing with every other measurement set to see if that changes things.
Another option would be to try to explore some points outside the solution to see if we can improve. In the 2D case that is easy because we could just try a handful of points to the left and to the right of our solution. Unfortunately we’re working in a six dimensional space so it gets exponentially expensive to explore that way. That doesn’t mean it’s impossible, just that we want to do it carefully.
All this is to say that I haven’t forgotten about this issue and there are some clear next steps that I am excited to explore.