User:Medelen8/ENES100/MRHN Implement 2

Goals for implementation performance, cost and quality
The goal of the implementation process for this project was to make the LEGO Mindstorm robot navigate around the hallway of the CL building faster than the group last semester had done. The LEGO Mindstorm robot is pricey, when searched the three Ultrasonic Sensors on it can cost about $52.

Implementation Plan (task allocation and work flow)
The implementation plan for this project was not set in stone. Our group did not know if it was best to implement the design of using three of the Ultrasonic sensors, or two like the working model had used. If three ultrasonic sensors were used, starting from scratch in MATLAB and Simulink would have been ideal since we had never used the program before. Aid from Professor Edelen on a crash course on how to use MATLAB and Simulink was necessary before beginning programming for the robot. Each member worked together to try and make the robot functional when it came to creating commands in the MATLAB software and tried to come up with creative ways to solve problems that came up (ie, full measurements of hallway including obstacles, necessity of a third sensor, etc).

Considerations for human user/operators
The operator should be savvy on how to use MATLAB and Simulink, as well as basic knowledge of uploading the code you create to the robot using a square ended USB cable. The operator should also be patient! A huge chunk of time for this project was simply trial and error-- seeing what worked and what did not work and thinking of ways to fix it.

The manufacturing and/or purchasing of parts
All parts used were already purchased/downloaded and available to the user/operators disposal. If new parts are needed, the link above shows where to buy new ultrasonic sensors should one of them become dysfunctional. Should you need a new LEGO Mindstorm NXT the link will direct you to a website where you may purchase one.

The assembly of parts into larger constructs
The robot was already preassembled when we were assigned the project, however it consists of the LEGO Mindstorm NXT, three ultrasonic sensors, and two motors (left and right). The two motors connect to the alphabetical ports on the LEGO Mindstorm while the ultrasonic sensors connect to the numerical ports on the LEGO Mindsotrm NXT. The motors and ultrasonic sensors can be easily removed and placed back on with prongs that fit snugly into holes on the LEGO Mindstorm NXT to keep them from moving. Once the robot is constructed it is a good idea to take all of the wires from the parts and use a Velcro strap to hold them in one place so they do not get in the way of the sensors and distort the data it is receiving.

The break down of high level components into module designs (including algorithms and data structures)
Use of MATLAB and Simulink software are the only way to make the robot functional. To begin, start by opening the MATLAB program on the computer and click "Simulink Library" on the top bar that appears when it has fully loaded. Then select the button in the left corner of the window that appears that has the Simulink library image with a + sign over it, this allows you to create a new model. Then you drag each component that is involved in the project into the new model-- in this case it would be the MATLAB Function (which allows you to write a code for the LEGO Mindstorm NXT) two-three ultrasonic sensors, and two motors. Double click on each component to make sure each one is assigned to the right port or you will receive an error message when you try and run the code. Either copy and paste a basic code in or begin writing your own by double clicking on the MATLAB Function component on your map. After you have done this, drag the arrows that appear from the sensors to the MATLAB Function, and then the arrows from the MATLAB Function to the two motors. This is basically saying take the data that the ultrasonic sensors sense, have the code you write take the data and interpret it, and tell the motors what to do with said data (turn left or right, slow down, etc). Your end result should look something like this:



The programming language
MATLAB is a fairly simple program to use when you spend a few hours learning how to use it. It simply needs a circumstance and a command to follow it. For example, if you want the robot to turn right when it is approaching a wall to its left you would give it a certain amount in centimeters to go before it turned away. if lsense < 20 rmotor= 90 lmotor= 100 this is telling the robot that when the distance between the left ultrasonic sensor and the wall is less than 20 centimeters, make a slight right turn away from the wall to avoid hitting it.

The low-level design (coding)
There is a component in the MATLAB software that can tell the robot to back up when it hits an obstacle. This component is called "Data Store Memory" and can be found in the MATLAB toolbar at the top when you click "Edit", it should be set up like this:

