gerardo jimenez john merle final project report:...

9
Gerardo Jimenez John Merle FINAL PROJECT REPORT: THE PATHFINDER Motivation and Overall Concept: We want to see if we can mimic the transit of track-restricted transports. But unlike railroads that require two tracks to keep it in place, we want to make a transport that relies on one contrasting surface (black line on white surface) to keep it in place. We believe that this type of transport would be eco-friendlier and will not disrupt the environment as much as cars or other gas-powered vehicles. Also, for science! Our robot, which we will also call the pathfinder, will follow a predesigned path using sensors (Pololu QTA-3A) to see the path. It will correct itself if it is unaligned with the path to keep consistent turns and travel. The sensors will also help in properly turning and finding the path if it strays too far away and gets lost. Functional Definition: We will use a line sensor (Pololu QTA-3A) to collect data of the surface. It should process three separate lines. The two sensors at the end (refer to schematic) should read white lines while the center sensor follows a black line. During its course, it will adjust the speed of the DC motors that should precisely center the robot back to the correct course. The two DC motors will continuously run at the same time until the sensors senses that it is off-course. Depending on which side it detects the change, it will slow down or stop one motor. If the pathfinder is off- centered from the left side, the right motor will slow down or stop and vice versa. Once the pathfinder starts sensing the 3 lines, it will start recording the time. Once the robot follows the track for a minute it will blink once. Any minute after, it will add a blink. So if the robot was following the track for 5 minutes it will blink 5 times. Sensors: We originally planned on using only one Pololu QTR-3A Reflectance Sensor Array on our robot, but after many obstacles we decided on using two, which was difficult to implement after we built our line follower. The sensors would sense a difference between the floor and the path it would follow. We also originally wanted to incorporate the internal Arduino function millis() to keep track of how much time it took for the Arduino to make a its journey from start to finish. Mechanical Considerations: The pathfinder will have an external battery power source which will power our Arduino and 2 DC motors. There will be one motor on each side but it will have four wheels. Two wheels for stability and the other two will be powered by one DC motor each. We will have a rubber continuous track on each side to connect the two wheels making it somewhat like a tank. Originally we wanted to have one QTR-3A sensor to be mounted on the front to find the path we created. However, due to difficulties in other aspects of the project we will discuss later, we decided to mount two sensors on the front of the robot. This made it much easier for it to differentiate between the path and intersection.

Upload: buicong

Post on 26-Mar-2018

216 views

Category:

Documents


2 download

TRANSCRIPT

Gerardo Jimenez John Merle

FINAL PROJECT REPORT: THE PATHFINDER

Motivation and Overall Concept: We want to see if we can mimic the transit of track-restricted transports. But unlike

railroads that require two tracks to keep it in place, we want to make a transport that relies on one contrasting surface (black line on white surface) to keep it in place. We believe that this type of transport would be eco-friendlier and will not disrupt the environment as much as cars or other gas-powered vehicles. Also, for science!

Our robot, which we will also call the pathfinder, will follow a predesigned path using

sensors (Pololu QTA-3A) to see the path. It will correct itself if it is unaligned with the path to keep consistent turns and travel. The sensors will also help in properly turning and finding the path if it strays too far away and gets lost.

Functional Definition:

We will use a line sensor (Pololu QTA-3A) to collect data of the surface. It should process three separate lines. The two sensors at the end (refer to schematic) should read white lines while the center sensor follows a black line. During its course, it will adjust the speed of the DC motors that should precisely center the robot back to the correct course. The two DC motors will continuously run at the same time until the sensors senses that it is off-course. Depending on which side it detects the change, it will slow down or stop one motor. If the pathfinder is off-centered from the left side, the right motor will slow down or stop and vice versa.

Once the pathfinder starts sensing the 3 lines, it will start recording the time. Once the robot follows the track for a minute it will blink once. Any minute after, it will add a blink. So if the robot was following the track for 5 minutes it will blink 5 times.

Sensors: We originally planned on using only one Pololu QTR-3A Reflectance Sensor Array on our robot, but after many obstacles we decided on using two, which was difficult to implement after we built our line follower. The sensors would sense a difference between the floor and the path it would follow. We also originally wanted to incorporate the internal Arduino function millis() to keep track of how much time it took for the Arduino to make a its journey from start to finish.

Mechanical Considerations: The pathfinder will have an external battery power source which will power our Arduino

and 2 DC motors. There will be one motor on each side but it will have four wheels. Two wheels for stability and the other two will be powered by one DC motor each. We will have a rubber continuous track on each side to connect the two wheels making it somewhat like a tank.

