Bar wrote:
Yeah, I agree that we should encourage folks to test, but we shouldn’t merge
it into Maslow-Main until we have decided which method to keep.
I agree, but it will be easy to rip out the selection (and old functions) once
it’s tested.
David Lang
I’m overall not feeling that great about this approach. I think that picking better starting values is a good idea, but I don’t like using random to do it.
Maybe we should be using an assumption that the frame is reasonably rectangular to shrink the search space?
That massively reduces the search space to just a few thousand calculations from millions (gotta love exponential growth)
Bar wrote:
I’m overall not feeling that great about this approach. I think that picking better starting values is a good idea, but I don’t like using random to do it.
This isn’t random, it’s a grid of points, but instead of straight lines parallel
to the bottom, it’s arcs centered on one of the top anchor points (plus a few
points on an arc centered on the other anchor point for the initial estimate)
Maybe we should be using an assumption that the frame is reasonably rectangular to shrink the search space?
that doesn’t help us much. We don’t know what the workpiece looks like compared
to the frame dimensions (See Ian’s frame which is massive (something like
4500x4000)
That massively reduces the search space to just a few thousand calculations from millions (gotta love exponential growth)
not really, but with the radial approach you could change spacing from every
100mm to every 200mm after the initial X and cut the number of points by a
factor of 4 (half as many rings, with half as many points on each ring)
David Lang
David Lang wrote:
Maybe we should be using an assumption that the frame is reasonably
rectangular to shrink the search space?
I think it may be reasonable to say that the workpiece is within a couple inches
of being centered in the X direction.
But I don’t think it’s reasonable to say that it’s centered in the Y direction
so using the arc-based grid will let us easily find the real limits on the Y
direction, and we can skip the more complex finding of the X limits
David Lang
@dlang I think that maybe you are replying to a different thread, I’m not getting the context
I thought you were referring to the low res diagram I posted above, here is a better one page used to create it is at SVG Generator
This is 100mm spacing for the initial X and 200mm spacing after that
this is 23 dots in the initial X and 46 across the rest of the frame
we would need to try this to see what the difference in accuracy would be
but even when I was doing just a 3x3 grid on 300x300 it gave significantly better accuracy than the initial 6 points at 300x150
and her is what it would do on a 2000x2440 frame (two narrow, so the corners are out of the green)
I would not be surprised to learn that just doing the blue X would be almost as accurate as going the red dots as well, but we would need to setup the ability to do this pattern and then test it.
but we need to ship the current version first 
we are approaching 100 commits since the last release
Yeah but before we ship it we need to test it a lot 
to work out mu frustration with the githum ai, I instead engaged with the grok ai (I know, glutton for punishment)
I had an interesting set of discussions (and was very amused when it showed as resources it was investigating, my posts on the forums here, including this thread)
It has suggested that the g-n algorithm I had it impelemtn and made an option was one to try, I asked this time what other ones to try, and if it’s possible to solve for the Z offsets as well (with a few more points measured, probably by making each move do two things, move in XY and take a measurement at Z=0 and then another measurement at Z=55 (or whatever our max safe height ends up as) the notes on each algorithm include comments about the impact that figuring out the Z offsets will have.
it estimates that it can get 0.1mm accuracy in 50-70 measurements (and that was with me saying that the best we could hope for was measuring belt and Z at 0.05mm when a single step with each is just over 0.01 mm. There are also comments in each algorithm of the number of points to measure and the spacing needed (additional points at less spacing do not add much value)
it came back and suggested 4 possibilities
The first is an improved version of what I implemented as an option
The fourth looks like approximately what Bar implemented in the stock UI (complete with warnings about it’s performance)
but the other two have very interesting capabilities
The second one is called Alternating Least Squares, and it has the very interesting feature that it’s incremental, you set a bootstrap, and then you can add points and do calculations one at a time. It means that it can be calculating the results of one point while we are moving to measure the next point. Each point improving our estimate
The third one can do that as well, but in addition, once it’s bootstraped, it can give directions on what point it wants to measure next, so instead of pre-defining a full grid and having to sample every point, the algorithm knows what areas it needs to get a measurement in to get more accuracy
These algorithms were designed by teams working on cable driven robots, and can accommodate systemic errors like belt stretch.
I am just going to dump a bunch of files here for people to read (and laugh at my fumbling) and use as starting points for further research.
grok-algorithms-GP.txt (7.1 KB)
grok-algorithms-ALS.txt (13.6 KB)
grok-algorithms.txt (7.0 KB)
grok-problem-restatement.txt (2.1 KB)
grok-density-last-1.txt (7.3 KB)
grok-density-last.txt (5.4 KB)
maslow_frame_prompt (5.3 KB)
grok-discussion.txt (59.2 KB)
None of this work is suitable for 1.13. We need to clean up and test what’s already written (we are nearing 100 commits since 1.12 with several pretty major features being added) but this points us at very interesting work and improvements in the near future.
