color-changing car dashboard lights with RGB LEDs

Using Arduino LEDs and Multiplexing
1

Alright guys, My car is in need of some new dashboard lighting, And I want to use my arduino UNO to do it. I've also got 10 RGB led's to work with, and I'll get any other materials i'll need (cause I'm somewhat an electrical noob)

Here is the features I'd want

-The arduino needs to remember my selected color/mode and light up my dashboard after I cut the power to it

-It'd be nice to have three buttons to serve as presets for favorite colors

-I'd need some sort of knob that cycles through the color spectrum as you rotate it.

-the brightness needs to be dimmable from no light to extremely bright (as much as the RGB can handle)

-A mode button would be cool that switches modes between...

  • mode 1 - steady color [use with the 3 preset buttons] )
  • mode 2 - fade back and fourth between two favorite colors that I pick
  • mode 3 - cycle relatively quickly through the entire color spectrum (rainbow)

My auto input is 12v, how would I use that to power the arduino?

I kind of just need A lot of guidance. Thanks guys! if it gets finished, I'll probably make a video presenting it, and if you help me a lot, i'll be sure to let all the viewers know who helped!

2

Arduino external power input can regulate 12V down to 5V, but you can get car accessory (cig lighter) USB power/chargers pretty cheap. You can also use a voltage divider to go from 12V to 5V but IIRC car 12V isn't super-stable so perhaps 12V down to 8V and that through a regulator would be best.

There are loads of cool switches/dials at many sites, some with lights of their own. You could go with capacitive touch sensors, zero moving parts and able to hide under dash padding or non-conductive panel but harder to get right than mechanical switches. You could maybe use IR-interrupt or IR-reflection for touchless switching.

3

-I'd need some sort of knob that cycles through the color spectrum as you rotate it.

Good luck with this part. There is no a linear relationship between R, G, and B values that you can calculate based on a desired position along the spectrum.

4

PaulS:

-I'd need some sort of knob that cycles through the color spectrum as you rotate it.

Good luck with this part. There is no a linear relationship between R, G, and B values that you can calculate based on a desired position along the spectrum.

Well even though there isn't a convenient mathematical relationship, it's possible to use a rotary encoder to achieve the desired functionality. The RGB combinations will just have to be predetermined either stored in an array or table, and then use conditional logic to tie the encoder's position to specific output colors (similar to the concept of indexed color, only refering to linear progression of colors instead of a 2D image). A more striaght-forward approach, the encoder be used to manually vary only one of the three color values at a time, the nice thing is 8-bit values will be enough for a large portion of human appreciable colors only byte-sized variables are needed to store the encoder position.

Edit: Typos

5

Or you can use a (mini/micro) joystick or touch-area with white at center and shades all around.

6

GoForSmoke:
Or you can use a (mini/micro) joystick or touch-area with white at center and shades all around.

That's an interesting idea. However, many joysticks (even the miniature ones) are designed to self center and even those that don't can't be counted on staying in position with all the movement to be expected in a car. Therefore, you'd either have to have one with a button action, or a separate button. That would allow control logic like press the button once to read the position of the joystick, then press it again to save it.

7

It depends entirely on how your code interprets stick input. Read the input as force/relative-movement instead of absolute position and center stick == stop where you are. That's how the keyboard nub mouse on my ancient Thinkpad works. I quit pushing it and the cursor stops, it doesn't go to screen center.

Using beam interrupt or capacitive sensors you wouldn't need a physical stick, just a small area to wiggle a finger in or over.

8

Assuming that you'll have "something" to change the brightness with, one more control, e.g. a rotary encoder is enough to change along a "spectrum".
Instead of the usual RGB color space use the HSV (Hue, Saturation, Value) model. Changing the Hue would change the color and Value the brightness. You'd have to clamp Saturation.

You can find a nice explanation and the code to change from RGB to USV here:

http://neuroelec.com/2011/10/better-hsb-to-rgb-coversion/

9

GoForSmoke:
It depends entirely on how your code interprets stick input. Read the input as force/relative-movement instead of absolute position and center stick == stop where you are. That's how the keyboard nub mouse on my ancient Thinkpad works. I quit pushing it and the cursor stops, it doesn't go to screen center.

True enough, but to address this in code the input device's behavior and conditions within the car have to be considered. There's enough vibration or changes in speed or direction during normal driving to cause a roughly inch tall "thumb" joystick to move, possibly enough to cause unwanted input while using a freeway ramp, hitting a bump, etc... So for that type of input device there either needs to be a "dead zone" larger than motion not directly caused by the user, or a way to enable the input only when it is wanted (as I previously described).

Of course, not all input devices have this problem. Tiny joysticks like the Thinkpad nubs, or tumb slide sticks wouldn't have the mass to generate enough inertia to move during normal driving. Similarly your other two suggestions below, or a touch pad, would be a good way to avoid this concern all together.

GoForSmoke:
Using beam interrupt or capacitive sensors you wouldn't need a physical stick, just a small area to wiggle a finger in or over.

