OK I think I’m at the point where I’m replicating what you’re doing.
Open ‘Optical Calibration’
Click ‘11 x 17 (Portrait)’
Click ‘Calibrate’
Click ‘Auto Home’ (wait for calibration to happen)
Note the calibration results (mine are below)
Click ‘Save and Send’ (and wait for logs to finish spitting out from the python stdout)
Click ‘Auto Home’ again (wait for calibration to happen)
Note the improved results
My error was pretty bad even after calibration, but looking at the values it seemed like my whole test pattern seems to be rotated clockwise around the zero position (note that I mounted my pattern differently so the position with [.02, .01] error is my home position). Sure enough after pulling out a bubble level, I verified that my test pattern is slightly clockwise. Any thoughts on how hard it would be to correct for rotation also? My top beam not being perfectly level is something I stress about
Also, As expected, my camera is definitely not centered. Seems like we could make a routine that asks the user to rotate the sled while one of the tracking squares is in the frame, and then calculate the optical center position from that. I’ll start thinking about how that might work. I’ll post some photos and videos in a bit for anyone that’s still following this thread.
I wrote some code for finding the center point of a circle from 3 points on the arc. To find the center of rotation in the camera frame, we could add a routine that captures the position of the tracking square at 3+ moments as the user rotates the sled by hand. Then we could pass the center points of the tracking square into the calculateCenterOfArc code below. Ideally we’d capture >3 points and run this multiple times and find an average for the center point. Then we don’t have to worry about our off-center jigs and endoscopes messing up the repeatability of the calibration.
It would be awesome to be able to account for this. You’d need to determine the rotational radius of the camera (how far off center it is) and use this value during the computation of the camera image rotation and x,y offset. That math would be a fair bit more complicated than it currently is, but I think its doable.
I also like the idea because potentially we could keep the router installed in the body. As long as the endoscope doesn’t end up too close where it can’t see the squares, I imagine a 3-D printed 1/4-inch or 1/2-inch cylinder that you insert into the router (where the routed bit would go) with an arm off it that you could then snap an endoscope into.
One bug I need to track down today is that if the camera can’t find a good square, it can produce a NaN for one of the values and then all heck breaks lose.
The routine takes 10 images and calculates the x and y errors for those images. It then runs through a process that throws out the outliers (anything that is off by 2 times the sd). Somewhere in there is the bug because in there is where the NaN is produced. Of course, it doesn’t happen consistently so tracking it down will be fun.
Theoretically, this process will compensate for it. But, the code you are using has a setting for top-beam tilt in Settings->Advanced. It’s based on a positive angle lowering the left motor and raising the right motor. I got a clinometer app for my phone and it seems pretty sensitive. It also moves the right and left motors in/out based upon the angle (since distance between motors is fixed).
A lot of smoke rising from the work of @madgrizzle, @johnboiles, and others! You guys are really on to something! Looking forward to the “prime time” results that we can all try! Thanks so much for your efforts! Yeah Forum!!!
Wouldn’t you just need to set the xA, yA values with the calculated center of the frame? Or is there something else I’m missing? Maybe this can be my little piece of the project.
I also like the idea because potentially we could keep the router installed in the body.
Neat, I like that idea! I bet not having the router weight on my sled makes a meaningful difference. Just keeping the router there is a lot easier than trying to build a heavy camera jig (e.g. filling my 3d printed part with bbs or something).
Theoretically, this process will compensate for [beam out-of-level].
Are you saying the current routine should compensate for it, or that it would be theoretically possible in the future? I was never able to get my error down, especially for the points furthest from the home point.
the code you are using has a setting for top-beam tilt in Settings->Advanced
Oh neat! I’ll play around with that. We could probably pull that feature into groundcontrol:master ahead of finishing these optical calibration changes. Seems like that would be broadly useful!
@madgrizzle would it also be helpful if I reworked your repo so that they’re forks of MaslowCNC/GroundControl and MaslowCNC/firmware (and then maybe a third repo with your test patterns and misc files)? That will make it easy to merge in any new changes from @bar in the main repo and make it easy to merge in your changes into the main repos when the time comes. I have a fair amount of experience wrangling git repos in weird ways so it’s potentially something I could contribute. Though it would mean you’d need to commit/push 2-3 repos during development instead of one. Let me know if you think that’d be helpful.
I haven’t really thought it through, but the camera can be rotated (along it’s own axis) and the camera can be rotated by being off from the center of the sled’s rotation (remember the sled rotates as it moves around). Right now, it only compensates for the camera being rotated along it’s axis. Spinning the sled that is not only off-center but also off-axis and calculating a single x,y point isn’t going to work. Edit: at least I don’t think it will work I hope that makes sense. Edit: Also, as in your case, the camera can also be off axis of its own housing…
so that’s three rotations going on
It’s theoretical because I never really got good results from the holey maslow calibration. It’s fundamentally sound though and the math always checked out. I wouldn’t be afraid of trying it… I’m just not putting down a money-back guarantee
I’m generally lost with the github stuff. I managed to figure out how to use github desktop and atom and get a repo working, but beyond that… I would definitely love help in doing it the right way.
If it’s easier for you to take over the repo, that’s perfectly fine as well. If we (and others) are going to work on it, we need to coordinate PR, etc. so I don’t mind someone with a clue having control over that Less chance of me messing it up.
Let me ask this… I develop on a couple of machines and would like the ability to push/pull from a repo that I’m working on. Is this how it works? We fork MaslowCNC and that becomes our combined repo and then I fork that repo and it allows me to do my work and when happy, I submit a PR to our combined repo and when that’s done and everyone is happy, we submit a PR to MaslowCNC??
We want to focus on the center of the sled’s rotation right? If we rotate the sled and find the center of rotation of the sled in the image, I think we can ignore the camera being off-axis (as long as the center of rotation is in the frame). I didn’t think about also rotating the image at the right spot, but I think that uses the same xA, yA variable (does the image get rotated here?). Of course, focusing on the center of the sled ignores that the router bit might not be perfectly centered, but maybe that’s ok.
It’s fundamentally sound though and the math always checked out.
That math isn’t in this version of the Optical Calibration routine though right?
I develop on a couple of machines and would like the ability to push/pull from a repo that I’m working on. Is this how it works? We fork MaslowCNC and that becomes our combined repo and then I fork that repo and it allows me to do my work and when happy, I submit a PR to our combined repo and when that’s done and everyone is happy, we submit a PR to MaslowCNC??
Yeah that’s right-ish! Though you can use branches instead of additional repos to hold in-progress changes for repos you have write access to. Typically it’s something like this
You fork MaslowCNC/GroundControl as the madgrizzle/GroundControl repo to work on your changes
You either commit your changes straight into the master branch in madgrizzle/GroundControl (like you’re doing now) OR if you are uncertain on changes first and want to discuss them further you push your changes into a different branch (not master) and open a pull request. The former is probably most appropriate at this stage in the project since you are doing the majority of the work here.
I fork madgrizzle/GroundControl to johnboiles/GroundControl and make my changes in my repo. I submit a PR back into madgrizzle/GroundControl:master with my changes.
At some point in the future, we open a pull-request from madgrizzle/GroundControl:master back into MaslowCNC/GroundControl:master and merge our changes upstream!
When we’re using forks, git also makes it really easy to merge upstream changes from MaslowCNC/GroundControl:master back into madgrizzle/GroundControl:master (in case @bar adds some new thing we want to include in our development). Git can do this mostly automatically, though we’ll need to manually fix merge conflicts where our changes conflict with new changes in MaslowCNC/GroundControl:master
That’s where the image gets rotated, but that’s just for display purpose. The magic is here. This is where xB, yB get rotated around the center of the image so that the true X and Y deltas can be calculated. This assumes that the camera is really precisely centered along the rotational axis of the sled and therefore treats both camera rotation (up not being up) and sled rotation as the same. If camera is actually offset from the center of rotation, then they aren’t the same rotation points and that’s what I’m thinking we need to consider.
Is there a way to give someone, other than the repo owner, control (admin rights or something) over a repo?
I think I’m starting to understand – it’s all because we need to figure out which way is up using the boxes that both rotation points matter. I’ll have to think about this more and get more familiar with the code. I’m struggling to visualize this math.
Is there a way to give someone, other than the repo owner, control (admin rights or something) over a repo?
Yep, from the repo page (e.g. GitHub - madgrizzle/HoleyMaslow) go to Settings → Collaborators. There you can add people to the repo and give them various levels of access.
Alternately to the way I’ve been thinking about finding the optical center (by rotating the sled), if we did your idea, we could instead rotate the camera by simply turning the router a bit. Then we’d be centering on the bit position, instead of the ring, which may be better since it could then correct for the router not being centered in the ring (assuming the sled stays reasonably level the whole time)
Let me know if it’s my code or just the math that you are struggling with.
Re: repo, I need to create separate repos for GroundControl and Firmware, correct? Make them in my “root”, correct? I actually have those there, but they are old and have some revisions I never did a PR with, so I can delete them and start from scratch. Then I can make a third repo for test data, scraps, etc… correct?
Less chance of me messing it up.