Team 1!

Labs and Milestones

"Work Work Work Workwork Workworkworkworkwork" - Rihanna

Lab 1

Learning what soul-crushing disappointment is like

Lab 2

Fighting the good fight

Lab 3

Growing as a robot

Lab 4

Confusing madness for happiness

Milestone 1

False hope

Milestone 2

Existential crisis

Milestone 3

Renaissance robot

Milestone 4

Machiavellian ascension to power

Final Implemented Design

It's too late to go back now

Ethics Homework

Autonomous vehicles

Team Logistics

Here's how we got to know our way around an Arduino

Team Contract

All men need laws to govern themselves, or they are in danger of leading nasty, brutish, and short lives. Robots, on the other hand, need no such thing. But alas, we are mere mortals so here are some rules that we hold each other to.

Meet the Wonder Bot

Face your fears: a robot so advanced, so intelligent, so fearsome, that it can easily collapse nations and rip families apart at their seams.

Meeting Minutes

We spend a lot of time with each other. We even count the seconds! This is a log of every magical moment.

The Dream Team

Together, we are your worst nightmare

Evan Kravitz

esk95

Michael Solomentsev

mys29

Jeffrey Hurd

jjh353

Radhika Chinni

rpc222

Frances Koback

flk26

Katherine Lu

kl645

"Cause the players gonna play, play, play, play, play. And the haters gonna hate, hate, hate, hate, hate. - Taylor Swift

Milestone 2

Treasure Frequency Detection

Materials used:

breadboard
wires
phototransistor
resistors
capacitor
Arduino Uno
USB serial cable
oscilloscope
LM 358 operational amplifier
treasure

Analog circuit

We constructed an analog circuit and wrote Arduino code that detects specific frequencies.

The first stage of implementation was creating an analog circuit that would feed time-domain voltage data to the Arduino Uno. The raw voltage output from the phototransistor upon receiving incident IR radiation has a significant DC component and a relatively small voltage swing. Our goal was to have the Arduino recieve a voltage input between 0 and 5 volts, with large voltage swing. Simply feeding the phototransistor voltage through a noninverting amplifier would amplify the DC component, and render the output signal unusable. Thus, we had to essentially create a high-pass filter at the op-amp input, and then add a DC bias signal to the op-amp output to ensure that the voltage stays within the 0-5v range. We achieved this by constructing the following circuit:

C1 and R2 function as a high-filter to remove the input DC. The 2.5V DC source before R2 is intended to DC-bias the output votlage so that the Arduino can properly read the signal. The theoretical gain of the circuit is roughly 5.5K (1 + R3/R4), though the demonstrated gain is much lower. Note that the actual circuit embedded on the robot will use a voltage divider to implement the 2.5V DC source, not an actual DC voltage source.

Arduino code

When developing the Arduino code to detect frequencies, we wanted to ensure that we had robust code that can detect variable frequencies. We also wanted to reduce false-positive and false-negatives.

The code we developed first generates an array containing the amplitudes of the time-domain signal at frequencies related to the bin index. Afterwards, we call 3 functions that check to see if the given array encodes a 7 kHz, 12 kHz, or 17 kHz signal. Each of the functions for each frequency first computes the "expected bin" where the highest ampitude should be observed. The theory is that if a signal is indeed a 7 kHz, 12 kHz, or 17 kHz signal, then the FFT should have a peak at those frequencies. However, given the imprecision of treasure frequency, combined with the nonlinearities of the circuit, there could be small discrepancies in where the max peak for a given periodic is observed versus where it should be. To address this issue, the function, `detectedFrequency` finds the maximum value within a predefined `peakIndexWidth` of the expected peak. From inspecting the graphs of different signals, we deduced that the maximum amplitude always falls within ~5 bins of where it is expected to be (so the default value for `peakIndexWidth` equals 5). The function iterates through all the FFT values in the array that are within `peakIndexWidth` from the expected max bin. It finds the maximum value contained in this window of bins. The function then checks to see if this maximum value exceeds an absolute threshold, in order to ensure that random noise signals don't produce false positives. If the maximum value fails to exceed an absolute threshold, the function returns `false`, indicating that input signal does not encode a specific frequency. Next, the function checks to see if there are no other bins which contain a value as high as the computed maximum value in the bin window. We don't count bins less than 30, since these correspond to strong DC signals, which are always contained in the input. If the function finds other bins that have values which exceed the value around the expected peak, then the function returns `false`, indicating that the signal is not a periodid signal with the specified frequency. If the input FFT array passes all these checks, then we determine that the signal is a periodic signal of the specified frequency and return `true`. A `true` return value prompts the program to print the frequency value that it has detected.

We have included the code for this program below:


/*

fft_adc_serial.pde

guest openmusiclabs.com 7.7.14

example sketch for testing the fft library.

it takes in data on ADC0 (Analog0) and processes them

with the fft. the data is sent out over the serial

port at 115.2kb.

*/



#define LOG_OUT 1 // use the log output function

#define FFT_N 256 // set to 256 point fft

#include "printf.h"



long clockFreq = 16E6;

int divisionFactor = 32;

int conversionTime = 13;

int numSamples = 256;

float samplingFrequency = ((clockFreq/((float)divisionFactor))/conversionTime);

float binWidth = samplingFrequency/numSamples;



#include  // include the library



void setup() {

  Serial.begin(115200); // use the serial port

  TIMSK0 = 0; // turn off timer0 for lower jitter

  ADCSRA = 0xe5; // set the adc to free running mode

  ADMUX = 0x40; // use adc0

  DIDR0 = 0x01; // turn off the digital input for adc0

  pinMode(13, OUTPUT);

  printf_begin();
}




boolean detectedFrequency(float freqToDetect, char fftArray[]){

  int peakIndexWidth = 5;

  int absoluteMinThreshold = 80;

  int centralBinIndex = int ((float)freqToDetect)/((float)binWidth);

  int maximumMag = -1;

  for (int i = centralBinIndex-peakIndexWidth; i<= centralBinIndex+peakIndexWidth; i++){

    if (abs((int)fftArray[i])>maximumMag){

      maximumMag = abs((int)fftArray[i]);
    }
  }

  if (maximumMag<(absoluteMinThreshold){

    return false;
  }

  

  for (int i = 30; i
    if (abs((int)fftArray[i])>= maximumMag){

      return false;
    }

  }

  for (int i = centralBinIndex+peakIndexWidth+1; i<256; i++){

    if (abs((int)fftArray[i])>= maximumMag){

      return false;
    }
  }



  return true;



}




void loop() { 

  while(1) { // reduces jitter

    cli();  // UDRE interrupt slows this way down on arduino1.0

    for (int i = 0 ; i < 512 ; i += 2) { // save 256 samples

      while(!(ADCSRA & 0x10)); // wait for adc to be ready

      ADCSRA = 0xf5; // restart adc

      byte m = ADCL; // fetch adc data

      byte j = ADCH;

      int k = (j << 8) | m; // form into an int

      k -= 0x0200; // form into a signed int

      k <<= 6; // form into a 16b signed int

      fft_input[i] = k; // put real data into even bins

      fft_input[i+1] = 0; // set odd bins to 0


    }

    fft_window(); // window the data for better frequency response

    fft_reorder(); // reorder the data before doing the fft

    fft_run(); // process the data in the fft

    fft_mag_log(); // take the output of the fft

    sei();

  

    if (detectedFrequency(7E3, fft_log_out)){

     Serial.print("7kHz \n");


     
    }

     if (detectedFrequency(12E3, fft_log_out)){

     Serial.print("12kHz \n");
     

    }



   if (detectedFrequency(17E3, fft_log_out)){

     Serial.print("17kHz \n");
    }
  }
}

There's a lot of boilerplate code from the FFT libtary. The function we implemented was `detectedFrequency`. We also added the `if` statements at the end of the `loop` method.

Here's a video of Evan demonstrating the functionality of the circuit and Arduino code:

Distance Sensing

Materials used:

breadboard
wires
long distance sensor
short distance sensor
Arduino Uno
USB serial cable

For this milestone, we implemented distance sensing. We had two sensor options: long range and short range. We at first decided that we wanted to try to use a combination of both sensors, as the short range would detect walls up close and tell the robot to turn to avoid collision, and the long range would allow for faster mapping.

We tested the short range sensor first. We wired up a simple circuit consisting of the distance sensor and the Arduino and wrote simple code to display the values outputted from the distance sensor when the block of wood was located at different distances away. We recorded data for the short range sensor when the block of wood was located in 5 cm intervals from 5 cm to 35 cm away, within the range of the specifications of the sensor we found online. We found that the specifications for the short range sensor online were consistent with the data we recorded, a graph of which is shown below.

realized that the sensors were transmitting a signal in a wide cone and were therefore detecting objects around the room that were not relevant. This is the data we got from two subsequent trials for the long range sensors.

We decided that because the long range sensors were more unpredictable, and because we thought the short range sensors would be able to more accurately predict when the robot was approaching a wall, we would implement wall detection using short range sensors.

Our code for this is shown below:


    if (distanceValue > 100) {

      wall = true;

      servoL.write(90);

      servoR.write(90);

      delay(500);
    }    



Here is a brief video of the robot with the integrated distance sensor. As it approaches the wall, it turns at the closest junction.




    
    
      
        
          
            
              
            
          
          
            
              
                
                  
                  Milestone 3
                     Maze Simulation 
                      
                      For this part of the lab, we wanted to prototype the maze navigation algorithm that would later be implemented on the robot. In Java, we implemented a Depth-First-Search (DFS) algorithm for navigating through the maze. We chose a DFS algorithm for a couple reasons. Firstly, we know that it is possible to traverse all reachable parts of the maze with a DFS algorithm. Also, we figured that a DFS, in comparison to a breadth-first search, would require the least amount of "back-tracking". Our simulation results confirmed that the DFS does an efficient job at traversing the maze.  
                      
                      At a very basic level, a DFS essentially entails traversing as far as possible down unexplored parts of the maze until a dead end is reached, and then backtracking to the previous junction and exploring more unexplored regions of the maze. The implementation required some mechanism for keeping track of unexplored areas, as well as previously-traveled nodes to which to travel should the robot reach a dead end or a node in which every adjacent and reachable node has been visited. 
                      
                      
                      There are a couple of ways to implement this kind of algorithm. A recursive, tree-based approach can implement a DFS. The downside to this approach is that it is not an intuitive way of representing the maze, especially since the 2-d rectangular maze lends itself better to an array-based representation. The upside to this node is that it is quite easy to represent adjacent and reachable nodes, and the recursive structure of the maze lends itself well to a DFS algorithm.  
                      
                      
                      Another way to implement a DFS is with a 2-d array to represent the maze, and additional data structures to keep track of unexplored areas and areas the robot has visited. The advantage of this system is a more intuitive way of representing the maze (which also integrates quite well with other aspects of the project). The downside is that we have to store these additional data structures, as well as implement them. In the end, we chose to implement an array-based DFS algorithm. 
                      
                      
                      To keep track of previously visited nodes, we chose to utilize a Stack data structure. Recall that a stack allows for "pushing" items to the "top" of the stack, and then extracting elements in a last-in, first-out (LIFO) manner. This is precisely what we need for our algorithm, since we will need to return to the last visited node should the robot hit a dead end of simply not have any more unvisited nodes in its immediate surroundings. The ideal implementation of a stack allows for amortized constant time element extraction and appending. This is achieved in the Java implementation of a stack. 
                      
                      
                      To keep track of unexplored regions of the maze, we utilize a Set data structure. Recall that a set stores unique elements in an unordered fashion, and allows the user to check for set containment, remove items from the set, and add items to the set. This is ideal for keeping track of unexplored regions of the maze, since we only need to store 1 copy of each unexplored region, the underlying indexing of the unexplored regiion within the set is unimportant, and we need to constantly check the set for containment, as well as perform removals and add elements. The ideal implementation of a stack allows for amortized constant execution of all these tasks (via a Hash function). This is achieved in the Java implemention. 
                      
                      
                      To actually store the maze, we utitlized a two dimensional Java array. Java arrays—like arrays in most languages—allow for constant time element access, removal, and updating (via indexing). This makes it very efficient at representing the maze. Note that in a tree structure, we would not be able to access an arbitrary maze coordinate in constant time, since we would need to traverse through the tree. In addition to keeping track of regions of the maze that can be occupied by the robot, the array also had to keep track of all possible locations of walls. This meant that the size of the 2d array would not be 4x5 (corresponding to the dimensions of the maze), but 7x9, in order to account for possible locations of walls. Note that the odd index values correspond to possible locations of walls, with values at these locations corresponding to the presence or non-presence of a possible wall. Additionally, locations in the maze array for which both coordinates are odd do not represent actual robot locations or potential wall locations in the maze -- these are extraneous elements that will be ignored. 
                      
                      
                      For the DFS simulation, we needed to somehow represent what the "actual" maze looked like. We did this by creating an  actualMaze  array of equal dimensions that encoded the actual maze that the robot would be traversing. In order to maintain the integrity of the simulation, the algorithm is only able to view adjacent elements (walls or nonwalls/open spaces) in this maze (with respect to the current position of the robot).  
                      
                      
                      Here's a high-level representation of the DFS algorithm. Note that the implementation of these functions can be viewed in Github repository. 
                      
                      
                      public class MazeNavigator {

                      
                        String[][] actualMaze = new String[7][9];

                        String[][] maze = new String[7][9];

                        int[] currPos = new int[2];

                        HashSet frontierSet= new HashSet(); 

                        Deque visitedStack = new ArrayDeque(); 

                        JFrame frame = new JFrame(); 

                        MazeDrawer oldMaze;
                          

                          

                        public MazeNavigator() throws InterruptedException {

                        
                          resetMaze();

                          initializeCurrentPosition();

                          frontierSet.add(Arrays.toString(currPos));

                          initializeActualMaze();

                          visitedStack.push(currPos);

                          createJFrame();

                          displayActualMaze();

                          while (!frontierSet.isEmpty()){

                          
                            updateJFrame();

                            Thread.sleep(500);

                            maze[currPos[0]][currPos[1]] = "Explored"; 

                            removeCurrentPosFromFrontier();

                            ArrayList reachableCells = getReachableCellsAndAddWalls(); 

                            addUnvisitedSurroundingNodesToFrontier(reachableCells); 

                            updateCurrPosAndVisitedSet(reachableCells); 

                            if (!frontierSet.isEmpty()){ 

                            
                              reachableCells = getReachableCellsAndAddWalls(); 

                              addUnvisitedSurroundingNodesToFrontier(reachableCells); 

                              updateJFrame(); 

                              
                            }




                          }

                          printDone();

                        
                      }

                      

                      
                      The class begins by instantiating the two arrays that will be used to represent the maze as it actually is ( actualMaze), and the maze as the robot currently sees it ( maze ). We then create an  int  array to store the current position of the robot. Next, we instantiate the  frontierSet  and  visitedStack  to keep track of the frontier (unvisited) nodes and visited nodes, respectively. Two additional objects are instantiated to be used in the Java Gui. The graphics implementation will not be comprehensively discussed in this report, but the code can be viewed on Github.  

                      
                      Inside the instance method, we call the  resetMaze()  to reset the maze that the robot will populate with data as it travels through the maze. Next, the  initializeCurrentPosition()  is called, which assigns the initial location of the robot. The current position is added to   frontierSet . Note that equality for arrays is determined not by the values at each cell, but by the object reference. Due to this, we cannot simply store arrays of current location in the HashSet, since we need the HashSet to recognize two distinct arrays with the same elements as equivalent. We didn't feel like creating a new object to store the current location, and overriding the equals method, so we instead just converted the array to String form. The String literals can be properly checked for equality, so that two arrays with the same element values—which Java by default views as distinct—would be viewed as equivalent when represented as Strings. We also need to initialize the array that represents the actual maze. Inside this method body, the user can define an arbitrary maze for the robot to navigate. We then add the current position to the  visitedStack . Note that we don't need to convert to a String form since we never need to check for equality among members of the Stack (we just need to add to the top, and remove from the top of the stack). The  displayActualMaze()  method is called, which displays the current maze contents to the GUI. 
                      
                      
                      The DFS is continually run so long as the robot knows that there are nodes that have been unvisited. This is what the  while  loop condition essentially entails. So while there are still unvisited nodes, we first update the GUI ( updateJFrame() ). Since we want to see the robot "traverse" the maze, we add a time delay of 500 milliseconds. We have chosen to store information about different maze locations as Strings, though this can be an Enum or another object. In Arduino, we will end up using Chars, as this is a lightweight data structure.  We update the current location to be "Explored" to reflect the fact that the robot has visited this spot. Next, we remove the current position from the  frontierSet . Next, we generate a list of cells that are reachable from the current location. The robot finds all walls that are immediately adjacent to it and writes wall values to its maze array, and if there's no wall in a possible wall location, adds the open cell on the other side of the nonexistent wall spot to an array of reachable cells to be returned.  The code then adds unvisited surrounding nodes to the  frontierSet . Afterwards, the program finds where it should move next and updates  visitedStack , as needed. This method is at the crux of the DFS. Essentially, if it finds a reachable node in its immediate surroundings that hasn't been visited yet, it will move to this node. If all the reachable nodes have been visited (or if there aren't any reachable nodes), it pops from  visitedStack  and moves to this node. The final  if  statement only applies if the robot finishes traversing the maze (there are no more nodes in  frontierSet ). If the robot has reached all the reachable nodes in the maze, then it takes note of the walls in its surroundings, and writes this to the maze array. Finally, the  printDone  method is called, which prints "DONE" to the GUI to signify that the maze traversal is complete. 

                      
 Implementing this algorithm in Arduino 

                      
                      There are important considerations to keep in mind as we implement this algorithm in Arduino. Most importantly, we have severe memory restrictions in Arduino. We won't have the luxury of using memory-intensive objects to store maze data. This means that instead of using Strings and integers, which take several bytes to encode, we will likely just use Char's, which are encoded in 1 byte. We will also have to deal with the fact that Arduino doesn't come with Stacks or Set data structures, so we will have to either import an external library that implements these objects, or create our own implementation. Another thing to keep in mind is how the robot will detect its surroundings. It won't simply check values in an array. Instead, it will only be able to tell if there's a wall right next to it. We will have to create a system for translating the presence of walls next to the robot into coordinates in the maze. 

                       Video of simulation 
                       


                  Physical Implementation
                    Moving out of the realm of simulation, our team needed to put in a lot of work to properly get our robot 
                    to navigate the maze. First, we had to install our new line sensors and reimplement line sensing and turning.
                    Next, we had to install and calibrate our wall sensors. Finally, we had to integrate the entire system and 
                    implement a high-level state machine to control the robot and navigate the maze. 

                    Lines!
                    Anyone who has followed our group closely has certainly understood that we have had our fair share of 
                    struggles implementing line following. Our line sensors have always seemed a bit wonky, and our servos never
                    seemed to move in a sensible fashion. We implemented fairly hacky, non-resilient solutions to the line 
                    following/turning milestones. We decided that a solid way to move forward would be to buy a 'better' line 
                    sensor online. We turned to the Pololu QTR-3RC Reflectance Sensor Array. This particular device presented 
                    a better alternative to our existing sensors in a variety of ways: First, it integrated three sensors in one 
                    board, perfectly positioned to follow the black tape; second, it used digital connections, reducing the 
                    burden on our analog pins; third, it had an existing Arduino library. We settled on final PID control values of KP = 0.1 and KD = 0.3

                    Because of the aforementioned library, integrating our existing line sensing code was extremely simple. 
                    We replaced our simple analog reads with the library's sensor read methods. We also used Pololu's calibration
                    and PID control code to augment our line following. We continued using our funky servo calibration values
                    for turning. It was a straightforward and successful process, that lead to a consistent line following and turning process.

                    Wall Sensing
                    This was mainly just a physical task. We basically dissassembled our robot fully in order to mount two more line sensors. We took this opportunity to clean up wiring and make our robot more visually appealing. We had a bit of an issue getting wall sensing to work properly, but it turns out that we just needed to redo our soldering. Check out this photo!

                     


                    Integration
                    Since this was a complicated milestone, we spent a lot of time organizing our code, preparing for integration. Beginning this milestone, our code for each module (wall detection, line sensing, treasure detection, etc.) were all in separate files. We now have a structure for our final robot code. We created a high level finite state machine, which identifies which state the robot is in (between junctions, at a junction, just starting out). Each state corresponds to different behaviors and interfaces between different modules. Here is the basic state machine:
                    
                    //JUNCTION state: detects walls and treasures, chooses next direction to move

                    if (state == JUNCTION) {

                    

                      stop();

                      detectWalls();

                    

                      if (!wallRight){

                          turnRight();

                          stop();

                      }

                      else if (!wallLeft) {

                          turnLeft();

                          stop();

                      }

                      else if (wallRight && wallMid && wallLeft) {

                        turnRight();

                        stop():

                        turnRight();

                        stop();

                      }

                      else {

                          turnRight();

                          stop();

                      }

                      state = BETWEEN;

                    }

                    //BETWEEN state: follows a line until it reaches the next junction

                    if (state == BETWEEN) {

                      Serial.println("BETWEEN");

                      position = qtrrc.readLine(sensors);

                      error = position - 1000;

                      junction();

                      if (isJunction) {

                        state == JUNCTION;
                      }

                      else  {

                      goStraight();
                      }

                    }

                    
                    //DONE state: robot has completed task

                    //TODO

                    }

                  


                  Before we implemented maze following, we spent time unit testing and making sure that the robot could move and navigate and detect walls (essentially reimplementing milestones 1 and 2). This proved to be a much more difficult task then first expected.

                  The first major integration challenge we faced was ensuring that line following continued to work. When we added all of the different code blocks together, there was a sudden change to the quality of our line following. Suddenly, the robot began to oscillate around the line much more - most worryingly, changing our PID control variables impacted it even more negatively. We hypothesized that this behavior was caused not by suboptimal PID control values, but by a multitude of print statements and excess code which delayed the PID control algorithm. As a result, the PWM control signal was updated less frequently and the robot moved jerkily. When we removed the majority of our prints statements, line following went back to working well.

                  Second, we struggled to implement wall sensing. Our first issue was that the wires from the IR sensor were stranded, and Michael's soldering job simply wasn't good enough (Michael is writing this, by the way). Once he (I) resoldered it, two out of the three sensors worked perfectly. However, a third sensor simply was not working, and we could not identify a hardware issue. After consulting with a TA, we commented out all FFT related code, and the wall sensor began to work. We believe that the FFT code has some sort of dependancy on the analog pin the wall sensor was on. We plan to resolve this issue once we need to.

                  Our third (extremely frustrating) issue was that of turning. The FSM was written on the assumption that the robot would stop at a junction - do measurements - and then turn. However our turning code did not operate in that manner: It instead detected a junction, moved forward more, then turned. This implementation was developed based on a lot of trial and error, and had the most consistent turn behavior. We had to reconcile these two turning implementations in order to get our robot to navigate the maze. You can look at the FSM code above to see our current implementation. We decided to have the junction state represent a true junction. At that point the robot pauses, detects walls around it, and then moves away. However, in order to make turning work, it moves forward first, then makes the turn. Each of the movement functions have a built in delay. This ensures that turns happen correctly.

                  Here is our robot using all of the above to move through a maze:

                 

                  As you could tell by the cheering in the background, this was the tenth time the robot succeeded its navigation in a row.
                  In order to fix the inconsistencies in the above turning behavior, we changed our robot and our algorithm. We added an additional line sensor, mounted beneath the rest of the robot. We attached it directly to an analog pin (we anticipate making a Schmitt trigger so that we can move it to a digital pin). We altered the junction detection code so that a junction was detected once the back sensor hit the tape. We then altered the turning code so that a turn ended once the back sensor hit the black tape again. This created a much more robust turning behavior.

                  
                  if (state == BETWEEN) {

                  while(analogRead(A0)>700 && sameJunct){ 

                        goStraight();

                      }

                      sameJunct = false;

                      digitalWrite(13, LOW);

                      

                      position = qtrrc.readLine(sensors);

                      junkSensor = analogRead(A0);

                      

                      error = position - 1000;

                      junction();

                      if (isJunction) {

                        state = JUNCTION;

                        digitalWrite(13, HIGH);

                      }

                      else  {

                        goStraight();

                      }

                    }

                  
                  
                  After implementing the above, and playing around with our servo turn values a bit more, we created a robust turning and wall detection implementation. Here's a video of this implementation:
                  

                  

                  We still need to work out some kinks with left turns, but we are able to navigate the maze! In the future, we will work to implement a more comprehensive maze mapping behavior, which we did not do in this iteration.
                  
                
              
            
          
        
      
    

    
    
      
        
          
            
              
            
          
          
            
              
                
                  
                  Milestone 4
                  Robot Rebuilding & Physical updates
                    Much of our time working on this milestone was spent making substantial changes to the robot's wiring and structure. We identified a multitude of needs that needed to be addressed through hardware, including:
                      -poor power supply connections;
                      -an analog line sensor which had to move to a digital pin;
                      -a fail-safe start button;
                      -wiring up our IR phototransistors and their amplifiers; and 
                      -wiring up our microphone.

                    We began dealing with these issues by working on a new protoboard. This protoboard would include a new set of power rails, as well as a manual start button and a Schmitt trigger for the back line sensor. We designed the Schmitt trigger to go high at 4V, and go low and 3V, thus making it easy for us to read whether the line sensor was over white or black (see the schematic below). Our manual reset button is just a button wired between 5V and a digital input pin with a pull-down resistor to ground. We put two power rails on either side of the protoboard for ease of wiring. This ended up being a huge issue, because we used some pretty terrible header pins. In order to actually get stable connections, we needed to solder the connections. See below for pictures of the protoboard and the Schmitt trigger diagram.

                     

                    R1=10kΩ, R2=50kΩ, R3=25kΩ, R4=50kΩ

                     


                    The functioning Schmitt trigger output

                     


                    We decided to put our treasure detection and microphone circuitry on a PCB. We used the schematics developed in Lab 2 and Milestone 3 for the microphone and IR sensors respectively. We assigned pin A0 to the microphone, A1 to be the right IR sensor, and A2 to the left IR sensor. The PCB came out really well, as you can see the schematic and final product below.

                     

                
                     


                     During this whole process, we made sweeping changes to our robot and its wiring, ultimately making it cleaner and easier to work with. See the below image:

                     



                   Start Detection 

                  
                  Since we already had all the hardware components attached, we decided to implement start detection on the robot. First, we worked on the manual start with a button. Our first issue was that the button would write "HIGH" frequently when the button was not actually pressed. However, once we grounded the button correctly with a pull-down resistor, this problem was remedied. Next, we tried implementing the FFT to detect the 660 Hz signal. In order to take up less memory, we changed the FFT from a 256-point FFT to a 128-point FFT. With the lower number of samples, we were still able to accurately detect a 660 Hz tone by checking the 10th bin on the FFT. We created two functions called  detectButton() and detectStart(), which when called, checks the button and the microphone respectively, and returns true only if the button is pressed or the 660 Hz tone is being played.
                  
                  
                  Finally, we implemented our  detectButton()  and  detectStart() code with the rest of our DFS. While, the button code integrated relatively easily, we had trouble including the microphone code due to the nature of the FFT process. There were two problematic lines of code in our FFT algorithm. We were writing TIMSK0 = 0 which turns off timer0 for lower jitter and ADMUX = 0x40 which uses adc0. This caused problems with our delays, which were dependent on the timer, and our wall sensing which needed the analog-to-digital converter. In order to resolve this issue, we saved the settings for these registers in a local variable at the beginning of the FFT algorithm, then wrote to the registers in the regular fashion. Then, after the FFT was calculated, we wrote back the saved register settings so it did not interfere with the rest of the code. Once this was fixed, we were able to implement start detection by using the following while loop at the beginning of our code:
                  
                  
  //start on 660 Hz Tone OR Button Press
   while(!startDFS) {
      set_motors(90,90);
      delay(25);
      startDFS = detectStart();
      startDFS |= detectButton();
  }


        


                    Treasure Detection  


                  
                  In a previous lab, our group was able to demonstrate that an analog circuit could be built, in addition to Arduino code, which would be able to detect different frequency treasures. In this lab, we took this a step further by demonstrating that this functionality can be achieved on our PCB, with multiple IR sensors, and within the framework of the existing Arduino code. One of the first challenges we faced was generating two FFTs—corresponding to the two photoresistors circuits mounted on the robot—and then deciding what treasure is present given the spectrum of both signals. We decided that in order to improve accuracy, we would take 30 frequency samples. In other words, each time the robot wanted to determine if a treasure was present in its vicinity, it would have to generate 30 unique FFTs for each IR sensor, corresponding to 30 time-domain samples of the input data for each sensor. We would identify the dominant frequency present in each sample in the same manner as in a previous lab. However, instead of simply returning what the frequency detected in a single voltage sample is, we would look at the frequencies that were most frequently represented among the 30 spectra. The Arduino code would determine that no treasure was in its immediate vicinity if no dominant IR frequency was dected for both sensors. The Arduino code would determine that a 7 kHz signal was present if one of the sensors detected a 7 Khz signal for most of its samples, and the other one detected no frequency for one of its samples, or vice-versa. A similar process was employed for 12 kHz and 17 Khz signals. This procedure ensures more reliable detection, with fewer false positives and false negatives. 
                  

                                    


                  Below is a video of the robot detecting frequencies. Although it is hard to read the serial messages, the integers 0,1,2,3 are printed out corresponding to no treasure, 7 kHz treasure, 12 kHz treasure, and 17 kHz treasure, respectively:
                  

                  
                  
                  

                  


               

                  DFS Integration

                     We had already developed a working  DFS algorithm in Java. There were a couple of important tasks that we had to take care of in order to have the robot perform the DFS. Firstly, we needed to keep track of the orientation of the robot with respect to the coordinate system of the array. This is important because we need some way to map relative wall values to actual elements in the array. Secondly, we needed to utilize data structures that are present in the standard Java SDK but not in Arduino. Fortunately, we were able to implement these functionalities. 


                    
 One of the ways in which we kept track of orientation involved adding a module called  generateNewDirection.  This module takes in two char inputs: one representing the current orientation of the robot, and one representing the displacement direction. Using these two inputs, this module would output the resultant direction. This was particularly useful in translating relative wall data from the robot into array indices, which was also used in determining reachable cells for a given robot location. Below is code that we developed that would achieve this functionality: 
                    
                      
                   char generateNewDirection(char currOrientation, char displacementOrientation){
  //go north
  if ((currOrientation==North && displacementOrientation==Straight) || //facing north, looking in front 
  (currOrientation==East && displacementOrientation==Left) || //facing east, looking left
  (currOrientation==South && displacementOrientation==Backwards) || // facing south, looking behind
  (currOrientation==West && displacementOrientation==Right)){ // facing west, looking right
    return North;
  }
  //go east
  if ((currOrientation==North && displacementOrientation==Right) || //facing north, looking right
  (currOrientation==East && displacementOrientation==Straight) || //facing east, looking in front
  (currOrientation==South && displacementOrientation==Left) || // facing south, looking left
  (currOrientation==West && displacementOrientation==Backwards)){ //facing west, looking behind
    return East;
  }
  //go south
  if ((currOrientation==North && displacementOrientation==Backwards) || //facing north, looking behind
  (currOrientation==East && displacementOrientation==Right) || //facing east, looking right
  (currOrientation==South && displacementOrientation==Straight) || // facing south, looking in front
  (currOrientation==West && displacementOrientation==Left)){ // facing west, looking left
    return South;
  }
  //go west
  if ((currOrientation==North && displacementOrientation==Left) || //facing north, looking left
  (currOrientation==East && displacementOrientation==Backwards) || //facing east, looking behind
  (currOrientation==South && displacementOrientation==Right) || // facing south, looking right
  (currOrientation==West && displacementOrientation==Straight)){ // facing west, looking in fornt
    return West;
  } 
  
}


                        
                    
                      
         We also had to calculate directions when deciding where the robot should turn after it updates its position in the array. To do this, we simply find the difference between the robots current position (the position the robot is being moved to) and the robots previous position. We use these values, in conjunction with the current orientation of the robot, to generate the next move the robot should make.

        
void updateMove(){
  
  int dx = (int)currPos[0] - (int)prevPos[0];
  int dy = (int)currPos[1] - (int)prevPos[1];
  if ((dx == 2 && currentOrientation==East) //displace east, facing east
     || (dy == -2 && currentOrientation==North) //displace north, facing north
     || (dx == -2 && currentOrientation==West) //displace west, facing west
     || (dy == 2 && currentOrientation==South)){      //displace south, facing south
        moveToPerform = Straight;
  }
  else if ((dy == 2  && currentOrientation==East) //displace south, facing east
     || (dx == -2 && currentOrientation==South) //displace west, facing south
     || (dy == -2 && currentOrientation==West) //displace north, facing west
     || (dx == 2 && currentOrientation==North)) //displace east, facing north
     {
        moveToPerform = Right;
  }
    else if ((dy == 2  && currentOrientation==North) //displace south, facing north
     || (dx == -2 && currentOrientation==East) //displace west, facing east
     || (dy == -2 && currentOrientation==South) //displace north, facing south
     || (dx == 2 && currentOrientation==West)) //displace east, facing west
     {
        moveToPerform = Backwards;
  }
    else if (dy ==0 && dx == 0){
      moveToPerform = Stop;
    }
  else{
    moveToPerform = Left;
  }

  

  

  
}


         

 The second major order of business was to create data structures that would have the functionality of a set and stack. For the stack, we simply imported an external stack library (https://playground.arduino.cc/Code/StackArray). For the set data structure, we created a 1 dimensional array of 20 elements that can handle all 20 possible elements that could theoretically be added to the frontier set. We were able to map the 2d indices of the reachable cells to integers from 1-20 (see code below). In this array, each element represents a single reachable cell. If a reachable cell is in the frontier set, the value corresponding to this cell in the array would be set to 1. If the cell is not in the frontier set, the value corresponding to this cell in the array would be set to 0. Below are the helper functions we created:


 boolean containsFrontier(char coordinate){
  if (frontier[coordinate-1] ==1){
    return true;
  }
  return false;
 }

 void addToFrontier(char coordinate){
  if (!containsFrontier(coordinate)){
    frontier[coordinate-1] = 1;
  }
 }

 void removeFromFrontier(char coordinate){
  frontier[coordinate-1] = 0;
 }

boolean frontierIsEmpty(){
  for (int i = 0; i<20; i++){
    if (frontier[i] == 1){
      return false;
    }
  }
  return true;
}




Here is how we map the 2d coordinates in the array corresponding to reachable cells to integers numbered 1-20, which are stored in the set:

 
 char convertCoordsToChar(char coodinateArray[]){
  if (coodinateArray[0]==1 && coodinateArray[1]==1){
    return (char) 1; 
  }
  if (coodinateArray[0]==3 && coodinateArray[1]==1 ){
    return (char) 2; 
  }
  if (coodinateArray[0]==5 && coodinateArray[1]==1 ){
    return (char) 3; 
  }
  if (coodinateArray[0]==7 && coodinateArray[1]==1 ){
    return (char) 4; 
  }
  if (coodinateArray[0]==1 && coodinateArray[1]==3 ){
    return (char) 5; 
  }
  if (coodinateArray[0]==3 && coodinateArray[1]==3 ){
    return (char) 6; 
  }
  if (coodinateArray[0]==5 && coodinateArray[1]==3 ){
    return (char) 7; 
  }
  if (coodinateArray[0]==7 && coodinateArray[1]==3 ){
    return (char) 8; 
  }
  if (coodinateArray[0]==1 && coodinateArray[1]==5 ){
    return (char) 9; 
  }
  if (coodinateArray[0]==3 && coodinateArray[1]==5 ){
    return (char) 10; 
  }
  if (coodinateArray[0]==5 && coodinateArray[1]==5 ){
    return (char) 11; 
  }
  if (coodinateArray[0]==7 && coodinateArray[1]==5 ){
    return (char) 12; 
  }
  if (coodinateArray[0]==1 && coodinateArray[1]==7 ){
    return (char) 13; 
  }
  if (coodinateArray[0]==3 && coodinateArray[1]==7 ){
    return (char) 14; 
  }
  if (coodinateArray[0]==5 && coodinateArray[1]==7 ){
    return (char) 15; 
  }
  if (coodinateArray[0]==7 && coodinateArray[1]==7 ){
    return (char) 16; 
  }
  if (coodinateArray[0]==1 && coodinateArray[1]==9 ){
    return (char) 17; 
  }
  if (coodinateArray[0]==3 && coodinateArray[1]==9 ){
    return (char) 18; 
  }
  if (coodinateArray[0]==5 && coodinateArray[1]==9 ){
    return (char) 19; 
  }
  if (coodinateArray[0]==7 && coodinateArray[1]==9 ){
    return (char) 20; 
  }
 }


                    

                     Note that this set data structure has constant time element retrieval, removal, and addition. It also takes constant time to check if the set is empty. This is excellent from a performance standpoint. 

 In simulation, we never had to worry about physically moving the robot from one cell to another. However, this is a critical consideration on the actual robot. As discussed earlier, we have developed a method for determining a move to make given a new current position. We have written 4 methods that perform the 4 primitive manuevers possible on the robot: moving forwards, going backwards, moving left, and moving right. Each one of these manuevers was represented by a function. Going forwards entailed going from the current junction to the next junction directly in front of the robot. Going backwards entailed first making a U-Turn, and then going to the next junction over. Going left and right involved performing a left/right turn, and then going to the next junction. At each junction, the DFS code was queried, which would generate the next move for the robot to make.  While at a junction, we also had to communicate to the Arduino base-station critical information about the robot's position and surroundings. We also had to engage the treasure and wall sensors. If the robot moves to a cell in which it completes the maze traversal, it must stop moving and communicate to the base station that it has completed the traversal. All these considerations are easily understandable from the main loop code, which we've included below

void loop(){

  //start on 660 Hz Tone OR Button Press
   while(!startDFS) {
      set_motors(90,90);
      delay(25);
      startDFS = detectStart();
      startDFS |= detectButton();
  }
  //turns light on to tell that we started
  digitalWrite(13, HIGH);
  set_motors(90,90);
  delay(500);
  digitalWrite(13, LOW);
   initializeCurrPos();

  prevPos[0] = currPos[0];
  prevPos[1] = currPos[1];
  resetMaze();
  initializeOrientation();
  addToFrontier(convertCoordsToChar(currPos));
  visitedStack.push(convertCoordsToChar(currPos));  

  while (true){
    detectWalls();
    detectTreasures();
    maze[currPos[0]][currPos[1]] = Explored;
    removeFromFrontier(convertCoordsToChar(currPos));
    addWallsToMaze();
    getReachableCells();
    addUnvisitedSurroundingNodesToFrontier();
    if (frontierIsEmpty()){
        doneWithNavigation();
    }
    else{
      recordAndTransmitData(); 
      updateCurrPosAndVisitedSet();
      updateMove();
      performMove();
    }

  }

}




 Note how the code is executed. The first task that is performed is checking if the 660 Hz has been recieved. If it has been recieved, then the maze traversal can begin. As in simulation, the DFS algorithm begins by first initializing the current position. Unlike in simulation, we had to keep track of the previous position for the purpose of deciding how to move the robot. Inside the  while  loop, the robot detects walls and treasures. The current position is marked as Explored, and the current position is removed from the frontier set. Walls are added to the maze array, reachable cells are recorded, and then unvisited surrounding nodes are added to the frontier (to see how all these functions are implemented, check out the DFS module). If the frontier is empty (the robot finishes traversing the maze), the  doneWithNavigation() method is called. This method sets the  done  variable to 1 (for communication to base station), and initiates the wireless data transfer to the base station. If the maze is not finished being traversed, then the robot initiates a wireless data transfer to the base station, updates the current position and visited set, decides on a move to take, and then calls the  performMove  to physically execute the move. 

                  
                


              






                  
Verilog & Wireless Communication Updates

                   Robot transmission to base station 

                  
                    The robot transmits maze information to the base station in between moves. We decided that it would be most efficient to send the data in the form of a  word . An Arduino word is a 16-bit data structure (see the next section for how we decided to encode the maze data within this word. We essentially just send over a concatenation of the two bytes that the Arduino will transmit to the FPGA). 16 bits is enough bits to encode all the information we send to the base station. We chose a compact data structure for wireless transmission since this will ensure greater reliability, as opposed to sending over many bytes of data. The only downside to this method was that it involved greater work on the part of the Arduino on the robot, since it had to assemble the word that is being sent over. To do this, we first assembled a String representing the word.This made it easy to concatenate strings representing different components of the data, and then convert it to a  word . 
                  

                  
                   Arduino and FPGA base station 

                   Implementing the base station was a culmination of work done over multiple different lab sessions. To  receive radio transmissions from the robot, we connected a tranceiver to the Arduino on the robot, as well as to an Arduino that outputs the received information to the FPGA to simulate via physical connections.  

                  

                   The base station arduino recieves a 16 bit  word  from the robot that describes the current position of the robot, as well as data about any adjacent walls and treasures.  The base station takes this word, and converts it into a string of length 16 with the same information.  The code for this conversion is shown below: 
                  
                    

String disassembleWord(word data) {
  String stringToReturn;
  for (int i = 0; i < 16; i++) {
    int bitIndex = 15 - i;
    stringToReturn += String(bitRead(data, bitIndex));
  }
  return stringToReturn;
}


                         
                     We then decode the information from this string and write the data to output pins that will communicate with the FPGA.  To do this, we made an indication bit that would be zero when we were communicating information about walls and treasures, and one when we were communicating information about the position of the robot.  In our arduino code, we wrote this indication bit high, and sent out a byte of data about the position of the robot.  We then set a valid bit low and then high after a delay to give time for all our inputs to change before verilog updated the inputs on the FPGA on the rising edge of this valid bit.  We did the same thing for the walls and treasures, setting indication bit low, sending the relevant data from the string, and then setting valid low and high after a delay. Below is a diagram of how the byte is organized. Also note that the word being sent from the robot to the base station is essentially the concatenation of these bytes together. 

                  


                   

                       
                   
 always @ (posedge valid) begin 
 
                       preX = robotX;

                          preY = robotY;



                          if (arduinoInput[6] == 1'b1) begin

                            updateType = 1'b0;

                            robotX = arduinoInput[5:4];

                            robotY = arduinoInput[3:1];

                            done = arduinoInput[0]; 


                          end

                          
if (arduinoInput[6] == 1'b0) begin

                            updateType = 1'b1;

                            walls = arduinoInput[5:2];

                            treasure = arduinoInput[1:0];


                          end 


                      end 




                   From there, the FPGA has to update the grid based on changes in input. If new location information comes in, the coordinate specified in the transmitted byte must have its color updated to reflect the movement of the robot. At reset, every coordinate is assigned an 8'b0 to represent that no updates from the robot have been received yet. The FPGA has been programmed to store the information in each coordinate of the grid in this manner: 

                   


                  
                     always @ (posedge CLOCK_25) begin 



                        
 grid1[preX][preY] = grid1[preX][preY] & 8'b11111101;



                        if (updateType == 1'b0) begin         // if location update



                           grid1[botX][botY] = grid1[botX][botY] & 8'b11111100;

                          grid1[botX][botY] = grid1[botX][botY] | currPos; 




                        end else begin                        // if wall/treasure update

                          grid1[botX][botY] = {wall,tres,currPos};




                        end 


                     end


                  


                   Our grids are 96x96 square pixels so to draw walls, treasures, explored grids, and the robot icon appropriately, when changing the pixel color, we not only have to pay attention to the appropriate bit but also the position of the pixel we're changing. For example, to draw walls, we restrict the bounds of the wall that is drawn to be only 4 pixels wide. 

                     
                        if (PIXEL_COORD_X<=(10'd4+(GRID_X*10'd96)) && PIXEL_COORD_X>=(GRID_X*10'd96) && currentGrid[6] == 1'b1) begin  //right wall 

                            
PIXEL_COLOR <= black;
 

                          end else 
                     
 
 

                     These are the colors we chose to represent the various items in our display:  
                       
                       localparam white = 8'b11111111; //unexplored

                       localparam black = 8'b0; //walls

                       localparam pink = 8'b11110011; //explored

                       localparam magenta = 8'b11100011; //botbotbot

                       localparam red = 8'b11100000;  // 7kHz treasure Freq (2'b01)

                       localparam blue = 8'b00110011; //12kHz treasure Freq (2'b10)

                       localparam green = 8'b01010001; // 17 kHZ treasure Freq (2'b11) 

                    


                     And here's a video of what the functionality looks like in action:  

                    

                 





  Milestone 4 Reflections 

 
Although we weren't able to integrate all necessary parts for Milestone 4, we came very close! The robot is easily able to traverse a maze and signal when it finishes. The treasure detection works as intended. The robot is able to send accurate maze data to the base station. The robot is also able to respond to the starting tone. Given time constraints, we weren't able to completely finish the FPGA/Base Station side of the code and integrate all the components for the milestone, though we came very close and are confident that we will be able to complete this portion of the project by the competition. Here's a video of our robot successfully traversing a maze and stopping when it's done. 






                  

                   

                
              
            
          
        
      
    

    
    
      
        
          
            
              
            
          
          
            
              
                
                  
                  Behold, in All Its Glory
                  The Cold-Blooded Killer
                  



                
              
            
          
        
      
    
 
    
      
        
          
            
              
            
          
          
            
              
                
                  
Minutes

9/1 Meeting

  11:15 Upson 349
  Present: All
  Absent: None


Meeting begins with pleasantries and small talk.
Evan discusses adding everyone to Github.
Turns out issue is with Cornell’s github enterprises system.
Evan adds everyone’s personal accounts..
Everyone sends Evan headshots to add to the website.
Begin writing the contract.
Various discussions about elements of the contract, etc (see contract for more details).
Contract signed.
We talk about adding more pages to the website..
Michael will add robot stuff to the lab1 page.
How to submit? Email to kirsten?

MEETING ADJOURNED at 12:06PM


9/8 Meeting

  12:05PM Duffield 
  Present: All
  Absent: None 

  The team discusses how nice the weather is
  We check everyone can update the website
  Discussion of lab 1 scoring
  Goals for the week?
  Basically get Lab 2 up and running
  Line following is scary and needs to be done
  Will need to implement FFT stuff

   MEETING ADJOURNED at 1:00PM 

9/15 Meeting

  11:15 Kimball B11
  Present: All
  Absent: Radhika, due to illness.  We hope she feels better soon :( 

We discuss the work we have done on our individual subteams and deliberate on how to tackle the rest of the objectives related to lab 2 and milestone 1. 

Optical team realizes they have not made the modifications necessary to make the Arduino light an LED in response to incident IR light, so we discuss when we can meet to work on that objective.
The robotics team explains that our robot is able to stop at junctions with extreme accuracy, but it is having trouble following a line.  We figure the reason the robot is having this trouble is because the servos that run the two wheels are not operating at the same speed.  The robotics team adds that the robot is having trouble moving forward in a straight line even when it is not attempting to follow a line, which further confirms our hypothesis. 

MEETING ADJOURNED at 12:06PM


9/22 Meeting

  12:09PM Duffield 
  Present: All
  Absent: None 

  As individuals trickle into our meeting we discuss everyone's breakfasts
  TJ ate some chickpeas
  Progress on line sensing and turning is slow and unsteady
  Radhika and Katherine report that we're not sure what the issue is
  FFT stuff seems pretty great
  We finished lab 2 this week - made progress on milestone 1
  Discuss what we need to do in milestone 2
  Need to implement treasure sensing
  We are on track for this - evan/tj take lead
  Wall sensing stuff - need to implement - Frannie/Mike
  Radhika/Katherine will do more line stuff

   MEETING ADJOURNED at 1:07PM 


9/29 Meeting

  11:20AM, Hollister B11 
  Present: Evan, TJ, Frannie, Radhika, Katherine, Michael
  Absent: None 

1. Discussed buying new IR sensor that uses digital pins 
  
    Pros: 
      
        only uses one digital pin, rather than 3-4 analog pins 
        Makes line following easier
      
    Cons: 
      
        Costs go towards our budget 
      
     Radhika will email Kirstin to try to buy part
  
  2. Explained Finite State Machine
    
      Need a method where the input is a Direction enum, and it will turn and follow a line until the next junction. 
    
  3. Chose teams for lab 3 
    

    Acoustic team: TJ, Michael, Frannie
    Graphics team: Katherine, Radhika, Evan
  


  MEETING ADJOURNED at 12:05 PM


10/6 Meeting

  11:17 AM Duffield 
  Present: All
  Absent: None 

   Michael sang a spontaneous (but deeply sarcastic) ode to FPGA's. TJ joined in, much to Michael's chagrin (he prefers to do his musical work alone).
   Michael gets offered a record deal. He flies to Los Angeles to record his single, "FPGA into My Heart." The single flops since the general public has no idea what an FPGA is. He re-joins us at our meeting--humbled but a bit jaded. 
   Lab 3 is progressing well. Evan, Radhika, and Katherine will write up what they have so far for the FPGA visual team soon.  
   Michael, Frannie, and TJ are coordinating their schedules to go in for extra lab hours.  
   Katherine stares at a squirrel eating scavenged crumbs for an inordinate amount of time. 
   MEETING ADJOURNED at 12:10PM  
  


  10/13 Meeting

  12:07 PM Duffield 
  Present: All
  Absent: None 

   We greet each other and ask each other the time-old, generic post-break question: "how was ur break?" The customary response, "good," is given in exchange. 
   OUR LINE SENSORS ARE HERE AND KATHERINE AND RADHIKA ARE SLOWLY BUT SURELY MAKING THE BOT A LITTLE LESS DUMB WITH EACH PASSING DAY. The boy will be expected to follow lines soon. Updates to come. 
   Evan Kravitz went in to extra lab hours while others were away during fall break and made headway with the FPGA display! Thanks Evan!  
   We are continuing with Lab 3 machinations on Monday.  
   Halloween is soon. Autumn looms over us, filling us with nostalgia for simpler times. A somber mood sets in. 
 
   MEETING ADJOURNED at 1:02PM  
        

10/20 Meeting



11:20 AM, Hollister B11 

Present: Evan, TJ, Frannie, Radhika, Katherine, Michael 

Absent: None
 

1. Lab today 
  
    Working to combine the VGA and wireless communication teams
    Working to combine the VGA and wireless communication teams
    Need to do integration part, update maze part
    Idea is to send 2 8-bit arrays
  
2. Milestone 3 due Monday Oct 30th 
  
    Need: 
    
      Working algorithm that explores maze 
      Indication that robot is done 
      In real life and in simulation 
    
     To do: 
      
        Line sensing, following and turning - Katherine and Radhika 
        Editing chassis and wall sensors - Michael, Frannie
      
  
  3. Future work 
    
       PCB stuff - Michael, TJ, Katherine 
       Algorithm - Radhika, Frannie 
       Update website - Katherine, Evan 
    


Motion to Adjourn: TJ
 
Seconded: Evan
  
MEETING ADJOURNED at 12:05 PM

10/27 Meeting


10/27 Meeting
Present: Everyone


Progress on milestone 3?
Evan has basically finished simulation
It’s in Java - need to port
Line sensing done!!! Back on track
Need to implement cornering
Wall sensors mounting will be easy
Katherine making mad progress on website - looks great
Mike is doing some PCB stuff! Should be done after Monday
Seems like no urgency



11/3 Meeting



Present: Everyone (Franny virtually! Good luck on interviews!!!)


Discussion of fortunes/fortunetellers
When are lab orders? Friday afternoon, Sat evening, Sun afternoon
What do we have to do?
Fully migrate code to arduino
Mount wall sensors
Turning is done!!!!!
Clean up the code dump
what classes is everyone taking next semester?
Today implementing wall following
Saturday will be implementing better things


11/10 Meeting



11/10 Meeting
Present: Everyone!!!!


Discussion of cold
TJ’s hypothetical: Know the year you die or the month you die
General morbidity
Need to do ethics hw -11/27
Have team meeting next friday, will talk about topic and then write up what we talked about
Topic: Self driving cars and fatalities
Everyone read about stuff
Team evals are due this saturday!
Robot!!! Stuff!!!
Milestone 4
Need to implement DFS, combine evan + TJ code
Combine difficulty
TO-DO
Combine DFS and FSM code
Put the sensors on the robot
Solder up the power strip
Re wire/Heat shrink tubing
move our power bank
Standardize communication
Final VGA stuff


11/13 Meeting

  11:15 Duffield 
  Present: All
  Absent: None 

   We got ethical in our meeting today! You can find the transcript of this meeting inside of our ethics homework under the labs tab. 
   MEETING ADJOURNED at 1:13PM 
  
  12/1 Meeting

  11:15 Phillips 437
  Present: All
  Absent: None


 We begin, as always, with pleasantries and small talk.
 Discuss mutual sadness that it is our last meeting of the semester.
 We get TJ and Rhadika up to date on what we did in lab yesterday. 
  We inform them that we programmed our FPGA so it will run with the monitor during competition. 
   We also fill them in on the videos we took of the robot working, which we can put on our final website.  
 We all agree that our robot is mainly finished and now our main priority should be updating our final website. 
 We discuss who will be working on what part of the final website.  
   We decide upon certian section headers that we should work to fill in.  
   Evan will take the DFS, Robot to Base Station, and treasure detection sections. 
   Frannie will take the wall sensing and Base Station to FPGA sections. 
   Katherine will take the verilog implementation of final design section. 
   Michael will take the physical robot structure section and conclusion, and help TJ with the IR section. 
   Rhadika will take the line following section. 
   TJ will take the introduction, as well as the microphone/ IR/ FFT section.   
   Katherine will update the website and put in the videos.  
   TJ will make all of our pictures lower resolution so that our website does not take as long to load.  
   We discuss that every person in his or her corresponding section should touch upon improvements made, and possible design flaws, 
   In addion to adding as many detailed diagrams/ useful bits of code as possible to make the sections user-friendly and easy to understand. 
  We decide that we should try to come for about an hour on sunday to make sure everything is good to go for the competition. 
H

MEETING ADJOURNED at 12:36PM





                  
                
              
            
          
        
      
    

        
    
      
        
          
            
              
            
          
          
            
              
                
                  
                  TEAM CONTRACT
                     
                       ECE 3400, Semester #FA17 Team #1
 
 Team Members: Radhika Chinni, Frances Koback, TJ Hurd, Katherine Lu, Michael  Solomentsev, Evan Kravitz
 

 Team Procedures
 

  We will plan to meet every Friday at 11:15 in the lobby of the 3rd floor of Upson Hall.  If we decide additional meetings are necessary, we will decide the date and time of the next meeting at the end of the previous meeting. If there is a lecture scheduled on Friday so that we can’t have a full-length meeting, we will discuss what works for that week during or after our lab session on Monday in Phillips 427 depending on how busy we are. 
  The team leader will set each agenda for all meetings in the period to which he or she has been assigned the team leader position.  Put the agenda in our Google Drive folder. The team leader will send a reminder message of the location and time of the next meeting the day prior in our GroupMe. The team leader will also be responsible for making sure the agenda for each meeting has been followed and that all assignments in that time period are turned in on time.  The team leader will have it under his or her discretion to decide how to respond when the rest of the team is not following the agenda, but should definitely open an honest discussion about any slack during a weekly meeting. 
  This team will make all decisions by majority vote. If someone is particularly knowledgeable for one part of our project, we will take their opinion into extra consideration.
  Meeting minutes will be taking for all group meetings, partial or full. Minutes will by default be taken by the team leader next in succession (i.e. the individual who will lead the team during the next time period). Minutes should be added to website within a few days of a meeting. 
  All members can communicate with the larger group through GroupMe. Everyone is responsible for responding within the course of a day through appropriate messaging, gif response, or heart emoji. 
  Any changes to this contract require a majority vote by team members.

 Team Expectations
  
 Work Quality:
 
  
    We agree to always peer review our work on the website and strive to create the best website we possibly can.  
    Individuals /sub-teams must finish their part at least a day before the deadline, foregoing extraneous circumstances.  If any individual or subteam in charge of a certain part of the project feels overwhelmed and does not think that the portion to which the team or individual is assigned can be completed in this time frame, said individual or subteam will inform the rest of the group and the group will arrange to compensate to help get the project completed.  
  
 Strategies to fulfill these standards:
 
  
    Team Participation:
      
        Strategies to ensure cooperation and equal distribution of tasks:
          
            The team leader will accordingly delegate and monitor all tasks.
          
        
Strategies for encouraging/including ideas from all team members (team maintenance):
          
            We will have open brainstorming sessions before beginning a new part of our project.
          
        Strategies for keeping on task (task maintenance):
          
              We will be trying our best to hold ourselves accountable on a mobile app called Trello which serves as a virtual to-do list which tracks the progress of each task. Anyone can add an action point or mark an action point as in progress of completed. It has a pretty user-friendly GUI interface so we probably won’t write up a tutorial for it but we can if further inquiry arises. 
          
        Strategies to get help if you're stuck:
          
              Ask for team help in GroupMe.
              Ask a T.A. 
          
      

    Personal Accountability:
      
        Expected individual attendance, punctuality, and participation at all team meetings:
          
            Members are expected to be on time for and participate in all meetings and give advance notice for any absences. 
          
        Expected level of responsibility for fulfilling team assignments, timelines, and deadlines:
          
            Each member is required to fulfill their responsibilities as they were delegated by the team lead. Subteam members should aid each other in meeting deadlines appropriately.
          
        Expected level of communication with other team members:
          
            Each member is responsible for communicating with all other team members when they have a high work load and/or are struggling with their task. We expect team members to freely reach out to each other.
          
        Expected level of commitment to team decisions and tasks: 
          
            If a majority vote has been reached, even dissenting members are responsible for seeing through the majority decision. 
          
        How should a team member catch up if they have to miss a meeting: 
          
            Reach out to the team leader and get assigned a task to do to make up for missed work. 
          
      
    Consequences for Failing to Follow Procedures and Fulfill Expectations:
      
        Describe how, as a group, you would handle individuals who do not live up to this contract:
          
            At the next meeting, group will address the issue with the person who committed the infraction.  Based on how that individual responds to this confrontation the group will determine the best course of action moving forward.  
          
        Describe what your team will do if these infractions continue:
          
            After repeated infractions, the rest of the team will collectively decide a plan of action (either speaking to course staff or reaching out to said individual).
          
      
  
 Team Leadership
  
Every person on the team will have to take the role as a leader for at least two weeks. The role of the leader will be to organize meetings and make sure that everything is submitted in a timely manner. Here are some hints on what the leader should do. Please note here who will be responsible when: 

Aug 28th - Sep 15th (Lab 1, work on lab 2): Evan Kravitz
Sep 16th - Sep 29th (Lab 2, Milestone 1 and 2): Frannie Koback
Sep 30th - Oct 20th (Lab 3, work on lab 4):Radhika Chinni
Oct 21st - Nov 3rd (Lab 4 and Milestone 3): TJ Hurd
Nov 4th - Nov 17th (Milestone 4): Katherine Lu
Nov 18th - Dec 5th (Final competition and deadline for the website): Michael Solomentsev

 I participated in formulating the standards, roles, and procedures as stated in this contract.
I understand that I am obligated to abide by these terms and conditions.
I understand that if I do not abide by these terms and conditions, I will suffer the consequences as stated in this contract.
         
Evan Samuel Kravitz
  date: Friday, September 1, 2017
Radhika Priya Chinni
  date: 9/1/17
Michael Yuri Solomentsev
  date: 9/1/17
Jeffrey Joy Hurd Jr. 
  date: 9/1/17
Katherine Lu 
  date: 9/1/17
Frances Lydia Koback 
  date: 9/1/17