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.
This week, I tried to build a machine powered by an arduino and two servos that would walk. My initial design had two servos tightly rubber banded together, with popsicle sticks glued onto the mounts. I did a lot of experimentation with getting it to move differently by changing the rates and timings of turning the sticks. I couldn’t achieve very coordinated motion with this initial design. The main issue I had to consider was how to get the bot to be able to reset the servos after they carried it forward (without the reset moving it backward too much).
I came back to the bot and decided to create a pipe cleaner tripod underneath it and shorten one of the sticks. I thought this might make the movement easier to analyze and increment off of. Unfortunately I had less time than I would have liked to spend with this because I had to go through a lengthy process of elimination of working/faulty parts, which came down to a single malfunctioning wire. I ended up with a robot that moves slowly sideways, and only when set up in a very particular way.
I don’t think the video portrays it well, but the bot almost fell off the table while I was tweaking the code and the tripod position.
Subtitle: shaoyie is not responsible enough to use a hot glue gun.
Finished product! Dragon! (Video will be attached below)
I will readily admit I probably should have focused on the “locomoting” part of it a bit more. Got a little too excited about the dragon part, so it uh, it moves. Just… not effectively. Or in the expected direction.
Photo of completed + video:
I promise it is actually moving. Just….. very incrementally.
I uhh… did not actually take that many pictures. /Technically/ this is my first iteration-
Which is, clearly, having some stability issues. It did actually move a little, but was basically falling over every time it took a step.
Which was funny. But also not great. So I decided to ease up on making it stand on its own, and gave it a little structure frame thing to hold it up properly.
(This was also when I realized why I don’t normally use hot glue guns. I know the glue is hot. Its a hot glue gun. But I always, without fail, want to poke it.)
In addition, I modified the code a bit to make the steps smaller, so it wouldn’t be flailing its limbs everywhere. The pace of the steps seemed to be generally in line with how walking could actually work, so once I had the general setup down, I kept that. This was actually done by incrementing the degrees of the two legs in one single for loop, which kind of made it so that one leg… lags? might be the best way of phrasing it? behind the other.
The final product still wasn’t as good as I wanted. The legs would actually be moving it properly, I think, if I had some extra time to work on it. The issue had to do with the grip the “feet” had + the way they were alternating; they were basically gripping the floor enough to move a little, but the other food was moving with the right timing to then shift it back. I wanted to modify the frame a bit so it would tilt forward more, so that there is grip when the foot moves back, but not when it swings forward. I ran out of time in the fab lab though, so its still not in primo condition. Maybe I will do some extra fixes before class starts tomorrow? We shall see.
Locomoting Pom Pom Bots
We continued on working with Arduinos, and the goal for this week was to make a pom-pom bot that moves from point A to point B.
Initial Design: Inchworm
In lab, I made an inchworm that moved like an inchworm, but didn’t traverse across a surface. So, I thought I could expand on the design, and make an actual inchworm robot. I planned to have a sticky end (dried hot glue) that would cling onto the surface so that each time the bot contracted, the non-sticky part would follow. I created the initial prototype, which did not work very well, and was flimsy. I thought that the sticky part was not heavy enough, so for the second prototype, I added additional weights to the sticky end. Sadly, that did not work out well either. Therefore, I decided to change the design altogether
New Design: Skiing
The new design I chose mimicked a cross-country skier. It would stand on two flat boards, and move by pushing itself forward. I planned to make one side of the stick have more friction than the other side, thinking that pushing on the side with less friction would not move the bot as far. The first design worked quite well, but it could only move back and forth, as pushing on the side with more friction had the same effect as pushing on the side with less friction.
I updated the skier to lift up the poles when moving the poles back to the starting point. It required adding two more servo motors to the bot, and hooking up together so that they did not interfere with each other. Also, I gave the bot a wider base so that it was more stable. Thankfully, the new designed worked very well, and the bot was able to move about.
I changed the poles to resemble a person holding a ski pole, and decorated the pom pom bot.
I think the final product worked very well, but I’m a little bit disappointed that my initial idea did not work quite well.
When I initially had started this project, I had initially decided to go for a simple concept: a “get out of the way” horn, using an active buzzer, and an obstacle detector.
I assembled my parts, and then began implementing them in my first set of code.
After some basic testing, I found that my initial iteration was wrong. The obstacle detector went low when it detected something, so I had to change that to correct it.
With that change, my initial project was working. But I thought that it would be boring with how easy it was to make and how little effort I needed for it, especially given my background, so I decided to change my project, whilst still incorporating what I already had. When going over the list of sensors we had, I discovered we had a laser and a button switch, and I hatched a new idea: a safer laser pointer that automatically shuts off and buzzes when pointed at someone!
After I added these sensors to my arduino board, I was ready to implement them into code. My code had gotten larger, so I couldn’t take a screenshot natively on the arduino coding interface, so I started to copy and paste my code into notepad and take screenshots after I hit what I believe to be important changes in my project.
On my first try, I had decided to have the button use an analog feature to turn on the system, by implementing the enable signal on the obstacle detector using an output signal from the arduino. However, I came to realize that this feature could be implemented more effectively in code by simply using that same input signal in an if else statement that locked the rest of the system’s logic behind that button press.
However, even after implementing it this way, I was still having issues getting the system to work. After some experimentation, I realized the same issue as with the obstacle detector also applied to the push button. So I had to switch the turn on case from high to low.
After that final change, the system worked well! Here’s a video demonstration:
A little difficult from a usability perspective, but for a bare-bones prototype it did a good job in my opinion. I was pretty at home throughout the making process this time, so I didn’t really find any part to be too difficult, the only problems I had were the same as in any other coding project with minor niggling issues that needed to be debugged. I found the process to be fun, especially since I hadn’t used most of these sensors before. In addition, the resources provided for this assignment were very helpful and informative, so learning these new sensors was a breeze.
I feel I’ve reached a stage close enough to completion to make this post. I decided to challenge myself and make a plushie for this project. Initially, what was most difficult was making clean and tight cuts in the fabric.
My efforts there were met with mixed success, and some parts of the plushie suffer (all the appliques were really hard). Straight line sewing stuff together was difficult since I had to be very mindful of the curvature to sew within the allowed margins. Whipstitching was fun but took a very long time since there were a lot of small pieces. Basically, everything took a long time.
When I finally wrapped things up with the face, I used the machine to make straight line stitches to construct the form of the body. I had to be very patient here since I had to constantly compensate for bad edges and shape by pulling fabric and shifting it. Finally, I stuffed it thoroughly and did a ladder stitch to close the back.
I formatted this post as what nearly amounts to stepping through my entire process because everything I did presented some kind of challenge that I wasn’t familiar with, and all of it was worth mentioning. Pretty fun stuff!
Assignment 6: Arduino Introduction
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.
Subtitle: I Swear I Know How To Use Computers
Preface: The end product really…. isnt very complicated. I cycled through trying out some 3/4 sensors because I got overexcited and then after, had a decent amount of difficulty getting my various ideas to work which is hilarious because… I should definitely be better at this. Oh well.
So after spending time in class playing around with:
- 2 magic ring sensors (able to tell when they’re being tilted, pretty neat.), considering making a steering wheel
Magic rings were fun! Pairing two of them together was an interesting idea, so I spent a pretty decent amount of time with it. A lot of the more neat ideas I had required a little more precision than the magic rings alone could offer, but I was pretty sure that at minimum, a basic steering wheel would be doable with two of them paired up. A tthat point I realized that might overlap a little more closely with what we’ll do next week, so I ended up opting against it.
- a proximity sensor (self explanatory) +buzzer in hopes of making a “stay away from me” alarm
Another fun in-class idea. The buzzing noises from the buzzers is /extremely/ irritating, so I figured, put that to good use. If someone got too close to the proximity sensor, send it blaring as a “Get Away From Me” thing. Unfortunately, some others in the class also had this excellent idea, so I figured I’d just branch out and try some other things instead. (Although proximity sensors are always cool).
Out of class, I spent a pretty decent amount of time playing around with IR receivers and transmitters, and was really considering working with that, just because, they’re extremely cool! Unfortunately, most tutorials/guides seemed to opt for having an IR remote to play with, to pair up with the receiver. I think if I had spent some more time on playing with the transmitter + receiver I could have figured it out, but I ultimately figured that if I wanted to play with it, I would want to do so with a remote as well, to get the best out of it.
I also.. apparently forgot to take pictures of this too, sorry.
I ended up with the photointerrupter, which is a neat little peace that has a u-shaped bit that transmits a beam across the u-shaped part. When the beam is broken, the signal the photointerrupting is sending back to the arduino changes.
(Google images photos coming up because I didn’t think to take close up pictures.)
These are my photos:
Anyway, in terms of prototypes, I was thinking some sort of setup that would turn off a light as soon as a door closes (like when it clicks into place). Specifically, I was thinking of it being triggered by a /screen/ door, or something similar (because otherwise the lights would turn off by default every time you shut the door, which would be irritating). So, once you shut the door, it would close by default.
….I do have a storyboard for this, but its /incredibly/ ugly, so we’re holding off on it.
Here is my blog post: Arduino
My demo video exceeds the file size limit, but I can play it in class for show and tell.
Intro to Arduino
This week, we learned to use an Arduino. As a computer science major, I was pretty comfortable with coding, but was fairly new to using electric components. Thankfully, the course was quite clear on what I had to do, so I did not have much trouble with using the Arduino.
Blinking LED Lights
The first thing I did was connect an LED to the Arduino. There were multiple pins on the board, and I could control each of the pins by interacting with the numbers in the code. The + side of the LEDs would go into the numbered pins, and the – side of the LEDs would go to a ground pin. Once I was able to turn the LED on and off, I then moved on to making it blink in morse code, which was pretty straightforward.
The next thing I did was make a touch sensor that controls the LED. I added a very simple addition to the blinking LED I had. It was just a resistor and an alligator clip. With just the two additional components, I was able to make a touch sensor. When I touched the alligator clip, the light would turn off, and when I didn’t touch the clip, the light would turn on.
Custom Arduino Device
For the custom Arduino device, I decided to use a joystick and an RGB LED. The idea is to be able to individually control the RGB components using the joystick. Moving left and right cycles through the RGBs, and moving up and down controls the light intensity of the selected color. Pressing the joystick would set the LED to a random color. There were plenty of online resources that I could use, so figuring out which pin on the LED and joystick went to which pins on the board wasn’t difficult at all.
My purpose of the device was to prototype something similar to the Scribble Pen. The Scribble Pen is a pen with an RGB sensor, that can copy any color and use the color to write or draw with. While the concept is very interesting, I could not find any information on whether it was possible to modify the scanned color to the user’s liking. Not being able to change the color of your pen unless there is an object nearby with the exact same color you want, would be very frustrating. So, this joystick add on would enable the user to make slight modifications to an already scanned color, or come up with a new color that hasn’t been scanned by the pen.
I was able to make the custom device as I wanted, except for setting the LED to a random color. For some reason, the joystick was constantly saying that the button was pressed, even when nothing was touching it. I planned to try it with another joystick, but unfortunately, all the joysticks were rented out by the time I had a chance to visit the lab again. However, apart from that, I would say that my project was quite successful.
Scribble Pen: https://scribblepen.com/ (probably not a real product)
For the storyboard portion, I thought about a few different IoT ideas that have been going through my head for a while. I’ve been thinking about doing a final project with kubernetes running on Raspberry Pis/Arduinos to accomplish some complicated task. The one I’ve been thinking about was for creating a music visualizer that ran off spotify. I already have an arduino project using neopixels to visualize some mp3 files, so I was primarily thinking about how to trigger the system and how to interact with spotify. I looked through some Spotify API libraries and realized this wasn’t totally unreasonable to accomplish. Maybe a final project idea!
In lab, I decided to provide some visualization of a rotary encoder’s position. No particular reason or imspiration for this. I started off with a piece of example code that I modified to write the position of the encoder to the serial out. I verified that it worked, and then decided to try a try an LCD output. Eventually, I got mired in the LiquidCrystal docs and was running out of lab time, so I switched to the RGB LEDs. This was much more simple to implement, and the end product shows the LEDs switching to a different color when the encoder position passes a factor of 25. Pretty neat!
Overall, the process of troubleshooting with arduino code was something I was familiar with (looking through forums, scanning through and implementing parts of example/other’s code). I don’t see this device having many useful applications, but it could be fun to provide ambient light on a joystick for a modded controller.