ICMadness (Weather Cat)

Really pleased with the product of my group, Jesse Simpsons, Hadar Ben-Tzur, the Cat That Teaches Using A Weather API.

For me this was the best of collaboration. Everyone had a job. Things came together in the end. There was doubt we could finish. But it worked, finally, flawlessly 🙂

http://alpha.editor.p5js.org/jps723/sketches/S1mh9y-Ab

 

Bigboard Rembrandt (Pcomp – Nov 1)

This week in Pcomp, I successfully completed the goal of last week’s Pcomp midterm of translating Rembrandt’s The Philosopher in Meditation up on my big LED board, using data extracted from the jpg image. Here is the result:

UNRESOLVED ISSUES

  • I could not get a handle on the bottom 3 LED rows that seem to act sporadically still. I have no idea how to control them or why they are not behaving when the rest of the LED matrix seems fine.

KEY FACTS LEARNED

  • Creation of colour is different RGB value on a screen than on an LED light painting.
  • Transplant of image alone is not enough for an artistic rendering of Rembrandt’s Philosopher in Meditation on the bigboard.
  • Great, subtle range of detail is possible even with an inaccurate LED matrix. The human element shows (in line with the conclusions drawn from Danny’s wooden mirror).

PROCESS

I used the code from last week’s successfully transplant of a 9×9 pixel gif to the 9×9 (81 LED) matrix. With adjustment for the larger LED board and image (only adjustment of dimensions), and directly applying the code, at at the onset, the result looked like this.

With screen in front – quite a beautiful pattern, but not what I’m looking for. Why was the image so sporatic? I checked the data coming in from P5 and it looks like its correlated to the Rembrandt image. Why did the images work last week and not work this week?

CHANGING THE ALGORITHM OF SYMMETRICAL IMAGES

I realized last week’s methods were appropriate for some symmetrical images, but inappropriate for asymmetrical images. I also knew that it displayed on the pixels differently than the image orientation. For instance see the following image and its display output:

This was the first clue something was insufficient about the code for my purposes.

I realized the problem was the conflict between directionality of the way the LEDs were wired (which starts from the bottom-right and proceeds in a zigzag left-to-right, right-to-left pattern) and how I programmed the p5 get() function (in loop that collects pixel data in a left-to-right way). The order of which to light the LEDs on a row that runs left-to-right is different from a row that runs right-to-left. Thus, I needed to find a way to construct the array to collect the LEDs in the exact opposite way the LEDs are wired to flow.

This involved intense manual calculations of where each LED row on the board start and ended. Precise LED locations for each row. (This was very difficult to do manually, given my tendency to make errors, so in the end I did it on Mac Numbers).

In the end even Numbers didn’t give me the accurate values. I tried to map out all the numbers ahead of time and it took a few hours. So I occurred to me to do it the manual debugging way: testing each row through commenting it out, and light up each row at a time, using different colours. Low-tech and effective.

After confirming accurate location of the rows, the information displayed still seemed quite sporadic.

I realised an error was that I was sending an array that was too large on P5 by making getPix() in the draw loop instead of the MousePressed function. Basically this means I was making my array way too large to be useful.

De-focusing my ambition of getting a rembrandt image right away, I settled on uploading a simple X image.

The output was somewhere, but still sporadic.

I tried to isolate it by row, but its still sporadic.

I tried using other types of images too but there was still inconsistency.

INABILITY TO VERIFY P5 DATA

During the difficulties, the key thing for me at this point is that there doesn’t seem to be a reliable way to verify precise serial data coming in from P5 on the arduino without contaminating the serial port.

For instance, when I tried to debug by serial.print() and display on the P5 console, the values stop at around the hundred-something mark and then the loop takes about half a second to complete (which I verifyed by blinking the pin 13 LED.)

