Week 14

This past week, I was able to get I2C working. I was so relieved to see that I could send and receive information on both the Micro and the Uno. I became frustrated when I could not acquire or send the correct values. The best way to send and receive data between the two microcontrollers was to use an array of values where each placeholder in the array indicated some value such as distance, hall effect sensor reading, station ID reading, or LED status.

I was also able to define the LED states based on what state the Micro was receiving from the ultrasonic sensor and the values from the Uno. We had 5 predefined states. 0 for green (podcar in motion), 1 for red (podcar stopped due to collision prevention), 2 for blue (hall effect sensor reading), 3 for blinking red (kill switch activated), and 4 for red (arrived at station, podcar has stopped). For the kill switch, I was able to create a latching button using code to prevent us from buying latching buttons. Using this method, we would not have to hold the button to make the podcar stop in the case of an emergency. On the contrary, we cannot restart the system by pressing the button again. We would have to either implement a separate button to restart the system, reset the Micro or change the code so that it will wait a certain amount of time before resetting the system.

In the coming week, I will be preparing well for our last presentation so that we can show how much we have improved since the first presentation. Before this semester, I was terrible at presentations and used to be really scared to speak in public. Now I feel much more better about presenting and should not be a problem when we showcase our project next semester at Maker Faire and the Paseo Prototyping challenge. I will also be helping my team prepare the rough draft of our report as well as compiling the code for the Uno so that it can be included in the final draft of the report. I will also have the system running by next week so that we have solid evidence that our system will work and will look promising.

Week 13

This week, my team and I were able to conduct some testing on a hall effect sensor so that we can transition from using a reed switch to this sensor for sensing when switching should occur. We finalized our decision on using this sensor which proved to work better than the current sensor mounted on the podcars. My only concern as well as the concern for my team is that since there are two hall effect sensors on the podcar (one from the positioning team and one from controls) that it would interfere with successfully reading the magnet on the track for our purposes.

From now until the next week, I will mainly focus on finishing a strong communication between the Arduino Uno and Micro and also coding the two functions that the software team requested from our team. I will also build a bench setup of our model by either just having everything connected to a breadboard or building another shield such as the one that is currently mounted on the podcar. I should be able to get all of this done and help my team with anything else if needed before we meet again next week. Debugging the code will be the only time consuming task from all of this as well as a couple of soldering here and there if I make the shield.

I am beginning to worry that everything is coming together in the last few weeks left for the semester and there is not much time left to get all of it done. It is time for projects, reports, presentations, and papers and all of it must get done in the next three weeks. I am beginning to stress a lot and worry that my team will not get a good grade for this semester even though I know that my team and I put in the effort to make the controls part of this project work. I am hoping we do pass this semester. It is difficult to juggle all of these classes at the same time without neglecting one class for another. In these last few weeks, I will keep on working on the project so that my team and I can reach our deadlines and goals that we had set at the beginning of this semester.

Week 12

This week, I was able to implement what Dr. Furman had suggested to our project which involved using I2C to communicate between two devices. I looked into I2C first to get a general understanding of how it works and what functions the Arduino environment has that can be useful for our purposes. I also looked into SPI communication but I found I2C easier to implement than SPI. With I2C, we only need two wires between the two devices and a common ground. These two wires are connected to two analog pins A4 and A5 on the Arduino Uno and Micro. This does not conflict with the number of pins we require to make our design work. The other analog pins will be used for the encoder of the motor as well as motor direction.

I was able to make some progress in the code instead of just picking out code from the summer team's code because much of the code is functional but we just need to add our sensors and our pathing. There is a lot of programming involved and this task cannot just be assigned to one person. That is why I am counting on my teammates to help me modify the code so that we can not only have multiple input to the code but also finish in a timely manner. We only have this week and next week to work on this project because after the Thanksgiving week we have presentations and rough draft of the report due. This is becoming to be stressful as there are papers and other projects from other classes as well but I am hoping that my team and I are able to have a working prototype by next presentation waves. I will continue to make progress in the code this week and the next.

Week 11

This week, my team and I got some amount of work done and we are beginning to progress with the programming aspect of our project. I am relieved to see progress in this project and that we will meet our goals for this semester. Initially, I was stressing out over minimal progress made in our project but my team has been working on it the best they could. Understanding the code from the summer team was difficult to understand because I have not personally programmed code the way that team did. In other words, their code was lengthy and much more advanced than what I am usually accustomed to.

I was able to make some progress in modifying the code in the Arduino Micro while my partners are working on modifying the code on the Arduino UNO and on pathing. Below is the code that I was able to generate by modifying the existing sketch on the Arduino Micro. I was able to implement the LED for our purposes by indicating any of the four status indicators. If the LED is red, the podcar has stopped at a station. If the LED is green, the podcar is in motion. If the LED is blinking red, the kill switch has been pressed and the podcar has stopped. If the LED is blue, a checkpoint was successfully read. We also needed to change the safe distance from 30 cm (1 ft) to 15 cm (6 in). The reason we did this change was because the podcar stopped as it turned into the station. One of the supports was below the safe range which caused it to stop.

