User:Medelen8/ENES100/MRHN Design B

Problem Statement
Design and implement control software that enables an existing a LEGO Mindstorms robot to autonomously navigate the hallways of Howard Community College's CL building.

Requirements for each element or component derived from system level goals and requirements
As long as the following requirements are fulfilled, the design of the software is left to the programmers:
 * Robot's physical design cannot be changed;
 * Sensors may be added to the Robot to help Robot make its journey around the hallway without running into obstacles.
 * Use Matlab and Simulink to design and code the Robot's actions;
 * The Robot should be able to avoid obstacles.
 * The Robot must eventually be able to travel all the way around the hallway(the given course of travel).

Alternatives in design
There are several ways for the robot to navigate along the hallway:


 * We could use a compass to follow a bearing of the hallway for a certain distance(measured by the amount of rotations of the wheels times the circumference formula). When the Robot went a certain distance, we could change the bearing of the compass sensor to have it go down another hallway and repeat this for each hallway.
 * Mapping the dimensions of the hallway into a code that the robot will use.
 * Use a servo motor attached to an Ultrasonic Sensor so the servo motor will turn the ultrasonic sensor, and the robot can make a decision of where to go based on the readings it receives.
 * Use two ultrasonic sensors: one left to follow the interior wall, one in front.

The initial design
In this model, an ultrasonic sensor has been placed on the very front of the Robot looking forward, and an Ultrasonic sensor has been placed on the left side of the Robot looking to the left. The purpose of this design is for the robot to follow the inside wall of the CL hallways all the way around. While doing this, it should avoid obstacles to the left and in front of the Robot. However, when one of the sensors read a distance that does not trigger a turn (such the corner space between a pillar and a wall), it moves into the corner and gets stuck. This problem is noticed in the given video. (insert video here).

The main problem with this design is that it the Robot gets itself into a corner before the sensors detect that it is there, and the robot does not have enough time to turn around the the obstacle, so it gets stuck.

The use of two ultrasonic sensors is favored for its simplicity and its feasibility:
 * The robot understands distance in terms of wheels' rotation. Since the robot is not moving straight, it is difficult to map the dimensions of the hallway.
 * The compass is not really needed, especially with the robot not moving along a straight line.
 * Implemeting the Servo motor will be a good feature if the hallway was not the required way but instead any way.

VIDEO

Experimental prototypes and testing conducted during design
Robot Design Two

The fifth Robot design kept the same physical design, but the code was a much cleaner way to write it than the fourth designs code. It keeps the idea that the Robot should back up if an object is to close to the front of it. The problem with this code is that when activated, it just goes backwards and it never takes the other functions into consideration. This happens because the code turns the back up function on by increasing our global variable A, but none of the other functions turn this variable back to 0(the value required for the Robot to not back up). This function is close to what we want it to be, we just need to find a medium for which the Robot will use all of the functions when they are supposed to be used.

Appropriate optimization in the presence of constraints
In order to determine the conditions that will make the robot turn using the ultrasonic sensors, different ranges were tested:


 * To turn sharply to the right when an obstacle is within 80 cm from the front sensor, a speed of 100 for the left motor and a speed of 35 for the right motor is used. When the speed of the right motor was 50 or 40, the robot was not able to turn sharply enough to get around an obstacle, so it would get stuck.
 * For the backing up function, a 30 cm distance in front a front sensor was used because a distance of 10 cm or 20 cm did not give the turning function enough space for the robot to maneuver around the obstacle. The robot would turn into a corner at weird angle and be stuck.
 * 80 cm is the left Ultrasonic sensor's maximum distance for it to sense an object on the left side and make the robot turn slightly to the right. This value was chosen because the pillars that are all along the walls protrude about 60 cm from the wall. 80 cm gives the robot plenty of space to go around the pillars. 80 cm is also roughly the middle of the hallway. When increasing this distance, the robot's path is much to parabolic and has a chance to just move in large circles in the middle of the hallway.
 * The timer that was added is programmed to have the robot back up for 1 second if it gets to close to an object in front of it. The value of 1 second was chosen because any value greater than that causes the robot to back up for a pointlessly long interval. If the value was smaller, the robot might not have enough space to allow the sharp turning maneuver around the obstacle.

Iteration until convergence
Up to design four, the codes above do not have a proper syntax and the logic might be difficult to pass to the Operate team. A flow chart was drawn and the code rewritten accordingly (See below). The timed back-up feature was also optimized.

The final design
The final physical design of the Robot uses the same design used in design three. The Front Ultrasonic sensor is on the lower front of the robot to detect any obstacles in front of the Robot. It is placed close to ground to make the Robot more concise and so it might detect smaller obstacles in front of the Robot. The Left Ultrasonic sensor is on the right side of the robot and it points to the left. This is used so the Robot can follow the inside wall all the way around the CL building's hallway. It was placed on the right side of the Robot so it would not get caught on obstacles when try to go around them. With the left Ultrasonic sensor on the right side it is both concise and convenient. If a program needs to be accessed on the Robot's programmable brick, the left Ultrasonic sensor can be pivoted out of the way and then pivoted back when the Robot is ready to run.

The code of the Robot is programmed with a default of moving slightly to left. If the left Ultrasonic sensor detects an object less than 80 cm away, the Robot will turn slightly to the right. If there is an object less than 30 cm away from the front Ultrasonic sensor, the Robot will back up for 1 second. If there is object greater than 30 cm away from the front Ultrasonic sensor but less than 80 cm away, the Robot will turn sharply to the right. The way it is programmed, the front Ultrasonic sensor functions always take precedence over the left Ultrasonic sensor functions. This code works together to drive the Robot all the way around the hallway.

This video shows the final product of this project.

Technical and scientific knowledge
- The majority of this project was using Matlab and Simulink to write the Robot's code. We had no idea of how Matlab and Sumulink worked, so we were taught the basics by Professor Edelen to help us get started. Although we did not know how to use Matlab and Simulink, prior knowledge of Java and C++ was very helpful for writing algorithms and programs for the Robot.

- We had to research on how NXT Lego robots worked and how they were compatible with Matlab and Simulink.

- Since this project was completely new to us, we had to look up on how to use ultrasonic sensors and how they were supposed to work.

Creativity, problem solving, and group decision-making
The main problems were to figured out a way to make the Robot turn a corner in the hallway and a way to make the Robot avoid obstacles. Using different scenarios, reviewing metrics, and considering the sensors used by the robot, the idea of always going left was adopted, along with using two ultrasonic sensors. We decided to do this because it was a simple way to make the Robot follow the inner wall all the way around the hallway. It was decided to use two ultrasonic sensors because one could make the Robot stay a distance away from the inner wall, and the other could keep the Robot from running into obstacles. Several positions were tested to find the best locations for the ultrasonic sensors. We decided to put the front ultrasonic sensor in the front and low to the ground so it would be closer to sensing obstacles and it could see smaller obstacles that were closer to the ground. We put the left ultrasonic sensor on the right so it would not get caught on obstacles when the Robot was going around obstacles.

Another problem was the issue of having the Robot back up in a timely and efficient manner. The robot was turning sharply and come face-to-face with an obstacle. When this happened backing up was not enough because the program was not written properly, so the Robot would only back up when it saw the object for the entire range that the front ultrasonic sensor planned it for. The most important decision was going back to the beginning to resolve this impasse. The logic was redrawn and the code was rewritten to match it.

Prior work in the field, standardization and reuse of designs (including reverse engineering and redesign)
In order to design the software, a week of preparations was used. It was for:
 * Understanding how a lego robot works ( ultrasonic sensor, compass sensor, how to make the robot turn and metrics used);
 * Finding how to use matlab and Simulink to design a logic (reverse engineering);

Modeling and/or Simulation
See above for Simulink models and a flow chart for different models of software and sensors' location.

Performance, life cycle cost and value
The performance will be based on how well the code is written. Aside of the life cycle of product and battery, it should not require additional cost to drive the robot along the hallway or to run the software (as long as the same version of matlab is used).

Aesthetics and human factors
Aesthetics were not important but an effort was made to not alter the physical appearance of the robot in a ridiculous manner. However, the changes made regarding the position of the left sensor brought a minor challenge. The pivot must be used to start the robot and put back into place right after.

Also, a corrosion was found at the far right battery slot. Batteries should be taken out if the robot will not be used for a long period of time.

Finally, documentation is very important for continuity.

Implementation, verification, test and environmental sustainability
A test of our final design was made and it worked. The robot is backing up at the beginning for a reason not yet determined but it drives along the hallway which proves that it is a viable design and the implementation will require some adjustments. Environmental sustainability was not a concern.

Maintainability, reliability, and safety
The software requires no maintenance and is only reliable along the path the robot has been assigned to drive along. From our last test, it seems that the robot is following any moving obstacle as well. Safety is not a concern but in order to prevent damages on it, the left ultrasonic sensor was mounted to the right (it still points to the left).

Robustness, evolution, product improvement and retirement
There is no plan for product improvement. The software is designed with the idea of using only the ultrasonic sensors. Unless their range improves and they are replaced, the logic can stay the same.