Can you explain this more? This sounds very interesting 
1 Like
I probably should have qualified that more than I did, it’s more a series of vague notions than a fully formed idea.
I’ve got a couple of hours of errands and driving to do, once I’m home I’ll try to write something up.
1 Like
OK, again let me preface this by saying that this is a very small data set. The results do however conform to some of my expectations- and some hunches. I do not have any concrete, actionable theory- and it’s probably all nonsense in the end.
The fact that the results of subsequent calibrations are inconsistent is not a concern in my mind- the measurements are small over the span. What seems notable is that there appears to be such a sharp difference in the variability within the derived results. (What I need to do is perform a large number of additional tests, with the same changes in orientation and normalization of data, and see if the pattern persists.)
The coordinate system used to define the anchors’ locations is completely necessary in order to have a functional CNC system- the point of the entire exercise- and absolutely valid, but at the same time it is both artificial and arbitrary. The distances between the anchors is fundamentally manifest in their physical placement in space. In, fact, M4 is entirely based on the idea of measuring point to point distances, not XY coordianates as with a gantry type CNC. (I’m just rambling at this point.)
It’s late, I’m tired, and I don’t have a completely firm grasp on what I think may be at play, so I’ll throw out the parts of what I’m thinking and someone can tell me why I’m wrong.
The first is that the calibration configuration defines a horizontal and vertical dimension- a rectangle. But the actual layout of the anchor points is likely to be something like this (exaggerated);
Then the calibration finds the ‘center’- which would be assumed to the be the intersection of the two diagonals of the rectangle, but due to the inability to know at this point the actual layout, and factors such as bowstring deflection, it’s entirely possible that the actual state is something like this (exaggerated)
Nothing about this is fatal, and the entire calibration process is designed to determine the actual layout, but at this point we are at the mercy of an unknown reality and some reasonable but not necessarily correct assumptions.
One thing I recall in some of the early discussions of calibration, specifically horizontal calibration (although many of the dynamics are also present in vertical movement, even with the addition of gravity providing an additional vector), is the idea that two belts are used to drag the sled (which we will consider a point) to a position, and then the other two belts are tightened one at a time. It was also noted that the order that these last two belts are tightened is important.
If the first of these ‘trailing’ belts to be tightened is not within the arc opposite the angle defined by the two ‘pulling’ belts, the sled will be moved away from the position that the pulling belts placed it.
Given there is non-zero friction, two belts should drag the sled to a given position, but one thing I have noticed is that the sled moves when the third belt is tensioned and then again when the fourth belt is tensioned- as far as I can tell every time. Thus the measured position of the sled is not that which was intended when it was placed by the two pulling belts.
Obviously, solving these dilemmas is the intent of the process of calibration. And everything I’ve noted is simply part of “it’s complicated”. But here’s the part that I suspect but still can’t put my finger on-
I think that some unknowns are more easily- or more fundamentally accurately- determined than others, based on the (unknown) relationships within the layout. I’m honestly not sure what these are, but I suspect that they something along the lines of the closer the two angles adjacent to a side are to right angles, the more accurate the calculations of that side’s end points are- or maybe instead or right angles it’s simply congruance of the adjacent sides. Or maybe it’s related to the whether a side falls within or outside the rectangle as defined by the calibration configuration.
The problem is that there is no way, in a given pass, to determine is a particular value is a high confidence value or a low confidence value (assuming that these distinctions exist.) I think that rather than running a calibration, deriving a set of coordinates, using it to seed the next calibration, which then overwrites the previous values, and perhaps iteration, the better approach is to do a series of calibrations and look for patterns or trends within the entire set.
Another way of looking at is, instead of looking for a set of coordinates that best match all the data gathered, it might be better to develop multiple sets of coordinates from different subsets of the data, and then look for correlations between them.
Here’s a fairly concrete example of what I mean-
- Prior to running any calibrations, I took six measurements of the anchors- the distance from each to the other three.
- I know they are inaccurate and further I know they are not equally inaccurate.
- The position of all four points relative to one another can be determined from any five of the six measurements.
- If one were to take each subset of five measurements, one could calculate a derived value for the sixth.
- Repeating this process would likely show which measurements were more accurate.
3 Likes
C Peter Lotz wrote:
It was also noted that the order that these last two belts are tightened is
important.If the first of these ‘trailing’ belts to be tightened is not within the arc
opposite the angle defined by the two ‘pulling’ belts, the sled will be moved
away from the position that the pulling belts placed it.Given there is non-zero friction, two belts should drag the sled to a given
position, but one thing I have noticed is that the sled moves when the third
belt is tensioned and then again when the fourth belt is tensioned- as far as
I can tell every time. Thus the measured position of the sled is not that
which was intended when it was placed by the two pulling belts.
I think that the important thing is that at the point measurements are taken,
all 4 bents need to be tight.
Right now, I think we have premature optimization taking place in deciding which
belts to tighten in what order to try and prevent the sled from moving.
I think that after you have pulled the two ‘lose belts’ snug, you should make
sure that all 4 really are snug by going around all of them and pulling tight
(I would do this in a loop, if pulling tight changes the belt measurements
significantly, go through all 4 again, repeat until there is not a significant
change in any belt lengths)
I think that some unknowns are more easily- or more fundamentally accurately-
determined than others, based on the (unknown) relationships within the
layout. I’m honestly not sure what these are, but I suspect that they
something along the lines of the closer the two angles adjacent to a side are
to right angles, the more accurate the calculations of that side’s end points
are- or maybe instead or right angles it’s simply congruance of the adjacent
sides. Or maybe it’s related to the whether a side falls within or outside the
rectangle as defined by the calibration configuration.
or what happens if you make two belts equal and then see what lengths the other
two are??
The problem is that there is no way, in a given pass, to determine is a
particular value is a high confidence value or a low confidence value
(assuming that these distinctions exist.) I think that rather than running a
calibration, deriving a set of coordinates, using it to seed the next
calibration, which then overwrites the previous values, and perhaps iteration,
the better approach is to do a series of calibrations and look for patterns or
trends within the entire set.Another way of looking at is, instead of looking for a set of coordinates that
best match all the data gathered, it might be better to develop multiple sets
of coordinates from different subsets of the data, and then look for
correlations between them.
looking for correlations between them may be hard to define, but looking for
outliers may be a way to find that ‘something went wrong measuring this point,
trhow this point out’
or instead of averaging all the results, do a weighted average of some sort???
Here’s a fairly concrete example of what I mean-
- Prior to running any calibrations, I took six measurements of the anchors- the distance from each to the other three.
- I know they are inaccurate and further I know they are not equally inaccurate.
- The position of all four points relative to one another can be determined from any five of the six measurements.
- If one were to take each subset of five measurements, one could calculate a derived value for the sixth.
- Repeating this process would likely show which measurements were more accurate.
a simple thing, instead of taking 6 measurements, take 12 (go to each corner,
measure the distance to the other 3 corners, even if it duplicates a measurement
you already too)
I think the current calibration routine is attempting to do this. That is one
reason for taking many measurements (the other is that measuring at different
points will involve different amounts of error from things like the belts
stretching, etc)
Note that I am not disagreeing with anything you’ve posted here.
David Lang
3 Likes
This is the deepest thing ever said in the forums.
Generally I think that you are spot on. I think that it is totally possible (and likely) that some data points are adding negative information and that we would be better off throwing them out. The tricky part is figuring out which ones.
I also agree that the idea of finding patterns and consistencies within the data is an exciting place to explore.
I am going to work on tweaking the calibration process to be faster (ie taking measurements and moving between points happens faster) and making it so that we can gather data more quickly (ie almost while moving) which should let us build a bigger dataset which should help make more in depth analysis possible
4 Likes
I am running into this same issue. Constantly restarting the maslow and wondering if I’ll be able to use my Wifi or if I’ll have to connect directly, which meant I had to take a 2nd laptop to my garage and use a USB stick to be able to reliably transfer new firmware without having to disconnect from the router to get internet and then connect back again.
This happened at the end of my first calibration run and it just kept printing the same results with slight variations over and over in the console, and I (not having seen prints from a calibration run before) thought it was just slowly working it’s way to finishing the calculations, as the fitness kept climbing with each repeat of the prints. It took me trying to restart the calibration to realize I had lost my connection.
Would appreciate it being easier to set it to no longer try to connect to my wifi so I can just have a consistent experience (and just hope no neighborhood kids connect and mess around while I’m using it). It also might do to have the interface page put something front and center when it no longer has a connection to the device.
1 Like
How terrible would it be to start the process by mounting the sled centered on your frame with screws and then extending the belts to the anchor points, letting it measure their length after it takes in the slack, and then using this accurate-if-not-precise centerpoint instead of letting it find one for itself? It’s not gone to where I would consider the center as a first step in any of the calibration attempts I’ve done, often being off by 6 or more inches to the right, too high, or too low.
1 Like
If you remove your home WiFi network from the settings the same way it was added the machine will stop trying to connect to your WiFi and instead create its own access point.
I ran into the issue with it reconnecting over and over thing and it’s MAYBE fixed in 0.69.3 by slowing down how often the data gets resent, but I’m not sure.
Mathematically there isn’t actually anything special about the center so it shouldn’t matter at all. When we start out the process we know that we don’t know the actual locations of the anchors so we don’t expect the starting point to be the actual center.
0.69.3 which just came out will run an initial 3x3 grid to establish some basic understanding of the anchor point locations and then spiral out from there. At the end it will return to the center (the true center) so if it’s not ending in the center that’s a concern, but starting out not in the center is just fine I think
1 Like
OK, so an at least partial answer may have been staring me in the face all along- TLDR - I think the calibration process is sometimes putting the original Y value back in.
I wanted to do a scatter plot for the values, following up on @dlang noting that it was probably easier to find outliers. When I limited my comparison to just the calibrations done in the ‘normal’ orientation (what I referred to as BR) the range for the D value dropped to a ludicrously low .05. This didn’t seem possible, so I rechecked all my calculations and transforms, and everything looked right. It took me far too long to bother looking at the original data taken from the serial logs.
For each calibration, there are four X/Y pairs returned- eight values total. But three of them- blX, blY, and brY are always zero, so there are only five significant values.
For the three X values, almost every value returned was unique- the only exception is that three of the tlX values were 0.0.
But the Y values were a very different story- two Y significant values were returned for each of nine calibrations- a total of eighteen values. Of these, ten of them- more than half- were the exact same value- 2363.0- and this value was not arbitrary- it was exactly the value entered as the machine height in the calibration configuration… Perhaps even more significantly, trY was returned as 2363.0 for every single landscape calibration. Furthermore, for the two portrait calibrations (where the width and height were inverted) were not returned as the default of 3578- that might be a clue as to the mechanism. (At this point I also noticed that one of the X values exactly matches the configured machine width- maybe a coincidence, maybe not. The three 0,0 tlX values might also be due to the same mechanismm)
| tlX | tlY | trX | trY | blX | blY | brX | brY | Fitness | |
|---|---|---|---|---|---|---|---|---|---|
| Landscape | 0.5 | 2363.0 | 3579.2 | 2363.0 | 0.0 | 0.0 | 3572.7 | 0.0 | 1.2 |
| Landscape | -0.5 | 2353.9 | 3578.7 | 2363.0 | 0.0 | 0.0 | 3577.6 | 0.0 | 1.6 |
| Landscape | -5.8 | 2355.4 | 3579.4 | 2363.0 | 0.0 | 0.0 | 3571.9 | 0.0 | 1.4 |
| Landscape | 0.6 | 2363.0 | 3578.3 | 2363.0 | 0.0 | 0.0 | 3572.9 | 0.0 | 1.0 |
| Portrait | 0.0 | 3581.0 | 2362.6 | 3570.4 | 0.0 | 0.0 | 2364.4 | 0.0 | 1.1 |
| Portrait | 0.0 | 3581.6 | 2357.5 | 3573.4 | 0.0 | 0.0 | 2363.0 | 0.0 | 1.0 |
| Landscape | 0.0 | 2363.4 | 3578.0 | 2363.0 | 0.0 | 0.0 | 3571.9 | 0.0 | 1.4 |
| Landscape | -5.1 | 2369.6 | 3578.2 | 2363.0 | 0.0 | 0.0 | 3563.3 | 0.0 | 1.2 |
Given the scatter in the other values, it seems at best extremely unlikely that that many results would converge on the same point. Given that the values in the are only reported to a single decimal point, the yaml files would have been ideal to test this, but I didn’t save those for each test.
Long story short, I think there’s a bug- at least in .69- that sometimes causes the original ‘guess’ to be returned instead of a calculated value- almost definitely for the trY in landscape.
In my case, my initial values were very close to the actual numbers, so it probably wouldn"t make much of a difference. But for anyone who had a looser guess- and particularly if they used the outside frame dimensions rather than the anchor spacing, the effect would be significant. This might also explain excess slack. particularly on the upper right belt.
2 Likes
This of course also explains the small range of values of D, and eliminates any significance to it and any resulting conclusions.
1 Like
that makes some sense. the way the current code appears to work is that it picks one anchor as ‘most wrong’ and moves that. If it always thinks that there is a different anchor that is ‘most wrong’ it would never change trY
1 Like
While I’d like to believe that my measurements were so accurate that the M4 couldn’t do better, the fact that the X value changes each time while the Y stays the same makes that seem unlikely.
2 Likes
You guys sound like no one knows how this code works.
I’m trying to be a little funny but I’m new to this product and seriously is the code to the calibration process a mystery?
William H wrote:
You guys sound like no one knows how this code works.
I’m trying to be a little funny but I’m new to this product and seriously is the code to the calibration process a mystery?
for most of us, pretty much, we have to hunt through the code to understand the
logic. Bar and Roman wrote it, but the rest of us are working backwards, and
even for Bar and Roman they are frequently getting videos of problems and going
“why is it doing that”
David Lang
2 Likes
Because this is a Kickstarter project rather than a finished commercial product, we are seeing the part of the development process that would usually be hidden behind the “new product coming soon” curtain.
7 Likes
…not to mention that the commerical product has armies of design engineers, test engineers, technicians, etc., all to make it work, and Maslow has a few people to do everything.
Even with all those resources we often gather around the machine and go WTF, it’s haunted?
I’ve been doing this for more than 40 years…
2 Likes
I deleted the text and hit Set and it worked.
I was not expecting this to be the route because typing my network name didn’t work initially, and I ended up picking it from the list via the nub of a button on the right of Set. I didn’t see a way to choose to not be connected to a network in that menu.
.70 ran much more smoothly. Acceptable fitness after a single attempt, though I did notice the sled wobble and lifting of the bottom edge that others mentioned (vertical frame). It happened mostly during the 7x7 grid, in case that ends up being a pattern/concern. It seems to jog smoothly and in straight lines, so I don’t think it ends up mattering unless I start seeing it during actual cuts.
Example of sled lifting: https://youtu.be/IwJln9qZJDg
Calculations were significantly faster on a more powerful laptop, of course. I swapped up for these attempts after seeing how long the first few took. Had originally been doing it with a relatively weak laptop that I had planned to leave in my garage as the primary interface. The difference was so much that I think it may be worth just outright recommending that people use a better machine if they have one to save themselves time with calibration.
Now I’m just stonewalled with an error about sd card code not initializing, but I’ll post about that elsewhere.
1 Like
I haven’t had much time for this, but over two days I did six calibrations using 0.7.2.
As I’ve stated elsewhere, it went well. But I’m wondering about the lack of repeatability.
I did two calibrations back to back the first evening. I expected to see an incremental improvement, but all five of the fitness values reported in the second calibration were lower than the corresponding value in the first calibration.
70.2 First Calibration.txt (21.3 KB)
70.2 Second Calibration.txt (20.9 KB)
The second day, I initially got a
[MSG:ERR: Center point deviation over 15.000mmm, your coordinate system is not accurate, maybe try running calibration again?]
even though I nothing changed as far as I know.
The third calibration returned values very close to the first two, with fitness between the first two,
70.2 Day 2 Third Calibration.txt (20.6 KB)
The next calibration was very similar to the third. At this point I felt that the results had likely converged on as good an answer as could be had, at least at this point.
I couldn’t leave well enough alone.
The next calibration gave similar results but reported notably lower fitness values.
70.2 Day 2 Fifth Calibration.txt (20.4 KB)
The real surprise came in the sixth and final calibration, as its values are notably different (admittedly by a few millimeters…) than the the others, but with better fitness than the previous. The one change I did make was to increase the retraction setting, but since I used the GUI it is my understanding that this shouldn’t affect calibration. (I checked the yaml, and the calibration setting is unchanged).
70.2 Day 2 Sixth Calibration.txt (20.2 KB)
I plotted the final calculated positions of the anchors for each of the six calibrations- Bottom left is of course trivial-
Bottom right is only slightly more meaningful as all the points will lie n the X axis-
But top right and in particular top left clearly show calibration six as an outlier-
I had hoped that multiple calibrations would either convert on a value or give a set that could be interpolated, but I’m questioning if there were something I was missing.
In order to better understand the actual differences between the data sets, I calculated the distances between the anchors in each set, including all the ones reported within the calibrations. I expected to see the same outlier, indicating that perhaps something had shifted in my frame, anchors, or M4- but this did not seem to be the case Looking at just the final results for the six calibrations, the range for the two diagonals are both under one mm.
Maslow 4 Calibration Calculations.xlsx (12.0 KB)
I suspect the answer is staring me in the face, I’m just at a loss. Based on others’ results, I believe could actually cut with the M4 in its current state, But I can’t shake the feeling that the lack of repeatability of the calibration will translate into no less repeatability of use.
5 Likes
It’s really cool to see such beautifully presented data.
That amount of variation is well within what I’ve seen. I agree that we want to keep improving and ideally every run would be identical, but at the moment I think that there is enough uncertainty in the measurements that is about the repeatability we get at the moment.
1 Like