Holey Triangular Calibration

Do we then enter these calculated values into maslow settings or do we need to wait for your new firmware to test?

I wouldn’t use them right now without different firmware. Just give me some time to see if this thing actually works. Feel free to cut the holes and post your measurements… it’s nice to have other sata points to play with.

1 Like

There’s an error in the chain sag calculations that I’m working on. No point of running the optimization code at this point.

1 Like

@Jatt I use .5 inch x 4’ x 8’ foam insulation board from a local home center for $8 for my calibration. It is foil backed and I cut on that side. I choose the .5 inch thickness because I cut mainly .5”x5’x5’ baltic birch. There are many thicknesses you can get though. The product is similar to this:
https://m.lowes.com/pd/Insulfoam-Common-0-5-in-x-4-ft-x-8-ft-Actual-0-5-in-x-4-ft-x-8-ft-R1-9-Faced-Polystyrene-Garage-Door-Foam-Board-Insulation/3033278

1 Like

So to go crazy and further eliminate assumptions, I’ve modified the routine to now allow for independent adjustment of the X, Y coordinates of each motor. Risky, yes. But it eliminates the assumptions:

  • the motors are perfectly level
  • the center point (0,0) is exactly in the middle of the two motors

The latter is important if there is any difference in chain tolerances. If center is not really center then the assumption that it is is wrong and calculations are off.

Part of this was an exercise to see if the optimization routines would settle on a good solution or blow up. Interestingly enough, I was able to get my error magnitude to 0.69 mm with the worse errors being about 1 mm (~1/16th inch). However, optimized values mean less than jack if they don’t produce results and I don’t know that yet. The motor spacing it liked seems higher than I think it really is.

Since the program liked to spread the motors apart, I think I’m going to do something a bit complex… constrain the X coordinates of the motors that so that the motors the distance between motors is fixed, but the X coordinates can shift left and right in tandem or get shifted based upon based upon the “tilt” of the top beam (i.e., if the Y coordinate of one of motors increases, the X coordinates will change based upon the rotation of the top beam). Math is fun.

Using these adjustments, I fixed the motor spacing and fixed the rotational radius. I allowed the top beam to move around (left, right, up, down and tilt) and allowed chain sag and left and right chain tolerances to vary. I restricted the chain tolerances from going higher than 1.0 (in the way I calculate chain tolerance, a number higher than 1.0 suggests the chains are shorter than they should be… which is not logical)

The results are encouraging in that it at least it minimized error value…

Error Magnitude: 0.809
Motor Spacing: 3602.6 (what I measured by hand… this was fixed)
Rotation Radius: 139.1 (what I believe it to be… this was fixed)
Chain Sag Correction: 28.023907
Left Chain: 0.994409
Right Chain: 0.997864
Left Motor X,Y: -1800.6534, -1082.749
Right Motor X,Y: 1801.9455, -1085.525 (this means right motor about 3 mm higher than left)
Left Chain Error Hole 1: -0.985
Left Chain Error Hole 2: 0.9938
Left Chain Error Hole 3: -0.9462
Left Chain Error Hole 4: 0.8875
Right Chain Error Hole 1: -0.7822
Right Chain Error Hole 2: 0.8981
Right Chain Error Hole 3: 0.0702
Right Chain Error Hole 4: -0.4148

2 Likes

X=0 is arbitrary, but it’s specified as being exactly in the middle of the two
motors.

chain tolerance shouldn’t change this, you may rotate the two motors different
amounts, but you are still going to be in the center.

making the machine not be symmetric around X=0 will have a LOT of side effects
in the math.

David Lang

Will be back to my machine next Tuesday, and look forward to trying this process, provided I can figure out exactly what you are doing…

  • I am assuming this process replaces the Triangular Test… we go through the calibration routine to that point, then run Holey instead. Or, we can work from our existing set-up, with the idea that Holey will take us a step further.
  • How does the mark happen… is it another hole?
  • Are you using v1.20 firm and software?
  • You are creating new firmware… will this be v1.21? Or will thie be something like v1.20.b, that will work with GC 1.20?

