Digging up this thread. For triangular kinematics, has an auto-calibration scheme such as what @dlang described at the beginning of this thread been developed?
I’ve been playing with this idea. I started with the concept of trying to determine the motor spacing by having the user measure the vertical distance between two cuts. To do this, I took the triangular kinematics formulas used to calculate chain length and attempted to solve them in reverse, such that _xCordOfMotor and _yCordOfMotor could be determined. However, with the updated triangular kinematics equations accounting for sprocket geometry, this process led to some complex equations which I was not able to solve.
With that, and because this is not involved in the real-time operation of cutting, I decided to try an iterative approach instead. I designed an algorithm which would extend both chains a certain amount (this would likely have to be completed by the user pressing a button to extend the chains to the desired length), such that when connected to the sled the sled is at the top of the workspace. A cut would be made in place, then the user would move the sled vertically down to the bottom of the workspace and another cut made. The distance between centerpoints of these two cuts would be measured. This measurement, combined with the known chain lengths for each cut, would serve as the inputs to the algorithm to determine the motor spacing.
I formed a very simple algorithm to solve this. It started with assuming the top cut defined position (0,0) (this can be changed later, as desired), and then used a seed position for the right motor of (1,1). As the cuts were performed in the horizontal middle of the workspace, due to both chains being extended the same amount, only one motor position needed to be solved for. I then had the algorithm compute the expected chain lengths for this motor position. The calculated chain lengths were compared with the actual chain lengths for each cut location, and based on the results the motor position was updated. If both estimates were too low, the motor X and Y coordinates were each increased by 50% of the average chain length error. If the top chain estimate was too short and the bottom chain estimate was too long, I assumed the estimated motor position was too high and decreased the motor Y coordinate by 50% of the average chain length error while keeping the X coordinate static. Similarly, if the top chain estimate was too long and the bottom chain estimate was too short, I assumed the estimated motor position was too far to the side and decreased the motor X coordinate by 50% of the average chain length error while maintaining the Y coordinate. If both chain length estimates were too long then both coordinates were reduced.
I ran a test case of this using actual motor coordinates (3413, 1857). 561 iterations later beginning at (1,1) and the estimated motor position was (3412.995, 1857.007).
Next, I turned my attention to the rotationDiskRadius variable. Like David mentioned, if you performed three cuts (one at the top, one in the center, and one at the bottom), you would have two data points of the distances between them. I tried this, using the chain lengths of the top and bottom cuts to calculate the motor position, and then referencing the chain length of the center cut to calculate the rotationDiskRadius. The theory is, if the rotationDiskRadius variable was lower than the actual radius of the linkage assembly, the calculated chain length to this middle cut would be lower than the actual chain length. I used a feedback loop on this chain length to calculate the rotationDiskRadius while the motor position was being calculated as well.
This proved to be a bit more challenging. I had to scale down the feedback loop for this variable, otherwise it tended to become unstable and run off to very high values. With enough tweaking, I got it to run reliably. The downside of this is that it takes a lot more iterations.
My test case was a motor position of (1524, 724) with a rotationDiskRadius of 103.4. I began the motor at (1, 1) with a rotationDiskRadius of 1. After 3,842 iterations the estimated motor position was (1523.951, 723.967) with a rotationDiskRadius of 103.324.
Overall then, the theory checks out. However theory and practice can be quite different. My primary concern comes from chain sag. The accuracy level of the chain lengths required to produce these results was 0.001mm. Using the last simulation with an accuracy of 0.1mm the estimated motor position was (1519.147, 720.700) with a rotationDiskRadius of 97.635. This gives a motor position error of (-4.853, 3.300) and a rotationDiskRadius error of -5.765. While it’s still in the right neighborhood, you can see that even small errors in chain length compound to substantial errors in the predicted dimensions.
All my simulations were done in Excel as I don’t have my Maslow yet, so I cannot comment on how much of a factor chain sag or other aspects would be. What I can say though is that from my simulations, if the rotationDiskRadius value was entered manually then the accuracy of the motor position becomes better than 0.4mm based on a 0.1mm chain accuracy. Given what I have seen doing this, and based on the relatively limited number of linkage kits compared to the drastic difference in motor position across different Maslows, I would prefer to use a static rotationDiskRadius and focus all the accuracy we have on motor position.
What do you guys think?