• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

line following robot

Status
Not open for further replies.
Hi, im trying to follow a straight white line on green ground , i've a big problem in which the left motor is more faster than the right motor by a great degree , hence it makes a great deviation ... the two motors are at the same kind but they are used ... how to solve this problem ? also i tried to use another two motors , the same happens ! i dont know from where this problem ? mechanics or motors .. ?
 

dknguyen

Well-Known Member
Most Helpful Member
Since to the two of anything (motors, wheel diameters, drive circuitry, and force on the wheel) are never the same, there is mismatch which will cause the veering when trying to move in a straight line that you are describing. You have to add some kind of speed measurement to each motor like an encoder. THen you can actively measure the actual speed of each wheel and adjust accordingly so they are the same.

This will not correct for mismatched wheel size however.

But this is a line follower...who cares if it goes straight as long as it follows the line even if it is swerving back and forth as it follows the line. It has the line to keep it going straight.
 
Last edited:
yea the problem is the robot crawling like that / \ / \ at very low speed ...also is there an easy way to attach an encoder and is this the final soultion ? what if i bought new motors from internet would this make it better ?
 

dknguyen

Well-Known Member
Most Helpful Member
New motors won't help the problem since you can never get two that are exactly a like. I suppose you could spend a LOT of money to get two motors made to very tight tolerances but that's silly if all you want to do is travel in a straight line.

