questions about the new camera calibrations in Issues/Solutions

[james.edwa...@gmail.com]

Dear group, I have a couple of questions:

1) After going through the preliminary camera calibration and then the advanced camera calibration, is there ever a need to go through the preliminary calibration again? If so under what circumstances?

2) After advanced top camera calibration (and re-homing) I see that the fiducials are shifted. Should I manually re-center then?

Best, Jim

[mark maker]

Thank for testing this.

Re 1)

Only if you fundamentally change the machine in terms of the camera, its mounting point, the lens. For slight changes, it would probably suffice to redo the advanced calibration. For larger changes, like changing the camera model, video mode, mount point, exchanging the lens (different focal length) etc. it's probably easier to just re-open all the issues back to the preliminary camera calibration. But then also re-open steps in between, like the precision nozzle offset etc. as they are dependent.

Note: if you fundamentally change the camera X/Y mounting point, you might lose all the coordinates you captured (feeders, nozzle tip changer etc.). These can in theory be safeguarded, by carefully re-referencing everything to the homing fiducial (if you had one), but how to achieve this, is beyond this description.

Re 2)

The secondary fiducial can shift, because the Advanced Camera Calibration corrects the tilt of the camera, which means that the center of the camera view is shifted so it looks down on the machine precisely perpendicular to the machine X/Y-plane. This means that all future X/Y coordinates captured with that camera will be accurate at any Z height. But this was not yet the case when the camera was only preliminary calibrated, therefore the secondary fiducial was captured when the camera view still had the tilt, so it may appear shifted once the tilt is corrected.

However, as the primary fiducial must be at the default Z height, it should not shift. Instead, the center shift brought in by correcting the tilt should  be compensated by a dynamic head offset applied to the camera (i.e they should cancel each other out).

To illustrate with the image below: The tilt shift changes the camera view center from the raw pixel center (red ray) to the perpendicular (blue ray). The raw camera view (black outline) is shifted, rectified with X/Y, and cropped (green rectangle). To compensate for the tilt shift (green arrow), camera head-offsets are applied internally. But at a higher Z (secondary fiducial) the head offsets are too much, therefore the raw-captured secondary fiducial appears slightly shifted. Obviously, no such thing will ever happen with locations captured after the advanced calibration (i.e. those captured with the blue-line).

If you see the primary fiducial shifted, this might be a bug, then please provide more info.

Note: the fiducial coordinates are not that important. As long as the fiducial vision still finds them, they're OK. It is also OK to have a removable, hand-mounted calibration rig, that might shift a bit. The fiducials are always re-calibrated before they are used inside any subsequent calibration routines.

However, the example also shows that it is important to apply the Advanced Camera Calibration before camera-capturing important locations at Z coordinates different than default Z / PCB surface Z. 

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cdd4ff8c-19c5-4963-8e94-c197ef742f69n%40googlegroups.com.

[tonyl...@gmail.com]

As Mark said, the location of the primary fiducial should be unchanged. However, if your homing fiducial is at a different Z coordinate than your primary fiducial, then the apparent shift in the homing fiducial (since its location was captured prior to advanced calibration) will get removed during visual homing and that will in turn make it appear as if everything else has an offset.  I think the bottom line is that any locations that were captured prior to advance calibration should be checked to verify their correctness (especially any with a Z coordinated different than your homing fiducial).  That's why its very important to get the top camera calibrated ASAP when setting up a machine.

Tony

[Jim Freeman]

Hi Tony (and Mark). I am continuing to explore the results of the test version. I have a question. I used to have a script that would move to (0,0) the homing spot. It doesn't work the same after advanced calibration. It moves to the negative of the top camera offset distance from the homing spot. Is this what I should expect?

I am including a png of the python script (I think my email filters python files out) as well as the camera calibration tab also showing the homing fiducial offset. As you can see the offset is the negative of the camera calibration offset.

If there is a better way to go to an (X,Y) point could you please tell me?

I also have a question/comment about Z  parking. To me this is a safety issue, I want to park the Z before moving (like jogging to find a feeder location.) It seems the way it works now is that unless "nozzle" is selected in the camera pane, Z parking doesn't do anything. So if "down camera" is selected when Z park is hit, nothing happens. If I select nozzle, then parking operates normally. I don't know why down camera is sometimes selected or nozzle is selected, I am not doing it. But it leaves the user in a dangerous state if the nozzle is down, he tries to park it, but didn't notice that the pane is in "down camera" mode. At least a warning " Physical parking is inoperative when in down-camera mode" or something like that to warn the operator.

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ea6a6eef-cc3c-43e8-b31e-e8a94948bef2n%40googlegroups.com.

[mark maker]

>  It doesn't work the same after advanced calibration.

Physically, yes that's true. The tilt shift is applied.

Optically, in the camera view cross-hairs, this should not be the case. They should pinpoint the same spot as before, assuming that spot is at default Z, i.e. the same Z as the primary calibration fiducial and (typically) PCB surface Z.

