LabVIEW for LEGO MINDSTORMS and LabVIEW for Education

cancel
Showing results for 
Search instead for 
Did you mean: 

Detecting colors and signal duration. Is it possible?

Solved!
Go to solution

just ask and eventually send some vi's

greetings from the Netherlands
0 Kudos
Message 11 of 97
(4,801 Views)
0 Kudos
Message 12 of 97
(4,802 Views)

Hi

My first advice is to keep wires as straight as possible and code as readable as possible.

I did no see major errors but as a "lazy brain programmer" I really cannot handle all the wire edges and at the same time see what happens. Just an advice, the compiler does not care but your mind does.

 

You can replace my color enum with the original LEGO enum and I would make sure that all color enums have the same type definition. If you see somewhere a red spot (as after the black enum at the upper right), this is a sign that the compiler adds a type conversion in the wire. Remove all these conversions by only using the original Lego color enum and not mine anymore.

 

Of course is it possible to show what is inside as color and timing, but you probably only want it at detection of a brick not each loop of the while so add it inside the detection case and use an array of detected clusters for that.

I will edit an example for that after dinnertime.

 

 

 

greetings from the Netherlands
0 Kudos
Message 13 of 97
(4,800 Views)

Thank you for taking the time... Really appreciate it! 

 

 

I leave you a notepad-doc with som further explenation of the problem...

 

 

0 Kudos
Message 14 of 97
(4,800 Views)

What you measure is milliseconds with noise from how many times the color measuring vi is running.

This is totally depending on speed of the color measuring vi. You can compare the speed of the system to the speed of the belt to see if the timing is realistic.

In your RTF I see that the first constant still generates a red dot at the shift register input, so hat one in the picture is probably still my version.

 

The compare itself is very fast so something else accounts for the differences.

I am downloadling LV12 now with LEGO (and will seek the old disk above) and can give you better examples afterwards.  (Windows claims 2..9 hours for the download, but most of the time it is faster.

 

A flash of insight: you should detect black again and then use the previous color to act on the block.

 

Anyway a simple version of a cluster each time a new block is detected.

greetings from the Netherlands
Message 15 of 97
(4,797 Views)

Hi

I've added a document trying to explain what happens with the comparison-block (less, lessandequal), and how it changes the measured length for some reason.

This is what holds us back from making any real progress at this time.

 

Thanks for the help! 🙂 

0 Kudos
Message 16 of 97
(4,785 Views)

I guess, that you enter this case with the wrong assumption.

The timing should start on a change in color from black to any color and stop on the switch from that color to black again. What I see on your screen is that the previous color is black in one and the previous color is green in the other occasion.

I made a slight change in my last .vi, did you use that vi or your edited your own version to get this result.

 

Maybe the transition is not as immediate as expected, instead of switching to black, an intermediate color can be detected at a boundary, That could cause a problem, Or a transient happens sometimes.

 

Send me your vi in which you found these results and I try to modify the logic to be more stable.

greetings from the Netherlands
0 Kudos
Message 17 of 97
(4,783 Views)

The screenshots i sent you are from the same code as you sent us yesterday, except we removed some of the blocks with the red square-thingy, just to try (couldnt really replace them with lego enums because we dont really know what replaces them... 

 

When using your code, program works fine; it displayes corrrect previous and current color... The reason it shows black as previous, is because when system notices a different color, the previos one is naturally the black "default" color...

However, we still get the same measurement problem when applying the comparator... 

 

Thanks

0 Kudos
Message 18 of 97
(4,782 Views)

I will  look into it later today.

Try to clean the code even more.

greetings from the Netherlands
Message 19 of 97
(4,776 Views)

Hi Albert, the legend!

 

We've added a few ideas to the VI and left a document explaining how we'd like the ordering system to work.

 

The less or equal comparator is still altering the length measurement... We cant seem to find any solution to this and it kind off holds us back 

 

Thanks for all the help 🙂

Download All
0 Kudos
Message 20 of 97
(4,761 Views)