Week 15

In the past week, my team and I prepared for our last presentation of the semester where various people attended our presentations throughout the day. My family came out to support me during my team's presentation and I felt pretty good about the presentation that I executed. The night before the presentation, I rehearsed my lines well and made sure that I covered each point of the presentation well.

Besides the presentation, my team and I also needed to prepare our final report for our project where our documentation must be fully detailed so that other teams that continue this project can pick up where our team left off and continue without trying to determine what needs to be done. I am in the process of writing up some sections that were assigned to me by Chris and also proofreading the code so that it is readable and "clean" for future teams to look at. I am aiming to apply common programming practices to our code as well as fully commenting our code with detail so that it is clear what each function or each section of the code does with respect to the full length of the code.

There is not much time to test anything else for our project and our full attention has been focused on writing up the report. Maker Faire is coming up this week and our project is ready to be showcased in San Mateo. I am hoping that the podcars run smoothly on the track with less problems than what we had experienced at Paseo in April. We are on the last stretch of this project and we must aim to leave a well documented report as well as an improved controls system compared to the last team that worked on this aspect of the Superway project.

Week 14

In the past week, I have begun to create a library for one of the electronic components that is wired to the Arduino Mega. Since I was a beginner at writing my own library, I began with the most simple component that we are using in our controls system, the RGB LED. Initially, I struggled to get the library working and I looked at a few Youtube videos to see how a library is created. After a few attempts at making the library work in the Arduino environment, I was able to successfully make it work and thus I was able to turn on the LED using the library I created. The only problem I encountered that I am unable to fix at the moment is that I was not able to make the LED blink using the library. Fortunately, the mobile app team will provide me with some assistance in making the LED blink using the library. I also attempted to create a library for our two ultrasonic sensors that are used for collision detection. Since the podcar that I took to test out the libraries that I created only has one ultrasonic sensor, I was unable to test out the library and I would have to wait until I am in the shop again.

I have also begun to prepare for our last team presentation of the semester that is coming up this coming week. I have begun to prepare my slides and formulate my thoughts so that when my team and I rehearse, I will be prepared and will be able to make some adjustments if needed. We also have the final report coming up but that is not due until the following week so I still have time to contribute to the report. During the coming week, my team and I will be rehearsing for our final presentation where my family will be attending our presentation and I will also try to create more libraries as well as writing up the final report and the individual evaluations.

Week 13

During the past week, my team and I have not really done much since most of the work that needs to be done involves the mobile app. We do have some work that the app team wants us to such as cleaning up the code for readability purposes and to also condense the length of the current code so that future teams can easily read it and it will also allow to remove the lag experienced in the code through the podcar.

In the length of the week, I looked at examples of how to create a header file and a C++ file that would make up a custom library. I looked at the Arduino website while simultaneously looking at Youtube videos to see if anyone had done. Fortunately, there were people who have accomplished this before and I was glad to finally learn how to create a library both in the Arduino environment and using the ChIDE that most ME students might have used in their ME 30 class. Basically, a header file and a C++ file must have a file of their own and included under one folder in the main library folder of the Arduino IDE. This was a problem I kept experiencing while attempting to follow the example in the Arduino website. I still have to learn how to convert our functions and apply what I learned in that example to one of functions. Once one function has been converted into a library, the rest of the functions should be easy to do.

In the coming week, I am planning to convert at least one of our functions into a library so that we can begin condensing our code as well as cleaning up the code to follow standard programming practices. I hope to also help my team with anything else that we still need to do before Maker Faire.

Week 12

This past week, Steven and I were assigned to create header files for our code so that we can simplify the amount of code we have for the project. The goal is to have fewer lines of code as we can so that next year's teams that work on this project will be able to easily understand the code without feeling overwhelmed with a lengthy code. Steven and I decided to split up the number of functions that we need to convert into header files so that we can both work on them together without having just one of us working on it alone and so that we can accomplish this in a timely manner.

