I’ve been doing some more fundamental research on how we can improve the calibration process and I’ve come across the Levenberg-Marquardt algorithm which is often used for camera calibration. It seems like it could be pretty ideal for helping us to locate the anchor points in a more reliable, fast, and accurate way.
I am going to work on implementing it, but I wanted to post to see if anyone happened to have experience with it 
Nice!
It’s not one I know, but it makes sense from the Wikipedia description.
Do you have sample code you can try on some extracted sets of points, or are you going to implement it straight into the code and test it that way?
It’s been a while since I looked at the code - how easy is it to keep what’s currently there and offer the choice of algorithm for the user (and even make it easier to add more options in the future?
Because actually testing changes on the hardware is such a slow process I built a couple of simulators to make testing faster.
One runs on data sets recorded from the machine in the past, and a second one will simulate the process of taking measurements with the option to add things like random error to each measurement or constant error (like every measurement is 5mm too long) to see how that impacts the results.
I’ve got the new algorithm running there (thanks to AI) and it seems like a huge improvement at least in the simulation. It’s about 300 times faster and it shouldn’t get stuck sometimes the way that the old one does.
Hopefully I’ll be able to test it on the hardware later today.
There is a PR open if you want to give it a try: Add Levenberg-Marquardt algorithm for anchor calibration and set it as default by Copilot · Pull Request #919 · MaslowCNC/Maslow_4 · GitHub
Gave it another try, very fast processing, Results very similar to original V1.20. Details in the #919.
Excellent! That is a great first data point.
The question now is it more precise than the old algorithm.
One of it’s strengths is that it should be less impacted by initial conditions so it should produce the same result more reliably than the old system
Trying it again, this time I set it up as 3000x3000 square. It completed then restarted, I think this may have been because I had2 browser windows open. It’s still running on 2nd iteration, after 1st the following values loaded.
Fitness: 1.0322332
Maslow_tlX: -166.5
Maslow_tlY: 4036.8
Maslow_trX: 4505.7
Maslow_trY: 4006.6
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 4538.4
Maslow_brY: 0.0
Got the same error message
[MSG:ERR: Calibration data not acknowledged by computer, resending]
Opened another session which allowed it to complete
I would love feedback from more folks on how this is working. It seems to be working great for me, but testing it in more situations is important.
Notice how the calculation step is now almost instant
firmware.bin (1.9 MB)
index.html.gz (137.4 KB)
I tried it setting the initial width and height values for 3000x2400 and it looked like it was going to fall off the table on the last iteration, so I hit power. As it turned out it wasn’t heading for oblivion, just offset by 100mm or so. The values it came back with were very similar to every other time. It does tend for the controlling PC to not accept the last set of values and it keeps resending. 3 times
[MSG:ERR: Calibration data not acknowledged by computer, resending]
This can be alleviated by opening another browser session.
Yesterday result from 3000x3000 start
I think that we might be getting the answer so much faster than ever before that it’s throwing something off in the communication
Bar wrote:
I think that we might be getting the answer so much faster than ever before that it’s throwing something off in the communication
the fix is probably to do the calculations in the firmware rather than doing the
bouncemack to the browser.
David Lang
I noticed some people had this problem in V1,20 so I’m not sure that’s it.
This from Moving onto 1.20
I have been running some tests with various versions of maslow.yaml, slightly modified for my setup.
Yesterday I was starting with the supplied yaml modified to reflect my Z values only. At the end of the 2nd iteration it failed with the following:
LM converged in 15 iterations, fitness: 0.3165228
Result: tl=(-153.6, 2431.8) tr=(3292.5, 2420.0) br=(3332.3, 0)
Calculated Fitness Too Low (0.3165228 < 0.45).
Maximum retry attempts (10) reached.
Best fitness achieved: 0.3165627
Updating initial frame size with best estimate from all attempts.
Find Anchors stopped due to low fitness after maximum retries.
Options:
** 1. Click “Find Anchors” to restart.**
** 2. Check to make sure that all four belts are fully tight with each measurement.**
** 3. Check to see if the frame could be flexing when the measurements are taken which will lead to inacruate measurements.**
When it failed, 2 of the belts were slack.
I repeated the run without changing anything, Same result.
Today i did the same thing with only one modification.
I changed teh Extend distance to match my setup (1975) instead of the 2600 it was set to in maaslow.yaml.
Result: Completed with no errors.
Ian Abbott wrote:
I changed teh Extend distance to match my setup (1975) instead of the 2600 it was set to in maaslow.yaml.
Result: Completed with no errors.
when you had the default 2600 how far off from center is the sled when the belts
pull tight?
I’m trying to think how extending too much could possibly cause grief, and the
only think I can think of is that when the belts pull tight from a longer
distance, something is going wrong
ways I can think of it going wrong
David Lang
It was still pretty much centered after pulling belts tight, and all belts were tight at the beginning of the run. As it progressed the trailing belts gradually got slacker on each iteration. I don’t understand it either, although I have seen something where someone reported a similar effect.
I decided to play a little. I turned the Maslow 180 degrees and ran the Find Anchors. I didn’t change the Z values to compensate as my wall anchors are at a distance and I have the opposing arms next to each other, so minimal change.
It ran the Find Anchors and finished after a little nudge by opening a 2nd browser window after the Maslow returned to the centre. The following is a comparison of the changes to the maslow,yaml file.
Worked out what it was. Two of the arms were binding. I have fixed now. nothing to do with Extend distance.
