Engineering Projects/Robot Hallway Navigation/Implement
Designing the Implementation Process
[edit | edit source]Goals for implementation performance, cost and quality
[edit | edit source]Our goal was to modify the existing code to make it around the hallway in a more timely fashion. During the design phase of the Mobile Robot Hallway Navigation project that we have been working on, it took about 10 minutes to make it around the hallway. Our goal in this project was to decrease the time that it took to get around the hallways to about six minutes.
Implementation Plan (task allocation and work flow)
[edit | edit source]First, we needed to figure out what skills each us in the group had to offer. Graham Knapp knew the basics of how to code with MatLab and Simulink and the others did not. Since this project was highly coding oriented, both Tudor Negrea and Nicholas Kapustin needed to learn the basics of how to code with MatLab and Simulink and it was Graham's job to teach them as well as code most of the Robot's functions. Tudor was assigned the task of making a test in which we could follow and input the Robot's data. Nick helped both efforts of coding and test making and made sure that our logic was sound in all of the solutions.
Considerations for human user/operators
[edit | edit source]There should not be any human interference with this NXT Mobile Robot. The Robot should autonomously travel around the CL Building's hallways without anyone controlling or operating it. The only thing required of an operator would be to place the Robot, to turn the Robot on, and to start the program.
Hardware Manufacturing Process
[edit | edit source]The manufacturing and/or purchasing of parts
[edit | edit source]This robot is easily made out of the NXT Mindstorms Robot Building set. It can be purchased for $294.95 online. There are guides on how to build the base robot without sensors in the kit. To add the sensor, it does not matter how it is done, but the Ultrasonic sensor that looks forward does need to be on the front of the Robot and the Ultrasonic sensor that looks to the left does need to be on the right side of the Robot(right if looking from the backside of the Robot).
The assembly of parts into larger constructs
[edit | edit source]N/A
Tolerances, variability, key characteristics
[edit | edit source]The Robot's parts can work in a very low stress environment. It is only meant to work on a flat floor and around the hallways of the CL Building. If to much pressure is applied to the wheels, they are easily taken off the rim and offset; this would cause the Robot's entire movement pattern to completely change and it would most likely not be able to travel around the hallway in the fashion that it is supposed too.
Software Implementation Process
[edit | edit source]The break down of high level components into module designs (including algorithms and data structures)
[edit | edit source]-
The block format of the Straight Timer Code.
The Simulink block format above shows the basic block format of the Robot's code. As shown, two Ultrasonic Sensor are plugged into the function block "f". These sensors give the function data of how far away an object is from the front and the side of the Robot. A display monitor is plugged into both of these connectors so the Robot output the numerical distance on the Robot's display screen. This helps with troubleshooting and knowing how the Robot reacts to certain distances. From there, the function block connects to two motor blocks. This shows that the output decided in the function affects the speed and direction of the Robot's motors. Also at the bottom of the Simulink format are a row of blocks with letters in them. These are global variables that used throughout the code as data holder's.
Algorithms (data structures, control flow, data flow)
[edit | edit source]The programming language
[edit | edit source]The NXT Mobile Robot is programmed using MatLab. The coding language is basically the same language as Java and C++ in the case that it uses the same words like if, else, elseif, while, for, etc. The only thing that is different about MatLab is that it leaves out some the brackets and semicolons that are used often in Java and C++.
The low-level design (coding)
[edit | edit source]1. This is the code we were trying to work on the make the Robot to move in a straighter path. This code is based on timers that control the turning and adjusting of the Robot. The problem we faced with this code was to get the travelling and the maneuvering parts of the code to coexist with the part of the code that allowed the Robot to turn corners onto the next hallways. The attempts of this worked for a short amount of time before the entire thing just did not work at all. The furthest the Robot got was down 1.5 hallways. All other attempts to improve the Robot made the Robot not even able to make it down the first hallway. This code was a failure in the end because it may have been moving faster than the code from the previous project cycle, but the Robot was not able to make it all the way around the hallways of the CL Building.
function [rightmotor, leftmotor] = f(distleft,distfront)
% This code will be used by a Lego NXT robot to navigate along
% CL hallways' building
%#codegen
global A
global B
global C
global D
global E
global F
if A > 0 %if backing up
leftmotor = -100; % Keep backing up
rightmotor = - 100;
A = A + 0.1;
if A > 1, A = 0; end
elseif B > 0
leftmotor=100; %turn slightly to the right and then return to straight
rightmotor=90;
B = B + 0.1;
if B>.5
leftmotor=96;
rightmotor=100;
end
if B > 1, B = 0; end
elseif C > 0
leftmotor=92; %turn slightly to the left and then return to straight
rightmotor=100;
C = C + 0.1;
if C>.5
leftmotor=100;
rightmotor=98;
end
if C > 1, C = 0; end
elseif D > 0
D = D + 0.1;
leftmotor=100; %turn 90 degrees to the right,
rightmotor=53;
if D>1 && D<2
leftmotor=100; %go straight for a second,
rightmotor=100;
end
if D>2
leftmotor = 38; %and turn 90 degrees to the left
rightmotor = 100;
end
if D > 2.5, D = 0; end
elseif E > 0
E = E + .1;
leftmotor = 55; %turn 90 degrees to the left
rightmotor = 100;
if E>1;
leftmotor = 98; %move straight for 4 seconds
rightmotor = 100;
end
if E > 6, E = 0; end
elseif F==2 %if at value, turn 90 degrees and move straight for 4 seconds
leftmotor = 98;
rightmotor = 100;
E = .1;
F=0;
elseif (distfront>60) && (110>distleft>80);
leftmotor=98; %go straight
rightmotor=100;
A=0;
F = 0;
elseif (distfront>60) && (distleft>110);
leftmotor=98; %turn slightly to the left and then return to straight
rightmotor=100;
A = 0;
C = 0.1;
if distleft ==255 %if the left sensor is maxed out at 255, at 1 to the global variable F
F =F+1;
else
F=0; %if not F = 0
end
elseif (distfront>60) && (distleft<80);
leftmotor=100;
rightmotor=90;
B = 0.1; %turn slightly to the right and then return to straight
A =0;
F=0;
elseif (distfront > 30 && distfront < 60) && (distleft>80);
leftmotor=100;
rightmotor=35; %turn 90 degrees to the right, go straight for a second, and turn 90 degrees to the left
A=0;
D=0.1;
if distleft==255
F =F+1; %if the left sensor is maxed out at 255, at 1 to the global variable F
else
F=0; %if not F = 0
end
elseif (distfront >30 && distfront<60) && (distleft<80);
leftmotor=100;
rightmotor=35;
A = 0;
D=0.1; %turn 90 degrees to the right, go straight for a second, and turn 90 degrees to the left
F=0;
elseif (distfront<30) && (distleft>80);
leftmotor = -100;
rightmotor = -100;
A = 0.1; %if to close to an object in front, back up for a second
if distleft ==255
F =F+1; %if the left sensor is maxed out at 255, at 1 to the global variable F
else
F=0; %if not F = 0
end
elseif (distfront<30) && (distleft<80);
leftmotor=-100;
rightmotor=-100;
A = 0.1; %if to close to an object in front, back up for a second
F=0;
else
rightmotor = 100;
leftmotor = 98; %for any condition not met: go straight
A=0;
end
end
2. This code was the original code from the last project with the slight adjustment of the backing up function activates at 20 cm instead of 30 cm. This code was re-tested to get the time that the Robot could make it around the hallway. With a new set of batteries, the Robot was able to make it all the way around the hallway in 7 minutes and 48 seconds (about 3 minutes faster than the previous project cycle ever got the Robot to go). This proves that fresh batteries substantially change the speed of the Robot.
function [rightmotor, leftmotor] = f(distleft,distfront)
% This code will be used by a Lego NXT robot to navigate along
% CL hallways' building
%#codegen
global A
%if backing up
if A > 0
leftmotor = -100; % Keep backing up
rightmotor = - 100;
A = A + 0.1;
if A > 1, A = 0; end
elseif (distfront>80) && (distleft>80); %if an object is outside of both of the sensors given range of 80 cm
leftmotor=90; %turn slightly to the left
rightmotor=100;
A=0;
elseif (distfront>80) && (distleft<80); %if an oject is within left sensors range of 80 cm
leftmotor=100; %turn slightly to the right
rightmotor=90;
A=0;
elseif (distfront > 20 && distfront < 80) && (distleft>80);%if an object is between front sensor's range of 20 cm and 80 cm
leftmotor=100; %turn sharply to the right
rightmotor=35;
A=0;
elseif (distfront >20 && distfront<80) && (distleft<80);%if an object is between front sensor's range of 20 cm and 80 cm
leftmotor=100; %turn sharply to the right
rightmotor=35;
A = 0;
elseif (distfront<20) && (distleft>80); %if an object is within front sensor's range of 20 cm
leftmotor = -100; %back up
rightmotor = -100;
A = 0.1;
elseif (distfront<20) && (distleft<80); %if an object is within front sensor's range of 20 cm
leftmotor=-100; %back up
rightmotor=-100;
A = 0.1;
else % for all other cases
rightmotor = 100; % go straight
leftmotor = 100;
A=0;
end
end
Hardware Software Integration
[edit | edit source]The integration of software in electronic hardware (size of processor, communications, etc)
[edit | edit source]The Robot is powered by 6 AA batteries in the back of the programmable brick. These batteries power the monitor on the programmable brick, the programmable brick itself, the Ultrasonic sensors on the Robot, and the motors that let the Robot move. This does not currently have a wireless control for communicating with the Robot. The way to change what the Robot does is to go onto the programmable brick is to scroll through the options. The only way to change a current program on the Robot is to plug it into the computer. The size of processor and other internal electronics are unknown to us.
The integration of software with sensor, actuators and mechanical hardware
[edit | edit source]The sensors and the motors on the Robot are all connected into the programmable brick so that a program on MatLab can control all of the parts.
Test, Verification, Validation, and Certification
[edit | edit source]Test and analysis procedures
[edit | edit source]| Test # and name: | Distance it went with out crashing: | Time to reach the corner off the first hallway: | Time to go around the hallways: |
|---|---|---|---|
| #1 Original code | 131.2 feet | seconds | 468 seconds |
| #2 Straight Timer code | 131.2 feet | 121 seconds | Did not make it all the way around the hallway |
| #3 Equation code | 15 feet | Did not make it to the end of the hall | N/A |
In testing the 3 codes, there are some definite results identified:
The Straight Timer code, the code that was based on timers so that it would move in a straighter path, does in fact make it down the first hallway faster than any of the other codes. However, the straight Timer is not reliable because the entire code changes based on the power of the batteries at a given time. This code was also unable to ever get around a corner and onto the next hallway.
The Equation code, the code that has an equation that changes the speed based on the distance from the wall, was an utter failure and was scrapped close to the beginning of testing. All of the tests ended with the Robot in the middle of the hallway going in circles because it would move away from a pillar and then it would be in the middle of the hallway where it would just go in circles because it would not see any objects. This code did not let the Robot even make it down the first hallway so it was not pursued.
The Original code, the code where the Robot moved in a parabolic fashion, from the last project cycle was slightly changed by decreasing the backing up activation distance from 30 cm to 20 cm. In the last project cycle, the Robot faced some issues in which it would sometimes back up unnecessarily because it would only just see the wall and it would back up. The distance was shortened so it would not do this and in doing this, the problem did not show up. Also, with a fresh set of batteries, the Robot moved in a much quicker fashion then previously. The Robot does still move in a parabolic fashion, so this does substantially increase the physical distance that the Robot travels, but in the end, the Original code was still the only code that was able to make it all the way around the hallway.
The verification of performance to system requirements
[edit | edit source]N/A
The validation of performance to customer needs
[edit | edit source]The purpose of this phase of the project was to make the Robot go quicker around the hallway; it should have gone at a pace of 6 minutes to be exact. Unfortunately, the Robot was unable to make it around the hallway at that quick of a pace. The Robot was off by 1 minute and 48 seconds, so the Robot definitely got close to the goal, but the Robot never reached the goal that was set (the customer's needs).
Implementation Management
[edit | edit source]Sourcing, partnering, and supply chains
[edit | edit source]N/A
Possible implementation process improvements
[edit | edit source]This process could have been a bit broader in aspects that could have been done. We were given a the option to make the Robot faster, and since we only had coding, there was not really much else that could be done. If we were given a broader set of things to do, then it would have allowed everyone to do a fair amount of work to keep the ideas flowing. Unfortunately, that was not the case.
Next Steps
[edit | edit source]There are three different paths that can be taken after this project:
Fix Straight Timer Code
[edit | edit source]The first option would be to fix the code. We are pretty sure the logic is sound, but we were just unable to make the code to work. We know there are definitely better ways to do it and that our way has many problems and too many variables, but this definitely a next step path.
Restart Implement Phase
[edit | edit source]Another option for a next step would be to scratch the Straight Timer code and start where the last group finished with the previous code. The entire Implement Phase could be restarted and a new way to make the Robot go faster could be Implemented. We would suggest this as being a pretty good way to fix this project. It is simple and it would give the new project holders some more room to spread their ideas.
Restart from Design
[edit | edit source]Another possible idea would be to make a completely new design from scratch. This would give the new project holders the chance to use there own ideas to make a better starting design for the Robot. They could use sensors that were not just two Ultrasonic sensors. They could use the compass sensor to try to make the Robot go an actually straight direction, or even use the stepper motor idea where there would be a turning heading on the Robot. The ideas could be limitless depending on how the next group takes it.