LitePlacer.com forums

Malte,
I think I am finally able to get something done with Git. The final piece came when I realized that the files in the working directory changed to the checked branch. Not knowing that makes it hard to keep branches and changes straight.

I can create a pull request now, but I have some changes to my algorithm to make. I realized today that if the wobble error refers to a fixed location in the camera domain, then I can guarantee that the camera offset doesn't need to be done with a new needle. Essentially, the proper offset can always be derived from the up camera position if the error is relative to it. Only if the camera moves does the offset need to be recalculated.

Steve

Hi Steve,

good to here you've been making friends with git

Can you tell me your fork's repository URL? I'd like to have a look.

And just one more piece of advice out of my experience: Commit small and often, basically each atomic functional change / enhancement should have a commit of its own.

If you do that (and provide meaningful comments!) it gets very easy to read and interpret the history of the code.

Look at OpenPNP commit history for a good example:
https://github.com/openpnp/openpnp/commits/develop

I particularly like the online diff-view for each commit, allows you to instantly spot what changed and why.

Cheers
Malte

Hi Malte,

Here is the URL.

https://github.com/sgraves/LitePlacer-DEV

The PictureBoxCrashFix branch is valid. I wanted to get that code out first.

The NeedleWobble branch has PictureBoxCrashFix code (and other) mixed into it. It is broken. I haven't decided how to handle it yet. I will probably blow it away and recreate it properly.

Yesterday I starting thinking about what I was going to call a "robust" needle compensation algorithm in which at each rotation the needle is moved until the video processing reports that it is at the center of the frame and recording the location value in the down camera domain. I realized that even if I don't do the moving the needle to the center part, but do translate all measurements into the down camera domain I have an improved algorithm. It we always use the same value in the down camera domain as our reference point to calculate the wobble error then a needle change would only need a new set of wobble correction factors. What we are effectively doing is giving the Up camera a value in the down camera domain. One way to visualize it is to imagine the down camera moving until it is precisely above the up camera and recording that value (even though for most of us this is physically impossible we can derive that value). Once one has that value and one moves the camera until the needle is precisely over the up camera, then the needle to camera offset is the difference between these two values in the down camera domain. The up camera position can't change (unless one of the camera moves), so needle wobble correction becomes absolute and no longer relative. A new needle (or new set of rotation positions after power cycle) only needs the wobble correction that is relative to an absolute point in the down camera domain.

The part of my thinking that started all this about moving the needle to the center of the up camera frame is not required to get the advantage outlined above. It does have the advantage that the up camera scaling setup becomes less critical since we are using the same point for all measurements.

Steve

I have made changes to the needle wobble algorithms. Surprisingly, once i delved into it, the centering function became less important. In fact, it is a trivial part of the solution.

Malte et. al. I have made a pull request with the changes.
https://github.com/jkuusama/LitePlacer-DEV/pull/42

Let me say I found that Juha's algorithm worked fine. Yes, it used the needle at the 0 angle position. Any position would have worked. It establishes a known location of the down camera relative to the up camera. The important thing to note is that when the needle is over the up camera, one knows exactly where the down camera is at and that is recorded in the Up Camera Location. The Needle Offset records the distance from that location to not only the needle but also to the Up camera. That relationship between the down camera location and offset to the up camera will not change unless the cameras move. Any following needle calibration point is relative to that known location. This would be true on needle change as well.

However, there was a problem in my eyes. Since the chosen point is on the edge of a wobble, all other calibration points would be away from the center. The point at 180 degrees would be at a wobble diameter away from the center of the up camera. Note that if the machine were power cycled at the different angle and that angle became 0, then the 0 angle would get the calibration values that the previous angle had and another angle (presuming 22.5 increments between the power cycle) would now have the 0,0 calibration values.

A small improvement to the algorithm could be to shift the Up Camera location and/or the Needle Offset so that the reference point was centered on the wobble. I decided to take a different approach. Mathematically, it would seem to have the same result, but there is a difference. I have calculated the position in the CNC domain where the down camera is directly above the up camera. It is the given Up Camera location from above minus the Needle Offset. Now for each needle calibration point I record the position in the CNC domain of the needle. The needle offset for that calibration point is the difference between the two values. If this was the only change, there would be very little improvement. It is how I determine the needle calibration point that is the improvement. Instead of simply rotating the needle around and using the video processing to calculate the position, I move the needle until the video processing says it is directly above the camera. Then the location in the CNC domain is recorded. I do this for all the rotations (22.5 degrees at this time). I used the same centering technique to establish the position of the needle during the Up Camera and Needle Offset calibration procedure. So all measurements are relative to the center of the Up camera.

I have been playing around with this and it seems that I hit the exact same point on the PCB no matter what my needle rotation is. I am happy with the results.

Steve

I turned on Slack Compensation on and found that it needs to be disabled during the needle centering functioning. The compensating moves are bigger than the small moves needed to center the needle. I have changed the algorithm, committed and pushed the changes to my fork.

Malte, do I need to do a another pull request. I suspect that I do.

Steve

sgraves wrote:Malte, do I need to do a another pull request. I suspect that I do.

The pull request is not for a single commit but for a branch.

So anything you commit and push to branch on GitHub is automagically included in your existing pull request.

This is by design, as the discussion of the pull request might lead to further code changes on your side.

You can inspect the pull request online - go to Juha's repo and click tab "Pull Request":
https://github.com/jkuusama/LitePlacer-DEV/pull/42

If you scroll down, you will find a list of all commits included.

If you click those, you will see a detailed summary of the changes. Juha, yourself and others can also comment on these (even inline in the code) and eventually, as all questions are resolved, Juha can merge into his branch.

On the other hand, if you continue making further changes, you should do so in a different branch. This will lead to a situation, where your other branch diverges from Juhas repo - in that case you have to merge (combine his changes and yours) or rebase (put your code on top of the latest state and replay all commits). Both ways have conflict resolution and I guess it sounds more complicated than it is. We'll tackle that once you get there

I will have a look at your changes and test them on my machine some point this week.

Thanks so far.

Thank you for this! I have received the request and when I'm back in the office, I'll handle it.

Juha,
I already assumed as much. I figured you would check in occasionally, but would "vacate" according to plan. I expect you to largely forget about us for now. That is if we are one of your sources of stress. And seeing some of the posts, I expect that we are.

Steve

Some notes on what we have found. First, the cameras are not secure in their body. The cable flexing can change where the camera is looking. We have 3-D printed a bracket to hold the cable securely and prevent it from moving.

Second, the Up Camera position on the setup camera tab minus the Needle Offset should always equal the same value. If they don't then one or both of your cameras have moved.

It is very important that the camera has a fixed relationship with the CNC positions. Almost every operation starts with a camera reference in some way. The moving cable caused us great heartache until we found that it was happening.