I was unable to make much progress into creating a header file because we had a paper due this coming Wednesday but I had done some more research on how to create them. I tried searching for video tutorials because the idea of creating a header file is still vague and I learn best by seeing some examples of how it is done. Steven and I had asked Tim from the mobile app team on how to create them but I became overwhelmed from his explanation since ME students do not have advanced programming skills, much less any knowledge of C++ coding or any other programming language. We basically have to create a .h file and a .cpp file to create a header file or library. These files utilize  the C++ programming language that I am not familiar with and I would have to learn quickly on how to use that language. During the next couple of weeks, I will rapidly try to learn how to create a library, practice on an example sketch, and then move on to converting our functions into libraries. Learning how to create these libraries will require time and patience but it would be an excellent skill to learn as well as advancing my programming knowledge in the Arduino environment.

Week 11

In the past week, we completed our second presentation of the Spring 2017 semester. Chris and I were the headline at the beginning of the presentations due to the picture that was posted in the San Jose Mercury News that included Chris and I in it during the Paseo event on April 8th. Our second presentation went well and it allowed us to reflect on the Paseo event so that we could improve the project before Maker Faire. There are some improvements that must be made as well as already keeping in mind what our team will leave behind for next year's team. The merging problem we witnessed at Paseo must be fixed. I am currently working with my team to think up ways to fix this issue. Before adding any extra hardware, we will look into the placement of the current ultrasonic sensor to see if the sensor could be placed in such a way as so it would be able to detect collisions before merging onto the outermost loop of the track.

Our team also started to think about the report and what we could do to simplify the informing process when next year's team takes over. Basically, we want next year's team to struggle less than we did at the beginning of this project at understanding what this project is about and what was done before them. The code from last year's team was lengthy and difficult to understand so this is one objective we have in mind when we leave behind our final updated code. Tim from the mobile app team suggested that we used conventional programming practices in our code as well as creating our own libraries to simplify our code. As of now, we have 1000+ lines of code which could be overwhelming to a newcomer to this project. This is why Steven and I will working in the next couple of weeks to create libraries for our different functions we have created as well as editing our code to follow common programming practices we were taught in past courses.

Week 10

During the past week, my team and I were engaged in testing our controls system on the track along with the software from the mobile app team and the positioning team. Unfortunately, we did not have that much time as we wanted to test on a complete track and some fixes need to be made to ensure smooth operation of the podcars on the track. Our team also participated in our first big event which was the Paseo Prototyping Challenge this past Saturday April 8th. Chris and I made the San Jose Mercury News paper. I was surprised to see a photo of us on the paper but it was a great experience. While at the event, we saw some issues that need to be fixed. We experienced issues with spacing on the track where the podcar slowed down at some locations because of tight spots. Some of the brackets used to house the hall effect sensors kept getting caught on the corrugated metal strip. We also experienced issues with some of the brackets since the hall effect sensors would sometimes miss a reading of a magnet and thus switching of the lever arms did not occur. It was most unfortunate that the software of the app team and the positioning team did not function as it was expected due to not enough time for testing. We also had to constantly supervise the podcars as they were moving around the track to avoid collisions when the podcars merged paths around the outer and inner loops and at the stations. That is another issue we need to address and fix.

Our presentation was postponed until this coming week since the 1/12th scale team had the Paseo event coming up. Thus, our team and I have also been busy with preparing for our second presentation of the Spring 2017 semester. There are some fixes that need to be done to our final designs and more testing needs to be done to ensure that we meet the deliverables assigned to us at the beginning of the academic year. Our team will also begin to contact Gene Nishinaga to see if we can use his software on our system.

Week 9

This past week was our Spring Break but all of the 1/12th scale subteams met throughout the week to work on the project. My team worked in collaboration with almost all of the subteams but more closely with the mobile app team. I joined my team to test our system on a partially built section of the track throughout the week having success as we tested it. The podcar successfully read the magnets mounted on the track as well as the RFID tags which are crucial to our destination designations as well as to switch the lever arms on the bogie. We ran the podcar at different speeds and we met the same results each time the podcar ran around the loop.

Although we only tested the podcar on a small part of the complete track, there were some concerns that we have addressed to the track team regarding tight spaces along some sections of the track, correct magnet placement, and issues with the bends that caused the podcar to destabilize as it made contact with both of the rails again. My team along with the app team were able to test only two different combinations of station-to-station designation due to only having half of the track to work with. We should be able to have at least four working podcars by Paseo that will be controlled through the app team's software. From the progress we have made during Spring Break and from hearing about the status of last year's teams during the same time of the academic year, I am confident that we will be able to have something to demonstrate at Paseo. I am just worried about the rain we are expecting this weekend which could pose potential problems to the track and all of the electronics we will have this coming Saturday. We have a plan B in case the software decides to work against us but my team and I have full confidence in the app team that they will be able to make our system work with their software. The first big event is coming and we will be ready to demonstrate a working project.

