Author: Hubert Chang

Click Here to Play on P5!

Concept Development

If you’ve seen my previous blog post and the ideas I had for how to construct this thing, you would notice that the final version of the build is very different from the original plan.

There were essentially two major issues going into this idea:
I forgot to consider that the trucks move in more than just one axis, they also lift up (I believe this is because I have RKP trucks); this means the original support columns would hold the trucks still and disallow it from tilting in either direction
I have no idea how to build stuff with wood.

It was actually Dustin that recommended me to search for “skateboard trainers” online instead of “skateboard mounts” because “mounts” were leading me to wall display mounts instead of what I wanted. Searching up “skateboard trainers” gave me these rubber things that I ordered immediately.

Dustin also recommended me to use large zip ties to secure the board in place instead of building a socket for each wheel. This greatly simplified the process and saved me so much time. I am forever grateful to Dustin.

Testing Prototypes

While I was in class, I thought it might be a good idea to see how people interact with the skateboard so far, with just the rubber trainers holding the wheels, so I invited Yongje and Siyona to take a ride on it. When Yongje initially stepped on it, he said some handle bars might make him feel safe but he quickly got comfortable with it. I paid special attention to where he approached getting onto the board and where he was placing his feet. Siyona was initially a little confused on where to place her feet, so this is when I got the idea to add some green indicators on the board for where to stand

It was at this time where Professor Mang strongly advised me against the idea of introducing a forward-leaning angle to the board. This would’ve created a safety nightmare so I decided to make the whole skateboard sit flat. We also measured out the board’s dimensions and the base’s potential dimensions based on that.

The next day, I went to the scene shop with Prof.Mang to grab a piece of plywood around 126 cm x 72 cm. We sanded it down and I taped a sequence of yellow and black tape as caution lines around the perimeter of the board. I also put down temporary paper tape to indicate where the wheels will go and where the trucks are; this would allow me to drill holes into the

After I had finished planing out the base, I had my good friend Clara step onto it to see how she would interact with it. This is what I documented for the week 13 User Testing so I’ll keep it brief; Clara has never stood on a skateboard before and this was her first time. I started getting an idea of where people who’ve never skateboarded typically stand.

Then I got a video from further away to see how she was naturally adjusting to the board as she got on. I pay special attention to how people bend their knees and adjust their arms when they’re leaning on the board.

Construction & Arduino Integration

 

For this project, I needed an accelerometer for its ability to detect tilt. I bought my Accelerometers off of Amazon instead of renting one from the connect2 system because I wanted to keep it for my project after the showcase. The

accelerometer I bought was the HiLetGo MPU6050 (the blue one) and it worked fantastic despite not being from one of the larger brands.

However, the accelerometer did not come pre-soldered so I had to solder it myself. Thankfully Professor Shiloh did a fantastic job of teaching me everything about soldering and I was able to solder everything really well by myself. 

Here’s my vector-hand drawn Affinity schematic for the circuits:

After that day, I spent a lot of time in the scene shop with Tony working on the base of my project. Carrying it by its sides was getting very tiring so I decided to cut a handle with the jigsaw. In my practice cuts I was not cutting very clean circular shapes at the ends of the handle so I decided to use a hole saw for the corners and use the jigsaw to cut the straights instead. The handle may not have been necessary but it was much more convenient to transport the big rectangular base after I made it.

Then was the task of drilling holes in the base for the zip ties to tie down the board to the base. The original idea was to tie it to the trucks but the rubber skateboard trainers actually make for a perfect place for the ziptie to slip through. I measured roughly where the zip ties would have to go through for maximum stability while allowing slight lift for the RKP trucks to tilt, marked it with a pencil, and then drilled it out with a 9.5mm bit. This part was very challenging since it was my first time woodworking but it was a very rewarding experience; I was very glad I challenged myself to make this project.

Professor Mang recommended that I make a small plank of wood that would house my Arduino and be semi-locked under my board but removable at any time so I decided to make that; I started by grabbing a small plank and sanding it down thoroughly since I was going to be handling it very often. Then I moved onto drilling two holes in opposite corners to each other and marking the holes on the main base with pencil. I then screwed in two small golden screws to hook onto the small modular piece. It turned out pretty great, and it even stays on while held vertically; although I’m not sure if the added weight from the Arduino and breadboard would allow that once those are mounted on.

You might have also noticed that I made a handle for the base; that took a really long time but I love how it turned out.