if (Serial.available() > 0) { // if there’s serial data available
for (int i=0; i<=2239; i++) {
inData[i] = Serial.parseInt(); // read it
Serial.print(inData[i]);

digitalWrite(13,HIGH);
delay(50);
digitalWrite(13,LOW);
/delay(50);
}

Why does this happen? When I comment it out, it works again. It “works” meaning it displays on the LED matrix, albeit incorrectly.

This is important to know because at the moment, I’m not sure if the problem is: (A) the way I am displaying the P5 data on the neopixels, of (B) if the way I am displaying the P5 data is fine and it’s the P5 data itself is corrupted going through the serial port.

UNRESOLVED ISSUES

  • Confusion over what ParseInt() does. The Arduino website says that it returns “parseInt() returns the first valid (long) integer number from the serial buffer.” However, my actual experience shows that it returns not just the first, but a series of values that allow them to populate the array that I am able to then transfer on to the Neopixel matrix. How exactly does

KNOWNS:

  • Data from Chrome Javascript Console (CJS) is correct and reflects configuration of pixels on image.
  • Arduino code to write to neopixel matrix (NM) has been confirmed to be accurate based on colour test.
  • Image printout to NM is sporatic and changes depending on which iteration I click, despite the fact that the P5 data is the exact same every time.
    • possible solution: I will code a NM reset to zero whenever the loop begins and before serial input is received.

HYPOTHESIS

  • Problem is in here:

for (int i=0; i<=2239; i++) {
inData[i] = Serial.parseInt();
}

  • Something about the above does not create the appropriate inData[] array that contains the appropriate pixel value.
  • Oh wait, another clue. After printing out the array length on P5 it seems the array has 5145 elements… definitely not the 2240 that I am looking for. Oh wait no that makes sense since the “JustR” array is not an array but a big string that keeps getting appended with more information and “,” in between. So that number makes sense. NEVERMIND.
  • Back to the original idea. I now coded it so that the beginning of the void loops completely empties the array of any values so that the array is completely fresh for whatever serial data brings. And when do mousepressed more than once, again it prints to the array in different configurations. Which makes me think its some issue of timing between serial data and the array storing it. Maybe the timing is not right between P5 and the arudino and the array is not capturing the parseInt() string data?
  • I notice that when I put things in the parseInt() part of the code, the NM does not light up and the pin 13 LED lights up for a while fast and then goes very slowly with a delay longer than I specified.

for (int i=0; i<=2239; i++) {
inData[i] = Serial.parseInt(); // read it

digitalWrite(13,HIGH);
delay(50);
digitalWrite(13,LOW);
delay(50);
}

  • I suddenly received an intuition that maybe I need to time the delay the in above loop in the right way to ensure the timing of the P5 serial data is the same timing as the Arduino. I remember Tom Igoe said something about this in his video. — NOPE THIS DIDN’T WORK.
  • It seemed that clearing the array at the start of each loop led to an accurate image at the first MousePressed data send from P5.
  • Update: 8:11pm Monday Oct 30. It seems like the top 29 rows are fine… it’s just the bottoms 3 rows that are off.

At a certain point, I just stopped trying to get a handle on the first 3 rows and decide to try the Rembrandt image again. And it worked. What I also realized was that RBG values for making colours on a screen are different than RBG values for making colours for a light painting.

I adjusted the colour by mapping the input based on different RBG values of the work as a whole:

for (int i=0; i<=2239; i++) {
RData[i] = map(Serial.parseInt(),0,255,0,50); // read it
}
for (int i=0; i<=2239; i++) {
GData[i] = map(Serial.parseInt(),0,255,0,30); // read it
}
for (int i=0; i<=2239; i++) {
BData[i] = map(Serial.parseInt(),0,255,0,10); // read it
}

UNRESOLVED ISSUES: why does the LED matrix do stuff like this? 

Finding Time for Art

Transferring schools from the Arts Students League of New York to ITP has been quite the change. I miss painting. I miss the “hard” arts. I miss doing abstract expressionist drawings.

I haven’t had any time to work on my own work: light paintings. I haven’t created any new images since the summer. Gabriel has been good about drawing. I aspire to follow his example.

Now that fab and video/sound are done inshallah i will have more time.

I just gotta have like, one day or something to devote to it.

I havent found the proper balance or rhythm yet.

Pcomp (Big Board – Image to Neopixel)

As Danny assured me in his office hours, serial communication really does open the doors wide open. My PComp midterm is about opening the doors for my ongoing art project, the Bushwick Lightbox. 

BACKGROUND:

From January-February 2017, I constructed a larger light board than the one I had been experimenting with last fall. This new light board was 32 x 70 = 2250 RGB LEDs.

One of the first thing I wanted to experiment with on this board was taking the light painting concept to the next level. I wanted to do a renaissance painting on it. I took one of the greatest painters of light of all time, Rembrant. I wanted to translate his Philosopher in Meditation into a new medium.

However, it was too much trouble to program each line manually. Below is an earlier iteration of this attempt. While it proved that the image had depth (and proved that it was possible to do figurative with light painting), it was a far cry from its highest potential.

Learning how to control the LED with the webcam during the Serial lab showed me the way forward on this particular piece. Controlling on LED is one thing, but controlling 2250 LEDs using a 2D matrix array would be a different matter. I have seen LED TVs before so obviously I know its possible — but I don’t know how to do this. This is a great opportunity to up my lightboard game w/ serial.

OBJECTIVE: to put up an image of Rembrant’s philosopher on the lightboard.

PROCESS LOG:

Session #1: Time is 6:57pm Saturday night Oct 21. Progress made in trying to make an array of the pixel values in P5 of the imported Rembrant image. But I’m encountering problems in printing them on console. It’s printing out a RGBA values, but it’s nothing but black, which is wrong. I’m close… but alas, I have social obligations to attend to.

Session #2: Resumed work on Sunday evening at 9pm. Encountering difficulties around the J5 pixels and displaying them. Get() doesn’t seem to be working consistently, even if I preload() the image. Shiftman’s video on Pixel arrays is helpful in this regard.

10:24pm – figured out why I was getting random readings on get(): the background was being painted every time! no wonder I was getting black. Now I am getting a beautiful console full of array RGBA values 🙂 However it runs from top left to right… my big board is programmed bottom-right to left. I’ll have to reconcile the two. Stopped working around midnight after my Arduino Due power light stopped working without a reason why.

Session #3: Monday morning 1030am. Figured out that I needed to plug the power supply to the entire board in order to keep the Due ON light from fading and assuring the computer could read the arduino on the serial port. Not sure why, since I was only powering one LED. Maybe it’s because there were so many LEDs the data wasn’t getting through to it.

12:30pm – having problems reading P5 serial data. I’m using serial.write on P5 and Serial.read() on the arduino. Not sure what’s up….

1:15pm – isolated the problem to the P5 wonky output I’m seeing through the console. For some reason, me mapping the pixel data to an array is stopping the console in its tracks. When I comment out the whole array part, the console operates normally. (Taking a break to see an acquitaince’s LED installation now).

3:00pm – figured out the error is this: “Exiting potential infinite loop at line 29. To disable loop protection: add “// noprotect” to your code“. I ignored it before since it didn’t seem to freeze the entire program, but somehow everything grinds to a halt when it shows up.

LINE 29 seems to be the culprit. But 29 is a fixed loop! how can it be infinite???

5:34: The P5 editor gave different results between myself and Dano (who I emailed for help on sorting out the above problem), so I have concluded that part of the problem may be the P5 alpha editor. Therefore, I had to sort out another way to get a P5 sketch running on my screen without the P5 editor… which was itself a journey. Now I’m up and running w/ Sublime text, a directory, for which this video was a great help. (Youtube has everything!) I am now watching a Shiftmann video on running a local server since the image wouldn’t load.

6:09pm: I am realizing this is really getting me to intimately involved with the Chrome console, which I have always wondered about.

6:31pm: really going down a rabbit hole here. Now I’m getting “from origin ‘null’ has been blocked by CORS policy” error on the chrome JS console. Seriously how do I change text colour in this wordpress editor? Very not useful, guys.

6:40pm: got it working! boom! it was just a simple matter of having the serialport.js in the libraries folder and making sure the scripting in the html file reflected that. Mental notes: CHECK FILE PATHS. The image loads after all! OK! Time to get back to work on serial to arduino after that detour!

6:50: everything should be working and data should be sending to serial. BUT now I am unsure of the order of operations to recieve data from P5 to arduino. Do I run the sketch first, then open the serial port, then open the Arduino console? etc. Experimenting with this…

7:06: having problems uploading the sketch to the Due. Getting the error [avrdude: stk500v2_ReceiveMessage(): timeout] Thought maybe the P5 sketch run through local server may be taking up the serial port so I closed the serialport app and the browser, but I’m still getting this gorgeous little error. (I give compliments to computers in the place of curse-words in the hopes this will appease them). I have disconnected the USB and restarted arduino and it still happens. Maybe it’s just a weird inexplicable error? ARDUINO GODS PLEASE WORK!

Oh crap Arduino was  on the MEGA mode from me taking a break to program my basement light, that’s why. Jeeez.

7:19: back on track. Still not reading serial data from the Arduino. My J5 is sending serial data, as confirmed in the chrome console but the Arduino is not reading it. Not sure why. My serial reading is basically taken straight from the lab.

7:48: trying to debug it with “here’s johnny!”. It’s weird because something shows on monitor… but stops, mid string. Weird. Attempting to google troubleshooting arduino receiving serial data.

8:06pm: wow seems like everything is not working now. When I reload the sketch, there’s no serial data on the console anymore, despite it being written serial.write(get(1,1)); clearly in the code! What the hell bro… Don’t tell me it’s not just an alpha editor issue!

A bit at a loss as to how to go forward from here. I may need to wait for tomorrow’s office hours…

8:11pm: discovered that serial.write() does not always show up in the console. But print() does.

8:19pm: at a complete standstill, no direction to explore. In such a situation, I think I’ll take a walk to the local pub and have a Miller High Life to celebrate the joys of life. Why am I in such a good mood? Who knows? Lina, if you’re reading this: MUAH 😉

Sessions #4, Tuesday, October 24:

11:28am: At ITP. I realized it may have something to do with my Arduino Due than anything else. I plugged in my UNO and immediately I am getting better values. Output still sort of uneven but its a start. I also figured out order of operations: 1. upload sketch to arduino, 2. open P5 sketch but don’t run it, 3. open serial port, 4. run sketch, 5. open Arduino serial monitor.

11:36am: Yup, still not working. I dont trust the alpha editor because of the unjustified infinite loop error and my localhost is not sending the values I want. Good thing I am seeing Mathura the resident in a few minutes.

12:11pm: Boom! It works! With Mathura’s help I discovered my error: I didn’t include the + ‘\n’ in my code. Apparently serial only starts reading value when it receives a non-binary. I should have read the lab a little more thoroughly.

12:24pm: back it not working. hmmm it seemed so smooth when Mathura was here…

12:56pm: BREAKTHOUGH. It just so happened that Jeff Feddersen was sitting in the adjunct zone and I was introduced to him by someone. I asked him a serial question and he gave me great pointers:

-don’t push too much emphasis on what you see on the Arduino Serial Monitor (ASM). Because there’s so much stuff going on there. P5 Serialport and P5 are competing things, and just because you see nothing in the ASM doesn’t mean there’s nothing there.

-better to debug with a blinking LED (the built-in PIN 13 one). That allows your serial data to manifest its presence indepdnetly of the demands of the serial port.

-put serial data in mousePressed() instead of draw() to control the tempo of serial port speed.

2:23pm: moving on to the array, now that I am sure that serial communication is coming through. The array from my 32×70 image, even if each pixel element has 4 elements seem impossibly big. I am going to simplify even further and not do this on the big board, but do this on the small board that I made for the fabrication enclosures assignment. It’s 81 LEDs, 9×9. I am also going to simplify the image so there is no mistake. I used the pixel drawing website to draw a 9×9 GIF that I will use. Nothing fancy.

2:33pm: At this point I am relying more on the LED blinking to tell me what’s going on. The values I’m reading from the ASM are pretty sporadic. Also in the JS Chrome Console (CC) I am seeing that the array length is 40014? 9 x 9 x 4 array elements = 324 at most! Even more confusing is when I print c.length() it prints out 18549. Where are they getting these two array length numbers from??

2:55pm: Figured out the culprit. I had put the function which contained append(c,get(i,j));  in draw() so it was just exponentially expanding! It should have been in setup() all along! DUH! Back on track!

NOTE: test pattern on small board is “smallboardtest”

6:43pm: back at it after Applications. Before I breaks I was having trouble extracting the value from the array since the arduino reads just a bunch of ints on serial.read(). I just want to dumb down the serial data coming over from P5 a little more. And Im content just passing on the R value of the pixels.

7:12: BREAKTHROUGH – After I popped my head into the residents office one of them helpfully told me I could extract out the R of the array with:

c[i][0]

And he advised me to print to console first before going to serial. “One step at a time”. Great advice. Back on track!

7:32: I was getting the right feedback on the JSC but not on the ASM. I was getting strange values. I asked Aaron about it, and he advised me to send one big string from P5 to Arduino, separated by commas. Makes sense. I’m doing it like this:

var justR = ” “; //this is a global

justR = justR + c[i][0] + ” , “;

Apparently you can just declare a variable like ” “? And then attached numerical and symbolic values together in a string? Very useful. And then, BOOM we are in business son!

9:32pm: Jason Beck is helping me debug this thing. At issue is that fact that after I had gotten my R values into a nice, comma-deliniated string, it wasn’t reading in Arduino. We thought it was my machine but I think it’s not, since the same code and arduino runs the same on Jason’s computer. Very sporatic values in the ASM.

10:48: After a brief moment when the thing worked and the board lit up — briefly — and then blowing my computer’s serial port, the Arduino no longer seems to read serial info from P5. Jason kindly taught me how to “handshake” the Arduino and P5 — to establish serial contact before any of the real serial work is done. Unfortunately the current situation is my P5 is not picking up the handshake info from the Arduino.

Not gonna lie folks — thinking about calling it quits. Haven’t even started my ICM homework yet…

Writing this chronicle brings to mind that scene in LOTR where they find the book of the dwarf war against the orcs where they write a journal about how every day they are losing the battle… LOL

11:07pm: OMG! Inexplicably it works!!! I just fiddled with the P5.Serialport App, opened and closed some stuff and it works!!!! THANK THE GODS!

OMG!! I’m so happy!!! I feel like they felt at the Battle of Helms Deep when Gandalf saved them!

Lessons learned:

-The ASM itself contaminates the P5 serial input into the Arduino

-inData[i] = Serial.parseInt() RETURNS AN ARRAY!

-The whole thing worked when I just stopped trying to ascertain the P5 input conceretely (i.e. seeing it on the ASM and just wrote it directly to the LED matrix).

Fab: two materials

Ben: for my make-up fab two materials assignment I decided to built upon my idea for the tea light holders I built for the “build 5 of something” assignment. Here at my tea lights on my wall, attached by velcro. The stark light/dark angled lines are something I did not expect.

I decided to make something to complement the existing light patterns. I looked at my materials and still had the original material I used for the tea-light holders, as well as some mirrors I bought for original use in that project. (I had previously wanted to explore reflection, but couldn’t make it work). I decided to revisit this idea by having something that would re-direct the candle light downwards using mirrors thought a piece of wood that could be affixed to the wall in the same fashion as my tea light holders.

Two pieces of wood would have 10 pieces of mirror each. They would be on different angles facing the wall. One piece would feature a 40 degree angle, and the other would be less step, perhaps 20 degrees). However it would not be a straight cut because I wanted the sides to be untouched to retain structural integrity while hanging off the wall. (If I had make a straight cut the velcro would give to its weight).