Week 8

This past week, not much could be done since my team and I are waiting on other subteams to get their work done so that we can begin testing. We almost have all of the expansion boards built but we had enough to begin testing on the track. Chris can now build the two expansion he could not build since the app team had a bench model with parts from our inventory and I also possessed a bench model. We are about a week away from the first important event where we will be able to showcase our project in front of many people. I am beginning to worry as I am sure other teams are also as well that there will not be enough time to fix any major issues with the project if they arise while testing. One such issue arose this past Sunday and it had to do with RFID. The app team and I believe that it might be the library that we are using but I am currently in the process of looking for other libraries that are compatible with the Arduino Mega that we can test to see which library will give us a repeatable and reproducible reading every time we swipe an RFID card on the RFID reader. We have also begun to modify the summer team's code to work with our components in the case that anything goes wrong and we could have a backup plan.

It looks like our team and other teams will have to spend almost everyday at the shop from now on to get this project fully functional. Even with doubts from other teams, I feel like we will experience some sort of success and I am hoping that we can get at least two podcars controlled through the mobile app team's software. I am more than confident that our project will work by Maker Faire but our current focus is on getting a conditionally functional project by next week. For now, we have to help each other out and do our very best to get this project working.

Week 7

This past week, I began to test with my team both the bench model that we have had with us all project year long and also with the model mounted on the podcar. With the deadline coming up, our team decided to meet up over the weekend at the shop to work on the project and test out our system on the provisional track while the track team builds the rest of the track. This past Sunday proved to demonstrate to us that there is a lot of fixing that must be done not only to our system but with other team's work as well. The track has some details that need attention in order for our system to run smoothly without having to worry that the podcar will get stuck on the track or will fall off.

In addition, Tim from the mobile app team and I have been in constant contact with regards to implementing his system into our system so that he can control all of the podcar's features. On Sunday, I was amazed to see that he was able to control the speed of the motors as well as control the indicator depending on what color the LED should be lighted as. I still have yet to see that the kill switch works as it is supposed to as well as stopping the podcar if there is an obstacle in front of it. Not much as been done to the code at this point since the app team is making modifications to the code so that they are able to control the system from their computer through the use of Xbees. At this point, I am just hoping for the best and hoping that our project is satisfactory enough to have something to show for at Paseo two weeks from this coming Saturday. We will see what happens in the next coming week which means a whole lot of debugging, fixing, testing, and making fast changes to our design.

Week 6

This past week, our team had our first presentation. We felt like we did well on it and hope that our confidence is reflected from the feedback that Eric will give us. Besides the presentation, my team went back to work on the project since the deadline to finish the project is coming up. Chris was tasked with building the rest of the prototype boards and any 3D printing so that we can have these done when testing on the track is ready to begin. Steven and I needed to get the encoders working so that we can set a speed appropriately instead of trial and error. We also needed to start integrating pathing and the controls systems together so that we can start integrating the app team's work.

I was not able to get anywhere with the encoders. I am getting encoder counts but I am not sure what to do with these counts. I know that to find the speed in rpm, we need to the find the difference in the encoder counts in a set time interval and divide that difference by that time interval. The formula for speed is the basic distance over time formula. At this point, I will have to seek help from my teammates and maybe seek the help from Dr. Furman since he does have experience with encoders. This encoder work has left me stumped and frustrated but I am hoping that I will get the help I need to measure a speed from the encoders.

Besides the encoders, I decided to start the process of integration since my work got halted with the encoders. I wanted to at least get the hall effect sensor that will switch the lever arm when it detects a "dumb" magnet to work since the podcars will be in motion at all times without any destination set until a station number is sent to a particular podcar. Since the podcars will be moving around the track, the app team requested that we set four checkpoints on the outer corners of the track on the outside loop so that they know which route is the quickest to get to a station. I have incorporated four more RFID cards that will cause the podcar indicator to light the LED blue as it passes the card.

