The best fitness I was able to achieve in v0.68 and v0.69 at any grid size was 0.4. Most attempts were less then .1. I assumed this was mostly due to the trouble I was having with the BR cable at waypoint 3.
v0.69.1 did not have the same issue at waypoint 3 and the initial fitness scores prove it. But the longer the calibration ran the worse the score. The loosest cable at the end was always BR.
Below is a summary table of my 5 calibration attempts with v0.69.1
Retraction Force Voltage
Center point deviation
0-8 Fitness
9-24 Fitness
25-48 Fitness
1300
TL: 0.144 TR: 0.219 BL: -4.910 BR: -16.488
1.52
0.53
0.46
1300
TL: 0.215 TR: 0.206 BL: -5.363 BR: -13.518
2.05
0.62
0.41
1800
TL: 0.263 TR: 0.332 BL: -7.160 BR: -11.768
1.31
0.494
fitness too low
1800
TL: 0.268 TR: 0.292 BL: -2.795 BR: -8.976
1.1
0.54
lost connection
1300
TL: 0.222 TR: 0.187 BL: -4.479 BR: -8.861
1.43
0.46
fitness too low
Observations from the first phase of calibration:
The center point was measured first and then only the perimeter of the 3x3 grid was measured in a clockwise outward spiral. There was no duplicate measurement of waypoint 0 or waypoint 1 that we used to get. As before during vertical calibration the top 2 cables were used for travel, they were never slack. The bottom 2 cables would decompress and then both would comply as they traveled. Then both bottom cables would take turns tightening before measurement. Cables would tighten right then left for waypoints 0,1,5-8 and right then left for points 3-4. During the left travel compliance was needed for the BR cable as it was moving away. Unfortunately the BL cable was also getting fed out (maybe because the subtle jostling of the sled triggered movement in the encoder?) This resulted in a lot more slack than needed at all of the bottom left waypoints. I also noticed the worst center point deviation was consistently the BR cable. Maybe an issue with my frame?
Observations from the later phases of calibration:
Waypoints continued the outward spiral in a 5x5 then 7x7 grid perimeter. I sometimes noticed a bit of decompression from the bottom 2 cables before traveling. It was much less then the first phase. The bottom cables were not compliant and often had tension during travel. They moved in/out instead of relying on slack. Despite this sometimes the bottom cables would accumulate a bit of slack, particularly the BR. Like the prior phase bottom cables would tighten for measurements. I noticed the amount of slack in the bottom cables would increase as the sled was near the top. The most snug the cables were during movement was the first few travels on the bottom to the left (immediately after the successful first 3x3 calibration).
Observations about my Maslow:
I noticed sometimes (more than a few) waypoints the bottom right cable would remain slack during measurement. Some other times when I felt the tension during retraction the BR cable would not be as tight as the others. Most of the other times it was plenty tight. To mitigate this I changed the Maslow_Calibration_Current_Threshold from 1300 to 1800. This solved the tension issues but did not have an impact on the fitness scores.
Suggestions:
For initial vertical calibration make both cables compliant for upward travel, neither compliant for downward travel and only one compliant for left or right travel. I was looking through the v0.68 code and I think I know where this can be changed.
Maybe have an option for a counter-clockwise spiral. Vertical orientation breaks one axis of symmetry and clockwise order breaks the other axis. I don’t know if there is an issue with my particular BR arm or if there is a general issue with the bottom opposite-of-spiral arm. I need another data point (BL).
With multiple phases it would be good to insert timestamps between each phase. I would like to know where my time is spent. How long for each phase and how long for taking measurements vs calculation.
I noticed sometimes (more than a few) waypoints the bottom right cable would
remain slack during measurement. Some other times when I felt the tension
during retraction the BR cable would not be as tight as the others. Most of
the other times it was plenty tight. To mitigate this I changed the
Maslow_Calibration_Current_Threshold from 1300 to 1800. This solved the
tension issues but did not have an impact on the fitness scores.
If the belt is not tight when the measurement is made, it’s not going to be an
accurate measurement, so it’s a good thing the machine is warning you.
I think the first thing you need to dig into is why is that bottom right arm not
working reliably.
The maslow decides a belt is tight based on how much force the motor is applying
to that belt. If it’s triggering when the belt isn’t really tight, there are a
few things you can do.
you can increase the limit in the settings.
you can excercise the arm (extending/retracting the belt) to see if a little
bit of wear makes it move more easily.
you can remove the arm and see if there is anything you can do to make it
move more smoothly (are the bolts too tight? can you add some of the silicon
lube? is there anything else ‘odd’ about the arm?
I think that until you solve the belt not being tight enough, nothing else
matters.
Suggestions:
For initial vertical calibration make both cables compliant for upward
travel, neither compliant for downward travel and only one compliant for left
or right travel.
from the videos, it really doesn’t look like any belts are ‘compliant’, it looks
like they are being fed out based on what is expected, not based on tension.
Or is it that the weight of the belt provides enough tension to fool the system? @bar ???
Maybe have an option for a counter-clockwise spiral. Vertical orientation
breaks one axis of symmetry and clockwise order breaks the other axis. I don’t
know if there is an issue with my particular BR arm or if there is a general
issue with the bottom opposite-of-spiral arm. I need another data point (BL).
you can also swap the position of the arms and see if the problem follows the
arm.
With multiple phases it would be good to insert timestamps between each
phase. I would like to know where my time is spent. How long for each phase
and how long for taking measurements vs calculation.
Oh man I wish it warned me! It took a lot of careful/lucky manual observation to notice this.
Your comment reminds me of another observation. During initial assembly and testing I would pull on the cable during retraction to trigger the threshold causing it to stop. I did this for different voltage thresholds and at different times in the retraction ramp up. I can tell you the tension is very different when retraction starts vs when it is winding full speed. The voltage is the same but the tension was much weaker at the start of retraction. I would urge caution about equating voltage threshold with assumed tension. I’m not sure this is fully accounted for in the firmware. Though this effect seemed to be greatly reduced at the higher thresholds.
I’ve addressed it by point 1, continued patience by point 2 and experience/reluctance to undertake point 3. At least 2 of those calibrations were mitigated with the higher limit (the first column in the table) and I feel confident with the observed tension that they were good measurements. I thought the same as you, I was very hopeful for a good calibration after bumping up the voltage threshold. I just knew that was the silver bullet… Now I have some data that shows good fitness with low threshold setting and poor fitness with consistently good tension. ¯\(ツ)/¯
After that I paid attention to it and observed it in all the rest of my calibrations. You can feel it feed out more belt when you pull on it during travel. You can see it stop if you help relieve the weight of the belt.
Oh man I wish it warned me! It took a lot of careful/lucky manual observation to notice this.
I was thinking of the ‘fitness too low to use’ warning
I’ve addressed it
apologies if I said things I had already told you, there are so many people
working through the issues that it’s hard to keep track of who’s who.
I thought the same as you, I was very hopeful for a good calibration after
bumping up the voltage threshold. I just knew that was the silver
bullet… Now I have some data that shows good fitness with low threshold
setting and poor fitness with consistently good tension. ¯\(ツ)/¯
I misunderstood your post, I thought you were saying that when you were
calibrating, you had one belt consistantly with low tension.
After that I paid attention to it and observed it in all the rest of
my calibrations. You can feel it feed out more belt when you pull on it during
travel. You can see it stop if you help relieve the weight of the belt.
I think this is the most important observation. If the belt is feeding out
because the weight of the belt is enough to provide the needed tension for
continuing to feed out the belt, that explains the ‘way too much belt’
experiences that people are having.
I can’t think of an easy answer when you don’t have any idea of the frame size
(other than a version of comply() that takes a parameter limiting how much can
be fed out).
Mine is still calibrating using v69.1 but the initial smaller grid was .68 and the second larger one is now .78 so things seem to be moving in the right direction. total belt slack looks to be much reduced as well!
EDIT: I also made a slight change in my belt end mounting, i’ve added my 1" spacers to make the belt ends the same height as my calibration plate.
EDIT2: so it did a 9x9 calibration grid 2082/863 (I took a 4/8’ sheet and took off 14" to account for the sled diameter). Point 80 was at bottom right of the largest grid. then when it moved back to the center for point 81, it let out too much slack on the lower right belt and the belt jumped the spool getting onto the upper right motor’s spool. I didn’t notice until it moved back up to the center. I then hit the stop button via the web interface and was unable to do anything else until i restarted the maslow board. I’m going to run another calibration and pay particular attention to the move on the last point as to not get the belts tangled.
EDIT3: additional calibration run went great. It got fitness in the mid 80’s for the inner grid, but ended with .65 for the outer most grid. I kept a eye on the final movement between points 80 and 81 and achived no belt jumps.
This is I would say from a physical standpoint fully understandable. A motor at a higher RPM needs less current then a motor at a lower RPM. But I don’t think, this is important for calibration, because the tension is measured at a standstill. Only during travel this effect could maybe cause problems. (keyword self-induction)
Finally I measured all distances of my frame with my laser. I could make it better probably, but not without help. Still I would say the accuracy is around ±2mm. Now we can compare my results with my measurements.
Here is version 0.69.2 which uses the same calibration pattern as 0.69.1 with two bug fixes.
First we weren’t recomputing the center point after each time that that the new calibration data was sent…that was only happening with a restart. Fixing that should help the process to run more smoothly.
Second a bug with the move back to center at the end was making the machine move unexpectedly fast which was startling.
Should I see the intermediate versions on the UI? I see the following after uploading these two files (updating firmware with firmware.bin and the ui with index.html.gz)
No, they won’t show up there, although I would expect to see 0.69 for the index.html version.
I also just discovered (and am fixing) a bug that I think will cause you trouble on 0.69.2 It wasn’t respecting the user selected grid size which isn’t going to play nice with portrait mode. I have a fix for it that I’m testing which should be out in a few minutes.
Here is version 0.69.3 which is really just a more polished version of 0.69.2
The big fixes are that you can now set the calibration grid size and also the number of points (3x3,5x5,7x7 or 9x9). There are also several other bug fixes including that the calculations are faster and also that the final move back to the center after the process is finished is smoother.
@ronlawrence, if you started with the Excel numbers and ended up with numbers from the M4’s calculations, do you think it was an improvement? When I look at the fit values in the log they didn’t seem to change at all, although the first value was from 200 iterations so changes may have happened before that. Do you have or can you get, the official fit value using the Excel values unmodified by the M4?
Using 69.3, have you tried starting with a rough estimate for the frame, not the precalculated numbers from Excel, and found where it ended up? My suspicion here is that this last calibration started with known good values from Excel and the Maslow just tweaked them a little.
Probably spot on. I’ll try again tonight after work with rougher numbers to start (8ft x 8ft) and see how it does by itself. I can maybe try a big calibration too with it up at 8x12… We’ll see how much time I have.
That also matches up with my experience of good calibration runs. In theory we should see zero change between runs. In practice I will see things bounce around by 1-2 mm between runs.