Click apply and you should be good to go with setting up the ability for the robot to back up because somehow yes, it still does manage to hit a wall. We tried out several different codes because we noticed that the left turn the robot was making to go back towards the left wall if it strayed too far away was way too sharp, causing it to either spin in a circle, hit a wall, or spend too much time adjusting itself to come closer to the wall rather than making forward progress. After editing the previous semesters code, these are the ones we tried: This code worked great for the LEGO Mindstorm NXT robot to get down the hallway quicker, since the turn was not as sharp it spent much less time readjusting itself for overcompensating a left turn to get closer to the wall again, however the turn was too gradual to make it around the left corners necessary to get around the hallways of the CL building. Though the difference in the left turn was only by 2 units, it made a huge difference. Not only was it able to get down the hallway faster than before but it was also able to make just enough of a left turn to get around the corners of the hallway. '''NOTE: The times it takes the LEGO Mindstorm Robot to get around the hallway are all very conditional dependent on where it starts in the hallway and when the robot decides using the commands given to turn around or away from on obstacle. For example, several tests were ran with the left turn being set for the left motor at 100 and the right motor at 93; one test was about 8 seconds faster than the right motor being set at 95 however it could also be slower depending on if it hit an obstacle and needed to back up and readjust itself costing more time. This is why it is important that more edits be made to assure more accurate times.'''

The integration of software in electronic hardware (size of processor, communications, etc)
The code from the MATLAB software was uploaded to the LEGO Mindstorm NXT Robot with a USB Cable with a square end that was compatible with the robot.

The integration of software with sensor, actuators and mechanical hardware
Only two Ultrasonic Sensors ended up being used in this run of the project-- it was decided between Justin and I that a third one was not yet necessary until we were sure that the robot could not go any faster with the two sensors on it and it can.

Test and analysis procedures
To test each code, it was applied in the MATLAB and Simulink software, "run" to check for any errors, then "ran on target hardware" (LEGO Mindstorm NXT) to download it. It was then turned on and allowed to run freely through the halls of the CL Building, avoiding obstacles as it went. The tests ran this time around with the original code as a baseline varied from 7 minutes and 48 seconds, we ran three tests. Test One: 7:52 Test Two: 8:05 Test Three: 7:56 We believe that the slight increase in time is due to the batteries running low causing the motors to not go as fast as they could normally. After changing the value of the left turn, we got the times listed below: Test One RMOTOR 95: 7:58 Test Two RMOTOR 93: 7:52
 * The RMOTOR at 92 was the same time as it being at 93

The verification of performance to system requirements
All components when connected and programmed correctly operate functionally.

The validation of performance to customer needs
Technically speaking, during some of the tests the robot did run faster. However, it was not a significant difference; a mere few seconds on any given test separated our time by the previous semesters time of 7 minutes and 48 seconds. More testing and edits will need to be made to have a significant time change in the amount of time it takes for the robot to get around the CL building.

Possible implementation process improvements
More edits in the code-- changing numerical values on the ultrasonic sensors for quicker reactions to obstacles in the way and addition of the right sensor. The right sensor may prove useful in helping the robot maintain a straighter path however it might also get in the way when the robot is underneath benches, backing up, or going around obstacles such as people or trashcans. All three of the sensors were made functional at one point, however the robot would follow a wall for a short period of time then begin to spin itself around in a circle for several minutes before being turned off to try and figure out what the issue was. Test 1 Test 2

Next Steps
The next steps for this project are to just keep on testing. It does take a lot of time, energy, and patience. Determining what will be a good value for the sensors to decide when to take action is almost a guessing game, you really need to see what works and what doesn't. "I have not failed 1,000 times. I have successfully discovered 1,000 ways to NOT make a light bulb." - Thomas Edison. Just because you try 100 different values for the sensors and they don't work does not mean that you failed the project, it just means you narrowed down the possibilities and that you are getting closer to the correct values.