With less time to work on the project, my team and I are beginning to stress out because there is still much to do in such a short amount of time. We are just hoping that our system will work and that our effort was not wasted into getting a controls system that will actually work reliably and efficiently. With few time left to work on the project, I will continue to integrate the systems together and start testing with the other subteams as soon as our team has a part of the track built.

Week 5

This past week, I was tasked to build a bench model for the app team as requested since they will begin testing their work with it. We encountered some complications while building the bench model but were able to fix it. I gave the bench model to the app team last Friday and showed them how to connect the rest of the components. I built the bench model so that the orientation of the components can only fit one way without them having to doubt themselves on how the component should go on the breadboard.

Along with building the bench model, my team and I were mostly busy preparing for the presentation that we have this week and writing the paper that is also due this week. Unfortunately, these assignments have halted our progress in the project but will immediately resume our work after the presentation. We are almost ready to test but we need to integrate Steven's and my work together so that we can also test the app team's work with our work. Time is almost up and I am hoping that everything runs smoothly with little debugging needed. Unfortunately, that may not be the case but we need to put in all of our effort now more than ever to finish this project. We need to have patience and we need to help each other succeed because in the end this will all reflect on how the 1/12th scale team did overall.

In the coming week, I will be working with Steven to integrate the whole system together as well as getting readouts on the speed of the motors. We will also begin testing so that we have enough time to debug our system. Simultaneously, we will also work with the app team to integrate their work with ours.

Week 4

This past week turned out to be an unsuccessful week on my part. I was unable to get the encoders to work properly to return a speed based on encoder counts from both of the motors. I had to have knowledge on using interrupts to acquire the speed while other code is running. I am hoping my team can provide some support this coming week because I feel frustrated knowing that I tried and could not get an end result for my team.

I was also unable to send commands through the Xbees to simulate what I think the mobile app team will be doing with the app. I researched through different forums and examples online but I was not able to send information through an Xbee and get it to receive on the other Xbee and display it on Serial Monitor of that microcontroller from the receiving Xbee. For the mean time, I postponed any progress on the Xbees since our team will be focusing on integrating our whole system as a whole including the encoders this coming week. I also want to know how the app team will want to use the Xbees to communicate between the microcontrollers and their database on Processing. I feel that our team will be doing a lot of debugging when we start to integrate our whole system together.

In the coming week, I will be preparing for the first presentation that our team will have next week and also be working on the paper that is also due next week. I will continue to work on the encoders and get them working way before next week so that our team can start integrating, testing, and building before the start of the next week. We have four weeks left until the deadline and I am not sure how to feel about that. I am just saving that bit of hope for our team that everything will work out in the end. I will also continue to do some side research on Xbees so that when it comes to working with the app team to integrate their app, we can immediately create a function or write some code that will receive the information through the use of the Xbees and our microcontrollers. 

Week 3

This past week, I was tasked to fix any bugs that our code had as well as get the encoders to work so that our team can determine the speed of the motors. There were issues with getting the LED to indicate the correct status as well as breaking from a loop when the error button was pressed or the podcar had arrived at a station. I was only able to fix the kill switch issue as well as indicating the correct status but in order to break the loop in regards to the station arrival indicator, that is still a working progress. This is due to that pathing needs to be implemented so that that particular indicator will function as desired.

As for the encoders, I had to do some background research and look back at old mechatronics notes I had from when I took the class in order to gain some knowledge about interrupts. In order to use the encoders, I must use interrupts for this application so that we can calculate the speed. Unfortunately, I have not been able to get the encoders to display a value that resembles a proper speed for the motors. In the coming week, I am aiming to get the encoders to work properly and have them ready by the time our team starts to build the systems for the podcars.

Also as requested from Chris, I was able to remake a wiring schematic of our system since we are using new components and a different microcontroller. Chris requested the schematic since he wanted to create a prototype of the final product that will be mounted on the podcar. The last task assigned to me was to do some research and testing with the Xbees since these devices will be the main source of communication between our microcontrollers and the system that the mobile app team created. I have some knowledge of how Xbees function and I have been able to successfully turn on an LED based on what values the microcontroller receives through the Serial Monitor in the Arduino IDE.

