I added it in the comment above. Just click on index.html (47.1 KB)
1 Like
Do you have the uncompiled code by any chance? Itās tough to decipher what changed once itās compiled into the index.html file
It is actually from the Calibration Simulator which is not compiled at all. I updated the algorithm a bit to ensure a correct solution. However, at line 363 you can tweak how many outlier are removed. The new file is here:
index.html (47.1 KB)
1 Like
Ahhhhhh my mistake. Iām sorry for not understanding. Thank you!
These changes look great!
I put together a pull request here which makes it easy to look at what has changed and comment on it: Changes from https://forums.maslowcnc.com/t/loose-belts-during-calibrā¦ by BarbourSmith Ā· Pull Request #5 Ā· BarbourSmith/Calibration-Simulation Ā· GitHub
Any chance I could talk you into throwing a couple comments on there with what changed and why so I can better understand?
Overall this looks like an excellent contribution 
1 Like
Perfect. I am happy to help. I will comment it in the upcoming days. I have another approach for you. I have re-implement it in python based on optimizer. It uses another metric. However, at the end there will be also printed the Fittness for completeness. But do not compare it to the html version because as I said, the minimizer uses another metric. After the run a .obj file will be generated and at least in my case, I think it is very interesting. You can see clearly, that the error is related to the direction of the sled (red means higher residuals). A possible interpretation could be that the order of the two belts that are tightened should be randomly.
residuals_med.obj (31.8 KB)
calibrate.py (13.2 KB)
1 Like
or we need to go around and tighten all belts rather than just pulling on each of them once.
1 Like
Iāve noticed this pattern of the largest error being on the far edges o the data, but I havenāt seen the that the upper left and lower right are noticeably worse. That is a very interesting find.
I agree that the belts tightening order could be a factor or there could be some other variable that we need to adjust. The next one on my list is to play with compensating for the thickness of the material being cut and see if that has an impact.
INFACT! Clearly in this data the top left is the worst and the bottom right is the second worstā¦AND the top left arm is the highest and the lower right arm is the second highest so this looks to me like we are introducing some error with the height of the arms.
1 Like
and I just made a post about this
the belt length calculations donāt take into account the fact that the belt is
not making a perfect triangle. once you add that, you add a noticable amount of
error that seems to correlate with this pattern.
David Lang
2 Likes
I do not think so. In my estimation I do a hight compensation for the fit as well. Therefore, it should be compensated. However, if you take a look on the shown residuals, the red dots are there where the maslow was moving from bottom to top or the other way around. For example the lowest right one is totally black (malsow was moving from right to the left). Next, it was moving to the top and the red color begin. This kind of shape is clearly visible on both diagonals. From left bottom to the right top all residuals are black (horizontal movement). On the diagonal from top left to the right bottom the residuals are red (vertical movement).
1 Like
Ulmair wrote:
I do not think so. In my estimation I do a hight compensation for the fit as
well. Therefore, it should be compensated. However, if you take a look on the
shown residuals, the red dots are there where the maslow was moving from
bottom to top or the other way around. For example the lowest right one is
totally black (malsow was moving from right to the left). Next, it was moving
to the top and the red color begin. This kind of shape is clearly visible on
both diagonals. From left bottom to the right top all residuals are black
(horizontal movement). On the diagonal from top left to the right bottom the
residuals are red (vertical movement).
The fit is worse when the highest arms have the shortest belts, which
corresponds to the error I identified from not taking into account that the arms
are flat, not on the same slope as the belts.
Do you have a way to solidly raise the belt anchors so that the belts are flat?
if so, could you do so and change the Z offsets and re-run the calibration
and see if the errors in those areas go down? you donāt need to raise each one
all the way to flat (although I think that would be ideal), just significantly
reducing the offset for the top arms would be enough to show the difference.
when you are in those worst corners, how far are you from the closest anchors?
David Lang
I had a lot of different settings, horizontal, vertical orientation combined with variable anchor heights. At least in my case, if the anchor points have the same height as the maslow arms, then the maslow begin to wiggle, i.e. the maslow table does not lay flat anymore on the tabel.
1 Like
Looking at it with fresh eyes Iām not so sure anymore. If it were just about the height of the arms we would see an error distribution closer to the corners but thatās not quite what we are seeing.
Iām still going to play with it, but Iām not quite as sure as I was
Iām able to run the code (which is awesome), how are you generating that neat visualization of the error distribution?
Please excuse my terrible freehand+mouse sketching, but
thatās exactly what we are seeing.
Or perhaps more correctly itās a corner to corner problem, thatās exacerbated by arm height.
Looking at the above image Iād say that there should be an advantage in having the greatest relative difference between arm heights between those furtherest from each other.
Current arrangement is (highest to lowest in the stack of arms) TL ā> BR ā TR ā> BL, but this results in the greatest relative height difference between TL ā BL
Iām wondering whether a better arrangement (for both āon-the-floorā and āon-the-angleā) to be (highest to lowest in the stack of arms) BL ->TL ā> BR ā TR
1 Like
Lee H wrote:
Iām wondering whether a better arrangement (for both āon-the-floorā and āon-the-angleā) to be (highest to lowest in the stack of arms) BL ->TL ā> BR ā TR
give it a try, all you need to do is reorder the arms and change the Z offset
values.
David Lang
1 Like
And modify my frame again ā¦
1 Like
I think what he was saying is that the error distribution isnāt completely clustered in the corners so the height of the arms alone doesnāt fully explain the resulting errors. For instance, the first column stays very red nearly all the way down, then fades quickly to black. However, in the second column, the first point is black, and in the third column, the second point is black. If it was solely the height of the arms, then those patches of black do not make much sense and youād expect things to more radiate out evenly towards the center. Also, why are the first and bottom rows nearly completely error free (except in the far corners), but similar results donāt show up in the columns (i.e., if the lower arms are keeping the machine in place in the top and bottom rows giving us all the dark dots, then why doesnāt it have any effect on keeping nearby errors out of their columns?). The graph definitely indicates something going on in those corners, but I donāt think the arm height quite explains everything wrong in the graph. Itās possible there is a combination of issues and not solely the arm height.
1 Like
Projecting the various arm heights out can give this visualisation
The alternative that I suggested (BL ->TL ā> BR ā TR) looks like this when performing the same kind of visualisation
1 Like