Software Development

I didn’t really have a clear idea of what the game would actually look like for most of the semester; and yes, I’ve been planning this since day one. I even

wrote it down on a doc in my drive.

Sure I had a few ideas, but nothing that really excited me. I wanted a game that involved only side to side movement, but it would still be engaging and dynamic.

I thought about games like Pong, Subway Surfers, and even the “catching random things falling out of the sky” genre, but none of these sounded fun. Pong would be easy to do but I’m not sure it would be very fun playing against a wall that bounces the wall back by oneself; the reason why the midterm co-op mode worked was because having a second player added a whole ‘nother dimension to the design.

I ended up having this great idea for a bullet-hell inspired 2D spaceship shooter; I didn’t want it to be too stressful so there wouldn’t actually be bullet hell intensity but there would still be obstacles you need to steer away from. So I got to work.

Interface Design

The interface was inspired by many different things. A lot of the UI is inspired by my midterm project; I thought it would be nice to have a coherent menu system between them. It made sense since I also reused my code for screen and button management for this project. I loved how the title screen turned out. I had been designing in portrait mode all semester because portrait feels more casual and informal but I knew this project had to get the full landscape treatment and be placed on a big display.

The “Hull Integrity” health bar is inspired by one of my favorite games of all time, Titanfall 2. It works perfectly here as the

health for the ship. I think it looks great too, especially with the blinking effect when your ship is “doomed.”

 

So much of this project was inspired by the Titanfall universe and the amazing design from the team behind it. I really hope that my designs make any potential Titanfall fans that play this project happy; it sure made me happy learning to recreate it.

Sprite Design 

All the sprites were custom drawn by me in Affinity using vector tools. I had a lot of fun designing the sprites for the game. I really loved creating separate sprites for the spaceship based on the damage it had taken. I think it adds a lot to the visual communication to the player, especially for them to take more caution.

The parasite alien sprites were inspired by Casey Reas’ Eyeo talk on chance operations all the way back from the Week 2 reading; it’s from around 28:00 minutes in where he creates these little symmetrical space invaders-looking aliens. I have an image below of one of the ones Casey made and one I made that was inspired by it. All of the parasite designs were strongly inspired by examples shown in that Eyeo talk; I thought it’d be a nice callback to I believe was our first ever reading assignment.

 

 

 

 

 

The asteroid sprites were the one I was least proud of, I really struggled to make unique variations so some of them look a lot nicer than the others. I’ve always struggled to depict nature so this stressed me out a lot. I only made 3 of these so unfortunately you see a lot of repeats.

Sound Design 

The sound design for this game was quite challenging. For one, the game is set in space— there is no sound in space. For two, I wanted to avoid generic Star Wars-like sounds. 

I chose a kickdrum for the railgun shooting sound because I knew a bass-y sound would be less annoying to listen to on repeat than something high pitched. I had a big emphasis on subtle sound design in this project.

Speaking of subtle, I really cared to add things like ambient spaceship-humming and stuff like a sci-fi bridge sound effect on loop when you’re on the menu screen. I thought the bridge sounds with the ambient music in combination turned out amazing; you could listen to some pretty immersive sounds while you browsed the menus.

I also had the countdown sound effect I used in my midterm project return for this one, used in the exact same way — to count the player down before the game starts.

Near the very end of developing this game, I found some voice line files from Titanfall 2 where the mech, BT, says to the pilot “Warning. Major Hull Damage Detected” and “Warning. Heavy Damage Sustained.” This really added to the immersion of the gameplay and I really hope people will like it.

Misc. Design Choices

I could go on forever about the many little decisions I made in an effort to make this game excellent but I’ll stick with the most practical things I designed.

I placed calibration settings in the “How To Play” menu so players can calibrate while they’re on the same page where they try to understand the controls and objectives.

I made all the menu navigation possible with just a mouse; so even if you don’t have a keyboard in your hands, you can just click RMB to go back to the main menu; but if you do have a keyboard available you can also press CTRL to go back (ESC would exit fullscreen and I don’t think I can remove that from the browser).

Creating Custom Keybinds

I had a lot of fun setting up the serial connection because I split everything up into separate functions I can call and assigned each of them to a keybind. I thought the “Connect to Arduino” buttons I was seeing looked so ugly and felt so unintuitive, so I came up with my own solution.

I needed a button to quickly reset the current angle to C so I assigned “C” to become my calibrated button. It was chosen because the word calibrate starts with a C, which became a reference point that was easy to remember.

