User:Gknapp2779/Project3

Please copy this form to your user page.

Please delete the italics (delete the two quote marks) when filling out this form.

Project Preference
''Your class negotiated 5 or 6 projects to do the rest of the semester. Please rank, in order of preference, your highest through lowest project names.''

Problem Statement
My group and I will be working on automating a NXT Lego Robot to travel all the way around the hallway. In this project phase we will be working on the Implement part of the CDIO Outline.

Project Plan
Over the next four weeks, my group and I will be focusing on making the NXT Lego Robot travel around the CL building hallways in at least 6 minutes.

Week 1 Narrative
Brain Storm

This week, my group had to think of some ideas on how to make the Robot travel around the CL Building's hallways faster. The previous best time that the Robot got when travelling around the hallway was about ten minutes long. Over these next four weeks my group and I must think of some ways to make the Robot faster without completely changing the design of the robot.


 * 1) Physically make the Robot faster. Professor Edelen said that even though the robot moves at its maximum speed, there is a way to implement gears into the motor system to make the Robot faster.
 * 2) Make the Robot go straighter and add timers to the code to control the turning.
 * 3) Add a function to the code that varies the turning speed based on the distance from an object that the Ultrasonic sensor detects.

Analysis of the Ideas


 * 1) To make the Robot physically faster with gears would help shorten the time that it takes to make it around the hallway, but that may not be fast enough. The Robot still swerves through the hallways a lot and even with a physically faster Robot, it may not make it all the way around the hallways in six minutes. This could also be a problem because it could make the Robot to fast to work with the current coding. If we were to use this idea, we would need to use another idea as well.
 * 2) Making the Robot go straighter would substantially decrease the amount of time that it would take for the Robot to make it around the hallway because currently the Robot swerves substantially. Theoretically, if we were able to stop the swerving, or at least greatly decrease the amount of swerving, the Robot's travel time should be about half of it's original travel time. Using timers to do this would make it so the Robot could keep a similar design except the Robot would move straighter and the turning would activate more steadily and smoothly. The main foreseeable problem this faces is how to make the Robot go around the corners of the hallway.
 * 3) Professor Edelen came up to me and gave me the idea of having one function that would control almost all of the functions by having an equation that decides the turning speed based on the distance that the Ultrasonic Sensor detects. This is a very good idea, but I feel like this will have a similar parabolic motion to the current code of the Robot. I will attempt to make this equation just to test it out, but I am not sure.

Possible Decision

I will first attempt to make the second idea with the timers work. The timers will work similarly to how the timer works with the back up function in the fifth design and the final design of the last groups project phase. The difference is that in the new timers the function has if-statements that work within the timer. For example, if the Robot is getting to close to left wall, the Robot will turn slightly to the right and then turns slightly back to the left. This way the Robot turns away from the wall and returns back to a straight path. This should fix the problem with parabolic motion through the hallway. A timer like this works for getting to close to the wall, getting to far away from the wall, and for getting to close to an object in front of it. The difference with the timer for turning around an obstacle in front of the Robot is that the Robot turns sharply to the right, moves straight for a bit, and then turns back to the straight path. It took a long to get the correct value for speed and times for these functions, but eventually we got the timer based turning functions to work.

Problems

The problem with the timer based idea is that it has a few problems. One of the problems is that when one of the timers turns on, the Robot does not take notice of any of the other functions while one of the other timers is going on. This is a big problem because if there are several obstructions coming into the Robot view at once, The Robot will turn on one of the timers and possibly run into an obstruction that another function should have taken care of. Another problem with this idea is because the Robot's default is now to go straight. The Robot does not yet have a way to turn the necessary amount to make it around the corners of the hallway. This idea may be a red herring but I will keep working with this idea and compare it to the turning based on distance idea and choose which my group thinks is a better way to make the Robot travel quicker around the hallway.

Week 2 Narrative
Equation Code

For the second week, it was my job to try to make an equation that completely controlled the way the Robot turned. I did the calculations that should make the function work ended up being "leftmotor = 75 + .14*(80 - distleft)". I got this code by having the inequality : abs(100) >= 75 + C * (80 - 255). I plugged the absolute value of 100 into the leftmotor variable to represent the maximum and minimum speeds that the motor could have and I plugged 255 into distleft because that is the maximum distance that the Ultrasonic Sensor can detect. Solving for "C", I got the value of 0.14. In the code I had this equation as the value of the left motor and the right motor had a constant value of 75. That way the right motor keeps a constant speed and the left motor changes depending on how far away from the left wall the Robot is.

Equation Code Faults

We had a run of the equation code and it did not work in the slightest. The problem with the this code is that it moves in a similar parabolic movement as the previous and successful design. So even if it did work, it would not be going any straighter than the previous design. However, it did not work because of the angle it would move at. Since the closer Robot is to the wall on the left, the quicker it turns to the right; so because it does this, it quickly turns with an angle that the Ultrasonic Sensor does not measure so it quickly and sharply turns to the left. At this point, the Robot is in the middle of the hallway and the Robot just goes in circles because it never sees any thing. I tried adjusting the C value and constant value of the right motor but no matter what I did, the Robot always gave the same results of circling in the middle of the hallway. So this idea will probably be scraped.

--I only just thought of this idea, but maybe I should make it so when the maximum distance value is plugged into the equation, the Robot only turns slightly to the left. This might give the right equilibrium speed for the Robot.

Timer Based Code

