SciBorgs

For Friday's class, we began exploring an application for arduinos – sciborgs! YAY!
But first, we had to learn about functions, but that's okay because functions are pretty great too! My partner for this assignment is Amy.

Functions:

In order to learn about functions, we were given an SOS code to look at and run. Functions are very useful for repetitive actions because, as you can see in the SOS code, it allows the coder to do less typing. YAY!

How Functions Work:

Functions are created outside the infinite loop and when the function is called, the computer jumps to the function and performs the task listed. When the computer has done what is listed inside the function, it jumps back to where it was in the infinite loop. If the function is called again, the computer will jump back to the function, run through the code, and jump back to the main loop, over and over again, for as many times as the code calls for, until the program ends.





Setting up our sciborg:

This is the part that I was really excited for – putting our Arduino knowledge to use! Here's a picture of our SciBorg

Singlemotor:

In this code, we tested out a single motor. This was pretty straightforward, as we were given the code.

Reset/Blank Code:

We also created a blank code whose sole function is to turn of the SciBorg when it isn't being used in order to preserve the batteries.

BothMotors:

Now, since we want our SciBorg to take full advance of both its motors, we turned both of them on by coding in the motion of its second motor. We used our previous single motor code as a template.

Bareminimum:

For this exercise, we spent some time tweaking with the motor speeds in order to get a better idea of what numerical speed correlated to what kind of visual speed. We then were able to discover that on the tables in the lab, the minimum power required for the SciBorg to move at all is at 80.

Hardturns:

To get the SciBorg to turn, the motors have to be set at different speeds from one another. No surprise there. In these next two exercises, by experimenting with values, we learned a bit more about the speed relations that would get us the different types of turns. To get a hard turn, or a very sharp turn, all you have to do is set one motor as the negative speed of the other. In our case, we had one motor at 255 and the other at -255.

Softturns:

In order to create a softer turn than in the above code, we decided to make the speed of one motor slower than the other (basically nonexistent, since we discovered that the minimum speed is 75). The smaller the difference between the motors, the softer the turn until the SciBorg is just going straight. How soft is too soft, or how soft is soft enough, depends on the course and scenario.

Traveling 10 Feet:

In order to get our SciBorg to travel 10 feet and stop, Amy and I decided to use a stopwatch to record the time it took for the SciBorg to travel the desired distance. Once we had our data, we set the run time of the SciBorg to 12300 ms or 12.3seconds. After the 12300ms, the SciBorg's motors were set to 0.

During our first run, we initially set both motors to maximum speed, however the SciBorg started veering to the side. To fix this, we kept one motor at 255, but lowered the right motor to 245 because the SciBorg had been veering to the left. This did a pretty good job at fixing our veering problem, but the SciBorg still ended up stopping 8 inches short of the 10 feet mark.

A video of our SciBorg running the above code

Arduino Introduction Part 2

During Tuesday's class, we continued to work on Arduinos. 

The first thing Jiaming and I had to do was to alter the code of our LED pattern that was created without the use of delays. We originally created it with multiple if/else statements under one umbrella if/else statement, but Amy wanted us to make it so that the lights blinked independently of one another – controlled by different time commands.

This assignment took us the longest out of all the Arduino programs we've been working on. The crux of the problem was to realize that we would need three separate time keeping commands – one for each LED. It's sort of like having three different stopwatches going at the same time. Each stopwatch works independently from one other, so that each LED can work independently from one another.

For our next assignment, we learned about photocells. Photocells are these pretty interesting resistors that adjust their resistance based on the amount of light hitting its sensor. In order to use photocells in our circuit, we first need to get an idea of the numerical values they relayed based on varying amounts of light. Using a code that included a few print lines and the help of the Serial Monitor tool, we were able to figure out the values that corresponded to: very bright (flashlight shined on photocell), bright(normal classroom white light), dim(hovering hand above photocell), and dark(covering the photocell completely). We did our calibrations with two different resistors in the circuit in series with the photocell, the 1k and the 10 k.

 

Once we calibrated values for the photocell, we had to create a LED pattern with it. We were given a lot of leeway in this assignment, since we were given the choice of deciding what we wanted our photo cell to control. Jiaming and I decided to have the light level of the LED determine a specific light pattern. If the photocell has a flashlight shining on it, then all three LEDs will turn on then off. If the photocell is in normal light, then there will be a LED pattern in which the LEDs will cycle through a pattern of having only two LEDs on at a time. If the photocell is under dim lighting, the LEDs will turn on and then off sequentially. If the photocell is in dark lighting, then the LEDs will cycle through a pattern of the 1st and 3rd turning on and then off while the 2nd turns on.

 

 

 

For the next assignment, we learned how to use a button to turn on a LED. When we pushed the button, it would complete the circuit and power kPinLed, which the LED was connected to.

The next thing we needed to do was to learn about servos. To get started we downloaded the templates of sweep and knob to get started. After we got an understanding of what the code did, we then had to alter the knob code so that it would only rotate the servo from 60 to 120 degrees.

 

Reflections:

Today's assignments were devoted mainly to learning about the various things we can power/use with the Arduino.  We learned how to use photocells, push buttons, and servos. I actually really like working with the photosensor – although, I do have to mention that the first time around, we accidentally plugged the photosensor in backwards, so the numbers were flipped. Regardless, I'm excited for when we get to use the photosensor in a project. The button assignment was pretty straightforward and I'm pretty curious as to how we'll use the servo in a project.

I'm still adjusting to the coding terminology in Arduino, but it's not too much of a problem. The hardest part is definitely figuring out how the stuff on the breadboard connects to what's written in the program. The setup portion of the code isn't difficult now because it's just given to us, but I imagine that if I had to start from a blank code, I would definitely be very confused. I'm at the point in which I can understand what's happening in the code, but would struggle to create my own setup code.

