Fall 2016 Week 15

This week, Luis and I worked on compiling all the code that we have been working on together so that we could test the whole thing on our test bench. Although we got all parts of the code working together, the task proved to much more difficult than we thought it would be. For example, we had trouble getting the motors to run or stop when we wanted it to, or getting the RGB led to display the correct color depending on the pod car's status.

In addition to compiling the code for both the Arduino Uno and Micro, I also worked on the final presentation that we will be giving this upcoming Wednesday. We have finally finished the first half of our project and I am very excited to begin finishing up the rest of it next semester.

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.

Week 7

This week, I worked a little more on the presentation since my team and I did not present last week. This was the case for the whole 1/12th scale team, so not much progress was made as a whole group this week as well. However, Luis and I were able to get the RFID reader and sonar sensor to work. The sonar sensor will perform the task we desire it to, but we found that the card or tag must be very close to the RFID reader in order to be read. In addition, the card or tag cannot pass by the sensor too quickly or it may not be read. Therefore, the best use for the RFID sensors is to be placed at each station such that we may be able to know which pod car is at which station or has passed by. Currently, we are still on track, but I'd like to finally be able to test the pod cars on the track. Hopefully, we will be able to find a way to use the magnets as a means for positioning and switching.

Fall 2016 Week 6

Not a lot of progress was made due to the fact that everyone was working on their presentations during the prior week. However, the 1/12th scale still met up just to touch base on where every sub team is at. As expected, each subteam was busy working with their presentations so very little progress was made or shared.

Therefore, this week, most of the half scale gave their presentations to simply tell us what their plans were, which I thought was actually pretty interesting. Other than that, I worked on trying to get the RFID card reader to work in hopes that it could possibly implemented into the project. However, I have been unsuccessful so far. Workload from other classes are catching up as well, so time constraint seems to be a current issue.

Fall 2016 Week 5

This week, my team and I worked on some ideas for the switching of the bogie. For example, we figured out where we would place magnets on the track in order to have the bogie switch when and where we wanted it to. In addition, we decided that the reed sensor on the left side of the bogie would be used for switching every time it passed by a magnet. Therefore, we decided to use the reed sensor on the right side of the bogie for switching during pathing. For example, the reed sensor on the right side would pass by a magnet, but would run through a code in order to decide whether or not it will switch tracks.

In addition, the positioning team notified us that the sensor they used only gave a digital output of 0 or 1 so it could not be used for positioning of the bogie. Therefore, the positioning team is currently working on finding a different sensor that could be used.

My team and I are also working on our presentations for next week so I hope that we begin to make some progress in our design and coding within the next week.

Fall 2016 Week 4

This week, a lot of lingering confusion was sorted out. My team and I were given our deliverables for the year, but we were still unsure of what the other sub teams were going to work on. Therefore, the whole 1/12th scale team had a meeting in order to figure out what each sub team was working on and exactly how much overlap there was between each team's responsibilities. In addition, a Slack group chat was created for the 1/12th scale team as a means of a communication and keeping everyone on the same page so that the project may be completed smoothly and cohesively.

After speaking to the positioning team, my team and I confirmed that the ferrous strips and magnets will be implemented for tracking of the bogie. As such, we are now trying to figure out a way where we can build off of the positioning code in order to control the bogie's switching.

This week really gave everyone, including myself, a clear picture of what we need to accomplish and which teams we must work and communicate with. Therefore, the objective of this project is no longer so vague and ambiguous as it was to me before. I am very excited to see what my team and I can achieve in the next couple weeks.

Fall 2016 Week 3

On week 2, after being fairly confused in regards to what our objective for the project was, my team (1/12th scale vehicle controls) and I were finally given our deliverables for the next year. Our main objectives for this year are to basically improve the sensing and positioning aspects of the bogie so that it is able to switch tracks reliably and consistently with multiple other bogies running simultaneously.

After meeting with Dr. Furman and Eric, it was decided that the team would replace the bar codes with another method that would be more robust and reliable. As such, we settled on the method of using ferrous strips and magnets in order to read pulse signals as a way to locate the position of the bogie on the track.

Besides our technical responsibilities, my team and I also realized that communication with the other subteams is very important because all our work must come together smoothly and cohesively. Therefore, if one team decides to make any changes to their part of the project, it is highly recommended that they consult with the other teams working on the 1/12th scale. Otherwise, it may force every other team to make drastic changes, or maybe even the whole 1/12th scale project itself to fail. Thankfully, it is still early on in the year so it is a good thing that we are realizing this now.

Week 1: Past Successes & Failures of Vehicle Controls Team

My name is Steven Mou and I am excited to be part of the vehicle controls team for the 2016-2017 Spartan Superway project. I am currently a mechanical engineering major at San Jose State University and intend to focus my studies into the field of mechatronics. Therefore, I look forward to being a part of the Spartan Superway because it will not only be a great way for me to expand my knowledge of mechatronics, but also allow me to utilize those skills towards something that can improve society.

Being part of the vehicle controls team, my team and I will be responsible for making sure that all the controls in the bogie function properly and cohesively. Reading the report that the 2015-2016 team had written, some of the main issues seemed to lie in the barcodes that the previous team used for positioning on the bogies. The barcode sensors seemed to be inaccurate and would also sometimes not miss some readings. As a result, the position of the bogie would not be able to be determined, which would prevent the bogie from knowing when to switch tracks. In addition, the algorithm used for the barcodes seemed difficult for someone who was not familiar with binary language to understand, let alone fix it.

Therefore, building upon the previous teams' work, my team and I hope to implement a different method to locate the positions of the bogie that would be simple yet robust. A potential method that was already discussed with the team involved placing ferrous strips on the tracks and having a sensor read magnetic pulses in order to determine positions multiple bogies simultaneously. In addition, the magnetic pulses would still read the same regardless of the direction that the bogie travels. Although it is still too early to settle on ideas without consulting the other teams beforehand, I believe we are off to a good start.