[Bug] Light turns green for Color(0, 0, 5--10) on TechnicHub

[laurensvalk]

Describe the bug
The light turns very bright green on TechnicHub for some low value parameters. On PrimeHub, it turns off correctly.

This seems to indicate a broken conversion from hsv to rgb.

To reproduce

from pybricks.hubs import TechnicHub
from pybricks.parameters import Color
from pybricks.tools import wait

hub = TechnicHub()

# Very faint white light: correct
hub.light.on(Color(h=0, s=0, v=4))
wait(2000)

# Bright green: bad
hub.light.on(Color(h=0, s=0, v=8))  # The range 5--10 is broken.
wait(2000)

# Faint white light: correct
hub.light.on(Color(h=0, s=0, v=12))
wait(2000)

Expected behavior
Light should be faint, somewhere in between 4 and 12, which do work correctly.

[laurensvalk]

It also appears that pbdrv_led_pwm_set_hsv is being called in a loop even if there are no patterns. This seems unnecessary.

[BertLindeman]

Does this depend on the firmware level?
Using the standard ('technichub', '3.0.0a13', 'v3.0.0a13 on 2021-01-08') , I see a very faint cyan color.

The definition of BLACK has v=10, should that be v=0?

Running this

    hub.light.on(Color(h=0, s=0, v=0))
    wait(1000)
    hub.light.on(Color.BLACK)
    wait(1000)

shows faint / black

[laurensvalk]

Yes, v=0 turns it off but v= 7 does not, see example above. I've only tried the latest version.

The definition of BLACK has v=10, should that be v=0?

Although this is not the issue here (I renamed the issue), no -- black is still a bit brighter than nothing at all (None). This is true especially for measured color. This is how you can tell black apart from detecting nothing at all. But it even applies to emitting colors. A black piece of paper does not emit/reflect much light, but still more than a complete void or black hole. 🤓

[BertLindeman]

A black piece of paper does not emit/reflect much light, but still more than a complete void or black hole. 🤓

Understood, thanks

[laurensvalk]

Using the standard ('technichub', '3.0.0a13', 'v3.0.0a13 on 2021-01-08') , I see a very faint cyan color.

I tried the example on this firmware, and the issue is present here too. Very bright green light in the (edited) example.

It's probably been broken for a while. This is why we're starting to create tests that will ultimately test each and every available function.

[BertLindeman]

Hard to create tests that need to look at the color of a hub light . . .
If in my competence I want to help creating tests, But where to start without throwing in a mess?

The v values that light up green on the a13 base firmware I determined with:

from pybricks import version
print(version)

from pybricks.hubs import TechnicHub
from pybricks.parameters import Color
from pybricks.tools import wait

hub = TechnicHub()
hub.light.off()

v_error = [6, 7, 8, 11]
for __i in v_error:
    print(__i, "looks wrong")
    hub.light.on(Color(h=0, s=0, v=__i))
    wait(2000)
    
for __i in range(50):
    if not __i in v_error:
        print(__i, "should be OK")
        hub.light.on(Color(h=0, s=0, v=__i))
        wait(500)

Strange that 10 is doing oke here..

[laurensvalk]

Hard to create tests that need to look at the color of a hub light . . .

Is it?

But it would still be fine if it wasn't measured. It doesn't have to be fully automated. It could print out what it is supposed to do, and the human observer may or may notice it. It's something we might do manually for every release, just not every commit.

If in my competence I want to help creating tests, But where to start without throwing in a mess?

The format isn't really defined yet. The idea is to fill up this folder with tests. There's only one there, at the moment.

[BertLindeman]

Hard to create tests that need to look at the color of a hub light . . .

Is it?

Hahaha hi, hi Great Laurens. Test the test subject with the test object. (or is it the other way around?)

But it would still be fine if it wasn't measured. It doesn't have to be fully automated. It could print out what it is supposed to do, and the human observer may or may notice it. It's something we might do manually for every release, just not every commit.

Any hint on where I might look at first?

sorry for hijacking this issue

[laurensvalk]

Any hint on where I might look at first?

Thanks for the help! It would be really helpful to have one script per sensor, which tests all its methods, with all possible arguments. Like this, but for sensors.

Starting with the SPIKE sensors would be a good start. Perhaps mounted side by side. With one motor (itself not the subject in these tests) waving something (colored) in front of the sensors to verify that they give the expected values. Simpler is better, so that the test itself does not fail mechanically at least.

Let's continue this conversation in the coverage repo.

[dlech]

The light turns very bright green on TechnicHub for some low value parameters. On PrimeHub, it turns off correctly.

This seems to indicate a broken conversion from hsv to rgb.

All of the hubs use the same conversion and at least one hub works so this seems unlikely . Since the issue is on TechnicHub, I would suspect pybricks/pybricks-micropython@7650872

[laurensvalk]

It also appears that pbdrv_led_pwm_set_hsv is being called in a loop even if there are no patterns. This seems unnecessary.

Is this related, or if not, is it intentional?

[dlech]

It's not related to the issue. It could probably be made more efficient. I can't remember what I was thinking at the time. 😉

[dlech]

This issue seems to be back again.

hub.light.on(Color.BLACK)

is bright green

MicroPython v3.0.0b2-23-gc170710d on 2021-02-27; LEGO Technic Hub with STM32L431RC

[dlech]

slightly different than before

     Color(h=0, s=0, v=8)  # OK
     Color(h=0, s=0, v=9)  # bad
     Color(h=0, s=0, v=10)  # bad
     Color(h=0, s=0, v=11)  # mostly OK but flickers sometimes
     Color(h=0, s=0, v=12)  # bad
     Color(h=0, s=0, v=13)  # OK