“X” was used to connect/disconnect the serial connection. It felt SO much more practical than having an onscreen button. “X’ was chosen purely because it was next to “C.”

And lastly, “B” to open the debug menu. This really made it feel like a real developed video game.

How this was Made (AI Utilization):

I asked ChatGPT 5.1 to help me set up the accelerometer I bought off of Amazon. It helped me understand what each pin did and gave me the library I needed to download for my MPU6050; afterwards, It helped me debug my serial connection code that I copied from the lecture notes and helped me add a P5 to Arduino transmission that would tell it to zero itself and calibrate the current angle to 0 degrees. ChatGPT 5.1 was a major help for setting up the serial connection.

ChatGPT 5.1 was also used to debug everything when I couldn’t figure it out. It recommended a lot of different approaches to program things like enemy spawning. Through the debugging process I ended up learning really fast because it answered all my questions like”why would you fix it that way?” or “are you sure you’re right? doesn’t this function() work like this?” in a really clear and precise manner.

Final Words:

This project was genuinely one of the most fun projects I’ve worked on in my three years at NYUAD. Through this project alone, I learned so much about woodworking with Tony in the scene shop, soldering with Professor Shiloh, and general project management throughout every step.

I want to give a very special thank you to Tony, Dustin, Professor Shiloh, Professor Ang for general guidance throughout the project, whether it was teaching me new skills or even training me in new tools. This project wouldn’t have been possible without them.

I also want to thank my playtesters:
Gauhar Meiram, Clara Juong, Yongje Jeon, Siyona Goel

For this week’s user testing, I invited my good friend Clara to be my test subject. Clara has never stood on a skateboard before and this was her first time. I try to tell her as little as possible but I did tell her to feel free and grab the table in front of her if she felt unsafe or if she lost her balance.

First I asked her to simply step onto the board; this is good for me to see where her feet would naturally stand. I’m also going to use Clara as the average height of a female user from now on.

Then I got a shot from further away to see how she was naturally adjusting to the board as she got on. I pay special attention to how people bend their knees and adjust their arms when they’re leaning on the board.

Lastly, I told her to try and lean far back and far forward to see if she was comfortable.

Are they able to figure it out? Where do they get confused and why? Do they understand the mapping between the controls and what happens in the experience?

Prior to Clara, I’ve also had a few other people step onto the board and everyone so far has understood how to step onto the board safely and slowly.

However, first-timers always express that either tilting forward or backward is initially a little scary, but the other way was fine; more people indicated that leaning backward made them more nervous than learning forward.

The controls are pretty intuitive based on what I’ve asked Clara and the many other unofficial test users. Afterall, you simply learn forward or backward once you’re on the board.

What parts of the experience are working well? What areas could be improved? 

People who have never stood on a skateboard before were really excited to try; everyone so far approaches the experience with caution so that part is working great. I believe the fact that the board is stationary calms a lot of people’s nerves. It did come to my attention that a lot of people on campus might be wearing very casual and loose footwear on the day of the showcase (sandals, crocs, etc), so I should probably restrict loose footwear that doesn’t hold your foot in place very well.

I’m going to make a slideshow explaining everything about the project for people who are lining up to try if there’s someone already playing with the project.

What parts of your project did you feel the need to explain? How could you make these areas more clear to someone that is experiencing your project for the first time?

I felt like I had to explain to people that whether you skate goofy or regular was not dependent on your dominant hand, and that they should do what feels more natural to them. 

I think a quick tutorial on how to stand on a skateboard before the game starts would be great. In addition to that, I’ve placed some colored tape to indicate where to stand and especially where not to stand (like the tail).

 

I unfortunately don’t have anything physical down for this week, but I have made a lot of my own blueprints for how everything will physically be put together.

After speaking with Professor Shiloh, I got a lot of ideas on how to go about assembling my skateboard controller. Prof. Shiloh showed us this tool that could measure the diameter of round axles and drill parts; I was thinking I could use that to measure the exact diameter of my skateboard truck hangars (the long metal piece). I’m expecting around 1.8 mm right now for the hangar diameter and around 8mm for the axle itself.

I’m probably going to create a hole with the size of the truck hangars in mind if possible; otherwise, I would need to create a hole for the truck axle to spin into, which might be a bit difficult. I want to build the frame in a way where I can take it apart for ease-of-transportation.

