Image Manipulation [Nov. 27, 2016]

Foreword:

I find it interesting how a collection of things may not make sense individually but all together for a coherent object. A letter without the context of a word has no meaning and a word without the context of a thought, sentence, etc. is less useless but similarly can have no meaning. The point I am making is everything is relative to a certain degree. With that in mind, I decided to play with perception. I took an image of Jupiter, the most beautiful planet in my opinion, and sliced it into 8 pieces. The direction of each piece alternated such that 4 went left ad 4 went right, then reversed directions after a certain point. When they met in the middle the planet was fully visible and the image was coherent. Otherwise, it was just an assortment of colourful slides.

Image: 

Code: 

 

What Computing Means To Me [Nov. 22, 2017]

     As a Computer Science major I obviously have a special relationship with computing and technology in general. When you really think about it, computing dominates our lives. Warming up your food in a microwave? That’s computing. Walking up to and through an automatic door without giving a second glance? That’s computing. Drawing money from an ATM. Again, computing. All these these may seem ordinary, and by now they are pretty ordinary, our lives would be so drastically different if they never existed. I’m sure many people don’t stop to consider the history of things they are using now but as someone who is absorbed in the field, it is impossible not to think about just how much computing we use in our daily lives.

     Before, when programming was more of a hobby than a career path for me, I thought technology was amazing, whether new or old. Older technology obviously has its charms because people of the time had to use what was available to them and yet they still managed to pave the way and lay the foundation for the advancements of today. Obviously newer technology is amazing too by virtue of the near-miraculous things we can achieve. Now that I have delved deeper into the field and it is no longer just a general interest, I find myself being even more amazed by everything. Now that I know the architecture of a computer, and instruction sets and memory and all these super complicated low-level things that go into the simplest of computers it is hard not to be in awe of how this stuff is even possible, how this stuff has progressed to the point where, as Michael said, it is almost impossible to know how everything works all at once. I am deeply appreciative of everybody who has come before me and excited to see what I, and everyone around me, can achieve all thanks to computing.

Frogger Inspired Game [Nov. 6, 2017]

Foreword:

This week we had to create a game using Processing and Arduino in conjunction with serial communication. My first idea was a game similar to Frogger, where the user would control one object and try to avoid the horizontal moving obstacles zooming in from the left. There are two safe areas at the top and bottom of the screen. When the player is in either safe zone the score is incremented but will not be able to be incremented using that safe area until the other one is visited. This was to remove the possibility of the player basically going in and out of the same safe area in quick succession and padding their score unfairly. If the player is hit by an obstacle the game is over and the Game Over screen is displayed. If the user wishes to play again they can press a button and the game will be restarted with new obstacles and reset score.

The serial communication part was fairly simple as I used the same code for the Etch-A-Sketch we created in class last week. The control scheme is the same: use two potentiometers to control the x and y position of the player and a button to trigger some event. So no problems were to be had there.

The hardest part was figuring out the logic for collision detection. All previous implementations of collision detection included fairly static items on the screen and only a few of them (for example: balls that would be moving, but the walls of the screen are constant). The problem was there were so many obstacles on the screen and the player could collide with them from any direction. Therefore to solve the problem I examined the cases. Either the player was coming from the right, the left, the bottom or the top of the object and so checked each condition in a series of nested if-statements. For example, if the object is within the bounds of another object from the right side, then if they were within the bounds of the object from the top then that is a collision. The same check has to be made for coming from the bottom as well and then these two checks have to be repeated but from the left side. This way all cases were handled.

I decided to add a score so that the game has some point to it (the way the score is calculated is described above), and a Game Over screen that shows the score and instructions on how to restart the game. The text() and textSize() functions were used to display text.

Finally, states in the game were all handled using boolean type variables so that the game would always know the state of different events. Is the game over? Has it been reset? Has this safe area been visited already? All these are stored in the boolean variables.

