User:N ngea/ENES100/Project 2

Project Preference
Mobile Robot Hallway - Bioengineering Project - Makerbot PLA characterization

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.

Project Plan
Here is our projection for the next four weeks:

The most difficult part will be to implement design.

Week 1 Narrative
This week, we were to get acquainted with the system : the robot has 2 motors, one compass and an ultrasonic sensor. The teacher provided some information on how to use matlab to program the robot. As it was our first time working with a robot, we spent the whole week looking for tutorials on Simulink and Lego. These two were particularly useful: http://www.mathworks.com/videos/modeling-logic-for-robot-control-81979.html http://www.mathworks.com/videos/a-hands-on-approach-to-teaching-with-lego-mindstorms-and-simulink-81794.html

The idea was to prepare so I could replicate and implement the following design from our teacher's profile:

As I was getting ready to implement the design, I realized I did not know what were the sensors metrics and even how the robot was moving. I decided to look up the different blocks in Simulink that were on the logic diagram. This helped me understand why and how the robot was put together. I also decided to divide my work in two parts:

This gave me the following idea: Add a second sensor so the robot stays off the wall and turn in an easy sequence.
 * Ultrasonic sensor metric: I first used the sensor with the left motor. The experiment was not conclusive so I decided to use the LCD to get some readings. It appears the sensor uses cm and can measure up to 255cm. It can only see what is in front of it.

The draw back is that the sensor is unstable so a delay must be introduced in the code to avoid unexpected behavior.


 * Motors: I had to use the encoder to generate an output on the LCD but it was not useful. I am not sure what the value means but I know now that this will help me map a path in terms of wheels' rotation. So I tried to use the ultrasonic sensor but the robot started spinning very fast. I concluded a code is needed to move the robot in a straight line and turn on the conditions illustrated above. I will need controllers block. After watching and running several models, I still do not know how it works or at least modify it.

The question is now, moving the robot requires mapping the path (closed loop) or can it just move? How? We were not able to replicate the teacher's model but we will try next week to move the robot in a straight line. It is still very confusing how to use Simulink. Coding requires a library but I have not found yet what are the functions or, as it seems any simulation is converted to c language, see that code.

Week 2 Narrative
Our goal this week was to move the robot along the hallway without avoiding any obstacle since we were not able to drive it last week. We consulted with the teacher who showed us different features of Matlab: using only block diagrams or insert Matlab functions. As we tested a timed maneuver (the robot should go backwards for 5 seconds when a signal is triggered), we realized we should move the ultrasonic sensor to a lower place because of its limited sight range. We also realized that the robot is not moving straight. We considered the third wheel in the back being the issue but once we removed it, we realized the robot was not balanced anymore. So we decided to test our idea of using two ultrasonic sensors or, as it seems, make the robot follow the wall. We noticed that the robot was following the wall rather awkwardly. We had to make it turn faster and increase the distance so the robot will not be stuck while trying to turn. We also noticed that lowering the ultrasonic sensor was not a good idea since it was running directly through the pillar because the side wall was elevated and out of sight. It was also looking at the distance between the pillar and the wall and interpret it as 'normal'. As I read that code, I decided to improve on that and work more on the 'awkward' behavior of the robot. We were only defining exceptions. What happens when the robot is stuck into a corner? First, I needed to define a normal behavior and from there build the exceptions with their different scenarios. Since I could not find the touch sensor, I decided to trigger the exception of going backwards for 5 seconds if the ultrasonic sensor reads a value 0 and based on the left sensor value, to turn right or left. Here is the design used:

As we could not get it to work, we tried without the timer and was not successful either. However, we realized that triggering the alarm when the front ultrasonic sensor reads 0 will not be enough if it stills reads a 'normal' distance while being stuck. We will need to move the front ultrasonic sensor up and add the touch sensor. We can also try to put that former sensor closer in the front so it reads at a 90-degree angle or less but not more than that.

Finally, the ultrasonic sensor flickers with its reading. Which might explain why the robot is not moving straight. Each wheel has its own motor so that might also explains it.

For next week, we will still work on the design above and add the touch sensor. We will also find a way to calibrate the ultrasonic sensor, may be the sample time should be set lower or higher. We will try both and observe the robot behavior. https://en.wikiversity.org/wiki/User:Medelen8/ENES100/MRHN_Design_B#The_Design_Process

Week 3 Narrative
Following this, I was to add a timer and work on the different constraints that we have used so far: Here is our design so far:
 * To turn sharply to the right or left when an obstacle is within 30 cm from the front sensor, we use a speed of 35 . When the speed was increment to 50 then 40, the robot was not making the left turn to continue along the hallway.
 * The 30cm in front a front sensor was introduced because the robot could turn in a weird angle and being stuck. This value is used so the robot could back up early and give it enough space to maneuver out of it. The robot tend to get trapped between the wall and a pillar because it is following the wall. It happens when it turns at a weird angle to go closer to the wall. his caused to reevaluate our idea to have the robot go straight because then what will the condition to make it turn sharply unless an obstacle is too close from the front sensor?
 * We use 80 cm is our minimum distance to force the robot to follow the wall. Increasing the distance, the robot started spinning around itself so 80cm works well.
 * We decided to attempt to move the robot straight as a default behavior anyway. It made it through the hallway without getting stuck and have to back up. I still have some testing to do because the only reason the robot is turning sharp now is because of the front sensor. May be have a reasonable turn instead of 40 use 50, so the robot will not start spinning around(because of the left sensor reading forever the value 200 I set up as a trigger and keep turning.

We noticed that when the robot was backing up, it was very sudden, making the robot stand on the front wheels for a fraction of seconds. So we decided to add a timer. It took a while to figure out how to deal with global variables but finally we found this tutorial. It took a while to understand the instructions. At last, we were ready to implement. At first we tried by incrementing by 0.1 but it was so fast it barely helped. And the backing up was still abrupt. So we decided to keep track of the speed using other variables that we could just negate and use to back up. Since we know how to use global variable now, it was easy. We also increased the time to back up from 5s to 10 seconds. The robot was going back and forth at some point because it kept coming back to the spot it was trapped or almost. We will try to increase that value again and see.

Finally, we worked on improving our program by working a different design. We did not get successful but the results were very helpful in explaining the robot's logic and giving ideas on how to improve our software and code with matlab. It was very helpful to set up the timer. For instance our iterations are not standard but once we standardized them, the robot was not moving the way we expected. https://en.wikiversity.org/wiki/User:Medelen8/ENES100/MRHN_Design_B#Appropriate_optimization_in_the_presence_of_constraints https://en.wikiversity.org/wiki/User:Medelen8/ENES100/MRHN_Design_B#Iteration_until_convergence

Week 4 Narrative
Last week design was tested and the backing up was not working for the time allotted because the other exceptions were taking over. Tracking the speed turned out to be a bad idea (the robot was not driving as before) so we decided to back up straight. We also decided to meet with the teacher about some concerns we had about our code syntax and also how to make the robot backing up for 5 seconds. He recommended that we draw a logic for our software and showed us some code as example. We tried to implement that code on the existing design and failed. However, we corrected our syntax and got some interesting results: We could improve our existing design. We also did not need a clock and a global variable. We could use the global variable only. After a day of preparation (going over results from last test, teacher's notes and remarks, we were ready to write a code for testing. We tested it, make some minor changes and got some results. Therefore, this is our final design:

One thing that we did not seem to figure out was why the robot is backing up at the beginning when our global variable is at 0. We also worked on the CDIO report and reviewed the teacher's CDIO design phase report for guidance. []