Mount Mechanism

For the mounting mechanism, I’m going to build a wooden frame to hold the board. I want it to be tilted forwards around 30 degrees for a more intense and immersive experience. The way I’m going to do that is to make the rear wheel support columns taller than the front ones.  Here’s what it might look like:

And this is a top-down view of the frame. It would have long extensions on each side to prevent the board from tipping over when the user is playing with the board. There’s no proper dimensions for this design yet but I’ll look into what length I would need each side to be for ideal safety standards.

I’m going to be placing the infrared sensors on the wooden frame below the board. There would be a sensor on both the left and right of the board, which will provide input values to the Arduino. The reason they aren’t going on the board is because then the sensors would tilt with the board, disallowing it from detecting true distance from the ground. This is roughly what it will look like:

Arduino Input & Output

The Arduino is going to take the two Infrared Distance sensors as an input (in millimeters). It’s going to do some quick calculations to estimate the degree of tilt based on the two sensors and output a value for the tilt; It’s probably going to use arbitrary units from -100 to 100 where 0 is perfectly neutral and not tilted while negative 100 is tilting far left and positive 100 is tilting far right.

P5 Input & Output

The P5 side of things is going to take the -100 to 100 scale from the Arduino output and likely map it to what the user is controlling. If the user is controlling the X-position of a ball, the board tilting left would cause the ball to slide to the right. It’s kinda like the video game Super Monkey Ball where you physically tilting your controller (gyro controls) causes the level to tilt and subsequently roll the ball around.

This would require some physics-like exponential mapping that I’m not quite sure how to do yet but I can imagine this already being a really fun experience.

 

Production #1: Potentiometer Moves Ellipse

Link to P5 Sketch #1

Production #2: P5 Controls LEDs

Link to P5 Sketch #2

I modified it to also take “A” and “D” keys as input just like the mouse clicks

From the very week of the semester when I learned what the final project would involve, I wanted to implement my skateboard into it as a controller.

The Digital Side of Things

I’m not quite sure of how the P5 side of things would look yet, but one of the ideas I had was to create an experience that commentates on the shaking feeling of anxiety and expresses it as speed wobbles going downhill. I’m not quite sure I can simulate that safely or even have a mechanism that provides movement to the board at all, but it could be a fun idea. You would have to balance the board at certain times but also lean in to either side to make decisions.

Another idea I had was to make a more simple arcade-styled game that uses the skateboard controller. For example, I could make a pong game with two skateboard controllers that have the same mechanics as my midterm project (the forward and backward velocity factors). This would definitely be a little easier on me on the programming side but I’m not sure how I would do two separate skateboard controllers, or if it’d even be fun.

The Physical Side of Things

I have actually thought extensively about how the board might be physically situated.

I want the skateboard to sit stationary so I’m probably going to create something like a wooden frame to hold the board either by the trucks or by the wheels. If I want the frame to hold onto the trucks, I would need to unscrew the wheels and create screw holes in the wooden frame. If I want to keep the wheels on, I would make a mold to hold the board with the wheels on.

For the input sensors, I would need a pair of two distance sensors, one for each side of the board. Each of them will be placed on the ground facing upward to detect how tilted the board is. If the distance between ground and board is closer on the left side than the right side, that means the rider is probably tilting left to turn left. I’m not sure if there’s a more efficient way of approaching this but that’s the idea I have so far.

I want to take advantage of resources we have in the IM lab and scene shop but I’ve never worked with physical materials on this scale before so I’m not sure where to start. That’s definitely one of the bigger pain points on the table right now.

Ultimately, there’s a good chance I might change the concept of my project entirely to fit a little closer to the scope of my current abilities. I realize there’s a lot of unfamiliar territory I want to explore here and it might be best to play it safer.

One of the most interesting points Pullin makes in his book is the idea that lots of design standards around disability is to cover it up rather than embrace it or emphasize it. There is always a strong push towards “normalcy” in the design world. His example of how glasses went from medical necessities to a fashion item; I believe most people may acknowledge someone wears glasses out of necessity but we also subtly know that the style of glasses they wear is also an expression of themselves. I imagine as prosthetics become more advanced and fine-tuned, humans will find a way to embrace these tools as more than just their functions but also introduce an expressive layer to them. An easy example of how that might look is if someone needs a prosthetic arm, they might want a prosthetic arm that resembles their favorite prosthetic-using character in fiction (like Edward Elric, Luke Skywalker, or even Guts). This agency and idea of co-design can empower non-able-bodied folks.

