Help requested: Improving the Calibration Process

[bar]

I am working on improving the calibration process. One of the biggest issues with how it works now is too much extra slack in the belts when moving between locations.

I’m looking for some feedback on the idea of running a mini calibration grid in the center of the sheet which could give us “good enough” results that we could use them to move between locations on a slightly larger grid without the extra slack.

Would anyone who is willing be able to run the calibration process with these settings:

(with your frame’s rough width and height entered in at the top)

---

I’m interested in learning:

What fitness did you get?

If it’s low I would also like to see your measurements which look like this: CLBM:[{bl:2125.12, br:2103.29, tr:2200.08, tl:2202.73},{bl:1661.16,…etc

How did you feel about that process?

Was it easy to do? Did you have to tend to the belts to keep them from getting tangled?

---

---

---

The idea is that the calibration is generally usable in an areas slightly larger than the calibration grid so if we run a tiny grid (200mmx200mm) in the middle it might be “good enough” to move around a slightly larger grid say 400x400mm without having slack in the belts…that could then be used on a larger grid spiraling out until we have everything covered.

The first question is if we can get through that first small grid reliably and then we can build from there.

[Ethan]

Glad to try it, since I can’t get mine to calibrate in general.

What fitness did you get?
1.013, wow! Is >1 even a thing? Or maybe it’s so good because we only did 6 points?

How did you feel about that process?
Great! Somehow it’s the first time I’ve gotten above ~0.3 fitness, so something I did must have made it better. Might have been raising the z axis a bit (see below). I didn’t have to tend the belts at all during calibration, so that’s a pretty big win.

Specs: Frame is approximately 3271 x 1995mm, horizontal with concrete anchors. Spoil board is OSB. Firmware is 0.68, all 3 files stock except frame dimensions. Calibration grid 200x200mm, 2x2, 1300 retraction force.

What I did: Setup > Release belt tension. Remove belts from anchors. Upload 0.68 firmware.bin, maslow.yaml, and index.html.gz. Restart using red button in FluidNC tab. Remove power and plug back in. Realized that collet of router is sticking below the sled a bit, so raised Z axis by 10mm. Setup>Config: Set frame dimensions, calibration grid, and retraction force. Setup>Retract All. Setup>Extend All. Setup>Calibrate.

[ronlawrence3]

Also good for me. same steps as Ethan. Fitness 1.25.

cal-04-12.txt (7.7 KB)

Things I noticed vs a bigger calibration:

less movement on retraction of the lower belts, as its nearer the center and the opposing belt keeps it from moving as drastically. on my bigger 1000x1000 calibration, I saw more movement on the sled when the belts tightened.

Easier to manage belts, although you still have to keep an eye on them!

[ronlawrence3]

Just another observation: I unplugged it, retract-all, extend all, then jogged around a little after this smaller calibration. Looks like the belts were a little more slack than they were on my last good calibration. I’m guessing that would be somewhat expected but thought I should mention.

[ronlawrence3]

So in going along with your approach, I did another calibration after these values were set with 400x400 and 4x4. After many minutes on my M2 mac mini, fitness on this finally crept up to 0.66 or so after 100000 iterations (it was still running when I typed this part…)

I notice the new algorithm on this hardware is taking > 1 sec per 100 iterations.

I somehow lost the output / calibration measurements, but I’ll try one again tomorrow and report back.

Of note, at this resolution the belt management is easy

[ronlawrence3]

Got a reprive from leaving and had time to do another one: this time 400x400 4x4 the algorithm gave up on me this time .15 in 900 iterations.

cal-04-12-n2.txt (12.7 KB)

[Ethan]

@ronlawrence3

I unplugged it, retract-all, extend all, then jogged around a little after this smaller calibration. Looks like the belts were a little more slack than they were on my last good calibration.

I had this exact same observation. Guessing that the 2x2 calibration is fairly rough like Bar mentioned. Still, for people where calibration will eventually succeed, it’s probably a better starting point that’ll reduce the need to tend belts. Maybe after this rough calibration, the machine gives 10% extra slack than the calculated length on the belts instead of as-needed slack.

I also ran a full 10x9 calibration on 1000x700mm after and that failed, so this isn’t yet the panacea I hoped it would be (at least for my setup). I’m going to try doing some more simulation and throwing out points to see if that helps.

[bar]

OK, here is phase two of this.

Now we have an initial small 2x2 calibration pattern which is done with the belts slack, and then that information is used to get a good enough sense of the frame dimensions to do a slightly larger 4x4 grid which is then again used to run a slightly larger 6x6 grid while the machine automatically keeps tension on the belts.

Basically at each of the red circles we stop and recompute the anchor point locations and improve our understanding of the world. Then we use that information to go a little further out.

The goal is to eliminate belts getting stuck in gears.

There are currently a couple of limitations.

1. It will only work in horizontal orientation (Sorry! Working on it!)

2. The grid size is hard coded right now so it will ignore your values for the grid size and always do a 500x500mm grid

If anyone would be willing to give it a test and let me know what you think I would be very grateful. Generally I’m looking for:

How did the user experience feel?

Did it seem like your belts were too tight or so lose that they were at risk of getting sucked into the gears at any point?

This is still pretty experimental so run it with one hand on the emergency stop button for sure!

index.html.gz (155.7 KB)
firmware.bin (1.6 MB)

[gazinux]

@bar

It will only work in horizontal orientation (Sorry! Working on it!)

What are the basic considerations/differences in horizontal vs vertical calibration and control? I suspect belt tension measurement use offsets that account for gravity tension on TL and TR for the weight pulling down on sled. Anything else?

[bar]

The real big difference is that in vertical mode the top two belts are always used to move around, while in horizontal mode we use whichever two belts are pulling based on the direction of the move (because belts can’t push)

[gazinux]

For experimentation, brainstorming, or as a diagnostic tool, we could reverse the calibration process by physically moving and locking the sled to ground truth locations i.e. start with the center point of the frame, then perform a belt tension tract until the belt tension threshold current is reached for each arm. Use a spring guage or something to read the actual belt tension on each arm. This could be used as a sanity check that (a) all four belts are within a deemed tolerance tension range of each other and that this tolerance is generally maintained at each ground truth test location and (b) to experiment with calibration and control techniques that use a lookup or gradient table to adjust the max belt tension current threshold for each arm at each position on the workpiece for each Maslow in the wild.

[CPL]

Driving home this evening, it occurred to me that one (probably minor) source of slack might be that people are using the outer dimensions of the frame, rather than the dimensions between the anchors.

For the standard frame, this is the would be the difference between 96"x120" and 92"x116"- 4" (100mm) in each direction. For the diagonal, that’s 5 1/2" (140mm) of extra slack.

[Will]

I would like to make a suggestion that would include the use of a spring on each cable.
Obviously, if the calibration requires slack cables in the process, my suggestion is null unless you incorporated a consideration for some slightly tensioned give.
The mechanical concept is easy. On each cable (or at least the bottom two if you’re not horizontal) goes a spring and a cable in parallel. The idea is that the cable should always be in tension and the spring is stretched.
During the calibration process, it could be that the spring has to do work of keeping enough tension so the belt doesn’t go twisted.
My first attempt of hardware test would be like a 4 to 6 inch long spring rated for single digit lbs. The cable would be a length that would not over pull the spring but would give a couple inches of tension. The cable would have loops and tied with crimped aluminum slugs.

I would like to know if this idea is even technically feasible with relation to the calibration process. Otherwise, I believe this to be a suitable tensioner.

[gazinux]

I was going to post this same idea, tension springs at anchor. please keep us posted!

[dlang]

the problem is that without knowing the tension in pounds, and the springs, you
can’t know how long the belts are, so you can’t calculate where the anchors are,
so you can’t successfully calibrate.

David Lang

[gazinux]

The spring is not configured in series with the belt it would be parellel. The spring gives a slight restoring force that’s it. Belt end would still be anchored exactly the same way and hard stop for meaurments. As long as a the spring’s max resistance is low, does not result in the movement of the sled, and is well below the force M4 asserts at the current threadshold for a read-distance measurment it should work.

[Carson_Barry]

It needs to be more clear in the assembly/setup guide that the index.html file should be updated whenever someone updates their firmware. The current wording makes it sound like it is something that only needs replaced when updates to it specifically are called out, rather than just being parallel to firmware.

Also it seems like we have to use inaccurate frame dimensions (smaller than actual frame by ~150 mm) to not have the default settings for calibration pull the sled off the bottom of the spoil board when working with a 4x8 spoil board on a vertical 12 ft frame. That said, aside from the very first measurements, I didn’t have to tend the belts at all for a default settings run with the most recent firmware with 3400x2000 mm set for a 12 ft frame. Accurate measurement was 3530x2386. My fitness only got up to 0.22ish and it never gave me a final report, plus my sled moved diagonally when told to move horizontally and gave out a lot of slack during manual movements after that calibration, so it must have not gone well.

Of course, I ran that with the .68 firmware and no updates to the index.html that was on the device when it arrived, so I can only imagine that is contributing.

[CPL]

OK, so I don’t know if I can provide anything new, but I’ll at least add to the conversation.

I am running 0.69.

One general, non-calibration observation- I had A LOT of disconnects (No heartbeat) and only recovered from one. I tried multiple computers and browsers with no solution. Only in hindsight do I wonder if this is due to the fact that I had configured the M4 to connect to a WiFi access point, but It was too far away to connect- I wonder if this was the cause- I will investigate further. Except as noted, I will not mention the disconnects.

The only really stand-out issue was one instance where the upper right belt just kept extending until the all of the belt was played out and actually started to wrap around the other way. I quickly killed power and I never saw anything like that again.

I measured the anchor-to-anchor distances with a metric graduated tape measure- not perfect, but probably accurate within 5mm. I used these measurements to configure the calibration process.

• After changing the calibration settings, I power cycled and re-verified the settings.
• I then did
  • Retract All
  • Extend All
  • Calibrate

Everything worked as expected. I did not have to tend the belts and the calculations were quick, with the following results after 400 passes;

Fitness: 1.160452386116394
Maslow_tlX: 0.5
Maslow_tlY: 2363.0
Maslow_trX: 3579.2
Maslow_trY: 2363.0
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3572.7
Maslow_brY: 0.0

To see how repeatable this was, I reloaded the initial maslow.yaml file, power cycled, and ran it again, with the addition of a tension after retract and extend and before calibration. Again, no belt tending needed and this time after 4500 passes I got;

Fitness: 1.5768336643895613
Maslow_tlX: -0.5
Maslow_tlY: 2353.9
Maslow_trX: 3578.7
Maslow_trY: 2363.0
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3577.6
Maslow_brY: 0.0

Not identical, but close.

Thinking that doing the tension before calibration might have made a difference (even though that appears to be the first step of the calibration process, I again reloaded the initial yaml, restarted, did the retract, extend, tension, calibrate, and this time after 5500 passes I got;

Fitness: 1.374156216552179
Maslow_tlX: -5.8
Maslow_tlY: 2355.4
Maslow_trX: 3579.4
Maslow_trY: 2363.0
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3571.9
Maslow_brY: 0.0

Given the variation in results, I rotated the M4 180 degrees and went through the exact same process. This time it took only 300 passes to return;

Fitness: 1.0332350382400288
Maslow_tlX: 0.6
Maslow_tlY: 2363.0
Maslow_trX: 3578.3
Maslow_trY: 2363.0
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3572.9
Maslow_brY: 0.0

Given the issues that have been noted in portrait orientation I decided to try rotating 90 degrees. To keep track of the rotations, I marked one of the anchors- the one that had been in the lower right in the first three calibrations and in the upper left in the fourth.

I repeated the same procedure as above, except I flipped the width and height values to reflect the orientation. 500 passes-

Fitness: 1.1440824224435107
Maslow_tlX: 0.0
Maslow_tlY: 3581.0
Maslow_trX: 2362.6
Maslow_trY: 3570.4
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 2364.4
Maslow_brY: 0.0

Obviously, because the bl is always 0,0 and the br is ?,0, the results of different orientations can’t be directly compared. I therefor decided to normalize all the layouts. I created a spreadsheet, calculating the distance from each anchor to the other three as follows;

Then, based on the location of the marked anchor, I rotated each set to normalize them to one another;

This way I could directly compare the results of each of the tests. (More on this later)

I did another pass with the opposite portrait orientation, 2000 passes this time;

Fitness: 0.9861474876265609
Maslow_tlX: 0.0
Maslow_tlY: 3581.6
Maslow_trX: 2357.5
Maslow_trY: 3573.4
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 2363.0
Maslow_brY: 0.0

I haven’t been mentioning it, but there had been no belt tending and other than many disconnects no issues.

Up until this point, I had been reloading the original yaml each time- I was not iteration on previous results. I had noticed that after finishing a calibration, after a restart, but before re-loading the yaml, the width and height had been updated to values from the previous calibration.

With the intention of now exploring the iterative process, I returned to the original landscape orientation and ran a new calibration. 500 passes resulted in

Fitness: 1.428265371706063
Maslow_tlX: 0.0
Maslow_tlY: 2363.4
Maslow_trX: 3578.0
Maslow_trY: 2363.0
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3571.9
Maslow_brY: 0.0

After restarting, I noticed that the values in the calibration configuration dialog had not been updated. Without thinking, I hit save, and downloaded the yaml file, only to discover that it contained updated values except the ones that had been overwritten by my saving the configuration.

At this point I should mention one issue that I had noted intermittently. Sometimes the calibration configuration dialog would contain what appear to be parsing errors such as seen here in the calibration grid width

I saw this in various fields, but never more than one at a time, and I feel like it may have been in cases where I suffered a disconnect and reloaded without first closing the old page/tab. I can’t be certain of this, but once I noted this it seemed to hold true.

So I did another calibration from a clean yaml

Fitness: 1.2425819411341716
Maslow_tlX: -5.1
Maslow_tlY: 2369.6
Maslow_trX: 3578.2
Maslow_trY: 2363.0
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3563.3
Maslow_brY: 0.0

which disconnected right at completion but was my only successful recovery- then without replacing the yaml went to a 600mmx300mm 4x3 (still with no belt tending)

Fitness: 0.6768156527426736
Maslow_tlX: -5.0
Maslow_tlY: 2369.4
Maslow_trX: 3577.7
Maslow_trY: 2363.0
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3563.3
Maslow_brY: 0.0

I then followed this up, again without replacing the yaml, with a 2000mmx1000mm 10x10. Unfortunately this failed at point 65, was not recoverable, and at this point it was 2am so I quit.

I did feel like I had to tend the belts a bit on this last large calibration. The scariest moment was near the beginning when it was moving from the bottom center to the bottom left- there were loose loops of belt which I was afraid might cause them to be caught in the gears, but gently pulling the affected belt was sufficient. Watching the process, belt tending was much more of an issue the closer the sled was to an anchor, as there was more belt on the spool and thus it spilled over.

On the other hand, since the ‘trailing’ belts are in compliant/'extend all" mode, anything other than the gentlest handling caused additional belt to be fed. Except for the lefthand most set of points, I did not tend the belts (although I never felt comfortable not continuously monitoring them), and the calibration failed before it reached the right side.

Here are all of the terminal logs for all the (successful) calibrations (and the last failed one) in case there might be anything of value there (unlikely). <edit- reuploaded w/ better headers>
Maslow Calibrations.txt (32.9 KB)

And here is the spread sheet with all the normalized values.
Maslow 4 Calibration Calculations Pass 21-4-24.xlsx (16.6 KB)

I expected the two diagonal values (E and F) to have a lower variation that the four sides, as I would expect cumulative errors to cancel out, and in general this is true.

What I find extremely interesting is that the normalized “D” value- which remember represents different sides with different orientation- has an extremely low variation. It would appear that there may be some bias in the calculations, and that it might be based on the relative locations of anchors to one another- not to the M4’s orintation. If this is the case, this might explain why some users have very straightforward calibration experience, while others struggle.