Pybricks
How to distinguish Black and No Color? #1990
Replies: 7 comments 5 replies
-
|
Hi, In pybricks doc of color look under Unsaturated colors. Bert |
Beta Was this translation helpful? Give feedback.
-
|
Black isn't a really a color but rather the total absence of it. This is the case both for scanning colors and applying the color black to a light. You could in principle distinguish between a tiny bit of reflection (call it Black, or - insert LEGO batman voice - very very dark gray) and none at all (and call this None). This can work but the results and thresholds are very application specific. For most applications, it is a bit annoying to have both None and Black enabled by default, since you'd occasionally get the wrong value when line following for example. This is why we've opted to enable one by default. But it can work very well if you tell your sensor what black looks like in your application. You can use the technique described here: https://youtu.be/kwnSbnlhOkA. Add your version of black to the overal list of detectable colors as done here. You can add the color None to that list without redefining it. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for that explanation, but frankly the Lego Spike built-in colors do
a bang-up job of distinguishing between black and no object, and I wish
pybricks could do the same. The one and only reason I installed pybricks is
because my Lego Spike Essentials hub and Lego City hub cannot play a stored
program when not connected via bluetooth. My Lego Spike Prime hub actually
can do this already, and so perhaps I will just keep the Lego Spike OS on
it since pybricks color sensing is not as robust. I just can't afford to
purchase additional $320 hubs for the rest of my project, and as backups.
Another problem is the pybricks default colors are having no success
recognizing anything WHITE. Lego Spike programs had no problem with this at
all. But pybricks consistently recognizes anything white as red in my
tests. This is really very frustrating. I'd simply like pybricks to possess
the Lego library functionality with its 8 built-in color values (one of
which is black, another of which is no object), but with the ability to run
those programs when offline. But the Lego Color Sensor spec I linked in the
OP defines these colors by RGB, not HSV. And it is mute on how it
distinguishes no object from the other "color" values. AI code seems to
want to measure ambient light, but this turns off the color sensor's light.
When running Lego OS code, the light stays on when distinguishing between
black and no object.
Also, a practical real-world engineering note: when scanning black items,
black is not truly the absence of color, because black items do reflect a
little bit of light. My tests do not produce HSV vaues of 0,0,0. There are
YouTube videos about the blackest fabric or the blackest paint, where
people have gone as far as possible in their quest to produce an object
that is truly black with no reflected light. But I am trying to identify
normal black objects that do have a bit of reflected light.
I could redefine all the default colors in the program if I only knew what
values the Lego color sensor interpreted as black versus no object, and
converted the Lego RGB values from the spec into the HSV values used by
pybricks.
…On Thu, Dec 26, 2024, 1:21 AM Laurens Valk ***@***.***> wrote:
Black isn't a really a color but rather the total absence of it. This is
the case both for scanning colors and applying the color black to a light.
You could in principle distinguish between a tiny bit of reflection (call
it Black, or - insert LEGO batman voice - very very dark gray) and none at
all (and call this None).
This *can* work but the results and thresholds are very application
specific. For most applications, it is a bit annoying to have both None and
Black enabled by default, since you'd occasionally get the wrong value when
line following for example. This is why we've opted to enable one by
default.
But it can work very well if you tell your sensor what black looks like in
your application. You can use the technique described here:
https://youtu.be/kwnSbnlhOkA. Add your version of black to the overal
list of detectable colors as done here. You can add the color None to that
list without redefining it.
—
Reply to this email directly, view it on GitHub
<#1990 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWL53SQ2R2ZAPDYQNLGWZEL2HO4BNAVCNFSM6AAAAABUGSVKYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRWG42DANI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's quite possible that the 10 standard values happen to work perfectly in your application. In most applications they don't, which is why we allow you to configure them. (Almost all FLL teams would rather measure green than randomly vary between read 3 shades of green, for example.) In the end it is the same sensor. Rounding to fewer colors gives better results by definition. This is a big benefit for most applications, but I suppose adding a few extra blocks can be an inconvenience for some users. Maybe we can add an example to our guide when we work on the tutorials for the color sensor. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. That's a good start for me to do some testing with code. Is there
any way to access these unsaturated values in coding blocks? The dropdown
list only lists the saturated colors.
…On Thu, Dec 26, 2024, 1:19 AM Bert ***@***.***> wrote:
Hi,
In pybricks doc of color
<https://code.pybricks.com/static/docs/v2.19.0/parameters/color.html>
look under Unsaturated colors.
NONE and BLACK are documented there.
Bert
—
Reply to this email directly, view it on GitHub
<#1990 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWL53SXGKAFFCVZG2ANWYVT2HO32BAVCNFSM6AAAAABUGSVKYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRWG4ZTSMI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I was simply referring the 8 standard color definitions that Lego puts in
their color sensor spec. One of those is black. Another is no object.
Another is white. Thx.
…On Thu, Dec 26, 2024, 4:20 AM Laurens Valk ***@***.***> wrote:
It's quite possible that the 10 standard values happen to work perfectly
in your application.
In most applications they don't, which is why we allow you to configure
them. (Almost all FLL teams would rather measure green than randomly vary
between read 3 shades of green, for example.)
In the end it is the same sensor. Rounding to fewer colors gives better
results by definition.
This is a big benefit for most applications, but I suppose adding a few
extra blocks can be an inconvenience for some users. Maybe we can add an
example to our guide when we work on the tutorials for the color sensor.
—
Reply to this email directly, view it on GitHub
<#1990 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWL53SX5DPCKDVEAFK3NW5T2HPQ7HAVCNFSM6AAAAABUGSVKYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRWHA2DGNQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, I meant to explain above 🙂 Perhaps you can give the method of the video a try? In the end it is maybe 3 extra blocks at the top of your code, and you'll have a great understanding of color detection and much better performance too. |
Beta Was this translation helpful? Give feedback.
-
|
I've just tried this on my line follower. Works great. The values for your application may very slightly. (Which is meant as a positive; now you can make it work no matter the print quality of your mat, or height of the sensor in your design, etc.)
Now it can accurately detect the black line, the white mat, and whether I've lifted it up, despite this being really close to black as you can see. It will also never give false positives like red or yellow. Anything will be rounded to the three chosen colors. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the tip. So the lifted up constant in your example is equivalent
to no object, correct?
…On Thu, Dec 26, 2024, 8:25 AM Laurens Valk ***@***.***> wrote:
I've just tried this on my line follower. Works great. The values for your
application may very slightly. (Which is meant as a positive; now you can
make it work no matter the print quality of your mat, or height of the
sensor in your design, etc.)
image.png (view on web)
<https://github.com/user-attachments/assets/1c240174-9586-4157-97cf-c800290865d9>
Now it can accurately detect the black line, the white mat, and whether
I've lifted it up, despite this being really close to black as you can see.
It will also never give false positives like red or yellow. Anything will
be rounded to the three chosen colors.
—
Reply to this email directly, view it on GitHub
<#1990 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWL53SU4S3JDXD5BOUY4R4T2HQNWRAVCNFSM6AAAAABUGSVKYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRWHE3DOMQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Right. The names are arbitrary and can be chosen for code legibility. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the false positives are easy if we eliminate saturated colors. Since
my application is detecting a marble's presence and then discerning its
colors from among some basic saturated primary colors plus black and white
and no object, I will have to do some playing around with default saturated
color values to get the code to recognize a white marble as white instead
of red. At least now I am headed in the right direction. And I can closely
control the sensor's distance to the marble to ensure consistency. Thanks
for the example.
…On Thu, Dec 26, 2024, 8:25 AM Laurens Valk ***@***.***> wrote:
I've just tried this on my line follower. Works great. The values for your
application may very slightly. (Which is meant as a positive; now you can
make it work no matter the print quality of your mat, or height of the
sensor in your design, etc.)
image.png (view on web)
<https://github.com/user-attachments/assets/1c240174-9586-4157-97cf-c800290865d9>
Now it can accurately detect the black line, the white mat, and whether
I've lifted it up, despite this being really close to black as you can see.
It will also never give false positives like red or yellow. Anything will
be rounded to the three chosen colors.
—
Reply to this email directly, view it on GitHub
<#1990 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWL53SU4S3JDXD5BOUY4R4T2HQNWRAVCNFSM6AAAAABUGSVKYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRWHE3DOMQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
You can expand the example by adding another color called You should be able to use a fixed distance, whichever works for your design, and then measure the HSV values for your setup. Then in principle it need not be a two-step detection for presence and then color, but all in one go. The video explains the reasoning and also gives an example of how to measure the HSV in your setup. |
Beta Was this translation helpful? Give feedback.
-
Coming from Lego Spike, I am having problems because the default colors for the Powered Up color sensor are not a 1 to 1 match between Spike Prime programming and pybricks programming.
SETTING UP THE PROBLEM BACKGROUND:
In the Lego Powered Up Color Sensor spec, it says that when the color sensor is in the color sensing mode (vs. ambient light or reflected light sensing), the color sensor can output 2 separate states of "no object" and "black". The spec states that the black color is H=0, S=0, V=0, but does not give an HSV value for "no object", so it is not clear how "no object" is detected.
(ref Lego color sensor spec at https://assets.education.lego.com/v3/assets/blt293eea581807678a/blt62a78c227edef070/5f8801b9a302dc0d859a732b/techspecs_techniccolorsensor.pdf?locale=en-us)
From another Lego Education link, it says the color -1 to 10, and the value is -1 for "no object" and "0" for black.
-1 = No object
0 = Black (LEGO:26; R:0, G:0, B:0)
1 = Magenta (LEGO:124; R:144, G:31, B:118)
3 = Blue (LEGO:23; R:30, G:90, B:168)
4 = Turquoise (LEGO:322; R:104, G:195, B226)
5 = Green (LEGO:28; R:0, G:133, B:43)
7 = Yellow (LEGO:24; R:250, G:200, B:10)
9 = Red (LEGO:21; R:180, G:0, B:0)
10 = White (LEGO:01; R:244, G:244, B:244)
(ref https://community.legoeducation.com/blogs/31/220)
HERE'S THE PROBLEM:
But in the Pybricks blocks, there is no black color. There is, however a "none" color value. However, it appears that the none value is H=0, S=0, V=0, because if I assign a new color value of "Black" as H=0, S=0, V=0, and then in the code test for the "none" color value, printing the result when the "none" color value is triggered, it prints Color.Black, so that makes me think that Pybricks detects "no color" by a black value.
MY 2 QUESTIONS:
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions