Team In Progress: Color Sensing Motor Control – Code

The code behind the project is fairly simple.

To establish communication between the Arduino and the color sensor, we sent register address and the byte value we want to write the magnetometer and loads the destination register with the value that was sent. To receive raw values, we send a register value address to a function and it will return the byte values for the magnetometer register’s content. Once the raw RGB values are read from their respective registers, they were converted into integers.


To determine the color being sensed, we compared the RGB values and found the color with the highest color value, then made that color the sensed color.


Once the color has been sensed, the Arduino sends out a character to the A3BU through UART.

The A3BU then takes the received character and adjusts the motor speed accordingly using Pulse Width Modulation.


Team 4.2 – Code Talk (The Hit new Talk Show starring Team 4.2)

First, the code driving it is fairly simple. The main initializes the board, the delays, and the IO ports. Then each pin that is being utilized in the project is set as either an input or output, depending on its functionality, with J1’s pins 0-2 being the input pins, J3 pins 0-2 and J2 pins 3-7 being the output pins for the LEDs. All the pins are then set to low, and the game starts. When the game starts, the input pins are enabled, and a while loop is entered:

//Waits until the player selects his option
else if(gpio_pin_is_high(J1_PIN2)==true)
else if(gpio_pin_is_high(J1_PIN1)==true)

As stated before, the pins that are referenced are the three input pins, corresponding to Rock, Paper, and Scissors respectively. This while loop stays active until one of the IO Pins are seen as being at a high logic value, and the corresponding selection is made for player 2, AKA the human player. (The first line of it where every pin is checked for being high was to combat some of the anomalies we had reached, and it was found that this did help filter some of them out.)

After the user inputs a value the pins for inputs are disabled, and the computer randomly selects a number between 1 and 3 for its selection.



After this a function is entered that lights up the selection LEDs by setting the corresponding pins as high for both the player and the computer for one second. Those pins are then set to low again, turning off the LEDs.

else if(player1selection==3 && player2selection==2)
//Set P1 P and C S

Next the code compares the computer and user selections to determine a winner, and the correct winner LED is lit up (if it is a tie then both of the red LEDs light up) for 3 seconds before turning off.

else if((player2selection==1&&player1selection==2)||(player2selection==2&&player1selection==3)||(player2selection==3&&player1selection==1))

The computer’s and player’s selections are then reset to 0, all the pins being used set to low again, and finally the function that runs the game is run again, repeating the process until the power is cut to the board. (There is currently no end state for the game. Ideally we would have wanted to implement another couple selection buttons to indicate if a person wanted to stop playing, but we did not have time to implement it. So for now, you’re stuck playing. FOREVER. Or until you walk away. Or cut the power. Or unwire something. Or punch it.)


Team ACM can see the Matrix. (or at least the tick count)

So here’s our codes detailing how we did things. This ticks the clock, checks if it needs to play a sound, and manages the sound it plays.

So one of the more… complicated things we ran into while programming this thing was being able to play the chime while keeping the clock ticking. The board didn’t have any multi-process support (unless we fancied writing our own scheduler), so we couldn’t just have it run both functions simultaneously. Instead, we got a bit more creative (desperate?) and made it so that while the clock is ticking, it is also checking to see if it should be playing a sound. See lines 30 and on for how we did this. We used ticks to count how long a note should play for (and for extending the DAAAAAAAAH at the end) The extension of the last note in particular was incredibly trying. We found that depending on the amount of ticks we told it to wait, the sound we continue (or not). However, the compiler did not like this solution. Any tick count below 55000 resulted in a short length, and any above 55000 resulted in a just too long length. BUT! adjusting the tick count for the length of the first three notes (which all play for the same amount of  time) would in fact actually basically adjust the play time accordingly! We stuck with the long one in the end, but still have no idea why the compiler couldn’t count correctly. Maybe, just maybe, it’s bad :p

  1.         //Run the clock
  2.         LED_Toggle(LED0);
  3.         struct pwm_config mypwm; //For PWM for speaker
  4.         uint16_t counter = 0; //Keep track of how long chime note has been playing
  5.         uint8_t playing = 0; //Keep track if our chime is playing
  6.         uint8_t chimeIndex = 0; //Keep track of position in Chime
  7.         uint16_t chime[4] = {440, 466, 493, 523};
  8.         while (true) {
  9.                 rtc_timestamp = rtc_get_time();
  10.                 // Update printed time if the time has changed
  11.                 if(rtc_timestamp != past_timestamp) {
  12.                         calendar_add_second_to_date(&date);
  13.                         LED_Toggle(LED0);
  14.                         LED_Toggle(LED1);
  15.                         drawNumber(secMSBColumn, date.second/10);
  16.                         drawNumber(secLSBColumn, date.second%10);
  17.                         drawNumber(minMSBColumn, date.minute/10);
  18.                         drawNumber(minLSBColumn, date.minute%10);
  19.                         drawNumber(hourMSBColumn, date.hour/10);
  20.                         drawNumber(hourLSBColumn, date.hour%10);
  21.                         //Make noises on quarter minutes
  22.                         if(date.second%15 == 0) {
  23.                                 playing = 1;
  24.                                 chimeIndex = 0;
  25.                                 pwm_init(&mypwm, PWM_TCC0, PWM_CH_A, chime[chimeIndex]);
  26.                                 pwm_start(&mypwm, 75);
  27.                         }
  28.                         past_timestamp = rtc_timestamp;
  29.                 }
  30.                 if(playing) {
  31.                         counter++;
  32.                         if(chimeIndex < (uint8_t) 3) {
  33.                                 if(counter%50000 == 0) {
  34.                                         chimeIndex++;
  35.                                         counter = (uint16_t)0;
  36.                                         pwm_set_frequency(&mypwm, chime[chimeIndex]);
  37.                                         pwm_start(&mypwm, 75);
  38.                                 }
  39.                         } else {
  40.                                 if(counter%70000 == 0) {
  41.                                         playing = (uint8_t) 0;
  42.                                         counter = (uint16_t) 0;
  43.                                         pwm_stop(&mypwm);
  44.                                 }
  45.                         }
  46.                 }
  47.         }

Theremin Coding

The code behind our project is fairly simple. Based on the voltage received from the distance sensor, we adjust the pitch of the buzzer. This allows one to move their hand up and down above the sensor and play ‘notes’.

The sensor uses sudden bursts of current, and this generates noise in the input voltage to the board. However, using a “simulated capacitor” in the code, we’re able to filter the noise out! Here’s the single line of code that does this:

filteredVoltage += ( inputVoltage – filteredVoltage )*0.02;

The filteredVoltage is the voltage we output to the buzzer. The way this works is that the filtered voltage is ramped up (like a capacitor) to the input voltage. Small spikes in the input voltage do not affect the output because of this.

How the Simon Game works

Here’s the circuit schematics for the Simon game’s input/output. We put four LEDs as output, and each LED was wired as an input as illustrated above. Transistors were used here for two reasons: we might have all four LEDs on at once, and transistors can handle all that current while the A3BU might not. Also, the LEDs from Adafruit ran on 12V, and the A3BU’s 3.3V would not light them. (We discovered that these LEDs have an integrated resistor, that’s why 12V doesn’t blow them up). The transistor can be connected to the ground side, and will switch fully on at 3.3V, completing the circuit through the LED to ground.

The project code is available at our github project repository.

Continue reading How the Simon Game works