Arduino and Bricktronics, Day 3

     

Last week, we began to connect various sensors to our Arduino and learned how to modify the programs associated with them to perform certain tasks. I previewed the LED-photocell task in my last blog post. As you can see, the photocell detects the brightness of the light it is exposed to, translates it into a number, and uses the number to vary the degree of turn in the servo and the speed with which the LED light flashes. Ours processed each reading and associated 3 flashes of light per reading, the time variance between each flash being high when the reading was dim. Below is our program for this task.
   

 We began by telling the Arduino that the Servo is involved with the program by the command "include." We named four integer variables. The setup incorporated 9600 baud as the serial data relaying rate, and attached the servo to terminal 9 of the Arduino and also designated terminal 12 the output.

Our loop began by focusing on the readings by the photocell. The reading (recorded by the command "analogRead(A0)" was temporarily set at the variable "value." The serial mode prints the text "analog reading =" and then next to it the value recorded by the photocell. We then used an "if / else if" command to designate certain number readings to a type of brightness, which were then listed next to the value recorded in serial mode. For example, a value of less than 200 reads as "dark" and a value of 800 (but greater than 600) reads as "light."


Next, the loop stores variable val1, which takes the value recorded by the photocell and converts it into a 0 to 180 degree scale. "Servo.write(val1)" then uses this converted value to rotate the servo motor by that amount.

The loop then stores val2, which takes 50 seconds divided by the value measured by the photocell. We chose 50 seconds because the photocell value has a range of 0 to 1000. Therefore by division, the longest period would be at a maximum of 5 seconds. We then said "for" x=0, x<=2, and x+=1 (setting the times the LED would flash at 3 specified intervals) that the LED connected to pin 12 would go on (high) for a time period of val2 and then off (low) for a time period of val2. If "value" was low, then val2 is high, increasing the delay between flashes and causing the LED to blink slower. There was a delay of 0.5 seconds and a command to set x to zero again before repeating the loop.

The next task was to type a SOS-LED code. Instead of directly writing the code with multiple "digitalWrite" commands and "delays," we learned how functions worked.

     
We first wrote the loop, featuring three dot functions, three dash functions, and three dot functions with a 3 second delay before repeating.

We then defined the dot function by the familiar "digitalWrite" and "delay" commands, and similarly defined the dash function.

We ran the program, which used our dot and dash functions to implement the SOS code in LED light flashes.










After these final exercises with the Arduino, we were introduced to sciborgs and the Bricktronics technology.

Our first steps included the construction of our sciborg. We learned how to solder, and used the technique to complete our battery pack apparatus. We fixed our Arduino and breadboard to the wooden platform with the battery pack underneath, and installed the Bricktronics shield directly above the Arduino. We then connected the two motors underneath to the shield via NXT cables.

Our first task was to use the Single Motor Bricktronics program to see what it did.



Here, we saw the Arduino program use the NXT wire and the Bricktronics shield via the "include" command. We also saw that "Motor m" was defined through a Bricktronics port. The motor and Bricktronics shield begin, and the serial recorder shows an introductory message. The loop uses a "while" command, stating that if everything inside is "true" then the loop will continue to run. True is always true, so the loop runs continuously. As the motor rotates forward at a scaled power output of 75, "going forward" is printed in the serial box. This occurs for 1 second, then the motor increases power output to 255, the maximum, for half a second. "Going in Reverse" is printed, and the motor turns in reverse, at 75 power for a second, and increases to -255 for half a second.

Many of these commands were unnecessary in the actual function of the motor. We simplified the program:

We then used this as the basis for our Double Motor program. 

Our comments show how we added another motor and allowed them both to run in the same speeds and directions at the same time. We then attempted to determine the minimum value for speed. We tried 0, and 1, but the sciborg would not move. We found that the minimum on the wooden tabletop was 49 speed. This is due to friction, which disables movement until a threshold is reached. 

Next, we made the sciborg execute hard turns. One wheel went full in reverse while the other went fully forward. 

Next up was to make the sciborg drive as close to 10' as possible. We worked on this while also trying to make the sciborg drive straight. 

We found that the vehicle tracked to the left before making any modifications. We decided to decrease the power of the left motor so that it turned more slowly and therefore kept pace with the right motor. We set the delay at 10 seconds and then told both motors to stop.