Originally we wanted to have one QTR-3A sensor to be mounted on the front to find the path we created. However, due to difficulties in other aspects of the project we will discuss later, we decided to mount two sensors on the front of the robot. This made it much easier for it to differentiate between the path and intersection.

Electrical Considerations:

Our Pololu QTR-A3 Line Sensors give analog inputs so they will go to analog pins A1, A3, A4, and A5. A1 and A5 are the outside line sensors and A3 and A4 are the center sensors. A3 and A4 will be the sensors to follow the path. It both should be on the black line at all times unless at a right turn only and while turning. If either one of the sensors do not find itself on the path, then there will be a condition in the code that will make it fix itself so that both sensors see the path and the robot is going in a straight line.

The motor driver will communicate with Arduino via pins 3,5,8,9,10,11,12. PWMA connects to pin 3 on the Arduino. AIN2 connects to pin 5. AIN1 connects to pin 8. Stand by or STBY connects to pin 9. BIN1 connects to pin 11. BIN2 to pin 12 And finally PWMB to pin 10. The DC motors will connect to A01, A02, B01, and B02.

The robot will have a built-in battery compartment to power the Arduino, sensors, and both DC motors with AA batteries. After finishing the robot and continuing on to testing, we

found that having AA batteries power the whole robot was a bad idea because the batteries would drain quickly and the speed at which the DC motors would function changed. This also affected how our robot turned, because we calibrated the turns using a delay function. The drained batteries caused the robot to turn inconsistently, but it could still find it way to the end of the path.

Interface: We plan on programming with Arduino Uno which will process the inputs from the

sensors. Afterwards, it will direct the DC motors. We’ll use the following pins: 5V, VIN, GND, A1, A2, A3, A4, A5, 8,9,10,11,12, and 13. Our Analog pins will be inputs while our digital pins will be outputs. Refer to the Electrical Considerations for in detail discussion. The Arduino will not have any external communication except for the line the sensors pick up. We will need to check if our programming works by observing the robot’s behavior. We will use Serial monitor to debug as necessary.

Software:

Since both of us struggle with programming, the whole programming process will be hard for us. We will be programming in C using the Arduino IDE because it is really the only programing language we know and it was taught in class, so we have some confidence in using it.

We will use a motor shield to ease the programming of the motors. This will also allow us to use the analog pins of the Arduino. We will also utilize the AFMotor.h library to help us with programming the DC motors.

The most difficult part of the programming would be accurately coding the conditions for the robot to follow. There are many different conditions it would have to follow to consistently follow a path and solve a maze. Because of this, we decided to use some if() and else if() functions alongside a switch() function and a couple of case() functions.

We also created some of our own functions such as Uturn(), slowleft(), and slowright() just to name a few.

Testing:

During the testing phase, we decided to start simple and work our way into a more complicated maze. We started with a straight line where the robot would follow the line and turn around at the end so we could calibrate the Uturn function. We then added a turn so we could calibrate the left and right turn. Then, we added some intersections for complexity. We used the Serial Monitor to debug and check where our programming failed.

Safety:

Overall, the project is relatively safe. It does not involve any sharp objects, fire, chemicals, or water. There are no high voltages or dangerously fast moving objects involved either. The robot does not move very fast either due to its low power supply that is continuously drained. Worst case scenario, something short circuits and the whole thing bursts into flames… jk

Parts and Reusability:

