Arduino Day 3 & 4

Day 2

When I walked in class on Tuesday, I was certainly impressed by the Sciborgs in our classroom. I was, again, very excited, to transform the codes what we have learned from last week into something more visible and practical.

Before we started with Sciborg, we learned another language for coding more concisely, which is function. Function stores a certain set of commands in a function and thus shortens the code when the set of commands needs to be repeated in loop. Here is the code for making SOS signal from LED's.

In this case, we avoided writing "dot()" and "dash()" repeatedly in void loop().

Before we started programming for Sciborg, we had to learn how to solder. Soldering is essentially connecting wires with an alloy wire containing mostly lead, which has a low melting point. We soldered the two wires from the battery box to a plug for the Arduino shield. One of the wires was covered by a plastic tube that shrinks from the heat. (The material expand axially so that it shrinks radially.) This is to prevent that two unseparated wires would cause a short in the circuit. The screws in the battery box were also taped to prevent shorts.

The first program we ran in Arduino was a single motor code. This allows one motor of the Sciborg to start working. Since the Sciborg has two wheels powered by two motors, we then modified the code to allow both motors to work at the same time.

Double motor, same speed

We did a test on the motor to see the minimum speed it requires to get the Sciborg moving. The results vary, but overall the Sciborg would start moving when the speed is above 50. The next step was to make the Sciborg turn. This is not hard to implement. The Sciborg would turn if the two wheels are moving at different speeds, because this implies that the wheels will travel for a different amount of distance in the same time period (d=v*t). We made the left wheel move at speed 255 and the right move at speed -255. In general, the smaller the difference between the speeds of the two wheels is, the gentler the turn.

At this point, it was clear that the Sciborg does not drive straight. I suspect that there are multiple reasons. First is that the free wheel is not completely frictionless. As a result, a slightly different positioning of the front wheel will cause the Sciborg to deviate from the original route. The center of weight of the lego structure is also not aligned at the center of the structure, causing the car not to move straight. I suspect that the motor may also differ slightly. The best we could do was to adjust the speed to 235 in the left wheel and 255 in the right wheel. We also made the motored wheels the back wheels. However, the Sciborg still shifts variously each time we let it run.

Anyhow, since the Sciborg does not move in a certain direction consistently, it was rather hard to estimate a time for which the Sciborg would stop after 10 ft. We made the time at around 10 seconds, and the Sciborg would stop near the finish line within +/- .5 ft.

The next step is to use a touch sensor. We have a touch sensor at the end of the motored wheels. As a result, the motored wheels must be in the front. In the program for touch sensor, there are two delays. This is to allow the program to debounce. Normally, the metal in the sensor may send multiple signals if there is a slight change. However, having the delay allows the program to debounce, which receives and processes the very first signal as opposed to all sequential signals. Here is our code which makes the Sciborg back off and turn and then continue when the touch sensor is activated.

Note that we have been through some modifications. We wanted the Sciborg to only turn slightly, so we initially used speed1*=-1.5 and speed2*=-1 as our turning speed. It turned out that as the loop goes through over and over, the speeds would multiply itself and thus the Sciborg did not act consistently. It turned out that the "=" updates the speed to the new result, which is something we were not aware of. We thus changed the modification to -1 and 1 but make the delay time shorter, so that the Sciborg would not turn as much. Here is the result.

Day 4

Today we started with Encoders. The encoder is a sensor in the motor that records how many times the shaft has rotated. Here is the code.

This basically makes the car go forward for 200 counts and backward for 400 counts, and records the turn of shaft at the same time. Note that we only used one motor in this case, which means that only one wheel was motored. The recording starts at 0, because the shaft does not turn. If physics worked perfectly, the recording should also end at 0. However, this was not true in our case. I suspect that the Sciborg starts in a still state, but when the Sciborg changes the direction it moves, it starts in a moving state. As a result, the momentum and speed would be different, causing the distance traveled to be different. The friction and other elements that control how much and how easily the Sciborg moves may also differ when the motored wheels change from the back wheels to the front wheels.

The second project requires us to use the sensor at the end of the free wheel. The sensor controls the LED light attached to the Arduino. We wrote a code so that the LED would turn on when the sensor is pressed down and would be off otherwise.

If the else statement was deleted, the LED would stay on forever after the sensor is pressed. This is because there is no command that tells the LED to turn off.

Now the last project we worked with was the Ultrasonic sensor. Here is the code.

Note that here, the sensor detects the object every half second. The closer the object is, the smaller the Analog reading is.