Here are some updates on work I have done. Still, everything is on this GitHub site, https://github.com/schmittjoshc/MaslowCalibration/blob/master.
- Added the chain tolerances to kinematics.py. The implementation is (should be) equivalent to the implementation in the firmware on the main branch at, https://github.com/MaslowCNC/Firmware/blob/master/cnc_ctrl_v1/Kinematics.cpp
- Added chain tolerances in the calibration, https://github.com/schmittjoshc/MaslowCalibration/blob/master/HoleyCalibration.py. This improved the results slightly, but nothing substantial.
- Added measurements to the top of the worksurface (4x8 plywood). This was necessary to calibrate the motorYOffset parameter.
At this point, everything appears to be working on the calibration side. Looking back at @madgrizzle’s original calibration results, here is a comparison:
- This solution is not significantly better, with the exception that the solution comes in ~4 optimization iterations; much fewer than @madgrizzle’s.
- There is a dependency on the scipy Python library, which has to be installed.
- There are no parameters like “desiredMotorSpacing”, which anchor the calibration.
- The calibration operates on the GC kinematics calculations, so the calibrated constants should translate into GC.
- IMHO the calibration algorithm referenced from the scipy Python library is very capable, and is the correct tool for the job. It is capable of handling very large problems, and should scale up well, regardless of where we end up taking this.
Here are the things that I hope to do in the future.
- Updates to the kinematics.py class should be merged back into the main branch. The implementation of chain tolerance is already in the firmware, and there is no reason it shouldn’t be in GC.
- I am on the fence as to whether or not I should change the hole-pattern. I think it is valuable to have a hole at the top-center of the workpiece, since this area is the most sensitive to changes to calibrated parameters.
- I would like to benchmark against simulated points. I would like to run a simulation in which the machine parameters are perturbed slightly, to represent an inaccurate machine. Then, go through a calibration to determine how close to the original parameters I get.
- If the simulation works out, (I should be the guinea-pig) I would like to test it on hardware.
- I think it makes sense to put the actual catenary equations into GC and the firmware. That way we are working with real chain tension, chain weight, and sled weight. The calibration of chain sag this is then easier to understand because there is a physical phenomenon associated with the numbers and calculations. I don’t believe there is a big computational penalty here.
- While we’re modifying the kinematics equations, may as well include chain-stretch. I know @gero has done some tests and found the chains stretch a few mm with very reasonable tension. This is a predictable phenomenon. Here is some information on chains: http://tsubaki.ca/pdf/library/the_Complete_guide_to_chain.pdf
- I spent a brief moment determining the elastic deflection calculation. StretchedLen=BaseLen*(1+Tension(lbf)*2.3e-05) I got the 2.3e-5 by visually looking at the graph in the above hyperlink. It is a property of the chain. It is not precise, but is is approximately correct. Length units just need to be consistent between StretchedLen and BaseLen.