User:Medelen8/ENES100/MRHN Implement 3

Goals for implementation performance, cost and quality
The goal of the implementation section of this project was to make the Lego Mindstorms Robot autonomously navigate through the hallway of the CL Building faster than the group the previous semester did. In terms of cost, the Lego Mindstorms robots are expensive, but they are very good quality and are reliable.

Implementation Plan (task allocation and work flow)
The plan for this part of the project was to mainly manipulate values in the code, and do many tests with the robot in the CL Building hallway. All the code was done in Matlab, as it was done previously, and sensor distance values were changed, as well as motor speeds.

Considerations for human user/operators
The person who is operating the robot needs to be patient and be willing to spend a lot of time repeatedly testing. The majority of this project is testing and trial and error, and editing the code to attempt to fix previous flaws. The operator should also be fluent with coding and Matlab, because all the programming of the robot is done in these and without it the robot is just a pretty paperweight.

The manufacturing and/or purchasing of parts
All the parts that were needed for this project had already been previously purchased and downloaded and are repeatedly reusable. If you need to purchase more NXT parts if one fails, you can purchase them on the Lego website at www.lego.com

The assembly of parts into larger constructs
The robot was preassembled for us, but it consists mainly of the NXT brick (which is what controls the robot, 2 wheels, 2 ultrasonic sensors (one on the left, one on the front), 2 motors (left and right), 4 wires, batteries, velcro, and the connectors that hold all the Lego pieces together. The motors are connected via the wires into the ports that are alphabetical (A, B, or C), and the ultrasonic sensors are connected via the wires into the numerical ports (1, 2, or 3).

The break down of high level components into module designs (including algorithms and data structures)
The way our mobile hallway robot worked was first by opening up MatLab and going to source library then finding the correct number of motors and the correct types of sensors. Finding these things is incredibly simple all that one must do is type into the search bar at the top of the page. Also don't forget about data storage, and the MatLab function. The Matlab function is where the code is written so that part of the process is vital. Then hook up the sensors and the motors to the correct ports and also connect them to the MatLab function to do so click and drag the arrow to the MatLab function. Then once all of this has been set up one must then start the actual coding procedure. First you have to declare all the variables then you have to tell them exactly what you want them to do and when. This can be done by a series of if the statements, make sure to leave comments for yourself because it will help you in the long run. The way our code worked was that the robot would gradually turn left we did this by setting the right motor to 100 and by having the left motor's power at 96 and then every time it would sense the wall the robot would then turn right with the right motor on 40 and the left motor on 100. Our code was relatively simple and easy to manage.

Algorithms (data structures, control flow, data flow)
To put our algorithm in very simple and standard terms we told our robot to slightly turn left and if it senses something to it's left or a distance of 40 to 80 cm ahead it would make a sharp turn back into the hallway to it can just gradually turn back into the wall. If the front sensor senses something in the front > 20 cm ahead it was told to back up and turn to the right. Our code pretty much had the robot bounce off of the wall, making it in a sense follow the wall through the hallway. As you can see it was a very simple algorithm, if you are looking of the code it is down 2 sections below in "The low level design code" section.

The programming language
The programing language that we used for our mobile hallway robot was MATLAB. MATLAB code is fairly elementary and straight forward yet it is capable of some complicated tasks, for example it can react with sensors and react quickly to the sensors response.

The integration of software in electronic hardware (size of processor, communications, etc)
The robot operates by uploading the code from the MATLAB software on the computer onto the Lego Mindstorms NXT brick via a USB cable that is designed for the Mindstorms NXT brick.

The integration of software with sensor, actuators and mechanical hardware
Only 2 Ultrasonic sensors were used, and they were used for the robot to "sense" how far away from the wall on the left it was, and to detect any objects that lie in front of it's path.

Test and analysis procedures
We tested our MRHN multiple times with different results our first couple runs we got the same results as the previous group did with a time of 7:54. But after tweaking the code a little to make the front sensor more sensitive the times went down to an average of 7:39 which is a huge improvement. We also worked on the left sensor being more sensitive but with that our results would range from not finishing to 7:56. So we figured that having the front sensor have a sensitivity at around 40 cm was the optimal length. This was all done with new batteries so our times will certainly vary depending on how much power the batteries have left in them. We tried adding another sensor on the right side of the robot but this only complicated things more and caused the robot to turn around and begin heading in the wrong direction, with the right sensor on sensitivity 10cm we had the most number of times where the robot did not complete the course. Note these test were done during optimal conditions from the same starting point which was right in front of the janitor's floor cleaning machine with the robot facing outwards. By optimal I mean we made sure the doors were close because it would completely mess with our results. Also we only counted the runs were our sensors worked correctly we had a few test runs where the sensors were not sensing correctly.

The verification of performance to system requirements
When all the wires are plugged into the correct ports, and the batteries are fully charged the program performs properly and effectively.

The validation of performance to customer needs
The data collected from testing the robot was inconsistent due to outside interference (people), and starting locations. We determined that without a "fixed" starting point the robot would travel the hallway in a different amount of time each time because it would "Sense" different obstacles and features in it's path.

Possible implementation process improvements
Continue editing the current code, or continue exploring possibilities that we began to explore such as having the robot travel straight down the hallway for "x" number of wheel rotations, or for "x" number of seconds, and eliminate the use of the ultrasonic sensors altogether to get consistent data that doesn't vary because of the people in the hallways.

Next Steps
The next step for this project is to keep on playing with the code and trying to beat the previous groups best time. Also you can experiment where exactly is the best place to start it off with and at what angle, all of this things depend on the code.