The following are the parts we plan to use: (an asterisk next to any part is for our expansion options) (# next to a part is anything that can be remove if it gets too complex

• 1x Arduino Uno • 1x Pololu Zumo Chassis • 2x 30 RPM DC 6V Gearbox Motors • 2x Pololu QTR-3A Reflective Sensor Array • 1x LED # • 1x Motor Driver (Most likely the Pololu Dual DC Motor Driver TB6612FNG) • *LCD • *Speaker

As long as we don’t burn the circuit, pretty much everything in the project is reuseable with the exception of wires and other easily replaced objects.

Project Analysis:

When we started the project, we knew what we wanted to do and how we wanted to do it. We hoped that we would finish the project early so that we could add some modifications, such as adding an LCD to tell you how far the robot has travelled or a modification that uses another motor to create a path while he robot follows the path being laid down.

Once we got started, the first thing we built was the mount. Since it was provided for us, we didn’t have to 3D print one or build one in the shop. The DC motors were provided for us as well, but the connections were covered in burnt plastic which made it difficult to solder. We eventually burned off some plastic in order to create a more better connection.

The next step we took was assembling the whole robot. We soldered the connections and set the motors inside the mount then found a way to attach the Arduino to the robot. This made a very compact and easy to transfer project. After we had the Arduino connected to the mount, taped the first line sensor we used to the front of the robot.

During testing, we noticed that three sensors were not enough to accurately and consistently go through the path because of the width of the path. There wasn’t any way we could tell the Arduino to stay on a straight path if it veered to the left or right. So, we decided to add another sensor. We took the assembly apart and soldered the connections to the sensor and taped the sensors to the front of the robot side-by-side.

This allowed for a more consistent robot. However, other obstacles came up. The biggest and most irritating obstacle we faced was the small power supply being drained too fast. This changed the delays we put in and the calibrations we made. Its speed would constantly change so it would start missing turns or make a wrong turn not following the left-hand rule to solve the maze. It would still solve the maze due to the ingenious coding, but because of inconsistencies it wouldn’t solve it in a way we could optimize a solved path, which was another enhancement option we wanted to explore.

In order to make the robot more consistent in turns and following a path, we decided to limit the path to a 1.5-centimeter width. This allowed the two middle sensors to both be on the path with some wiggle room. We also decided to calibrate it while it had low power to keep some consistency.

In the end, we were beaten by time and had to present an imperfect project, but given more time and resources, we are sure that we would have achieved our envisioned project.

Code:

#include <AFMotor.h> int QTR1=A1; int QTR2=17; int QTR3=18; int QTR4=A5; int LFSensor[2]={0,0}; int farRight=0; int farLeft=0; int mode; int error; int Status; AF_DCMotor sipues(1); AF_DCMotor nopues(2); void setup() { pinMode(QTR1,INPUT); pinMode(QTR2,INPUT); pinMode(QTR3,INPUT); pinMode(QTR4,INPUT); Serial.begin(9600); sipues.setSpeed(255); nopues.setSpeed(255); } void loop() { LineSensors(); if (Status==0) {switch(mode) {case 0: {Left(); delay(10); break;} case 1: {Stop(); delay(100); inch(); LineSensors(); if(mode==1) {End();} else if(mode==2)

{Left();} break;} case 2: {straight(); delay(10); LineSensors(); break;} case 3: {inch(); LineSensors(); if (mode==3) {Uturn(); delay(10);} break;} case 4: {slowleft(); break;} case 5: {slowright(); break;} case 6: {LineSensors(); right(); delay(10); straight(); break;} delay(10);} delay(500);} void LineSensors() {farLeft=analogRead(QTR1); LFSensor[0]=digitalRead(QTR2); LFSensor[1]=digitalRead(QTR3); farRight=analogRead(QTR4); if((farLeft>=800)&&(farRight<900)) {mode=0;} else if((farLeft>=800)&&(LFSensor[0]==1)&&(LFSensor[1]==0)&&(farRight<900)) {mode=0;} else if((LFSensor[0]==1)&&(LFSensor[1]== 1 )&&(farLeft>=500)&&(farRight >= 900)) {mode=1;} else if ((LFSensor[0]==1 )&&(LFSensor[1]== 1)&&(farLeft<800)&&(farRight<900)) {mode=2; } else if((LFSensor[0]== 0 )&&(LFSensor[1]== 0 )&&(farLeft<800)&&farRight<900) {mode=3;}

else if((LFSensor[0]== 1 )&&(LFSensor[1]== 0 )&&(farLeft<800)&&(farRight<900)) {mode=5;} else if((LFSensor[0]== 0 )&&(LFSensor[1]== 1 )&&(farLeft<800)&&(farRight<900)) {mode=4;} else if((farLeft<800)&&(farRight>=900)) {mode=6;} else if((farLeft<800)&&(LFSensor[0]==0)&&(LFSensor[1]==1)&&(farRight>=900)) {mode=6;} } void Uturn() {sipues.run(FORWARD); nopues.run(FORWARD); delay(3500); } void inch() { straight(); delay(700); Stop(); } void straight() { sipues.setSpeed(200); nopues.setSpeed(200); sipues.run(BACKWARD); nopues.run(FORWARD); delay(10); } void Left() { inch(); delay(10); sipues.run(FORWARD); nopues.run(FORWARD); delay(2200); Stop(); } void right() { inch(); delay(10); LineSensors(); if(mode==2) {mode=2;}

else { sipues.run(BACKWARD); nopues.run(BACKWARD); delay(2200); Stop();} } void slowright() {Stop(); delay(500); sipues.setSpeed(0); nopues.setSpeed(110); sipues.run(BACKWARD); nopues.run(FORWARD); } void slowleft() {Stop(); delay(500); sipues.setSpeed(120); nopues.setSpeed(0); sipues.run(BACKWARD); nopues.run(FORWARD); } void Stop() { sipues.run(RELEASE); nopues.run(RELEASE); delay(10); } void End() {Stop(); Status=1;}