Headroom:
Assuming that you'll have "something" to change the brightness with, one more control, e.g. a rotary encoder is enough to change along a "spectrum".
Instead of the usual RGB color space use the HSV (Hue, Saturation, Value) model. Changing the Hue would change the color and Value the brightness. You'd have to clamp Saturation.

If you had a two axes or two dimensional input device, hue and value could each be assigned to a different axis. A touch pad might be an effective way to implement this.

10

Here is a good thread about changing color on RGB LEDs.

http://arduino.cc/forum/index.php/topic,95019.0/topicseen.html

11

Far-seeker:

GoForSmoke:
It depends entirely on how your code interprets stick input. Read the input as force/relative-movement instead of absolute position and center stick == stop where you are. That's how the keyboard nub mouse on my ancient Thinkpad works. I quit pushing it and the cursor stops, it doesn't go to screen center.

True enough, but to address this in code the input device's behavior and conditions within the car have to be considered. There's enough vibration or changes in speed or direction during normal driving to cause a roughly inch tall "thumb" joystick to move, possibly enough to cause unwanted input while using a freeway ramp, hitting a bump, etc... So for that type of input device there either needs to be a "dead zone" larger than motion not directly caused by the user, or a way to enable the input only when it is wanted (as I previously described).

Of course, not all input devices have this problem. Tiny joysticks like the Thinkpad nubs, or tumb slide sticks wouldn't have the mass to generate enough inertia to move during normal driving. Similarly your other two suggestions below, or a touch pad, would be a good way to avoid this concern all together.

Once again, something easily taken care of in software. A stick only tells how far from center it is. The rest is completely interpretation, including dead zone. Best way to start is to not assume it must 'act' like other stick user-interfaces.

I'd rather go with something that has no physical stick to have no moving parts to break or wear. A point of light that if a finger is held a bit above or to the side would change values for RGB per second (or 10th of a second) that the finger is held there, using the color of the dash led as feedback. Or 3 lights, R G & B and holding a finger right over the light makes that color element brighter and holding a finger close but not over makes it dimmer, though that would be slower and maybe less or more intuitive depending on user concepts.

There's got to be at least 20 variations on position sensing to output, all of them with limits to engineer around.

I'm just throwing suggestions and hope the main one is to think freely about input and application, to not ape what has been done but see what you actually get and make a leap from there to what suits the user.

12

GoForSmoke:
Once again, something easily taken care of in software. A stick only tells how far from center it is. The rest is completely interpretation, including dead zone. Best way to start is to not assume it must 'act' like other stick user-interfaces.

I never implied that it would be difficult mitigate false inputs, just that extra steps are necessary to do so.

GoForSmoke:
I'd rather go with something that has no physical stick to have no moving parts to break or wear. A point of light that if a finger is held a bit above or to the side would change values for RGB per second (or 10th of a second) that the finger is held there, using the color of the dash led as feedback. Or 3 lights, R G & B and holding a finger right over the light makes that color element brighter and holding a finger close but not over makes it dimmer, though that would be slower and maybe less or more intuitive depending on user concepts.

A very creative concept, if properly tuned there would be very little chance of a false input or unintentional breakage. As you pointed out though, how well the user can interact with, or even like, this type of input it is going to be rather subjective.

As an aside, given a large enough time span every device will wear out. What is the functional life of an LED compared to a star? And yet even stars aren't eternal...

GoForSmoke:
There's got to be at least 20 variations on position sensing to output, all of them with limits to engineer around.

I'm just throwing suggestions and hope the main one is to think freely about input and application, to not ape what has been done but see what you actually get and make a leap from there to what suits the user.

I totally agree with you on these points.

My intention for examining the suggestions you and others made, isn't to critize any particular approach. Instead, I wanted to demonstrate the mental process of identifying and mitigating false inputs and other potential issues. Understanding that input device can be inadvertantly effected by external factors and that some thought and analysis beforehand can save a significant amount of time, effort, and sometimes expense later on. However, that is something the vast majority people either have to be taught or slowly learn on their own, and it doesn't become an intutive process without a lot of practice.

13

You could read an analog stick axis on an analog pin and count low reads, say < 300 as one direction and high reads, say > 723, as the other. That's plenty of free dead zone! Then < 100 or > 923 could be 2x as much or some such scheme to get some proportion out of it and have more than an 8-direction hat switch. Still, with time an 8-direction hat switch can work.

I've played with capacitive sensing enough to be 90% sure it could be done that way through the difference between 4 sensors given careful setup. A lot of things could raise or lower the bleed time of all the sensors to some different degree but with work a touch can be a dramatic difference it would be pretty hard to false. OTOH that would amount to a 4-direction hat, or as many directions as you could fit sensors in a ring. You'd have no moving parts and no 80,000 hour leds to wear out.

Maybe it'd be cool to put sensors in the steering wheel and where you hold the wheel would determine the dash light color?