Discovery on moving calibration grid

1

@dlang @ian_ab @volodymyr I think this might be interesting to yall

Sine the AI has really been struggling to automatically generate the calibration grid, I decided to give it a go by hand and it went pretty smoothly…until it didn’t.

You can find my attempt here:

It’s working well, except that the grid which it is generating is not right. The issue is that it seems like when starting from truly garbage initial values for the anchor points we don’t have a good enough estimate of the frame size after the first six points to accurately predict much of anything.

Here is the log from my most accurate attempt:

Maslow-serial(15).log (7.9 KB)

The most relevant part is here:

[MSG:INFO: Frame dimensions from kinematics: TR_X2708.100 TL_X: 35.300 TL_Y: 2541.700 BL_Y: 0.000]
[MSG:INFO: Frame size: 2672.800 x 2541.700 mm]
[MSG:INFO: Computed grid size: 1069.120 x 1016.680 mm]

Basically after the first pass the system thinks that my ~2300x3000mm frame is much more square than it is which results in a grid which is much more square than it should be.

I think that we’re going to have to go back to the drawing board and think a bit on what to do next.

One option is to demand a higher fitness value before moving on from the first 6 points. With just six points we should be able to hold out for something higher than 0.7 that I got there.

2

on mine, copilot stopped doing test compiles and it made a version that won’t compile :frowning: trying to get it to recognize there is a problem is hard. the emails that I get about a problem make it think it’s trying to compile Maslow-Main. once I can get it to compile again, we can test corner cases (the last version I could run went through the grid, then when it tried to log the results, it died with memory access errors)

as for the grid accuracy.

It may be that we need to do things in stages, but a better version of what was being done before.

before we were taking dimensions from the user and blindly trusting them (with poor results)

now we have the ability to get more info and make grid estimates from there

You have been going down the path of working as a percentage of the frame size. I have been going down the path of staying ‘in the green’ (and our issues have largely overlapped)

I think that the right next step is going to be something along the lines of
(thinking out loud)

if automatic grid

  • measure the belts at the center (gives us a very rough idea of the frame size

    • allocate arrays for coordinates and results based on a square frame with grid spacing (the idea being that for a given set of belts, a square is going to be the largest area, so a grid with spacing X will have more points than any rectangle that those same belts will reach)

  • based on this, start a loop

    • plan this iteration of the loop

      • from what we know of the frame size
        • can we do a ring around what we know (the next 8 points of a 3x3 one iteration, the next 16 points of a 5x5 the next)
        • when we hit the limit in X (or Y), keep going in Y (or X) until we hit the limit of the green in both X and Y
        • also need to limit for work area, a 8x4 work area should limit us to 7x3 to keep the machine from falling off the edge

    • measure these points and add them to a results array

    • recompute frame size

      • check all elements in the array to see if they are ‘in the green’. If not flag those points as ‘ignored in loop iteration X’ and recompute the frame size until all valid measurements are ‘in the green’ for the frame we think we have

by changing the planning and limit checking from a single step at the beginning to something we do each iteration through the loop, we get better estimation of the frame as we have more points and cover a wider area and avoid including bad values in our calculations.

In an advanced version of this, instead of planning a rectangular grid, I would do something more along the line of curves

  • start from the middle
    • swing around the TR anchor
      • length of TR belt does NOT change
      • put the bottom belts into comply
      • move towards the TL anchor for mm
      • snug bottom left
      • snug bottom right
      • measure (pull on all)
      • repeat for a bit (have to figure out how many times are safe)
      • return to center
  • swing around each of the other anchors
    • this gives us an X (with the arms curved) of points
  • shorten TR belt by mm and repeat

it’s nagging me that if we keep the distance to one anchor constant, we may be able to get calculations to converge a bit better??

1 Like
3

I was also thinking along similar lines, except

Starting from the centre position found from equal belt length for diagonal belts. Waypoint 0
Pull on one belt (say TR) a known amount, say 300 mm, then tension opposing belt diagonally, without tensioning the other 2 belts, take a reading. Waypoint 1
Pull on opposite belt (BL) for 600 mm and take a reading. Waypoint 2

Return to the centre and repeat, but this time with TL and BR to identify Waypoints 3 & 4

This would give you 4 points which we can assume is accurate (no sideways pull from the 2 belts not being used for initial finding.

Now we tension the other 2 belts and check to ensure that the corresponding position is maintained.

Repeat for the other waypoints 1 - 3 (4 already done). We can get a pretty good idea of the shape of the “rectangle” and we should be able to work out the angle of each belt in relation the line BL–> BR and calculate the distance from centre by the amount of belt fed out to reach the centre.

Does this seem logical?

1 Like
4

I have what looks like a working version of my ‘in the green’ code to try

5

you assume that there is no slope or surface friction that would cause the sled to go ‘downhill’ or start rotating

1 Like
6

Rotation shouldn’t matter, as we are working from centre, so the belts should be in a straight line from the centre. I have not taken into consideration any gravity effects, but even so it should give a pretty good indication of the actual shape of, and the direction and angle of the support anchors.

7

imagine a sticky point just off center to the right of the belt. when the sled
hits that, the belt will keep that edge stationary and the sled will rotate
around that to the left until the sled is past that point. so a point that was
almost in line with the belt (and almost centered on the belt) will not be ~90
dgrees from the belt but still on the same point of the board, moving the center
to the left by almost 1/2 sled diameter.

the surface isn’t smooth and flat, so you can’t count on a single belt pulling
it in a straight line

David Lang

1 Like
8

Before you take the reading the opposite belt is pulled tight which will give you reasonable confidence in the position of the sled. The angle of the sled is not a factor as we are relying on the belts pointing to the centre of the sled, so unless it is twisted far enough for the belts to be hitting a support (in which case no amount of points is going to be reliable) we can be confident sled is in a straight line between diagonal posts, ignoring gravitational effects at this stage. I would see this as a method of getting a general shape of the anchor points more than a final, definitive configuration. I am not suggesting this is the final solution with just a few waypoints, but it could give us a reasonable approximation to build on

1 Like
9

see Testing needed automatic calibration grid generation - #116 by dlang

I finally have a version that works (still some odd movement, but works)

10

I’ve been thinking about a complete revamp of the approach to calibration (based in large part at staring at my maslow run through the first 6 points with the horribly loose belts getting yanked tight again and again)

moving in straight lines requires coordination between multiple belts, but moving in an arc centered on an anchor is much easier (keep the TL belt the same, but the bottom belts in comply, pull on the TR belt and the sled will move in an arc, then snug up the bottom belts and measure)

I had originally thought about doing this just for the first measurements, but then thought, what if we did the entire grid this way?

This is what the grid could look like (100mm spacing between points, so LOTS of points)

image
image1669×1334 140 KB

it would first do the center point to get a rough idea of the scale of the frame

then do the blue points (which can be known-safe moves because we will know we aren’t getting close to the corners and we are swinging on a pivot, no possibility of belts pulling against each other unless your frame is REALLY short to where you are hitting the top edge limit)

now we have 9 data points across a space across a 300-400mm X and can try for reasonable anchor locations.

do a ‘in the green’ calculation and extend the X as far as you can go (the orange dots)

this gives us even better data to do a frame calculation

then go across the rest of the area in arcs to fill in the red dots (I don’t know how many calculations we would want to do along the way, and when we transition from the super-safe compliant lower belts to faster, more normal movement. All movement is either across known areas, or is only moving 100mm (we could even do 'if you are moving to a known point, use all 4 belts, if you are moving to a new point, have the bottom ones compliant

there may be flaws in this, and things we need to tweak for horizontal frames, but I wanted to through the idea out.

1 Like
11

Can see this being good for a vertical frame, maybe not as easy for a horizontal. Perhaps we need is to have different approaches for vertical and horizontal frames at least for the initial waypoints, until we have some idea of the anchor points.

12

Ian Abbott wrote:

Can see this being good for a vertical frame, maybe not as easy for a
horizontal. Perhaps we need is to have different approaches for vertical and
horizontal frames at least for the initial waypoints, until we have some idea
of the anchor points.

I think it would work for a horizontal frame as well

when you start at the center (you can match belt lengths and get pretty close)

pivot on the top left by pulling the TR 100mm, then snug up the bottom
do it again

then return to the center (you know the length for the belts there and the belts
at the point in between)

then pivot on the top left by pulling the BL 100mm, snug up the right..

then return to the center and do a mirror of this

no feeding belts out (just comply), no coordinated motor speeds to stay in a
straight line

remember, what we need here is measurements in a number of points, it doesn’t
really matter where the points are. you want to the area of the points to be
wide for best accuracy, but beyond that…

David Lang

13

Just brainstorming…

I like idea of reducing variables by locking one belt. What if we kept 2 opposite belts tight, . Ie TL BR

Then slack BL and retract TR say 100mm. Measure point.

Slack TR, retract BL 200mm. Measure point.

If perfectly rectangular frame points should be signed inverted. But probably not true but reduces 2 variables initially.

Would any of these help with getting initial guess.

Dano

1 Like
14

Dano wrote:

Just brainstorming…

I like idea of reducing variables by locking one belt. What if we kept 2 opposite belts tight, . Ie TL BR

Then slack BL and retract TR say 100mm. Measure point.

but to move in that direction, the BR and TL belts need to feed out just the
right amount (especially on a vertical frame where slacking the TL belt will let
the sled swing around the TR anchor a bit.

If perfectly rectangular frame points should be signed inverted. But probably not true but reduces 2 variables initially.

with the precision we need, it’s not true enough to be a problem

Would any of these help with getting initial guess.

in a perfect world, with no belt stretch and perfect accuracy, you can get away
with measuring three points if they are far enough apart.

we need more points to be able to move the machine safely in anything other than
an arc, and we need them to be widely separated.

so we need to do some sort of grid, it’s unclear how dense it needs to be (the
diagram above was very dense)

David Lang

15

another thing I was thinking of.

we need to know where the workpiece is and how big it is to avoid going off the
edge.

is someone using a 4x8 sheet on a default frame?
did they mount it in the middle? or did they mount it a bit lower (like Bar
does)?
are they trying to use a 5x5 sheet?
is this a 30’ square frame with a 1’ square board

rather than ask the user for numbers, have them swing the sled up as high as
they want to go and then as low as they want to go to get the range of motion
instead of the initial small X that I describe below for phase 1.

side to side is harder, and should wait until after the full phase 2 X is probed
and calculations take place.

now that we have code that gives us estimates with real error bars, we can do
some testing to see how different numbers of points help (or not). I’m thinking
that widely separated points will help, but probably not be worth the full grid.

something like:

after the initial X, you end up at the top. do the calculations and pivot on the
other motor (now you have X\ ) and then pivot back on the first one X/ ) until
the user tells you that you are at the edge of the safe area (don’t worry about
arms colliding at this point).

retrace the path and go to the other edge and you now know the 4 edges of the
machine and it can fill in between these areas as we decide is needed with no
risk of going off the edge

This is some manual machine operations, but it is just three buttons (continue,
back up, and enter) not measurements

it also won’t matter that much if these positions are off, it will just slightly
shrink the calibration grid area, the calibration should not change much

David Lang

16

pasting the measurements from your log into the new calibration algorithm results in:

x1 (B): 2940.1 ± 59.5 mm

x2 (C): 2965.4 ± 54.9 mm, y2 (C): 2228.9 ± 73.1 mm

x3 (E): -10.2 ± 8.4 mm, y3 (E): 2244.7 ± 72.8 mm

the error bars here are large, but 2952 ±60 x 2237 ±72 is far better than your 2672 x 2542

what are the actual dimensions of the frame?

17

I asked grok to convert the javascript program into a esp32 C function on the thought that this is SO much faster than the prior version, that we may be able to eliminate the back and forth to the browser and do everything on the esp32

I have not looked into the resulting code, and some adaptation will be needed to save the results in the right place. but here it is if someone wants to look into that (all 386 lines)

calibrator_esp32_fragment.cpp (13.8 KB)

In the meantime, I’m working on a PR for the UI that lets you select either the maslow classic algorithm or the new one.

I’m running into a bug testing that I think is the firmware, not the UI

PR is Add alternate calibration algorithm with Gauss-Newton Least Squares by Copilot · Pull Request #222 · BarbourSmith/ESP3D-WEBUI · GitHub
binary that seems to be working is at Add alternate calibration algorithm with Gauss-Newton Least Squares · BarbourSmith/ESP3D-WEBUI@f51b878 · GitHub