In the coming weeks, we will drastically work on the code for both the UNO and the Micro so that we can work with the mobile app team to get Processing to work with our design. These next remaining weeks might be stressful but I am confident that my team will meet our goals and what was expected of us this semester.

****************************************************************************
#define echoPin 7      // Echo Pin
#define trigPin 8      // Trigger Pin
#define STOP    13     // emergency stop
#define RED     6      // STOP and error status
#define GREEN   5      // GO status
#define BLUE    3      // status of podcar
#define COMMON_CATHODE // Type of RGB LED
#define BUTTON  2      // Kill Switch

#define IS_PRESSED  LOW
#define OFF         LOW
#define ON          HIGH

// RGB LED: green for GO status, red for STOP, blue for status, blinking red for error 

int maximumRange = 200;  // Maximum range needed
int minimumRange = 0;    // Minimum range needed
long duration, distance; // Duration used to calculate distance
int stop_counter = 0;
int restar_counter = 0;

void setup()
{
 pinMode(trigPin, OUTPUT);
 pinMode(echoPin, INPUT);
 pinMode(STOP, OUTPUT);
 pinMode(RED, OUTPUT);
 pinMode(GREEN, OUTPUT);
 pinMode(BLUE, OUTPUT);
 pinMode(BUTTON,INPUT_PULLUP);

 // change this to 56900 for XBEE comm
 Serial.begin (9600);

 Serial.print("Duration (ms)\t  Distance \t Error Message");
 Serial.println();
}

void loop()
{
/* The following trigPin/echoPin cycle is used to determine the
 distance of the nearest object by bouncing soundwaves off of it. */
 digitalWrite(trigPin, OFF);
 delayMicroseconds(2);

 digitalWrite(trigPin, ON);
 delayMicroseconds(10);

 digitalWrite(trigPin, OFF);

 // returns the length of the pulse in microseconds
 duration = pulseIn(echoPin, ON);

 //Calculate the distance (in cm) based on the speed of sound.
 distance = duration/58.2;

 Serial.print(duration);
 Serial.print("\t\t\t");
 Serial.print(distance);
 Serial.println();

 // changed distance from 30 cm to 15 cm due to pole obstacle
 if (distance <= 15)
 {
  setColor(255, 0, 0);
  delay(100);
  setColor(255, 0, 0);
  delay(100);
  setColor(255, 0, 0);
  delay(100);
 
  stop_counter++;
 }
 else if (digitalRead(BUTTON) == IS_PRESSED)
 {
  digitalWrite(STOP, LOW);
  setColor(255, 0, 0);
 }
 else
 {
  stop_counter = 0;
  setColor(0, 255, 0);
 }
   //Serial.println(stop_counter);
   if (stop_counter == 10)
   {
    restar_counter = 0;
    digitalWrite(STOP, HIGH);
   
    Serial.print("Warning: Out of range!");
    Serial.print("\t\t\t\t");
    Serial.println();
   
    stop_counter = 0;
    delay(1000);
   
    digitalWrite(STOP, LOW);
    }
 //Delay 50ms before next reading.
 delay(50);
}

void setColor(int red, int green, int blue)
{
  #ifdef COMMON_ANODE
    red = 255 - red;
    green = 255 - green;
    blue = 255 - blue;
  #endif
  analogWrite(RED, red);
  analogWrite(GREEN, green);
  analogWrite(BLUE, blue); 
}

Week 10

This week, my team focused primarily on improving our presentation skills and material content compared to the first presentation. We made sure that we had evidence that we are making progress in our project in the absence of a product since most of our work is using sensors and generating code to accomplish the task assigned. We presented last Wednesday in the first wave of presentations and I feel better about this presentation because we had much more content to talk about and also improved in the preferred presentation style, which is the assertion-evidence method.

I was amazed seeing the podcar move on the track, even though it did not move much due to the condition of the track. Depending on what the track team will be doing as a prototype, we might not be able to see anything move on the track this semester. Instead, my team will be focused on building a skeleton of all the electronics connected together and will be tested with the current podcar to see if sensing when switching should take place is improved. We will also test to see if the podcar is recognizable by the main system as well as the location of that podcar. I am beginning to worry that time will be against at this point in the semester because coding will take a chunk of our time and we still have some work we must do besides coding. Coding is the crucial part in our project and without it, controls will not be controls. I am confident that my team and I will accomplish our goals way before December and will do anything to get it done. I will be focusing on helping my team produce some code and aim to get much of the coding done by the next coming week.