User:Cpecenka/p2weeklyupdate

Project Preference
The project I was assigned to next is the mobile hallway robot with Justin as my partner.

Problem Statement
The mobile hallway robots purpose is to make a circuit around the hallway in a timely manner. A group from last semester made the robot work however it was slow, our group is going to try and make it faster. We are in the implement phase of this project.

Project Plan
The plan as of now it to replicate what the group last semester did to understand what they did to make it work and see what they were looking at. The next step is to learn how to use Matlab and Simulink in order to control the Lego hallway robot. The last step is to implement what we come up with and hopefully have the robot in working order in 4 weeks.

Week 1 Narrative
Our CDIO report page has not been created so tasks were not "formally" assigned however my partner and I quickly got to work. After taking a quick look at what previous groups had done a meeting was set up with Professor Edelen outside of class before seminar on Thursday for a brief crash course on how to use simulink and matlab. During the meeting it was learned how to put commands into simulink and how to upload it to the lego robot and learned (kind of) how to write code in matlab to give the robot the commands the ultrasonic sensors will need to detect obstacles and adjust itself accordingly by using a global value and changing how fast or slow it goes on either motor of the robots wheels to make turns and back up. This week was about learning a little about the robot and understanding how to get it working.

Week 2 Narrative
This week, we originally thought it would be a good idea to take off one of the sensors because we thought the robot might have been getting "confused" with too many commands, however we shortly realized the third sensor would be necessary in order to make progress with the goal of making the robot go faster. So, in keeping with the previous groups design we took their hallway measurements from the CDIO report the group created and had the idea that if the robot had commands to not go "X" amount of centimeters away from the wall that it would follow a sort of path and only zigzag within that path, decreasing the amount of time it would take for it to get close to a wall and turn itself around only to get close to another wall and spend more time adjusting itself. Taking the measurements from the hallway we attempted to write our own code, starting with one sensor at a time. Professor Edelen stayed after class for a few minutes to help with getting the left sensor operational however then we were left to our own devices. Justin and I got the right and front sensor working as well, however not in the way we wanted. The robot would go straight for a period of time then it would being spinning in a circle unable to find a wall again, we suspect this is because of the pillars that extrude into the hallway. More measurements will be taken and the codes will be adjusted in MATLAB and Simulink this week to try and accommodate the obstacles not accounted for. Pictures below are notes and work done in the past week.

Week 3 Narrative
This week Justin and I continued trying to write code in MATLAB to add on what we had working, which was the robot going straight and then spinning in a circle since it lost the wall at some point while it was on(video in Justin's weekly update from week 2). We thought this week that it would be quicker and much less painless to accomplish the task of making the hallway robot faster by implementing the code used by the group from last semester and adding the right sensor and appropriate commands to keep it on one track. Whenever we copy and pasted the MATLAB code into the MATLAB function in Simulink we kept getting error messages because there is a function called "Data Store Memory" that we did not know how to set up, Professor Edelen offered to help us with it but when we went to his office hours on Thursday he was not there. Since this was the plan for the week, we hit a bump in the road. So instead Justin and I took measurements of the entire hallway of the CL building, including the measurements of how wide the obstacles in the hallway were (pillars, benches, display case, cutouts for where door are, etc.) to make plugging in numbers for the left and right sensors easier to estimate. With this information, we were able to get the robot to go straight while only straying a few centimeters to the left or right before turning into the wall for some reason, probably because we did not get around to adding commands for the front sensor before it was time for the seminar.

Week 4 Narrative
This week Justin and I got the previous groups code working by setting up a model in simulink and applying the previous groups MatLab code to the LEGO mindstorm robot. An issue we had the previous week was not knowing how to get something called "data store memory" command being able to function, we kept getting error messages when we tried to run the model. We asked professor Edelen how to set it up and he pointed us in the direction of an online tutorial he had sent Justin the previous week. After following the directions on it we were able to set up the command and make the previous groups code operational. What the data store memory does it let the robot know when to back up when it runs into an obstacle, (since the code loops every .1 second there's the possibility that the sensors miss when it needs to turn away from an obstacle) we ran tests and found that the robot made it around the hallway in 7 minutes and 52 seconds. We also found that the time it takes to get around is subjective depending on where it starts-- for example it won't run into a bench if it starts in a different place than to did when it would run into a bench. We ran a few tests and the times did not vary much from each other. We believe that is because the batteries may be running low which slows it down.

Test One: 7:52 Test Two: 8:05 Test Three: 7:56

After making observations about the troubles it was having, we decided to make a few changes to their code. We noticed that anytime it strayed too far away from the wall to it's left, it would make a sharp left turn. This was a problem because it was taking time away from forward progression and it was taking too long to find a wall which added to the amount of time it took to find the wall and turn around. We fixed this by making the turn less severe, changing the original value of the LMOTOR from 90 to 95 and keeping the RMOTOR at 100. (100 being full speed). The problem we had with this now was that the left turn it made to get around the corners was too wide, however it did move faster and took less time to get around the hallway (7 minutes and 58 seconds) however not fast enough for a significant change in the time to declare we made it faster. The wide left turn made it so the robot sometimes ran into the wall and had to back itself up, in turn taking more time to get around the hallway. We kept playing with the value of the left turn with the information that 90 was too sharp and 95 was too wide. We found that 92 and 93 as a value for the left motor helped it maintain a steadier straight path which helped with the time, again he owner not enough of a significance to declare success.

Test One LMOTOR 95: 7:58 Test Two LMOTOR 93: 7:52 Test Three LMOTOR 92: 7:52

Again, the time it takes for the robot to get around the hallway depends on where it starts and when it decides to turn since the range on it's commands is between 20-80 centimeters. Perhaps with a net set of batteries and making adjustments to the range before it turns will help speed it up.