Pullin actually mentions that prosthetic arms are much more intimate than prosthetic legs; arms inherently serve more than their function, and it’s not just about nails, veins, or perceived texture. If it’s trying to resemble a fleshy human arm, it creates a serious sense of disappointment and is often off-putting. Pullin mentions the best approach here is often to NOT hide the fact that the arm is artificial and instead emphasize it while giving the functions of a fleshy arm. This was all really interesting to me, especially his example of how certain clients of Monestier would hate the feeling when the hand would initially fool new acquaintances until they had their moments of realization.

As I read this article, I thought about how prosthetics in fiction are often romanticized. A sick metal arm that can turn into a cannon or extend out to become a grapple hook are often framed as “upgrades” but I imagine not having complete dexterity and fleshiness creates quite a sense of void that most fiction rarely explores. I thought of this as a connection to last week’s reading on a “Brief Rant on the Future of Interaction Design”, which I also thought was very insightful. There must be an inherent, strong emotional gap on prosthetic function and feeling, and I think our portrayals of disabled characters in media could use some more commentary on losing their sense of touch.

This week Yongje and myself paired up to make our very own musical instrument.

I thought about the capabilities of the arduino speaker and was unimpressed with the sound “texture” of it, so we discussed what we could do with a rather limited range of sounds we could generate. I’m not much of a musician so I suggested what if we made a simple beat recorder, kinda like a metronome of sorts? Yongje informed me that what I was describing is called a “loopstation” and we got to designing.

Concept (With Visuals) – Hubert

After we planned what we wanted to do, I decided to visualize the user interaction side of the project first before designing the schematics and technical side.

The red button would be to start/stop the recording process. A red LED would indicate whether it was currently recording.

The blue button would be there for the user to tap in their beat.

When you are done with your beat, you can save it by clicking the red button once again. You can see whether it was properly stopped by the indicator turning off. Then you can press the green button to play your recorded beat.

Schematics & Planning – Hubert

Before we started connecting metal to metal, I made a schematic to quickly map out everything we needed to connect.

 

Code & Difficulties Encountered – Yongje

There are 3 main parts to the code.

The first is figuring out debouncing logic, which is used to remove the state when the system is bouncing between true and false when the switch is pressed. The second part is playback, actually playing back the recorded soundLastly, the third which is the hardest part: finding how to store the beat recording.

I’ll start by explaining the hardest part first, which is storing the beat recording.
The beat recording logic works by tracking the time of each button press and release while the device is in recording mode. Every time the beat button is pressed, the program calculates the gap since the previous press (gap = now – tRef) to capture the spacing between beats. When the button is released, it measures the duration the button was held (dur = now – lastPressTime) to record how long that beat lasted. Both values are stored in arrays (gaps[] and durs[]), building a timeline of when each beat starts and how long it plays. Figuring out this logic was the most difficult part.

Now onto explaining the playback logic. The playback logic is responsible for reproducing the rhythm that was recorded. It does this by reading through the stored arrays of gaps and durations in order. For each beat, the program first waits for the gap time, which is the delay before the next beat begins and then plays a tone on the speaker for the duration that was originally recorded. Because each recorded gap includes the previous beat’s duration, the playback code subtracts the previous duration from the current gap to get the true silent time between beats. This ensures that the playback matches the timing and spacing of the user’s original input, accurately reproducing both the rhythm and the length of each beat. I had to create a logic to turn negative silence time to positive because sometimes it gave errors when the inputs and the durations of beats were too short. This is explained in depth in the comment section of the code.

Finally, the debounce logic ensures that each button press or release is detected only once, even though mechanical switches naturally produce rapid, noisy fluctuations when pressed. When a button’s state changes, the program records the current time and waits a short period to confirm that the signal has stabilized. Only if the input remains steady for longer than this debounce delay does the program treat it as a valid press or release event. This filtering prevents false triggers caused by electrical noise or contact bounce, giving the system clean, reliable button inputs for recording and playback control. At first, I didn’t have this debounce logic implemented and had a hard time figuring out why the system sometimes failed to recognize button presses or seemed to trigger multiple times for a single press. Once the debounce logic was added, the button responses became stable and consistent.

Reflection

I believe this project turned out really well, and it was very interesting to work on our first group project of the semester.