Edit: I added images for the player character. When you score in the top safe area the images changes to a downward facing frog sprite and when you score in the bottom safe area the image changes to an upwards facing frog sprite. I also added sound effects for when you die using the Processing Sound library.

Screenshots:

During Gameplay

Game Over Screen

Code:

Processing

Arduino

 

Controlling Servo and LED Using Serial Connection [Nov. 1, 2017]

Foreword:

This assignment involved two pairs of Arduino and Processing patches both used to practise using serial connection to communicate with a microcontroller using Processing. The first one uses the mouseX location and sends it to the microcontroller. From there, in the microcontroller, the value received is mapped to a value between 0 and 180 and written to the connected servo. The second one draws two rectangles on the screen and then when the mouse is clicked a function runs to check if the position of the mouse is within one of the rectangles. Depending on which rectangle was clicked, a 1 or 0 is sent to the microcontroller. From there, in the microcontroller, the value received is used to turn the LED on or off.

Servo Code

Arduino Sketch

Processing Sketch

 

LED Code:

Arduino Sketch

Processing Sketch

 

Random Squares Remake [Oct. 30, 2017]

Foreword: 

I decided to recreate Bill Kolomyjec’s Random Squares from Computer Graphics and Art because I immediately thought of how to create it in code when I saw it. The biggest challenge was figuring out how to create a random number of squares in each larger square and how to create a uniform offset for each set of squares. I overcame this by making clever use of the random() function to create the “odds” of drawing a square inside another. I also used one random() function and a switch statement to determine which corner the squares should lean towards if any.

Picture of Original:

Picture of Remake:

Code:

 

Self Portrait and Rectangles [Oct. 16, 2017]

Foreword:

Here is a self portrait using the basic shapes in Processing. To generate the picture I played with the fill colours, whether there was or wasn’t a stroke around the shape, and had to get creative to create the curls for my hair. As mentioned in class, the Processing reference site has a lot of useful information and helped a lot in explaining what the arguments for each function mean.

The second task just required a loop to print five rectangles in random positions. To make it interesting I made the colours of each rectangle change. I also slowed down the frame rate so that the colours would change slower than the default fps, which is 60.

Pictures:

Code:

Self Portrait

Rectangles

 

Fishnet Football Player :) [Oct 11, 2017]

Foreword:

This project involved a pair of legs. The challenge was to get the legs to emulate human motion. I decided to raise and lower one of the legs. This was simple enough in theory because the leg that was to move would just need to be fixed to the moving servo arm. The code was simple too and the circuit is just one servo, not even a breadboard was needed.

Challenges Encountered:

As stated above, the task itself was not difficult. The most difficult thing for me was trying to figure out how to fix the unmovable leg to the servo, while keeping the movable leg free to move without hindrance. First I tried using a central axel that was fixed to the unmovable leg and the servo while the movable leg was placed loosely on the axle, giving it enough room to be able to spin. The problem with this is that the servo was not held in place well enough and so instead of the leg moving, the servo would be the one moving. My basic knowledge of circular motion and rotation had failed me so I went to my plan B. Plan B involved just sticking the servo through the static leg, meaning the servo arm was free to spin, then gluing the moving leg to the servo arm. Et voila, the problem was fixed but not as nice looking as it could have been.

Things I Learned:

  • The servo body will move if the arm can’t move
  • Axels are not as easy to implement as I thought.
  • Many body movements can be emulated with a servo

Code:

Schematic:

Match Game 2017 and Review of Atoka’s Game [Oct. 9, 2017]

Foreword:

