Led fur coat

Status
Not open for further replies.

Kannan

New member
I was reading your posts on the huge display builds that you have done with LED strips and wondered if my project might be of interest.

I am trying to create an LED fur coat similar to one I saw at Burning Man this year:

http://www.youtube.com/watch?v=t_ojswJ_h00

You can see the LED coat in this video without much effort!

I would like to make a sound-to-light version of this, possibly smaller to start with (a jacket to make as a prototype, also because of power requirements).

My obvious questions are this: What resolution do you think this jacket uses (30, 60 or 144 LEDs) with the obvious next question of what power source do you think he is using - as from what I can see any such project would require huge amounts of power! I was thinking of 60 5050s using multiple lion batteries in parallel.

Now I have quite a bit of programming experience and some electronics too (some years back also with RC), although I have never attempted a project like this before. I would appreciate any comments or pointers and was wondering if your driver might be a way of achieving this?

Many thanks!

Kannan
 
Wow, that coat looks amazing.

For reference, here's another project using 250 LEDs, which appears to be a pattern of dots.

http://anthrolume.wordpress.com/2013/09/12/anthrolume-shines-again-at-burning-man-2013/

Maybe the fur is spreading or diffusing the light? Or something else is? It's hard to imagine how many LEDs must be on that coat for such incredible coverage, apparently no individual bright points, at least none I could see in the video.
 
Perhaps using fiber optic cable strands to be more 'fur' like, and bring light from the individual LED pixels.

I do wonder how heavy the batteries are and how long the run is before you need to switch batteries. Of course, speaking as somebody who has carried his 20 pound steampunk camera for all day events, I know how weight can add up over time.
 
vest2.jpg

VEST1.jpg

I have just finished constructing a fur vest. It works...WS2812 strips cover the vest, and white fur diffuses the light.

I made an algorithm that generates plasma onto 470 leds.

It is not overly efficient though, and I only get 3 frames a second.

I wrote the code in Arduino, and will now try a native platform for this controller to try get some faster results.

The issues I have is that SIN() is really slow to calculate, and is used in plasma algorithms.

Plus power is a big issue. I am running the LED's at max 50 brightness. (~20%) Biright enough for night time use...it uses about 2 amps average.

Happy to share the source code. (feedback welcome)
 
Last edited:
I am trying to create an LED fur coat similar to one I saw at Burning Man this year:

http://www.youtube.com/watch?v=t_ojswJ_h00


I spoke to someone recently who saw this also, and was under the impression that the get the thing powered the coat needed to be plugged into mains power. It makes most sense, and I expect to view this in daylight it would need to be running a full brightness, and to cover that area it would be pulling (best guess) about 30 amps.

I would also guess it was using a T1000S controller (or similar), with the plasma animation precompiled. You can see it restarting the sequence a few times.
 
If you are heavily using floating point math, particularly sin, cos, etc. you might want to consider off loading the calculations to a chip that has hardware floating point. Two solutions come to mind:
  • You could use this chip that Sparkfun sells, and hook it up via SPI (or the slower i2c): https://www.sparkfun.com/products/8450;
  • You could move the processing off to a Rasberry Pi, and use the Teensy to run the lights (R-pi runs at 700 Mhz, and has hardware fp, Teensy 3.1 runs at 96 Mhz without fp, note the R-pi cannot drive ws2812 type lights).

In both cases, you want to minimize the amount of data that is transferred over the interface, moving more of the program over to the other device.
 
Last edited:
I'm not versed in OctoWS2811-fu, but since (as stated at the bidoulle link) the pattern repeats every 12 pi seconds, it seems that computing 12 pi seconds worth of frames out on your computer of choice, adjusting for your particular strip layout, and saving those as a movie or as discrete files to an SD card might be the quickest way to get a decent frame rate.

Not really that many frames, even: ~47.1 seconds * 24 fps = 1131 frames

I can't help you with the OctoWS2811 or fastLED libraries for the display portion, but they are established tech, so that's the path I'd take if Burning Man was in one week. Time permitting, I'd put a rotary switch on it to choose other animations, a pot for brightness, and call it done.

