Sciborg, Day 2

In class on Tuesday (3/10), we made our sciborgs functional and ran basic programs to explore basic ranges of motion. Day 2 focused upon the sensors built into our sciborgs.

The first challenge was to run Bricktronic's "motor button" sketch and understand it. To do so, we had to attach a NXT touch sensor to our sciborg.
Here is the example sketch:

We noticed two delays. These delays contribute to the "debounce" concept. Debounce here means to double check that the button is depressed before continuing some command. There is a very small delay between checks. Otherwise, the sensor could be counting it as two or more separate presses.

We then created a program that has the sciborg run forward until the touch sensor is pressed, then backs up and turns and continues forward.


We began all components, and set the speed of motor 1 to be slightly slower than the speed of motor 2 (to counteract the tendency of the sciborg to track left). We kept the debounce part of the code.

Next, we told the speed of both motors to be the negative of their previous speeds (by multiplying by -1). This caused the sciborg to move backward for 1 second.

Next, we set the speed of motor 1 to be the same as its previous speed (multiplying by 1), which means it was still moving backward. The speed of motor 2 was set to be the negative of its previous speed (going forward by multiplying by -1). This occurs for half a second.

After, both motors turn forward. This is enabled by multiplying motor 1's speed by -1 and keeping motor 2's previous speed.

The loop then repeats.

Encoder:

We began by running the example code.

This code incorporates encoders, which count how many times the shaft rotates inside the lego motors. Information is relayed in the serial print box. X begins at 0, for no axle rotations.

The sciborg is instructed to move forward at 50 power for x, which is the variable representing the rotations of the axle. The sciborg moves forward for x<200. The encoder "get_pos," or, gets its current position after every 10ms of traveling. It prints "Now I'm at" with the current position, which is equated to the position it recorded before. It then modifies x to equal x+1, which pushes the x count to be greater than 200. This causes the next command to be true.

The next command is a while command which accounts for movement in response to x being greater than 200 but smaller than 400. When this condition is originally true, the motor moves back at the same speed (the negative of the original power). The position is then recorded every 10ms and printed. When x=x+1 is no longer in the second while loop, the motor stops.

The end value isn't zero because of the interval with which the motor checks itself. The motor may reach 0 an extremely small amount of time after a check, and then have to wait the remainder of the 10ms to check again and process to stop. This could be compounded with over rotation in the going forward command.







Touch Switch:
Our next goal was to use the touch switch sample code to light a connected LED when pressed.

Sample code:


Running this program, we noted that the LED stayed on even after the button was released. We then modified the program to turn the LED off when the button was not pressed. (See comments)



Ultrasonic Sensor:
Our final goal was to incorporate the ultrasonic sensor into our sciborg. The sensor emits high pitched sounds and measures distance from objects by recording the amount of time it takes for the emitted sound to bounce back.

Sample code:
Serial data was transmitted at 9600 baud.

A variable integer "value" is recorded by the ultrasonic sensor "kPin_ultra" through an "analogRead" command.

In serial print, the Arduino prints "Analog Reading =" and sets it equal to the value read by the sensor.

We modified the delay to be half a second so we could follow and process the data as it was coming in to the serial print box.




A sample of our readings from the ultrasonic sensor. The value increases because we began by holding a relatively inflexible sheet of plastic before the sensor and gradually moving it away. This makes sense because the value is the time it takes for the sound to bounce back and reach the sensor once more.

We must be aware that objects in the periphery of the sensor can interfere with the readings to some large degree, depending on the distance from the sensor and the angle it's at relative to the projection of the sound.