Please report whether your homing fiducial is at default Z.

If this is the case and if I understand your description correctly,  this would point to a bug in the Advanced Camera Calibration and/or my invocation of it in Issues & Solutions.

> I also have a question/comment about Z  parking.

I will investigate if this has changed.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyD2Z2pdC3jKRHG%3Dvpj0G9g2SeiCUebW7CA6YM%3DwVzMB_Q%40mail.gmail.com.

[Jim Freeman]

My primary fiducial is at -23mm.  The homing fiducial is at -19mm. So not exactly the same. My camera ias a Y angle error of about 1.5 degrees. Tan(1.5 degrees) * 4mm = 0.1mm   So the apparent offset of the homing dot is much more than that.

--Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c1714302-8a22-1699-38b0-fb817191c2d5%40makr.zone.

[mark maker]

About the Z parking:

I've looked it up, the Park Z button never moved other tools to Safe Z. Only the selected tool.

However, due to the rather new Auto tool select option and the urge to enable this option for use with virtual camera Z axes and 3D units per pixel, this might still become more of a problem, now.

https://github.com/openpnp/openpnp/wiki/3D-Units-per-Pixel

Therefore, I added a new option on the Machine, where you can enable the safer behavior:

https://github.com/openpnp/openpnp/pull/1355

Available in the testing version (wait a few minutes for it to be deployed).

https://openpnp.org/test-downloads/

@Jim, please test, if possible,

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c1714302-8a22-1699-38b0-fb817191c2d5%40makr.zone.

[mark maker]

About the Advanced Camera Calibration:

I'm afraid I have to defer to @TonyLuken to find the issue.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyBd3h9eJbFCg73LaVRqT0x%2BbwXbBVnMsNkCfhRbL_PD%2Bg%40mail.gmail.com.

[tonyl...@gmail.com]

Jim,

Can you set your logging level to trace, rerun the advanced calibration on your top camera, and post the resulting log file?

Tony

[tonyl...@gmail.com]

Jim,

Can you also clarify - are you running your script before or after the machine has been re-homed after advanced calibration has completed? If before, please try homing and then running the script - does that still produce an offset from the homing fiducial?

Tony

[Jim Freeman]

Hi, Tony. Here is the log file. It seemed to be successful.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/63fa00d3-2ddc-4498-9d76-11798dbbc3e5n%40googlegroups.com.

[Jim Freeman]

I I recalibrated, sent you the log file. Then exiting the machine, restarting, homing then ran my script.  I got a slightly different camera offset this time, and after running my script the crosshair is almost exactly the negative of the offset in both x and y.

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/_BqWBSMAdt8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b58c48e1-7868-459d-893e-ccd234b2c8b7n%40googlegroups.com.

[tonyl...@gmail.com]

Jim, 

Are you sure that's the correct log? I can't find where advanced camera calibration was run anywhere in it.  Also did you see my earlier question about your script?

Tony

[Jim Freeman]

IHi, Mark>

 just downloaded the newest test and re-built and ran. The functionality I see is:

If the nozzle is not parked, hitting the "park" buttone parks it. This is independent of if the check box is checked or not. If I move the nozzle, select down camera, then park, the nozzle goes to park. Like I said, it is independent of check box status.

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3e640b7c-5608-24a9-dd78-939b7b6100b4%40makr.zone.

[Jim Freeman]

Yes, that was the correct log file. Let me do it again.

--Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/beb7fca5-0176-4932-a8fc-62a40686886dn%40googlegroups.com.

[Jim Freeman]

Here is a new log file, I only used 4 rays instead of the usual 32 to save time.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/beb7fca5-0176-4932-a8fc-62a40686886dn%40googlegroups.com.

[tonyl...@gmail.com]

Yes, that newest log has an advanced camera calibration run in it.

> I only used 4 rays instead of the usual 32 to save time.

That's ok, but how did the offsets look afterwards?  I see the estimated camera tilt was less on this run:
2022-01-03 14:51:49.109 AdvancedCalibration TRACE: Z axis rotational error = -0.6962492337627894 degrees 2022-01-03 14:51:49.110 AdvancedCalibration TRACE: Y axis rotational error = -0.8778178641291102 degrees 2022-01-03 14:51:49.110 AdvancedCalibration TRACE: X axis rotational error = -0.9745956285875966 degrees

And just to make sure we're all on the same page here - after running advanced camera calibration, re-home the machine. Then report what offsets you are seeing over the homing fiducial and both calibration fiducials.

Thanks,

Tony

[Jim Freeman]

Hi, Tony. Here you go.  There are 2 pictures. One is "after the calibration, re-homing, driving a distance to my X Y park spot, then using my python script to go to x=y= 0."  You see there is an error between the homing spot and the cross hair.  The second picture is where I manually adjust from the previous location to find the center of the homing spot. As you can see the offset is almost exactly the negative of the camera calibration location.

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cb2042d9-1ad2-497b-92ef-dd0a8c5c8fe4n%40googlegroups.com.