That said, you might find the integer math features of the (Teensy friendly) fastLED library (http://fastled.io) useful to speed up calculations in the original code.

John
 
If you are heavily using floating point math, particularly sin, cos, etc. you might want to consider off loading the calculations to a chip that has hardware floating point. Two solutions come to mind:
  • You could use this chip that Sparkfun sells, and hook it up via SPI (or the slower i2c): https://www.sparkfun.com/products/8450;
  • You could move the processing off to a Rasberry Pi, and use the Teensy to run the lights (R-pi runs at 700 Mhz, and has hardware fp, Teensy 3.1 runs at 96 Mhz without fp, note the R-pi cannot drive ws2812 type lights).

In both cases, you want to minimize the amount of data that is transferred over the interface, moving more of the program over to the other device.


Thanks for the awesome info!


I looked into R.Pi + Teensy/Arduino, but don't want to carry that much hardware around...
That said I have code to push frames of data from Linux to Arduino if anyone wants it.


What I have done for now is pre-render the LED data to a file on an SD card, and using Arduino Mega to push raw data from SD card to the lights.

Rendering 100,000 frames took 8 hours on the atmega. Frame rate still too low, 8fps.
https://vimeo.com/87725792


Ill check out offloading the FP calculations to the uM-FPU. Sexy.
 
I'm not versed in OctoWS2811-fu, but since (as stated at the bidoulle link) the pattern repeats every 12 pi seconds, it seems that computing 12 pi seconds worth of frames out on your computer of choice, adjusting for your particular strip layout, and saving those as a movie or as discrete files to an SD card might be the quickest way to get a decent frame rate.

Not really that many frames, even: ~47.1 seconds * 24 fps = 1131 frames

I can't help you with the OctoWS2811 or fastLED libraries for the display portion, but they are established tech, so that's the path I'd take if Burning Man was in one week. Time permitting, I'd put a rotary switch on it to choose other animations, a pot for brightness, and call it done.

That said, you might find the integer math features of the (Teensy friendly) fastLED library (http://fastled.io) useful to speed up calculations in the original code.

John

Thanks for taking the time to reply John!

Ill check out fastLED...this could solve my slow frame rate issues...and let me generate plasma in real time.
 
Last edited:
FinOminal: What a lovely effect! Prerendering was a great idea.

A Teensy 3.1 is bound to be much faster than your ATmega, especially if you use optimized trig libraries. I bet it will work easily. Math co-processor or Raspberry Pi probably won't be nearly as easy to get running from what you've currently got.

If the Teensy 3.1 is still not fast enough, you might want to test how sensitive the algorithm is to accuracy. My guess is that you can get away with a very fast and loose approximation to sin() without the quality suffering. If the Teensy 3.1 native trig isn't fast enough, a table lookup with or without interpolation will get you there.

If you need the memory for other things, you might search for "graphics gems" related to optimizing sin(). Many years ago I did graphics programming and I was always surprised by how few instructions were needed to get a "good enough" approximation.
 
If you've got enough memory you could also store a little lookup table of pre-calculated sine values.
 
would you be interested im sharing the read from sd code ?

Totally.

A little info on how it works:



There are 470 LED lights. Each light has 24 bits of data.

All I do with the *.led files is put the byte data in sequence: rgbrgbrgbrgbrgbrgbrgbrgb

Total file length = (LED Count * 3 * Number Of Frames)

The first THREE bytes are for LED 0, the second three for led 1, up to the number of leds on the vest. 1410 bytes for one frame.

Byte number 1411 is the first byte for the second frame (RED BYTE for LED zero) .



Currently I have 12 set files I play from. It's hard coded, but it works for the moment.

Next job: make file selection dynamic, so I can just drop files to the SD card.



My code doesn't follow standard aduino notation, sorry!

View attachment LedVestPlayFromSDFileSelect.ino
 
The magic of making it a canvas rather than just blinky blinky lights...is to use an INDEX that holds the X/Y co-ordiantes of all the leds.

The unique co-ordinates can be used to get relative pixels from videos, or inject them into the plasma algorithms.

Teensy 3.0 got me over 30 frames a second! It looks awesome now. Very Smoothe!

-------------------------


LED[] leds = new LED[LED_COUNT];


class LED
{
int x,y;

LED(int _x, int _y)
{
x=_x;
y=_y;
}
}



void PopulateLedArray()
{
leds[0] = new LED(0,1);
leds[1] = new LED(0,2);
leds[2] = new LED(0,3);
leds[3] = new LED(0,4);
leds[4] = new LED(0,5);
leds[5] = new LED(0,6);
leds[6] = new LED(0,7);
leds[7] = new LED(0,8);
leds[8] = new LED(0,9);
leds[9] = new LED(0,10);
leds[10] = new LED(1,13);
leds[11] = new LED(1,12);
leds[12] = new LED(1,11);

.... and so on for all 470 lights.
 
Last edited:
would you be interested im sharing the read from sd code ?

Totally.

A little info on how it works:



There are 470 LED lights. Each light has 24 bits of data.

All I do with the *.led files is put the byte data in sequence: rgbrgbrgbrgbrgbrgbrgbrgb

Total file length = (LED Count * 3 * Number Of Frames)

The first THREE bytes are for LED 0, the second three for led 1, up to the number of leds on the vest. 1410 bytes for one frame.

Byte number 1411 is the first byte for the second frame (RED BYTE for LED zero) .



Currently I have 12 set files I play from. It's hard coded, but it works for the moment.

Next job: make file selection dynamic, so I can just drop files to the SD card.



My code doesn't follow standard aduino notation, sorry!

View attachment 1578
 
Thanks ! And if I understand the timing of the playback is managed with the wait parameter ? It's at 5ms now, but does it play back at the same speed as the original ?
 
Instead of using the delay(wait), You could add a routine into the playtovest() function that uses a reference value declared at the topend of the sketch (int fps = 20) so that the update to leds waits for an elapsed time, such as: while millis < 1000/20 - wait, then continue the loop (which is getting the next frame of values and updating the leds). This fps variable could then easily by manipulated by an external button or control.
I guess that its not that different from using wait (other than the processor can still do things if you dont use delay) and you can use the fps value if you embed the fps value in the stored file
 
Last edited:
Instead of using the delay(wait), You could add a routine into the playtovest() function that uses a reference value declared at the topend of the sketch (int fps = 20) so that the update to leds waits for an elapsed time, such as: while millis < 1000/20 - wait, then continue the loop (which is getting the next frame of values and updating the leds). This fps variable could then easily by manipulated by an external button or control.
I guess that its not that different from using wait (other than the processor can still do things if you dont use delay) and you can use the fps value if you embed the fps value in the stored file



There is an issue I have not worked out yet, where millis() is not returning accurately using Teensy 3.0. 6500 ms real time returns as 2500.

Hence I haven't made the wait time autonomous yet.

Anyone know what I am missing?

Do I declare the clock time in Arduino SW?

I recall seeing a setting somewhere...where you could select 'teensy overclocked at 96mhz'...

Maybe I should just do the unthinkable...and read the manual.....gasp!
 
Last edited:
Thanks ! And if I understand the timing of the playback is managed with the wait parameter ? It's at 5ms now, but does it play back at the same speed as the original ?

It was just a hack until I worked out why millis() was not working, that got me roughly close to 25fps (40ms)


To avoid jitter (repeated frames and skipped frames) I am sourcing video at 25fps, and playing back at the same speed.

I could add a byte into the start of the files to set frame rate...but I think the headache is less by sticking to 25 fps native sources. Plus less than 25fps that looks jerky anyway.
 
Last edited:
Here is what I did to house the controller:

Teensy 3.0 on the lid, so I can still access the USB port.
IMG_20140308_144649.jpg

Power in is provided on the WS2811 cable. A little unconventional, but it is neat.
IMG_20140308_144810.jpg

SD card slot access. I knew I would find a use for the dremel someday...
IMG_20140308_144829.jpg
 
Last edited:
what type of battery pack are you using, did you not want to include the power pack within the housing?
 
Status
Not open for further replies.
Back
Top