Week 14

This week, Luis, Chris and I began working on the code for both the Arduino Micro and Uno. For example  I wrote a program that would assign each RFID tag a station number and then send that station number to the computer or mobile app, depending on where the data is requested to. What the code basically does is read the RFID tag and then run the predetermined tag id through an if/else loop. If the RFID tag is one that is recognized, then the program would assign a station number to it. This could be done for as many RFID tags possible so long as the predetermined RFID tag id is known. I also weote a program that would send a True value if the ultrasonic sensor detects an object that is closer than 6 inches and False value if not.

This week was basically dedicated to writing code individually and then combining all the functions into one code. Altogether, I am confident we will develop a successful test bench for all our sensors and electronic parts by next week.

Week 13

Nothing new has really happened this week as I helped Luis go through the summer team's code some more in order to figure out which parts could be reused or modified. Since we were able to get I2C communication working between the Arduinos, the summer team's code was a lot easier to understand. For example, Luis and I could not figure out how the Arduino Uno was receiving data from the ultrasonic sensor, which was connected to the Arduino Micro, because they were not using I2C communication and only had one pin connected to one another.

Other than that, Luis and I tried to get as much done this week because our team will be unable to meet next week.

Week 12

This week my team and I met with Eric, Dr. Furman and Ron to figure out exactly what is required of us by the end of the semester. My team's goal is to have a bench test for all the electronic components by the end of the semester in order to make sure everything is functioning correctly before they are assembled onto pod car.

On the other hand, Luis and I have managed to figure out how to get I2C communication working between the Arduino Micro and Arduino Uno, which is a big step for us. A big part of our confusion with the summer team's code was how the microncontrollers were communicating with one another. Fortunately, I2C communication only requires two wires and allows the two microcontrollers to send information directly back and forth. Although I2C communication has limitations, those limitations will not really affect us.

Now that things are becoming a lot clearer, all that is left is to continue salvaging pieces of the summer team's code while modifying our own. Our progress may have stalled for a bit due to presentations and essays, but my team and I are finally picking up momentum again.

Week 11

This week, Luis and I simply worked on salvaging pieces of code from the 2016 summer team's Arduino code. So far, I've determined that the entire sketch for the Arduino Micro could be used for our code because it simply controls the ultrasonic sensor and communicates that information to the Arduino Uno. The Arduino Micro communicates by using pin 13 to simply write a value of HIGH or LOW to pin 6 on the Arduino Uno. The code can be seen below:

#define echoPin 7 // Echo Pin
#define trigPin 8 // Trigger Pin
#define STOP 13 // emergency stop

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() {
 Serial.begin (57600);
 pinMode(trigPin, OUTPUT);
 pinMode(echoPin, INPUT);
 pinMode(STOP, OUTPUT);

Therefore, the code on the Arduino Uno that corresponds with the sketch above can be observed below. The code simply reads pin 6 and stops the bogie if the value is HIGH.

int emer = digitalRead(emergency_stop); 

if ( emer == HIGH) 

{

  control_rpm = 0 ;          

  STOP = true;        

  }

Currently, I am helping Luis with understanding more of the summer team's code such that we could salvage more pieces of it. Hopefully, we can begin writing in some of our own code and begin testing all the vehicle controls components.

Week 10

This week, I did testing with the sensors and actuators that the team decided on using. This was done by setting up everything on a breadboard and then running individual codes in order to make sure everything is running correctly. Even though everything works, I still need to figure out which parts of the code used last year could be salvaged and used by my team and I. From there, I must also figure out what code I must write or add in myself.

As for now, my team and I are basically in the rapid prototyping phase so we are on track. My only concern is time constraint because we need to make some significant progress before Thanksgiving break, which will set us back a couple days to a week.

Week 9

This week was a very successful week for my team and I because we were finally able to get the Processing software, that was used to interface with the pod cars, working. Without the help of the mobile software team, it would've been very difficult to have got the software working in the first place because there were no instructions left behind for us and none of us had any software background to begin with. It turned out that all I had to do was put the sketches in the same folder along with a folder that contained all the java files.

This week, I will be focusing on the presentation that my team and I will be giving next week. However, in regards to the project itself, I will be focusing on trying to understand the codes that were left behind by the teams from last year and the summer. The challenge will be figuring out which parts can be kept or taken out because there is a lot of the code right now that is associated with the bar code algorithm used for pathing.

As I had hoped last week, my team and I are finally picking up some momentum with our progress on the project and it won't be long until we are well on our way for testing.

Week 8

This week, I worked with Luis on developing some pseudocode. Therefore, we tried to understand the Processing software that was used by last year's team first. We were able to download the code that they had written, but we did not have the correct XBee device that would allow us to access the graphical user interface. Therefore, Luis and I would have to wait until next week in order to fully understand last year's team's code.

 I also helped test the sensors that would be used, which included: Magnetic reed switch sensors, Ultrasonic sensors, and RFID sensors. All sensors worked perfectly fine, but it was decided to have the RFID readers placed on the podcars rather than on the track. This was decided because placing RFID readers at each station would require at least one microcontroller and one XBee device per station, which would require a lot of wiring and extra complications that are simply unneeded. Instead, the RFID tags would be placed at each station so that each station would have its very own identification code and allow us to know exactly which podcar reached which station without the extra wiring. The only downside to placing the RFID reader on the podcar is size constraint, but that is an issue that could be solved.

We are a slightly behind on our schedule, but we are starting to pick up a lot of momentum in our progress. I am confident that Luis, Chris, and I will be able to create a successful prototype by the end of this semester.