There is only one thing that comes to my mind. Check all the
Vision Settings that they are set to Adjust and not Full:

Please report back, if you find anything (or not).
_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/87ae1063-938b-48db-a7f2-d6e6cf9b074fn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4002dc55-9495-2c73-e637-3d014dcb5f69%40makr.zone.
From the perspective of Alignment, this can only happen if the
part appears more than 45° turned. OpenPnP always snaps to the 90°
step angle that is nearest the wanted angle. So if a part were
really off by more than 45°, it would snap to the next + or - 90°.
I don't know if such a >45° offset can physically happen in feed&pick. I guess it depends on the kind of feeder, and accuracy of the pick for small parts (0402 was mentioned). If the pick was off and the vacuum leaking, I can imagine that a part could kinda "rotate-toward-vacuum-suction" on the nozzle tip. 😉
OpenPnP does not have a notion of length and width i.e. which
should be shorter. Even giving it a Footprint and performing the
Size Check does not help: the author implemented it in a way that
doesn't mind swapped width/height (one of my TODOs to improve).
https://github.com/openpnp/openpnp/wiki/Bottom-Vision#using-the-stock-vision-settings
There is always the possibility of a bug in the code, although
I'm really reluctant to believe this, given it works out okay most
of the times. Apart from the vision problems described above, this
is entirely linear math, it can't have any hidden "edge cases".
The same considerations (both vision and math) applies to the PCB/Panel Fiducial vision and Affine transform. At least that is what I assume, @Tony Luken might know more. 😎
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7edcf5cb-f0f4-49a4-9a45-ffd7e1467af5n%40googlegroups.com.
Sounds like a systemic problem. I need more information.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/38d96f56-c112-460b-ba97-92de75341efan%40googlegroups.com.
Thanks.
> 8. Set to "default"
Then the setting is inherited from Machine Setup / Vision / Bottom Vision. Please check there.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/632b6949-2d17-4092-9876-8a1f10c7a103n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b0941242-96e3-bc06-d441-9afafa2e5a41%40makr.zone.
Thanks.
> 8. Set to "default"
Then the setting is inherited from Machine Setup / Vision / Bottom Vision. Please check there.

Loose part feeder opens a whole new can of worms. It could be
wrong there too.
As I have no loose part feeders and no means to simulate, are you
ready to test this if I make a new test Version?
If yes, I'll have a look, in addition to the other problem(s).
> > Mark: " From the perspective of Alignment, this can only happen if the part appears more than 45° turned. OpenPnP always snaps to the 90° step angle that is nearest the wanted angle. So if a part were really off by more than 45°, it would snap to the next + or - 90°"
> But in my mind, I would have thought that 0 degrees on the bottom vision should be exactly the same as 0 degrees on the board (after fiducial checks), or am I missing something here?
When I said "more than 45° turned" I meant relative to
the expected angle, either plus or minus. So everything
should be irrespective of the angle at which it is
actually aligned.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6ecaccee-b2b5-4655-8e15-5d2878f88842n%40googlegroups.com.
its on the other tab ;-)
--
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/dca815be-983f-4f95-a3f9-42d73bb04fadn%40googlegroups.com.
As I have no loose part feeders and no means to simulate, are you
ready to test this if I make a new test Version?
If yes, I'll have a look, in addition to the other problem(s).
Me and my team are ready to test it! :)
Let us know as well if there is any development work that we can assist with as well.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7dea51d0-e018-2239-01b3-15afbb54871d%40makr.zone.
AdvancedLoosePartFeeder or ReferenceLoosePartFeeder?
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAFUn7QxSkD%3DatVCmHU_eKG68kXPjEhNbew%3DGQg6e%2B_KtN2oTcQ%40mail.gmail.com.

Thanks. I checked out both and one suspicion I had, turned out unfounded, it seems to work as it should, provided the vision works.
Could you please add a ImageWriteDebug stage to the feeder pipeline?

Set the prefix to something unique:

