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.
Wednesday, February 22, 2017
Tuesday, February 14, 2017
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);
}
}
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);
}
}
Tuesday, February 7, 2017
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.
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.
Wednesday, December 7, 2016
Week 15
This week has been the most busiest week ever. I am glad we have met our deliverables this semester and have most of the final report done which is due next week. We finally got our demo working for the last class meeting and we have also prepared for our representation. I am glad I worked well with my teammates this semester and without their help, we would have not met the goals for this semester. I feel like we accomplished what is necessary for this semester and that feels good.
I was beginning to get frustrated when our code wasn't working but with the help of Chris and Steven, we were able to get a working demo. We ran into some complications but we will have the break to fix those complications. We only have the final report to do for this semester. During the break, much focus will be on getting the pathing algorithm working as well as fixing any bugs and complications we had this week. I feel that next semester will be successful if we get our code working. I feel confident about our design and it will work.
I was beginning to get frustrated when our code wasn't working but with the help of Chris and Steven, we were able to get a working demo. We ran into some complications but we will have the break to fix those complications. We only have the final report to do for this semester. During the break, much focus will be on getting the pathing algorithm working as well as fixing any bugs and complications we had this week. I feel that next semester will be successful if we get our code working. I feel confident about our design and it will work.
Wednesday, November 30, 2016
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.
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.
Wednesday, November 23, 2016
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.
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.
Tuesday, November 15, 2016
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.
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.
Subscribe to:
Posts (Atom)