|
Edge probe issues
page [6 posts] |
9 year
|
Hi!
I'm having some issues with the edge probe module. I have three sequential probes (with different regions / params) separated by 'display variables' for debug purposes.
The first detects 1 edge and puts it into 'probed_edges'. The second detects two and puts the result in 'probed_edges_1' and _2. I'd expect the third to create new vars, but _1 and _2 get overwritten. Is this normal? Also, I have a _3 which is empty and don't know where it comes from.
Another issue is that since some operation, the purple and blue x,y textboxes from the edge probe window are greyed out and I cannot edit their contents anymore. Not sure how I got into this.
And finally another question that is a bit unrelated, but is also to pick the results from this module. I wanted to read the detectes edges from a cscript, and tried:
int ret = getFloatArrayVariable("probed_edges_1", &pe1[0], 4);
Where pe1 is float[4], but the retrieved values are wrong. What am I missing? As I workaround I found I can use getFloat with _1:0 and _1:1. Do I have to use those?
I'm posting the .robo in case it might help. Thanks in advance.
 program.robo
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Page,
Thanks for the robofile. That helps us understand the confusion.
Yes, the variables are being overwritten which is correct. The confusion is in that the Edge Probe module will always use the same variable name for its results. Thus the variable PROBED_EDGES will ALWAYS be overwritten anytime a new Edge Probe module is added into the pipeline.
What you need to do is to use the Set_Variable module after the Edge_Probe module to rename the variables you want to keep to some other variable. That module will handle any type of variable and make a copy such that the next time Edge_Probe is used the variable is not overwritten.
A futher complication about that module is that one can use multiple probes in a single instance of the module. I.e. when you select an area to probe, you can specify that 3 or 5 probe lines are used to get a better sample of what you are probing. When this happens, you can't store all the information in one variable otherwise you'd lose track of which probe is which ... thus when more than one probe is used (i.e. 'Number of Probes' in the GUI is more than 1) the module will start creating PROBED_EDGES_1, PROBED_EDGES_2 and PROBED_EDGES_3 for 3 probes. When you just use one the variable remains PROBED_EDGES since you don't need more than one.
This naming convention was what was confusing your results.
If you'd like, attach the actual image that you are probing along with how many sub probes within each area you actually want to use and we can send you a quick example of how to rename things after each probe is used.
STeven.
|
|
|
|
page [6 posts] |
9 year
|
Hi STeven,
Thanks, but I'm already using the renaming successfully. What about the cscript array question? Any clue?
Btw, a couple more comments: when more than 1 probe is set, there is an arrow that I thought was showing in which direction the transitions are looked for. However, I want specifically black->white, but it seems to detect the other case. Am I getting it wrong? Additionally, it would be awesome if sampled edges could be kept in the order they are found, not ordered by intensity.
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Page,
The CScript array issue should be solved in the latest version 2.62.2 The array type was not getting set correctly which was producing the strange numbers.
The black/white labeling was corrected. It was swapped. You may need to select the correct radio button if you load an existing robofile.
The sampled edges do not appear to be sorted by intensity. They are recorded as they are encountered. If you see something that is different from this case, could you attach an example?
Thanks,
STeven.
|
|
|
|
page [6 posts] |
9 year
|
Great, thanks for the fixes!
I'm attaching a simple jpg sample with stripes and a .robo. Notice the detected points. For added fun, edit the edge detection function, and grab the cyan corner and drag it around, looking at the detected points :)
Perhaps it has to do with having more than 1 probe? Also notice there's another issue with multi-probes, in that the purple and blue corner textedit boxes are grayed out by default after loading the .robo file. Changing the number of probes enables them, but it would be nice to fix this as well.
Oh, and I almost forgot:
>> 'Note that detected edges are ordered with respect to the edge intensity at each point.'
This comes from the '2. Identify' section in http://www.roborealm.com/help/Edge_Probe.php.
Thanks!
program.robo
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Page,
Thanks for the points. The grayed out issue should be solved.
I assume you are talking about the instability when moving the cyan box around? You can get better stability if you set it to detect 4 edges since the probe crosses 4 and may decided between them based on random luck (doesn't take much to change which 2 are higher in intensity than the other). While they are not sorted based on intensity, the top 2 edges reported will be the highest responding edges along the probe... which may change randomly. So with 4 edges and a bit of isolation the detection will be more stable. Does that make sense?
STeven.
program.robo
|
|
|
|
page [6 posts] |
9 year
|
Hi again,
Yes, I understand the variability in the previous example, and the improvements you describe. However, to understand a bit better how it was working, I did some additional tests with a different image, which has 'clear' transitions (each stripe only has pixels of 1 shade of gray).
I still don't understand why in the sample the 2nd transition is detected instead of the 1st one. Does detected intensity change somehow based on the probe angle through the edge?
And just an additional detail. Is edge isolation unit pixels? The 3 instances found seem to be closer than the 1 pixel I specified.
Thanks a lot for your help and fixes so far. I'm being a bit 'picky' since I need this in an industrial environment :)
program.robo
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Page,
The edge is broken into as many units as the Precision parameter specifies. This defaults and maxes at 10 so each pixel transition is expanded into 10 parts. That's why you can have 3 edges within a single pixel transition. If precision isn't needed, you can change the precision to 1 which will just focus on each pixel individually. If you do that, then the isolation isn't needed anymore since any transition will always include a single pixel.
No worries on being picky! As much info as you can provide as to the context of the problem is ideal ... as you may be trying to ask something that I'm not quite getting without that additional context. Often its better to forget about sub pixel resolution and just increase the image resolution to counter any aliasing that pixels create. But that may not be possible in your situation.
STeven.
|
|
|
|
page [6 posts] |
9 year
|
STeven (or anyone),
I thought I understood the behavior of this tool, but now I still find some cases where the detection does not do what I expect. I binarize the input image, to avoid any intensity issues, but still the detected edge is not the first. What am I missing?
Notice the x position of the probe is decimal, which is a normal case when you use multi-probes.
program.robo
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Page,
We reviewed the issues and made a couple updates that we think might reduce confusion. The main difference is that when the precision is now set to 1 the line sampling will use full pixel values and not interpolate between them. This should avoid the angle issue of subsampling values. Setting the precision to 1 should now provide you with what you'd expect.
Can you download the latest and see if this works better for you?
STeven.
|
|
|
|
page [6 posts] |
9 year
|
Thanks, the detected edge now seems to be consistent. However, you reversed all the directions of the probes. Was that intended? I'm afraid this will break existing user's programs.
Moreover, in this last version there appears to be something wrong in the blob filter. I'm using the 'avoid left border' and all the blobs are filtered out, not just the one I intended. This was working before.
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Page,
The probe reversal was due to the previous issue of the white/black not being in the correct order. The order it is now in in the intended way as depicted by the arrow (and previously documented). This arrow in the multi-probe was also showing the wrong direction too.
Thanks for the blob module tip. There was a mistake in that particular filter which we just noticed. The entire module went through an upgrade to fix the weight threshold that was being ignored by filters like the Avoids. The weight should be set to 1.0 to eliminate blobs touching the border. The upgrade caused this filter to fail as it was relying on a setting that was incorrect and broke when it got fixed.
We just uploaded a version that has this fix.
STeven.
|
|
This Thread
