I actually completed a calibration!
now to go back and fix some more stuff…
I actually completed a calibration!
now to go back and fix some more stuff…
Congrats
this should work, but it lost a lot of work, it uses a spaceing of 25mm between grid points, lost the maslow.yaml config, and probably a bunch more
It overwrote the maslow.yaml file with old crap
Tried this again this morning. Failed immediately. Logs attached
Maslow-serial - 2025-10-11T081813.497.log (6.3 KB)
ConfigRunSerial20251011T0818.txt (12.4 KB)
This has been a VERY frustrating couple of days, but I have a version that seems to work, please give it a try
I verified that this works if you do not enable automatic mode, and in automatic mode (my 700mm square frame with 75mm grid spacing and on a 40mm spacing)
Problems:
it does not go to every point on the grid (and copilot informed me that having it do so is out of scope and should be a separate PR)
I don’t like how it moves (it seems to move one way and then back moving from point to point
but again, it seems to work on a horizontal frame
Trying this now, it has been going for about 15 minutes, fitness is still less than 0.1607
Getting worse again, killing it, haven’t got the serial data from USB, was trying with putty, but it closed the connection. I have got the Maslow’s
Ok, that won’t work (that problem isn’t solved by this code)
is this on the initial 6 points?
it reports where these are in the log, can you send me what you have?
did these initial 6 points look like you expected? (and if so, what changed to
give you such a low fitness now when it worked before???)
David Lang
I sent the log file
CLBM:[{bl:3013.02, br:3100.69, tr:3014.48, tl:3098.65},{bl:3109.84, br:2992.01, tr:2917.40, tl:3212.24},{bl:3135.45, br:2998.19, tr:2890.63, tl:3184.02},{bl:3117.26, br:3128.36, tr:2913.64, tl:3080.25},{bl:3014.40, br:3217.99, tr:3023.47, tl:2984.85},{bl:2971.49, br:3116.82, tr:3057.87, tl:3051.69},]
No Maslow was not moving like it has every other time it was going out then pulling back nothing like previous pattern. no change to how I proceeded. Load firmware, powered down restarted did REC dance then kicked off Find Anchors
give this one a try, it should not go to all points in the grid and not jump around in the middle (I am about to load it and try it on my system)
if this still doesn’t give you a good fitness, try reducing the grid spacing (default 400) in the yaml file to something smaller so there are more points in the grid.
same fail again and
I don’t have an entry for grid spacing in the yaml file
working on it. sigh, when moving to a new issue/pr it once again didn’t pull all
the changes forward
David Lang
One thing that may have caused the low fitness is that you had trouble with belt measurements being inconsistant
MSG:ERR: Measurement error, measurements are not within 2.5 mm of each other, trying again]
[MSG:INFO: Max deviation: 3.361]
[MSG:INFO: Bottom Right 3053.615]
[MSG:INFO: Bottom Right 3050.254]
[MSG:INFO: Bottom Right 3050.813]
[MSG:INFO: Bottom Right 3051.091]
[MSG:INFO: Top Right 3057.823]
[MSG:INFO: Top Right 3057.834]
[MSG:INFO: Top Right 3057.845]
[MSG:INFO: Top Right 3057.855]
[MSG:INFO: Top Left 2971.482]
[MSG:INFO: Top Left 2971.482]
[MSG:INFO: Top Left 2971.482]
[MSG:INFO: Top Left 2971.482]
[MSG:INFO: Bottom Left 3113.394]
[MSG:INFO: Bottom Left 3115.283]
[MSG:INFO: Bottom Left 3115.949]
[MSG:INFO: Bottom Left 3116.260]
[MSG:DBG: Waypoint 5 measurements: [0:TL=3051.55,TR=3057.87,BL=2971.48,BR=3116.73] [1:TL=3051.65,TR=3057.87,BL=2971.49,BR=3116.81] [2:TL=3051.74,TR=3057.87,BL=2971.48,BR=3116.87] [3:TL=3051.82,TR=3057.87,BL=2971.48,BR=3116.87]]
you may want to increase your calibration current slightly
aughh copilot is now imposing a limit of 23 commits in a PR, then it starts saying "I have 23 commits and have fixes everything that was listed in the original issue (even if it broke things in the meantime) and refuses to do any more work on that PR
I’m working on an improved version
give this one a try (lots of log spam, but it just worked for me end-to-end)
it is still doing funny movement between measurements. In my case the measurement points are 50mm apart and it goes off about 100-150mm in a seemingly random direction before coming back to the next location.
edit: it would help if I included the link ![]()
Still not working for me. It ran out a lot of belt while it was doing the initial waypoints and because of that the adjustments were very forceful when it re-tensioned, much rougher than the existing configuration. I left the calcs going for about 30 minutes with it never getting anywhere finding the anchor points. Logs attached
ConfigRunSerial20251012T0845.txt (10.0 KB)
Maslow-serial - 2025-10-12T091515.424.log (145.5 KB)
I was looking at grok last night on ways to improve the calibration process and during the process I put in the numbers from your last attempt
A: (0.0, 0.0) mm (fixed origin)
B: (5931.0, 0.0) mm
C: (6033.8, 1373.2) mm
E: (46.7, 1288.7) mm
(Note: As before, "ABCD" refers to the fixed frame A, B, C, E, with D as the moving end-effector.)
Error Quantification
With only 6 measurements, the system is minimally overdetermined (12 constraints for 5 parameters + 12 D coordinates), leading to higher sensitivity. The fit achieves an RMS residual of 8.65 mm on BR and BL distances (mean absolute ~6.9 mm), indicating the data has an effective noise level of ~8-9 mm per measurement—much higher than the ideal 0.1 mm, likely due to simulated errors, limited point diversity, or slight ill-conditioning (Jacobian condition number ~96,000, amplifying vertical uncertainties).
from reduced chi-squared (dof = 7). Resulting 1σ uncertainties (to 0.1 mm):
x₁ (B_x): ±116.0 mm
x₂ (C_x): ±159.5 mm
y₂ (C_y): ±713.5 mm
x₃ (E_x): ±31.3 mm
y₃ (E_y): ±661.7 mm
absolutly horrific errors from that.
copilot broke the version I just posted when I told it to remove the debug logging, so it’s fixing that now
once that gets done, I’m going to try and change the move_while_slack() function that claims it feeds out belt for 3/4 of a second before moving (it seems like longer than that to me) to instead put the non-pulling belts in comply mode to see if that helps.
standby for the next iteration
Also after restarting with this version, I need to click on Release Tension twice. 1st time releases tension on bl–>tr 2nd Br–>tl
Ian Abbott wrote:
Also after restarting with this version, I need to click on Release Tension
twice. 1st time releases tension on bl–>tr 2nd Br–>tl
the current implementtion of release tension just puts the belts into comply
mode for a very short time. I’ve had to hit release tension a couple times
myself
David Lang