Reading colours

#1

Hi,
I’m trying to write a little program where Codey Rocky rids until it encounters a Duplo block (which we had lying around). It stops with the “obstacle detected” function.
So unfortunately I keep getting different RGB values for the same colour block.
e.g. green block:
16, 71, 16
16,112,30
6,64,15
0,4,0
4,23,3

Strangely, when I enter the RGB values to control the Codey LED, I do get a (more or less) correct colour.

Is there a way to determine if a block is red, green, yellow or blue? (I’m not even considering pink, brown, black, grey, …)

#2

Hi

I’m still new to this, but

I noticed in the mblock app on desktop (Windows) under the sensor tab, there is a tag which you can use in the IF command, you can choose different colors, Try it

Regards

#4

The point is that the color sensor is designed for reflective light. That means it does a good job in telling the color of the ground (and yes, it is calibrated for that). So unless it is really close to the Duplo block at a nice angle, it is unlikely to have a good performance. Cameras are good at telling colors in a distance, or some hacks (I did not try) may help - like using a lens to focus the light to the sensor like the light guns in video games.

#5

Thank you for your answer.
A few questions…

  1. If I turn on the LED on Rocky, I’m getting reflective light. No?
  2. If I use the obstacle sensor, am I right that the distance from the blocks it will stop will depend on the colour of the blocks? (farther away when blocks are bright, closer when blocks are dark)

Thanks,
Jurgen

#6

@JurgenG

After this test, you seem to be right:

I find it sad that the robot stops at a different distance depending on the color of the object.
Is this the same technique for mBot?

2

Otherwise, the color reading is correct when the sensor points forward and the object is 1.5 or 1 cm apart

err

#7

Well… it actually also changes depending on the ambient light and on the speed you advance with Rocky (so if you advance at 5% versus 50% is a different distance)

It’s a fun challenge to find a way around these issues… (I think this is acceptable given the scope and price of this robot… can’t expect calibrated color sensoring with environmental correction, advanced motors and distance meters) It’s not like this is a bomb squad robot… it’s Codey Rocky, a toy to learn my kids how to program :slight_smile:

I was hoping someone already had some experience (maybe with mbot) and knew a trick (f.e. if R-value > 3*(sum G-value + B-value) or G < 10% if R and B < 10% R … then we have RED) I’m trying to create some algorithms of this kind. So relative colorometry :smiley:

#8

Hi,

I understand that the Rocky Codey is a learning robot. However, it is used by children and should be easier. The formula you are looking for is too complex to be found by children.

I think I saw in the color sensor of the Neuron block, a color tolerance option.
It would be nice to add this option in the sensor options in order to be consistent with the Neuron blocks.

#9

Under Sensor you have <“red” color value detected>
image

Doesn’t it work?!

#10

It works at 1.5 or 1 cm distance. It depends on the light.
A tolerance will be welcome but I will still do more tests.

#11

Wow… didn’t see that one. I think I dismissed it because it only has a limited set of colours and Lego has more. But I’ll for sure check it when I connect Rocky again.

#12

Okay… so using the named colours works reasonably… you need to get to the right distance indeed. And the distance from the block differs depending on what colour it is, what colour the underground is (black cloth vs white cloth), what ambient light is…
Currently I’m trying using a recursive function and 4 colours - and if none is found, move a tiny bit closer and try again… but for some reason Codey gets in an infinite loop…

Any advice?

block-colours..png892x1006 84.6 KB

#13

Why do you call the “checkcolor” from it self ?
Try call it from the main program and manage the ending point for the sequence from there.

#14

The endless loop must come from the checkColour statement in the last ESLE block.

#15

Well… if you can’t find a colour, you’re still too far away and you need to advance a little bit and retry checking the colour. I made this recursive loop because it’s the only way I found for the robot to find the right distance for every colour and in every environment.

Recursion is a common practice in programming, no?

#16

Recursion is a common practice in programming, no?

Yes but in your example a normal loop is probably the best solution. The recursive loop requires a stop condition to exit the loop and stop processing. Usually use for algorithms like programs that create a kind of tree. I do not think Scratch or mBlock allow the stop of a procedure so you probably have to forget the recursive loops. This is possible with languages like C, Pascal, etc. Maybe there is another user who would be doing in Scratch?

#17