Looking forward to others “making it so” over the long weekend, so I can lurk on in and benefit from all your hard work!

Thanks So Much!!!

1 Like

I will be attempting this tomorrow morning, certainly with hangover cause party tonight.
Still I’m confident to get to play with the python :snake:
Lazy as I am to document I’ll record my screen and have additional screenshots.

Edit: I received 2 new chains from Portland yesterday. Not sure if a comparison to the first beta-tester batch will help. I will compare them and also try to see a difference of turning the 16 months used ones to slack side.

1 Like

Here’s the issue. In the Holey Calibration Model, the coordinates of each hole is calculated and Hole 0, which is drilled at where Maslow thinks the center is (0,0) is assumed to really be at 0,0. But let’s say the left chain has more wear than the right chain but chain tolerance is set to 0 for each chain. Even though Maslow thinks the sled is directly between the two motors, it’s really not. The left chain will be slightly longer than the right chain and therefore, the sled will be slightly to the right of the actual middle point (and I guess down a little as well). This is what I’m trying to account for. It’s an exercise to see if this makes a difference. Eventually, through multiple iterations of calibrations (assuming linear chain wear) you will get a calibration where the 0,0 is really equidistant to the two motors (assuming top beam level). After one run, it calculates my 0,0 is about 0.0034 mm to the right of middle… something really small… but the right motor is ~3mm higher than the left which is about 0.1 degrees tilt of the top beam.

The difference between allowing this adjustment:

With adjustments:

  • Error Magnitude: 0.809
  • RMS Error Hole 1: 1.2549
  • RMS Error Hole 2: 1.3436
  • RMS Error Hole 3: 0.9535
  • RMS Error Hole 4: 0.9713

Without adjustments (no tilt or shift left to right):

  • Error Magnitude: 1.021
  • RMS Error Hole 1: 0.3945
  • RMS Error Hole 2: 2.0912
  • RMS Error Hole 3: 1.4101
  • RMS Error Hole 4: 1.3499

First, there is no current ground control or firmware that can actually use the values that this routine generates. I’m working on it, but right now it’s not done.

Second, go ahead and calibrate your machine using the current method, but at this point, I recommend setting chain tolerance to 0 when calibrating. After the machine is calibrated, then do the following:

  1. Once again, ensure your chain tolerances to 0.
  2. Load the gcode for the hole pattern
  3. Run it
  4. Measure the distances shown on the diagram on the first post
  5. Edit the python code of the new calibration (will update it today):
    • change the motor spacing, motorYoffset, rotation radius, chainSagCorrection, chainOverSprocket to what they are when you did the cut.
    • change the desired motor spacing as well… when I ran the test pattern, I had a wrong number so I incorporated this feature. Chances your desired motor spacing is equal to 3602.6 is very slim
    • if using a ring kit, try leaving desiredRotationalRadius at 139.1 and see how it goes.
    • change the default values for the measurements
  6. In command prompt, run “python newcal-holes.py”
  7. It will first calculate the x,y coordinates of the holes and display them… press Enter
  8. It will then make calculations of chain lengths to each hole based upon the machine’s parameters and display them… press Enter
  9. It will run through a bazillion iterations of trying different solutions and will print the ones that make improvements. Eventually it will look like its frozen, but it will continue to try to find better solutions.
  10. Eventually it will present a message. Type ‘x’ and then press Enter to exit. The last printed solution is the best solution

As for the mark, you’ve got to figure out how to make the mark. Mark 5 needs to be the point where a line straight down from Hole 0 crosses a line drawn straight between Holes 2 and 3. This is the more challenging one to define. I can’t just drill a Hole 5… It needs to be determined. What I did was draw a line straight down and then marked where my tape measure stretched between Holes 2 and 3 crossed it.

As for new version, eventually if this works will will be done through a PR. But I’ll have a fork for people to test well before we get to a PR.

5 Likes

Holey Triangular Calibration, Madman!:bat:

3 Likes