I used the bandsaw to cut into the piece. It was difficult to cut a 40 degree angle while leaving the sides untouched. I did this in chunks and segments to make removing material easier.

The second piece was not so easy and in the end, I had to use a variety of materials, including a chisel, to try and remove material.

In the end the second piece was a little mashed up, but I figure given it would not be exposed to view (since it’s where the mirrors would sit), it would be OK and would even add to the element of randomness.

This is how it looks on my walls. The 40 degree angle one is on the top right. The 20 degree angle mirror reflector reflects on a greater distance, while the 40 degree one casts more of a concentrated reflection.

Fabrication Final (Mounting Motors)

I had recently bought a bunch of micro servos just for the hell of it, and it all constellated into a master plan for a PComp final (as well as further research on my light art) so I decided to utilize my final Fab assignment toward this end. 

The idea involves making a shadow box with servos in the middle that will control something like a set of blinds. First I need to cut holes for all the servos. This was my first experience working with MDF. Cutting neat square holes proved more challenging than I thought. I used the drill press to punch a hole, then the scroll saw to clean it up. And then the filer to clean it up further.

Cut em’ all out! Less neat that I originally thought. Maybe next time I’ll laser it. Wonder if MDF lasers well?

The intention was to have the least amount of daylight between the servo arms. To this end I think I succeeded. 