My initial impression regarding the”Brief Rant on the Future of Interaction Design” reading was that it was formatted in a very engaging way. As someone with ADHD, I tend to read long paragraphs a lot slower than individual sentences structured this way; this made me trust in the credibility of the author’s perspective on interaction design.

The way the author transitions from explaining the importance of touch to the complete lack of it in our touchscreen technology was really done, and I couldn’t agree more. Using touchscreens is really un-stimulating, and if anyone who has tried texting without haptics will know it feels incredibly unresponsive– but that also seems to be the future we’re headed towards. The images Bret Victor chooses to accompany his texts are hilarious too; there really aren’t many things we naturally need our hands to swipe on other than manmade touchscreens. Victor’s explanation of how humans naturally transition between grip-styles is pretty interesting to me too.

This reading gave me a lot to think about. One of the things that came to mind was the experience of using a controller versus mouse & keyboard when playing video games. For those unaware, let me explain the main differences between the two.

When you use a controller (or gamepad as some call it), you’re primarily using your thumbs for everything from the analog sticks to the surface-buttons. Using just your thumb to control your camera controls can be quite difficult if precise and delicate movements are required.

When you use a keyboard and mouse, your arm and wrist are capable of microadjustments while holding the mouse to input much more precise and delicate movements; not to mention your keyboard hand is using way more than just your thumb to control what’s happening on screen.

So going by what I’ve said, many would probably wonder why anyone would ever use a controller, but that’s the thing– I haven’t explained the one thing that makes this remotely a difficult decision.
Controllers give an extra layer of immersion by both letting the user relax their arms and lean back, but also provide the user with haptic feedback and vibrations in response to what’s happening in-game. Imagine you’re playing a game where explosions are involved– the controller would vibrate violently in your hands as explosions affect your character. This is why you turn to keyboard and mouse for precision but controllers for immersion.

Now onto Victor’s follow-up article– I thought his response to voice was pretty amusing, “I have a hard time imagining Monet saying to his canvas, “Give me some water lilies. Make ’em impressionistic.” It’s amusing because that’s literally how our modern generation approaches stuff they don’t know how to do.

One other thing that really caught my attention in the follow-up was this quote, “The density of nerve endings in our fingertips is enormous. Their discrimination is almost as good as that of our eyes. If we don’t use our fingers, if in childhood and youth we become “finger-blind”, this rich network of nerves is impoverished.” I wonder if late-gen Z and gen alpha have any indicators of finger blindness as so many of us grew up with touchscreen devices as our main source of entertainment.

 

I initially really struggled to come up with a concept for this week’s project. While I understood how to use analog and digital switches, I wasn’t sure how I would use them in conjunction to create something engaging and interesting. I slept on it and woke up with the idea to build off the theme of security from week 8 and make a lock mechanism using analog inputs like the potentiometer.

One of my biggest concerns was that I wasn’t sure how to draw a proper schematic so I looked online and used Tinkercad Circuits for a while but it wasn’t exactly the simple schematic drawing I wanted so I decided to save the site for future use instead.

This was the schematic I came up with. I knew I was going to mess up and have to move stuff around so I did it digitally using simple shapes and lines on canvas. I barely knew what I was doing and to be honest it made a LOT more sense to just start putting wires and pieces together on the breadboard but this schematic was how I thought it would look.

And this is how it looked physically with all the relevant pieces attached to the breadboard.

I knew the wiring would get pretty crazy as I started to connect everything so this is how I color-coded them:

• • Red: Power Source (+)
  • Black: Ground (-)
  • Green: Inputs Connections to Arduino Uno (Switch, Pot Meter, etc)
  • Yellow: Output Connections to Arduino Uno (LEDs)

On the code-side, I made sure to declare each pin I was going to use at the very top so I could quickly change it if I needed to swap stuff around.

int greenButton = 7; //button to open lock
int blackSwitch = 2; //part of the lock (the black on/off switch)
int potMeter = A4; //part of the lock (the roating blue one)

int greenLED = 12; //lock is open
int redLED = 11; //indicates lock is still locked

//LOCK COMBINATIONS
int blackSwitchANSWER = LOW;
int potMeterANSWER = 1000; //above X value to be correct

This is what the final product looked like:

I didn’t run into many bugs when coding but I did initially accidentally set the red light to always be on unless I was holding down the green button. I had to search online how I could fix this and I eventually found I could set the pinmode for the button to “INPUT_PULLUP” which was useful for inputs that otherwise would have no stable value when not pressed.