[Jim Freeman]

Hi, Tony. Here is a log file of when I do a 8 ray run. It is interesting that at time 15:09:03.571  there is an error. 

On Mon, Jan 3, 2022 at 3:09 PM tonyl...@gmail.com <tonyl...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cb2042d9-1ad2-497b-92ef-dd0a8c5c8fe4n%40googlegroups.com.

[fxframes]

Anyone experiencing disabled “Accept” buttons in the last test version inside I&S…?

[Jim Freeman]

Which button in particular?

On Mon, Jan 3, 2022 at 3:41 PM fxframes <mp5...@gmail.com> wrote:

Anyone experiencing disabled “Accept” buttons in the last test version inside I&S…?

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3c1339df-d8b2-4a72-add8-f55c0964a428n%40googlegroups.com.

[fxframes]

The Accept button. Downloaded the test version this morning. 

[james.edwa...@gmail.com]

Sorry, I never had that issue. Tony would be the expert on that.

Best, Jim

 

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of fxframes
Sent: Monday, January 03, 2022 4:25 PM
To: OpenPnP <ope...@googlegroups.com>
Subject: Re: [OpenPnP] questions about the new camera calibrations in Issues/Solutions

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7c6a5235-2e3b-4706-a207-0225de15aebdn%40googlegroups.com.

[tonyl...@gmail.com]

Mark would be more of an expert on the disabled Accept button - that's all part of Issues and Solutions and not part of camera calibration.

Jim,

Can you also attach your machine.xml file?  I don't see any position reports being requested or processing in you log file.

Tony

[james.edwa...@gmail.com]

Hi, Tony. I can’t do that until tomorrow, sorry. I have left work.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7a8132f3-bf14-47ec-9ee0-6dce745e14c3n%40googlegroups.com.

[mark maker]

Hi Jim,

I re-checked the source code and ran a test and I can almost certainly exclude such a behavior. The code is simple and was properly pushed too:

https://github.com/openpnp/openpnp/blob/test/src/main/java/org/openpnp/gui/JogControlsPanel.java#L596-L598

> re-built

Am I right to assume you run from git?

Are sure everything got properly merged, and you are truly on the test branch?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyDFUfZhcTi-XO879M7TK0vk2iAme%3D7O4mK-Srs9FJ0Y8g%40mail.gmail.com.

[mark maker]

Hi fxframes,

Is this reproducible?

I checked the source code. The only way this can happen should be when you select multiple lines in the issues list, but your screenshot does not look that way.

If you press Find Issues & Solutions again and then click on that single line again, does it remain?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7c6a5235-2e3b-4706-a207-0225de15aebdn%40googlegroups.com.

[mark maker]

Also send the log, maybe there's a hidden exception.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/30a060c6-f4c5-593d-99e0-922d6c4a13c2%40makr.zone.

[fxframes]

Hi Mark,

After shutting everything off and on again, it went away. I'll try to verify if this happens again when a new test version comes out.

Thanks for replying.

[fxframes]

Hi All,

Sorry another problem.

Just redid the primary and secondary calibrations and both went fine.

[fxframes]

This problem is now back. Log is attached. Thanks.

[fxframes]

If I click on "Find Issues and Solutions " again the button is re-enabled. :)

[fxframes]

Log is attached. It ends with the fiducial not being found.

Just speculating, but wasn't there a recent change to the fiducial bottom vision settings merged into the test version?
Thanks,

[mark maker]

Hi fxframes

Remember, when you did the preliminary calibration, you had to adjust the fiducial diameter. And it seemed to have worked then, right?

Have you since

1. Changed the calibration rig in any way, expecially the fiducial?
2. Changed the camera, lens, mounting point, video mode?

If in doubt, re-open all the calibrations steps back to the preliminary primary fiducial camera calibration. Enable Include Solved, select issues, and press Reopen.

Then redo them in order.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cdff2743-0a6e-41d6-89c2-8d869a442bc3n%40googlegroups.com.

[fxframes]

Hi Mark,

> when you did the preliminary calibration, you had to adjust the fiducial diameter. And it seemed to have worked then, right?

Correct.

> Have you since 
Changed the calibration rig in any way, expecially the fiducial?

No.

> Changed the camera, lens, mounting point, video mode?

No.

> If in doubt, re-open all the calibrations steps back to the preliminary primary fiducial camera calibration. Enable Include Solved, select issues, and press Reopen.

Then redo them in order.

That’s what I did before testing the new camera calibrations because it asked for the original primary and secondary fiducial setup which was done a while ago and I wasn’t sure, so I decided to redo everything. I’ll try once again.

Thanks,

[mark maker]

> No, No.

> I wasn’t sure, so I decided to redo everything. I’ll try once again.

Wait. In that case, no!

Can you screen-record another attempt at Advanced Camera Calibration?

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8C7E39D5-9F4E-4E76-8A67-3F442D3D5B6E%40gmail.com.

[fxframes]

Can you screen-record another attempt at Advanced Camera Calibration?

Sure.

[fxframes]

Here it is. Thanks for looking into this.

[mark maker]

Videos are often sooo good for diagnosis. 😉

There seems to be no camera settling taking place. And sure enough, if I look at a log you posted a while back:

2022-01-04 13:15:07.658 Scripting TRACE: Scripting.on Camera.BeforeCapture

2022-01-04 13:15:07.667 Scripting TRACE: Scripting.on Camera.AfterCapture

You have a mere 9ms settling time. No reasonable camera is that fast, no reasonable DIY machine that stiff .

https://github.com/openpnp/openpnp/wiki/Camera-Settling

_Mark

On 04.01.22 15:43, fxframes wrote:

Here it is. Thanks for looking into this.

[fxframes]

Indeed. 🙂

But my camera settling time is actually set at 300 ms. 🤔

I’ll try to go through the camera settling procedure/diagnostics anyway.

-- 
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/_BqWBSMAdt8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/78d32759-adf5-d9b4-bd56-f78bcef87f17%40makr.zone.

[mark maker]

> But my camera settling time is actually set at 300 ms. 🤔

WT...

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/A66226D6-6ED7-4645-B4E3-42334CE84E15%40gmail.com.

[Jim Freeman]

Hi, Tony. For completeness I am sending the: 

log file of when I did the calibration

image of home fiducial offset after calibration and re-homing, then moving the hed to the XY park location, then using my python script to bring the camera back to the homing fiducial

image of home fidicual after I manually correct (jog) the crosshair back over the home fiducial. There you can see the required offset which is pretty exactly the calibrated camera offset. It is as if the camra offset is not applied for the actions in my script.

my machine file.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7a8132f3-bf14-47ec-9ee0-6dce745e14c3n%40googlegroups.com.

[fxframes]

Hey Mark,

🙂

I’ve configured the camera settling setup to work with Maximum, Euclidean and back to FixedTime.

Unfortunately the camera calibration procedure can’t find the fiducial regardless of the settling setup.

Thanks for looking into this.

On 4 Jan 2022, at 15:11, mark maker <ma...@makr.zone> wrote:

> But my camera settling time is actually set at 300 ms. 🤔

WT...

On 04.01.22 16:05, fxframes wrote:

Indeed. 🙂

But my camera settling time is actually set at 300 ms. 🤔

I’ll try to go through the camera settling procedure/diagnostics anyway.

<Screenshot%202022-01-04%20at%2015.01.46.png>

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7b9420e3-c6f1-0f67-b9a1-2cb3b25c939e%40makr.zone.

[tonyl...@gmail.com]

Hey Mark,

I'm looking at the issue Jim pointed out - that after advanced camera calibration his script (which just moves the camera to (0, 0)) shows an offset over the homing fiducial.  I suspect this is either a feature or a bug in visual homing.  It appears that if the top camera has a non-zero head offset (either calibrated or not), that when visual homing is complete, the location of the camera when it is exactly over the homing fiducial is not (0, 0) but rather equal to its head offsets.  Is that what you would expect?  That doesn't seem intuitive to me.  I'd expect visual homing to complete with the top camera having a location of (0, 0) regardless of any head offsets it may have. In other words, shouldn't visual homing account for the fact that the camera has non-zero head offsets and subtract them before setting the motion planner global offsets?

Tony

[Jim Freeman]

By the way, when I hit the "position camera over location" on the configuration tab of the reference head, it goes to exactly the same spot as my script. See attached image.

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/817865f1-aaec-43b7-ad87-78a42166e711n%40googlegroups.com.

[mark maker]

Hi Tony,

Good analysis. Shame on me, I was always testing with Visual Homing set to the modern ResetToFiducialLocation, now that you mention it, I guess there is a bug when you use ResetToHomeLocation which is only used for backwards compatibility with legacy machine configurations. 

https://github.com/openpnp/openpnp/wiki/Visual-Homing

@Jim, am I right you are using ResetToHomeLocation?

I guess it should account for the head offsets here:

https://github.com/openpnp/openpnp/blob/95d557ea31fd36f2f336ed1e266218c0f9f89d52/src/main/java/org/openpnp/machine/reference/ReferenceHead.java#L88

Note, this is arguably not a new bug, if my reasoning is correct, it should always have done that, including way back when this was still a part of GcodeDriver (from where I took it). The reason this only pops up now is that there were traditionally no head offsets for the top camera. Now there are.

I'll fix this.

@Tony, do you agree that the code for ResetToFiducialLocation looks good? The head offsets are accounted for in
toHeadLocation().

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/817865f1-aaec-43b7-ad87-78a42166e711n%40googlegroups.com.

[james.edwa...@gmail.com]

I originally saw this “feature” using my own script, which had been working for several years by now. I am attaching it.

I also saw the same behavior with the ResetToHomeLocation button.

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of mark maker
Sent: Tuesday, January 04, 2022 1:36 PM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] questions about the new camera calibrations in Issues/Solutions

 

Hi Tony,

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/46c1f3e8-2ca4-a4f7-85ca-e7a663e9611e%40makr.zone.

[mark maker]

> I originally saw this “feature” using my own script, which had been working for several years by now. I am attaching it.

> I also saw the same behavior with the ResetToHomeLocation button.

Sorry, I don't understand what you mean. Do you use Visual Homing? If yes, with ResetToHomeLocation or ResetToFiducialLocation?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/020301d801a3%24d7fdef70%2487f9ce50%24%40gmail.com.

[james.edwa...@gmail.com]

Also, I observed the same behavior when I hit the red “go to home location button” in the configuration tab.

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of mark maker
Sent: Tuesday, January 04, 2022 1:36 PM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] questions about the new camera calibrations in Issues/Solutions

 

Hi Tony,

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/46c1f3e8-2ca4-a4f7-85ca-e7a663e9611e%40makr.zone.

[tonyl...@gmail.com]

Yeah, I think I'm ok with the ResetToFiducialLocation code.  According to Jim's machine.xml file, he is using ResetToHome which explains why he is seeing the problem.

Tony

[james.edwa...@gmail.com]

Hi, Tony. Does this mean I have a problem in my machine.xml file?

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a7c64f57-36dd-4ca2-bdc2-a7baffa4ff27n%40googlegroups.com.

[mark maker]

No, you found a bug with that legacy option: ResetToHomeLocation, thanks for reporting it!
👍

https://github.com/openpnp/openpnp/wiki/Visual-Homing#setting-up-visual-homing

https://github.com/openpnp/openpnp/wiki/Visual-Homing#method-for-old-machines

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/022301d801a9%24499a2810%24dcce7830%24%40gmail.com.

[mark maker]

Hi Jim,

There is a new testing version of OpenPnP 2.0 available. You are in a unique position to really physically test it. Please help! 😁

https://openpnp.org/test-downloads/

See the PR:

https://github.com/openpnp/openpnp/pull/1356

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/133d50cb-b410-2ef7-e22a-938cc4c81823%40makr.zone.

[james.edwa...@gmail.com]

No problem. I am actually REALLY glad to be of any help! I ask so many questions and you develop so many great features!  I will do it in the morning, I have already left work.

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/64e3dbe1-ce43-5dbf-27a3-bacf34fbae5d%40makr.zone.

[tonyl...@gmail.com]

Mark,

I just made a quick test and the problem appears resolved.  With a both a legacy head offset and a calibrated offset, visual homing sets the DRO to the legacy head offset.  So if the legacy head offset is zero the DRO reads zero (as expected).  Hopefully Jim will have positive results as well.

Tony

[fxframes]

Good morning everyone,

I installed the new test version and my old problem (fiducial not being found) went away, whatever was causing that.

Two new issues surfaced, though:

1. Towards the end of the procedure with the primary fiducial the motion froze and one of those "waiting for the TinyG to respond" warnings came up. The procedure however ignored it and carried on. Not sure about the data sanity as from the counting it didn't seem it was completely finished (with the primary fiducial).

2. At the very end, when it was doing some math an exception was thrown.

Thanks,

[tonyl...@gmail.com]

Jim,

Please post your log and machine.xml from that latest run.

Tony

[fxframes]

OK so after redoing everything from scratch it passed both advanced calibrations.

The TinyG seems incredibly sensitive to anything going wrong, it's as if some garbage gets stuck there and only a full restart clears it.

My only issue now seems to be that after the downcam calibration the head is trying to move beyond the X Axis soft limit when homing and it's hitting the limit switch. 

Also maybe let people know that if you have a diffuser on your uploading camera this procedure will wreck it. =)

[Jim Freeman]

Hi, Mark. I downloaded the newest test version as of this morning and ran it. Both my script and the button in the config tab seem to work as expected. The camera is moved to center over the homing fiducia. I am enclosing a screen shot and my log file.

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/64e3dbe1-ce43-5dbf-27a3-bacf34fbae5d%40makr.zone.

[mark maker]

Nice, thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyAP6F57Xf3K4VCoLDoW7pVF1TqLGz5bURBJ9UZt%3DbTJ7w%40mail.gmail.com.

[mark maker]

> the head is trying to move beyond the X Axis soft limit when homing and it's hitting the limit switch

Yes, if the camera tilt was unfortunate and the homing fiducial very close to the electro-mechanical homing position, this can happen. I know this was the standard way to do it, before the ResetToHomingLocation method was introduced, which advocates a more central homing fiducial position (and obviously the machine explicitly moving towards it, before visually homing):

https://github.com/openpnp/openpnp/wiki/Visual-Homing#mounting-a-fiducial

Unfortunately, I can't directly help you here (yet).

> Also maybe let people know that if you have a diffuser on your uploading camera this procedure will wreck it. =)

A better warning is in the pipeline.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4996a028-fb91-41a8-a57d-ebd922bc2af6n%40googlegroups.com.

[tonyl...@gmail.com]

>The TinyG seems incredibly sensitive to anything going wrong

Is the TinyG reporting any kind of error?  Usually there will be some sort of message in the log file.

 

> My only issue now seems to be that after the downcam calibration the head is trying to move beyond the X Axis soft limit when homing and it's hitting the limit switch.

Check the tilt of your downcam reported in the diagnostics section of the Advanced Calibration tab.  You probably have a positive tilt about the Y-axis which allowed the uncalibrated camera to be centered on objects further to its left (-x direction). Once calibrated, it is now looking straight down so the camera has to be physically moved further to the left in order to be centered on the same object.  It doesn't look like you need much more travel, could you just adjust the x min limit switch slightly to give you an extra millimeter of travel (and change your soft limit)?  Otherwise you need to move your homing fiducial to the right and when you do that I'd suggest you switch to ResetToHomingLocation method.

>Also maybe let people know that if you have a diffuser on your uploading camera this procedure will wreck it. =)

If you run advanced camera calibration manually from the Advanced Calibration tab, there is a bright yellow and black warning message to that affect.  I believe Mark is working on adding a similar message when it is run via I&S.  I guess we could also add a limit to how far the nozzle tip is permitted to travel from its central location during the calibration sequence but that is something the operator would have to manually enter on the GUI. 

[tonyl...@gmail.com]

> Also maybe let people know that if you have a diffuser on your uploading camera this procedure will wreck it. =)

It just occurred to me - what good is having a diffuser mounted higher than the level where you are going to be doing part bottom vision?  Doesn't the diffuser need to be lower than the bottom of the part?

[mark maker]

> It just occurred to me - what good is having a diffuser mounted higher than the level where you are going to be doing part bottom vision?  Doesn't the diffuser need to be lower than the bottom of the part?

I was aware that we must assume that cameras are sunken beneath tables, perhaps in some kind of shaft, so the focal plane is aligned with the table/PCB surface. The focal plane may be slightly beneath the table, i.e. we could bump into walls of said shaft. I wasn't thinking of a diffuser, though, I can't think of why a diffuser would be higher up than the part it is supposed to light.

However, I was always also working under the assumption that the bare nozzle tip (and we recommend to use the finest!) is free to move over the whole camera view. Only when a large tip and/or part is loaded, must one be more prudent, as the part could bump into walls on the side.

On the secondary Z (higher), the assumption was, that we have cleared any sunken structure, and we can move around even more liberally (which is needed with a wide lens view, opening up at higher Z). 

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1fe26abd-c73e-41fb-ac38-753ba06c65adn%40googlegroups.com.

[fxframes]

> Check the tilt of your downcam reported in the diagnostics section of the Advanced Calibration tab.  You probably have a positive tilt about the Y-axis which allowed the uncalibrated camera to be centered on objects further to its left (-x direction). Once calibrated, it is now looking straight down so the camera has to be physically moved further to the left in order to be centered on the same object.  It doesn't look like you need much more travel, could you just adjust the x min limit switch slightly to give you an extra millimeter of travel (and change your soft limit)?  Otherwise you need to move your homing fiducial to the right and when you do that I'd suggest you switch to ResetToHomingLocation method.

> Yes, if the camera tilt was unfortunate and the homing fiducial very close to the electro-mechanical homing position, this can happen. I know this was the standard way to do it, before the ResetToHomingLocation method was introduced, which advocates a more central homing fiducial position (and obviously the machine explicitly moving towards it, before visually homing):

https://github.com/openpnp/openpnp/wiki/Visual-Homing#mounting-a-fiducial
Unfortunately, I can't directly help you here (yet).

Thanks for the replies.

These are my results.

I’ve tried moving the limit switch but unfortunately it wasn’t enough, it kept reporting the same error. I already moved it once before because I was running into the same issue with the backlash calibration procedure so there's just very limited space there.

I’m a bit confused because that page (https://github.com/openpnp/openpnp/wiki/Visual-Homing#mounting-a-fiducial) says that that ResetToHomeLocation is not to be used with new machines.

If I have to move the home fiducial and start from scratch, why not use the “new” method ResetToFiducialLocation?

So if I have to recapture all locations :( do I have to run the advanced camera calibrations again?

That’s another warning that should be very clear to the user IMHO before they start the procedure.

I understand the risks associated with testing a new feature, but once it’s in the main version it can become very frustrating.

––––––––

> If you run advanced camera calibration manually from the Advanced Calibration tab, there is a bright yellow and black warning message to that affect.  I believe Mark is working on adding a similar message when it is run via I&S.  I guess we could also add a limit to how far the nozzle tip is permitted to travel from its central location during the calibration sequence but that is something the operator would have to manually enter on the GUI.

> It just occurred to me - what good is having a diffuser mounted higher than the level where you are going to be doing part bottom vision?  Doesn't the diffuser need to be lower than the bottom of the part?

Honestly I think having the warning on I&S as well is good enough.

In my case I didn’t think too much about the diffuser, I mostly followed the LitePlacer installation instructions but I think you’re right there the diffuser should be sitting below the image capturing plane. For now I even removed it.

––––––––

> Is the TinyG reporting any kind of error?  Usually there will be some sort of message in the log file.

Yes, most of the time it’s the "timeout waiting for response” error, but’ve had OpenPnP crash on me today while testing.

I’ve also posted an exception I got a few posts ago.

If I go to File > Save Configuration at any time, the next procedure will be messed up.

Over time I’ve learned to take it easy with the TinyG, like don’t do things in parallel, let it finish what it’s doing before starting something else, stuff like that.

Since it seems I’ll have to start over I’ll try to capture any errors that pop up.

[tonyl...@gmail.com]

Sorry, I misspoke, I meant to say switch to the new ResetToFiducialLocation.  You shouldn't need to run calibration again on the top camera.

>Yes, most of the time it’s the "timeout waiting for response” error

No that is an error generated by OpenPnP when it doesn't get the response it is expecting.  Sometimes TinyG will report something unexpected and that should appear in the log, something like:

2022-01-05 13:34:40.898 GcodeDriver$ReaderThread TRACE: [serial://COM5] << {er:{fb:440.21,st:204,msg:"Limit switch hit - Shutdown occurred"}}

[mark maker]

Hi fxframes,

This is a procedure to "migrate" to the new ResetToFiducialLocation method, without losing any coordinates you already captured. I write this for you and other users with a similar config.

1. This works easily, if your fiducial was very near the (electro-mechanical) homing coordinates. Otherwise see 14-17.
2. This is delicate: proceed with care and to the dot!
3. Leave your existing old homing fiducial physically intact (important!).
4. Mount a new fiducial in a more central location, both in X and Y (as described in the Wiki).
5. Start OpenPnP fresh.
   
6. (for fxframes's case only) Switch off the Advanced Camera Calibration. This will remove the tilt shift and make Visual Homing work again, temporarily.
7. Perform a full machine homing. Make sure the visual homing was successful and your old homing fiducial is perfectly in the cross-hairs, when you move to the home location (your script).
8. While the machine is still homed that way, do the following steps (don't interrupt this!)
9. Set Homing Method on the head to ResetToFiducialLocation, press Apply.
10. Jog to the new homing fiducial, press Visual Test to center the camera perfectly.
11. Capture the new Homing Fiducial fiducial location using the usual blue camera button. Press Apply.
12. (for fxframes's case only) Switch on the Advanced Camera Calibration again.
    
13. Test a full machine homing. It should now use the new fiducial and the modern ResetToFiducialLocation method.
    
14. If it does not find the fiducial, then your former ResetToHomingLocation configuration had a fiducial location that did not match the homing location at all, perhaps due to home-to-max, large retract, or something. The electro-mechanically homed coordinate system is too different from the visually homed one. You need to figure out the shift in X/Y.
    
15. Alternative A: if you have the TinyG, set the home coordinates on the X, Y Axes in OpenPnP to correspond to the visually homed coordinate system (compensate the shift). Then delete (empty) your existing HOME_COMMAND and let Issues & Solutions generate a dynamic one.
    
16. Alternative B: in our controller's config (e.g. Smoothieware config.txt), set the X, Y home coordinates to correspond to the visually homed coordinate system (compensate the shift).
    
17. Alternative C: Add G-code to your HOME_COMMAND to roughly move the camera over the old homing fiducial using coordinates of the electro-mechanically homed machine coordinate system and then reset this position to the visually homed coordinate system, something like this:
    ... ; existing homing sequence
    G1 X10 Y650 ; move roughly over the old fiducial (but use your raw old fiducial coordinates!)
    G92 X0 Y0 ; reset to old home coordinates (but use your old home coordinates!)
18. Retry from 13.
    

Report back if it works.

I've also added it to the Wiki:

https://github.com/openpnp/openpnp/wiki/Visual-Homing#migrate-to-new-resettofiduciallocation-method

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e74b5422-ec91-4779-9378-9420c9b7882en%40googlegroups.com.

[fxframes]

Thanks so much Mark, this is very thoughtful.

One question though before I proceed: I already had ResetToFiducialLocation active before all of this. Will #15 still work?

[mark maker]

> I already had ResetToFiducialLocation active before all of this. Will #15 still work?

Wait: are you saying that you already had a ResetToFiducialLocation configuration before?

If yes:

Then it is really simple. Just leave out step 9 and stop after step 13. You are guaranteed to not need steps 14. - 18.

If no:

The important thing is that you have not physically changed the old fiducial and not changed the fiducial coordinates in OpenPnP (otherwise restore them from old config). You can then switch back to ResetToHomingLocation and proceed with the procedure.

_Mark

Am 06.01.2022 um 11:26 schrieb fxframes:

Thanks so much Mark, this is very thoughtful.

One question though before I proceed: I already had ResetToFiducialLocation active before all of this. Will #15 still work?

On Thursday, January 6, 2022 at 9:37:08 AM UTC ma...@makr.zone wrote:

Hi fxframes,

This is a procedure to "migrate" to the new ResetToFiducialLocation method, without losing any coordinates you already captured. I write this for you and other users with a similar config.

1. This works easily, if your fiducial was very near the (electro-mechanical) homing coordinates. Otherwise see 14-17.
2. This is delicate: proceed with care and to the dot!
3. Leave your existing old homing fiducial physically intact (important!).
4. Mount a new fiducial in a more central location, both in X and Y (as described in the Wiki).
5. Start OpenPnP fresh.
   
6. (for fxframes's case only) Switch off the Advanced Camera Calibration. This will remove the tilt shift and make Visual Homing work again, temporarily.
7. Perform a full machine homing. Make sure the visual homing was successful and your old homing fiducial is perfectly in the cross-hairs, when you move to the home location (your script).
8. While the machine is still homed that way, do the following steps (don't interrupt this!)
9. Set Homing Method on the head to ResetToFiducialLocation, press Apply.
10. Jog to the new homing fiducial, press Visual Test to center the camera perfectly.
11. Capture the new Homing Fiducial fiducial location using the usual blue camera button. Press Apply.
12. (for fxframes's case only) Switch on the Advanced Camera Calibration again.
    

1. Test a full machine homing. It should now use the new fiducial and the modern ResetToFiducialLocation method. If it works, you're done.
   

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/820e8d6b-a7f0-4358-ad83-eb1382a6c657n%40googlegroups.com.

[fxframes]

> Wait: are you saying that you already had a ResetToFiducialLocation configuration before?

Yes.

> Then it is really simple. Just leave out step 9 and stop after step 13. You are guaranteed to not need steps 14. - 18.

Unfortunately I ended up physically moving my home fiducial location a bit. I know. 🙄

I guess there’s no way around it now...

I’ve been wanting to add non-squareness compensation to the machine for a while now so I guess the opportunity presented itself…

Thanks for the support. 👍🏻

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/_BqWBSMAdt8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9962c43e-78ca-dc9a-854d-63baeb792344%40makr.zone.

[fxframes]

Hi Mark,

I proceeded to set a new position for the home fiducial and the machine finds it and aligns to it, but still throws this message.

Any advice?

Thanks.

[mark maker]

If you have the fiducial at a new position, you'll lose all captured locations so far, but you knew that (quoting "I know. 🙄"):

Then temporarily switch off any visual homing, set Homing Method to None.

Then re-home the machine. It should now only do the electro-mechanical homing.

Then proceed as with a new machine:

https://github.com/openpnp/openpnp/wiki/Visual-Homing#method-for-new-machines

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9c664f45-67c7-4f81-b22e-7b3c3e075c6an%40googlegroups.com.

[Duncan Ellison]

Hi _Mark,

I've come back to my machine after a few month absence and I'm trying to catch up.

I did have my machine set up to mechanically home against the stop switches in the 'back left' corner then visually home on the diffuser ring on the bottom camera.  This has been working OK and the theory was that the two cameras would then 'self-align'.  Your recent work got me thinking though that this probably isn't optimal since the diffuser isn't at the board plane.

So ... I created a 6mm round fiducial on a black 3D printed holder and bolted this permanently to the PCB holder rails fairly close to the board 0,0 position and so that the white spot is exactly at the Z plane of the board.   I have another 40mm to the right at a known height above the board.

I'm now visually homing on the first fiducial and intend this to be in place 'forever' on the machine.  The second (higher) one is on location dowels and I can bolt and unbolt it as needed and it will still be in exactly the same position.

I've got a bit confused though about what we are calling the 'primary' and 'visual homing' fiducials.  Is there any reason why these can't be one and the same? 

Duncan

[tonyl...@gmail.com]

Hi Duncan,

The homing fiducial and the primary calibration fiducial can be one and the same.  Note however, that the calibration fiducials need to be mounted far enough away from the X and Y axis limits such that the camera can be positioned over them to make the fiducial appear in all of the four corners of the image (that is what the advanced calibration does).  So as long as you can jog the camera far enough that you can view the homing fiducial in all four corners of the camera's image without running into an axis limit, you can use it as the primary calibration fiducial as well.

Tony

[mark maker]

> I've got a bit confused though about what we are calling the 'primary' and 'visual homing' fiducials.  Is there any reason why these can't be one and the same?

They can be the same. Your setup sounds good.

I assume you read these directions too, regarding the free to move area around it?

https://github.com/openpnp/openpnp/wiki/Vision-Solutions#calibration-steps

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/17efc85c-148e-4890-a5a8-16974e390e76n%40googlegroups.com.

[mark maker]

> So as long as you can jog the camera far enough that you can view the homing fiducial in all four corners of the camera's image without running into an axis limit, you can use it as the primary calibration fiducial as well.

There should be more freedom of motion for the axis backlash calibration. ~125mm on each side, ideally.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4128de0a-8cd4-411f-8615-f20653407f38n%40googlegroups.com.