All in all, I'm having fun exploring the use of Arduinos and am looking forward to learning more about its applications!

Arduino Introduction

On Friday, we learned about the basic uses of the Arduino microcontroller, which used aspects of both electronics and computer science. My partner, Jiaming, and I have a little experience with both of these topics since we're both currently in PHY 108, where we're currently working on circuits and often use Python for physics animations. Python isn't exactly the same as the C++ that the Arduino, but the way of thinking necessary for computer science is similar.

Potentiometer

Tools we used:

breadboard – where we build
our circuits

resistors

LED – Light Emitting Diode

Applications:

• For the first project we started with a basic example program and had to figure out why a delay time of 10 leaves the light on constantly. Through this exercise, we learned that the time unit for the program is milliseconds and the delay of 10 ms is so small that the human eye can't register it, which is why it appears to be on continuously.

• For the second project, we had to create a blinking light pattern with at least three different lights, while using the delay function. We chose a pretty simple pattern, but it could easy made longer and more complicated by altering delay times and adding in more on/off commands.

• For the third project, we turned the difficulty up a notch; we had to use the potentiometer to change the delay time of a blinking LED. A potentiometer has fluctuating resistance that is dependent on the degree of rotation of a nob. It makes changing values like delay times, in this exercise, really easy. Potentiometers are really useful tools!

• For the fourth project, we had to figure out a way to create a 3 LED light pattern without the use of the delay function. Instead, we used multiple if - else statements to accomplish the task. This was definitely the hardest of the four tests. This activity definitely taught us the importance of careful bracket placement. We accidentally left the time update code outside of the while loop which created quite a predicament.

Reflections:
Learning how to use the Arduino wasn't extremely difficult. The circuitry wasn't very difficult although it took some adjusting to get use to the non bread board part of the circuit. The programming portion is very similar to the C++ that I learned previously in high school, so for me it was less of learning something completely new and instead, learning new conventions for things I've learned previously. That being said, this is just day one with Arduinos and I anticipate the programming portion getting a lot more difficult. Things that I struggled with was definitely the little things – making sure the program is set to the correct port, spelling words correctly, putting the brackets in the correct place, and the ever pesky semicolons.

Lego Racecar

For this project we learned how to use gear drives and were tasked with building a lego racer that would compete in a 4 meter dash. The lego racer is powered by a single motor with high speed, but low torque and has to carry a 1.0kg weight across the finish line.

My partner, Katrina, and I started by creating random gear train ratios to get an idea of what would be appropriate for our racer. Here are some examples of gear trains that we built and tested.

1:25
24:40 , 8:40 , 40:24 , 8:40

1-9
8:24 , 8:40 , 40:24

1:125
8:40 , 8:40 , 8:40

1-15
8:40 , 8:40 , 40:24

Once we made a few options, we went ahead to build the rest of the car, so we could begin testing out the ratios. Katrina focused on figuring out where to put the wheels and where to put the motor and PicoCricket. We originally felt that we would need a way to keep the weight from rolling off and given a weight that would sit flat, we decided to build a sort of container to put it in, so that it would be able to attach to the rest of the cart.

Katrina is troubleshooting
the motor

Regarding the wheels, we decided to use three wheels instead of four thinking that less wheels would mean less friction with the ground, especially since the motor was only driving the front wheels. For the front wheels, we decided to use the biggest wheels we had available because that meant that for one rotation, the wheel with the larger circumference would travel a farther distance. The back wheel, whose only real purpose is for support, we decided to used the smallest wheels available to use because a smaller wheel yields less friction.

Our first iteration:
The Tank (1:125)

Here's the structure that
I worked on

Our first iteration using a 1:125 gear ratio was a flop. It took the lego racer about 40 seconds to go from start to finish. As you can see from the picture, the lego racer looks quite formidable and would probably do better in a lego racer monster truck rally than in a competition for speed. So it was back to the drawing board for us.

We did a lot of testing and recorded times for the gear trains we built earlier and soon came to a conclusion that a 1:15 gear ratio would work to best. While the other gear ratios had higher torque, they didn't have enough speed. We needed to find the ratio that would allow the lego racer to have enough torque to move across the carpeted race cart, while maximizing speed and the 1:15 gear train do just that. It was also during these trials that we realized the less gears we used the better because each gear added, added on friction to the system.

We also realized that it would be in our best interests to make the cart thinner and move the wheels closer together. The further apart the wheels were from one another and the slower the cart would be. What we decided to do, in order to make the lego racer thinner, was to make parts of the gear train vertical, therefore preserving space. This would also allow us to drive both of the front wheels on one axil instead of two, which definitely helped to reduce gear friction.

Originally, we were hesitant to make the cart to tall because we were worried it would tip over more easily. However, we remember that since we are going along a straight course, height won't be a huge factor, now if this lego racer was taking laps in a circle, this might be something we want to consider.

We also decided to do away with the container we encased the weight in. Since we had two bigger wheels in the front and one small one in the back, by placing the weight in the front, gravity would keep the weight propped up. Therefore, we don't need the container that added a lot of weight to our cart (although it did look pretty cool...).

We struggled to to create a 1:15 gear ratio with just four gears because of spacing issues, so we ended up having to use six gears instead. This definitely added a bit more gear friction and slowed us down during the race.

Underside

Front view 

Our final iteration

Come race day our lego racer definitely wasn't the fastest clocking in around 12 seconds, but that was still a pretty big improvement from our first iteration. Given more time, we would definitely try to find a way to recreate the 1:15 gear ratio with only 4 gears. That is likely the leading cause of why we took so much longer than other teams. From there, we would then also consider ways to minimize the weight on the cart, but the gear train would definitely be the priority.