The original idea I had for my whimsical project was a device with buttons that seemingly correspond to LEDs, however, when you press a button the corresponding LED doesn’t blink. In fact, any of the LEDs might blink, plus a buzzer might sound, plus a servo might whiz around. The point was that your initial expectation upon pressing a button would go unfulfilled. So it would be a random box where the signifiers were misleading. My final project ended being the same as my idea, however, I turned it into a game of sorts where if the LED thank blinks corresponds with the button you pressed then you’d get a point. Once you have five points, you win and a victory tune plays.

 
Things I learned:
 
  • Tone() affects PWM on pins 3 and 9
  • Hot glue guns are your friend
  • Random() generates a pseudo-random between an interval you specify
  • The design is important because while my circuit was similar to last time, the design of the box around it makes it look so much better. 

Code:

Schematic:

Review of Atoka’s Device:

Description: Atoka created a fun little game where you had a wire disguised as a hook around another wire that was bent and misshapen into a weird shape. The aim of the game was to move the hook over the shaped wire without making it touch, similar to a maze game I saw online where you can’t let the mouse curser touch the sides of the maze as you traverse. If you touched the wires, it would make a loud buzzing sound and a red LED would flash.

Was it amusing?: The game and circuit were really simple, but still it was a lot of fun to play. I tried more than once to beat it without letting the wires touch. I really appreciated how effective her device was and its simplicity translated to elegance in its execution.

Were the affordances useful?: The game really only consisted of a switch basically. Touching the wires would close the circuit and cause the buzzer to beep and the LED to light up. Therefore the switch allowed us to be able to play the game. The buzzer and LED were both useful as well as they allowed a means of notifying the user (light for the LED and sound for the buzzer).

Were the signifiers helpful?: This is the area I feel Atoka lacked in. The LED and buzzer did go off when you closed the circuit, which notified that you have done something wrong, however, besides that nothing else gave any sort of indication of what to do. The design was so simple that it was not hard to figure out but at first glance a user will have no clue how to use it. 

Verdict: I really liked Atoka’s game overall. It was simple and effective. The affordances were adequate for what the device was meant to do but even one sign saying “don’t let the wires touch” would have been a helpful signifier to relay the aim of the device.

The Elaborate “No Wakey Wakey” Synth Piano [Oct. 2, 2017]

Foreword:

We have all had experiences where our roommate is being noisy and preventing you from sleeping. Well not with this piano. The built-in light sensor prevents this piano from playing when the room is dark and your roommate is sleeping. However, once the lights are on (and the power indicator LED will let you know what sufficient light is) you can play the three octaves of A that this model can output to your heart’s content. Maybe you wont compose the next masterpiece with this, but at least your roomie can get some shut-eye.

Potential Improvements/Ideas:

I wanted to add (and did at one point, before removing it) a servo that rotates 180 degrees from “off” to “on” and vice versa to act as a power indicator along with the LED. I scrapped this idea because I figured it was unnecessary for this assignment and plus, having so many things connected to my redBoard was making me nervous about burning it out.

Another idea would be to have a wider range of sounds, but I only have a few buttons and I feel like adding more sounds would be trivial and not display any additional knowledge that the three buttons don’t already show. If this was an actual product for sale more time would be spent in this regard but for the purpose of this “prototype” the aim is really proof of concept.

Problems Encountered:

  • A few of my wires were apparently not working and finding which ones needed to be replaced was a difficult task. 
  • Sometimes, if the buttons were not contacting properly with the breadboard, weird things would happen like the wrong note playing or inexplicable resistance on the buzzer causing volume dips… at least I think it was resistance, it could also have been conflicting signals causing strange behaviour.
  • At one point the buttons were not working (when the wires needed to be changed) so to determine which button was not working I did a Serial.println() each time a button was pressed so the faulty button could be snuffed out.
  • Before I removed the servo, in order to get it to work I had to ground it directly to the redBoard. Grounding it via the breadboard was not closing the circuit for some reason but connecting it directly to the redBoard did.

Code:

 

Schematic:

HW 7 – A Simple Instrument

Foreword:

This is a simple circuit with three buttons and a buzzer/speaker. Each button plays a different note and holds the note for as long as you hold the button. All the notes are really just different octaves of A so you will never be out of scale! 

Code:

Schematic: