User:Medelen8/ENES100/MRHN Design 2

Problem Statement
The task is to successfully navigate a LEGO Mindstorm robot around the first floor hallway of the CL building at Howard Community College. To complete the design phase, the use of MatLab is required in order to design and create the algorithm that will allow the robot to complete the circuit of the hallway off of its own power and ability.

The following tables aids in the understanding on the sketch of the hallway. It uses the measurements of the hallway in various units to better picture the size of the hallway.

Requirements for each element or component derived from system level goals and requirements
The following are requirements that were required for our design:
 * The robot must travel autonomously (no human interaction once started)
 * The robot cannot not be changed from the basic physical construction
 * The use of sensors on the robot are allowed
 * Must use a Arduino or Matlab based robot (In this case we chose the Matlab based robot)
 * Must complete the circuit in under 7 minutes
 * The robot needs to be able to correct itself from obstacles or walls

Alternatives in design
As a group we decided on various methods that could possibly allow the robot to successfully navigate around the hallway. Listed below are the ideas we came up with:
 * Light sensors to follow the ceiling lights around the hallway
 * Color sensors to follow the floor tiles on the floor
 * A compass sensor in order to follow the coordinates of the hallway (N,S,E,W)
 * Ultrasonic sensors to follow the walls of the hallway
 * Time/Distance based code for robot to follow

The Initial Design
In order to determine what design would be the best for what we are trying to do, our group decided the use of a design matrix was necessary. Below is our matrix.

Experimental prototypes and testing conducted during design
The initial code that was created for the robot did not include a backup function. We decided that his feature was a necessity in the event that it got stuck on the obstacles within the hallway such as benches or trashcans. Below is a image of the first code featuring a backup feature. The Simulink diagram did not change based on this new code (As seen below).

After the inital code featuring a timed backup feature was created, it was time to adjust the values that determined how the robot operates. This values include motor speeds, distances picked up by sensors, as well as time values.

Appropriate optimization in the presence of constraints
To reach the final design, it was required that we test the various values for the motors and sensors.In order for the robot to turn to a direction, it required that either the left or right motor be less than its opposite motor. We agreed that the quickest path around the hallway would be a path that was the straightest. So we adjusted the motor values for the slight turns to be only 5 less than its opposite value. For example to turn slight right, we set the left motor equal to 100, and the right motor to 95. This allowed for a very gradual turn that would keep a fairly straight path of travel.To determine when the robot would start initiating a turn to the slight right or slight left, the sensor distances had to be raised from our initial code. The distances required a greater value because the robot wasn't turning away from the wall until it was very close to the wall meaning that the robot was almost at a 90 degree angle once it reached the wall. This caused the robot to back up and turn itself around instead of turning the opposite direction of the wall. Once larger values were placed into the code, this issue dissipated.

Iteration until convergence
The general logic of the code did not change throughout the designing of this code. However, features were added onto the initial and original design code. The timed backup function is an example of a feature that was added onto the initial code. From the beginning of the design the use of ultrasonic sensors remained constant as well.

The final design
The final design for the robot consists of three ultrasonic sensors. One facing forward, one facing left, and one facing right.

Technical and scientific knowledge
In order to complete the design process, it was required that our group became familiar with using Matlab and Simulink. In conjunction to learning about Matlab, it was required that we familiarized ourselves with the LEGO NXT robot along with the various sensors that we could use to successfully complete the task.

Creativity, problem solving, and group decision-making
A major decision that was required by the group was the decision of what method or sensor(s) that we would use to complete the task. We made this decision using a decision matrix as shown at the top of this page. Often during the work process of this design, we encountered problems within our code such as error messages. In order to overcome and solve these problems we had to research our errors and use the debug and troubleshooting within Matlab to find a solution. Some degree of creativity was needed in order to successfully attach the 3 ultrasonic sensors to the robot in a way that wouldn't obscure another sensor or change the effectiveness of a sensor.

Prior work in the field, standardization and reuse of designs (including reverse engineering and redesign)
None of our group members had significant experience with using Matlab or Simulink in conjunction with the LEGO robot. To complete this task we researched the previous group's method of completing this task. We viewed their code and read through it to determine how the code worked with the robot. Seeing a completed code allowed us to understand what we needed to do to complete the task. Their design featured the use of two ultrasonic sensors, so we decided to improve upon that design and add a third ultrasonic sensor to make the robot more efficient at navigating the hallway.

Modeling and/or Simulation
All of the models we used can be seen under the Design section. Diagrams were created from the Mat Lab/Simulink Code and are a direct representation of what was used for the robot.

Performance, life cycle cost and value
The performance of the robot depends mostly on the code that it used for it. Performance could also be affected by the hardware, like motors and sensors that are used. Besides the initial cost of purchasing Mat Lab/Simulink and the robot and parts, it did not cost any money to actually make the robot navigate the hallway. The value should stay the same unless parts different from those provided, or new software, are added.

Aesthetics and human factors
Making the robot look pleasing was not an important factor for this project. However, it was important to keep the all of the wires neat to prevent any interference with the ultrasonic sensors. Also, the weight of the robot depends on how many pieces we add on to it. The speed of the robot is a secondary goal, but  it's good to bear in mind that the robot should be kept as light as possible.

Implementation, verification, test and environmental sustainability
After implementing our design, out robot was unfortunately unable to move around the hallway and avoid hitting any obstacles. During Week 4, we added a command that would cause the robot to reverse after encountering an obstacle in front of it, but it was unsuccessful. The error we received only occurred after adding a parameter, "A", to determine the amount of time for which the robot would back up. For an unknown reason, the errors referred to the a variable for one of the motors, which we never had a problem with before. After extensive research and troubleshooting, we were unable to resolve this error. Several tests were conducted prior to this, and it seemed that everything worked fine, despite being unable to back up properly.

Since the robot does not emit or leave behind any waste, environmental sustainability was not a concern. It poses no threat to the environment.

Maintainability, reliability, and safety
The robot requires little to no maintenance. It may occasionally require parts to be replaced if they fail, mainly the motors, batteries, and wheels. It is the user's responsibility to prevent any pieces from breaking. When manually turning the wheels with the robot was off, it was easy to tell that one wheel did not turn as smoothly as the other, possible due to dirt or a bad bearing, but this was unnoticeable with the robot on and running. With the current code, the robot cannot be relied on to complete the CL Hallway circuit on its own.

Since the robot is so small and cannot reach dangerously high speeds, there are hardly any safety concerns. The only case in which there would be an issue is when the robot is moving along the ground, as someone may step on it and slip, possibly injuring themselves. This is highly unlikely.

Robustness, evolution, product improvement and retirement
Since we were unable to get the robot to move around the hallway, improvements would start with the code to make all of the commands works properly. The code might possibly be simplified so that the commands will not conflict with one another.

If available, motors could be replaced with newer versions so that the robot will move faster. Also, if available, better sensors could be utilized to measure distances more accurately.