Week 5

 

In this past week, our team was able come up with three different approaches to how we would sense when switching would take place. All three ideas revolve around the idea of magnets but different sensors will be used that all have their advantages and disadvantages. The three sensors we will consider are hall effect sensors, RFID tags and cards, magnetic sensors (shown below in the mentioned order). The magnetic sensors mounted on the bogie have a great range of use. The only problem with these sensors is the spacing in between the track. The sensors were extremely close to the wall of the track on each opposite side of the bogie and caused scratching of the sensors as the bogie moved on the track. We could not get the RFID tags and cards to work but that will be one of the things my team and I will be working on this coming week. As for the hall effect sensors, we do not own any in the shop and we would like to order some so that we could test the efficiency of all three sensors and decide which of the sensors would work best for both positioning and sensing the magnets mounted on the track. Our team's first choice is the use of RFID tags and cards because it would greatly simplify positioning and sensing of switching. If the bogie could be redesigned a bit so that the magnetic sensors already existent on them could fit better without them scratching on the inside walls of the track, this method could also work satisfactorily.
   
I also helped my team determine where we would need switching to occur and where decision making needs to occur to either make a stop at a station or move to the next loop of the track. We decided that we would need to strategically place the magnets so that if the sensor reads a magnet on the left, the bogie would switch its mechanism from right to left and vice versa. If it reads a sensor on the left, we would need to implement some code based on its destination path if switching to another loop of the track would need to occur. Some of our code has already begun as pseudocode so that we will have a good enough understanding of what the code needs to accomplish.

This week, my team and I have been busy with preparing for our first presentation of the semester and we all hope it goes well. With this mentioned, I was unable to thoroughly go through the Processing software as I said I would do last week but I will make it my priority this coming week so that my team and I can start developing and testing some code so that we can progressively build our code. My teammate Steven had mentioned that he was unable to open the java codes for the Processing software that are on the drive. I am curious to know if I can open the files so that I can study the code and replicate the progress that was made last year. I will look into working with Processing to control a podcar and hopefully be able to get one podcar working with the code uploaded to one of them so that we can fully test the existing podcar and make changes as we see fit. I am looking forward to having our team be done with designing in the next two weeks and start deciding what hardware, tools, and supplies we need to build a successful prototype in the second third of the semester.

Week 4

This past week, we were able to sort out any confusions we had left and we all decided to have a meeting of all of the 1/12th scale subteams to make sure what each one of us was doing. We wanted to see how each subteam was approaching their problem and coming up with solutions so that our designs and other subteams' designs will agree with each other. I am relieved to know that our 1/12th scale team will not have much of a problem in terms of communication between subteams because we established a way so that we can all communicate with each other and at the same time uploading files so that all subteams have access to those files. We decided to use Slack as a way of communication outside of class and the Google Drive as a way of sharing files within the team. We also addressed a common goal of at least achieving 5 podcars running on the track by the end of the academic year.

I was able to download the Processing software that last year's team used to control a podcar from a remote location. From my basic understanding, the software is similar to Arduino IDE in the sense that we can program the same way we do in Arduino but there are other unique capabilities that are available in the Processing software such as color selector, creating fonts, and movie maker. You can also run Java scripts on this software. I was also able to look at last year's code that was used to control the bogie. Based on the code, I saw that there is some familiar code that deals with Xbee usage. I became familiar with using Xbees from a previous project that I worked in during my ME 106 class. I also saw the various lines of code used to determine when the podcar should stop based on the ultrasonic sensor and the lines of code that were responsible for switching the mechanism on the bogie based on the barcodes on the track. Unfortunately, the barcode sensing idea will be removed and will be replaced with a more robust and efficient method that might be along the lines of using magnetic encoders to track the position of a podcar and also determine when it should change the orientation of the bogie mechanism.

In the coming week, I plan to understand more of the code and also start to replicate what was achieved last year by also implementing our idea. We want to be able to control the bogie with the Processing software and also by running the code on a bogie to see how it works. Presently, I will only focus on increasing my knowledge of how the code works and start manipulating the code so that we can implement the magnetic encoder idea.

Week 3

We finally got some sense of clarification on what was expected of us for this project. Up until this point, I had no clear plan of action on how to improve upon what last year's bogie controls team had done. We have our deadlines now and I was able to work with my team to set up a working schedule of what we wanted to accomplish by set dates. My team and I had a brief meeting with Eric and Professor Furman to sort out any questions we had about the project and what course of action we should take to improve the design of the bogie controls. My team had partly agreed to replace the barcode sensing system with magnetic encoding to be able to track the position of the bogie as well as determine whether the bogie should switch its path. This idea arose from a team that wants to completely redesign the whole track and incorporate a magnetic strip on the track that we could use to accomplish our goals for bogie controls. I attempted to look at other methods of sensing when the bogie should change its path. I looked at motion sensors where we can use ultrasonics or infrared light to determine if the bogie has interrupted the sensor to determine what action it should execute. I found that it might be hard to implement these sensors on the track and it might cost more money to actually buy the sensors and any other hardware we would need. Instead we would just use what we have and simplify the design.

Apart from deciding partially what my team wanted to do, I looked at the archives for our part of the project and saw that the major flaw of the project was the communication between groups. Our team and other teams decided to create a folder on Google Drive with everyone who is involved in the small scale project so that we can hopefully improve the communication gap that was present in past team's work.  I also looked at the code that was used for the barcode sensing system and I was overwhelmed at how complicated the code appeared. I am hoping we acquire some help with building the code or at least simplifying the code.

This year, I am hoping I can improve on my communication and technical skills because I am terrified of public speaking. Communication is key in this project. My fear of public speaking cannot be a reason why this project cannot become a success and I plan to leave an excellent footprint for future groups. From a past ME 106 project, I gained some knowledge on using Xbees and using other versions of the Arduino such as Arduino Pro Mini and the Adafruit Pro Trinket. I am hoping that the knowledge I learned from that project, I will be able to apply to this project in some way if applicable in the case of shrinking the hardware to smaller, efficient components or communication between our hardware. I am looking forward to seeing this project become a success and seeing a working small scale model of the project.