@Dustcloud Hope this will speed you up on Tuesday

Before letting the :snake: run, edit in the newcal-holes.py the following lines with your values:

  • 72,73 (workspaceHeight/Width)
  • 89 to 94 (machine settings)
  • 97 (desiredRotationalRadius)
  • 104 to 113 (measured distances of hole pattern)

After a successful calibrations groundcontrol.ini is the fastest way to get the machine numbers:

From what I understand is that I should override the values that GC calibration found that seem wrong.
I my case motor distance, height of the sheet in Y and the rotation radius are not near the hand measured values, so I think I should enter my more trusted numbers.

@madgrizzle Running the script in the office with the default values I get:

-------------Machine parameters could no solve to your desired tolerance, but did you really expect to be able to?---------------------

Although I like the humour, it’s still a bit discouraging :innocent:
Heading over to workshop to feed the snake with some real life numbers and are hoping for

else:
print “Solved!”

3 Likes

Yeah… just me being me.

I tried this morning to use the new firmware (had to fix some errors in what was posted to get it to compile) but now I can’t even get it to move. I need to figure out how to debug firmware on the arduino… it could be hitting a math error and crashing or something.

So, like I said before, there’s no firmware that can use these numbers. You may be able to try to take the chain tolerance values and use them in the existing software by doing this:

chain tolerance (current software) = (1 - chainTolerance ) * 100

so if you get a 0.99934, the value for current software should be (1 - 0.9966) *100 = 0.33

That might work.

And you cant use the top beam tilt numbers… but it might help you determine how level your top beam is. Again, it might. Whether or not the tilt adjustment is real, I don’t know.

1 Like

To explain the new firmware, I’ve added a setting for top beam tilt and I’ve changed how the chain tolerance is used. Currently, chain tolerance is used to adjust how many millimeters of chain is fed out per rotation of the sprocket. I don’t think this is the best way to handle it, and in this firmware, it just changes the calculations (inverse triangular) on how much chain to feed out. As I said above, the software isn’t working so don’t try to use it.

2 Likes

I’ve used the cheap and easy clear tube water level to set my motors level over 3505mm.
Confident that I’m in a human error range of 1mm +/- 50%
image

3 Likes

I’ve updated the GC/firmware on my github. I had some really dumb mistakes in the firmware so I hope the revisions work. I’ll know later today/tomorrow when I get a chance to compile and upload them.

I’ve also updated the newcal-holes.py to be less discouraging and give the values needed for entering into the revised GC.

So a little about the top beam tilt and x-axis shift of center. The reason I incorporated these values into the calibration routine was to try to eliminate any assumptions. That way, if the assumptions are bad, we aren’t adjusting values that shouldn’t be adjusted to overcome the bad assumptions.

The top beam tilt has made it as a setting in GC and is used by the firmware because if there is a tilt, there is a tilt. If you don’t like having a tilt value, then make the frame more level. Honestly I don’t know if it works because I’m surprised that my frame is within 0.04 degrees of level and maybe some of it is being compensated by chain tolerances. Nevertheless, I’m going to try using that value and see what happens.

However, I’m not making the x-axis shift of center a setting in GC or firmware because I don’t think it should be. My rationale is that if you are going to do multiple (at least two) iterations, then eventually the chain tolerance values will produce a 0,0 that is truly in the middle horizontally between the two motors… at least theoretically that is the case.

1 Like

Could you not just retract the chain on the “low” side instead of adjusting for tilt (raising it)?

Sorry… not following… top beam tilt changes the X & Y coordinates of the motors. It makes the right motor a little higher or lower than the left motor depending on tilt and brings the x coordinates in a wee closer so that the distance between motors is maintained at what you set it for.

Something i’ve been wondering though - if the whole machine is tilted wouldn’t it work the exact same way as if it was level? What we don’t want is tilting of the motors in relation to the workpiece, not necessarily in relation to the groundplane. So if we compensate for the tilt of the motors, we should first make sure that the workpiece is not also tilted in the same way as the motors are.