Our last assignment! This project is supposed to be reflective of what we learned about the design process this semester. We had tasks such as: story boarding, paper prototyping, iterative assessment, and more! The only catch for this assignment was that we had to use a medium/tool that we have never used before. In the past we have always been given or had the option to use tools that we have learned in class, so this was all new. At the beginning, we were given a sheet of possible tools to choose from. Upon scanning the sheet for the first time, I saw “raspberry pi” on the list and immediately snapped into wanting to make a video game console. I have seen this done in the past, so I knew it was possible. I just had literally no idea of how to approach making it.
For the storyboard, it was simple. I wanted to make a portable device that could play games, play them well, and be able to have more than one players playing.
Picture 1: Initial Storyboard
Little did I know, this idea was ambitious to the point of being impossible. To start off, the games I wanted to play (gamecube) proved to be fundamentally impossible for the pi to run. Many forum posters say it is due to the pi not having a 64-bit architecture like the gamecube does. This is false because I ended up running N64, “64” for 64-bit architecture, games pretty well. In short, the pi just does not have enough power to run the games making it literally impossible to make a custom game cube out of a raspberry pi. To rectifiy this I went back a generation of game consoles to the Nintendo 64. Emulation for this console would prove sketchy but doable! To continue, I wrote “4 Players!!” completely ignorant to knowing what a “player” actually is. A player is something that is giving input that the console needs to read and execute. This is much more taxing on the cpu than a simple AI that doesn’t have inputs but only executions. So, this project was whittled down to a portable N64 game console that could support up to two players and run at 60 frames.
One of the first steps I had to take was purchasing a raspberry pi. I took about 30 minutes for me to make a decision between the Raspberry pi 2 B and the pi 3 and went with the 2B in the end. The Pi 3 did offer more processing power for 10 bucks more but many said I could emulate the same with a 2b. I took “the same” as the 2b has enough power to run the game flawlessly. I’m glad this was wrong. If the games ran flawlessly I wouldn’t have much to do. Instead, I learned a bunch about computers along the way.
The other sect of research I had to do was how to interface with the pi. I quickly found that there was an OS designed to emulate games on the pi called “retropie.” To interface with the pi, I need to load an operating system (OS) onto a micro-SD card and boot the pi from there. Getting the OS loaded was easy. Put the micro-SD into a SD adapter -> Put the SD adapter into my computer’s SD slot -> Unzip a folder containing the OS called “retropie” -> Reinsert the micro-SD back into the pi and boot. Research did not take as much time as I thought it would take so I started to worry about if what I was doing was enough. Luckily the pi I bought was nowhere near perfect.
The Meat and Potatoes
The meat and potatoes of this project was the optimization of this tiny computer. Many hours were spent within menus tweaking aspects of the pi that would either allot me more power or optimize a process.
Picture 2: My desk during this whole project!
This amalgamation of cables would be my own little raspberry pi lab for the next week and a half. Two monitors, a laptop, 2 keyboard, 2 mice, 2 usb N64 controllers, my pi, and my desktop. Laptop was for loading software/games to the raspberry pi. Desktop was for debugging research. One monitor to interface with the pi. A keyboard to navigate the pi’s command prompts. Finally, the controllers to test game play. This picture was not necessary, but it was amusing to me!
Picture 3: The raspberry pi 2 model B
This is the Pi I used for this project. In the middle of the board you can see a big green block of metal and a smaller grey block of metal to the right of the green block. These are heat sinks. Heat sinks act as a form of cooling without the fan. Heat is taken from the processor (green) and the Graphics Processing Unit(GPU, grey) and sent upward thorough the little fins. These fins proved crucial as they reduced the temperature of the pi running N64 games from 70 degrees C (highly dangerous) to around 58 degrees C (not highly dangerous). Outside to that modification, the rest of the board is run-of-the-mill. 32GB micro-SD (middle left), micro-USB power supply (bottom left) HDMI (bottom), Ethernet port (bottom right) and 4 USB 2.0 ports (top right).
I am going to do a quick run down of each of these screens’ options and how I used them to benefit me or why I didn’t use them.
Raspi config, left
Expand File system: This formats the SD to the raspberry Pi, already done on my computer
Change Password: Security measure, no password was used doubt someone will hack my pi
Boot options: Could choose to boot to this screen or the OS, I did OS
Wait for network at boot: Have to be connected to the internet to use the Pi, this was disabled.
Internationalization Options: Everything was in English so I did not touch this.
Enable Camera: You can connect a camera via ribbon cable to the the pi, cameras are not needed for video games.
Add to Rastrack: Online pi data tracking
Overclock: I had to enable overclocking on my pi. Bumped the processing power from 900Mhz to 1000Mhz. A 7-10 frame difference in testing.
Advanced options: see right
About Raspi-config: A READ ME file about what each of these menu options does.
Advanced options, right
Expand File system: I do not know why they had this twice
Over scan: Naturally games have these ugly black bars around the screen. Before messing with this, about half the screen was black bars. Over scan eliminates these bars making the game easier to see
Memory split: Oddly enough, I did not have to touch this option. I had the games running at 60 fps without touching it.
Audio: One can either play audio through the 3.5 mm jack on the board or through the HDMI. By default, it was through the jack so I changed it to HDMI.
Resolution: For some reason, the resolution was really high out of the box. Old games do not need high res do I bumped it down to 640×480. Doing this would put less stress on the GPU and processor because there is less on screen imaging to process. Also, there is a hertz associated with a resolution. This number of hertz is a hard cap at the amount of frames a game can be outputted to the monitor. There were options for 50hz resolutions but this would hard cap our game play at 50 frames, not ideal. 60 hertz for our desired 60 frame gameplay
GL Driver: For experimental versions of pi. Did not use.
Picture 6&7: Game Emulator Menu (left) picture taken of the emulation (right)
Each game on the pi is given its own emulation menu from which to control aspects of that games emulation. Every game is a tad different so they must be emulated different.
Default Emulator: Always picks the most powerful one which is the worst one.
Select Emulator: Can choose from 7 emulators. The one I picked, “gles2n64”, prioritizes game play over graphics leading to smoother game play but bad in-game menus and the lack of eyes from smash bros characters (right).
Remove emulator: Removes the emulator. I do not understand this option’s purpose.
Default video mode: I did this back in the raspi-config menu. CEA-1 is the 640×480 resolution.
Remove video mode: Removes the video mode. I do not understand this option’s purpose.
Select frame buffer: Having a frame buffer makes it so that input is separated by frames. Once can press four buttons at once and have them all be read or, with a frame buffer, can have the first button pushed be read while the others are not read. They are not read because the frame buffer counter is not up. This can make games seem more fluid. Games already have their own frame buffers so I did not use this option.
Launch: launch the game and play it.
Exit: save the settings and do not play the game.
The final thing I did was turn off something called retroarch.h settings. Retroarch was a controller setup program that made it so that one could have a specific set of controls per each game. Turning this off allotting me more cores towards emulation.
Overclocking to increase processor power
Changing resolution to decrease computing stress and give the ability for 60 frames per second
Fixing over scan to conform the game to the screen.
Audio to HDMI
Finding the right emulator to show the game
Disabling undesired programs (retroarch.h)
Adding heat sinks to my CPU and GPU to decease temperature.
All lead up to a game console that:
Can be played for hours without over heating
Supports two players easily
Can fit in your pocket
Can conform to any TV
Can hold 32 GB worth of N64 games (biggest game I saw was 50mb, so 640 games!)
And most importantly, run at 60 frames per second.
I could go on about how important to me it was that I managed 60 frames. It just produces the best game play bar-none.
The last bit I had to do was make a box! For this box I laser cut a press fit box. I could have 3D printed a case but a pressfit box took less time and looked better.
Picture 8: The pressfit case.
I used an online generator to produce a .svg file of a pressfit box. All I had to do was add holes for the ports. Picture 8 was a little bit too small so I had to reprint, the concept was there tho. The reason I cut holes in the top of the box was to allow for the heat to rise. Don’t want our console to overheat after all the work we had done to it.
Picture 9: Console presentation
The presentation went better than expected! I did not run into any issues testing at home pre-presentation but that doesn’t mean bugs will not creep up! This presentation ran for 90 min and the console maintained quality throughout. I had a couple people that stayed and played for awhile. I defiantly got more praise for it than I thought so needless to say I was proud of myself!
At the start of this project, when I had to establish learning goals. I said that my tech learning goal was to be able to use raspberry pi as a prototyping device in the future. As for what I would be prototyping, I do not know, but I have the know how of manipulating the pi to get a desired state. Somthing I just thought of being to prototype, as I’m writing this, would be a smart speaker. There is a ribbon cable spot for a screen so one does not have to use HDMI. Then there is the 3.5mm jack for audio. The micro-SD for storage and USB for a Bluetooth adapter as well as speakers them selves. One could use all these aspects to run Spotify on a tiny LCD and play music over Bluetooth (wifi if you have the pi 3).
It is baby’s first computer is what it is, low barrier to entry. A good place to start if one would like to tinker with computational architecture. Which leads me to my educational learning goal. I really wanted to learn how a computer works. I’ve built my own desktop before but that was all plug and play. I’ve never had to manipulate anything on the back end. Going in, I thought I would be just turning down the resolution and overclocking. What I ended up doing was min-maxing cores of the processor. Working in command prompts was also new to me so navigating those was troubling. It was almost like a text adventure but instead of giving command you are writing codes to change directories and call certain programs. Next time I will have to work with computers on a more intricate level I will think back to this project to see if what I did could help.
The theme of this project was iteration. Iteration is when you take a current version of something and modify it and make it better. There is not one sure fire way to iterate on a project to make it better so the sky is the limit on this project. The only catch was. that we had to use at least two techniques in conjunction, with each other, when making the iteration.
For this assignment I decided to iterate on my arduino concept project. In that assignment I simply made an arudino print text to a LCD screen. The text that was printed was dependent on which button was push, left button, or right button.
Pictures 1 & 2: Picture 1 shows actively reading input. Picture 2 shows (printed on the LCD screen) what could happen if you pressed one of the buttons.
How I planned to make an iteration was in three ways: physicality, better back end, and finally content. Before the iteration, the product was a skeleton that barley did anything. It was a ton of fun to breath life into this project!
What I mean by “physicality” is, changing what the project looks like. To change the project physically I considered what I wanted to make over. Being me, I wanted to make a game. What is the most iconic physical manifestation of a video game then? An arcade cabinet. An arcade cabinet is the name of the console that 70’s arcade games were put into. Classics like: Mrs. Pacman, Galaga, and Street Fighter can be found inside arcade cabinets.
Here we have my plan on paper and my inspiration. Once I saw this adorable little thing on the right I got to work jotting down dimensions. I modified the drawing a bit because I thought it would be easier without it. the dimensions on the left are relative to the arduino parts that I was using. Funny enough, the base of the cabinet ended up being a square (the picture is wrong). the length of the LCD is 3.25 in and the width of the arduino is 3.25. Besides the neat presentation, the case also allows for handheld game play. The player can play the game in the palm of their hands instead of being anchored to the table.
On the left we have the assembled shell. ideally what it would look like when completed. This shell was created by putting together two halves (center) with some wood glue. The back half of the shell turned out to not work with my design. The wires for the LCD prevented the back half from being put on. The red marking on the right picture was a marking telling me where I needed to cut. I ended up remaking the entire back half with a big window for the wires.
Picture 8 & 9: Completed Front & Completed Back.
The front of the cabinet looked amazing. On the left side of the picture we can see the little window where the wires get to peak through. The six cords coming through the middle are for the two buttons I will use for input. In the back we have some awesome wiring that I very proud of despite it being simple. The LCD and arduino are held together in place my rubber cement. I used rubber cement because it is what works best for gluing plastic to wood. I have a full back panel that I did not put on, for ease of access reasons, that makes the back look even more clean while giving me access to the power supply. This was the most intensive change done to the original project.
Better Back End
A better back end simply means that the coding was improved. What I did differently was, instead of just simply printing text to the screen using a void loop function, I implemented switch case functions with global variables. Switch case is basically a better if statement. Switch case functions get to bounce around depending on the situation, very manipulable through the use of global variables. Once a situation occurs I can change the global variables so that the program can jump to the right situation instead of just going down the list.
Content is the game side of the project. Within the switch cases, I spun a simple dungeon crawler game. What the player picks, or doesn’t pick, will affect them as they travel through the dungeon. Also, a mechanic in the game will be the buttons changing purpose. In the original project, I made the buttons only print yes or no. Now, the buttons will change purpose per the situation. Before a battle, two lines of text will display what the buttons do. For example, I have text saying “left is defend, right is attack” before a battle. This text tells the user that the buttons now serve a different purpose. Overall, I will use this mechanic to force the player into situations where they have to ponder the consequences of their future actions. The mechanic gave the game its name, “True Dichotomy.” Because, there are literally only two options thus the true dichotomy.
In the link provided one can see the project in motion. The switch case allowed the “really, no” text to come out. Since the variable counting the number of times left was pressed was one, instead of presenting nothing it jump to the next option.
Overall, this project was a ton of fun! This is one of the few times where an end project actually turns out how you wanted it to turn out! One aspect of this project I would change was in the planning phase. instead of doing: construction -> coding -> turn in. I should have done: coding -> construction -> turn in. I felt that I needed to construct the physical object before I coded the game, but that was wrong. I just needed the skeleton to code the game, and debug it. This left the end product feeling rushed. Other projects got in the way last week, so I really only was able to go to the FabLab today (extra time really helped!) thus I was only able to code the game for a couple hours. Coding the game before all this would have saved me a ton of time and stress! One final change I could make to this product is a portable battery. While one isn’t too anchored when playing the game, the 1.5 foot USB B-type cable doesn’t allow the user to stray to far from a computer. have an external power supply would really increase the portability of this product. Again, this project was super fun, and now have some thing to put on my future office desk!
For this assignment we are to use arduino and some 9g servo motors to creating a robot of some kind that can move at least an inch. Over the course of the assignment we are to: design a concept, design a prototype, make a 2nd prototype, and make a final bot that moves the inch. For the concept we are to put our ideas out on paper in a sketch or in words. For the prototypes, we are to describe what challenges we face and how we plan to combat these challenges. Same goes for the 2nd prototype except we have to talk about what improvements we made from the first prototype. I went about this project a little bit differently, my robot traveled by air. Air as in it traveled along two balance beams that were held up by two tables (you’ll see in the video). This project was a bit stressful, I’ll speak more about that in the reflection.
The initial design for was air travel robot was to have a single skewer hold the servo in the air and move each end a couple degrees at a time. Basically my robot was going to look like have of the thing constructed below.
My robot would use: pipe cleaners, skewer, pom poms, Popsicle sticks, servo, and a bent paperclip. Pipe cleaners were used to hold everything in place. Skewer was used to hold the servo in the air. Pom poms would act as anchor points, these would ideally move down the balance beams. Popsicle sticks would be used to construct the beams it would balance on. Servo for movement. Finally, the bent paperclip would be weaved through the servo fin to hold the pipe cleaner skewer in place when moving.
This video shows my first prototype and the biggest issue that I would spend many hours trying to solve. That issue being the fact that the skewer and servo motor are separate entities. Since these two are independent from each other they will not move in unison. Either the servo moves or the skewer moves. If I were to pinch the servo motor with my hands the robot would travel that inch no problem. So, I started to think how I can unify these two parts. I will not change the base of my design but, I could add a couple things to the servo to hold it all together. I thought of using rubber bands and an extra pipe cleaner to hold everything more tightly together.
Here is what the 2nd version looked like. The new pink pipe cleaner is wrapped around the center of the skewer and motor. This pipe cleaner actually did a nice job of holding it all together! Next I would take two rubber band and quadruple bind both side of the skewer. The servo motor has these little notches on the side that made for great rubber band sockets. Overall the 2nd prototype was far more secure that the first one.
I don’t have footage of the testing but the same thing happened, it didn’t move. The servo was still acting as an independent body. This is where I discovered that force was not my solution so I began to look elsewhere (not force) for my final design.
I began to think back to my initial design, about why it didn’t work. I said that, if the servo didn’t move the skewer would, thus I should try to find a way to hold the servo still. I tried to work against the separate bodies when I should have been working with them. Once I thought of this, I finished the project in the next 20 min.
Side note: I will never get over hearing myself in recordings, yuck.
So, here is the final design! Like is said the problem was not the force but of holding only the servo in place. The way I did this was by putting two large Popsicle sticks right next to the motor. These Popsicle sticks would be held in place by the force of two tables pushing on them. These forcefully held Popsicle sticks would act as walls for the servo to stay in place. In the video, one of the Popsicle sticks fell. This reduced my robots movement speed to a shimmy but still got the job done. Instead of being held still the whole time, it would only stay still for a small about of time, thus the shimmy.In this assignment (I’d imagine) one would have three key components: Means of travel, motor, and a core. For the bulk of this assignment I only had the motor and core. Not until I found my means of travel, did I complete this assignment. These side sticks seem odd, but think of it like they are feet. They are a means to move not directly connect to the main body. Would a robot with just toothpick legs be able to move? That is how I justify this addition.
Once again, I made this projects leagues harder then it really needed to be. Traveling by air proved to be a bigger challenge than I initially thought. Physics and stubbornness were my biggest issues for this project.
The issue of physics was the initial problem that made this assignment harder than it needed to be. To start off, the wacky physics I had to deal with we solely because my robot was in the air. Where most would have a robot that would exude a force back on the table, keeping everything together, my robot exudes a force downward, pulling on the sticks. I do not have the physics expertise to competently explain this, but this pulling down force seems to have made the two bodies separate. Moving on, stubbornness forces me to not give up fast enough to pursue alternative solutions. I usually get so fixated on a route to the point where I end up forcing it to work. This is more of just a personality trait that gets in the way more than a specific assignment issue. Overall, stubbornness and ignorance do what they do and delay progress.
As you have noticed my robot only had one motor and not the required two. This was due to be just assuming details instead of actually reading them. I figured we just had to make a robot move, and that the two motor robot was only for class. Since learning this error, I have thought about about a couple designs that I felt I should throw in, for what it’s worth. first design would look something like this -> \_🔲|🔲_/ The boxes are the servo motors and the lines are the Popsicle sticks. This robot would employ a climbing movement along the Popsicle sticks. I would have to put notches on the outer side of the popsicle sticks and something on the ends of the arms so that the arms would have something to hook onto. Almost a sliding lock. The other model would be like the initial two motor design at the top of the post. The design would be a cross that would spin continually on top of two layers of Popsicle sticks. Once one half of the wheel crossed into the middle (where it would fall) the other half would be holding it up. Ideally, in a perfect world, this design would act like a wheel as it spins down the lines of sticks.
During this assignment, we are introduced to Arduino. Arduino is a small computer that a user can upload code to, to execute a task. For example, if one wanted to make a light switch, one could make it so that once a switch was hit, an LED would turn on. What one would have to do to an Arduino to make this happen is tell the Arduino (in C++) to allow power through a certain channel when the switch is turned on. Arduino can be as complex or as simple as you want it to be. For this reason, Arduino has a low barrier to entry, anyone can use it.
I actually messed up and did not take any pictures of what I was doing during the lab so I will try and explain it all. Once we were given free reign to explore our options for Arduino, I examined a bunch of sensors. The fire sensor seemed the most comical but I did not have a flame source for it to detect. This lead me to discover the joystick and button sensors. Given my background of game design, I settled with these sensors. For the output of the game, I chose the 16×2 LCD screen.
For the next hour in lab, I got nothing done. Not because I did not feel like doing work, but I couldn’t find any help online. I only wanted to power/control the LCD screen. Every tutorial for the LCD screen never showed how they plugged the jumper cables in. The text tutorials didn’t help either, they never specified what board they used (it matters!). I managed to find a proper tutorial once I explicitly searched “16×2 LCD screen Arduino Uno.” Overall, learning how to search for the information I needed was the only piece of knowledge I took out of that lab time (not bad!).
Moving on, I messed around with the arduino a bunch in my free time. Most of the time I was just trying to get inspiration. At this point I had a slew of ideas, but didn’t know what was possible for me. A couple of the ideas were: a virtual keyboard, choose your own adventure, and a simple platformer. Once I found out how to upload text properly to the LCD I had an epiphany about a simple yet dynamic way to make a choose your own adventure game.
Choose Your Own Adventure “The True Dichotomy” – Storyboard
“The True Dichotomy” is a chose your own adventure game that only used two buttons as the form of input. In the panels, when the LCD is telling the player “Right is ____, Left is _____”, the LCD is explaining to the player what the buttons mean now. When navigating, they mean no and yes. When in combat, they mean fight and defend. This could me modified in a myriad of ways, perhaps for an iterative assignment?
Here’s a bunch of photos.
Input being printed to LCD. 1 = button not pressed, 0 = button is pressed.
The moment when I had that epiphany.
Picture 1. When no is pressed once. Picture 2. When no is pressed again.
If I didn’t have to pay money for Arduino drafting software (TinkerCad didn’t have enough moduals), I would have made an image showing how I did my wiring. It’s nothing complex, I had a line for ground and line for power. The inputs were inserting directly into the pin holes. The importance of the two photos was to show that there is actual progression in the text when one of the buttons is pressed. WordPress wouldn’t let me past my code for security reasons so just click here. This setup would not work long term. I’m looking into a way to jump to points in the code using global variables as a point of reference.
Jeez, I haven’t touched C++ since high school. Coming back to C++ was just a frustrating as I thought it would be. Knowledge of other languages defiantly makes some of the process easier but makes other aspects even more frustrating. On the other hand, working with Arduino itself was a relatively new frontier. We have worked with circuits before but I still have trouble visualizing circuits in my head. It’s just something I need to tinker with to understand. Basically what I did for this assignment, tinker.
This assignment will be the one i choose to do an iteration on! I have this whole idea for an arcade cabinet that has the two buttons but three LCD screens. I plan on making a legit choose your own adventure game completely contained within the Arduino. I am thinking about buying a bigger LCD screen for more text while having two smaller LCD screens displaying what the two buttons currently do. This is going to be so cool if I pull it off! Once I find a good framework for my code, everything will fall into place.
For assignment 5, we were tasked with creating two objects during class and one outside object. Object one was a simple drawstring pouch that sewed only using straight lines. The second object was an embroidered patch of our own creation. Finally, we had to combine the two skills we learned to make a textile object of our own.
The final object had to have at least 4 colors embroidered. This requirement seemed arbitrary to me since to complete this I would just have to choose a random spool of thread instead of doing two white sections. I embroidered an eye, so I feel that I should not be docked points for not stitching a red pupil on my chicken.
We may have been doing this assignment for three weeks, but this assignment offered the least amount of time to work. This is troubling since the out of class project needed more than three work days to complete. Because of this, I only have the head of my plush to show. Also, sewing machines are insanely inconsistent. The project became much easier one the idea of perfection was thrown into the sun.
Assignment One: D`rawstring Pouch
This pouch was the product of the first time we learned to sew. To start off we had to cut out two cloth outlines twice. Once cut we could fold one outline on the other and stitch them together. Finally, we had layer the two halves onto each other and stitch them together. Once we folded the bag in on itself it was complete. ez pz.
Assignment Two: Embroidered Patch
In this assignment we had to create a patch using the digital sewing software (I forgot the name of the program :/ ). In preparation for this assignment we had to find a picture/logo that we would be able to process as if we were going to make a sticker in silhouette. Instead of using edge detection, when tracing the bitmap in inkscape, we use the color re-scans. The number of color re-scans will be the same as the number of colors on the patch. Once completed we can export the .svg to the sewing software and start to stitch.
This patch was supposed to look a ton better but I spent more than an hour of class time debugging my sewing machine. I do not remember why, but my thread kept on clumping and getting jammed under the metal plate. One issue I vividly remember is having to re-thread the bobbin. I’m glad I had to figure that out since I had to do it again during my individual project. Kind of glad I experienced these problems, navigating a sewing machine is easy now. Only issue now is understanding why thread just clumps, seems really random.
Assignment Three: Torso-less Mythical Chicken
Ok, so this actually kinda cute plush chicken head was far more stressful than it should have been. The sewing seams just worked, I was bewildered at how it just came together. The guide was great, easy to follow. The reason why I’m astonished that it “just worked” was because everything else about this project was annoying.
To start off, I spent about two hours just cutting fabric. Of course this plush had more parts than just the head. A lot of little parts. With there only being one good pair of fabric scissors, cutting took some time. Next was the issue of embroidery. Embroidery most of the time just didn’t work. In the picture you can see the blue oval and how crappy it looks. I don’t know why it did that, it just did. Also, embroidering one face took about 30 min. Finally, was the issue that I printed two left faces lol. Instead of making a proper right face I inverted one of the left faces. so now, the right face looks ugly but I saved time. Overall, the development process was crappy but I feel that I produced a product that is indicative of my skill level.
Overall I feel that the challenges I faced in this assignment were not “real” challenges but more of ones of happenstance and poor planning. I’ve already stressed how much I dislike the randomness of the sewing machine. during assignment three that was almost the only issue with sewing, inconsistency.
The other fake challenge was how, in my opinion, how poorly this assignment was scheduled. I had a total of 7 hours available to work on this project, that was not enough. We could not really start the assignment until we learned embroidery. Since we learned that the week before spring break, and the assignment was due the week we come back, This only allotted me three possible times I could come in during the FabLab. This minute amount really impacted how I felt emotionally about the assignment. I didn’t care about my final product, I just wanted something I could turn in. I know scheduling is hard, especially for this semester, so I understand that one project was going to go poorly.
This week’s assignment was that of two parts, an in class introductory 3d model and, a batch of different prompts that we had to complete using 3D modelling software as well as print one. The three prompts I chose to complete were: 1. cutlery for your enemy, 3. insert yourself into a piece of famous art, and 4. make a part you need. The prompt I chose for my one print was the part that you actually need.
Overall this project was tough! I definitely spent more time thinking about the prompts then actually working in Fusion. Oddly enough the part I needed and printed took the least time to plot out. To be fair though, my printed object was just a rectangular prism that has had two subtractions. The other two models I made use different functions like loft and editing face meshes. The printed part was more plug and play while the other two were a design challenge.
In class we were given 15 min to design a castle in tinker CAD. I spent 10 of these minutes trying to figure out how the heck to make an arch. Turns out that you cannot rotate faces in tinker CAD so, in a mad panic, I threw up some castle wall and made concept art for a white castle. We then took our shoddy models into mesh mixer to toy around with various tools. The amalgamation shown below was the final product at the end of the session.
Picture 1: Castle walls made with extruding blocks, connected using the union function.
The next pictures will be answers to a few of the prompts that were laid out for us a couple weeks ago.
Pictures 2 & 3: Bumpy Whisk (left) is modified in mesh mixer. Metal Disk Whisker (right) made in fusion.
Ok, so this prompt, Cutlery for your enemy, ended up a bit weird but in a way I accomplished what I wanted to do. I included both the meshmixer picture and the fusion picture because the small metal disks (right) did not show up as well in the meshmixer picture (left). The original design was to make a whisk with metal disks at the top where one’s thumb would go and a bumpy sticky looking handle. The metal disks are placed where the user’s thumb would go, or where the most pressure would be applied. After some use these metal disks would probably slice the users hand. Moving on to the second modification, the handle was meant to be sticky-looking because that’d be terrible. I thought that if I were to use meshmixers’ brushes I could achieve some sort of residue looking pattern. I ran into the same issue we did in lab with there not being enough polygons, so I tried to remesh. Remeshing ruined everything so I had to revert everything. I ended up playing with the brushes at random and came up with the bumpy handle (left). So, this metal-slicing-disk-bumpy-sitcky-handle-whisk is the perfect gift for your latest enemy!
Pictures 4 & 5 Me 3D scanned using fusion and a piece of famous art found on google images.
This 3D model addresses prompt number three on the assignment sheet. We all scanned ourselves during last week lab and, when doing so, I made myself as low as a polygon render as possible because I knew I wanted to do some sort of bust. Through my googling I found that busts are WAY more detailed then most images. That is not to say that the image on the right is low detail because I chose it, but it was the easiest to incorporate into my 3D model. The bust was sculpted by Chris Mitton and is supposed to be modern iconography in a classical medium. I was already wearing a hoodie so having two hoods would look weird thus I had to find another way to make me look anonymous. I was able to make a complex mesh and seemed as though it was a bandanna wrapped around my face. Then I threw on some shades because I thought it was lacking.
Picture 6 Complex 3D Mesh
This was the mesh that I made using two center arcs connecting with a line. I then added a anchor point in the middle of the top line so it can be bent outward. I then used the face mesh editor to pull some vertices out, creating the warps you see above. All of this made it seem that the bandanna was kinda attached to my face.
Pictures 7 & 8 Battery Pack Wall Mount in Fusion(left) and Battery Wall Mount Printed(right).
The final prompt was to make a part that I needed. Would be silly to do this one and not print it thus is why I printed it. Starting out, I took measurements of the orange battery pack (right). Once I constructed a prism with the dimensions I needed I made two subtractions. One was to make a cavity for the battery pack. The other was so that I could snake a micro USB through the bottom. The picture on the left has the small hole in the wrong spot, I fixed it in the right picture. Where I messed up (I guess) was making the fusion model in inches instead of millimeters. When I imported the .stl into the flashware it came up as the inch measurements but in millimeters, so it was tiny as heck. I googled the conversion and scaled it. The right was the end result, didn’t print right at all.
Picture 9 Attempt at salvaging.
The height and depth were manageable but the width was not. So, I tried to clip them off with clippers. The model was too sturdy though so it just snapped and broke.
Overall I don’t think the biggest challenge was designing for 3D modelling but actually navigating the software. My prior experience in 3D modelling was using 3DS MAX, and its was more of a sculpting software, (atleast that how I used it). When making an arc, not have to sketch a line and loft it. I could just keep extruding the same circle and rotate the face a little bit to form a curve. the process of getting there is always the hardest, never the execution. The battery pack wall mount is a contender for my iterative project for sure. I have these modular slots on the front face of my computer tower and could possibly make a charging try come out of it. Would be really cool if I pull it off tho.
For this week’s assignment, we had to create some sort of paper circuit display using: copper tape, a watch cell battery, & some LEDs. In my case it was all those listed items plus some alligator clamps. The purpose of this assignment is to give us a very basic understanding of how electrons flow to make a circuit.
Instead of making a paper display with LEDs, I decided to do something a little more engaging. I made a small time version of the board game “Battleships” where the players used alligator clamps to scout for enemy “ships”(red LED). A player uses their alligator clamp to find enemy ships by clamping down on a positive end of the opponent’s LED. If it clamps onto an enemy ship the LED will light up red, if they miss the LED will light white. Instead of mimicking the 100 square board that Battleships has, I only did 9 squares so that I would be able to get the point of the design across.
To the left is the first version of the battleship board. The copper tape can be seen intended to make the 3×3 grid. I have an arbitrary LED at the bottom right of the copper box which I used to test the circuit. The placement of the watch battery servers a structural purpose by weighing down the paper flaps when the board is standing up. Once the player taps the positive side of the LED, the circuit is completed and the LED lights up.
I learned a couple things from making this prototype. For starters, terrible spot for the alligator clamp. The clamp being at the bottom of the paper made it difficult for the whole board to stand up. Also, paper is a poor material for making things stand up on their own so the jump to construction paper was made. Finally, I learned that completing the circuit while using another piece of metal, that is not the top of the watch cell battery, made completing the circuit inconsistent. So, I had to anchor the clamps to the actual board.
Pictured above in the blurry picture on the left and the clear picture on the right is the final form of the pseudo Battleship game. The LEDs on the paper have their positive side sticking through the paper so that the opposing player can clamp on to it while the negative side sits under copper tape waiting to be completed. I moved the clamp position from the bottom of the paper to the side of the board. This allows for not only a better structure, but also looks nice. From these pictures, one can see how this method could be applied to a large board for a real game of Battleships. Overall the project went well and turned out better than I thought it would.
Working with circuits was harder than I thought it would be! I’d like to think I am good at design, but when it comes to circuits I have no clue. I typically do not go for the most basic idea/what is assigned at a base level. So, thinking of something was the most challenging part of this assignment. My issue with circuits might stem from me not being able to visualize what is going on within the circuit. The water analogy seems to be the best visualization but, it just doesn’t do it for me. Doing projects like these could help my situation.
This weeks design task was to create an multilayered (minimum 4 layers) sticker of original design. This is not my first time using the silhouette cutter so there were not any issues regarding interacting with the technology. Issues with this task arose from the art/creativity side and will be explained late in the post.
The bulk of this assignment was spent in this planning phase. Starting out, I had a couple ideas but none I really liked. Most of them were simple, cut a logo in half, splice it into another one, made for a decent cop-out.
I have an affinity for taking dumb ideas and running with them, thus the Cannon Tangler! The Cannon Tangler is a Turtle with an Angler’s head and tail as well as tank cannons on its back. While this may just be a stupid design I actually had to actively think about certain aspects of the sticker that I would not have had to worry about had I went with one of my cop-outs. One such aspect was a sense of depth. the grey backing shown in Pic. 1 was made to be a consistent backing for the whole sticker as well as providing a base for one of the back cannons. In the final product (Pic. 2) you can see that I was able to achieve that sense of depth by making it seem that the Tangler has one cannon on each side of its shell. Finally, the grey backing supplied a stable base that made the sticker, well, stick better as a whole. Had I not had the backing, the back cannon would most likely not stick to the whole Tangler when peeling off the backing.
Pic. 1 Tangler Genesis. The Tangler gets its significant backing
Pic. 2 Tangler Revelation. Finished Tangler with green skin, brown spacers and, two cannons.
I do not have any pictures of the building process but in short it was mostly just connecting nodes, similar to that of the griffin lesson. However, getting the lines to fit the scraps properly was a bit of a pain. I just had to move around the red trace lines around a bit.
Our group came up with the idea of a LCD cutting board that shows the user how to chop a certain item as well as keep track of the current recipe. In the first panel we have a amateur home chef, ignorant at how to properly dice an onion. Introducing, the Chop Coach! The Chop Coach then shows the amateur home chef how to dice the onion with the use of guide lines. Multiple cutting styles can be shown on the Chop Coach, assuring the chef will always have the proper knowledge. In the last panels we see that the home chef was able to properly cook their meal with the aide of the LCD cutting board.
So, this week’s project was to create a name tag that represents them in some sort of way. Me being a game designer and video game addict I immediately went to games. My main thought process for most things starts off as a joke but then I end up refining it until I manage to make it work. More fun that way. Also, an interactive name tag, even though it’s just some lame buttons and a joystick, is a cool idea. In this post, I will be posting pictures of each component while listing off what went into the associated component.
Sidenote: I don’t know why the pictures are turning out so massive and text so small. really odd.
Here we have the innards of a broken xbox one controller
The gizmo on the left is the joystick.
Notice how there is no joystick on the right? I had to desolder it off because it wouldn’t fit the wooden frame.
Learning how to use a soldering iron was a little bit of a challenge but I’m glad I finally learned. TY to Amanda for showing me!
This was the process that took the
Not much went into this front plate but, there are some subtleties.
The plate was laser cut from a silhouette I found on google images and modified in Inkscape. I just removed the right joystick.
The font I wrote my name is from one of my favorite games, Titanfall. Adds a little more “me” into the project.
Finally, I used the laser cutter to cut the holes and raster my name in. EZ PZ.
Here is the final product!
The final thing was gluing.
I originally tried wood glue (cuz wood, duh) but it never ended up sticking.
Then, with the help of Duncan and Emilie, I found out the proper glue was a rubber adhesive.
Working buttons were achieved, I found a use for some old tech, all went well.