I have the Mindstorms set 51515 - Robot Inventor. I want to display the progress of a robot's work using the LEDs.
How can I change the colour of the RGB LED that the hub uses to indicate the Bluetooth/charging status?
Bricks is a question and answer site for LEGO® and building block enthusiasts. It only takes a minute to sign up.Sign up to join this community
Short answer: You can't.
Longer answer: It should be possible to do with custom firmware, but it's (a) not worth it, (b) difficult from a technical standpoint, and (c) a bad idea.
Disclaimer: besides being an AFOL, I have some experience in the microelectronics industry.
When you load a program into a spike/mindstorms/ev3/etc hub, the hub is not running just your program. It's running a lot of stuff under the hood.
In fact, your program (i.e. "the user program") does not communicate with the hardware (motors/sensors) directly. It communicates to the operating system of the hub. That's commonly called "firmware" since it lays somewhere in between "hardware" and "software". It's assumed to be immutable and reliable as hardware, but with some effort can be changed/updated as software.
The firmware handles the tricky bits of computing that you don't want to care about - such as the Pulse-Width Modulation for the LED colours, the Real-Time Clock to run commands for specific amounts of time, or the USB and BLE network stacks to communicate with desktop/laptop computers.
Note that your user programs do not have full control over the hardware, or over all the features of the OS. For example: any device with a USB stack and a button can be (in theory) converted into a USB mouse (technically a "USB HID")
Because it takes a lot of time; and given the amount of person-hours that it would take to develop custom firmware (such a
pybricks, the only non-lego™ firmware I'm aware of), you'd be way better off getting an Arduino and/or a Raspberry Pi. That way you can learn to take full(er) control of your hardware.
Or, if you just need extra lights, get set 88005-1.
I'm assuming you are reading this from the point of view of a person just learning computing/robotics. If you already have experience in computing, tweaking
pybricks or even Zephyr wouldn't be out of the question.
I've skimmed the source code for the
pybricks firmware. As far as I can see, the code paths for the user-programmable RGB LED and the battery LED are completely different. The former is treated as a peripheral, but the later is treated as process events passed to the underlying kontiki OS.
So in order to make the battery LED user-programmable, first you would need to disable it at a lower level. Which means losing the default behaviour for that LED.
When developing low-level firmware, the ways that the computer (the hub) can display information are very limited. I'm talking no bluetooth, no USB, no UART: a status LED is in most cases the only tool available. Losing that tool is plain dangerous.
From a support point of view, letting a user fake the behaviour of that tool means that you couldn't trust problem reports. If a LED is stuck on a colour, how can you be sure that it's a problem with the OS, or maybe is it a problem with the user's program?
As far as I know, this is not possible with the default firmware and APIs currently. The primary hub LED is exposed as
hub.led, but I don't believe that the other LED is accessible from user code.
It may be possible to access it in some undocumented way or via custom firmware, but I'm not familiar with any way to do this.