pinMode(greenButton, INPUT_PULLUP); //INPUT_PULLUP is good for buttons that automatically spring back uppinMode(blackSwitch, INPUT_PULLUP);
pinMode(potMeter, INPUT);

pinMode(greenLED, OUTPUT);
pinMode(redLED, OUTPUT);

I did have a physical difficulty where I was testing different kinds of inputs with the switch and the potentiometer and forgot what the correct combination actually was– and with no way to know if the green light was even going to turn on when it WAS correct. Thankfully a minute of trial and error and making sure the code side of things was correct got me to return to the original combination, but that could’ve been pretty annoying if the lock was any more complicated.

When it came to the LED light responses. I originally had the appropriate light turn on for 2 seconds and then turn off. I felt like this didn’t feel quite right so I made a creative decision to flash the appropriate light as feedback instead; I did this by creating a for loop that would flash the light 5 times with a small delay. This felt a LOT more responsive than the brief moment that the light would turn on previously. Below is the full if-statement that checked whether the confirm button, the green one, was pressed.

if (greenButtonState == LOW) {  
  if (LockIsUNLOCKED == true) { 
    digitalWrite(redLED, LOW); //turn OFF red light
    for(int i = 0; i < 5; i++) {    // flash 5 times
      digitalWrite(greenLED, HIGH);
      delay(150);
      digitalWrite(greenLED, LOW);
      delay(150);
    }

  } else {
    digitalWrite(greenLED, LOW); //turn OFF green light
    for(int i = 0; i < 5; i++) {    // flash 5 times
      digitalWrite(redLED, HIGH);
      delay(150);
      digitalWrite(redLED, LOW);
      delay(150);
    }
  }
}

I am very proud of how it turned out in the end with both the technical difficulties that I solved and how it feels to interact with it. Below is a demonstration of the lock working; you need to toggle the black switch to the right side and twist the potentiometer counterclockwise to the end.

Link to ino File (Google Drive)

I started this project with a few ideas. One of the ideas was to make a secret switch hidden on a bookshelf. One of the books would have a piece of copper tape underneath that would touch the copper tape beneath it on the shelf. However…I realized that I didn’t have enough books to make it look convincing so I started looking around my room for something that inherently had motion to make my life easier. So I thought– what if I used my door?

Sometimes I don’t fully close my door properly and don’t know if it’s fully closed. That inspired me to make the door a switch to act like a DIY security system. I have no experience with physical computing so I had some trouble visualizing how it would look in my head, and it didn’t help that I’ve been out sick for so long. This image below was my initial concept for it.

The idea is to set up a simple LED light on the breadboard that would light up when the door was fully closed. I think I understood that pretty comfortably, but I didn’t know how the rest would work.

One of the challenges was having a mobile power source, as I was definitely not going to use my laptop for power when the Arduino kit is all the way up on the wall. I remembered that I found a battery pack in the kit so I dug that out and went down to the IM lab to ask for help and got some spare AA batteries.

The breadboard and Arduino setup was pretty straightforward but the one thing I had to think about was which wires to leave as an open connection later. From my perspective, it made sense to have the ground be split up and later connected using the copper tape so that’s what I did, while following the color conventions of PWR and GND.

I walked over to my door and applied some copper tape and set up my Arduino & battery pack on the wall using some mounting tape. However, as I worked on setting up the rest of the copper tape, I realized that this was going to very clunky– the door’s frame is not seamless with the door itself which means I need something solid to connect it; however, the copper tape was a bit too flimsy to be that connection. This is what I had so far at the time:

 

I was pretty perplexed by this. After some critical thinking, I realized that I could set up the arduino on the door itself. And not only that– I could even take advantage of this metal piece that helps the door slide into the lock near the door handle. This was my updated plan for my switch:

When it came to positioning the wires, I thought the copper tape would suffice to keep the wires in place but it just wouldn’t stick very well; I also needed to be able to micro-adjust and tune the location of my wires to make sure the system worked smoothly. I decided to use mounting tape again to make fine tuning the position of the wires much easier on me

I think the final result turned out to be really nice, and I’m proud of myself for adapting to the difficulties encountered during the process of mounting the project on the wall. It’s a shame I have to take it down to make future projects but I had fun making it.

 

Here’s a video of the final result in action; the green LED lights up to indicate a full lock when closed properly. I would not recommend installing this as your sole security system.