Then set the logging level to TRACE.
Then try a small Job again, with parts deliberately at an angle.
Then send the log and the debug images.
https://github.com/openpnp/openpnp/wiki/FAQ#how-do-i-turn-on-debug-logging
https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located
https://github.com/openpnp/openpnp/wiki/FAQ#how-can-i-get-a-native-camera-image
Thanks.
Unfortunately, I gotta go now. Will look into this tomorrow.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/777887b9-421b-4955-8bea-2e7551537149n%40googlegroups.com.
its on the other tab ;-)
Hi Khaled,
in the log I see occasions where the angle is completely wrong:
2023-08-26 00:39:04.522 ReferenceBottomVision DEBUG: Bottom vision part R0805-1K result rect { {644.3677368164062, 344.36370849609375} 94x59 * -44.144901275634766 }
2023-08-26 00:39:04.522 ReferenceBottomVision DEBUG: Offsets too large (0.224080, 0.206479, 0.000000, 44.954952 mm) : center offset 0.30470576093817303 > 0.1
it detects a 44.95° offset from what it expected.
This angular offset is then confirmed in the subsequent alignment
passes, after it has been compensated.
2023-08-26 00:39:05.441 ReferenceBottomVision DEBUG: Bottom vision part R0805-1K result rect { {626.547607421875, 353.59918212890625} 93x58 * 0.9391909241676331 }
2023-08-26 00:39:05.441 ReferenceBottomVision DEBUG: Offsets too large (-0.248193, 0.164251, 0.000000, -0.129141 mm) : center offset 0.29762079596867835 > 0.1
...
2023-08-26 00:39:06.168 ReferenceBottomVision DEBUG: Bottom vision part R0805-1K result rect { {637.1075439453125, 363.65435791015625} 93x58 * 0.9710219502449036 }
2023-08-26 00:39:06.169 ReferenceBottomVision DEBUG: Offsets accepted (-0.093485, 0.012523, 0.000000, -0.160972 mm)
2023-08-26 00:39:06.169 ReferenceBottomVision DEBUG: Alignment result: R0805-1K | X:-0.118 Y:0.383 C:44.665 ?:0.401
When I search for N2.pick() log lines and from these lines look
upwards for the last N2.moveTo() above that, I see angles around
~60°. Which seems to be okay given your image:
So to me, this currently looks as if you get systematic problem
on the bottom camera vision. This could happen with small parts,
when there are bright specks on the nozzle tip in the background,
i.e. they rotate with the nozzle tip, so they will always skew the
rectangle in a similar ways.
Please enable ImageWriteDebug stages in the bottom vision pipeline to get some alignment shots, and send them.
https://github.com/openpnp/openpnp/wiki/Nozzle-Tip-Background-Calibration#trouble-shooting
https://github.com/openpnp/openpnp/wiki/Bottom-Vision#troubleshooting

If this is all good, and we have to turn our eye back on the
feeder:
I don't know much about the ReferenceLoosePartFeeder, but if I were you, I'd try the AdvancedLoosePartFeeder. There is no Wiki page, unfortunately, but the CHANGES say:
* AdvancedLoosePartFeeder
ReferenceLoosePartFeeder has received a big upgrade thanks
to @dzach. The
new AdvancedLoosePartFeeder
is able to be trained to recognize the orientation of loose
parts,
allowing perfect placement of loose bins of both polarized
and unpolartized parts. This
provides a complete feeding solution with no feeders at
all!
A lot of work and discussion has gone into this feature.
For more details see:
https://github.com/openpnp/openpnp/issues/573#issuecomment-311633280
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/openpnp/zqeeh6mGqtk/Ix9MgDbvCAAJ
It is expected that the default pipelines will need to be
tuned and updated as we
get more experience with this new system. Please post your
feedback about this feeder
to the mailing list.
Thank you @dzach!
By implication this means the ReferenceLoosePartFeeder does not recognize the part orientation, so there is a danger it will be off in steps of 90°. In my cursory examination I haven't seen something like that in the log, but maybe I overlooked something.
This looks like no easy solve. So I'll have to see when I find
more time...
_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/034f05df-0cb4-4832-8f31-a449908df817n%40googlegroups.com.
Just FYI, I still have this on the radar. I'm just a bit out of ideas, after having analyzed the code again.
I guess I will have to improve the diagnostics, before the real culprit can be caught. Unfortunately, I don't have much time in the next weeks 🙁.
One additional question:
9. If a part is picked from a certain feeder, will it
always be placed wrong? Or is it the combination of feeder and
placement angle, i.e. on the next board with the same part and
placement, will it also be wrong? Or is this completely random?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3638f857-7917-4480-93ac-a673a6e9a835n%40googlegroups.com.