YOu are going to need to get encoders. They can be professionally made especially for that motor, or just homemade with circles of paper (with alternating light and dark marks) and light sensors. You can make an optical encoder fairly easily at home (there are other kinds too like magnetic, but they aren't so easy to make at home). If you make the dark and light marks in certain way and use two light sensors (and maybe an LED to illuminate te paper wheel) properly positioned so they are out of phase by 90 degrees apart relative to the markings on the wheel, you have a "quadrature encoder" and can also determine the direction the motor is spinning in. BUt it's more work, and all you need is to know the speed (and not whether the wheel is moving forward or backwards since in your case you can assume fairly safeley which direction it is moving in).

Here is an example:
http://www.nubotics.com/index2.html

And here are some articles:
http://www.societyofrobots.com/sensors_encoder.shtml
http://www.geology.smu.edu/~dpa-www/robo/Encoder/pitt_html/encoders.html

EDIT:
Forget what I told you about the motors being mismatched. ALthough true, the solution of measuring wheelspeed is more for free roaming robots that need to move in a straight line and don't have anything as a reference. You have your line though which isn't necessarily straight (so perfectly matched motors and wheels won't do much anyways). THe line itself should be enough information for your robot to follow it accurately if the sensors provide accurate information to your motors so your motors don't overshoot the line by too much.

Your problem is that the sensors on the robot aren't accurate enough to follow the line without overshooting it (that's why it zig zags across the line). Although motor and drive mismatch is part of the problem, they can both be solved by adding more line sensors to your robot so it can pinpoint exactly where the line better. THis will also help it with following the line without overshooting. In fact, I think this is what you should do for a line follower. THe measuring motor speed to move in a straight line is more for robots that need to move in a line but don't have anything to refer to. You have the line. Add more sensors so your robot can tell where the line is more accurately so it doesn't overshoot as much.
 
Last edited:
i use 6 sensors .. yea i wonder really i know some guys in vietnam and they never used feedback using encoders and they can follow the line very good and very smooth ... where's the secret in that ?

and thanks alot for replying
 

dknguyen

Well-Known Member
Most Helpful Member
Yeah, you the encoder thing is more for robots that need to blindly move in a straight line. You have a line to follow so it wouldn't help you.

6 sensors? Really? How are they positioned? Maybe their positioning is redundant (more than one sensor is basically doing the same job and not improving your accuracy).

If not, maybe your control algorithm could be better.
 
i position them like that X X X|X X X , so do you think at high speed it can follow the line ? although the high mismatch between the two motors ?

my robot always overshoot to right position , even the left sensors 1|2|3 doesnt react !! i dont know why ...
 
Last edited:

dknguyen

Well-Known Member
Most Helpful Member
All the encoder did was to provide speed/direction feedback to the wheels to make sure they move in a straight path. BUt since you aren't moving in a straight, unmarked path (you are following a curvey line) then the encoders would not solve your problem since they are two different scenarios. The line sensors do the same thing for following a line as the encoder did for moving in a straight path - they provide your robot with the necessary feedback to adjust motor speed. It should solve any mismatches between the motor (they could probably be two different kinds of motors and it would still work fine).

Your sensors aren't placed in a redundant way so I'm not sure what the problem is. But I think increasing the speed will just make things worse. There is a chance that your robot may not respond in time when moving at high speeds and the line passes under all the sensors before the robot can react in time.

THe best suggestion I have is is to add a sensor in the middle that the robot tries to keep over top of the line (in addition to trying to keep the line between the other sensors). That way, your robot will know the second it veers off from the line, rather than just knowing when it has veered off too far from the line (which is what the other sensors do). THat should help you reduce overshoot at all speeds and not lose the line at higher speeds.

Or you could place the two middle REALLY close together and they both have to see the line for you to be overtop of it. If one lost the line but the other saw it, you would know much sooner that you were veering off the line.
 
Last edited:
nope , the line isnt curved , its straight with horizontal lines ---|---
also when i bend the robot little so that the first sensors of the left array acts , it doesnt and it overshoots ...

the sensors arrangment are like X X X | X X X . line width is 3cm , the two middel sensors are 3.5Cm apart
 

dknguyen

Well-Known Member
Most Helpful Member
It doesnt make a difference if the line is curved or straight because your robot is still overshooting the line as it tries to reach the desired condition (the line's path) from an undesired condition (you probably can't perfectly line up your robot to the line at the start).

YOur line is wide enough relative to the middle sensor spacing so that both sensors can see the line. Does your code make the robot behave differently in that situation? I assume the standard situation is that no sensor sees the line and if a sensor sees the line, the robot will start to veer in the opposite direction until the opposite sensor sees the line, and then it again veers in the opposite direction? This would cause your robot to constantly overshoot the line since your "tolerance" for following the line is too large.

I still think you should have another sensor used to detect the line when the robot is following it because right now you only have sensors to detect when IT'S NOT following line. A center sensor would tell your robot when it's doing right rather than just when it's doing wrong.
 
Last edited:
what if i turned 90 Degree and the robot isnt aligned on the line perfectly ?
the sensors should correct that misaligmnets shouldnt they ?
why they dont do that ? even at very low speed ..
also what's your opinion ?
 

dknguyen

Well-Known Member
Most Helpful Member
If your robot is 90 degrees to the line and all the sensors see the line, then the robot is confused since it's a different condition from a regular line following where only one sensor ever sees the line. You have to code what you want it to do in that case (like maybe stop and turn on the spot until only one sensor sees the line, then the regular code will be valid again and can reacquire the line).

It still might lose the line though if it is an outer sensor that detects the line and the robot starts moving in rhe wrong direction after it turns on the spot. But nothing is perfect. THe only way to reduce this particular problem really is to use more sensors, and even then you can still lose the line, just the robot has to be farther away from the line for it to happen after turning on the spot. (THat's why using more sensors in something like a circular arrangement might help a lot. You have multiple sensors on the front and back to see the line when you are on top of it, and multiple sensors to catch the line when you start to lose it including corners that are 90 degrees and sharper). But it makes things more complicated.
 
Last edited:
hi, what about using PID and the front sensors as feedback ? would it reduce that overshoot due to the missmatch of the motors ? i wrote a code and didnt test it yet , if you would like to see and check it for me , i would appericate that
 

dknguyen

Well-Known Member
Most Helpful Member
ahmedragia21 said:
hi, what about using PID and the front sensors as feedback ? would it reduce that overshoot due to the missmatch of the motors ? i wrote a code and didnt test it yet , if you would like to see and check it for me , i would appericate that
I've never coded for PID before and have not coded anything big in a long time. YOu should ask someone else.
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top