For the timer based Code, I changed the Robot's timer's to only occur for a second each so it does not affect the other situations. I also made it so the turning left timer made the Robot go a bit more to left. This way it does not run into the opposite wall. When I tested it this way, the Robot made it all the way down the hallway, but I had not yet made a way for the Robot to make it's way around the corner to the next hallway. So, I added another timer that would make the Robot turn 90 degrees to the left if its range was 250 to the left and then the Robot would move straight for five seconds so the Robot would be in range of the next wall.

Timer Based Code Testing

I tested the Robot with the new corner turning code but it did not make that far. Because the Robot was constantly swiveling down the hallway, the Robot would be at an angle where there would be nothing detected by the left Ultrasonic sensor, so the Robot would turn 90 degrees and move into the wall. From there I tried to make a code that would allow the Robot to activate the corner turning function only if it does not see an object to the left for a certain amount of time. I tested it with what I thought might be the right code, but it did not work as well. The robot still turned prematurely of the corner, but I looked at the screen to see what the sensor was detecting, and the sensor did detect a value less than 250 during the time, but it still turned 90 degrees to the left and into the wall. I am sure my idea is sound, but I do not know how I am supposed to make a code to do such a thing. If it is possible, I will probably have to use while loops or some other loop to do this. I will try to inquire information about how this might be possible.

Week 3 Narrative
This week's work was much different than any of the prior weeks. Since Thanksgiving was on Thursday, HCC was closed and I was out of town and away from technology from Thursday through Sunday. So the only days that I could physically work on the Robot were Monday and Tuesday this week.

Plans

The plans for this week was to try make a function that would allow the robot to turn the corners of the hallway. To do this I would try to have a different function that would be called. This would physically be another function block in the Simulink format. This function has a while loop, and the function basically returns a value if the Robot does not see an object for five seconds. This returned value would activate a timer that would turn the robot ninety degrees and move it forward for five seconds. The five second of moving forward would give the Robot time not be out in the middle of the hallway and see a wall to the left of the Robot; this way the Robot should not turn again into the wall.

As seen in the Simulink Picture, the format has the Left Ultrasonic sensor give data to both function f and function g. The value from function g then should be plugged into function f for one of the timers.

If this plan does not work, then I am afraid that we might need to just slightly adjust the original code to make the Robot go slightly faster. This is not what we want to have to come to, but it may be the only way to make the Robot successfully travel around the hallway at a quicker pace.

Testing

In attempting to make another function that the original function would call, it took a long time to fiddle with the code so the Robot would allow me to download it into the Robot. When I finally had a code that would actually run, the Robot did not work properly. It had a new problem that it would run the while statement of the new function completely before taking any of the other actions into consideration. So the range would be 255 and the while loop would start, but instead of considering the other statement at the same time, the Robot just went straight. Since it didn't see anything at the time, and it continued to not see anything from going straight, the Robot did its 90 degree turn and went straight into the wall. I continued to try and change things around and adjust the format of the Simulink, but I could not see to get any results different from these. All of the tests were failures.

However, what I can take from this is that I can call another function in Matlab. I am not sure how to make both function run at the same time, but it is possible to call another function into the existing one.

Week 4 Narrative
This week I was trying to improve upon the Robot's code that would make the Robot travel faster around the hallways of the CL Building.

Fortunate Mistake

Through a frustration at the timer based code that was supposed to make the Robot go straighter, I decided go back to the previous code from the last project cycle and I tested it again. I slightly changed the the code by making the backing up function activate at 20 cm instead of 30 cm. I also changed the batteries. When I turned it on and started the code, the Robot was going much faster than it did the last time. I timed the Robot and it traveled all the way around the hallway in 7 minutes and 48 seconds. This time is about 3 minutes faster than the previous code. This made me realize that the batteries do in fact make a substantial difference when running the Robot.

Back to the New Code

With the knowledge that the battery power affects the Robot, I went back to working on the timer based code. I made many slight changes to the code. For Example, I would slightly change the turning speed of the Robot, I would slight change the duration of turning, or I would change the distances in which each function was activated. I made these slight changes constantly throughout many tests. To make the navigation and maneuvering codes coexist with the turning down the next hallway code, I realized all I had to do was to add a counter to each part of the function. I used the global variable F to do this. In each part of the function, if the Robot's left Ultrasonic sensor was 255, F would gain a counter; if the Robot's left Ultrasonic sensor read any other number, F would go back to 0. If F equaled a certain number, the turning down the next hallway function would activate.

Results

Through much tedious work, I did end up getting the Robot down one length of the hallway and to turn the corner onto the next hallway. Unfortunately, the Robot got stuck halfway down the next hallway. I made some more alterations and changed the batteries again, and then the Robot went terribly wrong. It did not even make it down the first hallway. The problem was that the batteries affect the entire timer code. Since the Robot goes faster, and the Robot turn's based on time, the Robot was turning much further than it was supposed to, so the entire process was a waste of time. The only way to have valid results is to use a fresh set of batteries after each run, and that would be a terrible waste of batteries, so that technique was not used.

Final

In conclusion, the timer code was a complete bust and would not end up working the way it is. It is too complicated and it relies on too many factors. I would not suggest using this format for future design because it is not the best way that is could be done. In the end, the code from the previous project cycle was much better all around. The only thing that the timer code excelled more in was being able to go straight. If I were the next holder of this project, I would suggest going back to the design faze to make a better and more effective design that used more than just two Ultrasonic sensors.