The purpose of this thread is to discuss the firmware implementation of optical calibration corrections (originally by @madgrizzle). This change is in the following firmware PR.
Since optical calibration isn’t ready to go into GroundControl yet, this is mostly for discussion and directional feedback from the community. We probably don’t want this to get merged in yet.
I’m not sure I know what you mean by optical calibration.
This is actually a bad term for it.
They have a system where they get a banner printed with a grid and then put a
camera on the sled and map out where the system thinks it is compared to where
it really is. They then take this error mapping and use it to correct the
location of the sled when cutting.
This firmware work is not really about the optical part of the calibration, it’s
about using the resulting error matrix to have the maslow cut in the right place
instead of just depending on our math.
That’s kind of cool. 
First off, let’s change the name of this from ‘optical calibration’ to something
else ‘matrix error correction’ or something like that.
as I understand this (apologies for not digging through the PR first, so let me
know if I’m way off base), there are two modes of operation here
curve fitting where the system takes the error values and creates correction
curves to use.
point interpelation, where the system looks at the error around where it is
and tries to figure out what the correction is exactly where it’s trying to be.
I think both of these would be valuable to have, but I think they sould go in
separately, probably by taking the kinematics and reverse kinematics routines
that determine the chain lengths and make completely separate function calls for
each of the three modes (default, curve fitting, and interpelation), via
function pointers. This should let you significantly simplify the versions for
these new modes (as they don’t need to include all the corrections that we are
calculating for in the default mode) and keeps the default from being
complicated by these modes.
I would also ask that you make these routines general enough that instead of
relying on a particular correction pattern and density (you guys are using 1"
point spacing in a grid across the entire machine), allow for at least variable
spacing, and ideally as close to an arbitrary set of corrections as you can
support, including the ability to just store half of the points (assume
symmetry)
That way this is also useful for people who aren’t willing to go to the lengths
of a full video setup, but may be able to easily map out a dozen or so points.
David Lang
For those not familiar with this calibration, here’s an extremely long thread about it: Optical Calibration Demo and Three Hours Working on a Bug
Yeah also take a look at the description in the PR. There’s some more details here that I probably should have duplicated here (including the link to that original thread).
I spent a lot of time trying to respond… so I’m just going to throw this out and hope it’s taken the right way.
This optical calibration is a lot of work and I’ve found programming within the confines of the arduino to be a pain. With doing this in my free time and other projects going on, I might be able to find time to devote to the effort if a bunch of people say, “hey, this is a great idea, but 31x15 is way too many points for me. I’d give it a shot if I if I could just do a dozen squares”. But personally, if you are going to get a pattern printed on a 4x8 banner, set up a camera and all that, you might as well run it at 3-inches on center… it’s going to cost the same and you will end up having a higher resolution error matrix. The process does take a while to run, I give you that, but it requires no user intervention once you hit start. If you have a problem with a process that takes a couple hours to run, Maslow is not for you
I hate sloppy, fixed programming as much as the next person… but making it fixed 31x15 made it easier to troubleshoot and there’s been a need for a lot of that… If someone wants to take where its at and try to make it arbitrary and variable, I’d be more than happy to support them and incorporate their changes into any work I do in the future.
Now, if a goal of asking for this was to get a process included so that you can measure error at a different pattern (and not use it for calibration, or only use it to do a curve fit) that would be much simpler to do. If you wanted to use this technique to compare different changes you make to the calibration model, sled material, etc. and you felt you needed only 12, 24, 96, whatever number of points, that would be less complex (not easy, just less complex). I’ve got a lot of things I’m working on and might be able to find time to incorporate it…
I thank @johnboiles for his efforts to put this and other work out there in a PR.