This is how it will look like. At the bottom of the box will be the LED matrix that I previously made.

ICM (Oct 11 – Serial)

I attempted to make my Missile defence/ball vs square shooter into an arcade game with an Arudino-wired potentiometer and button to control and angle and firing of the gun, rather than MouseX and MouseY, which is was previously.

The most difficult thing is to figure out how to receive information Serially at any level of precision. It just seems so unpredictable. I have to open and close the p5.serialcontrol app, I need to unplug/replug the arduino. I need to mess around the finally it works — not ideal.

Collaboration vs Group Work

The most difficult thing about the first month and a half of ITP has been group work.

Note however that I use the word “Group Work” differently from the term “Collaboration”. Group work can be collaborative at it’s very best, but group work is more difficult than the free choosing of partners because strangers are paired together with abilities, temperaments and personality quirks that may or may not match.

If collaboration is dating, group work is the blind dating.

In the world of international diplomacy and government policy, when I was forced in work in a group in the past, typically the work is so delineated and already defined that there is little struggle on creative vision. But where there is the question of creative vision, it is usually the manager that acts at the ultimate arbiter. This is why there is typically a designated team lead.

Which is why the applications groupings were so uncomfortable. So uncomfortable… yet interesting and thought-provoking. Because of the imbalances within the group between age, temperment, worldviews and attributes of the different individuals I was often surprised at the direction the workflow would take. The necessity of doing something together with people you disagree with: it is a make or break thing. But I am constantly surprised what it makes. While I believe it makes something lesser to what a collaborative group makes in content, it works out mental muscles that could be better off for everyone in the long run.

It led me to think that maybe group work was ironically like travelling solo: when it sucks it really sucks, but when it’s great its really great.