In the coming week, I will be aiming to finish any encoder related work as well as applying user input so that commands or values can be sent through Xbee to control our system as will be done through the app created by the mobile app team. I will also be working closely with my teammates to integrate the system altogether so that we can begin testing in about a week or so. Presentations are also coming up so we need to prepare for that too. Deadlines are coming and I feel indifferent than what I had mentioned in past blog posts.

Week 2

During the past week, I have been working on building code for our controls system as my other teammates are also doing. I was in charge of making all of the individual system components work while my teammates focused on pathing and routing. I was able to successfully create the functions that the mobile app team requested from our team. There are some functions that still need to be created which deal with the encoders and the pathing algorithm we have for our controls system.

I was also able to run the motors at the target speed we had specified throughout the project year which was 0.82 ft/sec or 0.25 m/sec. There is a library that allows a user to set the PWM duty cycle using fast PWM pins, instantly changing the PWM duty cycle of an electronic component capable of PWM. The library used was the Timer3 library instead of the Timer1 library which was originally used for the Arduino Uno. Since our team is using the Arduino Mega, another Timer library that is compatible with the Mega had to be used. At the bottom of this post is part of the code that basically runs the motors and stops the motors under certain conditions. The RGB LED has also been incorporated as an indicator of the podcar status.

In the coming week, I will be working with my team to integrate all of our work together so that we can begin testing and debugging soon. We will also begin to build our system at the end of the month which is the anticipated approximate time when all of the small scale subteams will be ready to start testing everything on the track. I am looking forward to seeing our project be a success when it is up and running on the track.


**********************************************************************************
// Function that controls the functions of the system
void controls()
{
     // Changed distance from 30 cm to 15 cm due to pole obstacle
   // LED is Red when statement is true
   if (distance <= 15)
   {
    setStateLED(1);
    setSpeedOfMotors(0);
   }

   // LED is blinking red if button is pressed
   else if (kill_state < 1)
   {
    // Creates a latching button
    kill_latch_state = false;
    reset_latch_state = true;

    // Continues to blink the LED red while latching button is in effect
    // Only way to stop this cycle is to reset Arduino or add another button
    while(kill_latch_state == false && reset_latch_state == true)
    {
      setStateLED(4);
      setSpeedOfMotors(0);
    }
   }

   // Checks to see if the hall effect sensor on the left of podcar read a magnet
   else if (hall_1_state == 0 || hall_2_state == 0)
   {
    setStateLED(2);
    setSpeedOfMotors(580);
   }

   // Checks to see if podcar is at a station
   else if (StationId == 1 || StationId == 2 || StationId == 3 || StationId == 4)
   {
    setStateLED(1);
    setSpeedOfMotors(0);
   }

   // LED should be green
   else
   {
    setStateLED(3);
    setSpeedOfMotors(580);
   } 
}

Week 1 of Spring Semester 2017

Last week marked the first week of class for the second half of the project year. With a tough past semester, I managed to get some needed rest as well as making some progress in our project. Over the winter break, I was able to build code and test it on one microcontroller to determine if our team can use one microcontroller without any issues instead of using two. I was pleased to report to my team that we can transition our whole system to using an Arduino Mega because there seemed to be no interference with any of the sensors or components and the system response was surprisingly fast. The code was also much more condense than the previous code we had for each of the microcontrollers.

During this past week, I was assigned to fix some bugs that our team was experiencing with the LED status indicators as well as breaking from a loop when an indicator turns on without any indication that it will end without resetting the microcontroller. I was successfully able to fix those bugs and our system prototype seems to work satisfactorily. I was also able to assign station numbers to the RFID tags based on some serial number that the RFID reader would read. We are still having issues trying to drive the motors and the servo in the same manner that the past year's team implemented but if in any case, we would have to drive those components a different way and just adjust the performance as we see fit when we test our system.

After this coming week, we will only have roughly about 6 weeks to have a fully functional demo of our project. This leaves little time for mistakes and postponement of the project. With our team leader assigning us roles and tasks on a weekly basis, I am confident that our team will succeed this semester and have demo that will at least make me feel good and proud of. In the coming week, I will be meeting up often and working with my team to finish the pathing and routing of our system as well as getting the motors and the servo to run either in the past year's method or create a different method. We plan to build and test no later than the end of this month so that we have a reasonable amount of time to fix any bugs in our system.